Re: [FFmpeg-devel] [PATCH] avcodec/av1dec: check avctx->hwaccel when hwaccel pix_fmt selected

2020-09-28 Thread Xiang, Haihao
On Mon, 2020-09-28 at 23:35 -0300, James Almer wrote:
> On 9/28/2020 11:33 PM, Xiang, Haihao wrote:
> > On Sat, 2020-09-26 at 13:05 -0300, James Almer wrote:
> > > On 9/25/2020 4:35 AM, Xiang, Haihao wrote:
> > > > Since commit e46f34e8 was merged, I also saw the same error message when
> > > > I
> > > > tested my QSV av1 patch (
> > > > http://ffmpeg.org/pipermail/ffmpeg-devel/2020-September/270234.html)
> > > > however
> > > > the
> > > > command worked well for me.
> > > > 
> > > > [av1 @ 0x55b1604c42d0] Your platform doesn't suppport hardware
> > > > accelerated
> > > > AV1
> > > > decoding.
> > > > [av1 @ 0x55b1604c42d0] Failed to get pixel format.
> > > > [av1 @ 0x55b1604c42d0] video_get_buffer: image parameters invalid
> > > > [av1 @ 0x55b1604c42d0] get_buffer() failed
> > > > [av1 @ 0x55b1604c42d0] thread_get_buffer() failed
> > > > [av1 @ 0x55b1604c42d0] Failed to allocate space for current frame.
> > > > [av1 @ 0x55b1604c42d0] Get current frame error
> > > > 
> > > > I agree with Fei that the user will be confused with this error message.
> > > > 
> > > > Thanks
> > > > Haihao
> > > 
> > > I guess we could change it to warning, but every other printed message
> > > will be an error and there's not much else we can do.
> > > 
> > > I sent a patchset that prevents calling get_buffer() when no pix_fmt is
> > > set, so the errors it will print from then on will be less scary.
> > 
> > What's the subject of your patchset? I'd like to give a try with your
> > patchset.
> > 
> > Thanks
> > Haihao
> 
> First patch in the set is called "[PATCH 1/8] avcodec/cbs: add a flush
> callback to CodedBitstreamType".

Thanks, I will give a try.

> ___
> 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 2/2] libswcale/input: use more accurate rgbf32 yuv conversions

2020-09-28 Thread mindmark
From: Mark Reid 

---
 libswscale/input.c  |  12 ++-
 tests/ref/fate/filter-pixfmts-scale |   8 +-
 tests/ref/fate/sws-floatimg-cmp | 122 ++--
 3 files changed, 70 insertions(+), 72 deletions(-)

diff --git a/libswscale/input.c b/libswscale/input.c
index 064ed5902f..67a85b0418 100644
--- a/libswscale/input.c
+++ b/libswscale/input.c
@@ -984,15 +984,14 @@ static av_always_inline void planar_rgbf32_to_uv(uint8_t 
*_dstU, uint8_t *_dstV,
 uint16_t *dstV   = (uint16_t *)_dstV;
 int32_t ru = rgb2yuv[RU_IDX], gu = rgb2yuv[GU_IDX], bu = rgb2yuv[BU_IDX];
 int32_t rv = rgb2yuv[RV_IDX], gv = rgb2yuv[GV_IDX], bv = rgb2yuv[BV_IDX];
-int bpc = 16;
-int shift = 14;
+
 for (i = 0; i < width; i++) {
 int g = av_clip_uint16(lrintf(65535.0f * rdpx(src[0] + i)));
 int b = av_clip_uint16(lrintf(65535.0f * rdpx(src[1] + i)));
 int r = av_clip_uint16(lrintf(65535.0f * rdpx(src[2] + i)));
 
-dstU[i] = (ru*r + gu*g + bu*b + (257 << (RGB2YUV_SHIFT + bpc - 9))) >> 
(RGB2YUV_SHIFT + shift - 14);
-dstV[i] = (rv*r + gv*g + bv*b + (257 << (RGB2YUV_SHIFT + bpc - 9))) >> 
(RGB2YUV_SHIFT + shift - 14);
+dstU[i] = (ru*r + gu*g + bu*b + (0x10001 << (RGB2YUV_SHIFT - 1))) >> 
RGB2YUV_SHIFT;
+dstV[i] = (rv*r + gv*g + bv*b + (0x10001 << (RGB2YUV_SHIFT - 1))) >> 
RGB2YUV_SHIFT;
 }
 }
 
@@ -1003,14 +1002,13 @@ static av_always_inline void planar_rgbf32_to_y(uint8_t 
*_dst, const uint8_t *_s
 uint16_t *dst= (uint16_t *)_dst;
 
 int32_t ry = rgb2yuv[RY_IDX], gy = rgb2yuv[GY_IDX], by = rgb2yuv[BY_IDX];
-int bpc = 16;
-int shift = 14;
+
 for (i = 0; i < width; i++) {
 int g = av_clip_uint16(lrintf(65535.0f * rdpx(src[0] + i)));
 int b = av_clip_uint16(lrintf(65535.0f * rdpx(src[1] + i)));
 int r = av_clip_uint16(lrintf(65535.0f * rdpx(src[2] + i)));
 
-dst[i] = ((ry*r + gy*g + by*b + (33 << (RGB2YUV_SHIFT + bpc - 9))) >> 
(RGB2YUV_SHIFT + shift - 14));
+dst[i] = (ry*r + gy*g + by*b + (0x2001 << (RGB2YUV_SHIFT - 1))) >> 
RGB2YUV_SHIFT;
 }
 }
 
diff --git a/tests/ref/fate/filter-pixfmts-scale 
b/tests/ref/fate/filter-pixfmts-scale
index d7020ad2c3..30e7cd5b06 100644
--- a/tests/ref/fate/filter-pixfmts-scale
+++ b/tests/ref/fate/filter-pixfmts-scale
@@ -25,8 +25,8 @@ gbrap12be   1d9b57766ba9c2192403f43967cb9af0
 gbrap12le   bb1ba1c157717db3dd612a76d38a018e
 gbrap16be   c72b935a6e57a8e1c37bff08c2db55b1
 gbrap16le   13eb0e62b1ac9c1c86c81521eaefab5f
-gbrapf32be  42e53d9edccbd9e09c4cd78780ba92f3
-gbrapf32le  eebf3973ef94c841f0a1ceb1ed61621d
+gbrapf32be  366b804d5697276e8c481c4bdf05a00b
+gbrapf32le  558a268e6d6b907449d1056afab78f29
 gbrpdc3387f925f972c61aae7eb23cdc19f0
 gbrp10be0277d4c3a8498d75e2783fb81379e481
 gbrp10lef3d70f8ab845c3c9b8f7452e4a6e285a
@@ -38,8 +38,8 @@ gbrp16be5fc826cfabebfc1442cb793c4b6303e2
 gbrp16le1b3e0b63d47a3e1b6b20931316883bf2
 gbrp9be d9c88968001e1452ff31fbc8d16b18a0
 gbrp9le 2ccfed0816bf6bd4bb3a5b7591d9603a
-gbrpf32be   4614d32e4417f80e0adcc1bdcf6cde42
-gbrpf32le   1366ee77e5559672260bbe51040e28b2
+gbrpf32be   f3d0cefdf11c861001880772d817aac8
+gbrpf32le   290468205c1c18a0667edfca45061aee
 gray221201cc7cfc4964eacd8b3e426fd276
 gray10be9452756d0b37f4f5c7cae7635e22d747
 gray10le37fd2e1ec6b66410212d39a342e864df
diff --git a/tests/ref/fate/sws-floatimg-cmp b/tests/ref/fate/sws-floatimg-cmp
index 24204254c4..cf6788fc23 100644
--- a/tests/ref/fate/sws-floatimg-cmp
+++ b/tests/ref/fate/sws-floatimg-cmp
@@ -1,120 +1,120 @@
 gbrpf32le -> yuv444p16le -> gbrpf32le
-avg diff: 0.003852
+avg diff: 0.000125
 min diff: 0.00
-max diff: 0.006638
+max diff: 0.000501
 gbrpf32le -> yuv444p -> gbrpf32le
-avg diff: 0.004316
+avg diff: 0.001804
 min diff: 0.00
-max diff: 0.012704
+max diff: 0.006399
 gbrpf32le -> yuv444p9le -> gbrpf32le
-avg diff: 0.004053
-min diff: 0.01
-max diff: 0.009402
+avg diff: 0.000906
+min diff: 0.00
+max diff: 0.003313
 gbrpf32le -> yuv444p10le -> gbrpf32le
-avg diff: 0.003960
+avg diff: 0.000467
 min diff: 0.00
-max diff: 0.008123
+max diff: 0.001912
 gbrpf32le -> yuv444p12le -> gbrpf32le
-avg diff: 0.003878
+avg diff: 0.000166
 min diff: 0.00
-max diff: 0.007011
+max diff: 0.000802
 gbrpf32le -> yuv444p14le -> gbrpf32le
-avg diff: 0.003868
+avg diff: 0.000127
 min diff: 0.00
-max diff: 0.006729
+max diff: 0.000524
 gbrpf32le -> rgb24 -> gbrpf32le
-avg diff: 0.004122
+avg diff: 0.001011
 min diff: 0.00
-max diff: 0.008975
+max diff: 0.004229
 gbrpf32le -> bgr24 -> gbrpf32le
-avg diff: 0.004122
+avg diff: 0.001011
 min diff: 0.00
-max diff: 0.008975
+max diff: 0.004229
 gbrpf32le -> rgba -> gbrpf32le
-avg diff: 0.004122
+avg diff: 0.001011
 min diff: 0.00
-max diff: 0.008975

[FFmpeg-devel] [PATCH v2 1/2] libswscale/tests: add floatimg_cmp test

2020-09-28 Thread mindmark
From: Mark Reid 

changes since v1:
- made into fate test
- fixed c90 warnings
- tests more intermediate formats 
- tested on BE mips too

---
 libswscale/Makefile |   1 +
 libswscale/tests/.gitignore |   1 +
 libswscale/tests/floatimg_cmp.c | 296 
 tests/fate/libswscale.mak   |   4 +
 tests/ref/fate/sws-floatimg-cmp | 120 +
 5 files changed, 422 insertions(+)
 create mode 100644 libswscale/tests/floatimg_cmp.c
 create mode 100644 tests/ref/fate/sws-floatimg-cmp

diff --git a/libswscale/Makefile b/libswscale/Makefile
index 5e03e6fa0a..4b8f9de425 100644
--- a/libswscale/Makefile
+++ b/libswscale/Makefile
@@ -25,5 +25,6 @@ OBJS-$(CONFIG_SHARED)+= log2_tab.o
 SLIBOBJS-$(HAVE_GNU_WINDRES) += swscaleres.o
 
 TESTPROGS = colorspace  \
+floatimg_cmp\
 pixdesc_query   \
 swscale \
diff --git a/libswscale/tests/.gitignore b/libswscale/tests/.gitignore
index 1a26f038c4..c56abf0ee7 100644
--- a/libswscale/tests/.gitignore
+++ b/libswscale/tests/.gitignore
@@ -1,3 +1,4 @@
 /colorspace
+/floatimg_cmp
 /pixdesc_query
 /swscale
diff --git a/libswscale/tests/floatimg_cmp.c b/libswscale/tests/floatimg_cmp.c
new file mode 100644
index 00..5c67594fb6
--- /dev/null
+++ b/libswscale/tests/floatimg_cmp.c
@@ -0,0 +1,296 @@
+/*
+ * This file is part of FFmpeg.
+ *
+ * FFmpeg is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public
+ * License as published by the Free Software Foundation; either
+ * version 2.1 of the License, or (at your option) any later version.
+ *
+ * FFmpeg is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+ * Lesser General Public License for more details.
+ *
+ * You should have received a copy of the GNU Lesser General Public
+ * License along with FFmpeg; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "libavutil/avutil.h"
+#include "libavutil/imgutils.h"
+#include "libavutil/intfloat.h"
+#include "libavutil/intreadwrite.h"
+#include "libavutil/lfg.h"
+#include "libavutil/mem.h"
+#include "libavutil/parseutils.h"
+#include "libavutil/pixdesc.h"
+
+#include "libswscale/swscale.h"
+
+#define DEFAULT_W 96
+#define DEFAULT_H 96
+
+static const enum AVPixelFormat pix_fmts[] = {
+AV_PIX_FMT_YUV444P16LE,
+AV_PIX_FMT_YUV444P,
+AV_PIX_FMT_YUV444P9LE, AV_PIX_FMT_YUV444P10LE,
+AV_PIX_FMT_YUV444P12LE, AV_PIX_FMT_YUV444P14LE,
+AV_PIX_FMT_RGB24,  AV_PIX_FMT_BGR24,
+AV_PIX_FMT_RGBA,   AV_PIX_FMT_BGRA,
+AV_PIX_FMT_ARGB,   AV_PIX_FMT_ABGR,
+AV_PIX_FMT_0RGB,   AV_PIX_FMT_0BGR,
+AV_PIX_FMT_RGB0,   AV_PIX_FMT_BGR0,
+AV_PIX_FMT_RGB48LE,  AV_PIX_FMT_BGR48LE,
+AV_PIX_FMT_RGBA64LE, AV_PIX_FMT_BGRA64LE,
+AV_PIX_FMT_GBRP,   AV_PIX_FMT_GBRAP,
+AV_PIX_FMT_GBRP9LE,
+AV_PIX_FMT_GBRP10LE, AV_PIX_FMT_GBRAP10LE,
+AV_PIX_FMT_GBRP12LE, AV_PIX_FMT_GBRAP12LE,
+AV_PIX_FMT_GBRP14LE,
+AV_PIX_FMT_GBRP16LE,  AV_PIX_FMT_GBRAP16LE
+};
+
+const char *usage =  "floatimg_cmp -pixel_format  -size  
-ref \n";
+
+int main(int argc, char **argv)
+{
+enum AVPixelFormat inFormat = AV_PIX_FMT_NONE;
+enum AVPixelFormat dstFormat = AV_PIX_FMT_NONE;
+const AVPixFmtDescriptor *desc;
+uint8_t *ptr;
+uint32_t *in, *out;
+
+uint8_t *rgbIn[4]  = {NULL, NULL, NULL, NULL};
+uint8_t *rgbOut[4] = {NULL, NULL, NULL, NULL};
+int rgbStride[4];
+
+uint8_t *dst[4] = {NULL, NULL, NULL, NULL};
+int dstStride[4];
+
+int i, x, y, p, size, count;
+int res = -1;
+int w = -1;
+int h = -1;
+union av_intfloat32 v0, v1;
+
+double sum;
+float minimum, maximum, diff;
+
+struct SwsContext *sws = NULL;
+AVLFG rand;
+FILE *fp = NULL;
+
+for (i = 1; i < argc; i += 2) {
+if (argv[i][0] != '-' || i + 1 == argc)
+goto bad_option;
+if (!strcmp(argv[i], "-ref")) {
+fp = fopen(argv[i + 1], "rb");
+if (!fp) {
+fprintf(stderr, "could not open '%s'\n", argv[i + 1]);
+goto end;
+}
+} else if (!strcmp(argv[i], "-size")) {
+res = av_parse_video_size(&w, &h, argv[i + 1]);
+if (res < 0) {
+fprintf(stderr, "invalid video size %s\n",  argv[i + 1]);
+goto end;
+}
+} else if (!strcmp(argv[i], "-pixel_format")) {
+inFormat = av_get_pix_fmt(argv[i + 1]);
+if (inFormat == AV_PIX_FMT_NONE) {
+fprintf(stde

Re: [FFmpeg-devel] [PATCH] avcodec/av1dec: check avctx->hwaccel when hwaccel pix_fmt selected

2020-09-28 Thread James Almer
On 9/28/2020 11:33 PM, Xiang, Haihao wrote:
> On Sat, 2020-09-26 at 13:05 -0300, James Almer wrote:
>> On 9/25/2020 4:35 AM, Xiang, Haihao wrote:
>>> Since commit e46f34e8 was merged, I also saw the same error message when I
>>> tested my QSV av1 patch (
>>> http://ffmpeg.org/pipermail/ffmpeg-devel/2020-September/270234.html) however
>>> the
>>> command worked well for me.
>>>
>>> [av1 @ 0x55b1604c42d0] Your platform doesn't suppport hardware accelerated
>>> AV1
>>> decoding.
>>> [av1 @ 0x55b1604c42d0] Failed to get pixel format.
>>> [av1 @ 0x55b1604c42d0] video_get_buffer: image parameters invalid
>>> [av1 @ 0x55b1604c42d0] get_buffer() failed
>>> [av1 @ 0x55b1604c42d0] thread_get_buffer() failed
>>> [av1 @ 0x55b1604c42d0] Failed to allocate space for current frame.
>>> [av1 @ 0x55b1604c42d0] Get current frame error
>>>
>>> I agree with Fei that the user will be confused with this error message.
>>>
>>> Thanks
>>> Haihao
>>
>> I guess we could change it to warning, but every other printed message
>> will be an error and there's not much else we can do.
>>
>> I sent a patchset that prevents calling get_buffer() when no pix_fmt is
>> set, so the errors it will print from then on will be less scary.
> 
> What's the subject of your patchset? I'd like to give a try with your 
> patchset.
> 
> Thanks
> Haihao

First patch in the set is called "[PATCH 1/8] avcodec/cbs: add a flush
callback to CodedBitstreamType".
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

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

Re: [FFmpeg-devel] [PATCH] lavc/qsvenc: let the SDK to choose the encoding mode by default

2020-09-28 Thread Xiang, Haihao

> it would be good to describe the change a bit more clearly,
> something like: Allows MediaSDK *runtime *to choose LowPower/non-LowPower
> modes, if not explicitly set.

Thanks for the comment, I will update the commit log.

Regards
Haihao

> regards
> Max
> 
> On Mon, Sep 28, 2020 at 9:32 AM Haihao Xiang  wrote:
> 
> > The SDK may support LowPower and non-LowPower modes, some features are
> > available only under one of the two modes. It is hard for user to know
> > whether a feature is supported under the given mode, so let the SDK to
> > choose a mode for encoding by default.
> > ---
> >  libavcodec/qsvenc.c | 6 --
> >  libavcodec/qsvenc.h | 2 +-
> >  2 files changed, 5 insertions(+), 3 deletions(-)
> > 
> > diff --git a/libavcodec/qsvenc.c b/libavcodec/qsvenc.c
> > index 1ed8f5d973..cff96e59c9 100644
> > --- a/libavcodec/qsvenc.c
> > +++ b/libavcodec/qsvenc.c
> > @@ -510,7 +510,7 @@ static int init_video_param(AVCodecContext *avctx,
> > QSVEncContext *q)
> >  }
> >  }
> > 
> > -if (q->low_power) {
> > +if (q->low_power == 1) {
> >  #if QSV_HAVE_VDENC
> >  q->param.mfx.LowPower = MFX_CODINGOPTION_ON;
> >  #else
> > @@ -519,7 +519,9 @@ static int init_video_param(AVCodecContext *avctx,
> > QSVEncContext *q)
> >  q->low_power = 0;
> >  q->param.mfx.LowPower = MFX_CODINGOPTION_OFF;
> >  #endif
> > -} else
> > +} else if (q->low_power == -1)
> > +q->param.mfx.LowPower = MFX_CODINGOPTION_UNKNOWN;
> > +else
> >  q->param.mfx.LowPower = MFX_CODINGOPTION_OFF;
> > 
> >  q->param.mfx.CodecProfile   = q->profile;
> > diff --git a/libavcodec/qsvenc.h b/libavcodec/qsvenc.h
> > index 4f579d1db1..55cc1a 100644
> > --- a/libavcodec/qsvenc.h
> > +++ b/libavcodec/qsvenc.h
> > @@ -96,7 +96,7 @@
> >  { "adaptive_b", "Adaptive B-frame placement",
> >  OFFSET(qsv.adaptive_b), AV_OPT_TYPE_INT, { .i64 = -1 }, -1,
> > 1, VE }, \
> >  { "b_strategy", "Strategy to choose between I/P/B-frames",
> > OFFSET(qsv.b_strategy),AV_OPT_TYPE_INT, { .i64 = -1 }, -1,  1,
> > VE }, \
> >  { "forced_idr", "Forcing I frames as IDR frames",
> >  OFFSET(qsv.forced_idr), AV_OPT_TYPE_BOOL,{ .i64 = 0  },  0,
> > 1, VE }, \
> > -{ "low_power", "enable low power mode(experimental: many limitations by
> > mfx version, BRC modes, etc.)", OFFSET(qsv.low_power), AV_OPT_TYPE_BOOL, {
> > .i64 = 0}, 0, 1, VE},\
> > +{ "low_power", "enable low power mode(experimental: many limitations by
> > mfx version, BRC modes, etc.)", OFFSET(qsv.low_power), AV_OPT_TYPE_BOOL, {
> > .i64 = -1}, -1, 1, VE},\
> > 
> >  extern const AVCodecHWConfigInternal *ff_qsv_enc_hw_configs[];
> > 
> > --
> > 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 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/av1dec: check avctx->hwaccel when hwaccel pix_fmt selected

2020-09-28 Thread Xiang, Haihao
On Sat, 2020-09-26 at 13:05 -0300, James Almer wrote:
> On 9/25/2020 4:35 AM, Xiang, Haihao wrote:
> > On Fri, 2020-09-25 at 06:10 +, Wang, Fei W wrote:
> > > > -Original Message-
> > > > From: ffmpeg-devel  On Behalf Of Wang,
> > > > Fei W
> > > > Sent: Tuesday, September 22, 2020 11:22 AM
> > > > To: FFmpeg development discussions and patches 
> > > > Subject: Re: [FFmpeg-devel] [PATCH] avcodec/av1dec: check avctx->hwaccel
> > > > when hwaccel pix_fmt selected
> > > > 
> > > > 
> > > > 
> > > > > -Original Message-
> > > > > From: ffmpeg-devel  On Behalf Of
> > > > > James Almer
> > > > > Sent: Friday, September 18, 2020 8:57 PM
> > > > > To: ffmpeg-devel@ffmpeg.org
> > > > > Subject: Re: [FFmpeg-devel] [PATCH] avcodec/av1dec: check
> > > > > avctx->hwaccel when hwaccel pix_fmt selected
> > > > > 
> > > > > On 9/18/2020 2:40 AM, Wang, Fei W wrote:
> > > > > > 
> > > > > > 
> > > > > > > -Original Message-
> > > > > > > From: ffmpeg-devel  On Behalf Of
> > > > > > > Hendrik Leppkes
> > > > > > > Sent: Thursday, September 17, 2020 5:21 PM
> > > > > > > To: FFmpeg development discussions and patches
> > > > > > > 
> > > > > > > Subject: Re: [FFmpeg-devel] [PATCH] avcodec/av1dec: check
> > > > > > > avctx->hwaccel when hwaccel pix_fmt selected
> > > > > > > 
> > > > > > > On Thu, Sep 17, 2020 at 10:38 AM Fei Wang 
> > > > 
> > > > wrote:
> > > > > > > > 
> > > > > > > > Pix fmt with hwaccel flag may not be chosen in format probing,
> > > > > > > > in
> > > > > > > > this case avctx->hwaccel will not be inited.
> > > > > > > > 
> > > > > > > > Signed-off-by: Fei Wang 
> > > > > > > > ---
> > > > > > > >  libavcodec/av1dec.c | 12 
> > > > > > > >  1 file changed, 8 insertions(+), 4 deletions(-)
> > > > > > > > 
> > > > > > > > diff --git a/libavcodec/av1dec.c b/libavcodec/av1dec.c index
> > > > > > > > 0bb04a3e44..cdcc618013 100644
> > > > > > > > --- a/libavcodec/av1dec.c
> > > > > > > > +++ b/libavcodec/av1dec.c
> > > > > > > > @@ -251,6 +251,7 @@ static int get_pixel_format(AVCodecContext
> > > > > > > > *avctx) {
> > > > > > > >  AV1DecContext *s = avctx->priv_data;
> > > > > > > >  const AV1RawSequenceHeader *seq = s->raw_seq;
> > > > > > > > +const AVPixFmtDescriptor *desc;
> > > > > > > >  uint8_t bit_depth;
> > > > > > > >  int ret;
> > > > > > > >  enum AVPixelFormat pix_fmt = AV_PIX_FMT_NONE; @@ -327,10
> > > > > > > > +328,13 @@ static int get_pixel_format(AVCodecContext *avctx)
> > > > > > > >   * Since now the av1 decoder doesn't support native decode,
> > > > > > > > if
> > > > > > > > it will be
> > > > > > > >   * implemented in the future, need remove this check.
> > > > > > > >   */
> > > > > > > > -if (!avctx->hwaccel) {
> > > > > > > > -av_log(avctx, AV_LOG_ERROR, "Your platform doesn't
> > > > > > > > suppport"
> > > > > > > > -   " hardware accelerated AV1 decoding.\n");
> > > > > > > > -return AVERROR(ENOSYS);
> > > > > > > > +desc = av_pix_fmt_desc_get(ret);
> > > > > > > > +if (desc && (desc->flags & AV_PIX_FMT_FLAG_HWACCEL)) {
> > > > > > > > +if (!avctx->hwaccel) {
> > > > > > > > +av_log(avctx, AV_LOG_ERROR, "Your platform doesn't
> > > > > > > > suppport"
> > > > > > > > +   " hardware accelerated AV1 decoding.\n");
> > > > > > > > +return AVERROR(ENOSYS);
> > > > > > > > +}
> > > > > > > >  }
> > > > > > > > 
> > > > > > > 
> > > > > > > Isn't it supposed to quit here, because we do not have software
> > > > > > > decoding?
> > > > > > 
> > > > > > Since now av1 decoder allow probe, that will try to decode first
> > > > > > frame to find stream info in open_file stage. While the hwaccel will
> > > > > > not
> > > > > > be
> > > > 
> > > > inited.
> > > > > > If without change here, the error log will be print out but later
> > > > > > during transcode stage, it can gives out the correct output.
> > > > > 
> > > > > If you let it choose a software pix_fmt, it will think the decoder can
> > > > > actually output something, which is not true.
> > > > 
> > > > It's better not let ff_thread_get_format choose a software pix fmt here,
> > > > but
> > > > for
> > > > VAAPI the avctx->hw_device_ctx hasn't been created in probing so that
> > > > hwaccel
> > > > can not be inited and hwaccel pix fmt will not be chosen(same mechanism
> > > > with
> > > > other codecs). And then next available pix fmt in input array will be
> > > > considered.
> > > > 
> > > > > Probing works fine even if it fails at this point. It will have set
> > > > > enough AVCodecContext fields to allow things like remuxing, hence the
> > > > > relevant fate tests succeeding as is.
> > > > 
> > > > Yes, probing allows fail here. How about to keep the original
> > > > check(!avctx-
> > > > > hwaccel), and change log context as like "Hardware context not created
> > > > > or
> > > > 
> > > > your platform doesn't support hardware accelerated AV1 deco

Re: [FFmpeg-devel] [PATCH 2/2] libswcale/input: fix incorrect rgbf32 yuv conversions

2020-09-28 Thread Mark Reid
On Mon, Sep 28, 2020 at 10:38 AM Michael Niedermayer 
wrote:

> On Sat, Sep 26, 2020 at 10:01:30PM -0700, Mark Reid wrote:
> > On Mon, Sep 14, 2020 at 6:31 PM Mark Reid  wrote:
> >
> > >
> > >
> > > On Mon, Sep 14, 2020 at 2:44 PM Michael Niedermayer
> 
> > > wrote:
> > >
> > >> On Sun, Sep 13, 2020 at 04:04:42PM -0700, Mark Reid wrote:
> > >> > On Sun, Sep 13, 2020 at 8:55 AM Michael Niedermayer
> > >> 
> > >> > wrote:
> > >> >
> > >> > > On Sat, Sep 12, 2020 at 02:07:14AM -0700, mindm...@gmail.com
> wrote:
> > >> > > > From: Mark Reid 
> > >> > > >
> > >> > > > ---
> > >> > > >  libswscale/input.c  | 12 +---
> > >> > > >  tests/ref/fate/filter-pixfmts-scale |  8 
> > >> > > >  2 files changed, 9 insertions(+), 11 deletions(-)
> > >> > >
> > >> > > Can you provide some tests that show that this is better ?
> > >> > > Iam asking that because some of the numbers in some of the code
> > >> > > (i dont remember which) where tuned to give more accurate overall
> > >> results
> > >> > >
> > >> > > an example for tests would be converting from A->B->A then
> compare to
> > >> the
> > >> > > orig
> > >> > >
> > >> > > thx
> > >> > >
> > >> > >
> > >> > Hopefully i can explain this clearly!
> > >> >
> > >> > It's easier to see the error if you run a black image through the
> old
> > >> > conversion.
> > >> > zero values don't get mapped to zero. (attached sample image)
> > >> >
> > >> > ffmpeg -i 4x4_zero.exr -pix_fmt rgb48le -f rawvideo
> 4x4_zero.rawvideo
> > >> > The image should be rgb 0, 0, 0  everywhere but instead it's 353,
> 0, 407
> > >> >
> > >> >
> > >> > I think this is a error in fixed point rounding, the issue is
> basically
> > >> > boils down to
> > >> >
> > >> > 128 << 8 != 257 << 7
> > >> > and
> > >> > 16 << 8  != 33 << 7
> > >> >
> > >> > https://en.wikipedia.org/wiki/YUV#Studio_swing_for_BT.601
> > >> > the 8 bit rgb to yuv formula is
> > >> >
> > >> > Y = ry*r + gy*g + by*b  + 16
> > >> > U = ru*r + gu*g + bu*b + 128
> > >> > V = rv*r + gv*g + bv*b + 128
> > >> >
> > >> > I think the studio swing offsets at the end are calculated wrong in
> the
> > >> old
> > >> > code.
> > >> > (257 << (RGB2YUV_SHIFT + bpc - 9)))
> > >> > 257 is correct for 8 bit rounding but not for 16-bit.
> > >> >
> > >> > the 257 i believe is from (128 << 1) + 1
> > >> > the +1 is for rounding
> > >> >
> > >> > for rounding 16-bit (128 << 9) + 1 = 0x10001
> > >> >
> > >> > therefore I think the correct rounding any bit depth with the old
> > >> formula
> > >> > would be (untested)
> > >> > (((128 << (bpc - 7)) + 1) << (RGB2YUV_SHIFT-1) )
> > >> >
> > >> > I just simplified it to
> > >> > (0x10001 << (RGB2YUV_SHIFT - 1))
> > >> >
> > >> > The rgb48ToUV and rgb48ToY funcs in input.c use the formula I'm
> using.
> > >>
> > >> You quite possibly are correct, can you test that this actually works
> > >> out. The test sample only covers 1 color (black)
> > >> a testsample covering a wide range of the color cube would be more
> > >> convincing that this change is needed and sufficient to fix this.
> > >>
> > >> thx
> > >>
> > >
> > > I wrote a small python script to compare the raw gbrpf32le images if
> that
> > > works? I attached it and also a more colorful test pattern.
> > >
> > > it runs these two commands and compares the 2 raw float images
> > > ffmpeg -y -i test_pattern.exr -f rawvideo original.gbrpf32le
> > > ffmpeg -y -i test_pattern.exr -vf
> > > format=pix_fmts=rgb48le,format=pix_fmts=gbrpf32le -f rawvideo
> > > converted.gbrpf32le
> > >
> > > python gbrpf32le_diff.py test_pattern.exr
> > >
> > > without patch:
> > > avg error: 237.445495855
> > > min error: 0.0
> > > max error: 468.399102688
> > >
> > > with patch:
> > > avg error: 15.9312244829
> > > min error: 0.0
> > > max error: 69.467689991
> > >
> > >
> > > These are floating points scaled to 16-bit values.
> > > Even with my patch, I'm kinda disturbed how much error there is.
> > >
> >
> > ping
> > I re-wrote the python script as a c swscale test, if that helps
> > replicate my results. attached is patch for that.
> > it generates an image of random float values and does the
> > conversion/comparison .
> >
> > before patch:
> > gbrpf32le -> yuva444p16le -> gbrpf32le
> > avg diff: 0.003852
> > min diff: 0.00
> > max diff: 0.006638
> >
> > after patch:
> > gbrpf32le -> yuva444p16le -> gbrpf32le
> > avg diff: 0.000125
> > min diff: 0.00
> > max diff: 0.000501
>
> is it better for all middle formats ?
> Iam asking as it seems this should be rather easy to test with your code
>

good idea, yes it looks better for other intermediate formats too, see my
results below.
I'll submit a new version of patch that does this and with the warnings
fixed.

gbrpf32le -> yuv444p16le -> gbrpf32le
avg diff: 0.003852  avg diff: 0.000125
min diff: 0.00  min diff: 0.00
max diff: 0.006638 max diff: 0.000501

gbrpf32le -> yuv444p -> gbrpf32le
avg diff: 0.004316  avg diff: 0.001804
min diff: 0.00  min diff: 0.

Re: [FFmpeg-devel] [PATCH 2/2] avcodec/mv30: Fix several integer overflows in idct_1d()

2020-09-28 Thread Michael Niedermayer
On Sun, Jul 26, 2020 at 12:16:37AM +0200, Michael Niedermayer wrote:
> Fixes: signed integer overflow: -1846510390 + -361755993 cannot be 
> represented in type 'int'
> Fixes: 
> 23941/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_MV30_fuzzer-5654696631730176
> 
> Found-by: continuous fuzzing process 
> https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
> Signed-off-by: Michael Niedermayer 
> ---
>  libavcodec/mv30.c | 34 +-
>  1 file changed, 17 insertions(+), 17 deletions(-)

will apply

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

Take away the freedom of one citizen and you will be jailed, take away
the freedom of all citizens and you will be congratulated by your peers
in Parliament.


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] avcodec/pgxdec: Fix invalid shift in write_frame_*

2020-09-28 Thread Michael Niedermayer
On Sun, Jul 26, 2020 at 04:43:12AM +0200, Andreas Rheinhardt wrote:
> Michael Niedermayer:
> > Fixes: left shift of negative value -121
> > Fixes: 
> > 23911/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_PGX_fuzzer-4986800258154496
> > 
> > Found-by: continuous fuzzing process 
> > https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
> > Signed-off-by: Michael Niedermayer 
> > ---
> >  libavcodec/pgxdec.c | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> > 
> > diff --git a/libavcodec/pgxdec.c b/libavcodec/pgxdec.c
> > index 93b9f4e7a0..e72ec84152 100644
> > --- a/libavcodec/pgxdec.c
> > +++ b/libavcodec/pgxdec.c
> > @@ -102,7 +102,7 @@ error:
> >  for (i = 0; i < height; i++) { 
> >  \
> >  PIXEL *line = (PIXEL*)frame->data[0] + 
> > i*frame->linesize[0]/sizeof(PIXEL);  \
> >  for (j = 0; j < width; j++) {  
> >  \
> > -int val;   
> >  \
> > +unsigned val;  
> >   \
> 
> "unsigned" is longer than "int", so you need to delete a few spaces or
> the '\' won't be in line with the others any more.

will apply with this fixed

thx

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

Many things microsoft did are stupid, but not doing something just because
microsoft did it is even more stupid. If everything ms did were stupid they
would be bankrupt already.


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 v2] avformat/movenc: handle tracks w/o AVStreams in calculate_mpeg4_bit_rates

2020-09-28 Thread Jan Ekström
On Mon, Sep 28, 2020 at 11:57 PM Jan Ekström  wrote:
>
> The generated text streams for chapters lack an AVStream since they
> are but an internal concept within movenc.
>
> Fixes #8190

Yes, I have now twice missed the fact that it is #8910 and not #8190.
But fret not, I have noticed my mistake by now :) .

Jan
___
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/movenc: handle tracks w/o AVStreams in calculate_mpeg4_bit_rates

2020-09-28 Thread Jan Ekström
The generated text streams for chapters lack an AVStream since they
are but an internal concept within movenc.

Fixes #8190
---
 libavformat/movenc.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/libavformat/movenc.c b/libavformat/movenc.c
index 20768cd45f..c1ff922e88 100644
--- a/libavformat/movenc.c
+++ b/libavformat/movenc.c
@@ -641,10 +641,11 @@ struct mpeg4_bit_rate_values {
 
 static struct mpeg4_bit_rate_values calculate_mpeg4_bit_rates(MOVTrack *track)
 {
-AVCPBProperties *props =
+AVCPBProperties *props = track->st ?
 (AVCPBProperties*)av_stream_get_side_data(track->st,
   AV_PKT_DATA_CPB_PROPERTIES,
-  NULL);
+  NULL) :
+NULL;
 struct mpeg4_bit_rate_values bit_rates = { 0 };
 
 bit_rates.avg_bit_rate = compute_avg_bitrate(track);
-- 
2.26.2

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

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

[FFmpeg-devel] [PATCH] avcodec/qsv: Fix leak of options on error

2020-09-28 Thread Andreas Rheinhardt
Signed-off-by: Andreas Rheinhardt 
---
 libavcodec/qsv.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/libavcodec/qsv.c b/libavcodec/qsv.c
index 7816d2f93c..6e3154e1a3 100644
--- a/libavcodec/qsv.c
+++ b/libavcodec/qsv.c
@@ -361,6 +361,7 @@ static int ff_qsv_set_display_handle(AVCodecContext *avctx, 
QSVSession *qs)
 av_dict_set(&child_device_opts, "driver","iHD",  0);
 
 ret = av_hwdevice_ctx_create(&qs->va_device_ref, AV_HWDEVICE_TYPE_VAAPI, 
NULL, child_device_opts, 0);
+av_dict_free(&child_device_opts);
 if (ret < 0) {
 av_log(avctx, AV_LOG_ERROR, "Failed to create a VAAPI device.\n");
 return ret;
@@ -375,8 +376,6 @@ static int ff_qsv_set_display_handle(AVCodecContext *avctx, 
QSVSession *qs)
 }
 }
 
-av_dict_free(&child_device_opts);
-
 return 0;
 }
 #endif //AVCODEC_QSV_LINUX_SESSION_HANDLE
-- 
2.25.1

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

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

Re: [FFmpeg-devel] [PATCH 1/2] avformat/iff: Check data_size not overflowing int64

2020-09-28 Thread Michael Niedermayer
On Mon, Sep 28, 2020 at 08:30:50AM +1000, Peter Ross wrote:
> On Sun, Sep 27, 2020 at 10:20:52PM +0200, Michael Niedermayer wrote:
> > Fixes: Infinite loop
> > Fixes: 
> > 25844/clusterfuzz-testcase-minimized-ffmpeg_DEMUXER_fuzzer-5660803318153216
> > 
> > Found-by: continuous fuzzing process 
> > https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
> > Signed-off-by: Michael Niedermayer 
> > ---
> >  libavformat/iff.c | 3 +++
> >  1 file changed, 3 insertions(+)
> > 
> > diff --git a/libavformat/iff.c b/libavformat/iff.c
> > index 7feb121cd0..04fe8be4eb 100644
> > --- a/libavformat/iff.c
> > +++ b/libavformat/iff.c
> > @@ -449,6 +449,9 @@ static int iff_read_header(AVFormatContext *s)
> >  data_size = iff->is_64bit ? avio_rb64(pb) : avio_rb32(pb);
> >  orig_pos = avio_tell(pb);
> >  
> > +if (data_size >= INT64_MAX)
> > +return AVERROR_INVALIDDATA;
> > +
> >  switch(chunk_id) {
> >  case ID_VHDR:
> >  st->codecpar->codec_type = AVMEDIA_TYPE_AUDIO;
> > -- 
> > 2.17.1
> 
> ok

will apply

thx

[...]

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

The day soldiers stop bringing you their problems is the day you have stopped 
leading them. They have either lost confidence that you can help or concluded 
you do not care. Either case is a failure of leadership. - Colin Powell


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 2/3] avformat/movenc: Don't forget to free fragment buffers

2020-09-28 Thread Andreas Rheinhardt
The buffers used when fragmented output is enabled have up until now not
been freed in the deinit function; they leak e.g. if one errors out of
mov_write_trailer() before one reaches the point where they are normally
written out and freed. This can e.g. happen if allocating new vos_data
fails at the beginning of mov_write_trailer().

Signed-off-by: Andreas Rheinhardt 
---
 libavformat/movenc.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/libavformat/movenc.c b/libavformat/movenc.c
index c53be74a64..c12dd1e672 100644
--- a/libavformat/movenc.c
+++ b/libavformat/movenc.c
@@ -6279,9 +6279,11 @@ static void mov_free(AVFormatContext *s)
 av_freep(&mov->tracks[i].vos_data);
 
 ff_mov_cenc_free(&mov->tracks[i].cenc);
+ffio_free_dyn_buf(&mov->tracks[i].mdat_buf);
 }
 
 av_freep(&mov->tracks);
+ffio_free_dyn_buf(&mov->mdat_buf);
 }
 
 static uint32_t rgb_to_yuv(uint32_t rgb)
-- 
2.25.1

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

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

Re: [FFmpeg-devel] [PATCH 2/2] libswcale/input: fix incorrect rgbf32 yuv conversions

2020-09-28 Thread Michael Niedermayer
On Sat, Sep 26, 2020 at 10:01:30PM -0700, Mark Reid wrote:
> On Mon, Sep 14, 2020 at 6:31 PM Mark Reid  wrote:
> 
> >
> >
> > On Mon, Sep 14, 2020 at 2:44 PM Michael Niedermayer 
> > wrote:
> >
> >> On Sun, Sep 13, 2020 at 04:04:42PM -0700, Mark Reid wrote:
> >> > On Sun, Sep 13, 2020 at 8:55 AM Michael Niedermayer
> >> 
> >> > wrote:
> >> >
> >> > > On Sat, Sep 12, 2020 at 02:07:14AM -0700, mindm...@gmail.com wrote:
> >> > > > From: Mark Reid 
> >> > > >
> >> > > > ---
> >> > > >  libswscale/input.c  | 12 +---
> >> > > >  tests/ref/fate/filter-pixfmts-scale |  8 
> >> > > >  2 files changed, 9 insertions(+), 11 deletions(-)
> >> > >
> >> > > Can you provide some tests that show that this is better ?
> >> > > Iam asking that because some of the numbers in some of the code
> >> > > (i dont remember which) where tuned to give more accurate overall
> >> results
> >> > >
> >> > > an example for tests would be converting from A->B->A then compare to
> >> the
> >> > > orig
> >> > >
> >> > > thx
> >> > >
> >> > >
> >> > Hopefully i can explain this clearly!
> >> >
> >> > It's easier to see the error if you run a black image through the old
> >> > conversion.
> >> > zero values don't get mapped to zero. (attached sample image)
> >> >
> >> > ffmpeg -i 4x4_zero.exr -pix_fmt rgb48le -f rawvideo 4x4_zero.rawvideo
> >> > The image should be rgb 0, 0, 0  everywhere but instead it's 353, 0, 407
> >> >
> >> >
> >> > I think this is a error in fixed point rounding, the issue is basically
> >> > boils down to
> >> >
> >> > 128 << 8 != 257 << 7
> >> > and
> >> > 16 << 8  != 33 << 7
> >> >
> >> > https://en.wikipedia.org/wiki/YUV#Studio_swing_for_BT.601
> >> > the 8 bit rgb to yuv formula is
> >> >
> >> > Y = ry*r + gy*g + by*b  + 16
> >> > U = ru*r + gu*g + bu*b + 128
> >> > V = rv*r + gv*g + bv*b + 128
> >> >
> >> > I think the studio swing offsets at the end are calculated wrong in the
> >> old
> >> > code.
> >> > (257 << (RGB2YUV_SHIFT + bpc - 9)))
> >> > 257 is correct for 8 bit rounding but not for 16-bit.
> >> >
> >> > the 257 i believe is from (128 << 1) + 1
> >> > the +1 is for rounding
> >> >
> >> > for rounding 16-bit (128 << 9) + 1 = 0x10001
> >> >
> >> > therefore I think the correct rounding any bit depth with the old
> >> formula
> >> > would be (untested)
> >> > (((128 << (bpc - 7)) + 1) << (RGB2YUV_SHIFT-1) )
> >> >
> >> > I just simplified it to
> >> > (0x10001 << (RGB2YUV_SHIFT - 1))
> >> >
> >> > The rgb48ToUV and rgb48ToY funcs in input.c use the formula I'm using.
> >>
> >> You quite possibly are correct, can you test that this actually works
> >> out. The test sample only covers 1 color (black)
> >> a testsample covering a wide range of the color cube would be more
> >> convincing that this change is needed and sufficient to fix this.
> >>
> >> thx
> >>
> >
> > I wrote a small python script to compare the raw gbrpf32le images if that
> > works? I attached it and also a more colorful test pattern.
> >
> > it runs these two commands and compares the 2 raw float images
> > ffmpeg -y -i test_pattern.exr -f rawvideo original.gbrpf32le
> > ffmpeg -y -i test_pattern.exr -vf
> > format=pix_fmts=rgb48le,format=pix_fmts=gbrpf32le -f rawvideo
> > converted.gbrpf32le
> >
> > python gbrpf32le_diff.py test_pattern.exr
> >
> > without patch:
> > avg error: 237.445495855
> > min error: 0.0
> > max error: 468.399102688
> >
> > with patch:
> > avg error: 15.9312244829
> > min error: 0.0
> > max error: 69.467689991
> >
> >
> > These are floating points scaled to 16-bit values.
> > Even with my patch, I'm kinda disturbed how much error there is.
> >
> 
> ping
> I re-wrote the python script as a c swscale test, if that helps
> replicate my results. attached is patch for that.
> it generates an image of random float values and does the
> conversion/comparison .
> 
> before patch:
> gbrpf32le -> yuva444p16le -> gbrpf32le
> avg diff: 0.003852
> min diff: 0.00
> max diff: 0.006638
> 
> after patch:
> gbrpf32le -> yuva444p16le -> gbrpf32le
> avg diff: 0.000125
> min diff: 0.00
> max diff: 0.000501

is it better for all middle formats ?
Iam asking as it seems this should be rather easy to test with your code

But from what i  see above, obviously this is an improvment and should be 
applied

thx

[...]

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Awnsering whenever a program halts or runs forever is
On a turing machine, in general impossible (turings halting problem).
On any real computer, always possible as a real computer has a finite number
of states N, and will either halt in less than N cycles or never halt.


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 3/3] avformat/movenc: Avoid allocation for timecode track

2020-09-28 Thread Andreas Rheinhardt
Signed-off-by: Andreas Rheinhardt 
---
 libavformat/movenc.c | 12 
 1 file changed, 4 insertions(+), 8 deletions(-)

diff --git a/libavformat/movenc.c b/libavformat/movenc.c
index c12dd1e672..a481272ff1 100644
--- a/libavformat/movenc.c
+++ b/libavformat/movenc.c
@@ -6160,11 +6160,12 @@ static int mov_check_timecode_track(AVFormatContext *s, 
AVTimecode *tc, int src_
 
 static int mov_create_timecode_track(AVFormatContext *s, int index, int 
src_index, AVTimecode tc)
 {
-int ret;
 MOVMuxContext *mov  = s->priv_data;
 MOVTrack *track = &mov->tracks[index];
 AVStream *src_st= s->streams[src_index];
-AVPacket pkt= {.stream_index = index, .flags = AV_PKT_FLAG_KEY, .size 
= 4};
+uint8_t data[4];
+AVPacket pkt= { .data = data, .stream_index = index,
+.flags = AV_PKT_FLAG_KEY, .size = 4 };
 AVRational rate = find_fps(s, src_st);
 
 /* tmcd track based on video stream */
@@ -6187,13 +6188,8 @@ static int mov_create_timecode_track(AVFormatContext *s, 
int index, int src_inde
 track->st->avg_frame_rate = av_inv_q(rate);
 
 /* the tmcd track just contains one packet with the frame number */
-pkt.data = av_malloc(pkt.size);
-if (!pkt.data)
-return AVERROR(ENOMEM);
 AV_WB32(pkt.data, tc.start);
-ret = ff_mov_write_packet(s, &pkt);
-av_free(pkt.data);
-return ret;
+return ff_mov_write_packet(s, &pkt);
 }
 
 /*
-- 
2.25.1

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

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

[FFmpeg-devel] [PATCH 1/3] avformat/movenc: Free old vos_data before overwriting it

2020-09-28 Thread Andreas Rheinhardt
Otherwise the old data leaks whenever extradata needs to be rewritten
(e.g. when encoding FLAC with our encoder that sends an updated
extradata packet at the end).

Signed-off-by: Andreas Rheinhardt 
---
 libavformat/movenc.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/libavformat/movenc.c b/libavformat/movenc.c
index a90bbfa458..c53be74a64 100644
--- a/libavformat/movenc.c
+++ b/libavformat/movenc.c
@@ -6978,6 +6978,7 @@ static int mov_write_trailer(AVFormatContext *s)
 AVCodecParameters *par = track->par;
 
 track->vos_len  = par->extradata_size;
+av_freep(&track->vos_data);
 track->vos_data = av_malloc(track->vos_len + 
AV_INPUT_BUFFER_PADDING_SIZE);
 if (!track->vos_data)
 return AVERROR(ENOMEM);
-- 
2.25.1

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

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

Re: [FFmpeg-devel] [PATCH 2/2] libswcale/input: fix incorrect rgbf32 yuv conversions

2020-09-28 Thread Michael Niedermayer
On Sat, Sep 26, 2020 at 10:01:30PM -0700, Mark Reid wrote:
> On Mon, Sep 14, 2020 at 6:31 PM Mark Reid  wrote:
> 
> >
> >
> > On Mon, Sep 14, 2020 at 2:44 PM Michael Niedermayer 
> > wrote:
> >
> >> On Sun, Sep 13, 2020 at 04:04:42PM -0700, Mark Reid wrote:
> >> > On Sun, Sep 13, 2020 at 8:55 AM Michael Niedermayer
> >> 
> >> > wrote:
> >> >
> >> > > On Sat, Sep 12, 2020 at 02:07:14AM -0700, mindm...@gmail.com wrote:
> >> > > > From: Mark Reid 
> >> > > >
> >> > > > ---
> >> > > >  libswscale/input.c  | 12 +---
> >> > > >  tests/ref/fate/filter-pixfmts-scale |  8 
> >> > > >  2 files changed, 9 insertions(+), 11 deletions(-)
> >> > >
> >> > > Can you provide some tests that show that this is better ?
> >> > > Iam asking that because some of the numbers in some of the code
> >> > > (i dont remember which) where tuned to give more accurate overall
> >> results
> >> > >
> >> > > an example for tests would be converting from A->B->A then compare to
> >> the
> >> > > orig
> >> > >
> >> > > thx
> >> > >
> >> > >
> >> > Hopefully i can explain this clearly!
> >> >
> >> > It's easier to see the error if you run a black image through the old
> >> > conversion.
> >> > zero values don't get mapped to zero. (attached sample image)
> >> >
> >> > ffmpeg -i 4x4_zero.exr -pix_fmt rgb48le -f rawvideo 4x4_zero.rawvideo
> >> > The image should be rgb 0, 0, 0  everywhere but instead it's 353, 0, 407
> >> >
> >> >
> >> > I think this is a error in fixed point rounding, the issue is basically
> >> > boils down to
> >> >
> >> > 128 << 8 != 257 << 7
> >> > and
> >> > 16 << 8  != 33 << 7
> >> >
> >> > https://en.wikipedia.org/wiki/YUV#Studio_swing_for_BT.601
> >> > the 8 bit rgb to yuv formula is
> >> >
> >> > Y = ry*r + gy*g + by*b  + 16
> >> > U = ru*r + gu*g + bu*b + 128
> >> > V = rv*r + gv*g + bv*b + 128
> >> >
> >> > I think the studio swing offsets at the end are calculated wrong in the
> >> old
> >> > code.
> >> > (257 << (RGB2YUV_SHIFT + bpc - 9)))
> >> > 257 is correct for 8 bit rounding but not for 16-bit.
> >> >
> >> > the 257 i believe is from (128 << 1) + 1
> >> > the +1 is for rounding
> >> >
> >> > for rounding 16-bit (128 << 9) + 1 = 0x10001
> >> >
> >> > therefore I think the correct rounding any bit depth with the old
> >> formula
> >> > would be (untested)
> >> > (((128 << (bpc - 7)) + 1) << (RGB2YUV_SHIFT-1) )
> >> >
> >> > I just simplified it to
> >> > (0x10001 << (RGB2YUV_SHIFT - 1))
> >> >
> >> > The rgb48ToUV and rgb48ToY funcs in input.c use the formula I'm using.
> >>
> >> You quite possibly are correct, can you test that this actually works
> >> out. The test sample only covers 1 color (black)
> >> a testsample covering a wide range of the color cube would be more
> >> convincing that this change is needed and sufficient to fix this.
> >>
> >> thx
> >>
> >
> > I wrote a small python script to compare the raw gbrpf32le images if that
> > works? I attached it and also a more colorful test pattern.
> >
> > it runs these two commands and compares the 2 raw float images
> > ffmpeg -y -i test_pattern.exr -f rawvideo original.gbrpf32le
> > ffmpeg -y -i test_pattern.exr -vf
> > format=pix_fmts=rgb48le,format=pix_fmts=gbrpf32le -f rawvideo
> > converted.gbrpf32le
> >
> > python gbrpf32le_diff.py test_pattern.exr
> >
> > without patch:
> > avg error: 237.445495855
> > min error: 0.0
> > max error: 468.399102688
> >
> > with patch:
> > avg error: 15.9312244829
> > min error: 0.0
> > max error: 69.467689991
> >
> >
> > These are floating points scaled to 16-bit values.
> > Even with my patch, I'm kinda disturbed how much error there is.
> >
> 
> ping
> I re-wrote the python script as a c swscale test, if that helps
> replicate my results. attached is patch for that.
> it generates an image of random float values and does the
> conversion/comparison .
> 
> before patch:
> gbrpf32le -> yuva444p16le -> gbrpf32le
> avg diff: 0.003852
> min diff: 0.00
> max diff: 0.006638
> 
> after patch:
> gbrpf32le -> yuva444p16le -> gbrpf32le
> avg diff: 0.000125
> min diff: 0.00
> max diff: 0.000501
> 
> 
> >
> >
> >>
> >> [...]
> >>
> >> --
> >> Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
> >>
> >> There will always be a question for which you do not know the correct
> >> answer.
> >> ___
> >> 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".
> >
> >

>  Makefile |1 
>  tests/.gitignore |1 
>  tests/floatimg_cmp.c |  267 
> +++
>  3 files changed, 269 insertions(+)
> a04783297b0a5d9be6186a150606724457e7b0c5  
> 0001-libswscale-tests-add-floatimg_cmp-test.patch
> From 9c4bc86201037aec454a98b60301d9250fecc7ca Mon Sep 17 00:00:00 2001
> From: Mark Reid 
> Date: Sun, 20 Sep 2020 

[FFmpeg-devel] [PATCH] avformat/movenc: exit calculate_mpeg4_bit_rates early if track lacks required values

2020-09-28 Thread Jan Ekström
Missed due to lack of FATE tests, but chapters are a movenc track
w/o an AVStream. We also expect the codecpar in the track, which we are
utilizing without checks. Thus, cause an early exit if it is missing
as well.

Fixes #8190
---
 libavformat/movenc.c | 6 ++
 1 file changed, 6 insertions(+)

diff --git a/libavformat/movenc.c b/libavformat/movenc.c
index 20768cd45f..a17fa6757c 100644
--- a/libavformat/movenc.c
+++ b/libavformat/movenc.c
@@ -641,6 +641,12 @@ struct mpeg4_bit_rate_values {
 
 static struct mpeg4_bit_rate_values calculate_mpeg4_bit_rates(MOVTrack *track)
 {
+if (!track->st || !track->par)
+// if there is no AVStream or codecpar available for track, early exit
+return (struct mpeg4_bit_rate_values) {
+0
+};
+
 AVCPBProperties *props =
 (AVCPBProperties*)av_stream_get_side_data(track->st,
   AV_PKT_DATA_CPB_PROPERTIES,
-- 
2.26.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] avformat/movenc: Fix segfault upon allocation error

2020-09-28 Thread Jan Ekström
On Mon, Sep 28, 2020 at 6:14 PM Andreas Rheinhardt
 wrote:
>
> Signed-off-by: Andreas Rheinhardt 
> ---
>  libavformat/movenc.c | 3 +++
>  1 file changed, 3 insertions(+)
>
> diff --git a/libavformat/movenc.c b/libavformat/movenc.c
> index 63adae5e0a..a90bbfa458 100644
> --- a/libavformat/movenc.c
> +++ b/libavformat/movenc.c
> @@ -6254,6 +6254,9 @@ static void mov_free(AVFormatContext *s)
>  MOVMuxContext *mov = s->priv_data;
>  int i;
>
> +if (!mov->tracks)
> +return;
> +
>  if (mov->chapter_track) {
>  avcodec_parameters_free(&mov->tracks[mov->chapter_track].par);
>  }
> --
> 2.25.1

LGTM.

Jan
___
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/movenc: Fix segfault upon allocation error

2020-09-28 Thread Andreas Rheinhardt
Signed-off-by: Andreas Rheinhardt 
---
 libavformat/movenc.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/libavformat/movenc.c b/libavformat/movenc.c
index 63adae5e0a..a90bbfa458 100644
--- a/libavformat/movenc.c
+++ b/libavformat/movenc.c
@@ -6254,6 +6254,9 @@ static void mov_free(AVFormatContext *s)
 MOVMuxContext *mov = s->priv_data;
 int i;
 
+if (!mov->tracks)
+return;
+
 if (mov->chapter_track) {
 avcodec_parameters_free(&mov->tracks[mov->chapter_track].par);
 }
-- 
2.25.1

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

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

Re: [FFmpeg-devel] [PATCH 18/25] avcodec/utils: Only call codec->close if init has been called

2020-09-28 Thread Michael Niedermayer
On Sat, Sep 26, 2020 at 12:27:57PM +0200, Andreas Rheinhardt wrote:
> avcodec_open2() also called the AVCodec's close function if an error
> happened before init had ever been called if the AVCodec has the
> FF_CODEC_CAP_INIT_CLEANUP flag set. This is against the documentation of
> said flag: "The codec allows calling the close function for deallocation
> even if the init function returned a failure."
> 
> E.g. the SVQ3 decoder is not ready to be closed if init has never been
> called.
> 
> Fixes: NULL dereference

> Fixes: 
> 25762/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_SVQ3_fuzzer-5716279070294016

confirmed

thx

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

While the State exists there can be no freedom; when there is freedom there
will be no State. -- Vladimir Lenin


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] avcodec/h264_slice: use av_buffer_replace() to simplify code

2020-09-28 Thread James Almer
Based on eff289ce9f030f023e218ee7ce354d4f0e035b6d.

Signed-off-by: James Almer 
---
 libavcodec/h264_slice.c | 34 --
 1 file changed, 12 insertions(+), 22 deletions(-)

diff --git a/libavcodec/h264_slice.c b/libavcodec/h264_slice.c
index db7302a8b5..74575bccd4 100644
--- a/libavcodec/h264_slice.c
+++ b/libavcodec/h264_slice.c
@@ -325,29 +325,22 @@ int ff_h264_update_thread_context(AVCodecContext *dst,
 
 // SPS/PPS
 for (i = 0; i < FF_ARRAY_ELEMS(h->ps.sps_list); i++) {
-av_buffer_unref(&h->ps.sps_list[i]);
-if (h1->ps.sps_list[i]) {
-h->ps.sps_list[i] = av_buffer_ref(h1->ps.sps_list[i]);
-if (!h->ps.sps_list[i])
-return AVERROR(ENOMEM);
-}
+ret = av_buffer_replace(&h->ps.sps_list[i], h1->ps.sps_list[i]);
+if (ret < 0)
+return ret;
 }
 for (i = 0; i < FF_ARRAY_ELEMS(h->ps.pps_list); i++) {
-av_buffer_unref(&h->ps.pps_list[i]);
-if (h1->ps.pps_list[i]) {
-h->ps.pps_list[i] = av_buffer_ref(h1->ps.pps_list[i]);
-if (!h->ps.pps_list[i])
-return AVERROR(ENOMEM);
-}
+ret = av_buffer_replace(&h->ps.pps_list[i], h1->ps.pps_list[i]);
+if (ret < 0)
+return ret;
 }
 
-av_buffer_unref(&h->ps.pps_ref);
+ret = av_buffer_replace(&h->ps.pps_ref, h1->ps.pps_ref);
+if (ret < 0)
+return ret;
 h->ps.pps = NULL;
 h->ps.sps = NULL;
 if (h1->ps.pps_ref) {
-h->ps.pps_ref = av_buffer_ref(h1->ps.pps_ref);
-if (!h->ps.pps_ref)
-return AVERROR(ENOMEM);
 h->ps.pps = (const PPS*)h->ps.pps_ref->data;
 h->ps.sps = h->ps.pps->sps;
 }
@@ -432,12 +425,9 @@ int ff_h264_update_thread_context(AVCodecContext *dst,
 
 h->frame_recovered   = h1->frame_recovered;
 
-av_buffer_unref(&h->sei.a53_caption.buf_ref);
-if (h1->sei.a53_caption.buf_ref) {
-h->sei.a53_caption.buf_ref = 
av_buffer_ref(h1->sei.a53_caption.buf_ref);
-if (!h->sei.a53_caption.buf_ref)
-return AVERROR(ENOMEM);
-}
+ret = av_buffer_replace(&h->sei.a53_caption.buf_ref, 
h1->sei.a53_caption.buf_ref);
+if (ret < 0)
+return ret;
 
 for (i = 0; i < h->sei.unregistered.nb_buf_ref; i++)
 av_buffer_unref(&h->sei.unregistered.buf_ref[i]);
-- 
2.27.0

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

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

Re: [FFmpeg-devel] [PATCH v2] avcodec/dpx: Read alternative frame rate from television header

2020-09-28 Thread Harry Mallon


> On 14 Aug 2020, at 11:03, Harry Mallon  wrote:
> 
> Signed-off-by: Harry Mallon 
> ---
> libavcodec/dpx.c | 15 ++-
> 1 file changed, 14 insertions(+), 1 deletion(-)
> 
> diff --git a/libavcodec/dpx.c b/libavcodec/dpx.c
> index b1833ed9ef..7e3ac0af2e 100644
> --- a/libavcodec/dpx.c
> +++ b/libavcodec/dpx.c
> @@ -216,10 +216,23 @@ static int decode_frame(AVCodecContext *avctx,
> else
> avctx->sample_aspect_ratio = (AVRational){ 0, 1 };
> 
> +/* preferred frame rate from Motion-picture film header */
> if (offset >= 1724 + 4) {
> buf = avpkt->data + 1724;
> i = read32(&buf, endian);
> -if(i) {
> +if(i && i != 0x) {
> +AVRational q = av_d2q(av_int2float(i), 4096);
> +if (q.num > 0 && q.den > 0)
> +avctx->framerate = q;
> +}
> +}
> +
> +/* alternative frame rate from television header */
> +if (offset >= 1940 + 4 &&
> +!(avctx->framerate.num && avctx->framerate.den)) {
> +buf = avpkt->data + 1940;
> +i = read32(&buf, endian);
> +if(i && i != 0x) {
> AVRational q = av_d2q(av_int2float(i), 4096);
> if (q.num > 0 && q.den > 0)
> avctx->framerate = q;
> -- 
> 2.28.0
> 

Bump, does anyone have anything on this?

Best,
Harry

___
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/8] avcodec/cbs: add a flush callback to CodedBitstreamType

2020-09-28 Thread James Almer
On 9/25/2020 11:43 AM, James Almer wrote:
> Used to reset the codec's private internal state.
> 
> Signed-off-by: James Almer 
> ---
>  libavcodec/cbs.c  | 6 ++
>  libavcodec/cbs.h  | 5 +
>  libavcodec/cbs_internal.h | 3 +++
>  3 files changed, 14 insertions(+)

Will apply this set soon.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

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

Re: [FFmpeg-devel] [PATCH 2/3] avcodec/exr: Fix overflow with many blocks

2020-09-28 Thread Michael Niedermayer
On Sun, Sep 27, 2020 at 10:21:25AM +0200, Andreas Rheinhardt wrote:
> Michael Niedermayer:
> > Fixes: signed integer overflow: 1073741827 * 8 cannot be represented in 
> > type 'int'
> > Fixes: 
> > 25621/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_EXR_fuzzer-6304841641754624
> > 
> > Found-by: continuous fuzzing process 
> > https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
> > Signed-off-by: Michael Niedermayer 
> > ---
> >  libavcodec/exr.c | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> > 
> > diff --git a/libavcodec/exr.c b/libavcodec/exr.c
> > index c80e8eb5e0..8621a8cfe4 100644
> > --- a/libavcodec/exr.c
> > +++ b/libavcodec/exr.c
> > @@ -1783,7 +1783,7 @@ static int decode_frame(AVCodecContext *avctx, void 
> > *data,
> >  if ((ret = ff_thread_get_buffer(avctx, &frame, 0)) < 0)
> >  return ret;
> >  
> > -if (bytestream2_get_bytes_left(&s->gb) < nb_blocks * 8)
> > +if (bytestream2_get_bytes_left(&s->gb) < nb_blocks * 8L)
> 
> Does this have an advantage over dividing by 8?

probably not anything thats relevant in this case

thx

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

When the tyrant has disposed of foreign enemies by conquest or treaty, and
there is nothing more to fear from them, then he is always stirring up
some war or other, in order that the people may require a leader. -- Plato


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] avformat/movenc: Don't free AVCodecParameters manually

2020-09-28 Thread Andreas Rheinhardt
Signed-off-by: Andreas Rheinhardt 
---
 libavformat/movenc.c | 4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

diff --git a/libavformat/movenc.c b/libavformat/movenc.c
index 20768cd45f..891c833520 100644
--- a/libavformat/movenc.c
+++ b/libavformat/movenc.c
@@ -6255,9 +6255,7 @@ static void mov_free(AVFormatContext *s)
 int i;
 
 if (mov->chapter_track) {
-if (mov->tracks[mov->chapter_track].par)
-av_freep(&mov->tracks[mov->chapter_track].par->extradata);
-av_freep(&mov->tracks[mov->chapter_track].par);
+avcodec_paramters_free(&mov_tracks[mov->chapter_track].par);
 }
 
 for (i = 0; i < mov->nb_streams; i++) {
-- 
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 v2] avformat/movenc: Don't free AVCodecParameters manually

2020-09-28 Thread Andreas Rheinhardt
Signed-off-by: Andreas Rheinhardt 
---
Sorry, I missed that my tree is dirty before sending the last patch.

 libavformat/movenc.c | 4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

diff --git a/libavformat/movenc.c b/libavformat/movenc.c
index 20768cd45f..63adae5e0a 100644
--- a/libavformat/movenc.c
+++ b/libavformat/movenc.c
@@ -6255,9 +6255,7 @@ static void mov_free(AVFormatContext *s)
 int i;
 
 if (mov->chapter_track) {
-if (mov->tracks[mov->chapter_track].par)
-av_freep(&mov->tracks[mov->chapter_track].par->extradata);
-av_freep(&mov->tracks[mov->chapter_track].par);
+avcodec_parameters_free(&mov->tracks[mov->chapter_track].par);
 }
 
 for (i = 0; i < mov->nb_streams; i++) {
-- 
2.25.1

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

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

Re: [FFmpeg-devel] [PATCH] lavc/qsvenc: let the SDK to choose the encoding mode by default

2020-09-28 Thread Max Dmitrichenko
it would be good to describe the change a bit more clearly,
something like: Allows MediaSDK *runtime *to choose LowPower/non-LowPower
modes, if not explicitly set.

regards
Max

On Mon, Sep 28, 2020 at 9:32 AM Haihao Xiang  wrote:

> The SDK may support LowPower and non-LowPower modes, some features are
> available only under one of the two modes. It is hard for user to know
> whether a feature is supported under the given mode, so let the SDK to
> choose a mode for encoding by default.
> ---
>  libavcodec/qsvenc.c | 6 --
>  libavcodec/qsvenc.h | 2 +-
>  2 files changed, 5 insertions(+), 3 deletions(-)
>
> diff --git a/libavcodec/qsvenc.c b/libavcodec/qsvenc.c
> index 1ed8f5d973..cff96e59c9 100644
> --- a/libavcodec/qsvenc.c
> +++ b/libavcodec/qsvenc.c
> @@ -510,7 +510,7 @@ static int init_video_param(AVCodecContext *avctx,
> QSVEncContext *q)
>  }
>  }
>
> -if (q->low_power) {
> +if (q->low_power == 1) {
>  #if QSV_HAVE_VDENC
>  q->param.mfx.LowPower = MFX_CODINGOPTION_ON;
>  #else
> @@ -519,7 +519,9 @@ static int init_video_param(AVCodecContext *avctx,
> QSVEncContext *q)
>  q->low_power = 0;
>  q->param.mfx.LowPower = MFX_CODINGOPTION_OFF;
>  #endif
> -} else
> +} else if (q->low_power == -1)
> +q->param.mfx.LowPower = MFX_CODINGOPTION_UNKNOWN;
> +else
>  q->param.mfx.LowPower = MFX_CODINGOPTION_OFF;
>
>  q->param.mfx.CodecProfile   = q->profile;
> diff --git a/libavcodec/qsvenc.h b/libavcodec/qsvenc.h
> index 4f579d1db1..55cc1a 100644
> --- a/libavcodec/qsvenc.h
> +++ b/libavcodec/qsvenc.h
> @@ -96,7 +96,7 @@
>  { "adaptive_b", "Adaptive B-frame placement",
>  OFFSET(qsv.adaptive_b), AV_OPT_TYPE_INT, { .i64 = -1 }, -1,
> 1, VE }, \
>  { "b_strategy", "Strategy to choose between I/P/B-frames",
> OFFSET(qsv.b_strategy),AV_OPT_TYPE_INT, { .i64 = -1 }, -1,  1,
> VE }, \
>  { "forced_idr", "Forcing I frames as IDR frames",
>  OFFSET(qsv.forced_idr), AV_OPT_TYPE_BOOL,{ .i64 = 0  },  0,
> 1, VE }, \
> -{ "low_power", "enable low power mode(experimental: many limitations by
> mfx version, BRC modes, etc.)", OFFSET(qsv.low_power), AV_OPT_TYPE_BOOL, {
> .i64 = 0}, 0, 1, VE},\
> +{ "low_power", "enable low power mode(experimental: many limitations by
> mfx version, BRC modes, etc.)", OFFSET(qsv.low_power), AV_OPT_TYPE_BOOL, {
> .i64 = -1}, -1, 1, VE},\
>
>  extern const AVCodecHWConfigInternal *ff_qsv_enc_hw_configs[];
>
> --
> 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 mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

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

[FFmpeg-devel] [PATCH] lavc/qsvenc: add support for Screen Content Coding (SCC) extension

2020-09-28 Thread Haihao Xiang
This patch adds support for SCC encoding on ICL+ platform

Sample pipeline:
ffmpeg -init_hw_device qsv=qsv:hw -f lavfi -i testsrc -vf \
"format=nv12,hwupload=extra_hw_frames=64,format=qsv" -c:v hevc_qsv \
-profile:v scc -low_power 1 out.h265
---
 libavcodec/qsvenc.c  | 3 +++
 libavcodec/qsvenc_hevc.c | 3 +++
 2 files changed, 6 insertions(+)

diff --git a/libavcodec/qsvenc.c b/libavcodec/qsvenc.c
index 1ed8f5d973..29750735e0 100644
--- a/libavcodec/qsvenc.c
+++ b/libavcodec/qsvenc.c
@@ -69,6 +69,9 @@ static const struct {
 { MFX_PROFILE_HEVC_MAINSP,  "mainsp"},
 { MFX_PROFILE_HEVC_REXT,"rext"  },
 #endif
+#if QSV_VERSION_ATLEAST(1, 32)
+{ MFX_PROFILE_HEVC_SCC, "scc"   },
+#endif
 };
 
 static const char *print_profile(mfxU16 profile)
diff --git a/libavcodec/qsvenc_hevc.c b/libavcodec/qsvenc_hevc.c
index 347f30655e..663f21439f 100644
--- a/libavcodec/qsvenc_hevc.c
+++ b/libavcodec/qsvenc_hevc.c
@@ -241,6 +241,9 @@ static const AVOption options[] = {
 { "main10",  NULL, 0, AV_OPT_TYPE_CONST, { .i64 = MFX_PROFILE_HEVC_MAIN10  
}, INT_MIN, INT_MAX, VE, "profile" },
 { "mainsp",  NULL, 0, AV_OPT_TYPE_CONST, { .i64 = MFX_PROFILE_HEVC_MAINSP  
}, INT_MIN, INT_MAX, VE, "profile" },
 { "rext",NULL, 0, AV_OPT_TYPE_CONST, { .i64 = MFX_PROFILE_HEVC_REXT
}, INT_MIN, INT_MAX, VE, "profile" },
+#if QSV_VERSION_ATLEAST(1, 32)
+{ "scc", NULL, 0, AV_OPT_TYPE_CONST, { .i64 = MFX_PROFILE_HEVC_SCC 
}, INT_MIN, INT_MAX, VE, "profile" },
+#endif
 
 { "gpb", "1: GPB (generalized P/B frame); 0: regular P frame", 
OFFSET(qsv.gpb), AV_OPT_TYPE_BOOL, { .i64 = 1 }, 0, 1, VE},
 
-- 
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] lavc/qsvenc: let the SDK to choose the encoding mode by default

2020-09-28 Thread Haihao Xiang
The SDK may support LowPower and non-LowPower modes, some features are
available only under one of the two modes. It is hard for user to know
whether a feature is supported under the given mode, so let the SDK to
choose a mode for encoding by default.
---
 libavcodec/qsvenc.c | 6 --
 libavcodec/qsvenc.h | 2 +-
 2 files changed, 5 insertions(+), 3 deletions(-)

diff --git a/libavcodec/qsvenc.c b/libavcodec/qsvenc.c
index 1ed8f5d973..cff96e59c9 100644
--- a/libavcodec/qsvenc.c
+++ b/libavcodec/qsvenc.c
@@ -510,7 +510,7 @@ static int init_video_param(AVCodecContext *avctx, 
QSVEncContext *q)
 }
 }
 
-if (q->low_power) {
+if (q->low_power == 1) {
 #if QSV_HAVE_VDENC
 q->param.mfx.LowPower = MFX_CODINGOPTION_ON;
 #else
@@ -519,7 +519,9 @@ static int init_video_param(AVCodecContext *avctx, 
QSVEncContext *q)
 q->low_power = 0;
 q->param.mfx.LowPower = MFX_CODINGOPTION_OFF;
 #endif
-} else
+} else if (q->low_power == -1)
+q->param.mfx.LowPower = MFX_CODINGOPTION_UNKNOWN;
+else
 q->param.mfx.LowPower = MFX_CODINGOPTION_OFF;
 
 q->param.mfx.CodecProfile   = q->profile;
diff --git a/libavcodec/qsvenc.h b/libavcodec/qsvenc.h
index 4f579d1db1..55cc1a 100644
--- a/libavcodec/qsvenc.h
+++ b/libavcodec/qsvenc.h
@@ -96,7 +96,7 @@
 { "adaptive_b", "Adaptive B-frame placement", 
OFFSET(qsv.adaptive_b), AV_OPT_TYPE_INT, { .i64 = -1 }, -1,  1, VE 
}, \
 { "b_strategy", "Strategy to choose between I/P/B-frames", 
OFFSET(qsv.b_strategy),AV_OPT_TYPE_INT, { .i64 = -1 }, -1,  1, VE 
}, \
 { "forced_idr", "Forcing I frames as IDR frames", 
OFFSET(qsv.forced_idr), AV_OPT_TYPE_BOOL,{ .i64 = 0  },  0,  1, VE 
}, \
-{ "low_power", "enable low power mode(experimental: many limitations by mfx 
version, BRC modes, etc.)", OFFSET(qsv.low_power), AV_OPT_TYPE_BOOL, { .i64 = 
0}, 0, 1, VE},\
+{ "low_power", "enable low power mode(experimental: many limitations by mfx 
version, BRC modes, etc.)", OFFSET(qsv.low_power), AV_OPT_TYPE_BOOL, { .i64 = 
-1}, -1, 1, VE},\
 
 extern const AVCodecHWConfigInternal *ff_qsv_enc_hw_configs[];
 
-- 
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".