Re: [FFmpeg-devel] [PATCH v3 1/5] libavcodec/vc2enc: Split out common functions between software and hardware encoders
IndecisiveTurtle:
> From: IndecisiveTurtle
>
> ---
> libavcodec/Makefile| 2 +-
> libavcodec/vc2enc.c| 513 +
> libavcodec/vc2enc_common.c | 376 +++
> libavcodec/vc2enc_common.h | 196 ++
> 4 files changed, 581 insertions(+), 506 deletions(-)
> create mode 100644 libavcodec/vc2enc_common.c
> create mode 100644 libavcodec/vc2enc_common.h
>
> diff --git a/libavcodec/Makefile b/libavcodec/Makefile
> index 7bd1dbec9a..d4ebd86866 100644
> --- a/libavcodec/Makefile
> +++ b/libavcodec/Makefile
> @@ -769,7 +769,7 @@ OBJS-$(CONFIG_VC1_CUVID_DECODER) += cuviddec.o
> OBJS-$(CONFIG_VC1_MMAL_DECODER)+= mmaldec.o
> OBJS-$(CONFIG_VC1_QSV_DECODER) += qsvdec.o
> OBJS-$(CONFIG_VC1_V4L2M2M_DECODER) += v4l2_m2m_dec.o
> -OBJS-$(CONFIG_VC2_ENCODER) += vc2enc.o vc2enc_dwt.o diractab.o
> +OBJS-$(CONFIG_VC2_ENCODER) += vc2enc.o vc2enc_dwt.o
> vc2enc_common.o diractab.o
Overlong line
> OBJS-$(CONFIG_VCR1_DECODER)+= vcr1.o
> OBJS-$(CONFIG_VMDAUDIO_DECODER)+= vmdaudio.o
> OBJS-$(CONFIG_VMDVIDEO_DECODER)+= vmdvideo.o
> diff --git a/libavcodec/vc2enc_common.h b/libavcodec/vc2enc_common.h
> new file mode 100644
> index 00..eaaf5ac99c
> --- /dev/null
> +++ b/libavcodec/vc2enc_common.h
> @@ -0,0 +1,196 @@
> +/*
> + * Copyright (C) 2016 Open Broadcast Systems Ltd.
> + * Author2016 Rostislav Pehlivanov
> + *
> + * 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
> + */
> +
> +#ifndef AVCODEC_VC2ENC_COMMON_H
> +#define AVCODEC_VC2ENC_COMMON_H
> +
> +#include "avcodec.h"
> +#include "dirac.h"
> +#include "put_bits.h"
> +
> +#include "vc2enc_dwt.h"
> +#include "diractab.h"
> +
> +/* The limited size resolution of each slice forces us to do this */
> +#define SSIZE_ROUND(b) (FFALIGN((b), s->size_scaler) + 4 + s->prefix_bytes)
> +
> +/* Decides the cutoff point in # of slices to distribute the leftover bytes
> */
> +#define SLICE_REDIST_TOTAL 150
Need not be put in a header.
> +
> +typedef struct VC2BaseVideoFormat {
> +enum AVPixelFormat pix_fmt;
> +AVRational time_base;
> +int width, height;
> +uint8_t interlaced, level;
> +char name[13];
> +} VC2BaseVideoFormat;
> +
> +extern const VC2BaseVideoFormat base_video_fmts[];
> +extern const int base_video_fmts_len;
> +
> +enum VC2_QM {
> +VC2_QM_DEF = 0,
> +VC2_QM_COL,
> +VC2_QM_FLAT,
> +
> +VC2_QM_NB
> +};
> +
> +typedef struct SubBand {
> +dwtcoef *buf;
> +ptrdiff_t stride;
> +int width;
> +int height;
> +int shift;
> +} SubBand;
> +
> +typedef struct Plane {
> +SubBand band[MAX_DWT_LEVELS][4];
> +dwtcoef *coef_buf;
> +int width;
> +int height;
> +int dwt_width;
> +int dwt_height;
> +ptrdiff_t coef_stride;
> +} Plane;
> +
> +typedef struct SliceArgs {
> +const struct VC2EncContext *ctx;
> +union {
> +int cache[DIRAC_MAX_QUANT_INDEX];
> +uint8_t *buf;
> +};
> +int x;
> +int y;
> +int quant_idx;
> +int bits_ceil;
> +int bits_floor;
> +int bytes;
> +} SliceArgs;
> +
> +typedef struct TransformArgs {
> +const struct VC2EncContext *ctx;
> +Plane *plane;
> +const void *idata;
> +ptrdiff_t istride;
> +int field;
> +VC2TransformContext t;
> +} TransformArgs;
> +
> +typedef struct VC2EncContext {
> +AVClass *av_class;
> +PutBitContext pb;
> +Plane plane[3];
> +AVCodecContext *avctx;
> +DiracVersionInfo ver;
> +
> +SliceArgs *slice_args;
> +TransformArgs transform_args[3];
> +
> +/* For conversion from unsigned pixel values to signed */
> +int diff_offset;
> +int bpp;
> +int bpp_idx;
> +
> +/* Picture number */
> +uint32_t picture_number;
> +
> +/* Base video format */
> +int base_vf;
> +int level;
> +int profile;
> +
> +/* Quantization matrix */
> +uint8_t quant[MAX_DWT_LEVELS][4];
> +int custom_quant_matrix;
> +
> +/* Division LUT */
> +uint32_t qmagic_lut[116][2];
> +
> +int num_x; /* #slices horizontally */
> +int num_y; /* #slices vertically */
> +int prefix_bytes;
> +int size_scaler;
> +int chroma_x_shi
Re: [FFmpeg-devel] [PATCH v3 5/5] lavc: implement a Vulkan-based VC-2 encoder Implements a Vulkan based dirac encoder. Supports Haar and Legall wavelets and should work with all wavelet depths.
IndecisiveTurtle:
> From: IndecisiveTurtle
>
> Performance wise, encoding a 1080p 1-minute video is performed in about 2.5
> minutes with the cpu encoder running on my Ryzen 5 4600H, while it takes
> about 30 seconds on my NVIDIA GTX 1650
>
> Haar shader has a subgroup optimized variant that applies when configured
> wavelet depth allows it
> ---
> +
> +void put_vc2_ue_uint(inout PutBitContext pb, uint val)
> +{
> +int pbits = 0, topbit = 1, maxval = 1, bits = 0;
> +if (val == 0)
> +{
> +put_bits(pb, 1, 1);
> +return;
> +}
> +val++;
> +
> +while (val > maxval)
> +{
> +topbit <<= 1;
> +bits++;
> +maxval <<= 1;
> +maxval |= 1;
> +}
> +
> +for (int i = 0; i < bits; i++)
> +{
> +topbit >>= 1;
> +pbits <<= 2;
> +if ((val & topbit) != 0)
> +pbits |= 1;
> +}
> +
> +put_bits(pb, bits * 2 + 1, (pbits << 1) | 1);
> +}
> +
You are still using the old and inefficient way to write VC-2
exponential coded integers. Improving this gave a nice speed boost to
the software encoder.
- Andreas
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] libavfilter/ebur128: SIMD optimization
Thank you for the feedback. OK I understand. We’ll do that. Guillaume ___ 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 v3] libavutil: Add AVMap
On 4/17/25 16:12, Michael Niedermayer wrote: + * @param keyvalue_cmp compare function, will be passed the key + value concatenated. Please no. Pass the key and the value separately to the compare function. thats neither efficient nor does it fit the existing APIs. The value is most of the time not used and when used it is known exactly where it is. after a string compare of the key thats equal the value location is known or with arbitrary binary data the compare function knows the size of the data. Passing redudant pointers just wastes cpu cycles also existing APIs from av_tree strcmp() av_strcasecmp() and so on none of which take 4 pointers from which they would ignore 2. The problem is that passing the key and value pairs combined requires you to concatenate them. Since AVMapEntry has two separate pointers *key and *value, it doesn't make sense to concatenate them before comparison rather than just pass the pointers as-is. - Leo Izen (Traneptora) ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH] avcodec/vc2enc: Improve error codes
Patch attached.
- Andreas
From 7ef2a150ad06043c1e97d565360d7366f5fb81fe Mon Sep 17 00:00:00 2001
From: Andreas Rheinhardt
Date: Fri, 18 Apr 2025 11:09:21 +0200
Subject: [PATCH] avcodec/vc2enc: Improve error codes
Signed-off-by: Andreas Rheinhardt
---
libavcodec/vc2enc.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/libavcodec/vc2enc.c b/libavcodec/vc2enc.c
index d05df64911..99ca95c40a 100644
--- a/libavcodec/vc2enc.c
+++ b/libavcodec/vc2enc.c
@@ -1080,13 +1080,13 @@ static av_cold int vc2_encode_init(AVCodecContext *avctx)
if ((s->slice_width & (s->slice_width - 1)) ||
(s->slice_height & (s->slice_height - 1))) {
av_log(avctx, AV_LOG_ERROR, "Slice size is not a power of two!\n");
-return AVERROR_UNKNOWN;
+return AVERROR(EINVAL);
}
if ((s->slice_width > avctx->width) ||
(s->slice_height > avctx->height)) {
av_log(avctx, AV_LOG_ERROR, "Slice size is bigger than the image!\n");
-return AVERROR_UNKNOWN;
+return AVERROR(EINVAL);
}
if (s->base_vf <= 0) {
@@ -1096,7 +1096,7 @@ static av_cold int vc2_encode_init(AVCodecContext *avctx)
} else {
av_log(avctx, AV_LOG_WARNING, "Given format does not strictly comply with "
"the specifications, decrease strictness to use it.\n");
-return AVERROR_UNKNOWN;
+return AVERROR(EINVAL);
}
} else {
av_log(avctx, AV_LOG_INFO, "Selected base video format = %i (%s)\n",
--
2.45.2
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH v3 5/5] lavc: implement a Vulkan-based VC-2 encoder Implements a Vulkan based dirac encoder. Supports Haar and Legall wavelets and should work with all wavelet depths.
IndecisiveTurtle: > From: IndecisiveTurtle > > Performance wise, encoding a 1080p 1-minute video is performed in about 2.5 > minutes with the cpu encoder running on my Ryzen 5 4600H, while it takes > about 30 seconds on my NVIDIA GTX 1650 These are the same numbers as the first version of this patchset, yet the software encoder received speedups in the meantime. > > Haar shader has a subgroup optimized variant that applies when configured > wavelet depth allows it > --- > configure| 1 + > libavcodec/Makefile | 3 + > libavcodec/allcodecs.c | 1 + > libavcodec/vc2enc_vulkan.c | 959 +++ > libavcodec/vulkan/vc2_dwt_haar.comp | 82 ++ > libavcodec/vulkan/vc2_dwt_haar_subgroup.comp | 75 ++ > libavcodec/vulkan/vc2_dwt_hor_legall.comp| 82 ++ > libavcodec/vulkan/vc2_dwt_upload.comp| 96 ++ > libavcodec/vulkan/vc2_dwt_ver_legall.comp| 78 ++ > libavcodec/vulkan/vc2_encode.comp| 169 > libavcodec/vulkan/vc2_slice_sizes.comp | 170 > 11 files changed, 1716 insertions(+) > create mode 100644 libavcodec/vc2enc_vulkan.c > create mode 100644 libavcodec/vulkan/vc2_dwt_haar.comp > create mode 100644 libavcodec/vulkan/vc2_dwt_haar_subgroup.comp > create mode 100644 libavcodec/vulkan/vc2_dwt_hor_legall.comp > create mode 100644 libavcodec/vulkan/vc2_dwt_upload.comp > create mode 100644 libavcodec/vulkan/vc2_dwt_ver_legall.comp > create mode 100644 libavcodec/vulkan/vc2_encode.comp > create mode 100644 libavcodec/vulkan/vc2_slice_sizes.comp > > diff --git a/configure b/configure > index c94b8eac43..16ee163b05 100755 > --- a/configure > +++ b/configure > @@ -3130,6 +3130,7 @@ utvideo_encoder_select="bswapdsp huffman llvidencdsp" > vble_decoder_select="llviddsp" > vbn_decoder_select="texturedsp" > vbn_encoder_select="texturedspenc" > +vc2_vulkan_encoder_select="vulkan spirv_compiler" > vmix_decoder_select="idctdsp" > vc1_decoder_select="blockdsp h264qpel intrax8 mpegvideodec qpeldsp vc1dsp" > vc1image_decoder_select="vc1_decoder" > diff --git a/libavcodec/Makefile b/libavcodec/Makefile > index d4ebd86866..79505f8ef1 100644 > --- a/libavcodec/Makefile > +++ b/libavcodec/Makefile > @@ -770,6 +770,9 @@ OBJS-$(CONFIG_VC1_MMAL_DECODER)+= mmaldec.o > OBJS-$(CONFIG_VC1_QSV_DECODER) += qsvdec.o > OBJS-$(CONFIG_VC1_V4L2M2M_DECODER) += v4l2_m2m_dec.o > OBJS-$(CONFIG_VC2_ENCODER) += vc2enc.o vc2enc_dwt.o > vc2enc_common.o diractab.o > +OBJS-$(CONFIG_VC2_VULKAN_ENCODER) += vc2enc_vulkan.o > vulkan/vc2_encode.o vulkan/vc2_slice_sizes.o \ > + vulkan/vc2_dwt_hor_legall.o > vulkan/vc2_dwt_ver_legall.o \ > + vulkan/vc2_dwt_upload.o vulkan/ overlong lines vc2_dwt_haar.o vulkan/vc2_dwt_haar_subgroup.o > OBJS-$(CONFIG_VCR1_DECODER)+= vcr1.o > OBJS-$(CONFIG_VMDAUDIO_DECODER)+= vmdaudio.o > OBJS-$(CONFIG_VMDVIDEO_DECODER)+= vmdvideo.o > diff --git a/libavcodec/allcodecs.c b/libavcodec/allcodecs.c > index f10519617e..054b0d958b 100644 > --- a/libavcodec/allcodecs.c > +++ b/libavcodec/allcodecs.c > @@ -365,6 +365,7 @@ extern const FFCodec ff_vc1image_decoder; > extern const FFCodec ff_vc1_mmal_decoder; > extern const FFCodec ff_vc1_qsv_decoder; > extern const FFCodec ff_vc1_v4l2m2m_decoder; > +extern const FFCodec ff_vc2_vulkan_encoder; > extern const FFCodec ff_vc2_encoder; > extern const FFCodec ff_vcr1_decoder; > extern const FFCodec ff_vmdvideo_decoder; > diff --git a/libavcodec/vc2enc_vulkan.c b/libavcodec/vc2enc_vulkan.c > new file mode 100644 > index 00..d90d65e36d > --- /dev/null > +++ b/libavcodec/vc2enc_vulkan.c > @@ -0,0 +1,959 @@ > +/* > + * Copyright (C) 2025 raphaelthegreat > + * > + * 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/avassert.h" > +#include "libavutil/mem.h" > +#include "libavutil/pixdesc.h" > +#include "libavutil/opt.h" > +#include "libavutil/thread.h" > +#include "libavutil/version.h" > +#include "libavutil/vulkan_spirv.h" > +#include "libavutil/hwcontext_vulkan.h" > +#include
[FFmpeg-devel] [PATCH] vulkan: use ReadWithoutFormat/WriteWithoutFormat
This implements support for reading and writing storage images with
no format.
The issue is that we define our images as arrays, and arrays can
only have a single type, which means that f.ex. NV12 needs two
different images, R8 and RG8.
Not using any formats fixes this.
---
libavutil/vulkan.c | 22 +-
1 file changed, 17 insertions(+), 5 deletions(-)
diff --git a/libavutil/vulkan.c b/libavutil/vulkan.c
index 8f444b2dfe..4bf3f76d78 100644
--- a/libavutil/vulkan.c
+++ b/libavutil/vulkan.c
@@ -1804,10 +1804,13 @@ static VkFormat map_fmt_to_rep(VkFormat fmt, enum
FFVkShaderRepFormat rep_fmt)
return VK_FORMAT_UNDEFINED;
}
-static void bgr_workaround(AVVulkanFramesContext *vkfc,
+static void bgr_workaround(FFVulkanContext *s,
+ AVVulkanFramesContext *vkfc,
VkImageViewCreateInfo *ci)
{
-if (!(vkfc->usage & VK_IMAGE_USAGE_STORAGE_BIT))
+if (!(vkfc->usage & VK_IMAGE_USAGE_STORAGE_BIT) ||
+s->feats.features.shaderStorageImageReadWithoutFormat ||
+s->feats.features.shaderStorageImageWriteWithoutFormat)
return;
switch (ci->format) {
#define REMAP(src, dst) \
@@ -1858,7 +1861,7 @@ int ff_vk_create_imageview(FFVulkanContext *s,
.layerCount = 1,
},
};
-bgr_workaround(vkfc, &view_create_info);
+bgr_workaround(s, vkfc, &view_create_info);
if (view_create_info.format == VK_FORMAT_UNDEFINED) {
av_log(s, AV_LOG_ERROR, "Unable to find a compatible representation "
"of format %i and mode %i\n",
@@ -1920,7 +1923,7 @@ int ff_vk_create_imageviews(FFVulkanContext *s,
FFVkExecContext *e,
.layerCount = 1,
},
};
-bgr_workaround(vkfc, &view_create_info);
+bgr_workaround(s, vkfc, &view_create_info);
if (view_create_info.format == VK_FORMAT_UNDEFINED) {
av_log(s, AV_LOG_ERROR, "Unable to find a compatible
representation "
"of format %i and mode %i\n",
@@ -2060,6 +2063,9 @@ int ff_vk_shader_init(FFVulkanContext *s, FFVulkanShader
*shd, const char *name,
GLSLC(0, #extension GL_EXT_scalar_block_layout : require
);
GLSLC(0, #extension GL_EXT_shader_explicit_arithmetic_types : require
);
GLSLC(0, #extension GL_EXT_control_flow_attributes : require
);
+if (s->feats.features.shaderStorageImageReadWithoutFormat ||
+s->feats.features.shaderStorageImageWriteWithoutFormat)
+GLSLC(0, #extension GL_EXT_shader_image_load_formatted : require
);
if (s->extensions & FF_VK_EXT_EXPECT_ASSUME) {
GLSLC(0, #extension GL_EXT_expect_assume : require
);
} else {
@@ -2458,7 +2464,13 @@ print:
GLSLA("layout (set = %i, binding = %i", FFMAX(shd->nb_descriptor_sets
- 1, 0), i);
if (desc[i].mem_layout)
-GLSLA(", %s", desc[i].mem_layout);
+if ((desc[i].type != VK_DESCRIPTOR_TYPE_STORAGE_IMAGE) ||
+(!strcmp(desc[i].mem_quali, "readonly") &&
+ !s->feats.features.shaderStorageImageReadWithoutFormat) ||
+(!strcmp(desc[i].mem_quali, "writeonly") &&
+ !s->feats.features.shaderStorageImageWriteWithoutFormat))
+GLSLA(", %s", desc[i].mem_layout);
+
GLSLA(")");
if (prop->is_uniform)
--
2.49.0.395.g12beb8f557c
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH] lavc/vvc: Detect subpic overlaps at CTU level
In d5dbcc00d889fb17948b025a468b00ddbea9e058, it was hoped that detection
of subpicture overlaps could be performed at the tile level, so as to
avoid introducing per-CTU checks. Unfortunately since that patch,
fuzzing has indicated there are some structures involving
pps_subpic_one_or_more_tiles_slice where tile-level checking is not
sufficient. Performing the check at the CTU level should (touch wood)
be the be-all and and-all of this, as CTUs are the lowest common
denominator of the picture partitioning.
Signed-off-by: Frank Plowman
---
libavcodec/vvc/ps.c | 81 +++--
1 file changed, 42 insertions(+), 39 deletions(-)
diff --git a/libavcodec/vvc/ps.c b/libavcodec/vvc/ps.c
index e8c312d8ac..4edfe408c0 100644
--- a/libavcodec/vvc/ps.c
+++ b/libavcodec/vvc/ps.c
@@ -402,14 +402,35 @@ static int ctu_rs(const int rx, const int ry, const
VVCPPS *pps)
return pps->ctb_width * ry + rx;
}
+static void pps_add_ctu(VVCPPS *pps, int *off, const int x, const int y)
+{
+pps->ctb_addr_in_slice[*off] = ctu_rs(x, y, pps);
+(*off)++;
+}
+
static int pps_add_ctus(VVCPPS *pps, int *off, const int rx, const int ry,
const int w, const int h)
{
int start = *off;
for (int y = 0; y < h; y++) {
for (int x = 0; x < w; x++) {
-pps->ctb_addr_in_slice[*off] = ctu_rs(rx + x, ry + y, pps);
-(*off)++;
+pps_add_ctu(pps, off, rx + x, ry + y);
+}
+}
+return *off - start;
+}
+
+// Similar to pps_add_ctus, but with a check to ensure a given CTU isn't used
+// multiple times, to be used with some of the more complex partitioning
mechanisms.
+static int pps_add_ctus_check(VVCPPS *pps, int *off, const int rx, const int
ry,
+const int w, const int h)
+{
+int start = *off;
+for (int y = 0; y < h; y++) {
+for (int x = 0; x < w; x++) {
+if (*off >= pps->ctb_count)
+return AVERROR_INVALIDDATA;
+pps_add_ctu(pps, off, rx + x, ry + y);
}
}
return *off - start;
@@ -451,50 +472,39 @@ static void subpic_tiles(int *tile_x, int *tile_y, int
*tile_x_end, int *tile_y_
(*tile_y_end)++;
}
-static bool mark_tile_as_used(bool *tile_in_subpic, const int tx, const int
ty, const int tile_columns)
-{
-const size_t tile_idx = ty * tile_columns + tx;
-if (tile_in_subpic[tile_idx]) {
-/* the tile is covered by other subpictures */
-return false;
-}
-tile_in_subpic[tile_idx] = true;
-return true;
-}
-
-static int pps_subpic_less_than_one_tile_slice(VVCPPS *pps, const VVCSPS *sps,
const int i, const int tx, const int ty, int *off, bool *tile_in_subpic)
+static int pps_subpic_less_than_one_tile_slice(VVCPPS *pps, const VVCSPS *sps,
const int i, const int tx, const int ty, int *off)
{
-const int subpic_bottom = sps->r->sps_subpic_ctu_top_left_y[i] +
sps->r->sps_subpic_height_minus1[i];
-const int tile_bottom = pps->row_bd[ty] + pps->r->row_height_val[ty] - 1;
-const bool is_final_subpic_in_tile = subpic_bottom == tile_bottom;
-
-if (is_final_subpic_in_tile && !mark_tile_as_used(tile_in_subpic, tx, ty,
pps->r->num_tile_columns))
-return AVERROR_INVALIDDATA;
-
-pps->num_ctus_in_slice[i] = pps_add_ctus(pps, off,
+const int ret = pps_add_ctus_check(pps, off,
sps->r->sps_subpic_ctu_top_left_x[i],
sps->r->sps_subpic_ctu_top_left_y[i],
sps->r->sps_subpic_width_minus1[i] + 1,
sps->r->sps_subpic_height_minus1[i] + 1);
-return 0;
+if (ret < 0)
+return ret;
+else {
+pps->num_ctus_in_slice[i] = ret;
+return 0;
+}
}
static int pps_subpic_one_or_more_tiles_slice(VVCPPS *pps, const int tile_x,
const int tile_y, const int x_end, const int y_end,
-const int i, int *off, bool *tile_in_subpic)
+const int i, int *off)
{
for (int ty = tile_y; ty < y_end; ty++) {
for (int tx = tile_x; tx < x_end; tx++) {
-if (!mark_tile_as_used(tile_in_subpic, tx, ty,
pps->r->num_tile_columns))
-return AVERROR_INVALIDDATA;
-
-pps->num_ctus_in_slice[i] += pps_add_ctus(pps, off,
+const int ret = pps_add_ctus_check(pps, off,
pps->col_bd[tx], pps->row_bd[ty],
pps->r->col_width_val[tx], pps->r->row_height_val[ty]);
+
+if (ret < 0)
+return ret;
+else
+pps->num_ctus_in_slice[i] += ret;
}
}
return 0;
}
-static int pps_subpic_slice(VVCPPS *pps, const VVCSPS *sps, const int i, int
*off, bool *tile_in_subpic)
+static int pps_subpic_slice(VVCPPS *pps, const VVCSPS *sps, const int i, int
*off)
{
int tx, ty, x_end, y_end;
@@ -503,9 +513,9 @@ static int pps_subpic_slice(VVCPPS *pps, const VVCSPS *sps,
const int i, int *of
subpic_tiles(&tx, &ty, &x_end, &y_end, sps, pps, i);
if (ty + 1 == y_end && sps->r->sps_subpic_height_minus1[i] + 1 <
pps->r->row_heigh
[FFmpeg-devel] [PATCH v3] libavutil: Add AVMap
AVL Tree based Map
compared to AVDictionary this has
* clone is O(n) instead of O(n²)
* copy is O(n*log n) instead of O(n²)
* O(log n) malloc() calls by default and O(1) if av_map_realloc() is used
instead of O(n)
* get/add/delete is O(log n)
*
* You can add (if memory is realloced before) and remove entries while a
iterator stays valid
* copy is atomic, a failure means the dst is unchanged
*
* there are restrictions on what compare function can be used on get depending
on how the Map was created
* you can mix case sensitive and case insensitive compare with
av_map_supercmp_*
* Supports binary objects, not just strings
Signed-off-by: Michael Niedermayer
---
libavutil/Makefile| 3 +
libavutil/map.c | 415 ++
libavutil/map.h | 270 +
libavutil/tests/map.c | 221
libavutil/tree.c | 6 +-
libavutil/tree_internal.h | 28 +++
tests/fate/libavutil.mak | 4 +
tests/ref/fate/map| 27 +++
8 files changed, 969 insertions(+), 5 deletions(-)
create mode 100644 libavutil/map.c
create mode 100644 libavutil/map.h
create mode 100644 libavutil/tests/map.c
create mode 100644 libavutil/tree_internal.h
create mode 100644 tests/ref/fate/map
diff --git a/libavutil/Makefile b/libavutil/Makefile
index 9ef118016bb..3a92748a482 100644
--- a/libavutil/Makefile
+++ b/libavutil/Makefile
@@ -81,6 +81,7 @@ HEADERS = adler32.h
\
replaygain.h \
ripemd.h \
samplefmt.h \
+ map.h \
sha.h \
sha512.h \
spherical.h \
@@ -173,6 +174,7 @@ OBJS = adler32.o
\
rc4.o\
ripemd.o \
samplefmt.o \
+ map.o\
side_data.o \
sha.o\
sha512.o \
@@ -290,6 +292,7 @@ TESTPROGS = adler32
\
random_seed \
rational\
ripemd \
+map \
sha \
sha512 \
side_data_array \
diff --git a/libavutil/map.c b/libavutil/map.c
new file mode 100644
index 000..59b87a1f074
--- /dev/null
+++ b/libavutil/map.c
@@ -0,0 +1,415 @@
+/*
+ * Copyright (c) 2025 Michael Niedermayer
+ *
+ * This file is part of FFmpeg.
+ *
+ * FFmpeg is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public
+ * License as published by the Free Software Foundation; either
+ * version 2.1 of the License, or (at your option) any later version.
+ *
+ * FFmpeg is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+ * Lesser General Public License for more details.
+ *
+ * You should have received a copy of the GNU Lesser General Public
+ * License along with FFmpeg; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA
+ */
+
+#include
+#include
+
+#include "avassert.h"
+#include "avstring.h"
+#include "error.h"
+#include "mem.h"
+#include "map.h"
+
+#include "tree_internal.h" // For improved readability with AVTreeNode, do NOT
touch AVTreeNode internals
+
+typedef struct{
+AVMapEntry map_entry;
+uint8_t treenode_and_keyvalue[0];
+} AVMapInternalEntry;
+
+struct AVMap{
+#define CMP_MASK 31
+AVMapCompareFunc cmp[27];
+AVMapCopyFunc copy;
+AVMapFreeFunc freef;
+int count;
+int deleted;
+int next; ///< index of entry in root array after all
used entries
+unsigned internal_entries_len;
+AVTreeNode *tree_root;
+AVMapInternalEntry *internal_entries;
+};
+
+static uint8_t
Re: [FFmpeg-devel] [PATCH v2] fate: add various FFv1 tests for 1024 slices
On Wed, Apr 16, 2025 at 04:09:13PM +0200, Lynne wrote: > This lets us test features that were broken earlier, as well as > test the hardware decoder by using the HWACCEL=vulkan option. > --- > tests/Makefile| 1 + > tests/fate/ffv1.mak | 46 +++ > tests/ref/fate/ffv1-s1024-bgra| 4 +++ > tests/ref/fate/ffv1-s1024-bgra-r | 4 +++ > tests/ref/fate/ffv1-s1024-gbrp16 | 4 +++ > tests/ref/fate/ffv1-s1024-gray8 | 4 +++ > tests/ref/fate/ffv1-s1024-gray8-r | 4 +++ > tests/ref/fate/ffv1-s1024-yuv444p | 4 +++ > 8 files changed, 71 insertions(+) > create mode 100644 tests/fate/ffv1.mak > create mode 100644 tests/ref/fate/ffv1-s1024-bgra > create mode 100644 tests/ref/fate/ffv1-s1024-bgra-r > create mode 100644 tests/ref/fate/ffv1-s1024-gbrp16 > create mode 100644 tests/ref/fate/ffv1-s1024-gray8 > create mode 100644 tests/ref/fate/ffv1-s1024-gray8-r > create mode 100644 tests/ref/fate/ffv1-s1024-yuv444p Fails on qemu mips grep -B5 Err fatelist -a0ead8e9e709b6e93dca3e972a00c3d3 *tests/data/fate/ffv1-s1024-bgra-r.out.framecrc -stddev:28285.12 PSNR: 7.30 MAXDIFF:60652 bytes: 7603200/ 2990 +0a1d65aa7861338163ea947628df10d1 *tests/data/fate/ffv1-s1024-bgra-r.out.framecrc +stddev:28282.37 PSNR: 7.30 MAXDIFF:60652 bytes: 7603200/ 2990 Test ffv1-s1024-bgra-r failed. Look at tests/data/fate/ffv1-s1024-bgra-r.err for details. make: *** [src/tests/Makefile:315: fate-ffv1-s1024-bgra-r] Error 1 -- -a0ead8e9e709b6e93dca3e972a00c3d3 *tests/data/fate/ffv1-s1024-bgra.out.framecrc -stddev:28285.12 PSNR: 7.30 MAXDIFF:60652 bytes: 7603200/ 2990 +0a1d65aa7861338163ea947628df10d1 *tests/data/fate/ffv1-s1024-bgra.out.framecrc +stddev:28282.37 PSNR: 7.30 MAXDIFF:60652 bytes: 7603200/ 2990 Test ffv1-s1024-bgra failed. Look at tests/data/fate/ffv1-s1024-bgra.err for details. make: *** [src/tests/Makefile:316: fate-ffv1-s1024-bgra] Error 1 -- -c191aec6b3d999278963ebdd6a326ec3 *tests/data/fate/ffv1-s1024-gbrp16.out.framecrc -stddev:28358.70 PSNR: 7.28 MAXDIFF:60652 bytes: 7603200/ 2990 +10856377a7a7fe64c30fd20893f86d6e *tests/data/fate/ffv1-s1024-gbrp16.out.framecrc +stddev:28468.66 PSNR: 7.24 MAXDIFF:60652 bytes: 7603200/ 2990 Test ffv1-s1024-gbrp16 failed. Look at tests/data/fate/ffv1-s1024-gbrp16.err for details. make: *** [src/tests/Makefile:316: fate-ffv1-s1024-gbrp16] Error 1 [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB If you drop bombs on a foreign country and kill a hundred thousand innocent people, expect your government to call the consequence "unprovoked inhuman terrorist attacks" and use it to justify dropping more bombs and killing more people. The technology changed, the idea is old. signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH v3] libavutil: Add AVMap
On Fri, Apr 18, 2025 at 10:46:42AM -0400, Leo Izen wrote: > On 4/17/25 16:12, Michael Niedermayer wrote: > > > > > > > + * @param keyvalue_cmp compare function, will be passed the key + > > > > value concatenated. > > > > > > Please no. Pass the key and the value separately to the compare > > > function. > > > > thats neither efficient nor does it fit the existing APIs. > > The value is most of the time not used and when used it is known exactly > > where it is. after a string compare of the key thats equal the value > > location is known > > or with arbitrary binary data the compare function knows the size of the > > data. > > Passing redudant pointers just wastes cpu cycles > > also existing APIs from av_tree strcmp() av_strcasecmp() and so on none of > > which take 4 pointers from which they would ignore 2. > > > The problem is that passing the key and value pairs combined requires you to > concatenate them. Since AVMapEntry has two separate pointers *key and > *value, it doesn't make sense to concatenate them before comparison > rather than just pass the pointers as-is. AVMapEntry.key and value are always concatenate already thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Nations do behave wisely once they have exhausted all other alternatives. -- Abba Eban signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] avcodec/libvvenc: use av_vlog to print external library log messages
LGTM,
Nit: Would a lookup table be better?
On Fri, Apr 18, 2025 at 12:42 AM James Almer wrote:
> And improve the vvencMsgLevel <-> AV_LOG_* mapping.
>
> Signed-off-by: James Almer
> ---
> libavcodec/libvvenc.c | 35 +++
> 1 file changed, 27 insertions(+), 8 deletions(-)
>
> diff --git a/libavcodec/libvvenc.c b/libavcodec/libvvenc.c
> index 29a49ba091..c71fd78f1e 100644
> --- a/libavcodec/libvvenc.c
> +++ b/libavcodec/libvvenc.c
> @@ -63,14 +63,29 @@ typedef struct VVenCContext {
> static void vvenc_log_callback(void *ctx, int level,
> const char *fmt, va_list args)
> {
> -vvenc_config params;
> -vvencEncoder *encoder = ctx;
> -if (encoder) {
> -vvenc_config_default(¶ms);
> -vvenc_get_config(encoder, ¶ms);
> -if ((int)params.m_verbosity >= level)
> -vfprintf(level == 1 ? stderr : stdout, fmt, args);
> +AVCodecContext *avctx = ctx;
> +
> +switch (level) {
> +case VVENC_ERROR:
> +level = AV_LOG_ERROR;
> +break;
> +case VVENC_WARNING:
> +level = AV_LOG_WARNING;
> +break;
> +case VVENC_INFO:
> +level = AV_LOG_INFO;
> +break;
> +case VVENC_NOTICE:
> +case VVENC_VERBOSE:
> +level = AV_LOG_VERBOSE;
> +break;
> +case VVENC_DETAILS:
> +level = AV_LOG_DEBUG;
> +break;
> +default:
> +return;
> }
> +av_vlog(avctx, level, fmt, args);
> }
>
> static void vvenc_set_verbository(vvenc_config *params)
> @@ -82,7 +97,11 @@ static void vvenc_set_verbository(vvenc_config *params)
> else if (loglevel >= AV_LOG_VERBOSE)
> params->m_verbosity = VVENC_NOTICE;
> else if (loglevel >= AV_LOG_INFO)
> +params->m_verbosity = VVENC_INFO;
> +else if (loglevel >= AV_LOG_WARNING)
> params->m_verbosity = VVENC_WARNING;
> +else if (loglevel >= AV_LOG_ERROR)
> +params->m_verbosity = VVENC_ERROR;
> }
>
> static void vvenc_set_pic_format(AVCodecContext *avctx, vvenc_config
> *params)
> @@ -300,7 +319,7 @@ static av_cold int vvenc_init(AVCodecContext *avctx)
> return AVERROR(ENOMEM);
> }
>
> -vvenc_set_msg_callback(¶ms, s->encoder, vvenc_log_callback);
> +vvenc_set_msg_callback(¶ms, avctx, vvenc_log_callback);
> ret = vvenc_encoder_open(s->encoder, ¶ms);
> if (ret != 0) {
> av_log(avctx, AV_LOG_ERROR, "cannot open libvvenc encoder: %s\n",
> --
> 2.49.0
>
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
> To unsubscribe, visit link above, or email
> ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
>
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH v2] fate: add various FFv1 tests for 1024 slices
On 19/04/2025 03:01, Michael Niedermayer wrote: On Wed, Apr 16, 2025 at 04:09:13PM +0200, Lynne wrote: This lets us test features that were broken earlier, as well as test the hardware decoder by using the HWACCEL=vulkan option. --- tests/Makefile| 1 + tests/fate/ffv1.mak | 46 +++ tests/ref/fate/ffv1-s1024-bgra| 4 +++ tests/ref/fate/ffv1-s1024-bgra-r | 4 +++ tests/ref/fate/ffv1-s1024-gbrp16 | 4 +++ tests/ref/fate/ffv1-s1024-gray8 | 4 +++ tests/ref/fate/ffv1-s1024-gray8-r | 4 +++ tests/ref/fate/ffv1-s1024-yuv444p | 4 +++ 8 files changed, 71 insertions(+) create mode 100644 tests/fate/ffv1.mak create mode 100644 tests/ref/fate/ffv1-s1024-bgra create mode 100644 tests/ref/fate/ffv1-s1024-bgra-r create mode 100644 tests/ref/fate/ffv1-s1024-gbrp16 create mode 100644 tests/ref/fate/ffv1-s1024-gray8 create mode 100644 tests/ref/fate/ffv1-s1024-gray8-r create mode 100644 tests/ref/fate/ffv1-s1024-yuv444p Fails on qemu mips grep -B5 Err fatelist -a0ead8e9e709b6e93dca3e972a00c3d3 *tests/data/fate/ffv1-s1024-bgra-r.out.framecrc -stddev:28285.12 PSNR: 7.30 MAXDIFF:60652 bytes: 7603200/ 2990 +0a1d65aa7861338163ea947628df10d1 *tests/data/fate/ffv1-s1024-bgra-r.out.framecrc +stddev:28282.37 PSNR: 7.30 MAXDIFF:60652 bytes: 7603200/ 2990 Test ffv1-s1024-bgra-r failed. Look at tests/data/fate/ffv1-s1024-bgra-r.err for details. make: *** [src/tests/Makefile:315: fate-ffv1-s1024-bgra-r] Error 1 -- -a0ead8e9e709b6e93dca3e972a00c3d3 *tests/data/fate/ffv1-s1024-bgra.out.framecrc -stddev:28285.12 PSNR: 7.30 MAXDIFF:60652 bytes: 7603200/ 2990 +0a1d65aa7861338163ea947628df10d1 *tests/data/fate/ffv1-s1024-bgra.out.framecrc +stddev:28282.37 PSNR: 7.30 MAXDIFF:60652 bytes: 7603200/ 2990 Test ffv1-s1024-bgra failed. Look at tests/data/fate/ffv1-s1024-bgra.err for details. make: *** [src/tests/Makefile:316: fate-ffv1-s1024-bgra] Error 1 -- -c191aec6b3d999278963ebdd6a326ec3 *tests/data/fate/ffv1-s1024-gbrp16.out.framecrc -stddev:28358.70 PSNR: 7.28 MAXDIFF:60652 bytes: 7603200/ 2990 +10856377a7a7fe64c30fd20893f86d6e *tests/data/fate/ffv1-s1024-gbrp16.out.framecrc +stddev:28468.66 PSNR: 7.24 MAXDIFF:60652 bytes: 7603200/ 2990 Test ffv1-s1024-gbrp16 failed. Look at tests/data/fate/ffv1-s1024-gbrp16.err for details. make: *** [src/tests/Makefile:316: fate-ffv1-s1024-gbrp16] Error 1 Big endian? OpenPGP_0xA2FEA5F03F034464.asc Description: OpenPGP public key OpenPGP_signature.asc Description: OpenPGP digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH v2] fate: add various FFv1 tests for 1024 slices
On Sat, Apr 19, 2025 at 03:38:22AM +0200, Lynne wrote: > On 19/04/2025 03:01, Michael Niedermayer wrote: > > On Wed, Apr 16, 2025 at 04:09:13PM +0200, Lynne wrote: > > > This lets us test features that were broken earlier, as well as > > > test the hardware decoder by using the HWACCEL=vulkan option. > > > --- > > > tests/Makefile| 1 + > > > tests/fate/ffv1.mak | 46 +++ > > > tests/ref/fate/ffv1-s1024-bgra| 4 +++ > > > tests/ref/fate/ffv1-s1024-bgra-r | 4 +++ > > > tests/ref/fate/ffv1-s1024-gbrp16 | 4 +++ > > > tests/ref/fate/ffv1-s1024-gray8 | 4 +++ > > > tests/ref/fate/ffv1-s1024-gray8-r | 4 +++ > > > tests/ref/fate/ffv1-s1024-yuv444p | 4 +++ > > > 8 files changed, 71 insertions(+) > > > create mode 100644 tests/fate/ffv1.mak > > > create mode 100644 tests/ref/fate/ffv1-s1024-bgra > > > create mode 100644 tests/ref/fate/ffv1-s1024-bgra-r > > > create mode 100644 tests/ref/fate/ffv1-s1024-gbrp16 > > > create mode 100644 tests/ref/fate/ffv1-s1024-gray8 > > > create mode 100644 tests/ref/fate/ffv1-s1024-gray8-r > > > create mode 100644 tests/ref/fate/ffv1-s1024-yuv444p > > > > Fails on qemu mips > > grep -B5 Err fatelist > > -a0ead8e9e709b6e93dca3e972a00c3d3 > > *tests/data/fate/ffv1-s1024-bgra-r.out.framecrc > > -stddev:28285.12 PSNR: 7.30 MAXDIFF:60652 bytes: 7603200/ 2990 > > +0a1d65aa7861338163ea947628df10d1 > > *tests/data/fate/ffv1-s1024-bgra-r.out.framecrc > > +stddev:28282.37 PSNR: 7.30 MAXDIFF:60652 bytes: 7603200/ 2990 > > Test ffv1-s1024-bgra-r failed. Look at > > tests/data/fate/ffv1-s1024-bgra-r.err for details. > > make: *** [src/tests/Makefile:315: fate-ffv1-s1024-bgra-r] Error 1 > > -- > > -a0ead8e9e709b6e93dca3e972a00c3d3 > > *tests/data/fate/ffv1-s1024-bgra.out.framecrc > > -stddev:28285.12 PSNR: 7.30 MAXDIFF:60652 bytes: 7603200/ 2990 > > +0a1d65aa7861338163ea947628df10d1 > > *tests/data/fate/ffv1-s1024-bgra.out.framecrc > > +stddev:28282.37 PSNR: 7.30 MAXDIFF:60652 bytes: 7603200/ 2990 > > Test ffv1-s1024-bgra failed. Look at tests/data/fate/ffv1-s1024-bgra.err > > for details. > > make: *** [src/tests/Makefile:316: fate-ffv1-s1024-bgra] Error 1 > > -- > > -c191aec6b3d999278963ebdd6a326ec3 > > *tests/data/fate/ffv1-s1024-gbrp16.out.framecrc > > -stddev:28358.70 PSNR: 7.28 MAXDIFF:60652 bytes: 7603200/ 2990 > > +10856377a7a7fe64c30fd20893f86d6e > > *tests/data/fate/ffv1-s1024-gbrp16.out.framecrc > > +stddev:28468.66 PSNR: 7.24 MAXDIFF:60652 bytes: 7603200/ 2990 > > Test ffv1-s1024-gbrp16 failed. Look at > > tests/data/fate/ffv1-s1024-gbrp16.err for details. > > make: *** [src/tests/Makefile:316: fate-ffv1-s1024-gbrp16] Error 1 > > Big endian? yes [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB I do not agree with what you have to say, but I'll defend to the death your right to say it. -- Voltaire signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 2/3] doc/dict2: Add doc and api change for AVDictionary2
Hi On Thu, Apr 17, 2025 at 10:38:32PM +, softworkz . wrote: > > > > -Original Message- > > From: ffmpeg-devel On Behalf Of [...] > > the LLM would probably mix and confuse things and hallucinate > > a lot of nonsense. > > That's less of a problem meanwhile as the available context > windows have increased and operating on trac ticket discussions > does not create such long conversations where the context > window overflows and important parts fall off. > Some care might only need to be taken for that it doesn't ingest > really large log outputs as are sometimes included in the tickets. > > At this time, it would be still too bold to let it work fully > autonomously, but that's not necessary because its > operations could be easily arbitrated by conventional logic. > > It could be controlled by a set of tags - something like: > > - tracbot-error > - tracbot-inconclusive > - tracbot-needs-manual-review > - tracbot-awaiting-user-response > - tracbot-reproduced-in-master > - tracbot-fixed-in-master > > Then, a scheduler service would run over all open issues and > invoke the AI on it (see below). > > The scheduler would exclude tickets which already have one of > those tags assigned. > Additionally, it would include tickets that are tagged with > "tracbot-awaiting-user-response" and have been updated since > the tag was assigned. > > > When the AI is invoked on a ticked, it has clear instructions > to follow. The primary directive is to reproduce the reported > issue. If the specified information is unclear or incomplete > or when no test file is provided, it posts a message, asking > for the missing information and applies the awaiting-user-response > tag. > > The AI would have an execution environment in a Docker > container where it has access to a library with daily builds > from the past 5 years. > If the issue doesn't reproduce with the latest daily build, > it adds the tracbot-fixed-in-master tag. > > If it can be reproduced with the latest build, it "bisects" > the issue using the daily binaries. > It adds a message like: "Issue reproducible since version > 20xx-xx-xx and the tag tracbot-reproduced-in-master > > If it can't make sense of it, or is platform-specific or > needs certain hardware, or errors, it adds one of the > other tags. > > Some safeguards must be added to avoid anybody getting > into a longer chat with it (always ending with > awaiting-user-response), but otherwise, I don't think > that there's much that can go wrong. > > A mailing list could be set up, to which it reports it > operations, and where interested members (or anybody) > can subscribe to. This would provide a kind of real-time > monitoring by the community. > > > All-in-all I think it's well doable. > > Unfortunately though, I cannot spend that much time. > Perhaps a candidate for GSoC? GsoC would need a mentor and a student/contributor wanting to work on this. Also this would need someone (ideally either the mentor or contributor) willing to maintain it after GSoC And it would not surprise me if its more work for us to do this in GSoC than just do it ourselfs. thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB The real ebay dictionary, page 1 "Used only once"- "Some unspecified defect prevented a second use" "In good condition" - "Can be repaird by experienced expert" "As is" - "You wouldnt want it even if you were payed for it, if you knew ..." signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] libavcodec/riscv:add RVV optimized for idct_32x32_8:
On Tue, Apr 15, 2025 at 03:34:24PM +0800, daichengr...@iscas.ac.cn wrote: > From: daichengrong > > riscv/hevcdsp_idct_rvv: Optimize idct_32x32_8 > > On Banana PI F3: > > hevc_idct_32x32_8_c:119579.3 ( 1.00x) > hevc_idct_32x32_8_rvv_i64: 51254.4 ( 2.33x) > > Signed-off-by: daichengrong > --- > libavcodec/riscv/Makefile |1 + > libavcodec/riscv/hevcdsp_idct_rvv.S | 1042 +++ > libavcodec/riscv/hevcdsp_init.c | 52 +- > 3 files changed, 1075 insertions(+), 20 deletions(-) > create mode 100644 libavcodec/riscv/hevcdsp_idct_rvv.S there are 358 tabs in this, please use spaces both for consistency with the rest of the .S files and also because the git push hook will block this thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Republics decline into democracies and democracies degenerate into despotisms. -- Aristotle signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 1/3] avcodec/tests/mjpegenc_huffman: Also test length counts
Andreas Rheinhardt: > Patches attached. > I also tried to sort equal length codes in such a way that codes that > start and end with 1 bits are paired with values that occur less > frequently as suggested by Michael in > https://ffmpeg.org/pipermail/ffmpeg-devel/2025-April/341917.html. Yet > strangely this worsened compression (for the majority of the fate tests > affected by it). The patch can be found here: > https://github.com/mkver/FFmpeg/commits/mjpegenc_huffman/ > Will apply this patchset (without the extra patch on github) tomorrow unless there are objections. - Andreas ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH v3 09/11] fftools/ffmpeg_mux: Make ms_from_ost() inline
From: softworkz
Signed-off-by: softworkz
---
fftools/ffmpeg_mux.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/fftools/ffmpeg_mux.h b/fftools/ffmpeg_mux.h
index f41f2c18fa..4ca8ab73a4 100644
--- a/fftools/ffmpeg_mux.h
+++ b/fftools/ffmpeg_mux.h
@@ -123,7 +123,7 @@ typedef struct Muxer {
int mux_check_init(void *arg);
-static MuxStream *ms_from_ost(OutputStream *ost)
+static inline MuxStream *ms_from_ost(OutputStream *ost)
{
return (MuxStream*)ost;
}
--
ffmpeg-codebot
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 2/3] doc/dict2: Add doc and api change for AVDictionary2
Hi On Wed, Apr 16, 2025 at 11:15:12PM +, softworkz . wrote: > > > > -Original Message- > > From: ffmpeg-devel On Behalf Of > > Michael Niedermayer > > Sent: Mittwoch, 16. April 2025 23:48 > > To: FFmpeg development discussions and patches > de...@ffmpeg.org> > > Subject: Re: [FFmpeg-devel] [PATCH 2/3] doc/dict2: Add doc and api > > change for AVDictionary2 > > > > Hi softworkz > > > > I think we should use AI to support us and reduce the workload > > on people. > > I think this here cost you money > > This is part of an ongoing research for a project that is totally > unrelated to FFmpeg. It wasn't my own money and it wasn't spent > in order to create an AvDictionary2 for FFmpeg. > > Also, I didn't know that you are working on it, you had written > that you won't have time. That's why I thought it's a good subject, Yeah, I say i have no time and then spend time on it anyway ;) maybe thats one of several reasons why i dont have time But AVMap surely is/was an interresting project There are just too many interresting things to work on I need more time, the days are too short, life is too short and i need an assitent, also we (FFMpeg) needs someone to manage the bug tracker better. In the past carl did that (ask people questions when reports where incomplete or unreproduceable bisect regressions contact people causing regressions stuff like that) and i think we should fund carl to do it again. But until we find someone funding carl, maybe you can get some AI to do a subset of these tasks ? also maybe we could train a LLM on the bugtracker data, so that we then could just ask it questions about it. But then i feel the LLM would probably mix and confuse things and hallucinate a lot of nonsense > being a real-world task and somebody who will be interested in > something to play with, even though it's just at a prototype level. > > I had thought: Michael wants something, but has no time to work on > it - hmm, he will surely be positively surprised to get some code > in that direction. > > > So I hope all things are cleared up now. I had no bad intentions in > any direction, just the opposite. sure, thanks :) [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB I have never wished to cater to the crowd; for what I know they do not approve, and what they approve I do not know. -- Epicurus signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
