[FFmpeg-devel] [PATCH] avfilter: add shear video filter

[Paul B Mahol]

Signed-off-by: Paul B Mahol 
---
 doc/filters.texi |  27 
 libavfilter/Makefile |   1 +
 libavfilter/allfilters.c |   1 +
 libavfilter/vf_shear.c   | 309 +++
 4 files changed, 338 insertions(+)
 create mode 100644 libavfilter/vf_shear.c

diff --git a/doc/filters.texi b/doc/filters.texi
index 7cb0d868d0..c2d7bac51d 100644
--- a/doc/filters.texi
+++ b/doc/filters.texi
@@ -17808,6 +17808,33 @@ Keep the same colorspace property (default).
 @end table
 @end table
 
+@section shear
+Apply shear transform to input video.
+
+This filter supports the following options:
+
+@table @option
+@item shx
+Shear factor in X-direction. Default value is 0.
+Allowed range is from -2 to 2.
+
+@item shy
+Shear factor in Y-direction. Default value is 0.
+Allowed range is from -2 to 2.
+
+@item fillcolor, c
+Set the color used to fill the output area not covered by the transformed
+video. For the general syntax of this option, check the
+@ref{color syntax,,"Color" section in the ffmpeg-utils manual,ffmpeg-utils}.
+If the special value "none" is selected then no
+background is printed (useful for example if the background is never shown).
+
+Default value is "black".
+
+@item interp
+Set interpolation type. Can be @code{bilinear} or @code{nearest}. Default is 
@code{bilinear}.
+@end table
+
 @section showinfo
 
 Show a line containing various information for each input video frame.
diff --git a/libavfilter/Makefile b/libavfilter/Makefile
index fb7bc8f140..b930a00d8b 100644
--- a/libavfilter/Makefile
+++ b/libavfilter/Makefile
@@ -403,6 +403,7 @@ OBJS-$(CONFIG_SETRANGE_FILTER)   += 
vf_setparams.o
 OBJS-$(CONFIG_SETSAR_FILTER) += vf_aspect.o
 OBJS-$(CONFIG_SETTB_FILTER)  += settb.o
 OBJS-$(CONFIG_SHARPNESS_VAAPI_FILTER)+= vf_misc_vaapi.o vaapi_vpp.o
+OBJS-$(CONFIG_SHEAR_FILTER)  += vf_shear.o
 OBJS-$(CONFIG_SHOWINFO_FILTER)   += vf_showinfo.o
 OBJS-$(CONFIG_SHOWPALETTE_FILTER)+= vf_showpalette.o
 OBJS-$(CONFIG_SHUFFLEFRAMES_FILTER)  += vf_shuffleframes.o
diff --git a/libavfilter/allfilters.c b/libavfilter/allfilters.c
index 139ba15f7c..616962690b 100644
--- a/libavfilter/allfilters.c
+++ b/libavfilter/allfilters.c
@@ -384,6 +384,7 @@ extern AVFilter ff_vf_setrange;
 extern AVFilter ff_vf_setsar;
 extern AVFilter ff_vf_settb;
 extern AVFilter ff_vf_sharpness_vaapi;
+extern AVFilter ff_vf_shear;
 extern AVFilter ff_vf_showinfo;
 extern AVFilter ff_vf_showpalette;
 extern AVFilter ff_vf_shuffleframes;
diff --git a/libavfilter/vf_shear.c b/libavfilter/vf_shear.c
new file mode 100644
index 00..dd301b1a78
--- /dev/null
+++ b/libavfilter/vf_shear.c
@@ -0,0 +1,309 @@
+/*
+ * Copyright (c) 2021 Paul B Mahol
+ *
+ * This file is part of FFmpeg.
+ *
+ * FFmpeg is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public
+ * License as published by the Free Software Foundation; either
+ * version 2.1 of the License, or (at your option) any later version.
+ *
+ * FFmpeg is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+ * Lesser General Public License for more details.
+ *
+ * You should have received a copy of the GNU Lesser General Public
+ * License along with FFmpeg; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA
+ */
+
+#include "libavutil/avstring.h"
+#include "libavutil/opt.h"
+#include "libavutil/intreadwrite.h"
+#include "libavutil/parseutils.h"
+#include "libavutil/pixdesc.h"
+
+#include "avfilter.h"
+#include "drawutils.h"
+#include "internal.h"
+#include "video.h"
+
+#include 
+
+typedef struct ShearContext {
+const AVClass *class;
+
+float shx, shy;
+int interp;
+
+uint8_t fillcolor[4];   ///< color expressed either in YUVA or RGBA 
colorspace for the padding area
+char *fillcolor_str;
+int fillcolor_enable;
+int nb_planes;
+int depth;
+FFDrawContext draw;
+FFDrawColor color;
+
+int hsub, vsub;
+int planewidth[4];
+int planeheight[4];
+
+int (*filter_slice[2])(AVFilterContext *ctx, void *arg, int jobnr, int 
nb_jobs);
+} ShearContext;
+
+typedef struct ThreadData {
+AVFrame *in, *out;
+} ThreadData;
+
+#define OFFSET(x) offsetof(ShearContext, x)
+#define FLAGS AV_OPT_FLAG_FILTERING_PARAM|AV_OPT_FLAG_VIDEO_PARAM
+#define TFLAGS 
AV_OPT_FLAG_FILTERING_PARAM|AV_OPT_FLAG_VIDEO_PARAM|AV_OPT_FLAG_RUNTIME_PARAM
+
+static const AVOption shear_options[] = {
+{ "shx",   "set x shear factor",OFFSET(shx),   
AV_OPT_TYPE_FLOAT,  {.dbl=0.}, -2, 2, .flags=TFLAGS },
+{ "shy",   "set y shear factor",OFFSET(shy),   
AV_OPT_TYPE_FLOAT,  {.dbl=0.}, -2, 2, .flags=TFLAGS },
+{ "fillcolor", "set background fill color", OFFSET

[FFmpeg-devel] [PATCH] configure: add fallback to $arch in msvc assembler check.

[Reimar Döffinger]

Setting the defaults for $arch happens only later, so
the current code would not set AS correctly if --arch
was not specified on the command-line.
Fix it by adding an explicit fallback to $arch_default.
---
 configure | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/configure b/configure
index 54fbbd6b5f..df298b4b9b 100755
--- a/configure
+++ b/configure
@@ -4268,7 +4268,7 @@ case "$toolchain" in
 ld_default="$source_path/compat/windows/mslink"
 nm_default="dumpbin.exe -symbols"
 ar_default="lib.exe"
-case "$arch" in
+case "${arch:-$arch_default}" in
 aarch64|arm64)
 as_default="armasm64.exe"
 ;;
--
2.30.0

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

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

Re: [FFmpeg-devel] [PATCH] configure: add fallback to $arch in msvc assembler check.

[Martin Storsjö]

On Sat, 23 Jan 2021, Reimar Döffinger wrote:


Setting the defaults for $arch happens only later, so
the current code would not set AS correctly if --arch
was not specified on the command-line.
Fix it by adding an explicit fallback to $arch_default.
---
configure | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/configure b/configure
index 54fbbd6b5f..df298b4b9b 100755
--- a/configure
+++ b/configure
@@ -4268,7 +4268,7 @@ case "$toolchain" in
ld_default="$source_path/compat/windows/mslink"
nm_default="dumpbin.exe -symbols"
ar_default="lib.exe"
-case "$arch" in
+case "${arch:-$arch_default}" in
aarch64|arm64)
as_default="armasm64.exe"
;;
--
2.30.0


LGTM, thanks!

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

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

Re: [FFmpeg-devel] [PATCH 2/2] avformat/swfdec: Check outlen before allocation

[Anton Khirnov]

Quoting Michael Niedermayer (2021-01-22 15:09:47)
> Fixes: Timeout (too long -> 241ms)
> Fixes: 
> 29083/clusterfuzz-testcase-minimized-ffmpeg_dem_SWF_fuzzer-6273684478230528
> 
> Found-by: continuous fuzzing process 
> https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
> Signed-off-by: Michael Niedermayer 
> ---
>  libavformat/swfdec.c | 3 +++
>  1 file changed, 3 insertions(+)
> 
> diff --git a/libavformat/swfdec.c b/libavformat/swfdec.c
> index 1463f0ad4d..aa4be88f91 100644
> --- a/libavformat/swfdec.c
> +++ b/libavformat/swfdec.c
> @@ -367,6 +367,9 @@ static int swf_read_packet(AVFormatContext *s, AVPacket 
> *pkt)
>  ff_dlog(s, "bitmap: ch=%d fmt=%d %dx%d (linesize=%d) len=%d->%ld 
> pal=%d\n",
>  ch_id, bmp_fmt, width, height, linesize, len, out_len, 
> colormapsize);
>  
> +if (len * 17373LL < out_len)

Where does the magic number come from?

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

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

[FFmpeg-devel] [PATCH] avfilter: add kirsch video filter

[Paul B Mahol]

Signed-off-by: Paul B Mahol 
---
 doc/filters.texi |  21 ++
 libavfilter/Makefile |   1 +
 libavfilter/allfilters.c |   1 +
 libavfilter/vf_convolution.c | 133 +++
 4 files changed, 156 insertions(+)

diff --git a/doc/filters.texi b/doc/filters.texi
index c2d7bac51d..00f5d38406 100644
--- a/doc/filters.texi
+++ b/doc/filters.texi
@@ -13396,6 +13396,27 @@ kerndeint=map=1
 @end example
 @end itemize
 
+@section kirsch
+Apply kirsch operator to input video stream.
+
+The filter accepts the following option:
+
+@table @option
+@item planes
+Set which planes will be processed, unprocessed planes will be copied.
+By default value 0xf, all planes will be processed.
+
+@item scale
+Set value which will be multiplied with filtered result.
+
+@item delta
+Set value which will be added to filtered result.
+@end table
+
+@subsection Commands
+
+This filter supports the all above options as @ref{commands}.
+
 @section lagfun
 
 Slowly update darker pixels.
diff --git a/libavfilter/Makefile b/libavfilter/Makefile
index b930a00d8b..fbb4e29bd0 100644
--- a/libavfilter/Makefile
+++ b/libavfilter/Makefile
@@ -298,6 +298,7 @@ OBJS-$(CONFIG_INFLATE_FILTER)+= 
vf_neighbor.o
 OBJS-$(CONFIG_INTERLACE_FILTER)  += vf_tinterlace.o
 OBJS-$(CONFIG_INTERLEAVE_FILTER) += f_interleave.o
 OBJS-$(CONFIG_KERNDEINT_FILTER)  += vf_kerndeint.o
+OBJS-$(CONFIG_KIRSCH_FILTER) += vf_convolution.o
 OBJS-$(CONFIG_LAGFUN_FILTER) += vf_lagfun.o
 OBJS-$(CONFIG_LENSCORRECTION_FILTER) += vf_lenscorrection.o
 OBJS-$(CONFIG_LENSFUN_FILTER)+= vf_lensfun.o
diff --git a/libavfilter/allfilters.c b/libavfilter/allfilters.c
index 616962690b..d9d36554c4 100644
--- a/libavfilter/allfilters.c
+++ b/libavfilter/allfilters.c
@@ -283,6 +283,7 @@ extern AVFilter ff_vf_inflate;
 extern AVFilter ff_vf_interlace;
 extern AVFilter ff_vf_interleave;
 extern AVFilter ff_vf_kerndeint;
+extern AVFilter ff_vf_kirsch;
 extern AVFilter ff_vf_lagfun;
 extern AVFilter ff_vf_lenscorrection;
 extern AVFilter ff_vf_lensfun;
diff --git a/libavfilter/vf_convolution.c b/libavfilter/vf_convolution.c
index c238dae925..7b655ae25b 100644
--- a/libavfilter/vf_convolution.c
+++ b/libavfilter/vf_convolution.c
@@ -159,6 +159,55 @@ static void filter16_sobel(uint8_t *dstp, int width,
 }
 }
 
+static void filter16_kirsch(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)
+{
+uint16_t *dst = (uint16_t *)dstp;
+const uint16_t *c0 = (const uint16_t *)c[0], *c1 = (const uint16_t *)c[1], 
*c2 = (const uint16_t *)c[2];
+const uint16_t *c3 = (const uint16_t *)c[3], *c5 = (const uint16_t *)c[5];
+const uint16_t *c6 = (const uint16_t *)c[6], *c7 = (const uint16_t *)c[7], 
*c8 = (const uint16_t *)c[8];
+int x;
+
+for (x = 0; x < width; x++) {
+int sum0 = c0[x] *  5 + c1[x] *  5 + c2[x] *  5 +
+   c3[x] * -3 + c5[x] * -3 +
+   c6[x] * -3 + c7[x] * -3 + c8[x] * -3;
+int sum1 = c0[x] * -3 + c1[x] *  5 + c2[x] *  5 +
+   c3[x] *  5 + c5[x] * -3 +
+   c6[x] * -3 + c7[x] * -3 + c8[x] * -3;
+int sum2 = c0[x] * -3 + c1[x] * -3 + c2[x] *  5 +
+   c3[x] *  5 + c5[x] *  5 +
+   c6[x] * -3 + c7[x] * -3 + c8[x] * -3;
+int sum3 = c0[x] * -3 + c1[x] * -3 + c2[x] * -3 +
+   c3[x] *  5 + c5[x] *  5 +
+   c6[x] *  5 + c7[x] * -3 + c8[x] * -3;
+int sum4 = c0[x] * -3 + c1[x] * -3 + c2[x] * -3 +
+   c3[x] * -3 + c5[x] *  5 +
+   c6[x] *  5 + c7[x] *  5 + c8[x] * -3;
+int sum5 = c0[x] * -3 + c1[x] * -3 + c2[x] * -3 +
+   c3[x] * -3 + c5[x] * -3 +
+   c6[x] *  5 + c7[x] *  5 + c8[x] *  5;
+int sum6 = c0[x] *  5 + c1[x] * -3 + c2[x] * -3 +
+   c3[x] * -3 + c5[x] * -3 +
+   c6[x] * -3 + c7[x] *  5 + c8[x] *  5;
+int sum7 = c0[x] *  5 + c1[x] *  5 + c2[x] * -3 +
+   c3[x] * -3 + c5[x] * -3 +
+   c6[x] * -3 + c7[x] * -3 + c8[x] *  5;
+
+sum0 = FFMAX(sum0, sum1);
+sum2 = FFMAX(sum2, sum3);
+sum4 = FFMAX(sum4, sum5);
+sum6 = FFMAX(sum6, sum7);
+sum0 = FFMAX(sum0, sum2);
+sum4 = FFMAX(sum4, sum6);
+sum0 = FFMAX(sum0, sum4);
+
+dst[x] = av_clip(FFABS(sum0) * scale + delta, 0, peak);
+}
+}
+
 static void filter_prewitt(uint8_t *dst, int width,
float scale, float delta, const int *const matrix,
const uint8_t *c[], int peak, int radius,
@@ -214,6 +263,54 @@ static void filter_sobel(uint8_t *dst, int width,
 }
 }
 
+static void filt

Re: [FFmpeg-devel] [PATCH] libavdevice: Add KMS/DRM output device

[Anton Khirnov]

Quoting Marton Balint (2021-01-20 00:40:30)
> 
> 
> On Tue, 19 Jan 2021, Anton Khirnov wrote:
> 
> > Quoting Mark Thompson (2021-01-19 00:37:09)
> >> On 16/01/2021 22:12, Nicolas Caramelli wrote:
> >> > This patch adds KMS/DRM output device for rendering a video stream
> >> > using KMS/DRM dumb buffer.
> >> > The proposed implementation is very basic, only bgr0 pixel format is
> >> > currently supported (the most common format with KMS/DRM).
> >> > To enable this output device you need to configure FFmpeg with 
> >> > --enable-libdrm.
> >> > Example: ffmpeg -re -i INPUT -pix_fmt bgr0 -f kmsdumb /dev/dri/card0
> >> 
> >> If you want to render things to a normal display device why not use a 
> >> normal video player?  Or even ffplay?
> >> 
> >> IMO something like this would be of more value as a simple video player 
> >> example with the documentation rather than including it as weirdly 
> >> constrained library code which will see very little use.
> >> 
> >> (Note that I would argue against adding more general display output 
> >> devices which are already present, like fb and xv, because they are of 
> >> essentially no value to libavdevice users.  Removing legacy code is 
> >> harder, though.)
> >
> > +1
> >
> > IMO libavdevice output devices are worse than useless and should all be
> > removed.
> 
> Decklink is heavily used for both input and output.

But does anyone use anything else than ffmpeg.c for that?

The question here is not whether this functionality should exist at all,
but whether libavdevice/libavformat is the right place for it.

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

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

[FFmpeg-devel] [PATCH]lsws/ppc/yuv2rgb: Fix transparency converting from yuv->rgb32

[Carl Eugen Hoyos]

Hi!

Attached patch fixes ticket #9077 for me.

Please comment, Carl Eugen
From 82ac1fb1e33340e956ed36e106ea8a74ecf1f3a3 Mon Sep 17 00:00:00 2001
From: Carl Eugen Hoyos 
Date: Sat, 23 Jan 2021 17:28:14 +0100
Subject: [PATCH] lsws/ppc/yuv2rgb: Fix transparency converting from
 yuv->rgb32.

Based on 68363b69

Fixes ticket #9077.
---
 libswscale/ppc/yuv2rgb_altivec.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/libswscale/ppc/yuv2rgb_altivec.c b/libswscale/ppc/yuv2rgb_altivec.c
index 536545293d..d69ce4c016 100644
--- a/libswscale/ppc/yuv2rgb_altivec.c
+++ b/libswscale/ppc/yuv2rgb_altivec.c
@@ -424,13 +424,13 @@ static int altivec_ ## name(SwsContext *c, const unsigned char **in,  \
 }
 
 #define out_abgr(a, b, c, ptr)  \
-vec_mstrgb32(__typeof__(a), ((__typeof__(a)) { 255 }), c, b, a, ptr)
+vec_mstrgb32(__typeof__(a), ((__typeof__(a)) { 255, 255, 255, 255, 255, 255, 255, 255, 255, 255, 255, 255, 255, 255, 255, 255 }), c, b, a, ptr)
 #define out_bgra(a, b, c, ptr)  \
-vec_mstrgb32(__typeof__(a), c, b, a, ((__typeof__(a)) { 255 }), ptr)
+vec_mstrgb32(__typeof__(a), c, b, a, ((__typeof__(a)) { 255, 255, 255, 255, 255, 255, 255, 255, 255, 255, 255, 255, 255, 255, 255, 255 }), ptr)
 #define out_rgba(a, b, c, ptr)  \
-vec_mstrgb32(__typeof__(a), a, b, c, ((__typeof__(a)) { 255 }), ptr)
+vec_mstrgb32(__typeof__(a), a, b, c, ((__typeof__(a)) { 255, 255, 255, 255, 255, 255, 255, 255, 255, 255, 255, 255, 255, 255, 255, 255 }), ptr)
 #define out_argb(a, b, c, ptr)  \
-vec_mstrgb32(__typeof__(a), ((__typeof__(a)) { 255 }), a, b, c, ptr)
+vec_mstrgb32(__typeof__(a), ((__typeof__(a)) { 255, 255, 255, 255, 255, 255, 255, 255, 255, 255, 255, 255, 255, 255, 255, 255 }), a, b, c, ptr)
 #define out_rgb24(a, b, c, ptr) vec_mstrgb24(a, b, c, ptr)
 #define out_bgr24(a, b, c, ptr) vec_mstbgr24(a, b, c, ptr)
 
-- 
2.29.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 20/39] avcodec/h261dec: Don't initialize unused part of RLTable

[Anton Khirnov]

Quoting Andreas Rheinhardt (2021-01-21 21:20:52)
> Anton Khirnov:
> > Quoting Andreas Rheinhardt (2020-12-10 12:16:38)
> >> The H.261 decoder only uses an RLTable's VLC table, yet it also
> >> initializes its index_run, max_level and max_run. This commit stops
> >> doing so; it will also simplify making this decoder init-threadsafe,
> >> as the H.261 decoder and encoder now initialize disjoint parts of their
> >> common RLTable.
> > 
> > Does it then make sense to keep this RLTable common?
> > 
> I presume you want to know whether the RLTable structure should be split
> into smaller structures?

No, what I meant was whether we shouldn't use different RLTable
instances for encoder and decoder, since their use is disjoint. That
would make the code easier to reason about.

> 
> PS: It seems you overlooked patches 7-13.

It's more that I have next to zero experience with/insight into that
code. I don't think I can review on more than the most superficial level
without major effort.

-- 
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]lsws/ppc/yuv2rgb: Fix transparency converting from yuv->rgb32

[Reimar Döffinger]

Hi!

> On 23 Jan 2021, at 17:31, Carl Eugen Hoyos  wrote:
> Attached patch fixes ticket #9077 for me.
> 
> Please comment, Carl Eugen
> <0001-lsws-ppc-yuv2rgb-Fix-transparency-converting-from-yu.patch>

Unfortunately I can’t test anything myself anymore since
I don’t have any devices with VGA input anymore (and connecting
the PPC MacMini via HDMI never worked reliably).
But checking the surrounding code it might make sense to check
if vec_splat(…{255}, 0) also works, or maybe even generates
better code.
The other cases where a non-0 constant (128) is needed in the
whole vector use vec_splat instead of duplicating the value,
so I assume there is a reason.
In this case actually even more, since the code is generic and
we might not actually know just how many 255s exactly we need
to put into that array?

Best regards,
Reimar
___
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] ffmpeg_opts: remove lowres check

[Anton Khirnov]

Quoting James Almer (2021-01-21 14:29:22)
> On 1/21/2021 9:59 AM, Anton Khirnov wrote:
> > Quoting James Almer (2021-01-09 18:47:17)
> >> The st->codec values are updated based on the lowres factor by
> >> avformat_find_stream_info() when it runs an instance of the decoder 
> >> internally,
> >> and the same thing happens in ffmpeg.c when we open ist->dec_ctx with
> >> avcodec_open2(), so these assignments are redundant.
> >>
> >> Signed-off-by: James Almer 
> >> ---
> >> This chunk here is not properly wrapped with the relevant pre-processor 
> >> check
> >> for AVStream->codec, and seeing it's ultimately redundant, i figured we 
> >> might
> >> as well delete it now.
> >>
> >> For that matter, the deprecation of lowres in avcodec.h is in a very 
> >> strange
> >> state (the field is not removed, its offset is changed instead). Once the 
> >> value
> >> of FF_API_LOWRES is flipped, neither the field, the AVOption, or the usage
> >> within decoders will be removed, but some code in libavformat/utils.c will 
> >> be
> >> disabled, and that may result in unexpected behavior.
> > 
> > IMO it should just be made a codec-private option. And lavf has no
> > business treating it specially.
> 
> Technically speaking, there's no reason for lavf to check for lowres to 
> do what it's currently doing.
> 
> The code
> 
> > int orig_w = st->codecpar->width;
> > int orig_h = st->codecpar->height;
> > ret = avcodec_parameters_from_context(st->codecpar, 
> > st->internal->avctx);
> > if (ret < 0)
> > goto find_stream_info_err;
> > ret = add_coded_side_data(st, st->internal->avctx);
> > if (ret < 0)
> > goto find_stream_info_err;
> > #if FF_API_LOWRES
> > // The decoder might reduce the video size by the lowres factor.
> > if (st->internal->avctx->lowres && orig_w) {
> > st->codecpar->width = orig_w;
> > st->codecpar->height = orig_h;
> > }
> > #endif
> 
> Could be simplified to unconditionally set st->codecpar dimensions to 
> the backed up ones. If you agree, i can send a patch.

I'm not sure that won't have other side effects - the decoder might have
different ideas about dimensions than the demuxer, which might change
something in some obscure cases. I guess try and see if FATE passes?

-- 
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] ffmpeg_opts: remove lowres check

[James Almer]

On 1/23/2021 3:17 PM, Anton Khirnov wrote:

Quoting James Almer (2021-01-21 14:29:22)

On 1/21/2021 9:59 AM, Anton Khirnov wrote:

Quoting James Almer (2021-01-09 18:47:17)

The st->codec values are updated based on the lowres factor by
avformat_find_stream_info() when it runs an instance of the decoder internally,
and the same thing happens in ffmpeg.c when we open ist->dec_ctx with
avcodec_open2(), so these assignments are redundant.

Signed-off-by: James Almer 
---
This chunk here is not properly wrapped with the relevant pre-processor check
for AVStream->codec, and seeing it's ultimately redundant, i figured we might
as well delete it now.

For that matter, the deprecation of lowres in avcodec.h is in a very strange
state (the field is not removed, its offset is changed instead). Once the value
of FF_API_LOWRES is flipped, neither the field, the AVOption, or the usage
within decoders will be removed, but some code in libavformat/utils.c will be
disabled, and that may result in unexpected behavior.


IMO it should just be made a codec-private option. And lavf has no
business treating it specially.


Technically speaking, there's no reason for lavf to check for lowres to
do what it's currently doing.

The code


 int orig_w = st->codecpar->width;
 int orig_h = st->codecpar->height;
 ret = avcodec_parameters_from_context(st->codecpar, 
st->internal->avctx);
 if (ret < 0)
 goto find_stream_info_err;
 ret = add_coded_side_data(st, st->internal->avctx);
 if (ret < 0)
 goto find_stream_info_err;
#if FF_API_LOWRES
 // The decoder might reduce the video size by the lowres factor.
 if (st->internal->avctx->lowres && orig_w) {
 st->codecpar->width = orig_w;
 st->codecpar->height = orig_h;
 }
#endif


Could be simplified to unconditionally set st->codecpar dimensions to
the backed up ones. If you agree, i can send a patch.


I'm not sure that won't have other side effects - the decoder might have
different ideas about dimensions than the demuxer, which might change
something in some obscure cases. I guess try and see if FATE passes?


If i apply the following, the output of three remuxing (codec copy) 
tests change



diff --git a/libavformat/utils.c b/libavformat/utils.c
index 8ac6bc04b8..0cdf3156a6 100644
--- a/libavformat/utils.c
+++ b/libavformat/utils.c
@@ -4110,13 +4110,12 @@ FF_ENABLE_DEPRECATION_WARNINGS
 ret = add_coded_side_data(st, st->internal->avctx);
 if (ret < 0)
 goto find_stream_info_err;
-#if FF_API_LOWRES
-// The decoder might reduce the video size by the lowres factor.
-if (st->internal->avctx->lowres && orig_w) {
+
+// The decoder might change the video size.
+if (orig_w && orig_h) {
 st->codecpar->width = orig_w;
 st->codecpar->height = orig_h;
 }
-#endif
 }


What i assume happens is that without this change st->codecpar is being 
populated with dimensions set by whatever decoder was used during 
probing, and then propagated to the muxer codecpar, whereas with this 
change the dimensions from the source container are kept unchanged.


Case in point


diff --git a/tests/ref/fate/cbs-vp9-vp90-2-05-resize 
b/tests/ref/fate/cbs-vp9-vp90-2-05-resize
index 8f036bba81..37a37ff1ea 100644
--- a/tests/ref/fate/cbs-vp9-vp90-2-05-resize
+++ b/tests/ref/fate/cbs-vp9-vp90-2-05-resize
@@ -1 +1 @@
-6838422ebb45df353a2bad62b9aff8e9
+1c39300b93fe110e1db30974e5d3479d
diff --git a/tests/ref/fate/redcode-demux b/tests/ref/fate/redcode-demux
index 45119ec71e..c6e0b6de5c 100644
--- a/tests/ref/fate/redcode-demux
+++ b/tests/ref/fate/redcode-demux
@@ -1,7 +1,7 @@
 #tb 0: 1/24
 #media_type 0: video
 #codec_id 0: jpeg2000
-#dimensions 0: 2048x1152
+#dimensions 0: 4096x2304
 #sar 0: 0/1
 #tb 1: 1/24
 #media_type 1: audio
diff --git a/tests/ref/fate/wtv-demux b/tests/ref/fate/wtv-demux
index abe85a4ab6..39d395699c 100644
--- a/tests/ref/fate/wtv-demux
+++ b/tests/ref/fate/wtv-demux
@@ -3,7 +3,7 @@
 #tb 0: 1/1000
 #media_type 0: video
 #codec_id 0: mpeg2video
-#dimensions 0: 720x576
+#dimensions 0: 704x480
 #sar 0: 64/45
 #tb 1: 1/1000
 #media_type 1: audio
--


I personally think that for a codec copy scenario (Where you could have 
no decoders at all), this behavior is more consistent. Some samples have 
different resolution per frame, like that vp9 one, and a decoder could 
return the one from the last frame probed.

___
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 20/39] avcodec/h261dec: Don't initialize unused part of RLTable

[Andreas Rheinhardt]

Anton Khirnov:
> Quoting Andreas Rheinhardt (2021-01-21 21:20:52)
>> Anton Khirnov:
>>> Quoting Andreas Rheinhardt (2020-12-10 12:16:38)
 The H.261 decoder only uses an RLTable's VLC table, yet it also
 initializes its index_run, max_level and max_run. This commit stops
 doing so; it will also simplify making this decoder init-threadsafe,
 as the H.261 decoder and encoder now initialize disjoint parts of their
 common RLTable.
>>>
>>> Does it then make sense to keep this RLTable common?
>>>
>> I presume you want to know whether the RLTable structure should be split
>> into smaller structures?
> 
> No, what I meant was whether we shouldn't use different RLTable
> instances for encoder and decoder, since their use is disjoint. That
> would make the code easier to reason about.

I actually didn't think that these RLTables were difficult to reason
about: ff_rl_init and ff_rl_init_vlc/ff_init_2d_vlc_rl initialize
different parts of an RLTable and both only use the static parts of an
RLTable, so that these two can be called independently. In particular
there is no clash in the case of H.261 after the unnecessary call to
ff_rl_init by the decoder is gone. And in case the decoder needs
ff_rl_init, too, one just needs to make sure that it is only initialized
once and that is really not onerous.

So, my answer to your original question is that it makes sense to keep
these RLTables common.

>>
>> PS: It seems you overlooked patches 7-13.
> 
> It's more that I have next to zero experience with/insight into that
> code. I don't think I can review on more than the most superficial level
> without major effort.
> 
Ok, then I'll just ping these patches.

- 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]lsws/ppc/yuv2rgb: Fix transparency converting from yuv->rgb32

[Carl Eugen Hoyos]

Am Sa., 23. Jan. 2021 um 19:16 Uhr schrieb Reimar Döffinger
:
>
> Hi!
>
> > On 23 Jan 2021, at 17:31, Carl Eugen Hoyos  wrote:
> > Attached patch fixes ticket #9077 for me.
> >
> > Please comment, Carl Eugen
> > <0001-lsws-ppc-yuv2rgb-Fix-transparency-converting-from-yu.patch>
>
> Unfortunately I can’t test anything myself anymore since
> I don’t have any devices with VGA input anymore (and connecting
> the PPC MacMini via HDMI never worked reliably).
> But checking the surrounding code it might make sense to check
> if vec_splat(…{255}, 0) also works, or maybe even generates
> better code.
> The other cases where a non-0 constant (128) is needed in the
> whole vector use vec_splat instead of duplicating the value,
> so I assume there is a reason.
> In this case actually even more, since the code is generic and
> we might not actually know just how many 255s exactly we need
> to put into that array?

New patch attached, thank you!

Please comment, Carl Eugen
From 43859bd0eb325c35082b33eca89866116bf7a5e8 Mon Sep 17 00:00:00 2001
From: Carl Eugen Hoyos 
Date: Sat, 23 Jan 2021 19:33:13 +0100
Subject: [PATCH] lsws/ppc/yuv2rgb: Fix transparency converting from
 yuv->rgb32.
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Based on 68363b69 by Reimar Döffinger.

Fixes ticket #9077.
---
 libswscale/ppc/yuv2rgb_altivec.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/libswscale/ppc/yuv2rgb_altivec.c b/libswscale/ppc/yuv2rgb_altivec.c
index 536545293d..d55cf99521 100644
--- a/libswscale/ppc/yuv2rgb_altivec.c
+++ b/libswscale/ppc/yuv2rgb_altivec.c
@@ -424,13 +424,13 @@ static int altivec_ ## name(SwsContext *c, const unsigned char **in,  \
 }
 
 #define out_abgr(a, b, c, ptr)  \
-vec_mstrgb32(__typeof__(a), ((__typeof__(a)) { 255 }), c, b, a, ptr)
+vec_mstrgb32(__typeof__(a), ((__typeof__(a)) vec_splat((__typeof__(a)){ 255 }, 0)), c, b, a, ptr)
 #define out_bgra(a, b, c, ptr)  \
-vec_mstrgb32(__typeof__(a), c, b, a, ((__typeof__(a)) { 255 }), ptr)
+vec_mstrgb32(__typeof__(a), c, b, a, ((__typeof__(a)) vec_splat((__typeof__(a)){ 255 }, 0)), ptr)
 #define out_rgba(a, b, c, ptr)  \
-vec_mstrgb32(__typeof__(a), a, b, c, ((__typeof__(a)) { 255 }), ptr)
+vec_mstrgb32(__typeof__(a), a, b, c, ((__typeof__(a)) vec_splat((__typeof__(a)){ 255 }, 0)), ptr)
 #define out_argb(a, b, c, ptr)  \
-vec_mstrgb32(__typeof__(a), ((__typeof__(a)) { 255 }), a, b, c, ptr)
+vec_mstrgb32(__typeof__(a), ((__typeof__(a)) vec_splat((__typeof__(a)){ 255 }, 0)), a, b, c, ptr)
 #define out_rgb24(a, b, c, ptr) vec_mstrgb24(a, b, c, ptr)
 #define out_bgr24(a, b, c, ptr) vec_mstbgr24(a, b, c, ptr)
 
-- 
2.29.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 "avutil/timecode: fix sscanf format string with garbage at the end"

[Marton Balint]

On Sun, 17 Jan 2021, lance.lmw...@gmail.com wrote:


On Sun, Jan 17, 2021 at 03:30:15AM +0100, Marton Balint wrote:


On Sun, 17 Jan 2021, lance.lmw...@gmail.com wrote:

> On Sat, Jan 16, 2021 at 09:49:42AM +0100, Marton Balint wrote:
> > This reverts commit 6696a07ac62bfec49dd488510a719367918b9f7a.
> > 
> > It is wrong to restrict timecodes to always contain leading zeros or for hours

> > or frames to be 2 chars only.
> Sorry, I think I was misunderstood by the following syntax description:
> syntax: hh:mm:ss[:;.]ff
> 
> maybe it's better to change it to hour:minute:second[:;.]frame?


That would better reflect on what the code did before the patch.

> 
> After revisiting the code, I think we may support more valid syntax for the timecode

> string:
> ss
> ss[:;.]ff
> mm:ss
> mm:ss[:;.]ff
> hh:mm:ss
> hh:mm:ss[:;.]ff

I don't like this idea much, it is good if we are strict about the timecode
format (e.g request all components to be present and no garbage after the
parsed string), the main reasons I suggested the revert are because timecode
has to support > 100 fps and >= 100 hours because our timecode API also has
support for such timecodes.


Sure, please revert it anyway.


Ok, thanks, reverted.

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

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

[FFmpeg-devel] [PATCH] avpacket: RFC for ABI bump additions

[Lynne]

This is an RFC about the upcoming additions to the AVPacket structure
(whose size is still part of the ABI, so we need to plan for any changes).

The current RFC patch adds 3 fields:
    - "void *opaque;" for the user to use as they wish, same as AVFrame.opaque
    - "void *opaque_ref;" for more permanent and propagating user data, same as 
AVFrame.opaque_ref
    - "AVRational time_base;" which will be set to indicate the time base of 
the packet's timestamps

Some devs (JEEB) wanted reception timestamps and original, overflowed 
timestamps for MPEG-TS.
I'd be willing to add a reception timestamp as long as we add an additional 
time_base field
and make it independent of the packet's pts field, since those timestamps are 
usually on
highly precise system clock time bases, and reducing their precision would be 
undesirable.

I'm not sure about overflowed original timestamps or how they would help.
Perhaps we should introduce an AVBufferRef *internal_ref like with AVFrame to
store such single library-only data?
>From e46f0aeb78928e06c14fac5dfe6c4b11c4b75c42 Mon Sep 17 00:00:00 2001
From: Lynne 
Date: Sat, 23 Jan 2021 19:56:18 +0100
Subject: [PATCH] avpacket: RFC for ABI bump additions

---
 doc/APIchanges|  3 +++
 libavcodec/avpacket.c |  9 +
 libavcodec/packet.h   | 23 +++
 3 files changed, 35 insertions(+)

diff --git a/doc/APIchanges b/doc/APIchanges
index bbf56a5385..d239ef7627 100644
--- a/doc/APIchanges
+++ b/doc/APIchanges
@@ -15,6 +15,9 @@ libavutil: 2017-10-21
 
 API changes, most recent first:
 
+2021-xx-xx - xx - lavc 59.100.100 - avpacket.h
+  Add AVPacket.opaque, AVPacket.opaque_ref and AVPacket.time_base
+
 2021-01-11 - xx - lavc 58.116.100 - avcodec.h
   Add FF_PROFILE_VVC_MAIN_10 and FF_PROFILE_VVC_MAIN_10_444.
 
diff --git a/libavcodec/avpacket.c b/libavcodec/avpacket.c
index e4ba403cf6..cf2c5efb66 100644
--- a/libavcodec/avpacket.c
+++ b/libavcodec/avpacket.c
@@ -585,6 +585,12 @@ FF_ENABLE_DEPRECATION_WARNINGS
 dst->flags= src->flags;
 dst->stream_index = src->stream_index;
 
+#if LIBAVCODEC_VERSION_MAJOR > 58
+i = av_buffer_replace(&dst->opaque_ref, src->opaque_ref);
+if (i < 0)
+return i;
+#endif
+
 dst->side_data= NULL;
 dst->side_data_elems  = 0;
 for (i = 0; i < src->side_data_elems; i++) {
@@ -606,6 +612,9 @@ FF_ENABLE_DEPRECATION_WARNINGS
 void av_packet_unref(AVPacket *pkt)
 {
 av_packet_free_side_data(pkt);
+#if LIBAVCODEC_VERSION_MAJOR > 58
+av_buffer_unref(&pkt->opaque_ref);
+#endif
 av_buffer_unref(&pkt->buf);
 av_init_packet(pkt);
 pkt->data = NULL;
diff --git a/libavcodec/packet.h b/libavcodec/packet.h
index b9d4c9c2c8..8e3f95e6ae 100644
--- a/libavcodec/packet.h
+++ b/libavcodec/packet.h
@@ -391,6 +391,29 @@ typedef struct AVPacket {
 attribute_deprecated
 int64_t convergence_duration;
 #endif
+
+#if LIBAVCODEC_VERSION_MAJOR > 58
+/**
+ * for some private data of the user
+ */
+void *opaque;
+
+/**
+ * AVBufferRef for free use by the API user. FFmpeg will never check the
+ * contents of the buffer ref. FFmpeg calls av_buffer_unref() on it when
+ * the packet is unreferenced. av_packet_copy_props() calls create a new
+ * reference with av_buffer_ref() for the target packet's opaque_ref field.
+ *
+ * This is unrelated to the opaque field, although it serves a similar
+ * purpose.
+ */
+AVBufferRef *opaque_ref;
+
+/**
+ * Time base of the packet's timestamps.
+ */
+AVRational time_base;
+#endif
 } AVPacket;
 
 typedef struct AVPacketList {
-- 
2.30.0

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

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

Re: [FFmpeg-devel] [PATCH] avpacket: RFC for ABI bump additions

[Gyan Doshi]

On 24-01-2021 12:40 am, Lynne wrote:

This is an RFC about the upcoming additions to the AVPacket structure
(whose size is still part of the ABI, so we need to plan for any changes).

The current RFC patch adds 3 fields:
     - "void *opaque;" for the user to use as they wish, same as AVFrame.opaque
     - "void *opaque_ref;" for more permanent and propagating user data, same 
as AVFrame.opaque_ref
     - "AVRational time_base;" which will be set to indicate the time base of 
the packet's timestamps

Some devs (JEEB) wanted reception timestamps and original, overflowed 
timestamps for MPEG-TS.
I'd be willing to add a reception timestamp as long as we add an additional 
time_base field
and make it independent of the packet's pts field, since those timestamps are 
usually on
highly precise system clock time bases, and reducing their precision would be 
undesirable.

I'm not sure about overflowed original timestamps or how they would help.


Reception timestamps sounds useful.

Overflow timestamps may be useful, Right now, lavf rolls over timestamps 
correctly only once, as the offset doesn't accommodate further loops.



Regards,
Gyan
___
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] avpacket: RFC for ABI bump additions

[Marton Balint]

On Sat, 23 Jan 2021, Lynne wrote:


This is an RFC about the upcoming additions to the AVPacket structure
(whose size is still part of the ABI, so we need to plan for any changes).

The current RFC patch adds 3 fields:
    - "void *opaque;" for the user to use as they wish, same as AVFrame.opaque
    - "void *opaque_ref;" for more permanent and propagating user data, same as 
AVFrame.opaque_ref


These seem legit.


    - "AVRational time_base;" which will be set to indicate the time base of 
the packet's timestamps


Why? It seems redundant and it will not be clear when to use to use 
stream/bsf/etc time base and when embedded AVPacket timebase. So I don't 
think this is a good idea.




Some devs (JEEB) wanted reception timestamps and original, overflowed 
timestamps for MPEG-TS.


MPEG-TS with timestamps has many issues and I am afraid the introduction 
of original/overflowed timestamps won't solve them:
- discontinuity - the discontinuity should be hidden from the output 
timestamps, but the discontinuity should be detected based on the PCR of 
the streams
- parsers - the parsers merge/split packets as they want, who knows what 
will happen to the timestamps...
- overflows - ffmpeg's "infrastructure" for packet timestamp overflows 
only handles a single wraparound, not multiple, so it is useless for 
anything serious.



I'd be willing to add a reception timestamp as long as we add an additional 
time_base field
and make it independent of the packet's pts field, since those timestamps are 
usually on
highly precise system clock time bases, and reducing their precision would be 
undesirable.


I don't know, I'd really like to see some actual benefit of these extra
timestamps before we agree to add specific fields for it. Until then, maye 
just use side data?




I'm not sure about overflowed original timestamps or how they would help.
Perhaps we should introduce an AVBufferRef *internal_ref like with AVFrame to
store such single library-only data?


I guess you mean private_ref. This can be added, if for nothing else, then 
for consistency. :)


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

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

Re: [FFmpeg-devel] [PATCH] avpacket: RFC for ABI bump additions

[Lynne]

Jan 23, 2021, 21:04 by c...@passwd.hu:

>
>
> On Sat, 23 Jan 2021, Lynne wrote:
>
>> This is an RFC about the upcoming additions to the AVPacket structure
>> (whose size is still part of the ABI, so we need to plan for any changes).
>>
>> The current RFC patch adds 3 fields:
>>     - "void *opaque;" for the user to use as they wish, same as 
>> AVFrame.opaque
>>     - "void *opaque_ref;" for more permanent and propagating user data, same 
>> as AVFrame.opaque_ref
>>
>
> These seem legit.
>
>>     - "AVRational time_base;" which will be set to indicate the time base of 
>> the packet's timestamps
>>
>
> Why? It seems redundant and it will not be clear when to use to use 
> stream/bsf/etc time base and when embedded AVPacket timebase. So I don't 
> think this is a good idea.
>

I'd like to switch to using this to avoid the dance you have to do with
avformat init, where you have to give it your packet's time_base in the stream 
time_base
then init, which then sets the time_base in the same field you provided your 
time_base,
and then you have to rescale the timestamps of packets to that timebase.
Wouldn't it be simpler to just give avformat packets and let it adjust the
packet time base internally as it sees fit and store it in a private_ref field?

It was a struggle figuring out how to init avformat properly since none of this
was documented when I was implementing it, and it was only thanks to
comments in mpv's source that I figured it out.

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

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

Re: [FFmpeg-devel] [PATCH] avpacket: RFC for ABI bump additions

[Marton Balint]

On Sat, 23 Jan 2021, Lynne wrote:


Jan 23, 2021, 21:04 by c...@passwd.hu:




On Sat, 23 Jan 2021, Lynne wrote:


This is an RFC about the upcoming additions to the AVPacket structure
(whose size is still part of the ABI, so we need to plan for any changes).

The current RFC patch adds 3 fields:
    - "void *opaque;" for the user to use as they wish, same as AVFrame.opaque
    - "void *opaque_ref;" for more permanent and propagating user data, same as 
AVFrame.opaque_ref



These seem legit.


    - "AVRational time_base;" which will be set to indicate the time base of 
the packet's timestamps



Why? It seems redundant and it will not be clear when to use to use 
stream/bsf/etc time base and when embedded AVPacket timebase. So I don't think 
this is a good idea.



I'd like to switch to using this to avoid the dance you have to do with
avformat init, where you have to give it your packet's time_base in the stream 
time_base
then init, which then sets the time_base in the same field you provided your 
time_base,
and then you have to rescale the timestamps of packets to that timebase.


That is by design as far as I know, you set the timebase to your 
requested time base, if the format supports that then you are happy, if 
not, then you convert.



Wouldn't it be simpler to just give avformat packets and let it adjust the
packet time base internally as it sees fit and store it in a private_ref field?


I would not want avformat to rescale timestamps behind my back, that way I 
control how I lose precision.


Regards,
Marton



It was a struggle figuring out how to init avformat properly since none of this
was documented when I was implementing it, and it was only thanks to
comments in mpv's source that I figured it out.

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

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

___
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 01/10] avcodec/atrac3plus_data: Remove unused arrays

[Andreas Rheinhardt]

Forgotten in 58fc810d42fde26ed6c1f2996122e98ab7005849.

Signed-off-by: Andreas Rheinhardt 
---
 libavcodec/atrac3plus_data.h | 19 ---
 1 file changed, 19 deletions(-)

diff --git a/libavcodec/atrac3plus_data.h b/libavcodec/atrac3plus_data.h
index b0b85c4368..05ae2b78a9 100644
--- a/libavcodec/atrac3plus_data.h
+++ b/libavcodec/atrac3plus_data.h
@@ -104,25 +104,6 @@ static const uint8_t atrac3p_sf_xlats[] = {
  0,  1,  2, 14, 15,  3, 13,  4, 12,  5, 11,  6,  7,  9, 10,
 };
 
-static const uint8_t atrac3p_ct_huff1[4][2] = {
-{ 0, 1 }, { 1, 2 }, { 2, 3 }, { 3, 3 },
-};
-
-static const uint8_t atrac3p_ct_huff2[8][2] = {
-{ 0, 2 }, { 1, 3 }, { 2, 3 }, { 3, 3 }, { 4, 3 }, { 5, 3 }, { 6, 4 },
-{ 7, 4 },
-};
-
-static const uint8_t atrac3p_ct_huff3[8][2] = {
-{ 0, 2 }, { 1, 3 }, { 2, 3 }, { 3, 3 }, { 6, 3 }, { 7, 3 }, { 4, 4 },
-{ 5, 4 },
-};
-
-static const uint8_t atrac3p_ct_huff4[8][2] = {
-{ 0, 1 }, { 1, 3 }, { 2, 4 }, { 3, 4 }, { 4, 4 }, { 5, 4 }, { 6, 4 },
-{ 7, 4 },
-};
-
 /* weights for quantized word lengths */
 static const int8_t atrac3p_wl_weights[6][32] = {
 { 5, 5, 4, 4, 3, 3, 2, 2, 1, 1, 0, 0, 0, 0, 0, 0,
-- 
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 02/10] avcodec/ilbcdata: Remove unused array

[Andreas Rheinhardt]

Never used.

Signed-off-by: Andreas Rheinhardt 
---
 libavcodec/ilbcdata.h | 4 
 1 file changed, 4 deletions(-)

diff --git a/libavcodec/ilbcdata.h b/libavcodec/ilbcdata.h
index 8d145bc183..b17e24df5f 100644
--- a/libavcodec/ilbcdata.h
+++ b/libavcodec/ilbcdata.h
@@ -60,10 +60,6 @@ static const int16_t kLpcChirpSyntDenum[] = {
 32767, 29573, 26690, 24087, 21739, 19619, 17707, 15980, 14422, 13016, 11747
 };
 
-static const int16_t LpcChirpWeightDenum[] = {
-32767, 13835, 5841, 2466, 1041, 440, 186, 78,  33,  14,  6
-};
-
 static const int16_t cos_tbl[64] = {
 32767,  32729,  32610,  32413,  32138,  31786,  31357,   30853,
 30274,  29622,  28899,  28106,  27246,  26320,  25330,   24279,
-- 
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 03/10] avcodec/vp8data: Remove unused array

[Andreas Rheinhardt]

Unused since 748f921ad1997a464fb8963d0ba2c5bb5e036b1b.

Signed-off-by: Andreas Rheinhardt 
---
 libavcodec/vp8data.h | 6 --
 1 file changed, 6 deletions(-)

diff --git a/libavcodec/vp8data.h b/libavcodec/vp8data.h
index 5e6dea7617..1fcce134eb 100644
--- a/libavcodec/vp8data.h
+++ b/libavcodec/vp8data.h
@@ -316,12 +316,6 @@ static const uint8_t vp8_pred4x4_prob_intra[10][10][9] = {
 },
 };
 
-static const int8_t vp8_segmentid_tree[][2] = {
-{  1,  2 },
-{ -0, -1 }, // '00', '01'
-{ -2, -3 }, // '10', '11'
-};
-
 static const uint8_t vp8_coeff_band[16] = {
 0, 1, 2, 3, 6, 4, 5, 6, 6, 6, 6, 6, 6, 6, 6, 7
 };
-- 
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 09/10] avcodec/mpeg4videodec: Fix indentation

[Andreas Rheinhardt]

It was wrong since e03bf251d8784f4d1df2c22381c902087e151e31.

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

diff --git a/libavcodec/mpeg4videodec.c b/libavcodec/mpeg4videodec.c
index e364e0b493..a4479f889b 100644
--- a/libavcodec/mpeg4videodec.c
+++ b/libavcodec/mpeg4videodec.c
@@ -3201,15 +3201,15 @@ static int decode_studiovisualobject(Mpeg4DecContext 
*ctx, GetBitContext *gb)
 MpegEncContext *s = &ctx->m;
 int visual_object_type;
 
-skip_bits(gb, 4); /* visual_object_verid */
-visual_object_type = get_bits(gb, 4);
-if (visual_object_type != VOT_VIDEO_ID) {
-avpriv_request_sample(s->avctx, "VO type %u", visual_object_type);
-return AVERROR_PATCHWELCOME;
-}
+skip_bits(gb, 4); /* visual_object_verid */
+visual_object_type = get_bits(gb, 4);
+if (visual_object_type != VOT_VIDEO_ID) {
+avpriv_request_sample(s->avctx, "VO type %u", visual_object_type);
+return AVERROR_PATCHWELCOME;
+}
 
-next_start_code_studio(gb);
-extension_and_user_data(s, gb, 1);
+next_start_code_studio(gb);
+extension_and_user_data(s, gb, 1);
 
 return 0;
 }
-- 
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 04/10] avcodec/amrnbdata: Remove unused array

[Andreas Rheinhardt]

Always unused.

Signed-off-by: Andreas Rheinhardt 
---
 libavcodec/amrnbdata.h | 5 -
 1 file changed, 5 deletions(-)

diff --git a/libavcodec/amrnbdata.h b/libavcodec/amrnbdata.h
index 435fd9924b..20b7a6452f 100644
--- a/libavcodec/amrnbdata.h
+++ b/libavcodec/amrnbdata.h
@@ -1424,11 +1424,6 @@ static const float pred_fac[LP_FILTER_ORDER] = {
 
 // fixed tables
 
-/**
- * number of pulses per mode
- */
-static const uint8_t pulses_nb_per_mode[] = {2, 2, 2, 3, 4, 4, 8, 10};
-
 /** track start positions for algebraic code book routines */
 static const uint8_t track_position[16] = {
 0, 2, 0, 3, 0, 2, 0, 3, 1, 3, 2, 4, 1, 4, 1, 4
-- 
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 10/10] Revert "mpeg4videodec: raise an error if sprite_trajectory.table is NULL"

[Andreas Rheinhardt]

This reverts commit 6ac0e7818399a57e4684202bac79f35b3561ad1e.

The mpeg4video parser can reach code that presumes that a certain VLC
has been initialized; yet Libav did not ensure this and Libav bug #1012
[1] is about an ensuing crash.

Instead of fixing the root cause a simple check for whether said VLC
has already been initialized was added; said check is inherently racy.

The proper fix is of course to ensure that the VLC is initialized and
commit 7c76eaeca2791261d3f4f5c98c95f44abdbd879a already ensured this,
so there was no need to merge 6ac0e7818399a57e4684202bac79f35b3561ad1e
at all. This commit therefore reverts said commit.

[1]: https://bugzilla.libav.org/show_bug.cgi?id=1012

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

diff --git a/libavcodec/mpeg4videodec.c b/libavcodec/mpeg4videodec.c
index a4479f889b..5bfac4ea5a 100644
--- a/libavcodec/mpeg4videodec.c
+++ b/libavcodec/mpeg4videodec.c
@@ -197,10 +197,6 @@ static int mpeg4_decode_sprite_trajectory(Mpeg4DecContext 
*ctx, GetBitContext *g
 if (w <= 0 || h <= 0)
 return AVERROR_INVALIDDATA;
 
-/* the decoder was not properly initialized and we cannot continue */
-if (sprite_trajectory.table == NULL)
-return AVERROR_INVALIDDATA;
-
 for (i = 0; i < ctx->num_sprite_warping_points; i++) {
 int length;
 int x = 0, y = 0;
-- 
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 05/10] avcodec/tiff_common: Remove declarations of inexistent functions

[Andreas Rheinhardt]

Signed-off-by: Andreas Rheinhardt 
---
 libavcodec/tiff_common.h | 20 
 1 file changed, 20 deletions(-)

diff --git a/libavcodec/tiff_common.h b/libavcodec/tiff_common.h
index 03558c31a3..019d23e6d5 100644
--- a/libavcodec/tiff_common.h
+++ b/libavcodec/tiff_common.h
@@ -79,26 +79,6 @@ double   ff_tget_double(GetByteContext *gb, int le);
 /** Reads a byte from the bytestream using given endianness. */
 unsigned ff_tget(GetByteContext *gb, int type, int le);
 
-/** Returns an allocated string containing count
- *  rational values using the given separator.
- */
-char *ff_trationals2str(int *rp, int count, const char *sep);
-
-/** Returns an allocated string containing count
- *  long values using the given separator.
- */
-char *ff_tlongs2str(int32_t *lp, int count, const char *sep);
-
-/** Returns an allocated string containing count
- *  double values using the given separator.
- */
-char *ff_tdoubles2str(double *dp, int count, const char *sep);
-
-/** Returns an allocated string containing count
- *  short values using the given separator.
- */
-char *ff_tshorts2str(int16_t *sp, int count, const char *sep);
-
 /** Adds count rationals converted to a string
  *  into the metadata dictionary.
  */
-- 
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 06/10] avcodec/exif: Avoid allocation for small buffer

[Andreas Rheinhardt]

Signed-off-by: Andreas Rheinhardt 
---
 libavcodec/exif.c | 19 ++-
 1 file changed, 6 insertions(+), 13 deletions(-)

diff --git a/libavcodec/exif.c b/libavcodec/exif.c
index 2874772db4..0b656fd09b 100644
--- a/libavcodec/exif.c
+++ b/libavcodec/exif.c
@@ -95,22 +95,15 @@ static int exif_decode_tag(void *logctx, GetByteContext 
*gbytes, int le,
 ret = ff_exif_decode_ifd(logctx, gbytes, le, depth + 1, metadata);
 } else {
 const char *name = exif_get_tag_name(id);
-char *use_name   = (char*) name;
-
-if (!use_name) {
-use_name = av_malloc(7);
-if (!use_name) {
-return AVERROR(ENOMEM);
-}
-snprintf(use_name, 7, "0x%04X", id);
-}
-
-ret = exif_add_metadata(logctx, count, type, use_name, NULL,
-gbytes, le, metadata);
+char buf[7];
 
 if (!name) {
-av_freep(&use_name);
+name = buf;
+snprintf(buf, sizeof(buf), "0x%04X", id);
 }
+
+ret = exif_add_metadata(logctx, count, type, name, NULL,
+gbytes, le, metadata);
 }
 
 bytestream2_seek(gbytes, cur_pos, SEEK_SET);
-- 
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 07/10] avcodec/sp5x: Remove unused quant tables

[Andreas Rheinhardt]

Only the fifth one is used.

Signed-off-by: Andreas Rheinhardt 
---
 libavcodec/mpegvideo_enc.c |  4 +-
 libavcodec/sp5x.h  | 92 +-
 libavcodec/sp5xdec.c   |  5 +--
 3 files changed, 5 insertions(+), 96 deletions(-)

diff --git a/libavcodec/mpegvideo_enc.c b/libavcodec/mpegvideo_enc.c
index 7db042e5fe..a4b00c53f7 100644
--- a/libavcodec/mpegvideo_enc.c
+++ b/libavcodec/mpegvideo_enc.c
@@ -3874,8 +3874,8 @@ static int encode_picture(MpegEncContext *s, int 
picture_number)
 for(i=1;i<64;i++){
 int j= s->idsp.idct_permutation[ff_zigzag_direct[i]];
 
-s->intra_matrix[j] = sp5x_quant_table[5*2+0][i];
-s->chroma_intra_matrix[j] = sp5x_quant_table[5*2+1][i];
+s->intra_matrix[j]= sp5x_qscale_five_quant_table[0][i];
+s->chroma_intra_matrix[j] = sp5x_qscale_five_quant_table[1][i];
 }
 s->y_dc_scale_table= y;
 s->c_dc_scale_table= c;
diff --git a/libavcodec/sp5x.h b/libavcodec/sp5x.h
index 21c45715d0..d84d851768 100644
--- a/libavcodec/sp5x.h
+++ b/libavcodec/sp5x.h
@@ -132,58 +132,8 @@ static const uint8_t sp5x_data_dht[] = {
 };
 
 
-static const uint8_t sp5x_quant_table[20][64]=
+static const uint8_t sp5x_qscale_five_quant_table[][64]=
 {
-/* index 0, Q50 */
-{  16, 11, 12, 14, 12, 10, 16, 14, 13, 14, 18, 17, 16, 19, 24, 40,
-   26, 24, 22, 22, 24, 49, 35, 37, 29, 40, 58, 51, 61, 60, 57, 51,
-   56, 55, 64, 72, 92, 78, 64, 68, 87, 69, 55, 56, 80,109, 81, 87,
-   95, 98,103,104,103, 62, 77,113,121,112,100,120, 92,101,103, 99 },
-{  17, 18, 18, 24, 21, 24, 47, 26, 26, 47, 99, 66, 56, 66, 99, 99,
-   99, 99, 99, 99, 99, 99, 99, 99, 99, 99, 99, 99, 99, 99, 99, 99,
-   99, 99, 99, 99, 99, 99, 99, 99, 99, 99, 99, 99, 99, 99, 99, 99,
-   99, 99, 99, 99, 99, 99, 99, 99, 99, 99, 99, 99, 99, 99, 99, 99 },
-
-/* index 1, Q70 */
-{  10,  7,  7,  8,  7,  6, 10,  8,  8,  8, 11, 10, 10, 11, 14, 24,
-   16, 14, 13, 13, 14, 29, 21, 22, 17, 24, 35, 31, 37, 36, 34, 31,
-   34, 33, 38, 43, 55, 47, 38, 41, 52, 41, 33, 34, 48, 65, 49, 52,
-   57, 59, 62, 62, 62, 37, 46, 68, 73, 67, 60, 72, 55, 61, 62, 59 },
-{  10, 11, 11, 14, 13, 14, 28, 16, 16, 28, 59, 40, 34, 40, 59, 59,
-   59, 59, 59, 59, 59, 59, 59, 59, 59, 59, 59, 59, 59, 59, 59, 59,
-   59, 59, 59, 59, 59, 59, 59, 59, 59, 59, 59, 59, 59, 59, 59, 59,
-   59, 59, 59, 59, 59, 59, 59, 59, 59, 59, 59, 59, 59, 59, 59, 59 },
-
-/* index 2, Q80 */
-{   6,  4,  5,  6,  5,  4,  6,  6,  5,  6,  7,  7,  6,  8, 10, 16,
-   10, 10,  9,  9, 10, 20, 14, 15, 12, 16, 23, 20, 24, 24, 23, 20,
-   22, 22, 26, 29, 37, 31, 26, 27, 35, 28, 22, 22, 32, 44, 32, 35,
-   38, 39, 41, 42, 41, 25, 31, 45, 48, 45, 40, 48, 37, 40, 41, 40 },
-{   7,  7,  7, 10,  8, 10, 19, 10, 10, 19, 40, 26, 22, 26, 40, 40,
-   40, 40, 40, 40, 40, 40, 40, 40, 40, 40, 40, 40, 40, 40, 40, 40,
-   40, 40, 40, 40, 40, 40, 40, 40, 40, 40, 40, 40, 40, 40, 40, 40,
-   40, 40, 40, 40, 40, 40, 40, 40, 40, 40, 40, 40, 40, 40, 40, 40 },
-
-/* index 3, Q85 */
-{   5,  3,  4,  4,  4,  3,  5,  4,  4,  4,  5,  5,  5,  6,  7, 12,
-8,  7,  7,  7,  7, 15, 11, 11,  9, 12, 17, 15, 18, 18, 17, 15,
-   17, 17, 19, 22, 28, 23, 19, 20, 26, 21, 17, 17, 24, 33, 24, 26,
-   29, 29, 31, 31, 31, 19, 23, 34, 36, 34, 30, 36, 28, 30, 31, 30 },
-{   5,  5,  5,  7,  6,  7, 14,  8,  8, 14, 30, 20, 17, 20, 30, 30,
-   30, 30, 30, 30, 30, 30, 30, 30, 30, 30, 30, 30, 30, 30, 30, 30,
-   30, 30, 30, 30, 30, 30, 30, 30, 30, 30, 30, 30, 30, 30, 30, 30,
-   30, 30, 30, 30, 30, 30, 30, 30, 30, 30, 30, 30, 30, 30, 30, 30 },
-
-/* index 4, Q90 */
-{   3,  2,  2,  3,  2,  2,  3,  3,  3,  3,  4,  3,  3,  4,  5,  8,
-5,  5,  4,  4,  5, 10,  7,  7,  6,  8, 12, 10, 12, 12, 11, 10,
-   11, 11, 13, 14, 18, 16, 13, 14, 17, 14, 11, 11, 16, 22, 16, 17,
-   19, 20, 21, 21, 21, 12, 15, 23, 24, 22, 20, 24, 18, 20, 21, 20 },
-{   3,  4,  4,  5,  4,  5,  9,  5,  5,  9, 20, 13, 11, 13, 20, 20,
-   20, 20, 20, 20, 20, 20, 20, 20, 20, 20, 20, 20, 20, 20, 20, 20,
-   20, 20, 20, 20, 20, 20, 20, 20, 20, 20, 20, 20, 20, 20, 20, 20,
-   20, 20, 20, 20, 20, 20, 20, 20, 20, 20, 20, 20, 20, 20, 20, 20 },
-
 /* index 5, Q60 */
 {  13,  9, 10, 11, 10,  8, 13, 11, 10, 11, 14, 14, 13, 15, 19, 32,
21, 19, 18, 18, 19, 39, 28, 30, 23, 32, 46, 41, 49, 48, 46, 41,
@@ -193,46 +143,6 @@ static const uint8_t sp5x_quant_table[20][64]=
79, 79, 79, 79, 79, 79, 79, 79, 79, 79, 79, 79, 79, 79, 79, 79,
79, 79, 79, 79, 79, 79, 79, 79, 79, 79, 79, 79, 79, 79, 79, 79,
79, 79, 79, 79, 79, 79, 79, 79, 79, 79, 79, 79, 79, 79, 79, 79 },
-
-/* index 6, Q25 */
-{  32, 22, 24, 28, 24, 20, 32, 28, 26, 28, 36, 34, 32, 38, 48, 80,
-   52, 48, 44, 44, 48, 98, 70, 74, 58, 80,116,102,122,120,114,102,
-  112,110,128,144,184,156,128,136,174,138,1

[FFmpeg-devel] [PATCH 08/10] avcodec/mpeg4videodec: Move code around to avoid forward declaration

[Andreas Rheinhardt]

Also fix the indentation of decode_studio_vol_header while at it;
it was wrong since 177133a0f4b41b3c98b9cbc7f8f45755412c537b.

Signed-off-by: Andreas Rheinhardt 
---
 libavcodec/mpeg4videodec.c | 308 ++---
 1 file changed, 152 insertions(+), 156 deletions(-)

diff --git a/libavcodec/mpeg4videodec.c b/libavcodec/mpeg4videodec.c
index c88de63f36..e364e0b493 100644
--- a/libavcodec/mpeg4videodec.c
+++ b/libavcodec/mpeg4videodec.c
@@ -49,8 +49,6 @@
 #define MB_TYPE_B_VLC_BITS 4
 #define STUDIO_INTRA_BITS 9
 
-static int decode_studio_vol_header(Mpeg4DecContext *ctx, GetBitContext *gb);
-
 static VLC dc_lum, dc_chrom;
 static VLC sprite_trajectory;
 static VLC mb_type_b_vlc;
@@ -2148,6 +2146,158 @@ static void mpeg4_load_default_matrices(MpegEncContext 
*s)
 }
 }
 
+static int read_quant_matrix_ext(MpegEncContext *s, GetBitContext *gb)
+{
+int i, j, v;
+
+if (get_bits1(gb)) {
+if (get_bits_left(gb) < 64*8)
+return AVERROR_INVALIDDATA;
+/* intra_quantiser_matrix */
+for (i = 0; i < 64; i++) {
+v = get_bits(gb, 8);
+j = s->idsp.idct_permutation[ff_zigzag_direct[i]];
+s->intra_matrix[j]= v;
+s->chroma_intra_matrix[j] = v;
+}
+}
+
+if (get_bits1(gb)) {
+if (get_bits_left(gb) < 64*8)
+return AVERROR_INVALIDDATA;
+/* non_intra_quantiser_matrix */
+for (i = 0; i < 64; i++) {
+get_bits(gb, 8);
+}
+}
+
+if (get_bits1(gb)) {
+if (get_bits_left(gb) < 64*8)
+return AVERROR_INVALIDDATA;
+/* chroma_intra_quantiser_matrix */
+for (i = 0; i < 64; i++) {
+v = get_bits(gb, 8);
+j = s->idsp.idct_permutation[ff_zigzag_direct[i]];
+s->chroma_intra_matrix[j] = v;
+}
+}
+
+if (get_bits1(gb)) {
+if (get_bits_left(gb) < 64*8)
+return AVERROR_INVALIDDATA;
+/* chroma_non_intra_quantiser_matrix */
+for (i = 0; i < 64; i++) {
+get_bits(gb, 8);
+}
+}
+
+next_start_code_studio(gb);
+return 0;
+}
+
+static void extension_and_user_data(MpegEncContext *s, GetBitContext *gb, int 
id)
+{
+uint32_t startcode;
+uint8_t extension_type;
+
+startcode = show_bits_long(gb, 32);
+if (startcode == USER_DATA_STARTCODE || startcode == EXT_STARTCODE) {
+
+if ((id == 2 || id == 4) && startcode == EXT_STARTCODE) {
+skip_bits_long(gb, 32);
+extension_type = get_bits(gb, 4);
+if (extension_type == QUANT_MATRIX_EXT_ID)
+read_quant_matrix_ext(s, gb);
+}
+}
+}
+
+static int decode_studio_vol_header(Mpeg4DecContext *ctx, GetBitContext *gb)
+{
+MpegEncContext *s = &ctx->m;
+int width, height;
+int bits_per_raw_sample;
+int rgb, chroma_format;
+
+// random_accessible_vol and video_object_type_indication have already
+// been read by the caller decode_vol_header()
+skip_bits(gb, 4); /* video_object_layer_verid */
+ctx->shape = get_bits(gb, 2); /* video_object_layer_shape */
+skip_bits(gb, 4); /* video_object_layer_shape_extension */
+skip_bits1(gb); /* progressive_sequence */
+if (ctx->shape != RECT_SHAPE) {
+avpriv_request_sample(s->avctx, "MPEG-4 Studio profile non rectangular 
shape");
+return AVERROR_PATCHWELCOME;
+}
+if (ctx->shape != BIN_ONLY_SHAPE) {
+rgb = get_bits1(gb); /* rgb_components */
+chroma_format = get_bits(gb, 2); /* chroma_format */
+if (!chroma_format || chroma_format == CHROMA_420 || (rgb && 
chroma_format == CHROMA_422)) {
+av_log(s->avctx, AV_LOG_ERROR, "illegal chroma format\n");
+return AVERROR_INVALIDDATA;
+}
+
+bits_per_raw_sample = get_bits(gb, 4); /* bit_depth */
+if (bits_per_raw_sample == 10) {
+if (rgb) {
+s->avctx->pix_fmt = AV_PIX_FMT_GBRP10;
+} else {
+s->avctx->pix_fmt = chroma_format == CHROMA_422 ? 
AV_PIX_FMT_YUV422P10 : AV_PIX_FMT_YUV444P10;
+}
+} else {
+avpriv_request_sample(s->avctx, "MPEG-4 Studio profile bit-depth 
%u", bits_per_raw_sample);
+return AVERROR_PATCHWELCOME;
+}
+if (rgb != ctx->rgb || s->chroma_format != chroma_format)
+s->context_reinit = 1;
+s->avctx->bits_per_raw_sample = bits_per_raw_sample;
+ctx->rgb = rgb;
+s->chroma_format = chroma_format;
+}
+if (ctx->shape == RECT_SHAPE) {
+check_marker(s->avctx, gb, "before video_object_layer_width");
+width  = get_bits(gb, 14); /* video_object_layer_width */
+check_marker(s->avctx, gb, "before video_object_layer_height");
+height = get_bits(gb, 14); /* video_object_layer_height */
+check_marker(s->avctx, gb, "after video_object_layer_height");
+
+/* Do the same check as non

Re: [FFmpeg-devel] [PATCH 2/2] avfilter/vf_waveform: flat_pix_fmts never used

[Andreas Rheinhardt]

Peter Ross:
> ---
>  libavfilter/vf_waveform.c | 7 ---
>  1 file changed, 7 deletions(-)
> 
> diff --git a/libavfilter/vf_waveform.c b/libavfilter/vf_waveform.c
> index 11f8c0016e..8191da2792 100644
> --- a/libavfilter/vf_waveform.c
> +++ b/libavfilter/vf_waveform.c
> @@ -303,13 +303,6 @@ static const enum AVPixelFormat 
> out_gray12_lowpass_pix_fmts[] = {
>  AV_PIX_FMT_NONE
>  };
>  
> -static const enum AVPixelFormat flat_pix_fmts[] = {
> -AV_PIX_FMT_YUV444P, AV_PIX_FMT_YUVJ444P,
> -AV_PIX_FMT_YUV444P9, AV_PIX_FMT_YUV444P10,
> -AV_PIX_FMT_YUV444P12,
> -AV_PIX_FMT_NONE
> -};
> -
>  static int query_formats(AVFilterContext *ctx)
>  {
>  WaveformContext *s = ctx->priv;
> 
> 
LGTM.

- 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 1/2] avcodec/dvenc: dv100_weight_shift never used

[Andreas Rheinhardt]

Peter Ross:
> ---
>  libavcodec/dvenc.c | 3 +--
>  1 file changed, 1 insertion(+), 2 deletions(-)
> 
> diff --git a/libavcodec/dvenc.c b/libavcodec/dvenc.c
> index 0dc290642e..233e2b68c7 100644
> --- a/libavcodec/dvenc.c
> +++ b/libavcodec/dvenc.c
> @@ -318,9 +318,8 @@ static const int dv100_qstep_inv[16] = {
>  65536,  65536,  32768,  21845,  16384,  13107,  10923,  9362,  8192, 
>  4096,  3641,  3277,  2979,  2731,  2341,  1260,
>  };
>  
> -/* DV100 weights are pre-zigzagged, inverted and multiplied by 
> 2^(dv100_weight_shift)
> +/* DV100 weights are pre-zigzagged, inverted and multiplied by 2^16
> (in DV100 the AC components are divided by the spec weights) */
> -static const int dv100_weight_shift = 16;
>  static const int dv_weight_1080[2][64] = {
>  { 8192, 65536, 65536, 61681, 61681, 61681, 58254, 58254,
>58254, 58254, 58254, 58254, 55188, 58254, 58254, 55188,
> 
> 
LGTM.

- 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 4/4] avcodec/flashsv2enc: factorize updating block dimensions

[Marton Balint]

On Tue, 19 Jan 2021, Anton Khirnov wrote:


Quoting Marton Balint (2021-01-18 21:53:30)



On Mon, 18 Jan 2021, Anton Khirnov wrote:

> Quoting Marton Balint (2021-01-10 02:20:45)
>> Signed-off-by: Marton Balint 
>> ---
>>  libavcodec/flashsv2enc.c | 76 +---
>>  1 file changed, 32 insertions(+), 44 deletions(-)
>> 
>> diff --git a/libavcodec/flashsv2enc.c b/libavcodec/flashsv2enc.c

>> index 6603d0ded1..5139b17a28 100644
>> --- a/libavcodec/flashsv2enc.c
>> +++ b/libavcodec/flashsv2enc.c
>> @@ -252,7 +259,7 @@ static av_cold int flashsv2_encode_init(AVCodecContext * 
avctx)
>>  s->use_custom_palette =  0;
>>  s->palette_type   = -1;// so that the palette will be 
generated in reconfigure_at_keyframe
>> 
>> -return 0;

>> +return update_block_dimensions(s, 64, 64);
>
> This looks different from the original value. Why the change?

Block dimensions are recalculated on every keyframe, so it does not 
matter what the block width/height is after init. 64 is used 
because the current code always selects that (see the 
optimum_block_width/height functions).


Okay, makes sense. You could mention it in the commit message, since
one would not expect a 'factorize' commit to change behaviour.


OK, applied the series with the comment added.

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

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

Re: [FFmpeg-devel] [PATCH] avpacket: RFC for ABI bump additions

[Lynne]

Jan 23, 2021, 21:42 by c...@passwd.hu:

>
>
> On Sat, 23 Jan 2021, Lynne wrote:
>
>> Jan 23, 2021, 21:04 by c...@passwd.hu:
>>
>>>
>>>
>>> On Sat, 23 Jan 2021, Lynne wrote:
>>>
 This is an RFC about the upcoming additions to the AVPacket structure
 (whose size is still part of the ABI, so we need to plan for any changes).

 The current RFC patch adds 3 fields:
     - "void *opaque;" for the user to use as they wish, same as 
 AVFrame.opaque
     - "void *opaque_ref;" for more permanent and propagating user data, 
 same as AVFrame.opaque_ref

>>>
>>> These seem legit.
>>>
     - "AVRational time_base;" which will be set to indicate the time base 
 of the packet's timestamps

>>>
>>> Why? It seems redundant and it will not be clear when to use to use 
>>> stream/bsf/etc time base and when embedded AVPacket timebase. So I don't 
>>> think this is a good idea.
>>>
>>
>> I'd like to switch to using this to avoid the dance you have to do with
>> avformat init, where you have to give it your packet's time_base in the 
>> stream time_base
>> then init, which then sets the time_base in the same field you provided your 
>> time_base,
>> and then you have to rescale the timestamps of packets to that timebase.
>>
>
> That is by design as far as I know, you set the timebase to your requested 
> time base, if the format supports that then you are happy, if not, then you 
> convert.
>

You can still keep the mechanism, since it's init time, but what's
the problem with letting lavf convert the timestamps for you if they don't
match? It wouldn't break any behavior apart from what's currently 
improper API usage. And it would make the API much more usable, as
most users just want to mux at the FFMIN(muxer_max_tb, incoming_stream_tb)
rather than a specific timebase.

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

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

Re: [FFmpeg-devel] [PATCH 05/10] avcodec/tiff_common: Remove declarations of inexistent functions

[Paul B Mahol]

LGTM
___
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 07/39] avcodec/rl: Allow to create only a few VLC tables

[Andreas Rheinhardt]

Andreas Rheinhardt:
> It is not uncommon that only the first one is used; this is similar to
> ff_init_2d_vlc_rl().
> 
> Signed-off-by: Andreas Rheinhardt 
> ---
>  libavcodec/rl.c | 3 +++
>  libavcodec/rl.h | 8 
>  2 files changed, 11 insertions(+)
> 
> diff --git a/libavcodec/rl.c b/libavcodec/rl.c
> index c532b5bf56..93153ff723 100644
> --- a/libavcodec/rl.c
> +++ b/libavcodec/rl.c
> @@ -80,6 +80,9 @@ av_cold void ff_rl_init_vlc(RLTable *rl, unsigned 
> static_size)
>  int qmul = q * 2;
>  int qadd = (q - 1) | 1;
>  
> +if (!rl->rl_vlc[q])
> +return;
> +
>  if (q == 0) {
>  qmul = 1;
>  qadd = 0;
> diff --git a/libavcodec/rl.h b/libavcodec/rl.h
> index a83debccf7..26e0b32a90 100644
> --- a/libavcodec/rl.h
> +++ b/libavcodec/rl.h
> @@ -68,6 +68,14 @@ void ff_rl_init_vlc(RLTable *rl, unsigned static_size);
>  }\
>  }
>  
> +#define INIT_FIRST_VLC_RL(rl, static_size)  \
> +do {\
> +static RL_VLC_ELEM rl_vlc_table[static_size];   \
> +\
> +rl.rl_vlc[0] = rl_vlc_table;\
> +ff_rl_init_vlc(&rl, static_size);   \
> +} while (0)
> +
>  static inline int get_rl_index(const RLTable *rl, int last, int run, int 
> level)
>  {
>  int index;
> 
Will apply all the patches up until #26 tomorrow unless there are
objections.

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

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

[FFmpeg-devel] [PATCH 6/6] avformat/flvdec: Check for EOF in loop in flv_data_packet()

[Michael Niedermayer]

Fixes: Timeout
Fixes: 
29656/clusterfuzz-testcase-minimized-ffmpeg_dem_FLV_fuzzer-5840098987999232

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

diff --git a/libavformat/flvdec.c b/libavformat/flvdec.c
index 4bc5e15dd2..02797e1fba 100644
--- a/libavformat/flvdec.c
+++ b/libavformat/flvdec.c
@@ -909,6 +909,11 @@ static int flv_data_packet(AVFormatContext *s, AVPacket 
*pkt,
 
 while (array || (ret = amf_get_string(pb, buf, sizeof(buf))) > 0) {
 AMFDataType type = avio_r8(pb);
+if (avio_feof(pb)) {
+ret = AVERROR_INVALIDDATA;
+goto skip;
+}
+
 if (type == AMF_DATA_TYPE_STRING && (array || !strcmp(buf, "text"))) {
 length = avio_rb16(pb);
 ret= av_get_packet(pb, pkt, length);
-- 
2.17.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] avformat/flvdec: Check for nesting depth in amf_parse_object()

[Michael Niedermayer]

Fixes: out of array access
Fixes: 
29202/clusterfuzz-testcase-minimized-ffmpeg_dem_KUX_fuzzer-5112845840809984

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

diff --git a/libavformat/flvdec.c b/libavformat/flvdec.c
index 07ef342278..e15be0a221 100644
--- a/libavformat/flvdec.c
+++ b/libavformat/flvdec.c
@@ -41,6 +41,8 @@
 
 #define RESYNC_BUFFER_SIZE (1<<20)
 
+#define MAX_DEPTH 10
+
 typedef struct FLVContext {
 const AVClass *class; ///< Class for private options.
 int trust_metadata;   ///< configure streams according onMetaData
@@ -493,6 +495,9 @@ static int amf_parse_object(AVFormatContext *s, AVStream 
*astream,
 double num_val;
 amf_date date;
 
+if (depth > MAX_DEPTH)
+return AVERROR_PATCHWELCOME;
+
 num_val  = 0;
 ioc  = s->pb;
 if (avio_feof(ioc))
-- 
2.17.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] avpacket: RFC for ABI bump additions

[Marton Balint]

On Sat, 23 Jan 2021, Lynne wrote:


Jan 23, 2021, 21:42 by c...@passwd.hu:




On Sat, 23 Jan 2021, Lynne wrote:


Jan 23, 2021, 21:04 by c...@passwd.hu:




On Sat, 23 Jan 2021, Lynne wrote:


This is an RFC about the upcoming additions to the AVPacket structure
(whose size is still part of the ABI, so we need to plan for any changes).

The current RFC patch adds 3 fields:
    - "void *opaque;" for the user to use as they wish, same as AVFrame.opaque
    - "void *opaque_ref;" for more permanent and propagating user data, same as 
AVFrame.opaque_ref



These seem legit.


    - "AVRational time_base;" which will be set to indicate the time base of 
the packet's timestamps



Why? It seems redundant and it will not be clear when to use to use 
stream/bsf/etc time base and when embedded AVPacket timebase. So I don't think 
this is a good idea.



I'd like to switch to using this to avoid the dance you have to do with
avformat init, where you have to give it your packet's time_base in the stream 
time_base
then init, which then sets the time_base in the same field you provided your 
time_base,
and then you have to rescale the timestamps of packets to that timebase.



That is by design as far as I know, you set the timebase to your requested time 
base, if the format supports that then you are happy, if not, then you convert.



You can still keep the mechanism, since it's init time, but what's
the problem with letting lavf convert the timestamps for you if they don't
match?


And why do you need per-AVPacket time bases for that if your packets are 
in a fixed timestamp anyway?


It wouldn't break any behavior apart from what's currently 
improper API usage. And it would make the API much more usable, as


I don't see why, you only gain that you don't have to call 
av_packet_rescale_ts() yourself.



most users just want to mux at the FFMIN(muxer_max_tb, incoming_stream_tb)
rather than a specific timebase.


The user should preferably mux audio in 1/sample_rate time base, video in 
1/frame_rate time base, and that's what ffmpeg.c does AFAIK.


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

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

[FFmpeg-devel] [PATCH 1/6] avutil/common: Add FFABSU() for a signed -> unsigned ABS

[Michael Niedermayer]

Signed-off-by: Michael Niedermayer 
---
 libavutil/common.h | 8 
 1 file changed, 8 insertions(+)

diff --git a/libavutil/common.h b/libavutil/common.h
index b9fbcc4d60..a60a558b1d 100644
--- a/libavutil/common.h
+++ b/libavutil/common.h
@@ -80,6 +80,14 @@
  */
 #define FFNABS(a) ((a) <= 0 ? (a) : (-(a)))
 
+/**
+ * Unsigned Absolute value.
+ * This takes the absolute value of a signed int and returns it as a unsigned.
+ * This also works with INT_MIN which would otherwise not be representable
+ * As with many macros, this evaluates its argument twice.
+ */
+#define FFABSU(a) ((a) <= 0 ? -(unsigned)(a) : (unsigned)(a))
+
 /**
  * Comparator.
  * For two numerical expressions x and y, gives 1 if x > y, -1 if x < y, and 0
-- 
2.17.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] tools/target_dec_fuzzer: adjust threshold for cook

[Michael Niedermayer]

Fixes: Timeout (long -> 3ms)
Fixes: 
29134/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_COOK_fuzzer-5192822695264256

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

diff --git a/tools/target_dec_fuzzer.c b/tools/target_dec_fuzzer.c
index e737d434f1..5ba138e95f 100644
--- a/tools/target_dec_fuzzer.c
+++ b/tools/target_dec_fuzzer.c
@@ -146,6 +146,7 @@ int LLVMFuzzerTestOneInput(const uint8_t *data, size_t 
size) {
 case AV_CODEC_ID_AGM: maxpixels  /= 1024;  break;
 case AV_CODEC_ID_BINKVIDEO:   maxpixels  /= 32;break;
 case AV_CODEC_ID_CFHD:maxpixels  /= 128;   break;
+case AV_CODEC_ID_COOK:maxsamples /= 1<<20; break;
 case AV_CODEC_ID_DIRAC:   maxpixels  /= 8192;  break;
 case AV_CODEC_ID_DST: maxsamples /= 1<<20; break;
 case AV_CODEC_ID_DXV: maxpixels  /= 32;break;
-- 
2.17.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]lsws/ppc/yuv2rgb: Fix transparency converting from yuv->rgb32

[Reimar Döffinger]

> On 23 Jan 2021, at 19:35, Carl Eugen Hoyos  wrote:
> 
> 
> New patch attached, thank you!
> 

Looks good to me.
I don’t know if I didn’t test the original change properly
or if compiler behaviour has changed/is different,
but this way should be more correct either way.

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

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

[FFmpeg-devel] [PATCH 5/6] avformat/flvdec: Check for nesting depth in amf_skip_tag()

[Michael Niedermayer]

Fixes: out of array access
Fixes: 
29440/clusterfuzz-testcase-minimized-ffmpeg_dem_KUX_fuzzer-5985279812960256.fuzz

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

diff --git a/libavformat/flvdec.c b/libavformat/flvdec.c
index e15be0a221..4bc5e15dd2 100644
--- a/libavformat/flvdec.c
+++ b/libavformat/flvdec.c
@@ -842,10 +842,13 @@ static void clear_index_entries(AVFormatContext *s, 
int64_t pos)
 }
 }
 
-static int amf_skip_tag(AVIOContext *pb, AMFDataType type)
+static int amf_skip_tag(AVIOContext *pb, AMFDataType type, int depth)
 {
 int nb = -1, ret, parse_name = 1;
 
+if (depth > MAX_DEPTH)
+return AVERROR_PATCHWELCOME;
+
 switch (type) {
 case AMF_DATA_TYPE_NUMBER:
 avio_skip(pb, 8);
@@ -870,7 +873,7 @@ static int amf_skip_tag(AVIOContext *pb, AMFDataType type)
 }
 avio_skip(pb, size);
 }
-if ((ret = amf_skip_tag(pb, avio_r8(pb))) < 0)
+if ((ret = amf_skip_tag(pb, avio_r8(pb), depth + 1)) < 0)
 return ret;
 }
 break;
@@ -914,7 +917,7 @@ static int flv_data_packet(AVFormatContext *s, AVPacket 
*pkt,
 else
 break;
 } else {
-if ((ret = amf_skip_tag(pb, type)) < 0)
+if ((ret = amf_skip_tag(pb, type, 0)) < 0)
 goto skip;
 }
 }
-- 
2.17.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] avcodec/apedec: Use FFABSU() in do_apply_filter()

[Michael Niedermayer]

Fixes: negation of -2147483648 cannot be represented in type 'int'; cast to an 
unsigned type to negate this value to itself
Fixes: 
29053/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_APE_fuzzer-4814432697974784

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

diff --git a/libavcodec/apedec.c b/libavcodec/apedec.c
index 8fe7b5ee86..388d851d03 100644
--- a/libavcodec/apedec.c
+++ b/libavcodec/apedec.c
@@ -1333,7 +1333,7 @@ static void do_apply_filter(APEContext *ctx, int version, 
APEFilter *f,
 /* Version 3.98 and later files */
 
 /* Update the adaption coefficients */
-absres = FFABS(res);
+absres = FFABSU(res);
 if (absres)
 *f->adaptcoeffs = APESIGN(res) *
   (8 << ((absres > f->avg * 3) + (absres > 
f->avg * 4 / 3)));
-- 
2.17.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] avpacket: RFC for ABI bump additions

[Lynne]

Jan 23, 2021, 23:12 by c...@passwd.hu:

>
>
> On Sat, 23 Jan 2021, Lynne wrote:
>
>> Jan 23, 2021, 21:42 by c...@passwd.hu:
>>
>>>
>>>
>>> On Sat, 23 Jan 2021, Lynne wrote:
>>>
 Jan 23, 2021, 21:04 by c...@passwd.hu:

>
>
> On Sat, 23 Jan 2021, Lynne wrote:
>
>> This is an RFC about the upcoming additions to the AVPacket structure
>> (whose size is still part of the ABI, so we need to plan for any 
>> changes).
>>
>> The current RFC patch adds 3 fields:
>>     - "void *opaque;" for the user to use as they wish, same as 
>> AVFrame.opaque
>>     - "void *opaque_ref;" for more permanent and propagating user data, 
>> same as AVFrame.opaque_ref
>>
>
> These seem legit.
>
>>     - "AVRational time_base;" which will be set to indicate the time 
>> base of the packet's timestamps
>>
>
> Why? It seems redundant and it will not be clear when to use to use 
> stream/bsf/etc time base and when embedded AVPacket timebase. So I don't 
> think this is a good idea.
>

 I'd like to switch to using this to avoid the dance you have to do with
 avformat init, where you have to give it your packet's time_base in the 
 stream time_base
 then init, which then sets the time_base in the same field you provided 
 your time_base,
 and then you have to rescale the timestamps of packets to that timebase.

>>>
>>> That is by design as far as I know, you set the timebase to your requested 
>>> time base, if the format supports that then you are happy, if not, then you 
>>> convert.
>>>
>>
>> You can still keep the mechanism, since it's init time, but what's
>> the problem with letting lavf convert the timestamps for you if they don't
>> match?
>>
>
> And why do you need per-AVPacket time bases for that if your packets are in a 
> fixed timestamp anyway?
>

If we don't change anything regarding the lavf API, it's exactly why this field 
was added:
So you could rescale the packet timestamps without having to match them
up to a stream. In my code the muxer loop just gets packets from encoders via a 
FIFO
and has to match them up to whatever stream the encoder was registered to use,
then look up its time base and rescale from that timebase. Currently I just use 
some
leftover fields as a hack, and while I could just carry that info in an 
opaque_ref,
it would be neater to just have all the info necessary to rescale every 
packet's timestamps
in the packet itself.
___
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] avformat/swfdec: Check outlen before allocation

[Michael Niedermayer]

On Sat, Jan 23, 2021 at 03:29:38PM +0100, Anton Khirnov wrote:
> Quoting Michael Niedermayer (2021-01-22 15:09:47)
> > Fixes: Timeout (too long -> 241ms)
> > Fixes: 
> > 29083/clusterfuzz-testcase-minimized-ffmpeg_dem_SWF_fuzzer-6273684478230528
> > 
> > Found-by: continuous fuzzing process 
> > https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
> > Signed-off-by: Michael Niedermayer 
> > ---
> >  libavformat/swfdec.c | 3 +++
> >  1 file changed, 3 insertions(+)
> > 
> > diff --git a/libavformat/swfdec.c b/libavformat/swfdec.c
> > index 1463f0ad4d..aa4be88f91 100644
> > --- a/libavformat/swfdec.c
> > +++ b/libavformat/swfdec.c
> > @@ -367,6 +367,9 @@ static int swf_read_packet(AVFormatContext *s, AVPacket 
> > *pkt)
> >  ff_dlog(s, "bitmap: ch=%d fmt=%d %dx%d (linesize=%d) 
> > len=%d->%ld pal=%d\n",
> >  ch_id, bmp_fmt, width, height, linesize, len, out_len, 
> > colormapsize);
> >  
> > +if (len * 17373LL < out_len)
> 
> Where does the magic number come from?

A very quick simulation of the best case compression for "compress"
below is not nice written code as i did not expect I or anyone else
would ever see it again

I would have preferred some nicer expression or course, but thats
what it seems to be asymptotically. For smaller amounts of data a
tighter bound is possible but i saw no nice way to consider that 
and it seems also overkill to try to do it more fine grained for
just this 

main(){
int64_t bits = 0;
int bank = 256;
int bitbank = 8;
for(unsigned i = 0; i<1024*1024*1024*4U-10;) {
int word_size = bank-255;
i += word_size;
bits += bitbank;

if (!(bank & (bank-1)))
bitbank ++;
bank++;
if (bitbank > 16) {
printf("BEST %f \n", 8.0 * i / bits );
bank = 256;
bitbank = 8;
}
}
}

above assumes i remembered correctly how the algorithm works but the
value was close to what actual compession of zeros gave


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

The misfortune of the wise is better than the prosperity of the fool.
-- Epicurus


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

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

Re: [FFmpeg-devel] [PATCH v3] avformat/hls: change sequence number type to int64_t

[Steven Liu]

"zhilizhao(赵志立)"  于2021年1月22日周五 下午9:24写道：
>
>
>
> > On Jan 22, 2021, at 4:10 PM, Steven Liu  wrote:
> >
> > "zhilizhao(赵志立)"  于2021年1月22日周五 下午3:17写道：
> >>
> >> Ping for review.
> >
> > looks no objections?
>
> Please help merge the patch, thanks!

Pushed, thanks Zhili and thanks all the reviewers :)
>
> >>
> >>> On Jan 16, 2021, at 11:40 AM, Zhao Zhili  wrote:
> >>>
> >>> Fix atoi() overflow for large EXT-X-MEDIA-SEQUENCE.
> >>>
> >>> The spec says the type of sequence number is uint64_t. Use int64_t
> >>> here since current implementation requires it to be signed integer,
> >>> and hlsenc use int64_t too.
> >>> ---
> >>> v3:
> >>> handle MEDIA-SEQUENCE higher than INT64_MAX
> >>>
> >>> v2:
> >>> AV_WB32 -> AV_WB64
> >>>
> >>> libavformat/hls.c | 56 +++
> >>> 1 file changed, 32 insertions(+), 24 deletions(-)
> >>>
> >>> diff --git a/libavformat/hls.c b/libavformat/hls.c
> >>> index 619e4800de..af2468ad9b 100644
> >>> --- a/libavformat/hls.c
> >>> +++ b/libavformat/hls.c
> >>> @@ -112,13 +112,13 @@ struct playlist {
> >>>int finished;
> >>>enum PlaylistType type;
> >>>int64_t target_duration;
> >>> -int start_seq_no;
> >>> +int64_t start_seq_no;
> >>>int n_segments;
> >>>struct segment **segments;
> >>>int needed;
> >>>int broken;
> >>> -int cur_seq_no;
> >>> -int last_seq_no;
> >>> +int64_t cur_seq_no;
> >>> +int64_t last_seq_no;
> >>>int m3u8_hold_counters;
> >>>int64_t cur_seg_offset;
> >>>int64_t last_load_time;
> >>> @@ -199,7 +199,7 @@ typedef struct HLSContext {
> >>>int n_renditions;
> >>>struct rendition **renditions;
> >>>
> >>> -int cur_seq_no;
> >>> +int64_t cur_seq_no;
> >>>int m3u8_hold_counters;
> >>>int live_start_index;
> >>>int first_packet;
> >>> @@ -722,7 +722,7 @@ static int parse_playlist(HLSContext *c, const char 
> >>> *url,
> >>>int is_http = av_strstart(url, "http", NULL);
> >>>struct segment **prev_segments = NULL;
> >>>int prev_n_segments = 0;
> >>> -int prev_start_seq_no = -1;
> >>> +int64_t prev_start_seq_no = -1;
> >>>
> >>>if (is_http && !in && c->http_persistent && c->playlist_pb) {
> >>>in = c->playlist_pb;
> >>> @@ -808,10 +808,17 @@ static int parse_playlist(HLSContext *c, const char 
> >>> *url,
> >>>goto fail;
> >>>pls->target_duration = strtoll(ptr, NULL, 10) * AV_TIME_BASE;
> >>>} else if (av_strstart(line, "#EXT-X-MEDIA-SEQUENCE:", &ptr)) {
> >>> +uint64_t seq_no;
> >>>ret = ensure_playlist(c, &pls, url);
> >>>if (ret < 0)
> >>>goto fail;
> >>> -pls->start_seq_no = atoi(ptr);
> >>> +seq_no = strtoull(ptr, NULL, 10);
> >>> +if (seq_no > INT64_MAX) {
> >>> +av_log(c->ctx, AV_LOG_DEBUG, "MEDIA-SEQUENCE higher than 
> >>> "
> >>> +"INT64_MAX, mask out the highest bit\n");
> >>> +seq_no &= INT64_MAX;
> >>> +}
> >>> +pls->start_seq_no = seq_no;
> >>>} else if (av_strstart(line, "#EXT-X-PLAYLIST-TYPE:", &ptr)) {
> >>>ret = ensure_playlist(c, &pls, url);
> >>>if (ret < 0)
> >>> @@ -832,9 +839,9 @@ static int parse_playlist(HLSContext *c, const char 
> >>> *url,
> >>>if (has_iv) {
> >>>memcpy(cur_init_section->iv, iv, sizeof(iv));
> >>>} else {
> >>> -int seq = pls->start_seq_no + pls->n_segments;
> >>> +int64_t seq = pls->start_seq_no + pls->n_segments;
> >>>memset(cur_init_section->iv, 0, 
> >>> sizeof(cur_init_section->iv));
> >>> -AV_WB32(cur_init_section->iv + 12, seq);
> >>> +AV_WB64(cur_init_section->iv + 8, seq);
> >>>}
> >>>
> >>>if (key_type != KEY_NONE) {
> >>> @@ -889,9 +896,9 @@ static int parse_playlist(HLSContext *c, const char 
> >>> *url,
> >>>if (has_iv) {
> >>>memcpy(seg->iv, iv, sizeof(iv));
> >>>} else {
> >>> -int seq = pls->start_seq_no + pls->n_segments;
> >>> +int64_t seq = pls->start_seq_no + pls->n_segments;
> >>>memset(seg->iv, 0, sizeof(seg->iv));
> >>> -AV_WB32(seg->iv + 12, seq);
> >>> +AV_WB64(seg->iv + 8, seq);
> >>>}
> >>>
> >>>if (key_type != KEY_NONE) {
> >>> @@ -954,16 +961,17 @@ static int parse_playlist(HLSContext *c, const char 
> >>> *url,
> >>>if (prev_segments) {
> >>>if (pls->start_seq_no > prev_start_seq_no && c->first_timestamp != 
> >>> AV_NOPTS_VALUE) {
> >>>int64_t prev_timestamp = c->first_timestamp;
> >>> -int i, diff = pls->start_seq_no - prev_start_seq_no;
> >>> +int i;
> >>> +int64_t diff = pls->start_seq_no - prev_start_seq_no;
> >>>

Re: [FFmpeg-devel] [PATCH 03/10] avcodec/vp8data: Remove unused array

[Peter Ross]

On Sat, Jan 23, 2021 at 09:47:53PM +0100, Andreas Rheinhardt wrote:
> Unused since 748f921ad1997a464fb8963d0ba2c5bb5e036b1b.
> 
> Signed-off-by: Andreas Rheinhardt 
> ---
>  libavcodec/vp8data.h | 6 --
>  1 file changed, 6 deletions(-)
> 
> diff --git a/libavcodec/vp8data.h b/libavcodec/vp8data.h
> index 5e6dea7617..1fcce134eb 100644
> --- a/libavcodec/vp8data.h
> +++ b/libavcodec/vp8data.h
> @@ -316,12 +316,6 @@ static const uint8_t vp8_pred4x4_prob_intra[10][10][9] = 
> {
>  },
>  };
>  
> -static const int8_t vp8_segmentid_tree[][2] = {
> -{  1,  2 },
> -{ -0, -1 }, // '00', '01'
> -{ -2, -3 }, // '10', '11'
> -};
> -
>  static const uint8_t vp8_coeff_band[16] = {
>  0, 1, 2, 3, 6, 4, 5, 6, 6, 6, 6, 6, 6, 6, 6, 7
>  };

looks good

-- Peter
(A907 E02F A6E5 0CD2 34CD 20D2 6760 79C5 AC40 DD6B)
___
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".