[FFmpeg-devel] [PATCH] libavfilter/vf_colorrange_cuda: CUDA-accelerated video filter for MPEG and JPEG color range conversions

2022-09-10 Thread Roman Arzumanyan 
Hello,

This patch adds video filter which does color range conversion similar to 
swscale scaling filter.

How to use it:
./ffmpeg \
  -hwaccel cuda -hwaccel_output_format cuda \
  -i /path/to/intput/file.mp4 \
  -vf colorrange_cuda=range=mpeg \
  -c:v h264_nvenc \
  -y /path/to/output/file.mp4
From 2b15d8a609a12d97b1ba7500c7f8771b336e2fdf Mon Sep 17 00:00:00 2001
From: Roman Arzumanyan 
Date: Sat, 10 Sep 2022 11:05:56 +0300
Subject: [PATCH] libavfilter/vf_colorrange_cuda CUDA-accelerated color range
 conversion filter

---
 configure |   2 +
 libavfilter/Makefile  |   3 +
 libavfilter/allfilters.c  |   1 +
 libavfilter/vf_colorrange_cuda.c  | 432 ++
 libavfilter/vf_colorrange_cuda.cu |  93 +++
 5 files changed, 531 insertions(+)
 create mode 100644 libavfilter/vf_colorrange_cuda.c
 create mode 100644 libavfilter/vf_colorrange_cuda.cu

diff --git a/configure b/configure
index 9d6457d81b..e5f9738ad1 100755
--- a/configure
+++ b/configure
@@ -3155,6 +3155,8 @@ transpose_npp_filter_deps="ffnvcodec libnpp"
 overlay_cuda_filter_deps="ffnvcodec"
 overlay_cuda_filter_deps_any="cuda_nvcc cuda_llvm"
 sharpen_npp_filter_deps="ffnvcodec libnpp"
+colorrange_cuda_filter_deps="ffnvcodec"
+colorrange_cuda_filter_deps_any="cuda_nvcc cuda_llvm"
 
 amf_deps_any="libdl LoadLibrary"
 nvenc_deps="ffnvcodec"
diff --git a/libavfilter/Makefile b/libavfilter/Makefile
index 30cc329fb6..784e154d81 100644
--- a/libavfilter/Makefile
+++ b/libavfilter/Makefile
@@ -230,6 +230,9 @@ OBJS-$(CONFIG_COLORMAP_FILTER)   += vf_colormap.o
 OBJS-$(CONFIG_COLORMATRIX_FILTER)+= vf_colormatrix.o
 OBJS-$(CONFIG_COLORSPACE_FILTER) += vf_colorspace.o colorspacedsp.o
 OBJS-$(CONFIG_COLORTEMPERATURE_FILTER)   += vf_colortemperature.o
+OBJS-$(CONFIG_COLORRANGE_CUDA_FILTER)+= vf_colorrange_cuda.o \
+vf_colorrange_cuda.ptx.o \
+cuda/load_helper.o
 OBJS-$(CONFIG_CONVOLUTION_FILTER)+= vf_convolution.o
 OBJS-$(CONFIG_CONVOLUTION_OPENCL_FILTER) += vf_convolution_opencl.o opencl.o \
 opencl/convolution.o
diff --git a/libavfilter/allfilters.c b/libavfilter/allfilters.c
index 5ebacfde27..5e9cbe57ec 100644
--- a/libavfilter/allfilters.c
+++ b/libavfilter/allfilters.c
@@ -213,6 +213,7 @@ extern const AVFilter ff_vf_colormap;
 extern const AVFilter ff_vf_colormatrix;
 extern const AVFilter ff_vf_colorspace;
 extern const AVFilter ff_vf_colortemperature;
+extern const AVFilter ff_vf_colorrange_cuda;
 extern const AVFilter ff_vf_convolution;
 extern const AVFilter ff_vf_convolution_opencl;
 extern const AVFilter ff_vf_convolve;
diff --git a/libavfilter/vf_colorrange_cuda.c b/libavfilter/vf_colorrange_cuda.c
new file mode 100644
index 00..949e7d3bbf
--- /dev/null
+++ b/libavfilter/vf_colorrange_cuda.c
@@ -0,0 +1,432 @@
+/*
+ * Copyright (c) 2022, NVIDIA CORPORATION. All rights reserved.
+ *
+ * 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.
+ */
+
+#include 
+
+#include "libavutil/avstring.h"
+#include "libavutil/common.h"
+#include "libavutil/cuda_check.h"
+#include "libavutil/hwcontext.h"
+#include "libavutil/hwcontext_cuda_internal.h"
+#include "libavutil/internal.h"
+#include "libavutil/opt.h"
+#include "libavutil/pixdesc.h"
+
+#include "avfilter.h"
+#include "formats.h"
+#include "internal.h"
+#include "scale_eval.h"
+#include "video.h"
+
+#include "cuda/load_helper.h"
+
+static const enum AVPixelFormat supported_formats[] = {
+AV_PIX_FMT_NV12,
+AV_PIX_FMT_YUV420P,
+AV_PIX_FMT_YUV444P,
+};
+
+#define DIV_UP(a, b) (((a) + (b)-1) / (b))
+#define BLOCKX 32
+#define BLOCKY 16
+
+#define CHECK_CU(x) FF_CUDA_CHECK_DL(ctx, s->hwctx->internal->cuda_dl, x)
+
+typedef struct CUDAConvContext {
+const AVClass* class;
+
+AVCUDADeviceContext* hwctx;
+

Re: [FFmpeg-devel] [PATCH v2] avcodec/jpeg2000: Add support for High-Throughput JPEG 2000 (HTJ2K) decoding.

2022-09-10 Thread Caleb Etemesi 
Ideally, what I wanted to achieve was following best practices of what I
saw,

most of the error reporting inside jpeg2000dec.c would log errors using
s->avctx, in case of things like corrupt bitstream errors, I did want also
the htj2k code to emulate this, and the only reason its present in
jpeg2000_decode_ctx_vlc was for it to report in case I read out of bounds,
(it was to replace the assert0(index < 1024))

That's the only reason I need a Jpeg2000DecoderContext in jpeg2000htdec.c

I later learnt you can pass NULL to av_log, and used that to report invalid
bit reads e.g at
https://github.com/etemesi254/FFmpeg/blob/87de24efb472c1cf60d920c433d710cf95a64ea5/libavcodec/jpeg2000htdec.c#L189-L191
since I saw the call stack was too deep to justify me passing around
Jpeg2000DecoderContext everywhere.

So since I'll be making changes to address these issues, what are your
thoughts?

For the circular reference, I forgot about inclusion guards, sorry about
that.

Regards,
Caleb





On Sat, Sep 10, 2022 at 12:34 AM Andreas Rheinhardt <
andreas.rheinha...@outlook.com> wrote:

> Caleb Etemesi:
> >> This is unneeded for the encoder
> >> maybe a jpeg2000dec.h would be better for this
> >> also code moving should be in a seperate patch
> >> from functional changes
> >
> >
> > This will be a circular dependence, since jpeg2000htdec.h needs the
> decoder
> > context, and jpeg2000.c needs jpeg2000htdec.c.
> >
>
> It seems like the only use of the decoder context in jpeg2000htdec.h is
> in jpeg2000_decode_ctx_vlc() where the Jpeg2000DecoderContext is not
> even used at all. And I fail to see the circular dependency even if
> jpeg2000htdec.h needed the decoder context: after all, you are not
> adding an inclusion of jpeg2000htdec.h to jpeg2000.h, so jpeg2000dec.h
> will also not include jpeg2000htdec.h.
>
> >
> > On Fri, 9 Sept 2022, 19:52 Caleb Etemesi, 
> wrote:
> >
> >> Will address in the next iteration
> >>
> >> On Fri, 9 Sept 2022, 18:46 Michael Niedermayer,  >
> >> wrote:
> >>
> >>> On Thu, Sep 08, 2022 at 11:49:53PM +0300, etemesica...@gmail.com
> wrote:
>  From: caleb 
> 
>  Rebased this patch on master branch
>  ---
>   libavcodec/Makefile|2 +-
>   libavcodec/j2kenc.c|   26 +-
>   libavcodec/jpeg2000.h  |  103 ++-
>   libavcodec/jpeg2000dec.c   |  193 ++
>   libavcodec/jpeg2000htdec.c | 1212
> 
>   libavcodec/jpeg2000htdec.h |  210 +++
>   6 files changed, 1599 insertions(+), 147 deletions(-)
>   create mode 100644 libavcodec/jpeg2000htdec.c
>   create mode 100644 libavcodec/jpeg2000htdec.h
> 
>  diff --git a/libavcodec/Makefile b/libavcodec/Makefile
>  index 945908e3b8..ecf5c47cad 100644
>  --- a/libavcodec/Makefile
>  +++ b/libavcodec/Makefile
>  @@ -450,7 +450,7 @@ OBJS-$(CONFIG_JACOSUB_DECODER) +=
> >>> jacosubdec.o ass.o
>   OBJS-$(CONFIG_JPEG2000_ENCODER)+= j2kenc.o mqcenc.o mqc.o
> >>> jpeg2000.o \
> jpeg2000dwt.o
>   OBJS-$(CONFIG_JPEG2000_DECODER)+= jpeg2000dec.o jpeg2000.o
> >>> jpeg2000dsp.o \
>  -  jpeg2000dwt.o mqcdec.o
> mqc.o
>  +  jpeg2000dwt.o mqcdec.o
> mqc.o
> >>> jpeg2000htdec.o
>   OBJS-$(CONFIG_JPEGLS_DECODER)  += jpeglsdec.o jpegls.o
>   OBJS-$(CONFIG_JPEGLS_ENCODER)  += jpeglsenc.o jpegls.o
>   OBJS-$(CONFIG_JV_DECODER)  += jvdec.o
>  diff --git a/libavcodec/j2kenc.c b/libavcodec/j2kenc.c
>  index e883d5deb7..233d75e96d 100644
>  --- a/libavcodec/j2kenc.c
>  +++ b/libavcodec/j2kenc.c
>  @@ -106,7 +106,7 @@ static const int dwt_norms[2][4][10] = { //
> >>> [dwt_type][band][rlevel] (multiplied
>   typedef struct {
>  Jpeg2000Component *comp;
>  double *layer_rates;
>  -} Jpeg2000Tile;
>  +} Jpeg2000EncTile;
> 
>   typedef struct {
>   AVClass *class;
>  @@ -131,7 +131,7 @@ typedef struct {
>   Jpeg2000CodingStyle codsty;
>   Jpeg2000QuantStyle  qntsty;
> 
>  -Jpeg2000Tile *tile;
>  +Jpeg2000EncTile *tile;
>   int layer_rates[100];
>   uint8_t compression_rate_enc; ///< Is compression done using
> >>> compression ratio?
> 
>  @@ -427,7 +427,7 @@ static void compute_rates(Jpeg2000EncoderContext*
> s)
>   int layno, compno;
>   for (i = 0; i < s->numYtiles; i++) {
>   for (j = 0; j < s->numXtiles; j++) {
>  -Jpeg2000Tile *tile = &s->tile[s->numXtiles * i + j];
>  +Jpeg2000EncTile *tile = &s->tile[s->numXtiles * i + j];
>   for (compno = 0; compno < s->ncomponents; compno++) {
>   int tilew = tile->comp[compno].coord[0][1] -
> >>> tile->comp[compno].coord[0][0];
>   int tileh = tile->comp[compno].coord[1][1] -
>

Re: [FFmpeg-devel] [PATCH v4 0/2] 32bps FLAC patches

2022-09-10 Thread Martijn van Beurden 
Op za 3 sep. 2022 om 11:21 schreef Martijn van Beurden :

> Recently libFLAC gained the ability (not in any released version yet
> though) to create FLAC files containing 32-bit int PCM samples. To
> keep complexity reasonable, the choice was made to limit residuals
> to 32-bit integers, which the encoder must make sure of. In case
> the encoder cannot find any predictor of which the residuals fit
> this limit, it must default to using a verbatim subframe. Tests have
> shown that this does not happen often (<0.1% of subframes on a
> music corpus of various styles). See also discussion here:
> https://github.com/ietf-wg-cellar/flac-specification/pull/148
>
> These two patches implement decoding and encoding following this
> format.
>
> Changes since v1:
> fix copy-paste error in encoder, several invocations of
> lpc_encode_choose_datapath used wrong parameters, making FATE fail as
> compression was less than it should be
>
> Changes since v2:
> Rebased decoder part as it didn't apply anymore
>
> Changes since v3:
> Moved put_golomb part to flacenc.c (as it is now quite specific to FLAC)
> and renamed put_sbits64 to put_sbits63 (and changed assert accordingly)
>
> Martijn van Beurden (2):
>   libavcodec/flacdec: Implement decoding of 32 bit-per-sample PCM
>   libavcodec/flacenc: Implement encoding of 32 bit-per-sample PCM
>
>  libavcodec/flac.c   |   4 +-
>  libavcodec/flacdec.c| 248 +--
>  libavcodec/flacenc.c| 519 
>  libavcodec/get_bits.h   |  12 +
>  libavcodec/mathops.h|   9 +
>  libavcodec/put_bits.h   |   7 +
>  libavcodec/put_golomb.h |  14 --
>  7 files changed, 674 insertions(+), 139 deletions(-)
>
> --
> 2.30.2
>
>
Perhaps a little early for a reminder, sorry about that. I'd just like to
add to the above email that the FLAC reference implementation, libFLAC, has
had a release yesterday including the functionality of these patches
(encoding/decoder of 32 bps audio).
___
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/riffdec: don't unconditionally overwrite WAVEFORMATEXTENSIBLE layout

2022-09-10 Thread James Almer 
Do it only if the value conflicts with the previous channels value.
Fixes ticket #9912

Signed-off-by: James Almer 
---
 libavformat/riffdec.c | 12 +---
 1 file changed, 9 insertions(+), 3 deletions(-)

diff --git a/libavformat/riffdec.c b/libavformat/riffdec.c
index 3946ecb72f..aef6b6625a 100644
--- a/libavformat/riffdec.c
+++ b/libavformat/riffdec.c
@@ -102,6 +102,8 @@ int ff_get_wav_header(AVFormatContext *s, AVIOContext *pb,
 return AVERROR_INVALIDDATA;
 }
 
+av_channel_layout_uninit(&par->ch_layout);
+
 par->codec_type  = AVMEDIA_TYPE_AUDIO;
 if (!big_endian) {
 id = avio_rl16(pb);
@@ -189,9 +191,13 @@ int ff_get_wav_header(AVFormatContext *s, AVIOContext *pb,
 if (par->codec_id == AV_CODEC_ID_ADPCM_G726 && par->sample_rate)
 par->bits_per_coded_sample = par->bit_rate / par->sample_rate;
 
-av_channel_layout_uninit(&par->ch_layout);
-par->ch_layout.order   = AV_CHANNEL_ORDER_UNSPEC;
-par->ch_layout.nb_channels = channels;
+/* ignore WAVEFORMATEXTENSIBLE layout if different from channel count */
+if (par->ch_layout.order == AV_CHANNEL_ORDER_NATIVE &&
+channels != par->ch_layout.nb_channels) {
+av_channel_layout_uninit(&par->ch_layout);
+par->ch_layout.order   = AV_CHANNEL_ORDER_UNSPEC;
+par->ch_layout.nb_channels = channels;
+}
 
 return 0;
 }
-- 
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] libavfilter/vf_colorrange_cuda: CUDA-accelerated video filter for MPEG and JPEG color range conversions

2022-09-10 Thread Timo Rothenpieler 

On 10.09.2022 10:16, Roman Arzumanyan wrote:

From 2b15d8a609a12d97b1ba7500c7f8771b336e2fdf Mon Sep 17 00:00:00 2001
From: Roman Arzumanyan 
Date: Sat, 10 Sep 2022 11:05:56 +0300
Subject: [PATCH] libavfilter/vf_colorrange_cuda CUDA-accelerated color range
 conversion filter


We could also call this colorspace_cuda, since it does overlap with what 
the colorspace software filter does, just not nearly to the same degree 
of feature-completeness.
That's fine in my book though, and if someone cares enough, the other 
features of the colorspace filter can be added over time.



---
 configure |   2 +
 libavfilter/Makefile  |   3 +
 libavfilter/allfilters.c  |   1 +
 libavfilter/vf_colorrange_cuda.c  | 432 ++
 libavfilter/vf_colorrange_cuda.cu |  93 +++
 5 files changed, 531 insertions(+)
 create mode 100644 libavfilter/vf_colorrange_cuda.c
 create mode 100644 libavfilter/vf_colorrange_cuda.cu

diff --git a/configure b/configure
index 9d6457d81b..e5f9738ad1 100755
--- a/configure
+++ b/configure
@@ -3155,6 +3155,8 @@ transpose_npp_filter_deps="ffnvcodec libnpp"
 overlay_cuda_filter_deps="ffnvcodec"
 overlay_cuda_filter_deps_any="cuda_nvcc cuda_llvm"
 sharpen_npp_filter_deps="ffnvcodec libnpp"
+colorrange_cuda_filter_deps="ffnvcodec"
+colorrange_cuda_filter_deps_any="cuda_nvcc cuda_llvm"


Typically should be sorted in by alphapetical ordering.


 amf_deps_any="libdl LoadLibrary"
 nvenc_deps="ffnvcodec"
diff --git a/libavfilter/Makefile b/libavfilter/Makefile
index 30cc329fb6..784e154d81 100644
--- a/libavfilter/Makefile
+++ b/libavfilter/Makefile
@@ -230,6 +230,9 @@ OBJS-$(CONFIG_COLORMAP_FILTER)   += 
vf_colormap.o
 OBJS-$(CONFIG_COLORMATRIX_FILTER)+= vf_colormatrix.o
 OBJS-$(CONFIG_COLORSPACE_FILTER) += vf_colorspace.o colorspacedsp.o
 OBJS-$(CONFIG_COLORTEMPERATURE_FILTER)   += vf_colortemperature.o
+OBJS-$(CONFIG_COLORRANGE_CUDA_FILTER)+= vf_colorrange_cuda.o \
+vf_colorrange_cuda.ptx.o \
+cuda/load_helper.o


Same here on alphabetical ordering, should be between colormatrix and 
colorspace.



 OBJS-$(CONFIG_CONVOLUTION_FILTER)+= vf_convolution.o
 OBJS-$(CONFIG_CONVOLUTION_OPENCL_FILTER) += vf_convolution_opencl.o 
opencl.o \
 opencl/convolution.o
diff --git a/libavfilter/allfilters.c b/libavfilter/allfilters.c
index 5ebacfde27..5e9cbe57ec 100644
--- a/libavfilter/allfilters.c
+++ b/libavfilter/allfilters.c
@@ -213,6 +213,7 @@ extern const AVFilter ff_vf_colormap;
 extern const AVFilter ff_vf_colormatrix;
 extern const AVFilter ff_vf_colorspace;
 extern const AVFilter ff_vf_colortemperature;
+extern const AVFilter ff_vf_colorrange_cuda;
 extern const AVFilter ff_vf_convolution;
 extern const AVFilter ff_vf_convolution_opencl;
 extern const AVFilter ff_vf_convolve;
diff --git a/libavfilter/vf_colorrange_cuda.c b/libavfilter/vf_colorrange_cuda.c
new file mode 100644
index 00..949e7d3bbf
--- /dev/null
+++ b/libavfilter/vf_colorrange_cuda.c
@@ -0,0 +1,432 @@
+/*
+ * Copyright (c) 2022, NVIDIA CORPORATION. All rights reserved.
+ *
+ * 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.
+ */
+
+#include 
+
+#include "libavutil/avstring.h"
+#include "libavutil/common.h"
+#include "libavutil/cuda_check.h"
+#include "libavutil/hwcontext.h"
+#include "libavutil/hwcontext_cuda_internal.h"
+#include "libavutil/internal.h"
+#include "libavutil/opt.h"
+#include "libavutil/pixdesc.h"
+
+#include "avfilter.h"
+#include "formats.h"
+#include "internal.h"
+#include "scale_eval.h"
+#include "video.h"
+
+#include "cuda/load_helper.h"
+
+static const enum AVPixelFormat supported_formats[] = {
+AV_PIX_FMT_NV12,
+AV_PIX_FMT_YUV420P,
+AV_PIX_FMT_YUV444P,
+};
+
+#define DIV_UP(a, b) (((a) + (b)-1) / (b))
+#define BLOC

Re: [FFmpeg-devel] [PATCH v4 0/2] 32bps FLAC patches

2022-09-10 Thread Paul B Mahol 
On Sat, Sep 10, 2022 at 12:33 PM Martijn van Beurden 
wrote:

> Op za 3 sep. 2022 om 11:21 schreef Martijn van Beurden :
>
> > Recently libFLAC gained the ability (not in any released version yet
> > though) to create FLAC files containing 32-bit int PCM samples. To
> > keep complexity reasonable, the choice was made to limit residuals
> > to 32-bit integers, which the encoder must make sure of. In case
> > the encoder cannot find any predictor of which the residuals fit
> > this limit, it must default to using a verbatim subframe. Tests have
> > shown that this does not happen often (<0.1% of subframes on a
> > music corpus of various styles). See also discussion here:
> > https://github.com/ietf-wg-cellar/flac-specification/pull/148
> >
> > These two patches implement decoding and encoding following this
> > format.
> >
> > Changes since v1:
> > fix copy-paste error in encoder, several invocations of
> > lpc_encode_choose_datapath used wrong parameters, making FATE fail as
> > compression was less than it should be
> >
> > Changes since v2:
> > Rebased decoder part as it didn't apply anymore
> >
> > Changes since v3:
> > Moved put_golomb part to flacenc.c (as it is now quite specific to FLAC)
> > and renamed put_sbits64 to put_sbits63 (and changed assert accordingly)
> >
> > Martijn van Beurden (2):
> >   libavcodec/flacdec: Implement decoding of 32 bit-per-sample PCM
> >   libavcodec/flacenc: Implement encoding of 32 bit-per-sample PCM
> >
> >  libavcodec/flac.c   |   4 +-
> >  libavcodec/flacdec.c| 248 +--
> >  libavcodec/flacenc.c| 519 
> >  libavcodec/get_bits.h   |  12 +
> >  libavcodec/mathops.h|   9 +
> >  libavcodec/put_bits.h   |   7 +
> >  libavcodec/put_golomb.h |  14 --
> >  7 files changed, 674 insertions(+), 139 deletions(-)
> >
> > --
> > 2.30.2
> >
> >
> Perhaps a little early for a reminder, sorry about that. I'd just like to
> add to the above email that the FLAC reference implementation, libFLAC, has
> had a release yesterday including the functionality of these patches
> (encoding/decoder of 32 bps audio).
>

Great, it will be merged if there are no more objections.
Could add fate test so that it does not get broken.


> ___
> 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 v2] avformat/riffdec: don't unconditionally overwrite WAVEFORMATEXTENSIBLE layout

2022-09-10 Thread James Almer 
Do it only if the value conflicts with the previous channels value.

Fixes ticket #9912

Signed-off-by: James Almer 
---
 libavformat/riffdec.c | 11 ---
 1 file changed, 8 insertions(+), 3 deletions(-)

diff --git a/libavformat/riffdec.c b/libavformat/riffdec.c
index 3946ecb72f..c1e4a04550 100644
--- a/libavformat/riffdec.c
+++ b/libavformat/riffdec.c
@@ -102,6 +102,8 @@ int ff_get_wav_header(AVFormatContext *s, AVIOContext *pb,
 return AVERROR_INVALIDDATA;
 }
 
+av_channel_layout_uninit(&par->ch_layout);
+
 par->codec_type  = AVMEDIA_TYPE_AUDIO;
 if (!big_endian) {
 id = avio_rl16(pb);
@@ -189,9 +191,12 @@ int ff_get_wav_header(AVFormatContext *s, AVIOContext *pb,
 if (par->codec_id == AV_CODEC_ID_ADPCM_G726 && par->sample_rate)
 par->bits_per_coded_sample = par->bit_rate / par->sample_rate;
 
-av_channel_layout_uninit(&par->ch_layout);
-par->ch_layout.order   = AV_CHANNEL_ORDER_UNSPEC;
-par->ch_layout.nb_channels = channels;
+/* ignore WAVEFORMATEXTENSIBLE layout if different from channel count */
+if (channels != par->ch_layout.nb_channels) {
+av_channel_layout_uninit(&par->ch_layout);
+par->ch_layout.order   = AV_CHANNEL_ORDER_UNSPEC;
+par->ch_layout.nb_channels = channels;
+}
 
 return 0;
 }
-- 
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] lavu/pixdesc: favour formats where bit depth exactly matches

2022-09-10 Thread Michael Niedermayer 
On Thu, Sep 08, 2022 at 08:46:11PM -0700, Philip Langdale wrote:
> Since introducing the various packed formats used by VAAPI (and p012),
> we've noticed that there's actually a gap in how
> av_find_best_pix_fmt_of_2 works. It doesn't actually assign any value
> to having the same bit depth as the source format, when comparing
> against formats with a higher bit depth. This usually doesn't matter,
> because av_get_padded_bits_per_pixel() will account for it.
> 
> However, as many of these formats use padding internally, we find that
> av_get_padded_bits_per_pixel() actually returns the same value for the
> 10 bit, 12, bit, 16 bit flavours, etc. In these tied situations, we end
> up just picking the first of the two provided formats, even if the
> second one should be preferred because it matches the actual bit depth.
> 
> This bug already existed if you tried to compare yuv420p10 against p016
> and p010, for example, but it simply hadn't come up before so we never
> noticed.
> 
> But now, we actually got a situation in the VAAPI VP9 decoder where it
> offers both p010 and p012 because Profile 3 could be either depth and
> ends up picking p012 for 10 bit content due to the ordering of the
> testing.
> 
> In addition, in the process of testing the fix, I realised we have the
> same gap when it comes to chroma subsampling - we do not favour a
> format that has exactly the same subsampling vs one with less
> subsampling when all else is equal.
> 
> To fix this, I'm introducing a small score penalty if the bit depth or
> subsampling doesn't exactly match the source format. This will break
> the tie in favour of the format with the exact match, but not offset
> any of the other scoring penalties we already have.
> 
> I have added a set of tests around these formats which will fail
> without this fix.
> 
> Signed-off-by: Philip Langdale 
> ---
>  libavutil/pixdesc.c   | 16 +-
>  libavutil/tests/pixfmt_best.c | 93 ---
>  tests/ref/fate/pixfmt_best|  2 +-
>  3 files changed, 89 insertions(+), 22 deletions(-)
> 
> diff --git a/libavutil/pixdesc.c b/libavutil/pixdesc.c
> index d7c6ebfdc4..412e257a30 100644
> --- a/libavutil/pixdesc.c
> +++ b/libavutil/pixdesc.c
> @@ -3004,6 +3004,11 @@ static int get_pix_fmt_score(enum AVPixelFormat 
> dst_pix_fmt,
>  if ((ret = get_pix_fmt_depth(&dst_min_depth, &dst_max_depth, 
> dst_pix_fmt)) < 0)
>  return -3;
>  
> +// Favour formats where bit depth exactly matches. If all other scoring 
> is
> +// equal, we'd rather use a lower bit depth that matches the source.
> +if (src_min_depth != dst_min_depth || src_max_depth != dst_max_depth)
> +score -= 64;

This adds a penalty for decreasing the depth, that is under FF_LOSS_DEPTH

more so if we decreas depth from 16 to 15 bit, that gives a penalty of 2
but increasing from 15 to 16 a penalty of 64. This needs an adjustment
also are we intentionally treating a increase from 14 to 15 like 14 to 16 ?
or do we want to prefer the closer ?

a FF_LOSS_EQUAL_DEPTH / DIFFERENT_DEPTH could be added to keep this more in
line with existing code


> +
>  src_color = get_color_type(src_desc);
>  dst_color = get_color_type(dst_desc);
>  if (dst_pix_fmt == AV_PIX_FMT_PAL8)
> @@ -3020,14 +3025,21 @@ static int get_pix_fmt_score(enum AVPixelFormat 
> dst_pix_fmt,
>  }
>  
>  if (consider & FF_LOSS_RESOLUTION) {
> +// Apply a large penalty if there's a loss of resolution, but also 
> apply
> +// a small penalty of the dst resolution is higher so that we favour
> +// exactly matching formats.
>  if (dst_desc->log2_chroma_w > src_desc->log2_chroma_w) {
>  loss |= FF_LOSS_RESOLUTION;
>  score -= 256 << dst_desc->log2_chroma_w;
> -}
> +} else if (dst_desc->log2_chroma_w < src_desc->log2_chroma_w)
> +score -= 32;
> +
>  if (dst_desc->log2_chroma_h > src_desc->log2_chroma_h) {
>  loss |= FF_LOSS_RESOLUTION;
>  score -= 256 << dst_desc->log2_chroma_h;
> -}
> +} else if (dst_desc->log2_chroma_h < src_desc->log2_chroma_h)
> +score -= 32;

this would favor 410 -> 411 over 410 -> 420, i dont think that choice is
correct in that specific case

i do agree though with the basic idea behind this patch

thx

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

I do not agree with what you have to say, but I'll defend to the death your
right to say it. -- Voltaire


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

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

Re: [FFmpeg-devel] [PATCH 2/2] swscale/input: Avoid calls to av_pix_fmt_desc_get()

2022-09-10 Thread Michael Niedermayer 
On Fri, Sep 09, 2022 at 08:15:22PM +0200, Andreas Rheinhardt wrote:
> Michael Niedermayer:
> > On Thu, Sep 08, 2022 at 11:44:51PM +0200, Andreas Rheinhardt wrote:
> >> Michael Niedermayer:
> >>> On Thu, Sep 08, 2022 at 09:38:51PM +0200, Andreas Rheinhardt wrote:
>  Michael Niedermayer:
> > [...]
> >>> To me if i look at the evolution
> >>> of isBE() / code checking BE-ness it become more messy over time
> >>>
> >>> I think it would be interresting to think about if we can make
> >>> av_pix_fmt_desc_get(compile time constant) work at compile time.
> >>> or if we maybe can return to a simpler implementation
> >>>
> >>
> >> We could put the av_pix_fmt_descriptors array into an internal header
> >> and use something like
> >>
> >> static av_always_inline const AVPixFmtDescriptor
> >> *ff_pix_fmt_descriptor_get(enum AVPixelFormat fmt)
> >> {
> >> if (av_builtin_constant_p(fmt))
> >> return &av_pix_fmt_descriptors[fmt];
> >> return av_pix_fmt_desc_get(fmt);
> >> }
> > 
> > yes thats what i was thinking of too.
> > 
> 
> Seems like Anton is away for a week or so. I am sure he has an opinion
> on the above approach. I think we will wait for him or shall I apply the
> patches as they are given that they do not block any later alternative
> solution?

please dont apply code like "IS_BE(BE_LE)" 
iam sure it makes sense to you today but it requires an additional step
for the reader to understand
simplest is a seperate endianness and isbe variable. on the wrapper
that should be less code too but quite possibly you see a better and
cleaner way


> (There is one thing I already don't like about the alternative solution:
> It relies on av_builtin_constant_p, which not every compiler supports.)

Thats why i didnt suggets to use av_builtin_constant_p() i was hoping you
saw a better way to achieve it.

But this is a problem which occurs more than once in the codebase.
mapping some identifer to some value just depending on the identifer,
something that is compile time constant, yet it calls to a function to
do a lookup

thx

[...]

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

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


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

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

Re: [FFmpeg-devel] [PATCH 2/2] libavformat/hls: Free keys

2022-09-10 Thread Michael Niedermayer 
On Fri, Sep 09, 2022 at 11:21:38AM +0800, Steven Liu wrote:
> Michael Niedermayer  于2022年9月9日周五 06:45写道：
> >
> > Fixes: memleak
> > Fixes: 
> > 50703/clusterfuzz-testcase-minimized-ffmpeg_dem_HLS_fuzzer-6399058578636800
> >
> > Found-by: continuous fuzzing process 
> > https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
> > Signed-off-by: Michael Niedermayer 
> > ---
> >  libavformat/hls.c | 1 +
> >  1 file changed, 1 insertion(+)
> >
> > diff --git a/libavformat/hls.c b/libavformat/hls.c
> > index 3dc7bd39309..e622425e801 100644
> > --- a/libavformat/hls.c
> > +++ b/libavformat/hls.c
> > @@ -250,6 +250,7 @@ static void free_init_section_list(struct playlist *pls)
> >  {
> >  int i;
> >  for (i = 0; i < pls->n_init_sections; i++) {
> > +av_freep(&pls->init_sections[i]->key);
> >  av_freep(&pls->init_sections[i]->url);
> >  av_freep(&pls->init_sections[i]);
> >  }
> > --
> > 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".
> 
> lgtm

will apply

thx

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

You can kill me, but you cannot change the truth.


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

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

Re: [FFmpeg-devel] [PATCH 1/2] tools/target_dec_fuzzer: Adjust threshold for UTVIDEO

2022-09-10 Thread Michael Niedermayer 
On Fri, Sep 09, 2022 at 12:44:57AM +0200, Michael Niedermayer wrote:
> Fixes: Timeout
> Fixes: 
> 47969/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_UTVIDEO_fuzzer-5097256832860160
> 
> 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(+)

will apply

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

The real ebay dictionary, page 1
"Used only once"- "Some unspecified defect prevented a second use"
"In good condition" - "Can be repaird by experienced expert"
"As is" - "You wouldnt want it even if you were payed for it, if you knew ..."


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

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

Re: [FFmpeg-devel] [PATCH 2/2] swscale/input: Avoid calls to av_pix_fmt_desc_get()

2022-09-10 Thread Andreas Rheinhardt 
Michael Niedermayer:
> On Fri, Sep 09, 2022 at 08:15:22PM +0200, Andreas Rheinhardt wrote:
>> Michael Niedermayer:
>>> On Thu, Sep 08, 2022 at 11:44:51PM +0200, Andreas Rheinhardt wrote:
 Michael Niedermayer:
> On Thu, Sep 08, 2022 at 09:38:51PM +0200, Andreas Rheinhardt wrote:
>> Michael Niedermayer:
>>> [...]
> To me if i look at the evolution
> of isBE() / code checking BE-ness it become more messy over time
>
> I think it would be interresting to think about if we can make
> av_pix_fmt_desc_get(compile time constant) work at compile time.
> or if we maybe can return to a simpler implementation
>

 We could put the av_pix_fmt_descriptors array into an internal header
 and use something like

 static av_always_inline const AVPixFmtDescriptor
 *ff_pix_fmt_descriptor_get(enum AVPixelFormat fmt)
 {
 if (av_builtin_constant_p(fmt))
 return &av_pix_fmt_descriptors[fmt];
 return av_pix_fmt_desc_get(fmt);
 }
>>>
>>> yes thats what i was thinking of too.
>>>
>>
>> Seems like Anton is away for a week or so. I am sure he has an opinion
>> on the above approach. I think we will wait for him or shall I apply the
>> patches as they are given that they do not block any later alternative
>> solution?
> 
> please dont apply code like "IS_BE(BE_LE)" 
> iam sure it makes sense to you today but it requires an additional step
> for the reader to understand
> simplest is a seperate endianness and isbe variable. on the wrapper
> that should be less code too but quite possibly you see a better and
> cleaner way
> 

I actually thought that my solution is superior to the one you seem to
have in mind; after all, the parameter for isbe is redundant: It can
also be derived from the pixfmt-name.

> 
>> (There is one thing I already don't like about the alternative solution:
>> It relies on av_builtin_constant_p, which not every compiler supports.)
> 
> Thats why i didnt suggets to use av_builtin_constant_p() i was hoping you
> saw a better way to achieve it.
> 

Well, without av_builtin_constant_p() the only other way for this would
be to add two systems to get the information, one for compile-time
constants and one for not-constants. Ensuring that the former is only
used for compile-time constants will be a challenge, to say the least.

> But this is a problem which occurs more than once in the codebase.
> mapping some identifer to some value just depending on the identifer,
> something that is compile time constant, yet it calls to a function to
> do a lookup
> 

Another idea from the top of my head:
- We could provide some of the info contained in the descriptors via
separate defines/enums that parallel the actual enum, like
enum AVPixelFormatFlags {
AV_PIX_FMT_YUV420P_FLAGS = AV_PIX_FMT_FLAG_PLANAR,
AV_PIX_FMT_YUYV422_FLAGS = 0,
...
};
The list in pixdesc.c would then use these constants instead of defining
the flags twice (to avoid inconsistencies). These constants can be used
from macros via fmt ## _FLAGS, avoiding the av_builtin_constant_p()
issue. This could even be made public if we add a big warning that new
flags may be added in the future. Other such enums for other values may
be added, too, but honestly I don't really like this approach.

We could also use make an xmacro out of the list in lavu/pixdesc.c and
use this xmacro to query the values. E.g. isBE() would then in effect
become one big switch:
isBE(fmt)
{
switch (fmt) {
case AV_PIX_FMT_YUV420P: return 0;

}
}
This could be made to handle non-compile-time constants as well (by
having a default that uses av_pix_fmt_desc_get()), but it has a
downside: There would be runtime checks for whether we are in the
default branch or not. So once again this function should not be used
with non-compile time constants.

- 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] fftools: allow decoders to set AVFrame time_base

2022-09-10 Thread Leo Izen 
This patch allows decoders to set AVFrame->time_base, which
determines the units that AVFrame->pts will use. Currently
no decoders do this, but it will allow it in the future.
---
 fftools/ffmpeg.c | 3 ++-
 fftools/ffplay.c | 2 +-
 2 files changed, 3 insertions(+), 2 deletions(-)

diff --git a/fftools/ffmpeg.c b/fftools/ffmpeg.c
index 0e1477299d..e3ea7a6c29 100644
--- a/fftools/ffmpeg.c
+++ b/fftools/ffmpeg.c
@@ -2274,7 +2274,8 @@ static int decode_video(InputStream *ist, AVPacket *pkt, 
int *got_output, int64_
 }
 
 if(best_effort_timestamp != AV_NOPTS_VALUE) {
-int64_t ts = av_rescale_q(decoded_frame->pts = best_effort_timestamp, 
ist->st->time_base, AV_TIME_BASE_Q);
+int64_t ts = av_rescale_q(decoded_frame->pts = best_effort_timestamp,
+decoded_frame->time_base.num ? decoded_frame->time_base : 
ist->st->time_base, AV_TIME_BASE_Q);
 
 if (ts != AV_NOPTS_VALUE)
 ist->next_pts = ist->pts = ts;
diff --git a/fftools/ffplay.c b/fftools/ffplay.c
index 9242047f5c..986b0831ac 100644
--- a/fftools/ffplay.c
+++ b/fftools/ffplay.c
@@ -1771,7 +1771,7 @@ static int get_video_frame(VideoState *is, AVFrame *frame)
 double dpts = NAN;
 
 if (frame->pts != AV_NOPTS_VALUE)
-dpts = av_q2d(is->video_st->time_base) * frame->pts;
+dpts = av_q2d(frame->time_base.num ? frame->time_base : 
is->video_st->time_base) * frame->pts;
 
 frame->sample_aspect_ratio = av_guess_sample_aspect_ratio(is->ic, 
is->video_st, frame);
 
-- 
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 2/2] swscale/input: Avoid calls to av_pix_fmt_desc_get()

2022-09-10 Thread Michael Niedermayer 
On Sat, Sep 10, 2022 at 06:34:43PM +0200, Andreas Rheinhardt wrote:
> Michael Niedermayer:
> > On Fri, Sep 09, 2022 at 08:15:22PM +0200, Andreas Rheinhardt wrote:
> >> Michael Niedermayer:
> >>> On Thu, Sep 08, 2022 at 11:44:51PM +0200, Andreas Rheinhardt wrote:
>  Michael Niedermayer:
> > On Thu, Sep 08, 2022 at 09:38:51PM +0200, Andreas Rheinhardt wrote:
> >> Michael Niedermayer:
> >>> [...]
> > To me if i look at the evolution
> > of isBE() / code checking BE-ness it become more messy over time
> >
> > I think it would be interresting to think about if we can make
> > av_pix_fmt_desc_get(compile time constant) work at compile time.
> > or if we maybe can return to a simpler implementation
> >
> 
>  We could put the av_pix_fmt_descriptors array into an internal header
>  and use something like
> 
>  static av_always_inline const AVPixFmtDescriptor
>  *ff_pix_fmt_descriptor_get(enum AVPixelFormat fmt)
>  {
>  if (av_builtin_constant_p(fmt))
>  return &av_pix_fmt_descriptors[fmt];
>  return av_pix_fmt_desc_get(fmt);
>  }
> >>>
> >>> yes thats what i was thinking of too.
> >>>
> >>
> >> Seems like Anton is away for a week or so. I am sure he has an opinion
> >> on the above approach. I think we will wait for him or shall I apply the
> >> patches as they are given that they do not block any later alternative
> >> solution?
> > 
> > please dont apply code like "IS_BE(BE_LE)" 
> > iam sure it makes sense to you today but it requires an additional step
> > for the reader to understand
> > simplest is a seperate endianness and isbe variable. on the wrapper
> > that should be less code too but quite possibly you see a better and
> > cleaner way
> > 
> 
> I actually thought that my solution is superior to the one you seem to
> have in mind; after all, the parameter for isbe is redundant: It can
> also be derived from the pixfmt-name.

your solution is supperior in some sense. But iam concerned that it is
less readable for a small gain.
Maybe BE_LE and others can be renamed to make it immedeatly clear


> 
> > 
> >> (There is one thing I already don't like about the alternative solution:
> >> It relies on av_builtin_constant_p, which not every compiler supports.)
> > 
> > Thats why i didnt suggets to use av_builtin_constant_p() i was hoping you
> > saw a better way to achieve it.
> > 
> 
> Well, without av_builtin_constant_p() the only other way for this would
> be to add two systems to get the information, one for compile-time
> constants and one for not-constants. Ensuring that the former is only
> used for compile-time constants will be a challenge, to say the least.

I dont think its a challenge, but iam still quite unsure if this would
lead to other issues.

For example, if we add a constant lookup function that has direct access
to the table. We assue that will only be used where constants are the
arguzment. Now its easy to add a extra field to that table and then
grep the binary for that. If its found it was either used with a non
constant or the compiler failed to optimize it out.
This could be a fate test. If it works 100% thats simple but if it works
99% it will be a pain and is not a direction i would suggest, it would
be more pain than its worth.

So really this is just for discussion at this point, far from a plan
with understood consequences

thx
[...]

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Frequently ignored answer#1 FFmpeg bugs should be sent to our bugtracker. User
questions about the command line tools should be sent to the ffmpeg-user ML.
And questions about how to use libav* should be sent to the libav-user ML.


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] Add LoongArch SIMD optimization in swscale lib.

2022-09-10 Thread Michael Niedermayer 
On Fri, Sep 09, 2022 at 05:43:38PM +0800, yinshiyou...@loongson.cn wrote:
> > -原始邮件-
> > 发件人: "Hao Chen" 
> > 发送时间:2022-09-09 17:00:23 (星期五)
> > 收件人: ffmpeg-devel@ffmpeg.org
> > 抄送: 
> > 主题: [FFmpeg-devel] Add LoongArch SIMD optimization in swscale lib.
> > 
> > v2: Some modifications were made according to the comments of the reviewers.
> > v3: Update and run CI test again.
> > v4: Resolve the warning for the build.
> > v5: Re-trigger the Patchwork test.
> > 
> > [PATCH v5 1/3] swscale/la: Optimize hscale functions with lasx.
> > [PATCH v5 2/3] swscale/la: Add yuv2rgb_lasx.c and rgb2rgb_lasx.c
> > [PATCH v5 3/3] swscale/la: Add output_lasx.c file.
> > 
> > ___
> > ffmpeg-devel mailing list
> > ffmpeg-devel@ffmpeg.org
> > https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> > 
> > To unsubscribe, visit link above, or email
> > ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
> 
> LGTM.

will apply

thx

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

The real ebay dictionary, page 2
"100% positive feedback" - "All either got their money back or didnt complain"
"Best seller ever, very honest" - "Seller refunded buyer after failed scam"


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

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

[FFmpeg-devel] [PATCH] improve VAAPI error handling

2022-09-10 Thread Andreas Kies 
In case something is wrong in vaapi_device_create() you usually just get
EINVAL, but not the real cause.
This patch allows to return the cause as set in errno.
EINVAL is used for kernel driver name mismatch.
ENODEV in case vaGetDisplayDRM() fails.
Also changed:
   Try X11 interface in case vaGetDisplayDRM() fails.
   Try to open any of the possible 8 devices.From 09c11ebba68076c5c17254ea42183e6031a9a44f Mon Sep 17 00:00:00 2001
From: Andik 
Date: Sat, 10 Sep 2022 18:22:03 +0200
Subject: [PATCH] improve VAAPI error handling

---
 libavutil/hwcontext_vaapi.c | 13 ++---
 1 file changed, 10 insertions(+), 3 deletions(-)

diff --git a/libavutil/hwcontext_vaapi.c b/libavutil/hwcontext_vaapi.c
index 9ba5225ad2..82218c4c9c 100644
--- a/libavutil/hwcontext_vaapi.c
+++ b/libavutil/hwcontext_vaapi.c
@@ -1655,6 +1655,7 @@ static int vaapi_device_create(AVHWDeviceContext *ctx, const char *device,
 VADisplay display = NULL;
 const AVDictionaryEntry *ent;
 int try_drm, try_x11, try_all;
+int dev_errno = ENOENT;
 
 priv = av_mallocz(sizeof(*priv));
 if (!priv)
@@ -1692,6 +1693,7 @@ static int vaapi_device_create(AVHWDeviceContext *ctx, const char *device,
 if (device) {
 priv->drm_fd = open(device, O_RDWR);
 if (priv->drm_fd < 0) {
+dev_errno = errno;
 av_log(ctx, loglevel, "Failed to open %s as "
"DRM device node.\n", device);
 break;
@@ -1708,15 +1710,18 @@ static int vaapi_device_create(AVHWDeviceContext *ctx, const char *device,
  "/dev/dri/renderD%d", 128 + n);
 priv->drm_fd = open(path, O_RDWR);
 if (priv->drm_fd < 0) {
+if (errno != ENOENT)
+dev_errno = errno;
 av_log(ctx, AV_LOG_VERBOSE, "Cannot open "
"DRM render node for device %d.\n", n);
-break;
+continue;
 }
 #if CONFIG_LIBDRM
 if (kernel_driver) {
 drmVersion *info;
 info = drmGetVersion(priv->drm_fd);
 if (strcmp(kernel_driver->value, info->name)) {
+dev_errno = EINVAL;
 av_log(ctx, AV_LOG_VERBOSE, "Ignoring device %d "
"with non-matching kernel driver (%s).\n",
n, info->name);
@@ -1744,9 +1749,9 @@ static int vaapi_device_create(AVHWDeviceContext *ctx, const char *device,
 
 display = vaGetDisplayDRM(priv->drm_fd);
 if (!display) {
+dev_errno = ENODEV;
 av_log(ctx, AV_LOG_VERBOSE, "Cannot open a VA display "
"from DRM device %s.\n", device);
-return AVERROR_EXTERNAL;
 }
 break;
 }
@@ -1757,6 +1762,8 @@ static int vaapi_device_create(AVHWDeviceContext *ctx, const char *device,
 // Try to open the device as an X11 display.
 priv->x11_display = XOpenDisplay(device);
 if (!priv->x11_display) {
+if (errno != ENOENT)
+dev_errno = errno;
 av_log(ctx, AV_LOG_VERBOSE, "Cannot open X11 display "
"%s.\n", XDisplayName(device));
 } else {
@@ -1780,7 +1787,7 @@ static int vaapi_device_create(AVHWDeviceContext *ctx, const char *device,
 else
 av_log(ctx, AV_LOG_ERROR, "No VA display found for "
"any default device.\n");
-return AVERROR(EINVAL);
+return AVERROR(dev_errno);
 }
 
 ent = av_dict_get(opts, "driver", NULL, 0);
-- 
2.34.1

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

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

[FFmpeg-devel] [PATCH] avcodec: Micronas SC-4 decoder and parser

2022-09-10 Thread Paul B Mahol 
Patches attached.
From 9a85823ed8a616491b9da280f75e03103eb7d38f Mon Sep 17 00:00:00 2001
From: Paul B Mahol 
Date: Thu, 8 Sep 2022 20:44:49 +0200
Subject: [PATCH 1/2] avcodec: add MI-SC4 audio decoder

Signed-off-by: Paul B Mahol 
---
 libavcodec/Makefile |   1 +
 libavcodec/allcodecs.c  |   1 +
 libavcodec/codec_desc.c |   7 ++
 libavcodec/codec_id.h   |   1 +
 libavcodec/misc4.c  | 182 
 libavformat/riff.c  |   1 +
 6 files changed, 193 insertions(+)
 create mode 100644 libavcodec/misc4.c

diff --git a/libavcodec/Makefile b/libavcodec/Makefile
index 0b46bc0173..4112a0fb2e 100644
--- a/libavcodec/Makefile
+++ b/libavcodec/Makefile
@@ -471,6 +471,7 @@ OBJS-$(CONFIG_METASOUND_DECODER)   += metasound.o metasound_data.o \
   twinvq.o
 OBJS-$(CONFIG_MICRODVD_DECODER)+= microdvddec.o ass.o
 OBJS-$(CONFIG_MIMIC_DECODER)   += mimic.o
+OBJS-$(CONFIG_MISC4_DECODER)   += misc4.o
 OBJS-$(CONFIG_MJPEG_DECODER)   += mjpegdec.o mjpegdec_common.o
 OBJS-$(CONFIG_MJPEG_QSV_DECODER)   += qsvdec.o
 OBJS-$(CONFIG_MJPEG_ENCODER)   += mjpegenc.o mjpegenc_common.o \
diff --git a/libavcodec/allcodecs.c b/libavcodec/allcodecs.c
index 5d58a5d9f0..447225e26b 100644
--- a/libavcodec/allcodecs.c
+++ b/libavcodec/allcodecs.c
@@ -483,6 +483,7 @@ extern const FFCodec ff_interplay_acm_decoder;
 extern const FFCodec ff_mace3_decoder;
 extern const FFCodec ff_mace6_decoder;
 extern const FFCodec ff_metasound_decoder;
+extern const FFCodec ff_misc4_decoder;
 extern const FFCodec ff_mlp_encoder;
 extern const FFCodec ff_mlp_decoder;
 extern const FFCodec ff_mp1_decoder;
diff --git a/libavcodec/codec_desc.c b/libavcodec/codec_desc.c
index c002480d39..648c518b3c 100644
--- a/libavcodec/codec_desc.c
+++ b/libavcodec/codec_desc.c
@@ -3297,6 +3297,13 @@ static const AVCodecDescriptor codec_descriptors[] = {
 .long_name = NULL_IF_CONFIG_SMALL("Bonk audio"),
 .props = AV_CODEC_PROP_LOSSY | AV_CODEC_PROP_INTRA_ONLY | AV_CODEC_PROP_LOSSLESS,
 },
+{
+.id= AV_CODEC_ID_MISC4,
+.type  = AVMEDIA_TYPE_AUDIO,
+.name  = "misc4",
+.long_name = NULL_IF_CONFIG_SMALL("Micronas SC-4 Audio"),
+.props = AV_CODEC_PROP_LOSSY | AV_CODEC_PROP_INTRA_ONLY,
+},
 
 /* subtitle codecs */
 {
diff --git a/libavcodec/codec_id.h b/libavcodec/codec_id.h
index 858b5c3a75..bc8226ff07 100644
--- a/libavcodec/codec_id.h
+++ b/libavcodec/codec_id.h
@@ -528,6 +528,7 @@ enum AVCodecID {
 AV_CODEC_ID_MSNSIREN,
 AV_CODEC_ID_DFPWM,
 AV_CODEC_ID_BONK,
+AV_CODEC_ID_MISC4,
 
 /* subtitle codecs */
 AV_CODEC_ID_FIRST_SUBTITLE = 0x17000,  ///< A dummy ID pointing at the start of subtitle codecs.
diff --git a/libavcodec/misc4.c b/libavcodec/misc4.c
new file mode 100644
index 00..4376d0d025
--- /dev/null
+++ b/libavcodec/misc4.c
@@ -0,0 +1,182 @@
+/*
+ * Micronas SC-4 audio decoder
+ * Copyright (c) 2022 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/internal.h"
+#include "libavutil/intreadwrite.h"
+#include "avcodec.h"
+#include "codec_internal.h"
+#include "decode.h"
+#include "bytestream.h"
+#include "mathops.h"
+
+static const int16_t tab0[16] = {
+4084, 18, 41, 64, 112, 198, 355, 1122,
+1122, 355, 198, 112, 64, 41, 18, 4084,
+};
+
+static const int16_t steps[16] = {
+2048, 4, 135, 213, 273, 323, 373, 425,
+425, 373, 323, 273, 213, 135, 4, 2048,
+};
+
+typedef struct ChannelContext {
+unsigned last_step;
+int64_t new_pred;
+int64_t pred;
+int64_t weights_tab[6];
+int32_t diffs_tab[6];
+} ChannelContext;
+
+typedef struct MISC4Context {
+GetByteContext gb;
+
+uint32_t marker;
+
+ChannelContext ch[2];
+} MISC4Context;
+
+static av_cold int misc4_init(AVCodecContext *avctx)
+{
+MISC4Context *s = avctx->priv_data;
+
+avctx->sample_fmt = AV_SAMPLE_FMT_S16;
+switch (avctx->sample_rate) {
+case 8000:
+case 11025:
+s->marker = 0x11b;
+break;
+case 16000:
+case 32000:
+s->marker = 0x2b2;
+break;
+}
+
+return 0;
+}
+
+static int64_t prediction(int delta, Chann

Re: [FFmpeg-devel] [PATCH] avcodec: Micronas SC-4 decoder and parser

2022-09-10 Thread James Almer 

On 9/10/2022 3:27 PM, Paul B Mahol wrote:

Patches attached.


This looks like it would fit in adpcm.c as an ADPCM codec.
___
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: Micronas SC-4 decoder and parser

2022-09-10 Thread Paul B Mahol 
On 9/10/22, James Almer  wrote:
> On 9/10/2022 3:27 PM, Paul B Mahol wrote:
>> Patches attached.
>
> This looks like it would fit in adpcm.c as an ADPCM codec.

Nope

> ___
> 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] avcodec: Micronas SC-4 decoder and parser

2022-09-10 Thread James Almer 

On 9/10/2022 4:11 PM, Paul B Mahol wrote:

On 9/10/22, James Almer  wrote:

On 9/10/2022 3:27 PM, Paul B Mahol wrote:

Patches attached.


This looks like it would fit in adpcm.c as an ADPCM codec.


Nope


nibble, step, prediction. All terminology taken straight out of adpcm, 
down to the decoding process.
The entire decoder can surely be implemented in adpcm.c and named 
adpcm_msc4, and unless you have a good reason not to I'd really like you 
doing so, because once the AVCodecID is added renaming it becomes a PITA.

___
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: Micronas SC-4 decoder and parser

2022-09-10 Thread Paul B Mahol 
On 9/10/22, James Almer  wrote:
> On 9/10/2022 4:11 PM, Paul B Mahol wrote:
>> On 9/10/22, James Almer  wrote:
>>> On 9/10/2022 3:27 PM, Paul B Mahol wrote:
 Patches attached.
>>>
>>> This looks like it would fit in adpcm.c as an ADPCM codec.
>>
>> Nope
>
> nibble, step, prediction. All terminology taken straight out of adpcm,
> down to the decoding process.
> The entire decoder can surely be implemented in adpcm.c and named
> adpcm_msc4, and unless you have a good reason not to I'd really like you
> doing so, because once the AVCodecID is added renaming it becomes a PITA.

It have parser, and if you look actually carefully different
layout in packets, not sharing anything with adpcm.c code.

So please refrain from non-constructive comments.

> ___
> 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] avcodec: Micronas SC-4 decoder and parser

2022-09-10 Thread Paul B Mahol 
On 9/10/22, Paul B Mahol  wrote:
> On 9/10/22, James Almer  wrote:
>> On 9/10/2022 4:11 PM, Paul B Mahol wrote:
>>> On 9/10/22, James Almer  wrote:
 On 9/10/2022 3:27 PM, Paul B Mahol wrote:
> Patches attached.

 This looks like it would fit in adpcm.c as an ADPCM codec.
>>>
>>> Nope
>>
>> nibble, step, prediction. All terminology taken straight out of adpcm,
>> down to the decoding process.
>> The entire decoder can surely be implemented in adpcm.c and named
>> adpcm_msc4, and unless you have a good reason not to I'd really like you
>> doing so, because once the AVCodecID is added renaming it becomes a PITA.
>
> It have parser, and if you look actually carefully different
> layout in packets, not sharing anything with adpcm.c code.
>
> So please refrain from non-constructive comments.

Also it is not really ADPCM codec as it have dynamics
weights and use dot product too.

So next time look at code more carefully.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

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

[FFmpeg-devel] [PATCH 1/2] fate/id3v2: Add test for reading and writing UTF-16 BOM tags

2022-09-10 Thread Andreas Rheinhardt 
Signed-off-by: Andreas Rheinhardt 
---
 tests/fate/id3v2.mak   |  5 
 tests/ref/fate/id3v2-utf16-bom | 42 ++
 2 files changed, 47 insertions(+)
 create mode 100644 tests/ref/fate/id3v2-utf16-bom

diff --git a/tests/fate/id3v2.mak b/tests/fate/id3v2.mak
index 4dca681e38..7ad4d877a4 100644
--- a/tests/fate/id3v2.mak
+++ b/tests/fate/id3v2.mak
@@ -7,6 +7,11 @@ fate-id3v2-priv-remux: CMD = transcode mp3 
$(TARGET_SAMPLES)/id3v2/id3v2_priv.mp
 FATE_ID3V2_FFMPEG_FFPROBE-$(call REMUX, AIFF, WAV_DEMUXER) += 
fate-id3v2-chapters
 fate-id3v2-chapters: CMD = transcode wav $(TARGET_SAMPLES)/wav/200828-005.wav 
aiff "-c copy -metadata:c:0 description=foo -metadata:c:0 date=2021 -metadata:c 
copyright=none -metadata:c:1 genre=nonsense -write_id3v2 1" "-c copy -t 0.05" 
"-show_entries format_tags:chapters"
 
+# Tests reading and writing UTF-16 BOM strings; also tests
+# the AIFF muxer's and demuxer's ability to preserve channel layouts.
+FATE_ID3V2_FFMPEG_FFPROBE-$(call REMUX, AIFF, WAV_DEMUXER FLAC_DEMUXER 
PCM_S16LE_DECODER MJPEG_DECODER ARESAMPLE_FILTER CHANNELMAP_FILTER 
PCM_S24BE_ENCODER) += fate-id3v2-utf16-bom
+fate-id3v2-utf16-bom: CMD = transcode wav 
$(TARGET_SAMPLES)/audio-reference/yo.raw-short.wav aiff "-map 0:a -map 1:v -af 
aresample,channelmap=channel_layout=hexagonal,aresample -c:a pcm_s24be -c:v 
copy -write_id3v2 1 -id3v2_version 3 -map_metadata:g:0 1:g -map_metadata:s:v 
1:g" "-c copy -t 0.05" "-show_entries 
stream=channel_layout:stream_tags:format_tags" "-i 
$(TARGET_SAMPLES)/cover_art/cover_art.flac"
+
 FATE_SAMPLES_FFPROBE+= $(FATE_ID3V2_FFPROBE-yes)
 FATE_SAMPLES_FFMPEG_FFPROBE += $(FATE_ID3V2_FFMPEG_FFPROBE-yes)
 fate-id3v2: $(FATE_ID3V2_FFPROBE-yes) $(FATE_ID3V2_FFMPEG_FFPROBE-yes)
diff --git a/tests/ref/fate/id3v2-utf16-bom b/tests/ref/fate/id3v2-utf16-bom
new file mode 100644
index 00..dd2566de2b
--- /dev/null
+++ b/tests/ref/fate/id3v2-utf16-bom
@@ -0,0 +1,42 @@
+9b8bfdf87a8d3d089819ef9f6f264ec4 *tests/data/fate/id3v2-utf16-bom.aiff
+885482 tests/data/fate/id3v2-utf16-bom.aiff
+#tb 0: 1/9
+#media_type 0: video
+#codec_id 0: mjpeg
+#dimensions 0: 350x350
+#sar 0: 1/1
+#tb 1: 1/48000
+#media_type 1: audio
+#codec_id 1: pcm_s24be
+#sample_rate 1: 48000
+#channel_layout_name 1: hexagonal
+0,  0,  0,0,19650, 0xd5662610
+1,  0,  0,  227, 4086, 0x
+1,227,227,  227, 4086, 0x
+1,454,454,  227, 4086, 0x
+1,681,681,  227, 4086, 0x667b2643
+1,908,908,  227, 4086, 0x9a09957d
+1,   1135,   1135,  227, 4086, 0x763e27c5
+1,   1362,   1362,  227, 4086, 0x2a47f536
+1,   1589,   1589,  227, 4086, 0xed32e5f2
+1,   1816,   1816,  227, 4086, 0x2e96c720
+1,   2043,   2043,  227, 4086, 0x84c5b5f0
+1,   2270,   2270,  227, 4086, 0xe3dfeefc
+[STREAM]
+channel_layout=hexagonal
+[/STREAM]
+[STREAM]
+TAG:title=Дороги
+TAG:comment=Other
+[/STREAM]
+[FORMAT]
+TAG:artist=Мельница
+TAG:RATING=0
+TAG:album=Ангелофрения
+TAG:title=Дороги
+TAG:tracktotal=11
+TAG:totaltracks=11
+TAG:genre=Folk
+TAG:track=2
+TAG:date=2012
+[/FORMAT]
-- 
2.34.1

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

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

[FFmpeg-devel] [PATCH 2/2] fate/subtitles: Add PGS remux test

2022-09-10 Thread Andreas Rheinhardt 
Signed-off-by: Andreas Rheinhardt 
---
 tests/fate/subtitles.mak |  5 +
 tests/ref/fate/sub-pgs-remux | 15 +++
 2 files changed, 20 insertions(+)
 create mode 100644 tests/ref/fate/sub-pgs-remux

diff --git a/tests/fate/subtitles.mak b/tests/fate/subtitles.mak
index bc464edce6..e6684a814b 100644
--- a/tests/fate/subtitles.mak
+++ b/tests/fate/subtitles.mak
@@ -50,6 +50,11 @@ fate-sub-mpsub: CMD = fmtstdout ass -i 
$(TARGET_SAMPLES)/sub/MPSub_capability_te
 FATE_SUBTITLES_ASS-$(call DEMDEC, MPSUB, TEXT) += fate-sub-mpsub-frames
 fate-sub-mpsub-frames: CMD = fmtstdout ass -i 
$(TARGET_SAMPLES)/sub/MPSub_capability_tester_frames.sub
 
+# FIXME?: The dts in the input file are not monotonous and so the
+# timestamps of the remuxed file have been fixed up.
+FATE_SUBTITLES-$(call REMUX, SUP) += fate-sub-pgs-remux
+fate-sub-pgs-remux: CMD = transcode sup $(TARGET_SAMPLES)/sub/pgs_sub.sup sup 
"-copyts -c:s copy" "-copyts -c:s copy"
+
 FATE_SUBTITLES_ASS-$(call DEMDEC, PJS, PJS) += fate-sub-pjs
 fate-sub-pjs: CMD = fmtstdout ass -i 
$(TARGET_SAMPLES)/sub/PJS_capability_tester.pjs
 
diff --git a/tests/ref/fate/sub-pgs-remux b/tests/ref/fate/sub-pgs-remux
new file mode 100644
index 00..e965d93bec
--- /dev/null
+++ b/tests/ref/fate/sub-pgs-remux
@@ -0,0 +1,15 @@
+cf306b7bc30122effc6429e35364f640 *tests/data/fate/sub-pgs-remux.sup
+49382 tests/data/fate/sub-pgs-remux.sup
+#tb 0: 1/9
+#media_type 0: subtitle
+#codec_id 0: hdmv_pgs_subtitle
+0,   6072,   6072,0,   30, 0x32b303ec
+0,   6072,   6072,0,   22, 0x27510416
+0,   6072,   6072,0,  160, 0xe2024133
+0,   6072,   6072,0,22943, 0xc011fe0e
+0,   6072,   6072,0, 2969, 0x35604c6f
+0,   6072,   6072,0,3, 0x01800080
+0,  35426,  36102,0,   30, 0x2db303ac
+0,  35426,  35862,0,   22, 0x27510416
+0,  35426,  35426,0,  160, 0xe2024133
+0,  35426,  35862,0,22943, 0xc011fe0e
-- 
2.34.1

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

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

[FFmpeg-devel] [PATCH 5/5] avcodec/tta: Check 24bit scaling for overflow

2022-09-10 Thread Michael Niedermayer 
Fixes: signed integer overflow: -8427924 * 256 cannot be represented in type 
'int'
Fixes: 
48798/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_TTA_fuzzer-5409428670644224

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

diff --git a/libavcodec/tta.c b/libavcodec/tta.c
index 6fb8d7a74f9..d66e25af059 100644
--- a/libavcodec/tta.c
+++ b/libavcodec/tta.c
@@ -377,8 +377,15 @@ static int tta_decode_frame(AVCodecContext *avctx, AVFrame 
*frame,
 case 3: {
 // shift samples for 24-bit sample format
 int32_t *samples = (int32_t *)frame->data[0];
-for (i = 0; i < framelen * s->channels; i++)
-*samples++ *= 256;
+int overflow = 0;
+
+for (i = 0; i < framelen * s->channels; i++) {
+int scaled = *samples * 256U;
+overflow += (scaled >> 8 != *samples);
+*samples++ = scaled;
+}
+if (overflow)
+av_log(avctx, AV_LOG_WARNING, "%d overflows occurred on 24bit 
upscale\n", overflow);
 // reset decode buffer
 s->decode_buffer = NULL;
 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".

[FFmpeg-devel] [PATCH 1/5] avcodec/apedec: Fix integer overflow in filter_3800()

2022-09-10 Thread Michael Niedermayer 
Fixes: signed integer overflow: -2147448926 + -198321 cannot be represented in 
type 'int'
Fixes: 
48798/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_APE_fuzzer-5739619273015296
Fixes: 
48798/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_APE_fuzzer-6744428485672960

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 4e3ddfea01b..c08d13d6c23 100644
--- a/libavcodec/apedec.c
+++ b/libavcodec/apedec.c
@@ -934,7 +934,7 @@ static av_always_inline int filter_3800(APEPredictor *p,
 p->coeffsB[filter][0] += (((d3 >> 29) & 4) - 2) * sign;
 p->coeffsB[filter][1] -= (((d4 >> 30) & 2) - 1) * sign;
 
-p->filterB[filter] = p->lastA[filter] + (predictionB >> shift);
+p->filterB[filter] = p->lastA[filter] + (unsigned)(predictionB >> shift);
 p->filterA[filter] = p->filterB[filter] + 
(unsigned)((int)(p->filterA[filter] * 31U) >> 5);
 
 return p->filterA[filter];
-- 
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/5] avcodec/mobiclip: Check quantizer for overflow

2022-09-10 Thread Michael Niedermayer 
Fixes: signed integer overflow: 127 + 2147483536 cannot be represented in type 
'int'
Fixes: 
48798/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_MOBICLIP_fuzzer-6014034970804224

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

diff --git a/libavcodec/mobiclip.c b/libavcodec/mobiclip.c
index 5348f3bd6c3..aca462428c1 100644
--- a/libavcodec/mobiclip.c
+++ b/libavcodec/mobiclip.c
@@ -330,7 +330,7 @@ static av_cold int mobiclip_init(AVCodecContext *avctx)
 return 0;
 }
 
-static int setup_qtables(AVCodecContext *avctx, int quantizer)
+static int setup_qtables(AVCodecContext *avctx, int64_t quantizer)
 {
 MobiClipContext *s = avctx->priv_data;
 int qx, qy;
@@ -1256,7 +1256,7 @@ static int mobiclip_decode(AVCodecContext *avctx, AVFrame 
*rframe,
 frame->key_frame = 0;
 s->dct_tab_idx = 0;
 
-ret = setup_qtables(avctx, s->quantizer + get_se_golomb(gb));
+ret = setup_qtables(avctx, s->quantizer + (int64_t)get_se_golomb(gb));
 if (ret < 0)
 return ret;
 
-- 
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/5] avcodec/dstdec: Check for overflow in build_filter()

2022-09-10 Thread Michael Niedermayer 
Fixes: signed integer overflow: 1917019860 + 265558963 cannot be represented in 
type 'int'
Fixes: 
48798/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_DST_fuzzer-4833165046317056

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

diff --git a/libavcodec/dstdec.c b/libavcodec/dstdec.c
index 6bdd6c885c8..4b1762db33c 100644
--- a/libavcodec/dstdec.c
+++ b/libavcodec/dstdec.c
@@ -215,7 +215,7 @@ static uint8_t prob_dst_x_bit(int c)
 return (ff_reverse[c & 127] >> 1) + 1;
 }
 
-static void build_filter(int16_t table[DST_MAX_ELEMENTS][16][256], const Table 
*fsets)
+static int build_filter(int16_t table[DST_MAX_ELEMENTS][16][256], const Table 
*fsets)
 {
 int i, j, k, l;
 
@@ -226,14 +226,17 @@ static void build_filter(int16_t 
table[DST_MAX_ELEMENTS][16][256], const Table *
 int total = av_clip(length - j * 8, 0, 8);
 
 for (k = 0; k < 256; k++) {
-int v = 0;
+int64_t v = 0;
 
 for (l = 0; l < total; l++)
 v += (((k >> l) & 1) * 2 - 1) * fsets->coeff[i][j * 8 + l];
+if ((int16_t)v != v)
+return AVERROR_INVALIDDATA;
 table[i][j][k] = v;
 }
 }
 }
+return 0;
 }
 
 static int decode_frame(AVCodecContext *avctx, AVFrame *frame,
@@ -328,7 +331,9 @@ static int decode_frame(AVCodecContext *avctx, AVFrame 
*frame,
 return AVERROR_INVALIDDATA;
 ac_init(ac, gb);
 
-build_filter(s->filter, &s->fsets);
+ret = build_filter(s->filter, &s->fsets);
+if (ret < 0)
+return ret;
 
 memset(s->status, 0xAA, sizeof(s->status));
 memset(dsd, 0, frame->nb_samples * 4 * channels);
-- 
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/5] avcodec/exr: Check preview psize

2022-09-10 Thread Michael Niedermayer 
Fixes: signed integer overflow: 17121181824 * 538976288 cannot be represented 
in type 'long long'
Fixes: 
48798/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_EXR_fuzzer-5915330316206080

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

diff --git a/libavcodec/exr.c b/libavcodec/exr.c
index 235f6fa6cdd..c924406f131 100644
--- a/libavcodec/exr.c
+++ b/libavcodec/exr.c
@@ -1942,9 +1942,12 @@ static int decode_header(EXRContext *s, AVFrame *frame)
  "preview", 16)) >= 0) {
 uint32_t pw = bytestream2_get_le32(gb);
 uint32_t ph = bytestream2_get_le32(gb);
-int64_t psize = 4LL * pw * ph;
+uint64_t psize = pw * ph;
+if (psize > INT64_MAX / 4)
+return AVERROR_INVALIDDATA;
+psize *= 4;
 
-if (psize >= bytestream2_get_bytes_left(gb))
+if ((int64_t)psize >= bytestream2_get_bytes_left(gb))
 return AVERROR_INVALIDDATA;
 
 bytestream2_skip(gb, psize);
-- 
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 v1 3/3] swscale/la: Add output_lasx.c file.

2022-09-10 Thread Shiyou Yin 


> 2022年9月9日 21:11，Andreas Rheinhardt  写道：
> 
> Shiyou Yin:
>> 
>> 
>>> 2022年9月6日 16:12，Shiyou Yin  写道：
>>> 
 
 2022年8月29日 20:30，Andreas Rheinhardt >>> > 写道：
 
 Hao Chen:
> ffmpeg -i ~/media/1_h264_1080p_30fps_3Mbps.mp4 -f rawvideo -s 640x480 
> -pix_fmt
> rgb24 -y /dev/null -an
> before: 150fps
> after: 183fps
> 
> Signed-off-by: Hao Chen 
> ---
> libswscale/loongarch/Makefile | 3 +-
> libswscale/loongarch/output_lasx.c | 1982 +
> libswscale/loongarch/swscale_init_loongarch.c | 3 +
> libswscale/loongarch/swscale_loongarch.h | 6 +
> 4 files changed, 1993 insertions(+), 1 deletion(-)
> create mode 100644 libswscale/loongarch/output_lasx.c
> 
>> 
> +static void
> +yuv2rgb_2_template_lasx(SwsContext *c, const int16_t *buf[2],
> + const int16_t *ubuf[2], const int16_t *vbuf[2],
> + const int16_t *abuf[2], uint8_t *dest, int dstW,
> + int yalpha, int uvalpha, int y,
> + enum AVPixelFormat target, int hasAlpha)
> +{
> + const int16_t *buf0 = buf[0], *buf1 = buf[1],
> + *ubuf0 = ubuf[0], *ubuf1 = ubuf[1],
> + *vbuf0 = vbuf[0], *vbuf1 = vbuf[1];
> + int yalpha1 = 4096 - yalpha;
> + int uvalpha1 = 4096 - uvalpha;
> + int i, count = 0;
> + int len = dstW - 15;
> + int len_count = (dstW + 1) >> 1;
> + const void *r, *g, *b;
> + int head = YUVRGB_TABLE_HEADROOM;
> + __m256i v_yalpha1 = __lasx_xvreplgr2vr_w(yalpha1);
> + __m256i v_uvalpha1 = __lasx_xvreplgr2vr_w(uvalpha1);
> + __m256i v_yalpha = __lasx_xvreplgr2vr_w(yalpha);
> + __m256i v_uvalpha = __lasx_xvreplgr2vr_w(uvalpha);
> + __m256i headroom = __lasx_xvreplgr2vr_w(head);
> +
> + for (i = 0; i < len; i += 16) {
> + int Y1, Y2, U, V;
> + int i_dex = i << 1;
> + int c_dex = count << 1;
> + __m256i y0_h, y0_l, y0, u0, v0;
> + __m256i y1_h, y1_l, y1, u1, v1;
> + __m256i y_l, y_h, u, v;
> +
> + DUP4_ARG2(__lasx_xvldx, buf0, i_dex, ubuf0, c_dex, vbuf0, c_dex,
> + buf1, i_dex, y0, u0, v0, y1);
> + DUP2_ARG2(__lasx_xvldx, ubuf1, c_dex, vbuf1, c_dex, u1, v1);
> + DUP2_ARG2(__lasx_xvsllwil_w_h, y0, 0, y1, 0, y0_l, y1_l);
> + DUP2_ARG1(__lasx_xvexth_w_h, y0, y1, y0_h, y1_h);
> + DUP4_ARG1(__lasx_vext2xv_w_h, u0, u1, v0, v1, u0, u1, v0, v1);
> + y0_l = __lasx_xvmul_w(y0_l, v_yalpha1);
> + y0_h = __lasx_xvmul_w(y0_h, v_yalpha1);
> + u0 = __lasx_xvmul_w(u0, v_uvalpha1);
> + v0 = __lasx_xvmul_w(v0, v_uvalpha1);
> + y_l = __lasx_xvmadd_w(y0_l, v_yalpha, y1_l);
> + y_h = __lasx_xvmadd_w(y0_h, v_yalpha, y1_h);
> + u = __lasx_xvmadd_w(u0, v_uvalpha, u1);
> + v = __lasx_xvmadd_w(v0, v_uvalpha, v1);
> + y_l = __lasx_xvsrai_w(y_l, 19);
> + y_h = __lasx_xvsrai_w(y_h, 19);
> + u = __lasx_xvsrai_w(u, 19);
> + v = __lasx_xvsrai_w(v, 19);
> + u = __lasx_xvadd_w(u, headroom);
> + v = __lasx_xvadd_w(v, headroom);
> + WRITE_YUV2RGB(y_l, y_l, u, v, 0, 1, 0, 0);
> + WRITE_YUV2RGB(y_l, y_l, u, v, 2, 3, 1, 1);
> + WRITE_YUV2RGB(y_h, y_h, u, v, 0, 1, 2, 2);
> + WRITE_YUV2RGB(y_h, y_h, u, v, 2, 3, 3, 3);
> + WRITE_YUV2RGB(y_l, y_l, u, v, 4, 5, 4, 4);
> + WRITE_YUV2RGB(y_l, y_l, u, v, 6, 7, 5, 5);
> + WRITE_YUV2RGB(y_h, y_h, u, v, 4, 5, 6, 6);
> + WRITE_YUV2RGB(y_h, y_h, u, v, 6, 7, 7, 7);
> + }
> + if (dstW - i >= 8) {
> + int Y1, Y2, U, V;
> + int i_dex = i << 1;
> + __m256i y0_l, y0, u0, v0;
> + __m256i y1_l, y1, u1, v1;
> + __m256i y_l, u, v;
> +
> + y0 = __lasx_xvldx(buf0, i_dex);
 
 1. Not long ago, I tried to constify the src pointer of several asm
 functions and noticed that they produced new warnings for loongarch
 (according to patchwork:
 https://patchwork.ffmpeg.org/project/ffmpeg/patch/db6pr0101mb2214178d3e6b8dca5b86f8198f...@db6pr0101mb2214.eurprd01.prod.exchangelabs.com/),
 even though I was sure that the code is const-correct. After finding
 (via https://github.com/opencv/opencv/pull/21833) a toolchain
 (https://gitee.com/wenux/cross-compiler-la-on-x86) that can build the
 lasx and lsx code (upstream GCC seems to be lacking lsx and lasx support
 at the moment; at least, my self-compiled loongarch-GCC did not support
 lsx and lasx) the issue was clear: lsxintrin.h and lasxintrin.h do not
 use const at all, even for functions that only read data (I presume the
 vl in __lsx_vldx stands for "vector load"?).
 So I sent another iteration
 https://ffmpeg.org/pipermail/ffmpeg-devel/2022-August/299562.html of
 that patchset that now added wrappers for __lsx_vldx() and
 __lasx_xvldx() and cc'ed you and some other developers from loongson to
 alert you of the issue in the hope that you fix the headers, so that my
 wrappers wouldn't need to be applied. That didn't work, as my mails
 could not be delivered to you. So I a

Re: [FFmpeg-devel] [PATCH 02/18] avcodec/vp8: Disable lf_delta for VP7

2022-09-10 Thread Peter Ross 
On Sat, Sep 10, 2022 at 03:07:13AM +0200, Andreas Rheinhardt wrote:
> It is a VP8-only feature.
> 
> Signed-off-by: Andreas Rheinhardt 
> ---
>  libavcodec/vp8.c | 3 +--
>  1 file changed, 1 insertion(+), 2 deletions(-)
> 
> diff --git a/libavcodec/vp8.c b/libavcodec/vp8.c
> index c00c5c975e..04a2113cc8 100644
> --- a/libavcodec/vp8.c
> +++ b/libavcodec/vp8.c
> @@ -637,7 +637,6 @@ static int vp7_decode_frame_header(VP8Context *s, const 
> uint8_t *buf, int buf_si
>  for (i = 0; i < 2; i++)
>  memcpy(s->prob->mvc[i], vp7_mv_default_prob[i],
> sizeof(vp7_mv_default_prob[i]));
> -memset(&s->lf_delta, 0, sizeof(s->lf_delta));
>  memcpy(s->prob[0].scan, ff_zigzag_scan, sizeof(s->prob[0].scan));
>  }
>  
> @@ -2171,7 +2170,7 @@ void filter_level_for_mb(VP8Context *s, VP8Macroblock 
> *mb,
>  } else
>  filter_level = s->filter.level;
>  
> -if (s->lf_delta.enabled) {
> +if (!is_vp7 && s->lf_delta.enabled) {
>  filter_level += s->lf_delta.ref[mb->ref_frame];
>  filter_level += s->lf_delta.mode[mb->mode];
>  }

what's the motivation for patches 01 and 02?
are you not just adding another condition (is_vp7) to evaluate at decode time?
if its improved readability, then suggest renaming 'lf_delta' to 'lf_delta_vp8'

pathces 3-18 look fine to me.

-- Peter
(A907 E02F A6E5 0CD2 34CD 20D2 6760 79C5 AC40 DD6B)


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 02/18] avcodec/vp8: Disable lf_delta for VP7

2022-09-10 Thread Andreas Rheinhardt 
Peter Ross:
> On Sat, Sep 10, 2022 at 03:07:13AM +0200, Andreas Rheinhardt wrote:
>> It is a VP8-only feature.
>>
>> Signed-off-by: Andreas Rheinhardt 
>> ---
>>  libavcodec/vp8.c | 3 +--
>>  1 file changed, 1 insertion(+), 2 deletions(-)
>>
>> diff --git a/libavcodec/vp8.c b/libavcodec/vp8.c
>> index c00c5c975e..04a2113cc8 100644
>> --- a/libavcodec/vp8.c
>> +++ b/libavcodec/vp8.c
>> @@ -637,7 +637,6 @@ static int vp7_decode_frame_header(VP8Context *s, const 
>> uint8_t *buf, int buf_si
>>  for (i = 0; i < 2; i++)
>>  memcpy(s->prob->mvc[i], vp7_mv_default_prob[i],
>> sizeof(vp7_mv_default_prob[i]));
>> -memset(&s->lf_delta, 0, sizeof(s->lf_delta));
>>  memcpy(s->prob[0].scan, ff_zigzag_scan, sizeof(s->prob[0].scan));
>>  }
>>  
>> @@ -2171,7 +2170,7 @@ void filter_level_for_mb(VP8Context *s, VP8Macroblock 
>> *mb,
>>  } else
>>  filter_level = s->filter.level;
>>  
>> -if (s->lf_delta.enabled) {
>> +if (!is_vp7 && s->lf_delta.enabled) {
>>  filter_level += s->lf_delta.ref[mb->ref_frame];
>>  filter_level += s->lf_delta.mode[mb->mode];
>>  }
> 
> what's the motivation for patches 01 and 02?
> are you not just adding another condition (is_vp7) to evaluate at decode time?
> if its improved readability, then suggest renaming 'lf_delta' to 
> 'lf_delta_vp8'
> 
> pathces 3-18 look fine to me.
> 

is_vp7 is evaluated at compile-time, because all the functions that use
is_vp7 in this decoder are marked as av_always_inline.
If it were otherwise, several of the patches 3-18 would make no sense
and would just add another runtime check.

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