[FFmpeg-devel] [PATCH] doc/examples: Add qsv_transcode example
From: Wenbin Chen
Add qsv_transcode example which shows how to use qsv to do hardware
accelerated transcoding, also show how to dynamically set encoding
parameters.
examples:
Normal usage:
qsv_transcode input.mp4 h264_qsv output.mp4 "g 60"
Dynamic setting usage:
qsv_transcode input.mp4 hevc_qsv output.mp4 "g 60 asyne_depth 1"
100 "g 120"
This command initializes codec with gop_size 60 and change it to
120 after 100 frames
Signed-off-by: Wenbin Chen
---
configure| 2 +
doc/examples/.gitignore | 1 +
doc/examples/Makefile| 1 +
doc/examples/qsv_transcode.c | 440 +++
4 files changed, 444 insertions(+)
create mode 100644 doc/examples/qsv_transcode.c
diff --git a/configure b/configure
index 70c9e41dcc..a8b4496465 100755
--- a/configure
+++ b/configure
@@ -1748,6 +1748,7 @@ EXAMPLE_LIST="
transcoding_example
vaapi_encode_example
vaapi_transcode_example
+qsv_transcode_example
"
EXTERNAL_AUTODETECT_LIBRARY_LIST="
@@ -3811,6 +3812,7 @@ transcode_aac_example_deps="avcodec avformat swresample"
transcoding_example_deps="avfilter avcodec avformat avutil"
vaapi_encode_example_deps="avcodec avutil h264_vaapi_encoder"
vaapi_transcode_example_deps="avcodec avformat avutil h264_vaapi_encoder"
+qsv_transcode_example_deps="avcodec avformat avutil h264_qsv_encoder"
# EXTRALIBS_LIST
cpu_init_extralibs="pthreads_extralibs"
diff --git a/doc/examples/.gitignore b/doc/examples/.gitignore
index 44960e1de7..d787afdd4c 100644
--- a/doc/examples/.gitignore
+++ b/doc/examples/.gitignore
@@ -22,3 +22,4 @@
/transcoding
/vaapi_encode
/vaapi_transcode
+/qsv_transcode
diff --git a/doc/examples/Makefile b/doc/examples/Makefile
index 81bfd34d5d..f937fbefda 100644
--- a/doc/examples/Makefile
+++ b/doc/examples/Makefile
@@ -21,6 +21,7 @@ EXAMPLES-$(CONFIG_TRANSCODE_AAC_EXAMPLE) += transcode_aac
EXAMPLES-$(CONFIG_TRANSCODING_EXAMPLE) += transcoding
EXAMPLES-$(CONFIG_VAAPI_ENCODE_EXAMPLE) += vaapi_encode
EXAMPLES-$(CONFIG_VAAPI_TRANSCODE_EXAMPLE) += vaapi_transcode
+EXAMPLES-$(CONFIG_QSV_TRANSCODE_EXAMPLE) += qsv_transcode
EXAMPLES := $(EXAMPLES-yes:%=doc/examples/%$(PROGSSUF)$(EXESUF))
EXAMPLES_G := $(EXAMPLES-yes:%=doc/examples/%$(PROGSSUF)_g$(EXESUF))
diff --git a/doc/examples/qsv_transcode.c b/doc/examples/qsv_transcode.c
new file mode 100644
index 00..9b37bbea9f
--- /dev/null
+++ b/doc/examples/qsv_transcode.c
@@ -0,0 +1,440 @@
+/*
+ * Quick Sync Video (video transcoding) transcode sample
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a copy
+ * of this software and associated documentation files (the "Software"), to
deal
+ * in the Software without restriction, including without limitation the rights
+ * to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
+ * copies of the Software, and to permit persons to whom the Software is
+ * furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice shall be included in
+ * all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
+ * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
FROM,
+ * OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN
+ * THE SOFTWARE.
+ */
+
+/**
+ * @file
+ * Intel QSV-accelerated transcoding example.
+ *
+ * @example qsv_transcode.c
+ * This example shows how to do QSV-accelerated transcoding and how to
+ * dynamically change encoder's option.
+ * Usage: qsv_transcode input_stream codec output_stream initial option
+ * { frame_number new_option }
+ * e.g: - qsv_transcode input.mp4 h264_qsv output_h264.mp4 "g 60"
+ * - qsv_transcode input.mp4 hevc_qsv output_hevc.mp4 "g 60 async_depth 1"
+ * 100 "g 120"
+ * (initialize codec with gop_size 60 and change it to 120 after 100
+ * frames)
+ */
+
+#include
+#include
+
+#include
+#include
+#include
+#include
+
+static AVFormatContext *ifmt_ctx = NULL, *ofmt_ctx = NULL;
+static AVBufferRef *hw_device_ctx = NULL;
+static AVCodecContext *decoder_ctx = NULL, *encoder_ctx = NULL;
+static int video_stream = -1;
+
+typedef struct DynamicSetting {
+int frame_number;
+char* optstr;
+} DynamicSetting;
+static DynamicSetting *dynamic_setting;
+static int setting_number;
+static int current_setting_number;
+
+static int str_to_dict(char* optstr, AVDictionary **opt)
+{
+char *key, *value;
+if (strlen(optstr) == 0)
+return 0;
+key = strtok(optstr, " ");
+if (key == NULL)
+return AVERROR(ENAVAIL);
+value = strtok(NUL
[FFmpeg-devel] [PATCH v6] libavfilter/x86/vf_convolution: add sobel filter optimization and unit test with intel AVX512 VNNI
From: bwang30
This commit enabled assembly code with intel AVX512 VNNI and added unit test
for sobel filter
sobel_c: 4537
sobel_avx512icl 2136
Signed-off-by: bwang30
---
libavfilter/convolution.h | 74 +
libavfilter/vf_convolution.c | 91 +++-
libavfilter/x86/vf_convolution.asm| 147 ++
libavfilter/x86/vf_convolution_init.c | 18
tests/checkasm/Makefile | 1 +
tests/checkasm/checkasm.c | 3 +
tests/checkasm/checkasm.h | 1 +
tests/checkasm/vf_convolution.c | 103 ++
8 files changed, 360 insertions(+), 78 deletions(-)
create mode 100644 tests/checkasm/vf_convolution.c
diff --git a/libavfilter/convolution.h b/libavfilter/convolution.h
index 88aabe9a20..e44bfb5da8 100644
--- a/libavfilter/convolution.h
+++ b/libavfilter/convolution.h
@@ -21,6 +21,7 @@
#ifndef AVFILTER_CONVOLUTION_H
#define AVFILTER_CONVOLUTION_H
#include "avfilter.h"
+#include "libavutil/intreadwrite.h"
enum MatrixMode {
MATRIX_SQUARE,
@@ -61,4 +62,77 @@ typedef struct ConvolutionContext {
} ConvolutionContext;
void ff_convolution_init_x86(ConvolutionContext *s);
+void ff_sobel_init_x86(ConvolutionContext *s, int depth, int nb_planes);
+
+static void setup_3x3(int radius, const uint8_t *c[], const uint8_t *src, int
stride,
+ int x, int w, int y, int h, int bpc)
+{
+int i;
+
+for (i = 0; i < 9; i++) {
+int xoff = FFABS(x + ((i % 3) - 1));
+int yoff = FFABS(y + (i / 3) - 1);
+
+xoff = xoff >= w ? 2 * w - 1 - xoff : xoff;
+yoff = yoff >= h ? 2 * h - 1 - yoff : yoff;
+
+c[i] = src + xoff * bpc + yoff * stride;
+}
+}
+
+static void filter_sobel(uint8_t *dst, int width,
+ float scale, float delta, const int *const matrix,
+ const uint8_t *c[], int peak, int radius,
+ int dstride, int stride, int size)
+{
+const uint8_t *c0 = c[0], *c1 = c[1], *c2 = c[2];
+const uint8_t *c3 = c[3], *c5 = c[5];
+const uint8_t *c6 = c[6], *c7 = c[7], *c8 = c[8];
+int x;
+
+for (x = 0; x < width; x++) {
+float suma = c0[x] * -1 + c1[x] * -2 + c2[x] * -1 +
+ c6[x] * 1 + c7[x] * 2 + c8[x] * 1;
+float sumb = c0[x] * -1 + c2[x] * 1 + c3[x] * -2 +
+ c5[x] * 2 + c6[x] * -1 + c8[x] * 1;
+
+dst[x] = av_clip_uint8(sqrtf(suma*suma + sumb*sumb) * scale + delta);
+}
+}
+
+static void filter16_sobel(uint8_t *dstp, int width,
+ float scale, float delta, const int *const matrix,
+ const uint8_t *c[], int peak, int radius,
+ int dstride, int stride, int size)
+{
+uint16_t *dst = (uint16_t *)dstp;
+int x;
+
+for (x = 0; x < width; x++) {
+float suma = AV_RN16A(&c[0][2 * x]) * -1 + AV_RN16A(&c[1][2 * x]) * -2
+ AV_RN16A(&c[2][2 * x]) * -1 +
+ AV_RN16A(&c[6][2 * x]) * 1 + AV_RN16A(&c[7][2 * x]) * 2
+ AV_RN16A(&c[8][2 * x]) * 1;
+float sumb = AV_RN16A(&c[0][2 * x]) * -1 + AV_RN16A(&c[2][2 * x]) * 1
+ AV_RN16A(&c[3][2 * x]) * -2 +
+ AV_RN16A(&c[5][2 * x]) * 2 + AV_RN16A(&c[6][2 * x]) * -1
+ AV_RN16A(&c[8][2 * x]) * 1;
+
+dst[x] = av_clip(sqrtf(suma*suma + sumb*sumb) * scale + delta, 0,
peak);
+}
+}
+
+static av_unused void ff_sobel_init(ConvolutionContext *s, int depth, int
nb_planes)
+{
+for (int i = 0; i < 4; i++) {
+s->filter[i] = filter_sobel;
+s->copy[i] = !((1 << i) & s->planes);
+s->size[i] = 3;
+s->setup[i] = setup_3x3;
+s->rdiv[i] = s->scale;
+s->bias[i] = s->delta;
+}
+if (s->depth > 8)
+for (int i = 0; i < 4; i++)
+s->filter[i] = filter16_sobel;
+#if ARCH_X86_64
+ff_sobel_init_x86(s, depth, nb_planes);
+#endif
+}
#endif
diff --git a/libavfilter/vf_convolution.c b/libavfilter/vf_convolution.c
index 9a9c099e6d..7762fa2a05 100644
--- a/libavfilter/vf_convolution.c
+++ b/libavfilter/vf_convolution.c
@@ -139,24 +139,6 @@ static void filter16_roberts(uint8_t *dstp, int width,
}
}
-static void filter16_sobel(uint8_t *dstp, int width,
- float scale, float delta, const int *const matrix,
- const uint8_t *c[], int peak, int radius,
- int dstride, int stride, int size)
-{
-uint16_t *dst = (uint16_t *)dstp;
-int x;
-
-for (x = 0; x < width; x++) {
-float suma = AV_RN16A(&c[0][2 * x]) * -1 + AV_RN16A(&c[1][2 * x]) * -2
+ AV_RN16A(&c[2][2 * x]) * -1 +
- AV_RN16A(&c[6][2 * x]) * 1 + AV_RN16A(&c[7][2 * x]) * 2
+ AV_RN16A(&c[8][2 * x]) * 1;
-float sumb = AV_RN16A(&c[0][2 * x]) * -1 + AV_RN16A(&c[2][2 * x]) * 1
+ AV_RN16A(&c[3][2 * x]) * -2 +
- AV_RN16A(&c[5][2 * x]) * 2 + AV_RN16A(&c
Re: [FFmpeg-devel] [PATCH v2 0/4] swscale rgbaf32 input/output support
Hi, On Mon, Oct 31, 2022 at 1:33 AM wrote: > > From: Mark Reid > > This patch series adds swscale input/output support for the packed rgb float > formats. > A few of the filters also needed support the larger 96/128 bit packed pixel > sizes. > > I also plan to eventually add lossless unscaled conversions between the > planer and packed formats. > > changes since v1 > * output correct alpha is src doesn't have alpha I do not have the knowledge to review this patchset, but let me say i am very happy to see it! Thanks for the work. All the best, Dee ___ 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 03/10] avcodec: add bitstream parser for H266/VVC
On Mon, 24 Oct 2022 at 16:38, James Almer wrote:
> On 10/24/2022 11:06 AM, Thomas Siedel wrote:
> > +static int combine_au(AVCodecParserContext *ctx, AVCodecContext *avctx,
> > + const uint8_t **buf, int *buf_size)
> > +{
>
> This is being called only when you first assembled AUs from what's
> assumed to be raw input. When PARSER_FLAG_COMPLETE_FRAMES is set, it
> should also parse the AU for bitstream information.
>
Yes, currently, "combine_au" is only called when
PARSER_FLAG_COMPLETE_FRAMES is disabled, but I do not really understand
what the issue is here.
As far as I know, all bitstream information is parsed properly for any kind
of supported content (currently, ES, MP4, and TS are supported).
Would you happen to have an example of a use case where
PARSER_FLAG_COMPLETE_FRAMES is enabled, and the bitstream information is
needed or not parsed correctly from the current implementation?
The current behavior is pretty similar to other codec
parser implementations like hevc, avc, and av1. Why should the vvc parser
code differ from the (default) behavior of other codecs?
> > +VVCParserContext *s = ctx->priv_data;
> > +CodedBitstreamFragment *pu = &s->picture_unit;
> > +int ret;
> > +
> > +s->cbc->log_ctx = avctx;
> > +
> > +if (avctx->extradata_size && !s->parsed_extradata) {
> > +s->parsed_extradata = 1;
> > +
> > +if ((ret = ff_cbs_read(s->cbc, pu, avctx->extradata,
> avctx->extradata_size)) < 0)
>
> ff_cbs_read_extradata_from_codec()
>
> > +av_log(avctx, AV_LOG_WARNING, "Failed to parse
> extradata.\n");
> > +
> > +ff_cbs_fragment_reset(pu);
> > +}
> > +av_packet_unref(&s->last_au);
> > +ret = parse_nal_units(ctx, *buf, *buf_size, avctx);
> > +if (ret == 0) {
> > +if (s->last_au.size) {
> > +*buf = s->last_au.data;
> > +*buf_size = s->last_au.size;
> > +} else {
> > +//no output
> > +ret = 1;
> > +}
> > +}
> > +s->cbc->log_ctx = NULL;
> > +return ret;
> > +}
> > +
> > +static int vvc_parser_parse(AVCodecParserContext *ctx, AVCodecContext
> *avctx,
> > + const uint8_t **poutbuf, int *poutbuf_size,
> > + const uint8_t *buf, int buf_size)
> > +{
> > +int next;
> > +VVCParserContext *s = ctx->priv_data;
> > +ParseContext *pc = &s->pc;
> > +
> > +if (avctx->extradata && !s->parsed_extradata) {
> > +av_log(avctx, AV_LOG_INFO, "extra data is not supported
> yet.\n");
> > +return AVERROR_PATCHWELCOME;
> > +}
> > +
> > +if (ctx->flags & PARSER_FLAG_COMPLETE_FRAMES) {
> > +next = buf_size;
> > +} else {
> > +int ret, flush = !buf_size;
> > +next = find_frame_end(ctx, buf, buf_size);
> > +if (ff_combine_frame(pc, next, &buf, &buf_size) < 0)
> > +goto no_out;
> > +ret = combine_au(ctx, avctx, &buf, &buf_size);
> > +if (ret > 0 && flush) {
> > +buf_size = 0;
> > +ret = combine_au(ctx, avctx, &buf, &buf_size);
> > +}
> > +if (ret != 0) {
> > +buf_size = next;
> > +goto no_out;
> > +}
> > +}
> > +*poutbuf = buf;
> > +*poutbuf_size = buf_size;
> > +return next;
> > +no_out:
> > +*poutbuf = NULL;
> > +*poutbuf_size = 0;
> > +return buf_size;
> > +}
> ___
> 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 0/1] Add "no packet timeout" to mpegts
This fixes mpegts infinitely parsing streams that contain only stuffed PATs, which apparently happens on some dead livetv sources. Wolfgang Haupt (1): Add "no packet" timeout option for mpegts libavformat/mpegts.c | 18 ++ 1 file changed, 18 insertions(+) -- 2.25.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 1/1] Add "no packet" timeout option for mpegts
Retrieving an mpegts stream with only stuffed PAT,
results in endless reading.
This change adds a new timeout that specifies a
timespan in AV_TIME_BASE units until when a full
packet must be read successfully.
Signed-off-by: Wolfgang Haupt
---
libavformat/mpegts.c | 18 ++
1 file changed, 18 insertions(+)
diff --git a/libavformat/mpegts.c b/libavformat/mpegts.c
index d97702fcd7..5b615cca63 100644
--- a/libavformat/mpegts.c
+++ b/libavformat/mpegts.c
@@ -32,6 +32,7 @@
#include "libavutil/opt.h"
#include "libavutil/avassert.h"
#include "libavutil/dovi_meta.h"
+#include "libavutil/time.h"
#include "libavcodec/avcodec.h"
#include "libavcodec/bytestream.h"
#include "libavcodec/get_bits.h"
@@ -180,6 +181,12 @@ struct MpegTSContext {
AVStream *epg_stream;
AVBufferPool* pools[32];
+
+/**
+ * Timeout in AV_TIME_BASE units, until at least one packet is read
+ * from the stream.
+ */
+int64_t packet_read_timeout;
};
#define MPEGTS_OPTIONS \
@@ -203,6 +210,8 @@ static const AVOption options[] = {
{.i64 = 0}, 0, 1, 0 },
{"max_packet_size", "maximum size of emitted packet",
offsetof(MpegTSContext, max_packet_size), AV_OPT_TYPE_INT,
{.i64 = 204800}, 1, INT_MAX/2, AV_OPT_FLAG_DECODING_PARAM },
+{"packet_read_timeout", "Maximum time utnil at least one packet is
successfully read from the stream", offsetof(MpegTSContext,
packet_read_timeout), AV_OPT_TYPE_INT64,
+ {.i64 = 0 }, 0, INT64_MAX, AV_OPT_FLAG_DECODING_PARAM },
{ NULL },
};
@@ -2972,6 +2981,8 @@ static int handle_packets(MpegTSContext *ts, int64_t
nb_packets)
const uint8_t *data;
int64_t packet_num;
int ret = 0;
+time_t start = 0;
+time_t now = 0;
if (avio_tell(s->pb) != ts->last_pos) {
int i;
@@ -2996,8 +3007,15 @@ static int handle_packets(MpegTSContext *ts, int64_t
nb_packets)
ts->stop_parse = 0;
packet_num = 0;
memset(packet + TS_PACKET_SIZE, 0, AV_INPUT_BUFFER_PADDING_SIZE);
+start = av_gettime_relative();
for (;;) {
packet_num++;
+now = av_gettime_relative();
+if (now - start > ts->packet_read_timeout) {
+av_log(ts->stream, AV_LOG_TRACE, "No packet after %"PRId64"ms\n",
ts->packet_read_timeout/1000);
+break;
+}
+
if (nb_packets != 0 && packet_num >= nb_packets ||
ts->stop_parse > 1) {
ret = AVERROR(EAGAIN);
--
2.25.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] Revert "avfilter/vf_palette(gen|use): support palettes with alpha"
On Mon, Oct 31, 2022 at 01:43:11AM +, Soft Works wrote: [...] > > > > The patch I had submitted doesn't change the previous behavior > > > > without the use_alpha parameter. > > > > Yes I noticed, but unfortunately I'm reworking the color distance to > > work > > in perceptual color space, and the way that alpha is mixed up in the > > equation just doesn't make any sense at all and prevents me from > > doing > > these changes. > > If you want to implement a new color distance algorithm, it should > be either a new filter or a new (switchable) mode for the existing > filter. Why? > Photoshop has these different modes as well and it would > surely be useful, but I don't think it should be replacing the > existing behavior. > There is no point in keeping a ton of complexity exposed as user options for something implementation specific. We offer no guarantee over how the quantization is expected to run. > When it turns out that the use_alpha implementation doesn't fit > with your new color distance calculation and you add it as > an additional mode, then it would be fine IMO when the filter > errors in case it would be attempted to use that mode in > combination with use_alpha. IMO The use_alpha option shouldn't exist in the first place, it should be the default behaviour because honoring the alpha is the correct thing to do. That's not what the option is currently doing though. > > > Do you think it might make sense to put more weight on the > > > alpha value by tripling it? So it would be weighted equally to the > > > RGB value? > > > > You cannot mix alpha with colors at all, they are separate domains > > and you > > need to treat them as such. > > What's interesting is that I've followed the same (simplified) > way for adding a use_alpha option to vf_elbg and it provides excellent > results without treating alpha separately. I don't know how the filter works and what it's supposed to do, but if it's indeed using the same approach as the palette ones, it cannot work. > > From paletteuse perspective what you need to do is first choose the > > colors > > in the palette that match exactly the alpha (or at least the closest > > if > > and only there is no exact match). Then within that set, and only > > within > > that one, you'd pick the closest color. > > > > From palettegen perspective, you need to split the colors in > > different > > transparency domain (a first dimensional quantization), then quantize > > the > > colors in each quantized alpha dimension. And when you have all your > > quantized palettes for each level of alpha, you find an algorithm to > > reduce the number of transparency dimensions or the number of colors > > per > > dimension to make it fit inside a single palette. But you can't just > > do > > the alpha and the colors at the same time, it cannot work, whatever > > weights you choose. > > I would be curious to see how well that would work, especially > in cases when the target palettes have just a few number of colors. > You have to make a call between whether you want to preserve the transparency or the color while constructing the palette, but when choosing a color you must absolutely not choose a color with a different transparency, you must pick amongst the closest alpha, with a particular attention to extreme alphas: an opaque colors must stay opaque, and fully transparent one as well: - rounding a color with 43% alpha into 50% alpha is acceptable - rounding a color with 100% alpha into a 99% alpha is not acceptable in any way because you're starting to make transparent areas that weren't - rounding a color with 0% alpha into a 1% alpha is not acceptable because some areas of the images are not starting to blend into an area that was supposedly non-existent > But to return to the proposal of removal: If everything from ffmpeg > would be removed which is not perfect, then it would be lacking > quite a number of features I suppose :-) We're not talking about perfection, we're talking about files with artifacts. It's almost as bad as a corrupted file, because if used in a pipeline where transparency matters, you're going to get a completely broken output. > In the same way, one could say that palettegen/-use should be removed > because its results are wrong and colors are randomly mixed and > misplaced while the vf_elbg filter does it right. > When you look at the result under the heading > > "Paletteuse/gen Regular (to 8-bit non-alpha palette; only single > transparent color)" > https://gist.github.com/softworkz/deef5c2a43d3d629c3e17f9e21544a8f?permalink_comment_id=3905155#gistcomment-3905155 > > Even without the alpha, many color pixels appear to be wrong and > random like for example the light purple pixels on the darker purple > at the bottom of the "O". That's not much different from irregularities > in the alpha channel you've shown (https://imgur.com/a/50YyRGV). > So, I agree to that it's not perfect, but the whole filter is > not perfec
[FFmpeg-devel] [PATCH] avfilter/src_movie: support unknown channel layouts
Patch attached.
From 975a677906256f5f7a6da876a1eede21c5cb2a8e Mon Sep 17 00:00:00 2001
From: Paul B Mahol
Date: Mon, 31 Oct 2022 12:55:17 +0100
Subject: [PATCH] avfilter/src_movie: support unknown channel layouts
Signed-off-by: Paul B Mahol
---
libavfilter/src_movie.c | 8 ++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/libavfilter/src_movie.c b/libavfilter/src_movie.c
index 711854c23c..2e30e54ad2 100644
--- a/libavfilter/src_movie.c
+++ b/libavfilter/src_movie.c
@@ -196,11 +196,15 @@ static int guess_channel_layout(MovieStream *st, int st_index, void *log_ctx)
av_channel_layout_default(&chl, dec_par->ch_layout.nb_channels);
if (!KNOWN(&chl)) {
-av_log(log_ctx, AV_LOG_ERROR,
+char *cl_name;
+
+av_log(log_ctx, AV_LOG_WARNING,
"Channel layout is not set in stream %d, and could not "
"be guessed from the number of channels (%d)\n",
st_index, dec_par->ch_layout.nb_channels);
-return AVERROR(EINVAL);
+cl_name = av_asprintf("%dC", dec_par->ch_layout.nb_channels);
+av_channel_layout_from_string(&chl, cl_name);
+free(cl_name);
}
av_channel_layout_describe(&chl, buf, sizeof(buf));
--
2.37.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] Revert "avfilter/vf_palette(gen|use): support palettes with alpha"
On 10/31/22, Clément Bœsch wrote: > On Mon, Oct 31, 2022 at 01:43:11AM +, Soft Works wrote: > [...] >> > > > The patch I had submitted doesn't change the previous behavior >> > > > without the use_alpha parameter. >> > >> > Yes I noticed, but unfortunately I'm reworking the color distance to >> > work >> > in perceptual color space, and the way that alpha is mixed up in the >> > equation just doesn't make any sense at all and prevents me from >> > doing >> > these changes. >> >> If you want to implement a new color distance algorithm, it should >> be either a new filter or a new (switchable) mode for the existing >> filter. > > Why? > >> Photoshop has these different modes as well and it would >> surely be useful, but I don't think it should be replacing the >> existing behavior. >> > > There is no point in keeping a ton of complexity exposed as user options > for something implementation specific. We offer no guarantee over how the > quantization is expected to run. > >> When it turns out that the use_alpha implementation doesn't fit >> with your new color distance calculation and you add it as >> an additional mode, then it would be fine IMO when the filter >> errors in case it would be attempted to use that mode in >> combination with use_alpha. > > IMO The use_alpha option shouldn't exist in the first place, it should be > the default behaviour because honoring the alpha is the correct thing to > do. That's not what the option is currently doing though. > >> > > Do you think it might make sense to put more weight on the >> > > alpha value by tripling it? So it would be weighted equally to the >> > > RGB value? >> > >> > You cannot mix alpha with colors at all, they are separate domains >> > and you >> > need to treat them as such. >> >> What's interesting is that I've followed the same (simplified) >> way for adding a use_alpha option to vf_elbg and it provides excellent >> results without treating alpha separately. > > I don't know how the filter works and what it's supposed to do, but if > it's indeed using the same approach as the palette ones, it cannot work. > >> > From paletteuse perspective what you need to do is first choose the >> > colors >> > in the palette that match exactly the alpha (or at least the closest >> > if >> > and only there is no exact match). Then within that set, and only >> > within >> > that one, you'd pick the closest color. >> > >> > From palettegen perspective, you need to split the colors in >> > different >> > transparency domain (a first dimensional quantization), then quantize >> > the >> > colors in each quantized alpha dimension. And when you have all your >> > quantized palettes for each level of alpha, you find an algorithm to >> > reduce the number of transparency dimensions or the number of colors >> > per >> > dimension to make it fit inside a single palette. But you can't just >> > do >> > the alpha and the colors at the same time, it cannot work, whatever >> > weights you choose. >> >> I would be curious to see how well that would work, especially >> in cases when the target palettes have just a few number of colors. >> > > You have to make a call between whether you want to preserve the > transparency or the color while constructing the palette, but when > choosing a color you must absolutely not choose a color with a different > transparency, you must pick amongst the closest alpha, with a particular > attention to extreme alphas: an opaque colors must stay opaque, and fully > transparent one as well: > - rounding a color with 43% alpha into 50% alpha is acceptable > - rounding a color with 100% alpha into a 99% alpha is not acceptable in > any way because you're starting to make transparent areas that weren't > - rounding a color with 0% alpha into a 1% alpha is not acceptable because > some areas of the images are not starting to blend into an area that was > supposedly non-existent > >> But to return to the proposal of removal: If everything from ffmpeg >> would be removed which is not perfect, then it would be lacking >> quite a number of features I suppose :-) > > We're not talking about perfection, we're talking about files with > artifacts. It's almost as bad as a corrupted file, because if used in a > pipeline where transparency matters, you're going to get a completely > broken output. > >> In the same way, one could say that palettegen/-use should be removed >> because its results are wrong and colors are randomly mixed and >> misplaced while the vf_elbg filter does it right. >> When you look at the result under the heading >> >> "Paletteuse/gen Regular (to 8-bit non-alpha palette; only single >> transparent color)" >> https://gist.github.com/softworkz/deef5c2a43d3d629c3e17f9e21544a8f?permalink_comment_id=3905155#gistcomment-3905155 >> >> Even without the alpha, many color pixels appear to be wrong and >> random like for example the light purple pixels on the darker purple >> at the bottom of the "O". That's not much different from irr
Re: [FFmpeg-devel] [PATCH] avfilter/src_movie: support unknown channel layouts
Paul B Mahol:
> -av_log(log_ctx, AV_LOG_ERROR,
> +char *cl_name;
> +
> +av_log(log_ctx, AV_LOG_WARNING,
> "Channel layout is not set in stream %d, and could not "
> "be guessed from the number of channels (%d)\n",
> st_index, dec_par->ch_layout.nb_channels);
> -return AVERROR(EINVAL);
> +cl_name = av_asprintf("%dC", dec_par->ch_layout.nb_channels);
> +av_channel_layout_from_string(&chl, cl_name);
> +free(cl_name);
1. Wrong deallocator.
2. The allocation is completely unnecessary: One can just use snprintf
with a big enough (yet still small) buffer.
3. But even that is unnecessary: Just set chl = (AVChannelLayout){
.order = AV_CHANNEL_ORDER_UNSPEC, .nb_channels =
dec_par->ch_layout.nb_channels }.
- 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] [RFC]lavc/tiff: Support dng cropping
Quoting Carl Eugen Hoyos (2022-10-23 20:46:57)
> Am So., 23. Okt. 2022 um 16:35 Uhr schrieb Carl Eugen Hoyos
> :
> >
> > Hi!
> >
> > I tried to implement dng cropping, it unfortunately can only work with
> > -flags +unaligned, is there an alternative to simply print a warning
> > if the flag was not supplied?
>
> New patch with more parentheses attached.
>
> Please comment, Carl Eugen
>
> From 1bfe065564604659b7703e75b1bb750c031fdc81 Mon Sep 17 00:00:00 2001
> From: Carl Eugen Hoyos
> Date: Sun, 23 Oct 2022 16:31:53 +0200
> Subject: [PATCH] lavc/tiff: Support dng cropping,
A FATE test would be nice.
> needs -flags +unaligned
AFAICT this is not entirely correct. Applying left cropping in
libavcodec might need AV_CODEC_FLAG_UNALIGNED, but not always. Users may
also set apply_cropping=0 and apply cropping themselves.
The decoder should not care about it in any case, since it's handled in
the generic code.
>
> Fixes samples mentioned in ticket #4364.
> ---
> libavcodec/tiff.c | 83 +++
> libavcodec/tiff.h | 3 ++
> 2 files changed, 86 insertions(+)
>
> diff --git a/libavcodec/tiff.c b/libavcodec/tiff.c
> index fd9db18c0b..33edff8213 100644
> --- a/libavcodec/tiff.c
> +++ b/libavcodec/tiff.c
> @@ -1492,6 +1492,89 @@ static int tiff_decode_tag(TiffContext *s, AVFrame
> *frame)
> case DNG_WHITE_LEVEL:
> s->white_level = value;
> break;
> +case DNG_CROP_ORIGIN:
> +if (count != 2 || type != TIFF_SHORT && type != TIFF_LONG && type !=
> TIFF_RATIONAL) {
This condition could definitely use more parentheses. Same in two checks
below.
> +av_log(s->avctx, AV_LOG_WARNING, "Invalid crop origin (count:
> %d, type: %d)\n", count, type);
> +break;
> +}
> +if (type == TIFF_RATIONAL) {
> +unsigned denum1, denum2;
> +value = ff_tget(&s->gb, TIFF_LONG, s->le);
> +denum1 = ff_tget(&s->gb, TIFF_LONG, s->le);
> +value2 = ff_tget(&s->gb, TIFF_LONG, s->le);
> +denum2 = ff_tget(&s->gb, TIFF_LONG, s->le);
> +if (denum1 != 1 || denum2 != 1) {
> +av_log(s->avctx, AV_LOG_WARNING, "Unsupported crop
> origin\n");
> +break;
> +}
> +} else {
> +value = ff_tget(&s->gb, type, s->le);
> +value2 = ff_tget(&s->gb, type, s->le);
> +}
This entire block is duplicated for DNG_CROP_ORIGIN and DNG_CROP_SIZE,
you could split it into a function.
> +av_log(s->avctx, AV_LOG_DEBUG, "dng crop origin: %d/%d\n", value,
> value2);
> +if (value >= s->width || value2 >= s->height) {
> +av_log(s->avctx, AV_LOG_WARNING, "Invalid crop origin
> (%d/%d)\n", value, value2);
> +break;
> +}
> +if ((value || value2) && !(s->avctx->flags &
> AV_CODEC_FLAG_UNALIGNED)) {
> +av_log(s->avctx, AV_LOG_WARNING,"Correct DNG cropping needs
> -flags +unaligned\n");
> +} else {
> +frame->crop_left = value;
> +frame->crop_top = value2;
> +}
> +break;
> +case DNG_CROP_SIZE:
> +if (count != 2 || type != TIFF_SHORT && type != TIFF_LONG && type !=
> TIFF_RATIONAL) {
> +av_log(s->avctx, AV_LOG_WARNING, "Invalid crop size (count: %d,
> type: %d)\n", count, type);
> +break;
> +}
> +if (type == TIFF_RATIONAL) {
> +unsigned denum1, denum2;
> +value = ff_tget(&s->gb, TIFF_LONG, s->le);
> +denum1 = ff_tget(&s->gb, TIFF_LONG, s->le);
> +value2 = ff_tget(&s->gb, TIFF_LONG, s->le);
> +denum2 = ff_tget(&s->gb, TIFF_LONG, s->le);
> +if (denum1 != 1 || denum2 != 1) {
> +av_log(s->avctx, AV_LOG_WARNING, "Unsupported crop size\n");
> +break;
> +}
> +} else {
> +value = ff_tget(&s->gb, type, s->le);
> +value2 = ff_tget(&s->gb, type, s->le);
> +}
> +av_log(s->avctx, AV_LOG_DEBUG, "dng crop size %d x %d\n", value,
> value2);
> +if (value + frame->crop_left >= s->width || value2 + frame->crop_top
> >= s->height) {
value/value2 can be arbitrary 32bit integers, so the addition can
overflow. Move crop_left/top to the other side of the comparison, since
they are known to be smaller than width/height. Analogously for
DNG_ACTIVE_AREA.
--
Anton Khirnov
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] Revert "avfilter/vf_palette(gen|use): support palettes with alpha"
On Mon, Oct 31, 2022 at 12:58:20PM +0100, Paul B Mahol wrote: [...] > I'm against removing useful features. Did you just rudely dismissed all the arguments made, or is this a joke? Regards, -- Clément B. ___ 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 0/1] Add "no packet timeout" to mpegts
This fixes mpegts infinitely parsing streams that contain only stuffed PATs, which apparently happens on some dead livetv sources. Wolfgang Haupt (1): Add "no packet" timeout option for mpegts libavformat/mpegts.c | 18 ++ 1 file changed, 18 insertions(+) -- 2.25.1 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] avcodec/v210enc: add new function for avx2 avx512 avx512icl
+%else +pand m1, m6, m1 +pandn m0, m6, m0 +porm0, m0, m1 +%endif Isn't that pattern a vpblendb or some such ? I think Kieran already responded to this on IRC but I will too. Unfortunately not. This blend is at the bit level. This is v210 so the packing has the middle sample overlapping with the bottom sample in the second byte. I also want to amend my performance numbers on Broadwell. I can confirm Kieran's disagreement and can reproduce the 10% speed up on it: 1676±14.6 vs 1426±20.9 I will re-check Zen and amend the commit message as necessary. ___ 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 0/1] Add "no packet timeout" to mpegts
This fixes mpegts infinitely parsing streams that contain only stuffed PATs, which apparently happens on some dead livetv sources. Wolfgang Haupt (1): Add "no packet" timeout option for mpegts libavformat/mpegts.c | 18 ++ 1 file changed, 18 insertions(+) -- 2.25.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] avformat/mpegts: Add "no packet" timeout option
Retrieving an mpegts stream with only stuffed PAT,
results in endless reading.
This change adds a new timeout that specifies a
timespan in AV_TIME_BASE units until when a full
packet must be read successfully.
Signed-off-by: Wolfgang Haupt
---
libavformat/mpegts.c | 16
1 file changed, 16 insertions(+)
diff --git a/libavformat/mpegts.c b/libavformat/mpegts.c
index d97702fcd7..45bf82f61c 100644
--- a/libavformat/mpegts.c
+++ b/libavformat/mpegts.c
@@ -32,6 +32,7 @@
#include "libavutil/opt.h"
#include "libavutil/avassert.h"
#include "libavutil/dovi_meta.h"
+#include "libavutil/time.h"
#include "libavcodec/avcodec.h"
#include "libavcodec/bytestream.h"
#include "libavcodec/get_bits.h"
@@ -180,6 +181,12 @@ struct MpegTSContext {
AVStream *epg_stream;
AVBufferPool* pools[32];
+
+/**
+ * Timeout in AV_TIME_BASE units, until at least one packet is read
+ * from the stream.
+ */
+int64_t packet_read_timeout;
};
#define MPEGTS_OPTIONS \
@@ -203,6 +210,8 @@ static const AVOption options[] = {
{.i64 = 0}, 0, 1, 0 },
{"max_packet_size", "maximum size of emitted packet",
offsetof(MpegTSContext, max_packet_size), AV_OPT_TYPE_INT,
{.i64 = 204800}, 1, INT_MAX/2, AV_OPT_FLAG_DECODING_PARAM },
+{"packet_read_timeout", "Maximum time utnil at least one packet is
successfully read from the stream", offsetof(MpegTSContext,
packet_read_timeout), AV_OPT_TYPE_INT64,
+ {.i64 = 0 }, 0, INT64_MAX, AV_OPT_FLAG_DECODING_PARAM },
{ NULL },
};
@@ -2972,6 +2981,7 @@ static int handle_packets(MpegTSContext *ts, int64_t
nb_packets)
const uint8_t *data;
int64_t packet_num;
int ret = 0;
+time_t start = 0;
if (avio_tell(s->pb) != ts->last_pos) {
int i;
@@ -2996,8 +3006,14 @@ static int handle_packets(MpegTSContext *ts, int64_t
nb_packets)
ts->stop_parse = 0;
packet_num = 0;
memset(packet + TS_PACKET_SIZE, 0, AV_INPUT_BUFFER_PADDING_SIZE);
+start = av_gettime_relative();
for (;;) {
packet_num++;
+if (ts->packet_read_timeout > 0 && (av_gettime_relative() - start >
ts->packet_read_timeout)) {
+av_log(ts->stream, AV_LOG_TRACE, "No packet after %"PRId64"ms\n",
ts->packet_read_timeout/1000);
+break;
+}
+
if (nb_packets != 0 && packet_num >= nb_packets ||
ts->stop_parse > 1) {
ret = AVERROR(EAGAIN);
--
2.25.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] FFmpeg 5.0
Quoting Neal Gompa (2022-10-30 22:04:42) > On Sun, Oct 30, 2022 at 4:10 PM Michael Niedermayer > wrote: > > > > On Sat, Oct 29, 2022 at 02:29:56PM -0400, Neal Gompa wrote: > > > On Fri, Oct 28, 2022 at 2:23 PM Michael Niedermayer > > > wrote: > > > > > > > > Hi > > > > > > > > According to our > > > > https://trac.ffmpeg.org/wiki/Downstreams > > > > > > > > Noone and nothing is using 5.0 > > > > should i make another release of 5.0 ? > > > > should i move 5.0 to olddownloads ? > > > > > > > > does anyone use it ? plan to use it or know of someone using it ? > > > > > > > > > > Fedora 36 still uses FFmpeg 5.0 as I discovered there was an ABI break > > > that made upgrading to FFmpeg 5.1 not possible for F36. FFmpeg 5.1 is > > > used for Fedora 37, though. > > > > > > This had apparently been also discovered by openSUSE some time ago: > > > https://build.opensuse.org/package/view_file/multimedia:libs/ffmpeg-5/work-around-abi-break.patch?expand=1 > > > > You can replace 5.0 by 5.1 but not 5.1 by 5.0, The compatibility is only > > in one way. > > Iam assuming here you talk about the addition of functions and there is > > not some other issue iam not aware of. > > > > My understanding is that when using symbol versions, modifying the > symbol table creates a breakage on its own. Do you have some authoritative source for this claim? So far all the arguments I've seen were along the lines of "because I say so". > > > > > > Do we have ABI testing in place for submitted patches? I haven't seen > > > any evidence of CI testing of patches submitted to the mailing list, > > > but maybe I'm looking in the wrong place? If there is, maybe we can > > > consider adding some kind of ABI testing for release branches, using > > > tools like libabigail[1] with abidiff[2]? > > > > > > [1]: https://sourceware.org/libabigail/ > > > [2]: https://www.mankier.com/1/abidiff > > > > iam not sure there is agreement between you and others of what is a ABI > > break > > so the tool maybe will not help. > > > > I have generaly done testing with replacing old libraries by new when doing > > releases. But for me a ABI break is if replacing a library by another breaks > > some binary that is not rebuild and linked to the new lib. > > > > More testing is always good and welcome of course. > > > > Yeah, I think that qualifying how ABI is validated in a reproducible > way would be useful. The abigail tooling can help here, In Fedora, > every update runs through abigail validation too. I vaguely recall > that it warned me when I did the update in Rawhide, which is how I wound > up talking to Jan in openSUSE and RPM Fusion maintainers, who both > didn't refresh FFmpeg on stable branches with 5.0 to 5.1. > > It's also entirely possible that I was *too* cautious, and I'm okay > with having a conversation that leads me to do differently in the future. Having automated ABI testing would be definitely a good idea, not all developers understand how ABI compatibility works and there have been breakages (according to our definition) recently. I also have https://github.com/lvc/abi-compliance-checker/ on my to-look-at list, but as always time is lacking. -- Anton Khirnov ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] Revert "avfilter/vf_palette(gen|use): support palettes with alpha"
> -Original Message- > From: ffmpeg-devel On Behalf Of > Clément Bœsch > Sent: Monday, October 31, 2022 11:57 AM > To: FFmpeg development discussions and patches de...@ffmpeg.org> > Subject: Re: [FFmpeg-devel] [PATCH] Revert > "avfilter/vf_palette(gen|use): support palettes with alpha" > > On Mon, Oct 31, 2022 at 01:43:11AM +, Soft Works wrote: > [...] > > > > > The patch I had submitted doesn't change the previous > behavior > > > > > without the use_alpha parameter. > > > > > > Yes I noticed, but unfortunately I'm reworking the color distance > to > > > work > > > in perceptual color space, and the way that alpha is mixed up in > the > > > equation just doesn't make any sense at all and prevents me from > > > doing > > > these changes. > > > > If you want to implement a new color distance algorithm, it should > > be either a new filter or a new (switchable) mode for the existing > > filter. > > Why? > > > Photoshop has these different modes as well and it would > > surely be useful, but I don't think it should be replacing the > > existing behavior. > > > > There is no point in keeping a ton of complexity exposed as user > options > for something implementation specific. We offer no guarantee over how > the > quantization is expected to run. Says who? > > When it turns out that the use_alpha implementation doesn't fit > > with your new color distance calculation and you add it as > > an additional mode, then it would be fine IMO when the filter > > errors in case it would be attempted to use that mode in > > combination with use_alpha. > > IMO The use_alpha option shouldn't exist in the first place, it > should be > the default behaviour because honoring the alpha is the correct thing > to > do. That's not what the option is currently doing though. > > > > > Do you think it might make sense to put more weight on the > > > > alpha value by tripling it? So it would be weighted equally to > the > > > > RGB value? > > > > > > You cannot mix alpha with colors at all, they are separate > domains > > > and you > > > need to treat them as such. > > > > What's interesting is that I've followed the same (simplified) > > way for adding a use_alpha option to vf_elbg and it provides > excellent > > results without treating alpha separately. > > I don't know how the filter works and what it's supposed to do, but > if > it's indeed using the same approach as the palette ones, it cannot > work. Then it's magic, I guess. The commands and results are on the same page I have posted. And pngquant doing the impossible as well: > Interestingly, pngquant which is supposed to have the best open source > quantization algorithms seems to be using weights (albeit in a more > sophisticated way) and does not handle alpha separately for calculating > color distance, variance and averaging: https://github.com/ImageOptim/libimagequant/blob/a16c9ca66a24158496da02d86925cc0167831205/pam.h#L163-L182 https://github.com/ImageOptim/libimagequant/blob/a16c9ca66a24158496da02d86925cc0167831205/mediancut.c#L29-L49 https://github.com/ImageOptim/libimagequant/blob/a16c9ca66a24158496da02d86925cc0167831205/mediancut.c#L449-L476 > That's not how it's going to work, sorry; I'm not going to increase > complexity and maintenance effort for no gain. Implementing a correct > support for the alpha will likely involve a revert of that commit > anyway. If you want to improve the way it works that's another story. But at this point, we're talking about removal. And I disagree to that. Best regards, softworkz ___ 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/av1: fixed an vaapi decoding corruption issue
[problem]
When decoding an av1 bitstream, it shows image corruption
in the middle of the bitstream around key frames.
[analysis]
In av1_spec.pdf page 38/669, there is a sentence below:
if ( frame_type == KEY_FRAME && show_frame ) {
for ( i = 0; i < NUM_REF_FRAMES; i++) {
RefValid[ i ] = 0
..
}
..
}
This shows that the condition of invalidating current
DPB frames should be the coming frame_type is KEY_FRAME plus
show_frame is equal to 1. Otherwise, some of the frames
in sequence after KEY_FRAME still refer to the reference frames
before KEY_FRAME, and if these before KEY_FRAME reference
frames were invalidated, these frames could not find their
reference frames, and it could cause image corruption.
[solution]
Add show_frame flag as another condition to co-determine
when to invalidate DPB reference frames.
Mesa fix is in https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/19386
cc: Fei Wang
Signed-off-by: Ruijing Dong
---
libavcodec/vaapi_av1.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavcodec/vaapi_av1.c b/libavcodec/vaapi_av1.c
index 63374c31c9..d0339b2705 100644
--- a/libavcodec/vaapi_av1.c
+++ b/libavcodec/vaapi_av1.c
@@ -274,7 +274,7 @@ static int vaapi_av1_start_frame(AVCodecContext *avctx,
};
for (int i = 0; i < AV1_NUM_REF_FRAMES; i++) {
-if (pic_param.pic_info_fields.bits.frame_type == AV1_FRAME_KEY)
+if (pic_param.pic_info_fields.bits.frame_type == AV1_FRAME_KEY &&
frame_header->show_frame)
pic_param.ref_frame_map[i] = VA_INVALID_ID;
else
pic_param.ref_frame_map[i] = ctx->ref_tab[i].valid ?
--
2.25.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] libavcodec/flacenc: Enable sample rates > 655350 Hz
Also, make use of the full sample rate code table
---
libavcodec/flacenc.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/libavcodec/flacenc.c b/libavcodec/flacenc.c
index 5d8c3f82be..bca71b3780 100644
--- a/libavcodec/flacenc.c
+++ b/libavcodec/flacenc.c
@@ -299,7 +299,7 @@ static av_cold int flac_encode_init(AVCodecContext *avctx)
/* find samplerate in table */
if (freq < 1)
return AVERROR(EINVAL);
-for (i = 4; i < 12; i++) {
+for (i = 1; i < 12; i++) {
if (freq == ff_flac_sample_rate_table[i]) {
s->samplerate = ff_flac_sample_rate_table[i];
s->sr_code[0] = i;
@@ -318,6 +318,9 @@ static av_cold int flac_encode_init(AVCodecContext *avctx)
} else if (freq < 65535) {
s->sr_code[0] = 13;
s->sr_code[1] = freq;
+} else if (freq < 1048576) {
+s->sr_code[0] = 0;
+s->sr_code[1] = 0;
} else {
av_log(avctx, AV_LOG_ERROR, "%d Hz not supported\n", freq);
return AVERROR(EINVAL);
--
2.37.3
___
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/flacenc: Enable sample rates > 655350 Hz
On 10/31/2022 4:09 PM, Martijn van Beurden wrote: > Also, make use of the full sample rate code table > --- > libavcodec/flacenc.c | 5 - > 1 file changed, 4 insertions(+), 1 deletion(-) It is interesting that the IETF RFC and the Xiph spec disagree on whether this is allowed. The Xiph spec says: Sample rate in Hz. Though 20 bits are available, the maximum sample rate is limited by the structure of frame headers to 655350Hz. Also, a value of 0 is invalid. The RFC just says: Sample rate in Hz. I see your name on the RFC - can you provide some insight here? - Derek ___ 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/libaomdec: fix pix_fmt w/AVCOL_SPC_RGB
On Tue, Oct 25, 2022 at 10:02 PM James Zern wrote: > > On Tue, Oct 25, 2022 at 11:28 AM James Zern wrote: > > > > Signed-off-by: James Zern > > --- > > libavcodec/libaomdec.c | 8 ++-- > > 1 file changed, 6 insertions(+), 2 deletions(-) > > > > I was reminded that there was an earlier patch [1], which I had an > open comment on. I think it's better to be consistent with the > libdav1d wrapper and ffvp9/libvpx for now. > I pushed this. Any other fixes should try to keep both wrappers in sync. > [1] > https://patchwork.ffmpeg.org/project/ffmpeg/patch/20210606051612.89211-1-val.zapod...@gmail.com/ ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] FFmpeg 5.0
On Monday, 31 October 2022 14:03:21 CET Anton Khirnov wrote: > Quoting Neal Gompa (2022-10-30 22:04:42) > > > On Sun, Oct 30, 2022 at 4:10 PM Michael Niedermayer > > > > wrote: > > > On Sat, Oct 29, 2022 at 02:29:56PM -0400, Neal Gompa wrote: > > > > On Fri, Oct 28, 2022 at 2:23 PM Michael Niedermayer > > > > > > > > wrote: > > > > > Hi > > > > > > > > > > According to our > > > > > https://trac.ffmpeg.org/wiki/Downstreams > > > > > > > > > > Noone and nothing is using 5.0 > > > > > should i make another release of 5.0 ? > > > > > should i move 5.0 to olddownloads ? > > > > > > > > > > does anyone use it ? plan to use it or know of someone using it ? > > > > > > > > Fedora 36 still uses FFmpeg 5.0 as I discovered there was an ABI break > > > > that made upgrading to FFmpeg 5.1 not possible for F36. FFmpeg 5.1 is > > > > used for Fedora 37, though. > > > > > > > > This had apparently been also discovered by openSUSE some time ago: > > > > https://build.opensuse.org/package/view_file/multimedia:libs/ffmpeg-5/ > > > > work-around-abi-break.patch?expand=1> > > > > You can replace 5.0 by 5.1 but not 5.1 by 5.0, The compatibility is only > > > in one way. > > > Iam assuming here you talk about the addition of functions and there is > > > not some other issue iam not aware of. > > > > My understanding is that when using symbol versions, modifying the > > symbol table creates a breakage on its own. > > Do you have some authoritative source for this claim? So far all the > arguments I've seen were along the lines of "because I say so". > > > > > Do we have ABI testing in place for submitted patches? I haven't seen > > > > any evidence of CI testing of patches submitted to the mailing list, > > > > but maybe I'm looking in the wrong place? If there is, maybe we can > > > > consider adding some kind of ABI testing for release branches, using > > > > tools like libabigail[1] with abidiff[2]? > > > > > > > > [1]: https://sourceware.org/libabigail/ > > > > [2]: https://www.mankier.com/1/abidiff > > > > > > iam not sure there is agreement between you and others of what is a ABI > > > break so the tool maybe will not help. > > > > > > I have generaly done testing with replacing old libraries by new when > > > doing > > > releases. But for me a ABI break is if replacing a library by another > > > breaks some binary that is not rebuild and linked to the new lib. > > > > > > More testing is always good and welcome of course. > > > > Yeah, I think that qualifying how ABI is validated in a reproducible > > way would be useful. The abigail tooling can help here, In Fedora, > > every update runs through abigail validation too. I vaguely recall > > that it warned me when I did the update in Rawhide, which is how I wound > > up talking to Jan in openSUSE and RPM Fusion maintainers, who both > > didn't refresh FFmpeg on stable branches with 5.0 to 5.1. > > > > It's also entirely possible that I was *too* cautious, and I'm okay > > with having a conversation that leads me to do differently in the future. > > Having automated ABI testing would be definitely a good idea, not all > developers understand how ABI compatibility works and there have been > breakages (according to our definition) recently. > > I also have https://github.com/lvc/abi-compliance-checker/ on my > to-look-at list, but as always time is lacking. At libssh we use https://github.com/ansasaki/abimap for symbol versioning. Ask if master could be added to ABI Laboratory: https://abi-laboratory.pro/index.php?view=timeline&l=ffmpeg Just my 2c. Andreas -- Andreas Schneider a...@cryptomilk.org GPG-ID: 8DFF53E18F2ABC8D8F3C92237EE0FC4DCC014E3D ___ 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/flacenc: Enable sample rates > 655350 Hz
Op ma 31 okt. 2022 om 17:58 schreef Derek Buitenhuis : > > It is interesting that the IETF RFC and the Xiph spec disagree on whether > this is allowed. > The Xiph spec also says the IETF spec is better, and it remains as historical reference and overview :) > The Xiph spec says: > > Sample rate in Hz. Though 20 bits are available, the maximum sample rate > is limited by the > structure of frame headers to 655350Hz. Also, a value of 0 is invalid. > > The RFC just says: > >Sample rate in Hz. > The spec as it is on the FLAC website (which is being "preserved") is wrong. I don't know how this came to be, I think it was at first poorly worded and later incorrectly fixed. See this commit: https://github.com/xiph/flac/commit/96534bb5f35eb9c2f6f393dc470625e9c74df1a5 The text as it was before that commit doesn't make any sense, the text as it is after the commit is not correct either. The issue here is that FLAC has a sample rate in the streaminfo metadata block, at the very start of the file. That one can accommodate sample rates up to 2^20-1. The frame headers repeat the sample rate every frame and can only accommodate up to 655350Hz, but they can also reference the streaminfo metadata block. Because of the possibility to reference that 20 bit number, it is possible to store sample rates up to 1048575Hz. You can see this patch only touches the encoder: the FFmpeg decoder has already been equipped to deal with this since its inception in 2004. There is some kind of limitation to sample rates above 655350Hz, or samplerates between 65535Hz and 655350Hz that are not a multiple of 10 though: a FLAC file with such a sample rate cannot be multicast, because a decoder receiving a multicast stream does not receive the streaminfo metadata block, and thus cannot use it to figure out the correct sample rate. Please let me know when this explanation falls short. Kind regards, Martijn van Beurden ___ 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] Revert "avfilter/vf_palette(gen|use): support palettes with alpha"
On Mon, Oct 31, 2022 at 03:11:13PM +, Soft Works wrote: [...] > > > Photoshop has these different modes as well and it would > > > surely be useful, but I don't think it should be replacing the > > > existing behavior. > > > > > > > There is no point in keeping a ton of complexity exposed as user > > options > > for something implementation specific. We offer no guarantee over how > > the > > quantization is expected to run. > > Says who? The API contract with the user is that we propose a quantization, the implementation details do not matter, we do not document that so we take no engagement whatsoever in that regards. Also, users are not looking for many options about how it works under the hood, they just want the best they can get out of the box, that's a basic UX rule. [...] > And pngquant doing the impossible as well: > > > Interestingly, pngquant which is supposed to have the best open source > > quantization algorithms Says who? > > seems to be using weights (albeit in a more > > sophisticated way) and does not handle alpha separately for calculating > > color distance, variance and averaging: > > https://github.com/ImageOptim/libimagequant/blob/a16c9ca66a24158496da02d86925cc0167831205/pam.h#L163-L182 > > https://github.com/ImageOptim/libimagequant/blob/a16c9ca66a24158496da02d86925cc0167831205/mediancut.c#L29-L49 > > https://github.com/ImageOptim/libimagequant/blob/a16c9ca66a24158496da02d86925cc0167831205/mediancut.c#L449-L476 > I'd rather not look too much into that code. Do they mess up the alpha channel as well? If not, feel free to investigate how they achieve that. > > That's not how it's going to work, sorry; I'm not going to increase > > complexity and maintenance effort for no gain. Implementing a correct > > support for the alpha will likely involve a revert of that commit > > anyway. > > If you want to improve the way it works that's another story. > > But at this point, we're talking about removal. And I disagree to that. You may disagree but: - the option causes many transparency artifacts - the option is fundamentally flawed and need to be rewritten differently - handling the alpha should be by default if such a feature was existing - the option is preventing improvements to the code I will send a patchset in the coming days, which depends on its removal. You'll be free to propose again a patch to support alpha quantization properly, but I'll ask for it to be reliable enough so that it's enabled by default. Regards, -- Clément B. ___ 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] avfilter/src_movie: support unknown channel layouts
On 10/31/2022 9:15 AM, Andreas Rheinhardt wrote:
Paul B Mahol:
-av_log(log_ctx, AV_LOG_ERROR,
+char *cl_name;
+
+av_log(log_ctx, AV_LOG_WARNING,
"Channel layout is not set in stream %d, and could not "
"be guessed from the number of channels (%d)\n",
st_index, dec_par->ch_layout.nb_channels);
-return AVERROR(EINVAL);
+cl_name = av_asprintf("%dC", dec_par->ch_layout.nb_channels);
+av_channel_layout_from_string(&chl, cl_name);
+free(cl_name);
1. Wrong deallocator.
2. The allocation is completely unnecessary: One can just use snprintf
with a big enough (yet still small) buffer.
3. But even that is unnecessary: Just set chl = (AVChannelLayout){
.order = AV_CHANNEL_ORDER_UNSPEC, .nb_channels =
dec_par->ch_layout.nb_channels }.
He doesn't even need to do that because it's already set.
av_channel_layout_default() will give set the output layout as an UNSPEC
one with nb_channels amount of channels if it can't find a named native
layout for it.
There is however a problem with this patch as is, and it's the next
printed warning now that he removed the return. After this change it
will mention a layout was guessed when one wasn't. So this patch should
simply change the "return AVERROR(EINVAL)" into another "return
av_channel_layout_copy(&dec_par->ch_layout, &chl);"
___
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 03/10] avcodec: add bitstream parser for H266/VVC
On 10/31/2022 7:16 AM, Thomas Siedel wrote:
On Mon, 24 Oct 2022 at 16:38, James Almer wrote:
On 10/24/2022 11:06 AM, Thomas Siedel wrote:
+static int combine_au(AVCodecParserContext *ctx, AVCodecContext *avctx,
+ const uint8_t **buf, int *buf_size)
+{
This is being called only when you first assembled AUs from what's
assumed to be raw input. When PARSER_FLAG_COMPLETE_FRAMES is set, it
should also parse the AU for bitstream information.
Yes, currently, "combine_au" is only called when
PARSER_FLAG_COMPLETE_FRAMES is disabled, but I do not really understand
what the issue is here.
I'm not talking about combine_au() but parse_nal_units(), which is only
called from within combine_au(). My comment was about bitstream parsing,
not AU assembling. Apologies if it wasn't clear.
As far as I know, all bitstream information is parsed properly for any kind
of supported content (currently, ES, MP4, and TS are supported).
Would you happen to have an example of a use case where
PARSER_FLAG_COMPLETE_FRAMES is enabled, and the bitstream information is
needed or not parsed correctly from the current implementation?
libavformat and its demuxers are not the only user of AVCodecParsers.
The current behavior is pretty similar to other codec
parser implementations like hevc, avc, and av1. Why should the vvc parser
code differ from the (default) behavior of other codecs?
Both h264 and hevc parsers call parse_nal_units() regardless of
PARSER_FLAG_COMPLETE_FRAMES being set or not.
AVCodecParsers have two purposes. One is assembling a full packet for a
given timestamp (access unit for these codecs, temporal unit for av1,
the like) depending on the value of AVCodecParserContext.flags, and the
other is parsing the full packet for bitstream information. If a parser
does the latter, it should do it regardless of having assembled a packet
before that or not.
The parser doesn't know where the packet came from. It could have been a
lavf demuxer, or it could have been from some other lavc user, because
this API after all is from lavc and not lavf. So it must always fill the
AVCodecParserContext struct with the parsed information if it's present
and readable.
If i set the PARSER_FLAG_COMPLETE_FRAMES flag, this parser as you wrote
it is a no-op.
+VVCParserContext *s = ctx->priv_data;
+CodedBitstreamFragment *pu = &s->picture_unit;
+int ret;
+
+s->cbc->log_ctx = avctx;
+
+if (avctx->extradata_size && !s->parsed_extradata) {
+s->parsed_extradata = 1;
+
+if ((ret = ff_cbs_read(s->cbc, pu, avctx->extradata,
avctx->extradata_size)) < 0)
ff_cbs_read_extradata_from_codec()
+av_log(avctx, AV_LOG_WARNING, "Failed to parse
extradata.\n");
+
+ff_cbs_fragment_reset(pu);
+}
+av_packet_unref(&s->last_au);
+ret = parse_nal_units(ctx, *buf, *buf_size, avctx);
+if (ret == 0) {
+if (s->last_au.size) {
+*buf = s->last_au.data;
+*buf_size = s->last_au.size;
+} else {
+//no output
+ret = 1;
+}
+}
+s->cbc->log_ctx = NULL;
+return ret;
+}
+
+static int vvc_parser_parse(AVCodecParserContext *ctx, AVCodecContext
*avctx,
+ const uint8_t **poutbuf, int *poutbuf_size,
+ const uint8_t *buf, int buf_size)
+{
+int next;
+VVCParserContext *s = ctx->priv_data;
+ParseContext *pc = &s->pc;
+
+if (avctx->extradata && !s->parsed_extradata) {
+av_log(avctx, AV_LOG_INFO, "extra data is not supported
yet.\n");
+return AVERROR_PATCHWELCOME;
+}
+
+if (ctx->flags & PARSER_FLAG_COMPLETE_FRAMES) {
+next = buf_size;
+} else {
+int ret, flush = !buf_size;
+next = find_frame_end(ctx, buf, buf_size);
+if (ff_combine_frame(pc, next, &buf, &buf_size) < 0)
+goto no_out;
+ret = combine_au(ctx, avctx, &buf, &buf_size);
+if (ret > 0 && flush) {
+buf_size = 0;
+ret = combine_au(ctx, avctx, &buf, &buf_size);
+}
+if (ret != 0) {
+buf_size = next;
+goto no_out;
+}
+}
+*poutbuf = buf;
+*poutbuf_size = buf_size;
+return next;
+no_out:
+*poutbuf = NULL;
+*poutbuf_size = 0;
+return buf_size;
+}
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ff
Re: [FFmpeg-devel] [PATCH] avfilter/src_movie: support unknown channel layouts
On 10/31/22, Paul B Mahol wrote:
> Patch attached.
>
Fixed patch attached.
From 17a5d411ff9a130aab7b9f638c94b35281f20133 Mon Sep 17 00:00:00 2001
From: Paul B Mahol
Date: Mon, 31 Oct 2022 12:55:17 +0100
Subject: [PATCH] avfilter/src_movie: support unknown channel layouts
Signed-off-by: Paul B Mahol
---
libavfilter/src_movie.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/libavfilter/src_movie.c b/libavfilter/src_movie.c
index 711854c23c..5937613d13 100644
--- a/libavfilter/src_movie.c
+++ b/libavfilter/src_movie.c
@@ -196,11 +196,11 @@ static int guess_channel_layout(MovieStream *st, int st_index, void *log_ctx)
av_channel_layout_default(&chl, dec_par->ch_layout.nb_channels);
if (!KNOWN(&chl)) {
-av_log(log_ctx, AV_LOG_ERROR,
+av_log(log_ctx, AV_LOG_WARNING,
"Channel layout is not set in stream %d, and could not "
"be guessed from the number of channels (%d)\n",
st_index, dec_par->ch_layout.nb_channels);
-return AVERROR(EINVAL);
+return av_channel_layout_copy(&dec_par->ch_layout, &chl);
}
av_channel_layout_describe(&chl, buf, sizeof(buf));
--
2.37.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".
[FFmpeg-devel] [PATCH v2] avcodec/atrac3plus: reorder channels to match the output layout
The order in which the channels are coded in the bitstream do not always follow
the native, bitmask-based order of channels both signaled by the WAV container
and forced by this same decoder. This is the case with layouts containing an
LFE channel, as it's always coded last.
Fixes ticket #9964.
Signed-off-by: James Almer
---
libavcodec/atrac3plusdec.c | 13 -
1 file changed, 12 insertions(+), 1 deletion(-)
diff --git a/libavcodec/atrac3plusdec.c b/libavcodec/atrac3plusdec.c
index ee71645a3c..9e12f21930 100644
--- a/libavcodec/atrac3plusdec.c
+++ b/libavcodec/atrac3plusdec.c
@@ -48,6 +48,17 @@
#include "atrac.h"
#include "atrac3plus.h"
+static uint8_t channel_map[8][8] = {
+{ 0, },
+{ 0, 1, },
+{ 0, 1, 2, },
+{ 0, 1, 2, 3, },
+{ 0, },
+{ 0, 1, 2, 4, 5, 3, },
+{ 0, 1, 2, 4, 5, 8, 3, },
+{ 0, 1, 2, 4, 5, 9, 10, 3, },
+};
+
typedef struct ATRAC3PContext {
GetBitContext gb;
AVFloatDSPContext *fdsp;
@@ -378,7 +389,7 @@ static int atrac3p_decode_frame(AVCodecContext *avctx,
AVFrame *frame,
channels_to_process, avctx);
for (i = 0; i < channels_to_process; i++)
-memcpy(samples_p[out_ch_index + i], ctx->outp_buf[i],
+memcpy(samples_p[channel_map[frame->ch_layout.nb_channels -
1][out_ch_index + i]], ctx->outp_buf[i],
ATRAC3P_FRAME_SAMPLES * sizeof(**samples_p));
ch_block++;
--
2.38.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] Revert "avfilter/vf_palette(gen|use): support palettes with alpha"
> -Original Message- > From: ffmpeg-devel On Behalf Of > Clément Bœsch > Sent: Monday, October 31, 2022 7:51 PM > To: FFmpeg development discussions and patches de...@ffmpeg.org> > Subject: Re: [FFmpeg-devel] [PATCH] Revert > "avfilter/vf_palette(gen|use): support palettes with alpha" > > On Mon, Oct 31, 2022 at 03:11:13PM +, Soft Works wrote: > [...] > > And pngquant doing the impossible as well: > > > > > Interestingly, pngquant which is supposed to have the best open > source > > > quantization algorithms > > Says who? That's the result of my research I did at that time. Feel free to do your own research. > https://github.com/ImageOptim/libimagequant/blob/a16c9ca66a24158496da > 02d86925cc0167831205/pam.h#L163-L182 > > > https://github.com/ImageOptim/libimagequant/blob/a16c9ca66a24158496da > 02d86925cc0167831205/mediancut.c#L29-L49 > > > https://github.com/ImageOptim/libimagequant/blob/a16c9ca66a24158496da > 02d86925cc0167831205/mediancut.c#L449-L476 > > > > I'd rather not look too much into that code. Do they mess up the > alpha > channel as well? When working on this, you should at least be familiar with the quality of results it provides, even when you don't want to look at the code. > > If you want to improve the way it works that's another story. > > > > But at this point, we're talking about removal. And I disagree to > that. > > You may disagree but: > - the option causes many transparency artifacts > - the option is fundamentally flawed and need to be rewritten > differently > - handling the alpha should be by default if such a feature was > existing > - the option is preventing improvements to the code > > I will send a patchset in the coming days, which depends on its > removal. > You'll be free to propose again a patch to support alpha quantization I'll take that as a joke.. > properly, but I'll ask for it to be reliable enough so that it's > enabled > by default. That's not acceptable either, because the filter may also be used to create animated GIFs where only a single palette entry may exist which indicates full transparency and all others are fully opaque. I don't want to be just negative and rejective and I'm really welcoming patches that provide improvement. But I think that a prerequisite for working on this subject is to be familiar with state-of-the art implementations of image color quantization. The best implementations I'm aware of can be found in PhotoShop (closed source) and pngquant (open source). The quantization that vf_elbg (with use_alpha) does get very close to the aforementioned, but it comes at the price of relatively high computational cost. If you would come up with an implementation for palettegen/-use that provides comparable results in an efficient way like pngquant, that would be really awesome! > but I'll ask for it to be reliable enough so that it's I'll ask for your patch to support alpha in the same optional way like it is supported right now. (actually something that should go without saying) Best regards, softworkz ___ 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/6 v3] avcodec/aacdec: fix parsing streams with channel configuration 11
Set the correct amount of tags in tags_per_config[].
Also, there are no channels that correspond to a side element in this
configuration, so reflect this in the list of known/supported channel layouts.
Signed-off-by: James Almer
---
libavcodec/aacdec_template.c | 4 +---
libavcodec/aacdectab.h | 6 +++---
2 files changed, 4 insertions(+), 6 deletions(-)
diff --git a/libavcodec/aacdec_template.c b/libavcodec/aacdec_template.c
index 4a9513d53e..c10bc743b6 100644
--- a/libavcodec/aacdec_template.c
+++ b/libavcodec/aacdec_template.c
@@ -731,9 +731,7 @@ static ChannelElement *get_che(AACContext *ac, int type,
int elem_id)
return ac->tag_che_map[TYPE_CPE][elem_id] = ac->che[TYPE_CPE][2];
}
case 11:
-if (ac->tags_mapped == 2 &&
-ac->oc[1].m4ac.chan_config == 11 &&
-type == TYPE_SCE) {
+if (ac->tags_mapped == 3 && type == TYPE_SCE) {
ac->tags_mapped++;
return ac->tag_che_map[TYPE_SCE][elem_id] = ac->che[TYPE_SCE][1];
}
diff --git a/libavcodec/aacdectab.h b/libavcodec/aacdectab.h
index e38b93a534..327efbcde0 100644
--- a/libavcodec/aacdectab.h
+++ b/libavcodec/aacdectab.h
@@ -35,7 +35,7 @@
#include
-static const int8_t tags_per_config[16] = { 0, 1, 1, 2, 3, 3, 4, 5, 0, 0, 0,
4, 5, 16, 5, 0 };
+static const int8_t tags_per_config[16] = { 0, 1, 1, 2, 3, 3, 4, 5, 0, 0, 0,
5, 5, 16, 5, 0 };
static const uint8_t aac_channel_layout_map[16][16][3] = {
{ { TYPE_SCE, 0, AAC_CHANNEL_FRONT }, },
@@ -81,7 +81,7 @@ static const uint64_t aac_channel_layout[] = {
AV_CH_LAYOUT_5POINT0_BACK,
AV_CH_LAYOUT_5POINT1_BACK,
AV_CH_LAYOUT_7POINT1_WIDE_BACK,
-AV_CH_LAYOUT_6POINT1,
+AV_CH_LAYOUT_6POINT1_BACK,
AV_CH_LAYOUT_7POINT1,
AV_CH_LAYOUT_22POINT2,
0,
@@ -97,7 +97,7 @@ static const AVChannelLayout aac_ch_layout[] = {
AV_CHANNEL_LAYOUT_5POINT0_BACK,
AV_CHANNEL_LAYOUT_5POINT1_BACK,
AV_CHANNEL_LAYOUT_7POINT1_WIDE_BACK,
-AV_CHANNEL_LAYOUT_6POINT1,
+AV_CHANNEL_LAYOUT_6POINT1_BACK,
AV_CHANNEL_LAYOUT_7POINT1,
AV_CHANNEL_LAYOUT_22POINT2,
{ 0 },
--
2.38.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH 2/6 v3] avutil/channel_layout: add a 7.1(top) channel layout
Signed-off-by: James Almer
---
doc/APIchanges| 3 +++
doc/utils.texi| 2 ++
libavutil/channel_layout.c| 1 +
libavutil/channel_layout.h| 2 ++
tests/ref/fate/channel_layout | 1 +
5 files changed, 9 insertions(+)
diff --git a/doc/APIchanges b/doc/APIchanges
index 3c86f24285..58a970328b 100644
--- a/doc/APIchanges
+++ b/doc/APIchanges
@@ -14,6 +14,9 @@ libavutil: 2021-04-27
API changes, most recent first:
+2022-10-xx - xx - lavu 57.xx.xxx - channel_layout.h
+ Add AV_CH_LAYOUT_7POINT1_TOP_BACK and AV_CHANNEL_LAYOUT_7POINT1_TOP_BACK.
+
2022-10-30 - xx - lavu 57.40.100 - channel_layout.h
Add AV_CH_LAYOUT_CUBE and AV_CHANNEL_LAYOUT_CUBE.
diff --git a/doc/utils.texi b/doc/utils.texi
index 907a6b87cb..8e8bfa76d4 100644
--- a/doc/utils.texi
+++ b/doc/utils.texi
@@ -713,6 +713,8 @@ FL+FR+FC+LFE+BL+BR+SL+SR
FL+FR+FC+LFE+BL+BR+FLC+FRC
@item 7.1(wide-side)
FL+FR+FC+LFE+FLC+FRC+SL+SR
+@item 7.1(top)
+FL+FR+FC+LFE+BL+BR+TFL+TFR
@item octagonal
FL+FR+FC+BL+BR+BC+SL+SR
@item cube
diff --git a/libavutil/channel_layout.c b/libavutil/channel_layout.c
index 5af7ea0e01..e2f7512254 100644
--- a/libavutil/channel_layout.c
+++ b/libavutil/channel_layout.c
@@ -196,6 +196,7 @@ static const struct channel_layout_name
channel_layout_map[] = {
{ "7.1",AV_CHANNEL_LAYOUT_7POINT1 },
{ "7.1(wide)", AV_CHANNEL_LAYOUT_7POINT1_WIDE_BACK },
{ "7.1(wide-side)", AV_CHANNEL_LAYOUT_7POINT1_WIDE},
+{ "7.1(top)", AV_CHANNEL_LAYOUT_7POINT1_TOP_BACK},
{ "octagonal", AV_CHANNEL_LAYOUT_OCTAGONAL },
{ "cube", AV_CHANNEL_LAYOUT_CUBE},
{ "hexadecagonal", AV_CHANNEL_LAYOUT_HEXADECAGONAL },
diff --git a/libavutil/channel_layout.h b/libavutil/channel_layout.h
index 3e69163360..f345415c55 100644
--- a/libavutil/channel_layout.h
+++ b/libavutil/channel_layout.h
@@ -232,6 +232,7 @@ enum AVChannelOrder {
#define AV_CH_LAYOUT_7POINT1
(AV_CH_LAYOUT_5POINT1|AV_CH_BACK_LEFT|AV_CH_BACK_RIGHT)
#define AV_CH_LAYOUT_7POINT1_WIDE
(AV_CH_LAYOUT_5POINT1|AV_CH_FRONT_LEFT_OF_CENTER|AV_CH_FRONT_RIGHT_OF_CENTER)
#define AV_CH_LAYOUT_7POINT1_WIDE_BACK
(AV_CH_LAYOUT_5POINT1_BACK|AV_CH_FRONT_LEFT_OF_CENTER|AV_CH_FRONT_RIGHT_OF_CENTER)
+#define AV_CH_LAYOUT_7POINT1_TOP_BACK
(AV_CH_LAYOUT_5POINT1_BACK|AV_CH_TOP_FRONT_LEFT|AV_CH_TOP_FRONT_RIGHT)
#define AV_CH_LAYOUT_OCTAGONAL
(AV_CH_LAYOUT_5POINT0|AV_CH_BACK_LEFT|AV_CH_BACK_CENTER|AV_CH_BACK_RIGHT)
#define AV_CH_LAYOUT_CUBE
(AV_CH_LAYOUT_QUAD|AV_CH_TOP_FRONT_LEFT|AV_CH_TOP_FRONT_RIGHT|AV_CH_TOP_BACK_LEFT|AV_CH_TOP_BACK_RIGHT)
#define AV_CH_LAYOUT_HEXADECAGONAL
(AV_CH_LAYOUT_OCTAGONAL|AV_CH_WIDE_LEFT|AV_CH_WIDE_RIGHT|AV_CH_TOP_BACK_LEFT|AV_CH_TOP_BACK_RIGHT|AV_CH_TOP_BACK_CENTER|AV_CH_TOP_FRONT_CENTER|AV_CH_TOP_FRONT_LEFT|AV_CH_TOP_FRONT_RIGHT)
@@ -389,6 +390,7 @@ typedef struct AVChannelLayout {
#define AV_CHANNEL_LAYOUT_7POINT1 AV_CHANNEL_LAYOUT_MASK(8,
AV_CH_LAYOUT_7POINT1)
#define AV_CHANNEL_LAYOUT_7POINT1_WIDE AV_CHANNEL_LAYOUT_MASK(8,
AV_CH_LAYOUT_7POINT1_WIDE)
#define AV_CHANNEL_LAYOUT_7POINT1_WIDE_BACK AV_CHANNEL_LAYOUT_MASK(8,
AV_CH_LAYOUT_7POINT1_WIDE_BACK)
+#define AV_CHANNEL_LAYOUT_7POINT1_TOP_BACK AV_CHANNEL_LAYOUT_MASK(8,
AV_CH_LAYOUT_7POINT1_TOP_BACK)
#define AV_CHANNEL_LAYOUT_OCTAGONAL AV_CHANNEL_LAYOUT_MASK(8,
AV_CH_LAYOUT_OCTAGONAL)
#define AV_CHANNEL_LAYOUT_CUBE AV_CHANNEL_LAYOUT_MASK(8,
AV_CH_LAYOUT_CUBE)
#define AV_CHANNEL_LAYOUT_HEXADECAGONAL AV_CHANNEL_LAYOUT_MASK(16,
AV_CH_LAYOUT_HEXADECAGONAL)
diff --git a/tests/ref/fate/channel_layout b/tests/ref/fate/channel_layout
index 02eaad0929..b93f96dbb3 100644
--- a/tests/ref/fate/channel_layout
+++ b/tests/ref/fate/channel_layout
@@ -24,6 +24,7 @@ hexagonal FL+FR+FC+BL+BR+BC
7.1FL+FR+FC+LFE+BL+BR+SL+SR
7.1(wide) FL+FR+FC+LFE+BL+BR+FLC+FRC
7.1(wide-side) FL+FR+FC+LFE+FLC+FRC+SL+SR
+7.1(top) FL+FR+FC+LFE+BL+BR+TFL+TFR
octagonal FL+FR+FC+BL+BR+BC+SL+SR
cube FL+FR+BL+BR+TFL+TFR+TBL+TBR
hexadecagonal FL+FR+FC+BL+BR+BC+SL+SR+TFL+TFC+TFR+TBL+TBC+TBR+WL+WR
--
2.38.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH 3/6] swresample/rematrix: support mixing top front left/right channels
Signed-off-by: James Almer
---
libswresample/rematrix.c | 24
1 file changed, 24 insertions(+)
diff --git a/libswresample/rematrix.c b/libswresample/rematrix.c
index fe823dc575..0c3fff6c42 100644
--- a/libswresample/rematrix.c
+++ b/libswresample/rematrix.c
@@ -138,6 +138,8 @@ static int sane_layout(AVChannelLayout *ch_layout) {
return 0;
if(!even(av_channel_layout_subset(ch_layout, (AV_CH_FRONT_LEFT_OF_CENTER |
AV_CH_FRONT_RIGHT_OF_CENTER
return 0;
+if(!even(av_channel_layout_subset(ch_layout, (AV_CH_TOP_FRONT_LEFT |
AV_CH_TOP_FRONT_RIGHT
+return 0;
if(ch_layout->nb_channels >= SWR_CH_MAX)
return 0;
@@ -369,6 +371,28 @@ av_cold int swr_build_matrix2(const AVChannelLayout
*in_layout, const AVChannelL
}else
av_assert0(0);
}
+
+if (unaccounted & AV_CH_TOP_FRONT_LEFT) {
+if (av_channel_layout_index_from_channel(&out_ch_layout,
AV_CHAN_TOP_FRONT_CENTER) >= 0) {
+matrix[TOP_FRONT_CENTER][TOP_FRONT_LEFT ] += M_SQRT1_2;
+matrix[TOP_FRONT_CENTER][TOP_FRONT_RIGHT] += M_SQRT1_2;
+if (av_channel_layout_index_from_channel(&in_ch_layout,
AV_CHAN_TOP_FRONT_CENTER) >= 0)
+matrix[TOP_FRONT_CENTER][TOP_FRONT_CENTER] = center_mix_level
* sqrt(2);
+} else if (av_channel_layout_index_from_channel(&out_ch_layout,
AV_CHAN_FRONT_LEFT) >= 0) {
+if (av_channel_layout_index_from_channel(&in_ch_layout,
AV_CHAN_FRONT_LEFT) >= 0) {
+matrix[FRONT_LEFT ][TOP_FRONT_LEFT ] += M_SQRT1_2;
+matrix[FRONT_RIGHT][TOP_FRONT_RIGHT] += M_SQRT1_2;
+} else {
+matrix[FRONT_LEFT ][TOP_FRONT_LEFT ] += 1.0;
+matrix[FRONT_RIGHT][TOP_FRONT_RIGHT] += 1.0;
+}
+} else if (av_channel_layout_index_from_channel(&out_ch_layout,
AV_CHAN_FRONT_CENTER) >= 0) {
+matrix[FRONT_CENTER][TOP_FRONT_LEFT ] += M_SQRT1_2;
+matrix[FRONT_CENTER][TOP_FRONT_RIGHT] += M_SQRT1_2;
+} else
+av_assert0(0);
+}
+
/* mix LFE into front left/right or center */
if (unaccounted & AV_CH_LOW_FREQUENCY) {
if (av_channel_layout_index_from_channel(&out_ch_layout,
AV_CHAN_FRONT_CENTER) >= 0) {
--
2.38.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH 4/6 v3] avcodec/aacdec: add support for channel configuration 14
It corresponds to the 7.1(top) layout.
Signed-off-by: James Almer
---
libavcodec/aacdec_template.c | 23 ++-
libavcodec/aacdectab.h | 6 +++---
libavcodec/mpeg4audio.c | 5 +++--
libavcodec/mpeg4audio.h | 2 +-
4 files changed, 29 insertions(+), 7 deletions(-)
diff --git a/libavcodec/aacdec_template.c b/libavcodec/aacdec_template.c
index c10bc743b6..9a85692069 100644
--- a/libavcodec/aacdec_template.c
+++ b/libavcodec/aacdec_template.c
@@ -404,6 +404,21 @@ static uint64_t sniff_channel_order(uint8_t
(*layout_map)[3], int tags)
i++;
}
+// The previous checks would end up at 4 at this point for chan_config 14
+if (layout == AV_CH_LAYOUT_5POINT1_BACK && tags == 5 && i == 4) {
+const uint8_t (*reference_layout_map)[3] = aac_channel_layout_map[13];
+for (int j = 0; j < tags; j++) {
+if (layout_map[j][0] != reference_layout_map[j][0] ||
+layout_map[j][2] != reference_layout_map[j][2])
+goto end_of_layout_definition;
+}
+
+i += assign_pair(e2c_vec, layout_map, i,
+ AV_CH_TOP_FRONT_LEFT,
+ AV_CH_TOP_FRONT_RIGHT,
+ AAC_CHANNEL_FRONT,
+ &layout);
+}
// The previous checks would end up at 8 at this point for 22.2
if (layout == PREFIX_FOR_22POINT2 && tags == 16 && i == 8) {
const uint8_t (*reference_layout_map)[3] = aac_channel_layout_map[12];
@@ -633,7 +648,7 @@ static int set_default_channel_config(AACContext *ac,
AVCodecContext *avctx,
int channel_config)
{
if (channel_config < 1 || (channel_config > 7 && channel_config < 11) ||
-channel_config > 13) {
+channel_config > 14) {
av_log(avctx, AV_LOG_ERROR,
"invalid default channel configuration (%d)\n",
channel_config);
@@ -717,6 +732,12 @@ static ChannelElement *get_che(AACContext *ac, int type,
int elem_id)
/* For indexed channel configurations map the channels solely based
* on position. */
switch (ac->oc[1].m4ac.chan_config) {
+case 14:
+if (ac->tags_mapped > 2 && ((type == TYPE_CPE && elem_id < 3) ||
+(type == TYPE_LFE && elem_id < 1))) {
+ac->tags_mapped++;
+return ac->tag_che_map[type][elem_id] = ac->che[type][elem_id];
+}
case 13:
if (ac->tags_mapped > 3 && ((type == TYPE_CPE && elem_id < 8) ||
(type == TYPE_SCE && elem_id < 6) ||
diff --git a/libavcodec/aacdectab.h b/libavcodec/aacdectab.h
index 327efbcde0..0e5e47da64 100644
--- a/libavcodec/aacdectab.h
+++ b/libavcodec/aacdectab.h
@@ -68,8 +68,8 @@ static const uint8_t aac_channel_layout_map[16][16][3] = {
{ TYPE_SCE, 5, AAC_CHANNEL_FRONT }, // SCE6 = BtFC,
{ TYPE_CPE, 7, AAC_CHANNEL_FRONT }, // CPE8 = BtFL and BtFR
},
+{ { TYPE_SCE, 0, AAC_CHANNEL_FRONT }, { TYPE_CPE, 0, AAC_CHANNEL_FRONT },
{ TYPE_CPE, 1, AAC_CHANNEL_BACK }, { TYPE_LFE, 0, AAC_CHANNEL_LFE }, {
TYPE_CPE, 2, AAC_CHANNEL_FRONT }, },
{ { 0, } },
-/* TODO: Add 7+1 TOP configuration */
};
#if FF_API_OLD_CHANNEL_LAYOUT
@@ -84,8 +84,8 @@ static const uint64_t aac_channel_layout[] = {
AV_CH_LAYOUT_6POINT1_BACK,
AV_CH_LAYOUT_7POINT1,
AV_CH_LAYOUT_22POINT2,
+AV_CH_LAYOUT_7POINT1_TOP_BACK,
0,
-/* AV_CH_LAYOUT_7POINT1_TOP, */
};
#endif
@@ -100,8 +100,8 @@ static const AVChannelLayout aac_ch_layout[] = {
AV_CHANNEL_LAYOUT_6POINT1_BACK,
AV_CHANNEL_LAYOUT_7POINT1,
AV_CHANNEL_LAYOUT_22POINT2,
+AV_CHANNEL_LAYOUT_7POINT1_TOP_BACK,
{ 0 },
-/* AV_CHANNEL_LAYOUT_7POINT1_TOP, */
};
#endif /* AVCODEC_AACDECTAB_H */
diff --git a/libavcodec/mpeg4audio.c b/libavcodec/mpeg4audio.c
index e38a8c0852..fbd2a8f811 100644
--- a/libavcodec/mpeg4audio.c
+++ b/libavcodec/mpeg4audio.c
@@ -56,7 +56,7 @@ static int parse_config_ALS(GetBitContext *gb,
MPEG4AudioConfig *c, void *logctx
return 0;
}
-const uint8_t ff_mpeg4audio_channels[14] = {
+const uint8_t ff_mpeg4audio_channels[15] = {
0,
1, // mono (1/0)
2, // stereo (2/0)
@@ -70,7 +70,8 @@ const uint8_t ff_mpeg4audio_channels[14] = {
0,
7, // 3/3.1
8, // 3/2/2.1
-24 // 3/3/3 - 5/2/3 - 3/0/0.2
+24, // 3/3/3 - 5/2/3 - 3/0/0.2
+8, // 3/2.1 - 2/0
};
static inline int get_object_type(GetBitContext *gb)
diff --git a/libavcodec/mpeg4audio.h b/libavcodec/mpeg4audio.h
index a6f71cff58..56615ef321 100644
--- a/libavcodec/mpeg4audio.h
+++ b/libavcodec/mpeg4audio.h
@@ -42,7 +42,7 @@ typedef struct MPEG4AudioConfig {
} MPEG4AudioConfig;
extern const int ff_mpeg4audio_sample_rates[16];
-extern const uint8_t ff_mpeg4audio_channels[14];
+extern const uint8_t ff_mpeg4audio_channels[15];
/**
* Parse MPEG-4 systems extradata from a potentially unaligned GetBitContext
to re
[FFmpeg-devel] [PATCH 5/6] avcodec/aacdec: don't force a layout when a channel position is unknown
If PCE defines channels not covered by those in the standard configurations
then don't try to come up with some made up layout and just return them in the
coded order.
Fixes al08_44.mp4 from the conformance suite, now reporting and decoding all 48
channels instead of 10.
Signed-off-by: James Almer
---
libavcodec/aacdec_template.c | 27 ++-
1 file changed, 6 insertions(+), 21 deletions(-)
diff --git a/libavcodec/aacdec_template.c b/libavcodec/aacdec_template.c
index 9a85692069..4a88aeae1d 100644
--- a/libavcodec/aacdec_template.c
+++ b/libavcodec/aacdec_template.c
@@ -325,36 +325,19 @@ static uint64_t sniff_channel_order(uint8_t
(*layout_map)[3], int tags)
AAC_CHANNEL_FRONT, &layout);
num_front_channels -= 2;
}
-while (num_front_channels >= 2) {
-i += assign_pair(e2c_vec, layout_map, i,
- UINT64_MAX,
- UINT64_MAX,
- AAC_CHANNEL_FRONT, &layout);
-num_front_channels -= 2;
-}
+if (num_front_channels)
+return 0; // Non standard PCE defined layout
if (num_side_channels >= 2) {
i += assign_pair(e2c_vec, layout_map, i,
AV_CH_SIDE_LEFT,
AV_CH_SIDE_RIGHT,
- AAC_CHANNEL_FRONT, &layout);
-num_side_channels -= 2;
-}
-while (num_side_channels >= 2) {
-i += assign_pair(e2c_vec, layout_map, i,
- UINT64_MAX,
- UINT64_MAX,
AAC_CHANNEL_SIDE, &layout);
num_side_channels -= 2;
}
+if (num_side_channels)
+return 0; // Non standard PCE defined layout
-while (num_back_channels >= 4) {
-i += assign_pair(e2c_vec, layout_map, i,
- UINT64_MAX,
- UINT64_MAX,
- AAC_CHANNEL_BACK, &layout);
-num_back_channels -= 2;
-}
if (num_back_channels >= 2) {
i += assign_pair(e2c_vec, layout_map, i,
AV_CH_BACK_LEFT,
@@ -373,6 +356,8 @@ static uint64_t sniff_channel_order(uint8_t
(*layout_map)[3], int tags)
i++;
num_back_channels--;
}
+if (num_back_channels)
+return 0; // Non standard PCE defined layout
if (i < tags && layout_map[i][2] == AAC_CHANNEL_LFE) {
e2c_vec[i] = (struct elem_to_channel) {
--
2.38.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH 6/6] avcodec/aacdec: refactor the channel layout derivation code
Generalize the checks for channels in all positions, and properly support
the three height groups (normal, top, bottom) instead of manually setting
the relevant channels for the latter two after the normal height tags were
parsed.
Signed-off-by: James Almer
---
libavcodec/aacdec_template.c | 256 ---
libavcodec/aacdectab.h | 27 +++-
2 files changed, 107 insertions(+), 176 deletions(-)
diff --git a/libavcodec/aacdec_template.c b/libavcodec/aacdec_template.c
index 4a88aeae1d..245fd9f6fe 100644
--- a/libavcodec/aacdec_template.c
+++ b/libavcodec/aacdec_template.c
@@ -238,13 +238,13 @@ static int assign_pair(struct elem_to_channel
e2c_vec[MAX_ELEM_ID],
}
static int count_paired_channels(uint8_t (*layout_map)[3], int tags, int pos,
- int *current)
+ int current)
{
int num_pos_channels = 0;
int first_cpe= 0;
int sce_parity = 0;
int i;
-for (i = *current; i < tags; i++) {
+for (i = current; i < tags; i++) {
if (layout_map[i][2] != pos)
break;
if (layout_map[i][0] == TYPE_CPE) {
@@ -259,207 +259,117 @@ static int count_paired_channels(uint8_t
(*layout_map)[3], int tags, int pos,
first_cpe = 1;
} else {
num_pos_channels++;
-sce_parity ^= 1;
+sce_parity ^= (pos != AAC_CHANNEL_LFE);
}
}
if (sce_parity &&
-((pos == AAC_CHANNEL_FRONT && first_cpe) || pos == AAC_CHANNEL_SIDE))
+(pos == AAC_CHANNEL_FRONT && first_cpe))
return -1;
-*current = i;
+
return num_pos_channels;
}
-#define PREFIX_FOR_22POINT2
(AV_CH_LAYOUT_7POINT1_WIDE_BACK|AV_CH_BACK_CENTER|AV_CH_SIDE_LEFT|AV_CH_SIDE_RIGHT|AV_CH_LOW_FREQUENCY_2)
-static uint64_t sniff_channel_order(uint8_t (*layout_map)[3], int tags)
+static int assign_channels(struct elem_to_channel e2c_vec[MAX_ELEM_ID],
uint8_t (*layout_map)[3],
+ uint64_t *layout, int tags, int layer, int pos, int
*current)
{
-int i, n, total_non_cc_elements;
-struct elem_to_channel e2c_vec[4 * MAX_ELEM_ID] = { { 0 } };
-int num_front_channels, num_side_channels, num_back_channels;
-uint64_t layout = 0;
+int i = *current, j = 0;
+int nb_channels = count_paired_channels(layout_map, tags, pos, i);
-if (FF_ARRAY_ELEMS(e2c_vec) < tags)
+if (nb_channels < 0 || nb_channels > 5)
return 0;
-i = 0;
-num_front_channels =
-count_paired_channels(layout_map, tags, AAC_CHANNEL_FRONT, &i);
-if (num_front_channels < 0)
-return 0;
-num_side_channels =
-count_paired_channels(layout_map, tags, AAC_CHANNEL_SIDE, &i);
-if (num_side_channels < 0)
-return 0;
-num_back_channels =
-count_paired_channels(layout_map, tags, AAC_CHANNEL_BACK, &i);
-if (num_back_channels < 0)
-return 0;
+if (pos == AAC_CHANNEL_LFE) {
+while (nb_channels) {
+if (aac_channel_map[layer][pos - 1][j] == AV_CHAN_NONE)
+return -1;
+e2c_vec[i] = (struct elem_to_channel) {
+.av_position = 1ULL << aac_channel_map[layer][pos - 1][j],
+.syn_ele = layout_map[i][0],
+.elem_id = layout_map[i][1],
+.aac_position = pos
+};
+*layout |= e2c_vec[i].av_position;
+i++;
+j++;
+nb_channels--;
+}
+*current = i;
-if (num_side_channels == 0 && num_back_channels >= 4) {
-num_side_channels = 2;
-num_back_channels -= 2;
+return 0;
}
-i = 0;
-if (num_front_channels & 1) {
+while (nb_channels & 1) {
+if (aac_channel_map[layer][pos - 1][0] == AV_CHAN_NONE)
+return -1;
+if (aac_channel_map[layer][pos - 1][0] == AV_CHAN_UNUSED)
+break;
e2c_vec[i] = (struct elem_to_channel) {
-.av_position = AV_CH_FRONT_CENTER,
-.syn_ele = TYPE_SCE,
+.av_position = 1ULL << aac_channel_map[layer][pos - 1][0],
+.syn_ele = layout_map[i][0],
.elem_id = layout_map[i][1],
-.aac_position = AAC_CHANNEL_FRONT
+.aac_position = pos
};
-layout |= e2c_vec[i].av_position;
+*layout |= e2c_vec[i].av_position;
i++;
-num_front_channels--;
+nb_channels--;
}
-if (num_front_channels >= 4) {
-i += assign_pair(e2c_vec, layout_map, i,
- AV_CH_FRONT_LEFT_OF_CENTER,
- AV_CH_FRONT_RIGHT_OF_CENTER,
- AAC_CHANNEL_FRONT, &layout);
-num_front_channels -= 2;
-}
-if (num_front_channels >= 2) {
-i += assign_pair(e2c_vec, layout_map, i,
- AV_CH_FRONT_LEFT,
- AV_CH_FRONT_RIGHT,
-
Re: [FFmpeg-devel] [PATCH] libavcodec/flacenc: Enable sample rates > 655350 Hz
On 10/31/2022 6:33 PM, Martijn van Beurden wrote: > The Xiph spec also says the IETF spec is better, and it remains as > historical reference and overview :) So it does. > The spec as it is on the FLAC website (which is being "preserved") is > wrong. I don't know how this came to be, I think it was at first > poorly worded and later incorrectly fixed. See this commit: > https://github.com/xiph/flac/commit/96534bb5f35eb9c2f6f393dc470625e9c74df1a5 > The text as it was before that commit doesn't make any sense, the text > as it is after the commit is not correct either. Well that's pretty confusing, indeed. > The issue here is that FLAC has a sample rate in the streaminfo > metadata block, at the very start of the file. That one can > accommodate sample rates up to 2^20-1. The frame headers repeat the > sample rate every frame and can only accommodate up to 655350Hz, but > they can also reference the streaminfo metadata block. Because of the > possibility to reference that 20 bit number, it is possible to store > sample rates up to 1048575Hz. You can see this patch only touches the > encoder: the FFmpeg decoder has already been equipped to deal with > this since its inception in 2004. > > There is some kind of limitation to sample rates above 655350Hz, or > samplerates between 65535Hz and 655350Hz that are not a multiple of 10 > though: a FLAC file with such a sample rate cannot be multicast, > because a decoder receiving a multicast stream does not receive the > streaminfo metadata block, and thus cannot use it to figure out the > correct sample rate. > > Please let me know when this explanation falls short. It all makes sense, thanks for the explanation. - Derek ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH v2] avcodec/atrac3plus: reorder channels to match the output layout
James Almer:
> The order in which the channels are coded in the bitstream do not always
> follow
> the native, bitmask-based order of channels both signaled by the WAV container
> and forced by this same decoder. This is the case with layouts containing an
> LFE channel, as it's always coded last.
>
> Fixes ticket #9964.
>
> Signed-off-by: James Almer
> ---
> libavcodec/atrac3plusdec.c | 13 -
> 1 file changed, 12 insertions(+), 1 deletion(-)
>
> diff --git a/libavcodec/atrac3plusdec.c b/libavcodec/atrac3plusdec.c
> index ee71645a3c..9e12f21930 100644
> --- a/libavcodec/atrac3plusdec.c
> +++ b/libavcodec/atrac3plusdec.c
> @@ -48,6 +48,17 @@
> #include "atrac.h"
> #include "atrac3plus.h"
>
> +static uint8_t channel_map[8][8] = {
> +{ 0, },
> +{ 0, 1, },
> +{ 0, 1, 2, },
> +{ 0, 1, 2, 3, },
> +{ 0, },
> +{ 0, 1, 2, 4, 5, 3, },
> +{ 0, 1, 2, 4, 5, 8, 3, },
> +{ 0, 1, 2, 4, 5, 9, 10, 3, },
> +};
> +
> typedef struct ATRAC3PContext {
> GetBitContext gb;
> AVFloatDSPContext *fdsp;
> @@ -378,7 +389,7 @@ static int atrac3p_decode_frame(AVCodecContext *avctx,
> AVFrame *frame,
>channels_to_process, avctx);
>
> for (i = 0; i < channels_to_process; i++)
> -memcpy(samples_p[out_ch_index + i], ctx->outp_buf[i],
> +memcpy(samples_p[channel_map[frame->ch_layout.nb_channels -
> 1][out_ch_index + i]], ctx->outp_buf[i],
> ATRAC3P_FRAME_SAMPLES * sizeof(**samples_p));
>
> ch_block++;
Looking at the last two entries, it seems to me that you simply used the
numerical values of the AV_CHAN_* constants, i.e. as if you wanted to
write { AV_CHAN_FRONT_LEFT, AV_CHAN_FRONT_RIGHT, AV_CHAN_FRONT_CENTER,
AV_CHAN_BACK_LEFT, AV_CHAN_BACK_RIGHT, AV_CHAN_SIDE_LEFT,
AV_CHAN_SIDE_RIGHT, AV_CHAN_LOW_FREQUENCY } for the last entry. This is
wrong, as it conflates the enum AVChannel domain with the index domain;
it will segfault for 6.1 and 7.1, because there are no data planes with
indices 8, 9 and 10 in the output frame.
The array for 6.1 is { 0, 1, 2, 4, 5, 6, 3 }, for 7.1 it is { 0, 1, 2,
4, 5, 6, 7, 3, } (presuming that your first patch was right). The
derivation for 6.1 is as follows: The first channel in atrac is FL,
which is also the first channel in AV_CHANNEL_LAYOUT_6POINT1_BACK. So
the first entry is 0; the next channel is FR which is the second channel
in AV_CHANNEL_LAYOUT_6POINT1_BACK, so the second entry is 1. The next
atrac entry is FC, which is also the next entry in
AV_CHANNEL_LAYOUT_6POINT1_BACK, so the next entry is 2. The next atrac
entry is BL, which is not the next channel in
AV_CHANNEL_LAYOUT_6POINT1_BACK (which is lfe), but the one after that.
So the next entry is four. Similarly, the next entry is five. The atrac
entry after that is BC, which is the next (and last) entry of
AV_CHANNEL_LAYOUT_6POINT1_BACK and has index six. It doesn't matter for
this that there are several channels in enum AVChannel between BR and
BC, as these channels are not present in AV_CHANNEL_LAYOUT_6POINT1_BACK
(it would also not matter if there were any gaps in the values of the
AV_CHAN_* constants in between). The next (and last) atrac entry is LFE,
which is the fourth channel in AV_CHANNEL_LAYOUT_6POINT1_BACK and
therefore has index 3.
Is it really absolutely guaranteed that atrac only has one channel
layout per channel count? It seems to me that adding a const uint8_t
*channel_map to the context that gets set like ctx->channel_map = (const
uint8_t[]){ 0, 1, 2, 4, 5, 6, 3 } (for 6.1) would be simpler.
- 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 v2] avcodec/atrac3plus: reorder channels to match the output layout
On 10/31/2022 7:13 PM, Andreas Rheinhardt wrote:
James Almer:
The order in which the channels are coded in the bitstream do not always follow
the native, bitmask-based order of channels both signaled by the WAV container
and forced by this same decoder. This is the case with layouts containing an
LFE channel, as it's always coded last.
Fixes ticket #9964.
Signed-off-by: James Almer
---
libavcodec/atrac3plusdec.c | 13 -
1 file changed, 12 insertions(+), 1 deletion(-)
diff --git a/libavcodec/atrac3plusdec.c b/libavcodec/atrac3plusdec.c
index ee71645a3c..9e12f21930 100644
--- a/libavcodec/atrac3plusdec.c
+++ b/libavcodec/atrac3plusdec.c
@@ -48,6 +48,17 @@
#include "atrac.h"
#include "atrac3plus.h"
+static uint8_t channel_map[8][8] = {
+{ 0, },
+{ 0, 1, },
+{ 0, 1, 2, },
+{ 0, 1, 2, 3, },
+{ 0, },
+{ 0, 1, 2, 4, 5, 3, },
+{ 0, 1, 2, 4, 5, 8, 3, },
+{ 0, 1, 2, 4, 5, 9, 10, 3, },
+};
+
typedef struct ATRAC3PContext {
GetBitContext gb;
AVFloatDSPContext *fdsp;
@@ -378,7 +389,7 @@ static int atrac3p_decode_frame(AVCodecContext *avctx,
AVFrame *frame,
channels_to_process, avctx);
for (i = 0; i < channels_to_process; i++)
-memcpy(samples_p[out_ch_index + i], ctx->outp_buf[i],
+memcpy(samples_p[channel_map[frame->ch_layout.nb_channels -
1][out_ch_index + i]], ctx->outp_buf[i],
ATRAC3P_FRAME_SAMPLES * sizeof(**samples_p));
ch_block++;
Looking at the last two entries, it seems to me that you simply used the
numerical values of the AV_CHAN_* constants, i.e. as if you wanted to
write { AV_CHAN_FRONT_LEFT, AV_CHAN_FRONT_RIGHT, AV_CHAN_FRONT_CENTER,
AV_CHAN_BACK_LEFT, AV_CHAN_BACK_RIGHT, AV_CHAN_SIDE_LEFT,
AV_CHAN_SIDE_RIGHT, AV_CHAN_LOW_FREQUENCY } for the last entry. This is
wrong, as it conflates the enum AVChannel domain with the index domain;
it will segfault for 6.1 and 7.1, because there are no data planes with
indices 8, 9 and 10 in the output frame.
Yeah, i mixed ids and indexes. Will fix.
The array for 6.1 is { 0, 1, 2, 4, 5, 6, 3 }, for 7.1 it is { 0, 1, 2,
4, 5, 6, 7, 3, } (presuming that your first patch was right). The
derivation for 6.1 is as follows: The first channel in atrac is FL,
which is also the first channel in AV_CHANNEL_LAYOUT_6POINT1_BACK. So
the first entry is 0; the next channel is FR which is the second channel
in AV_CHANNEL_LAYOUT_6POINT1_BACK, so the second entry is 1. The next
atrac entry is FC, which is also the next entry in
AV_CHANNEL_LAYOUT_6POINT1_BACK, so the next entry is 2. The next atrac
entry is BL, which is not the next channel in
AV_CHANNEL_LAYOUT_6POINT1_BACK (which is lfe), but the one after that.
So the next entry is four. Similarly, the next entry is five. The atrac
entry after that is BC, which is the next (and last) entry of
AV_CHANNEL_LAYOUT_6POINT1_BACK and has index six. It doesn't matter for
this that there are several channels in enum AVChannel between BR and
BC, as these channels are not present in AV_CHANNEL_LAYOUT_6POINT1_BACK
(it would also not matter if there were any gaps in the values of the
AV_CHAN_* constants in between). The next (and last) atrac entry is LFE,
which is the fourth channel in AV_CHANNEL_LAYOUT_6POINT1_BACK and
therefore has index 3.
Is it really absolutely guaranteed that atrac only has one channel
layout per channel count? It seems to me that adding a const uint8_t
*channel_map to the context that gets set like ctx->channel_map = (const
uint8_t[]){ 0, 1, 2, 4, 5, 6, 3 } (for 6.1) would be simpler.
I don't know if it's guaranteed, but that's what this decoder assumes
directly during init with user set values (so nothing read from the
bitstream for it), so I'll not assume the opposite.
- 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 mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH v2] avcodec/atrac3plus: reorder channels to match the output layout
On 10/31/2022 7:13 PM, Andreas Rheinhardt wrote:
James Almer:
The order in which the channels are coded in the bitstream do not always follow
the native, bitmask-based order of channels both signaled by the WAV container
and forced by this same decoder. This is the case with layouts containing an
LFE channel, as it's always coded last.
Fixes ticket #9964.
Signed-off-by: James Almer
---
libavcodec/atrac3plusdec.c | 13 -
1 file changed, 12 insertions(+), 1 deletion(-)
diff --git a/libavcodec/atrac3plusdec.c b/libavcodec/atrac3plusdec.c
index ee71645a3c..9e12f21930 100644
--- a/libavcodec/atrac3plusdec.c
+++ b/libavcodec/atrac3plusdec.c
@@ -48,6 +48,17 @@
#include "atrac.h"
#include "atrac3plus.h"
+static uint8_t channel_map[8][8] = {
+{ 0, },
+{ 0, 1, },
+{ 0, 1, 2, },
+{ 0, 1, 2, 3, },
+{ 0, },
+{ 0, 1, 2, 4, 5, 3, },
+{ 0, 1, 2, 4, 5, 8, 3, },
+{ 0, 1, 2, 4, 5, 9, 10, 3, },
+};
+
typedef struct ATRAC3PContext {
GetBitContext gb;
AVFloatDSPContext *fdsp;
@@ -378,7 +389,7 @@ static int atrac3p_decode_frame(AVCodecContext *avctx,
AVFrame *frame,
channels_to_process, avctx);
for (i = 0; i < channels_to_process; i++)
-memcpy(samples_p[out_ch_index + i], ctx->outp_buf[i],
+memcpy(samples_p[channel_map[frame->ch_layout.nb_channels -
1][out_ch_index + i]], ctx->outp_buf[i],
ATRAC3P_FRAME_SAMPLES * sizeof(**samples_p));
ch_block++;
Looking at the last two entries, it seems to me that you simply used the
numerical values of the AV_CHAN_* constants, i.e. as if you wanted to
write { AV_CHAN_FRONT_LEFT, AV_CHAN_FRONT_RIGHT, AV_CHAN_FRONT_CENTER,
AV_CHAN_BACK_LEFT, AV_CHAN_BACK_RIGHT, AV_CHAN_SIDE_LEFT,
AV_CHAN_SIDE_RIGHT, AV_CHAN_LOW_FREQUENCY } for the last entry. This is
wrong, as it conflates the enum AVChannel domain with the index domain;
it will segfault for 6.1 and 7.1, because there are no data planes with
indices 8, 9 and 10 in the output frame.
The array for 6.1 is { 0, 1, 2, 4, 5, 6, 3 }, for 7.1 it is { 0, 1, 2,
4, 5, 6, 7, 3, } (presuming that your first patch was right). The
derivation for 6.1 is as follows: The first channel in atrac is FL,
which is also the first channel in AV_CHANNEL_LAYOUT_6POINT1_BACK. So
the first entry is 0; the next channel is FR which is the second channel
in AV_CHANNEL_LAYOUT_6POINT1_BACK, so the second entry is 1. The next
atrac entry is FC, which is also the next entry in
AV_CHANNEL_LAYOUT_6POINT1_BACK, so the next entry is 2. The next atrac
entry is BL, which is not the next channel in
AV_CHANNEL_LAYOUT_6POINT1_BACK (which is lfe), but the one after that.
So the next entry is four. Similarly, the next entry is five. The atrac
entry after that is BC, which is the next (and last) entry of
AV_CHANNEL_LAYOUT_6POINT1_BACK and has index six. It doesn't matter for
this that there are several channels in enum AVChannel between BR and
BC, as these channels are not present in AV_CHANNEL_LAYOUT_6POINT1_BACK
(it would also not matter if there were any gaps in the values of the
AV_CHAN_* constants in between). The next (and last) atrac entry is LFE,
which is the fourth channel in AV_CHANNEL_LAYOUT_6POINT1_BACK and
therefore has index 3.
Is it really absolutely guaranteed that atrac only has one channel
layout per channel count? It seems to me that adding a const uint8_t
*channel_map to the context that gets set like ctx->channel_map = (const
uint8_t[]){ 0, 1, 2, 4, 5, 6, 3 } (for 6.1) would be simpler.
Unless i'm missing something, this would be local to set_channel_params().
- 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 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] Revert "avfilter/vf_palette(gen|use): support palettes with alpha"
> -Original Message- > From: ffmpeg-devel On Behalf Of > Michael Niedermayer > Sent: Monday, October 31, 2022 10:59 PM > To: FFmpeg development discussions and patches de...@ffmpeg.org> > Subject: Re: [FFmpeg-devel] [PATCH] Revert > "avfilter/vf_palette(gen|use): support palettes with alpha" > > On Mon, Oct 31, 2022 at 11:57:16AM +0100, Clément Bœsch wrote: > > On Mon, Oct 31, 2022 at 01:43:11AM +, Soft Works wrote: > > [...] > > > > > > The patch I had submitted doesn't change the previous > behavior > > > > > > without the use_alpha parameter. > > > > > > > > Yes I noticed, but unfortunately I'm reworking the color > distance to > > > > work > > > > in perceptual color space, and the way that alpha is mixed up > in the > > > > equation just doesn't make any sense at all and prevents me > from > > > > doing > > > > these changes. > > > > > > If you want to implement a new color distance algorithm, it > should > > > be either a new filter or a new (switchable) mode for the > existing > > > filter. > > > > Why? > > > > > Photoshop has these different modes as well and it would > > > surely be useful, but I don't think it should be replacing the > > > existing behavior. > > > > > > > There is no point in keeping a ton of complexity exposed as user > options > > for something implementation specific. We offer no guarantee over > how the > > quantization is expected to run. > > > > > When it turns out that the use_alpha implementation doesn't fit > > > with your new color distance calculation and you add it as > > > an additional mode, then it would be fine IMO when the filter > > > errors in case it would be attempted to use that mode in > > > combination with use_alpha. > > > > IMO The use_alpha option shouldn't exist in the first place, it > should be > > the default behaviour because honoring the alpha is the correct > thing to > > do. That's not what the option is currently doing though. > > > > > > > Do you think it might make sense to put more weight on the > > > > > alpha value by tripling it? So it would be weighted equally > to the > > > > > RGB value? > > > > > > > > You cannot mix alpha with colors at all, they are separate > domains > > > > and you > > > > need to treat them as such. > > > > > > What's interesting is that I've followed the same (simplified) > > > way for adding a use_alpha option to vf_elbg and it provides > excellent > > > results without treating alpha separately. > > > > I don't know how the filter works and what it's supposed to do, but > if > > it's indeed using the same approach as the palette ones, it cannot > work. > > > > > > From paletteuse perspective what you need to do is first choose > the > > > > colors > > > > in the palette that match exactly the alpha (or at least the > closest > > > > if > > > > and only there is no exact match). Then within that set, and > only > > > > within > > > > that one, you'd pick the closest color. > > > > > > > > From palettegen perspective, you need to split the colors in > > > > different > > > > transparency domain (a first dimensional quantization), then > quantize > > > > the > > > > colors in each quantized alpha dimension. And when you have all > your > > > > quantized palettes for each level of alpha, you find an > algorithm to > > > > reduce the number of transparency dimensions or the number of > colors > > > > per > > > > dimension to make it fit inside a single palette. But you can't > just > > > > do > > > > the alpha and the colors at the same time, it cannot work, > whatever > > > > weights you choose. > > > > > > I would be curious to see how well that would work, especially > > > in cases when the target palettes have just a few number of > colors. > > > > > > > You have to make a call between whether you want to preserve the > > transparency or the color while constructing the palette, but when > > choosing a color you must absolutely not choose a color with a > different > > transparency, you must pick amongst the closest alpha, with a > particular > > attention to extreme alphas: an opaque colors must stay opaque, and > fully > > transparent one as well: > > - rounding a color with 43% alpha into 50% alpha is acceptable > > - rounding a color with 100% alpha into a 99% alpha is not > acceptable in > > any way because you're starting to make transparent areas that > weren't > > - rounding a color with 0% alpha into a 1% alpha is not acceptable > because > > some areas of the images are not starting to blend into an area > that was > > supposedly non-existent > > really ? > so if i have all shades of green available for all transparencies > from 1% to 99% > i "must" make my plants all use 0% trasparency even if i only have a > single color and > that is bright pink > I dont think that is the best choice > > There are perceptual differences between the different areas of the > RGBA hypercube > though. Hardly anyone would notice the difference between a 255 and > 254 blue but > having some sligh
Re: [FFmpeg-devel] [PATCH v2] avcodec/atrac3plus: reorder channels to match the output layout
James Almer:
> On 10/31/2022 7:13 PM, Andreas Rheinhardt wrote:
>> James Almer:
>>> The order in which the channels are coded in the bitstream do not
>>> always follow
>>> the native, bitmask-based order of channels both signaled by the WAV
>>> container
>>> and forced by this same decoder. This is the case with layouts
>>> containing an
>>> LFE channel, as it's always coded last.
>>>
>>> Fixes ticket #9964.
>>>
>>> Signed-off-by: James Almer
>>> ---
>>> libavcodec/atrac3plusdec.c | 13 -
>>> 1 file changed, 12 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/libavcodec/atrac3plusdec.c b/libavcodec/atrac3plusdec.c
>>> index ee71645a3c..9e12f21930 100644
>>> --- a/libavcodec/atrac3plusdec.c
>>> +++ b/libavcodec/atrac3plusdec.c
>>> @@ -48,6 +48,17 @@
>>> #include "atrac.h"
>>> #include "atrac3plus.h"
>>> +static uint8_t channel_map[8][8] = {
>>> + { 0, },
>>> + { 0, 1, },
>>> + { 0, 1, 2, },
>>> + { 0, 1, 2, 3, },
>>> + { 0, },
>>> + { 0, 1, 2, 4, 5, 3, },
>>> + { 0, 1, 2, 4, 5, 8, 3, },
>>> + { 0, 1, 2, 4, 5, 9, 10, 3, },
>>> +};
>>> +
>>> typedef struct ATRAC3PContext {
>>> GetBitContext gb;
>>> AVFloatDSPContext *fdsp;
>>> @@ -378,7 +389,7 @@ static int atrac3p_decode_frame(AVCodecContext
>>> *avctx, AVFrame *frame,
>>> channels_to_process, avctx);
>>> for (i = 0; i < channels_to_process; i++)
>>> - memcpy(samples_p[out_ch_index + i], ctx->outp_buf[i],
>>> +
>>> memcpy(samples_p[channel_map[frame->ch_layout.nb_channels -
>>> 1][out_ch_index + i]], ctx->outp_buf[i],
>>> ATRAC3P_FRAME_SAMPLES * sizeof(**samples_p));
>>> ch_block++;
>>
>> Looking at the last two entries, it seems to me that you simply used the
>> numerical values of the AV_CHAN_* constants, i.e. as if you wanted to
>> write { AV_CHAN_FRONT_LEFT, AV_CHAN_FRONT_RIGHT, AV_CHAN_FRONT_CENTER,
>> AV_CHAN_BACK_LEFT, AV_CHAN_BACK_RIGHT, AV_CHAN_SIDE_LEFT,
>> AV_CHAN_SIDE_RIGHT, AV_CHAN_LOW_FREQUENCY } for the last entry. This is
>> wrong, as it conflates the enum AVChannel domain with the index domain;
>> it will segfault for 6.1 and 7.1, because there are no data planes with
>> indices 8, 9 and 10 in the output frame.
>>
>> The array for 6.1 is { 0, 1, 2, 4, 5, 6, 3 }, for 7.1 it is { 0, 1, 2,
>> 4, 5, 6, 7, 3, } (presuming that your first patch was right). The
>> derivation for 6.1 is as follows: The first channel in atrac is FL,
>> which is also the first channel in AV_CHANNEL_LAYOUT_6POINT1_BACK. So
>> the first entry is 0; the next channel is FR which is the second channel
>> in AV_CHANNEL_LAYOUT_6POINT1_BACK, so the second entry is 1. The next
>> atrac entry is FC, which is also the next entry in
>> AV_CHANNEL_LAYOUT_6POINT1_BACK, so the next entry is 2. The next atrac
>> entry is BL, which is not the next channel in
>> AV_CHANNEL_LAYOUT_6POINT1_BACK (which is lfe), but the one after that.
>> So the next entry is four. Similarly, the next entry is five. The atrac
>> entry after that is BC, which is the next (and last) entry of
>> AV_CHANNEL_LAYOUT_6POINT1_BACK and has index six. It doesn't matter for
>> this that there are several channels in enum AVChannel between BR and
>> BC, as these channels are not present in AV_CHANNEL_LAYOUT_6POINT1_BACK
>> (it would also not matter if there were any gaps in the values of the
>> AV_CHAN_* constants in between). The next (and last) atrac entry is LFE,
>> which is the fourth channel in AV_CHANNEL_LAYOUT_6POINT1_BACK and
>> therefore has index 3.
>>
>> Is it really absolutely guaranteed that atrac only has one channel
>> layout per channel count? It seems to me that adding a const uint8_t
>> *channel_map to the context that gets set like ctx->channel_map = (const
>> uint8_t[]){ 0, 1, 2, 4, 5, 6, 3 } (for 6.1) would be simpler.
>
> Unless i'm missing something, this would be local to set_channel_params().
>
Correct.
- 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] avcodec/atrac3plus: reorder channels to match the output layout
The order in which the channels are coded in the bitstream do not always follow
the native, bitmask-based order of channels both signaled by the WAV container
and forced by this same decoder. This is the case with layouts containing an
LFE channel, as it's always coded last.
Fixes ticket #9964.
Signed-off-by: James Almer
---
libavcodec/atrac3plusdec.c | 16 +++-
1 file changed, 15 insertions(+), 1 deletion(-)
diff --git a/libavcodec/atrac3plusdec.c b/libavcodec/atrac3plusdec.c
index ee71645a3c..2bc023cb23 100644
--- a/libavcodec/atrac3plusdec.c
+++ b/libavcodec/atrac3plusdec.c
@@ -48,6 +48,17 @@
#include "atrac.h"
#include "atrac3plus.h"
+static const uint8_t channel_map[8][8] = {
+{ 0, },
+{ 0, 1, },
+{ 0, 1, 2, },
+{ 0, 1, 2, 3, },
+{ 0, },
+{ 0, 1, 2, 4, 5, 3, },
+{ 0, 1, 2, 4, 5, 6, 3, },
+{ 0, 1, 2, 4, 5, 6, 7, 3, },
+};
+
typedef struct ATRAC3PContext {
GetBitContext gb;
AVFloatDSPContext *fdsp;
@@ -65,6 +76,7 @@ typedef struct ATRAC3PContext {
int num_channel_blocks; ///< number of channel blocks
uint8_t channel_blocks[5]; ///< channel configuration descriptor
+const uint8_t *channel_map; ///< channel layout map
} ATRAC3PContext;
static av_cold int atrac3p_decode_close(AVCodecContext *avctx)
@@ -143,6 +155,8 @@ static av_cold int set_channel_params(ATRAC3PContext *ctx,
return AVERROR_INVALIDDATA;
}
+ctx->channel_map = channel_map[channels - 1];
+
return 0;
}
@@ -378,7 +392,7 @@ static int atrac3p_decode_frame(AVCodecContext *avctx,
AVFrame *frame,
channels_to_process, avctx);
for (i = 0; i < channels_to_process; i++)
-memcpy(samples_p[out_ch_index + i], ctx->outp_buf[i],
+memcpy(samples_p[ctx->channel_map[out_ch_index + i]],
ctx->outp_buf[i],
ATRAC3P_FRAME_SAMPLES * sizeof(**samples_p));
ch_block++;
--
2.38.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] avcodec/av1: fixed an vaapi decoding corruption issue
On Mon, 2022-10-31 at 11:46 -0400, Ruijing Dong wrote:
The title should be "avcodec/av1_vaapi: ".
> [problem]
> When decoding an av1 bitstream, it shows image corruption
> in the middle of the bitstream around key frames.
>
> [analysis]
> In av1_spec.pdf page 38/669, there is a sentence below:
>
> if ( frame_type == KEY_FRAME && show_frame ) {
> for ( i = 0; i < NUM_REF_FRAMES; i++) {
>RefValid[ i ] = 0
>..
> }
> ..
> }
>
> This shows that the condition of invalidating current
> DPB frames should be the coming frame_type is KEY_FRAME plus
> show_frame is equal to 1. Otherwise, some of the frames
> in sequence after KEY_FRAME still refer to the reference frames
> before KEY_FRAME, and if these before KEY_FRAME reference
> frames were invalidated, these frames could not find their
> reference frames, and it could cause image corruption.
[problem] and [solution] part and title "[analysis]" can be removed in
the commit message. Content after [analysis] is clear enough.
Thanks
Fei
>
> [solution]
> Add show_frame flag as another condition to co-determine
> when to invalidate DPB reference frames.
>
> Mesa fix is in
> https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/19386
>
> cc: Fei Wang
> Signed-off-by: Ruijing Dong
> ---
> libavcodec/vaapi_av1.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/libavcodec/vaapi_av1.c b/libavcodec/vaapi_av1.c
> index 63374c31c9..d0339b2705 100644
> --- a/libavcodec/vaapi_av1.c
> +++ b/libavcodec/vaapi_av1.c
> @@ -274,7 +274,7 @@ static int vaapi_av1_start_frame(AVCodecContext
> *avctx,
> };
>
> for (int i = 0; i < AV1_NUM_REF_FRAMES; i++) {
> -if (pic_param.pic_info_fields.bits.frame_type ==
> AV1_FRAME_KEY)
> +if (pic_param.pic_info_fields.bits.frame_type ==
> AV1_FRAME_KEY && frame_header->show_frame)
> pic_param.ref_frame_map[i] = VA_INVALID_ID;
> else
> pic_param.ref_frame_map[i] = ctx->ref_tab[i].valid ?
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [RFC]lavc/tiff: Support dng cropping
Am Mo., 31. Okt. 2022 um 13:39 Uhr schrieb Anton Khirnov :
>
> Quoting Carl Eugen Hoyos (2022-10-23 20:46:57)
> > Am So., 23. Okt. 2022 um 16:35 Uhr schrieb Carl Eugen Hoyos
> > :
> > >
> > > Hi!
> > >
> > > I tried to implement dng cropping, it unfortunately can only work with
> > > -flags +unaligned, is there an alternative to simply print a warning
> > > if the flag was not supplied?
> >
> > New patch with more parentheses attached.
> >
> > Please comment, Carl Eugen
> >
> > From 1bfe065564604659b7703e75b1bb750c031fdc81 Mon Sep 17 00:00:00 2001
> > From: Carl Eugen Hoyos
> > Date: Sun, 23 Oct 2022 16:31:53 +0200
> > Subject: [PATCH] lavc/tiff: Support dng cropping,
>
> A FATE test would be nice.
The samples are big but will look into this once the patch is ok.
> > needs -flags +unaligned
>
> AFAICT this is not entirely correct. Applying left cropping in
> libavcodec might need AV_CODEC_FLAG_UNALIGNED, but not always.
Of course, but evidence indicates that in nearly all cases, it is needed.
> Users may also set apply_cropping=0 and apply cropping themselves.
It should be possible to check this.
> The decoder should not care about it in any case, since it's handled in
> the generic code.
Could you elaborate?
The reason I added this check (and I would love to see that it is not
necessary) is that there is no (working) generic code afaict and that
decoding just breaks without a useful hint if the check is removed.
> > Fixes samples mentioned in ticket #4364.
> > ---
> > libavcodec/tiff.c | 83 +++
> > libavcodec/tiff.h | 3 ++
> > 2 files changed, 86 insertions(+)
> >
> > diff --git a/libavcodec/tiff.c b/libavcodec/tiff.c
> > index fd9db18c0b..33edff8213 100644
> > --- a/libavcodec/tiff.c
> > +++ b/libavcodec/tiff.c
> > @@ -1492,6 +1492,89 @@ static int tiff_decode_tag(TiffContext *s, AVFrame
> > *frame)
> > case DNG_WHITE_LEVEL:
> > s->white_level = value;
> > break;
> > +case DNG_CROP_ORIGIN:
> > +if (count != 2 || type != TIFF_SHORT && type != TIFF_LONG && type
> > != TIFF_RATIONAL) {
>
> This condition could definitely use more parentheses. Same in two checks
> below.
Sorry, I disagree.
> > +av_log(s->avctx, AV_LOG_WARNING, "Invalid crop origin (count:
> > %d, type: %d)\n", count, type);
> > +break;
> > +}
> > +if (type == TIFF_RATIONAL) {
> > +unsigned denum1, denum2;
> > +value = ff_tget(&s->gb, TIFF_LONG, s->le);
> > +denum1 = ff_tget(&s->gb, TIFF_LONG, s->le);
> > +value2 = ff_tget(&s->gb, TIFF_LONG, s->le);
> > +denum2 = ff_tget(&s->gb, TIFF_LONG, s->le);
> > +if (denum1 != 1 || denum2 != 1) {
> > +av_log(s->avctx, AV_LOG_WARNING, "Unsupported crop
> > origin\n");
> > +break;
> > +}
> > +} else {
> > +value = ff_tget(&s->gb, type, s->le);
> > +value2 = ff_tget(&s->gb, type, s->le);
> > +}
>
> This entire block is duplicated for DNG_CROP_ORIGIN and DNG_CROP_SIZE,
> you could split it into a function.
Will do, but I expect this to look ugly.
> > +av_log(s->avctx, AV_LOG_DEBUG, "dng crop origin: %d/%d\n", value,
> > value2);
> > +if (value >= s->width || value2 >= s->height) {
> > +av_log(s->avctx, AV_LOG_WARNING, "Invalid crop origin
> > (%d/%d)\n", value, value2);
> > +break;
> > +}
> > +if ((value || value2) && !(s->avctx->flags &
> > AV_CODEC_FLAG_UNALIGNED)) {
> > +av_log(s->avctx, AV_LOG_WARNING,"Correct DNG cropping needs
> > -flags +unaligned\n");
> > +} else {
> > +frame->crop_left = value;
> > +frame->crop_top = value2;
> > +}
> > +break;
> > +case DNG_CROP_SIZE:
> > +if (count != 2 || type != TIFF_SHORT && type != TIFF_LONG && type
> > != TIFF_RATIONAL) {
> > +av_log(s->avctx, AV_LOG_WARNING, "Invalid crop size (count:
> > %d, type: %d)\n", count, type);
> > +break;
> > +}
> > +if (type == TIFF_RATIONAL) {
> > +unsigned denum1, denum2;
> > +value = ff_tget(&s->gb, TIFF_LONG, s->le);
> > +denum1 = ff_tget(&s->gb, TIFF_LONG, s->le);
> > +value2 = ff_tget(&s->gb, TIFF_LONG, s->le);
> > +denum2 = ff_tget(&s->gb, TIFF_LONG, s->le);
> > +if (denum1 != 1 || denum2 != 1) {
> > +av_log(s->avctx, AV_LOG_WARNING, "Unsupported crop
> > size\n");
> > +break;
> > +}
> > +} else {
> > +value = ff_tget(&s->gb, type, s->le);
> > +value2 = ff_tget(&s->gb, type, s->le);
> > +}
> > +av_log(s->avctx, AV_LOG_DEBUG, "dng crop size %d x %d\n", value,
> > value2);
> > +if (value + frame->crop_left >= s->width || value2 +
> > frame->crop_top >= s->height) {
>
> value/value2 can be
[FFmpeg-devel] [PATCH] avcodec/av1_vaapi: fixed a decoding corruption issue
v2: update commit message
In av1_spec.pdf page 38/669, there is a sentence below:
if ( frame_type == KEY_FRAME && show_frame ) {
for ( i = 0; i < NUM_REF_FRAMES; i++) {
RefValid[ i ] = 0
..
}
..
}
This shows that the condition of invalidating current
DPB frames should be the coming frame_type is KEY_FRAME plus
show_frame is equal to 1. Otherwise, some of the frames
in sequence after KEY_FRAME still refer to the reference frames
before KEY_FRAME, and if these before KEY_FRAME reference
frames were invalidated, these frames could not find their
reference frames, and it could cause image corruption.
Mesa fix is in https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/19386
cc: Fei Wang
Signed-off-by: Ruijing Dong
---
libavcodec/vaapi_av1.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavcodec/vaapi_av1.c b/libavcodec/vaapi_av1.c
index 63374c31c9..d0339b2705 100644
--- a/libavcodec/vaapi_av1.c
+++ b/libavcodec/vaapi_av1.c
@@ -274,7 +274,7 @@ static int vaapi_av1_start_frame(AVCodecContext *avctx,
};
for (int i = 0; i < AV1_NUM_REF_FRAMES; i++) {
-if (pic_param.pic_info_fields.bits.frame_type == AV1_FRAME_KEY)
+if (pic_param.pic_info_fields.bits.frame_type == AV1_FRAME_KEY &&
frame_header->show_frame)
pic_param.ref_frame_map[i] = VA_INVALID_ID;
else
pic_param.ref_frame_map[i] = ctx->ref_tab[i].valid ?
--
2.25.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH v2] avcodec/tiff: add read support for compressed rgb floating point formats
On Thu, Oct 20, 2022 at 9:49 AM Mark Reid wrote: > > On Sun, Oct 2, 2022 at 10:18 AM James Almer wrote: > >> On 10/2/2022 2:06 PM, Michael Niedermayer wrote: >> > On Sat, Oct 01, 2022 at 04:05:12PM -0700, mindm...@gmail.com wrote: >> >> From: Mark Reid >> >> >> >> floating point uses a slightly different predictor technique describe >> here >> >> http://chriscox.org/TIFFTN3d1.pdf >> >> >> > >> >> Here is a link the test files, if someone could add them to fate me >> >> https://www.dropbox.com/s/fg59h2os4gb4wug/tiff_fate_samples.zip >> > >> > ccing samples-requ...@ffmpeg.org, for sample upload req >> > >> > thx >> >> Done. >> > > ping > ping ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 2/2] avcodec/vpp_qsv: Copy side data from input to output frame
On Mon, 2022-10-24 at 23:04 +, softworkz wrote:
> From: softworkz
>
> Signed-off-by: softworkz
> ---
> libavfilter/qsvvpp.c | 6 ++
> libavfilter/vf_overlay_qsv.c | 19 +++
> 2 files changed, 21 insertions(+), 4 deletions(-)
>
> diff --git a/libavfilter/qsvvpp.c b/libavfilter/qsvvpp.c
> index 8428ee89ab..ae9766d12f 100644
> --- a/libavfilter/qsvvpp.c
> +++ b/libavfilter/qsvvpp.c
> @@ -880,6 +880,12 @@ int ff_qsvvpp_filter_frame(QSVVPPContext *s, AVFilterLink
> *inlink, AVFrame *picr
> return AVERROR(EAGAIN);
> break;
> }
> +
> +av_frame_remove_all_side_data(out_frame->frame);
> +ret = av_frame_copy_side_data(out_frame->frame, in_frame->frame, 0);
> +if (ret < 0)
> +return ret;
> +
> out_frame->frame->pts = av_rescale_q(out_frame-
> >surface.Data.TimeStamp,
> default_tb, outlink->time_base);
>
> diff --git a/libavfilter/vf_overlay_qsv.c b/libavfilter/vf_overlay_qsv.c
> index d947a1faa1..04fd284b92 100644
> --- a/libavfilter/vf_overlay_qsv.c
> +++ b/libavfilter/vf_overlay_qsv.c
> @@ -231,13 +231,24 @@ static int process_frame(FFFrameSync *fs)
> {
> AVFilterContext *ctx = fs->parent;
> QSVOverlayContext *s = fs->opaque;
> +AVFrame *frame0 = NULL;
> AVFrame*frame = NULL;
> -int ret = 0, i;
> +int ret = 0;
>
> -for (i = 0; i < ctx->nb_inputs; i++) {
> +for (unsigned i = 0; i < ctx->nb_inputs; i++) {
> ret = ff_framesync_get_frame(fs, i, &frame, 0);
> -if (ret == 0)
> -ret = ff_qsvvpp_filter_frame(s->qsv, ctx->inputs[i], frame);
> +
> +if (ret == 0) {
> +if (i == 0)
> +frame0 = frame;
> +else {
> +av_frame_remove_all_side_data(frame);
> +ret = av_frame_copy_side_data(frame, frame0, 0);
> +}
> +
> +ret = ret < 0 ? ret : ff_qsvvpp_filter_frame(s->qsv, ctx-
> >inputs[i], frame);
> +}
> +
> if (ret < 0 && ret != AVERROR(EAGAIN))
> break;
> }
Patchset LGTM, I'll push this patchset if no more comment or objection.
Thanks
Haihao
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH v6] libavfilter/x86/vf_convolution: add sobel filter optimization and unit test with intel AVX512 VNNI
On Mon, 2022-10-31 at 16:12 +0800, bin.wang-at-intel@ffmpeg.org wrote:
> From: bwang30
>
> This commit enabled assembly code with intel AVX512 VNNI and added unit test
> for sobel filter
>
> sobel_c: 4537
> sobel_avx512icl 2136
>
> Signed-off-by: bwang30
> ---
> libavfilter/convolution.h | 74 +
> libavfilter/vf_convolution.c | 91 +++-
> libavfilter/x86/vf_convolution.asm| 147 ++
> libavfilter/x86/vf_convolution_init.c | 18
> tests/checkasm/Makefile | 1 +
> tests/checkasm/checkasm.c | 3 +
> tests/checkasm/checkasm.h | 1 +
> tests/checkasm/vf_convolution.c | 103 ++
> 8 files changed, 360 insertions(+), 78 deletions(-)
> create mode 100644 tests/checkasm/vf_convolution.c
>
> diff --git a/libavfilter/convolution.h b/libavfilter/convolution.h
> index 88aabe9a20..e44bfb5da8 100644
> --- a/libavfilter/convolution.h
> +++ b/libavfilter/convolution.h
> @@ -21,6 +21,7 @@
> #ifndef AVFILTER_CONVOLUTION_H
> #define AVFILTER_CONVOLUTION_H
> #include "avfilter.h"
> +#include "libavutil/intreadwrite.h"
>
> enum MatrixMode {
> MATRIX_SQUARE,
> @@ -61,4 +62,77 @@ typedef struct ConvolutionContext {
> } ConvolutionContext;
>
> void ff_convolution_init_x86(ConvolutionContext *s);
> +void ff_sobel_init_x86(ConvolutionContext *s, int depth, int nb_planes);
> +
> +static void setup_3x3(int radius, const uint8_t *c[], const uint8_t *src, int
> stride,
> + int x, int w, int y, int h, int bpc)
> +{
> +int i;
> +
> +for (i = 0; i < 9; i++) {
> +int xoff = FFABS(x + ((i % 3) - 1));
> +int yoff = FFABS(y + (i / 3) - 1);
> +
> +xoff = xoff >= w ? 2 * w - 1 - xoff : xoff;
> +yoff = yoff >= h ? 2 * h - 1 - yoff : yoff;
> +
> +c[i] = src + xoff * bpc + yoff * stride;
> +}
> +}
> +
> +static void filter_sobel(uint8_t *dst, int width,
> + float scale, float delta, const int *const matrix,
> + const uint8_t *c[], int peak, int radius,
> + int dstride, int stride, int size)
> +{
> +const uint8_t *c0 = c[0], *c1 = c[1], *c2 = c[2];
> +const uint8_t *c3 = c[3], *c5 = c[5];
> +const uint8_t *c6 = c[6], *c7 = c[7], *c8 = c[8];
> +int x;
> +
> +for (x = 0; x < width; x++) {
> +float suma = c0[x] * -1 + c1[x] * -2 + c2[x] * -1 +
> + c6[x] * 1 + c7[x] * 2 + c8[x] * 1;
> +float sumb = c0[x] * -1 + c2[x] * 1 + c3[x] * -2 +
> + c5[x] * 2 + c6[x] * -1 + c8[x] * 1;
> +
> +dst[x] = av_clip_uint8(sqrtf(suma*suma + sumb*sumb) * scale + delta);
> +}
> +}
> +
> +static void filter16_sobel(uint8_t *dstp, int width,
> + float scale, float delta, const int *const matrix,
> + const uint8_t *c[], int peak, int radius,
> + int dstride, int stride, int size)
> +{
> +uint16_t *dst = (uint16_t *)dstp;
> +int x;
> +
> +for (x = 0; x < width; x++) {
> +float suma = AV_RN16A(&c[0][2 * x]) * -1 + AV_RN16A(&c[1][2 * x]) *
> -2 + AV_RN16A(&c[2][2 * x]) * -1 +
> + AV_RN16A(&c[6][2 * x]) * 1 + AV_RN16A(&c[7][2 * x])
> * 2 + AV_RN16A(&c[8][2 * x]) * 1;
> +float sumb = AV_RN16A(&c[0][2 * x]) * -1 + AV_RN16A(&c[2][2 * x])
> * 1 + AV_RN16A(&c[3][2 * x]) * -2 +
> + AV_RN16A(&c[5][2 * x]) * 2 + AV_RN16A(&c[6][2 * x]) *
> -1 + AV_RN16A(&c[8][2 * x]) * 1;
> +
> +dst[x] = av_clip(sqrtf(suma*suma + sumb*sumb) * scale + delta, 0,
> peak);
> +}
> +}
> +
> +static av_unused void ff_sobel_init(ConvolutionContext *s, int depth, int
> nb_planes)
> +{
> +for (int i = 0; i < 4; i++) {
> +s->filter[i] = filter_sobel;
> +s->copy[i] = !((1 << i) & s->planes);
> +s->size[i] = 3;
> +s->setup[i] = setup_3x3;
> +s->rdiv[i] = s->scale;
> +s->bias[i] = s->delta;
> +}
> +if (s->depth > 8)
> +for (int i = 0; i < 4; i++)
> +s->filter[i] = filter16_sobel;
> +#if ARCH_X86_64
> +ff_sobel_init_x86(s, depth, nb_planes);
> +#endif
> +}
> #endif
> diff --git a/libavfilter/vf_convolution.c b/libavfilter/vf_convolution.c
> index 9a9c099e6d..7762fa2a05 100644
> --- a/libavfilter/vf_convolution.c
> +++ b/libavfilter/vf_convolution.c
> @@ -139,24 +139,6 @@ static void filter16_roberts(uint8_t *dstp, int width,
> }
> }
>
> -static void filter16_sobel(uint8_t *dstp, int width,
> - float scale, float delta, const int *const matrix,
> - const uint8_t *c[], int peak, int radius,
> - int dstride, int stride, int size)
> -{
> -uint16_t *dst = (uint16_t *)dstp;
> -int x;
> -
> -for (x = 0; x < width; x++) {
> -float suma = AV_RN16A(&c[0][2 * x]) * -1 + AV_RN16A(&
