Re: [FFmpeg-devel] [PATCH] lavc/qsvenc_hevc: add -pic_timing_sei option
On Fri, Dec 24, 2021 at 07:35:25AM +, Xiang, Haihao wrote:
> On Fri, 2021-08-06 at 10:10 +0800, Haihao Xiang wrote:
> > The SDK may insert picture timing SEI for hevc and the code to set mfx
> > parameter has been added in qsvenc, however the corresponding option is
> > missing in the hevc option array
> > ---
> > libavcodec/qsvenc_hevc.c | 1 +
> > 1 file changed, 1 insertion(+)
> >
> > diff --git a/libavcodec/qsvenc_hevc.c b/libavcodec/qsvenc_hevc.c
> > index b7b2f5633e..1e31968673 100644
> > --- a/libavcodec/qsvenc_hevc.c
> > +++ b/libavcodec/qsvenc_hevc.c
> > @@ -248,6 +248,7 @@ static const AVOption options[] = {
> > { "tile_rows", "Number of rows for tiled
> > encoding", OFFSET(qsv.tile_rows),AV_OPT_TYPE_INT, { .i64 = 0 }, 0,
> > UINT16_MAX, VE },
> > { "recovery_point_sei", "Insert recovery point SEI
> > messages", OFFSET(qsv.recovery_point_sei), AV_OPT_TYPE_INT, {
> > .i64
> > = -1 }, -1, 1, VE },
> > { "aud", "Insert the Access Unit Delimiter NAL", OFFSET(qsv.aud),
> > AV_OPT_TYPE_INT, { .i64 = 0 }, 0, 1, VE},
> > +{ "pic_timing_sei","Insert picture timing SEI with
> > pic_struct_syntax
> > element", OFFSET(qsv.pic_timing_sei), AV_OPT_TYPE_INT, { .i64 = 1 }, 0, 1,
> > VE
It's better to use AV_OPT_TYPE_BOOL if the option is used for on/off or
enable/disable.
I think you need to add description in the doc for the new options if possible.
> > },
> >
> > { NULL },
> > };
>
> Will apply
>
> -Haihao
>
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
> To unsubscribe, visit link above, or email
> ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
--
Thanks,
Limin Wang
___
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/vaapi_encode_vp9: fix > 4k encode fail issue
On Fri, Dec 24, 2021 at 07:32:28AM +, Xiang, Haihao wrote:
> On Mon, 2021-04-12 at 09:47 +0800, Zhang yuankun wrote:
> > This patch will fix following command:
> > ffmpeg -hwaccel vaapi -hwaccel_output_format vaapi -i input.264 \
> > -vf 'scale_vaapi=w=7680:h=4096' -c:v vp9_vaapi output.ivf
> >
> > Max width of a vp9 tile is 4096. If the source frame > 4096, we need split
> > to
> > multiple tiles.
> >
> > Signed-off-by: Zhang yuankun
> > ---
> > libavcodec/vaapi_encode_vp9.c | 8
> > 1 file changed, 8 insertions(+)
> >
> > diff --git a/libavcodec/vaapi_encode_vp9.c b/libavcodec/vaapi_encode_vp9.c
> > index 0e1c52c92a..ed45cd6d03 100644
> > --- a/libavcodec/vaapi_encode_vp9.c
> > +++ b/libavcodec/vaapi_encode_vp9.c
> > @@ -31,6 +31,7 @@
> >
> > #define VP9_MAX_QUANT 255
> >
> > +#define VP9_MAX_TILE_WIDTH 4096
> >
> > typedef struct VAAPIEncodeVP9Picture {
> > int slot;
> > @@ -82,10 +83,17 @@ static int
> > vaapi_encode_vp9_init_picture_params(AVCodecContext *avctx,
> > VAAPIEncodeVP9Picture *hpic = pic->priv_data;
> > VAEncPictureParameterBufferVP9 *vpic = pic->codec_picture_params;
> > int i;
> > +int num_tile_columns;
> >
> > vpic->reconstructed_frame = pic->recon_surface;
> > vpic->coded_buf = pic->output_buffer;
> >
> > +// Maximum width of a tile in units of superblocks is
> > MAX_TILE_WIDTH_B64(64)
> > +// So the number of tile columns is related to the width of the
> > picture.
> > +// We set the minimum possible number for num_tile_columns as defualt
defualt -> default
> > value.
> > +num_tile_columns = (vpic->frame_width_src + VP9_MAX_TILE_WIDTH - 1) /
> > VP9_MAX_TILE_WIDTH;
> > +vpic->log2_tile_columns = num_tile_columns == 1 ? 0 :
> > av_log2(num_tile_columns - 1) + 1;
> > +
> > switch (pic->type) {
> > case PICTURE_TYPE_IDR:
> > av_assert0(pic->nb_refs == 0);
>
> LGTM, will apply
>
> -Haihao
>
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
> To unsubscribe, visit link above, or email
> ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
--
Thanks,
Limin Wang
___
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/vaapi_encode_vp9: fix > 4k encode fail issue
On Fri, 2021-12-24 at 16:19 +0800, lance.lmw...@gmail.com wrote:
> On Fri, Dec 24, 2021 at 07:32:28AM +, Xiang, Haihao wrote:
> > On Mon, 2021-04-12 at 09:47 +0800, Zhang yuankun wrote:
> > > This patch will fix following command:
> > > ffmpeg -hwaccel vaapi -hwaccel_output_format vaapi -i input.264 \
> > > -vf 'scale_vaapi=w=7680:h=4096' -c:v vp9_vaapi output.ivf
> > >
> > > Max width of a vp9 tile is 4096. If the source frame > 4096, we need split
> > > to
> > > multiple tiles.
> > >
> > > Signed-off-by: Zhang yuankun
> > > ---
> > > libavcodec/vaapi_encode_vp9.c | 8
> > > 1 file changed, 8 insertions(+)
> > >
> > > diff --git a/libavcodec/vaapi_encode_vp9.c b/libavcodec/vaapi_encode_vp9.c
> > > index 0e1c52c92a..ed45cd6d03 100644
> > > --- a/libavcodec/vaapi_encode_vp9.c
> > > +++ b/libavcodec/vaapi_encode_vp9.c
> > > @@ -31,6 +31,7 @@
> > >
> > > #define VP9_MAX_QUANT 255
> > >
> > > +#define VP9_MAX_TILE_WIDTH 4096
> > >
> > > typedef struct VAAPIEncodeVP9Picture {
> > > int slot;
> > > @@ -82,10 +83,17 @@ static int
> > > vaapi_encode_vp9_init_picture_params(AVCodecContext *avctx,
> > > VAAPIEncodeVP9Picture *hpic = pic->priv_data;
> > > VAEncPictureParameterBufferVP9 *vpic = pic->codec_picture_params;
> > > int i;
> > > +int num_tile_columns;
> > >
> > > vpic->reconstructed_frame = pic->recon_surface;
> > > vpic->coded_buf = pic->output_buffer;
> > >
> > > +// Maximum width of a tile in units of superblocks is
> > > MAX_TILE_WIDTH_B64(64)
> > > +// So the number of tile columns is related to the width of the
> > > picture.
> > > +// We set the minimum possible number for num_tile_columns as defualt
>
> defualt -> default
Thanks, will fix this typo when pushing the patch.
>
> > > value.
> > > +num_tile_columns = (vpic->frame_width_src + VP9_MAX_TILE_WIDTH - 1) /
> > > VP9_MAX_TILE_WIDTH;
> > > +vpic->log2_tile_columns = num_tile_columns == 1 ? 0 :
> > > av_log2(num_tile_columns - 1) + 1;
> > > +
> > > switch (pic->type) {
> > > case PICTURE_TYPE_IDR:
> > > av_assert0(pic->nb_refs == 0);
> >
> > LGTM, will apply
> >
> > -Haihao
> >
> > ___
> > ffmpeg-devel mailing list
> > ffmpeg-devel@ffmpeg.org
> > https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> >
> > To unsubscribe, visit link above, or email
> > ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
>
>
___
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_hevc: add -pic_timing_sei option
On Fri, 2021-12-24 at 16:17 +0800, lance.lmw...@gmail.com wrote:
> On Fri, Dec 24, 2021 at 07:35:25AM +, Xiang, Haihao wrote:
> > On Fri, 2021-08-06 at 10:10 +0800, Haihao Xiang wrote:
> > > The SDK may insert picture timing SEI for hevc and the code to set mfx
> > > parameter has been added in qsvenc, however the corresponding option is
> > > missing in the hevc option array
> > > ---
> > > libavcodec/qsvenc_hevc.c | 1 +
> > > 1 file changed, 1 insertion(+)
> > >
> > > diff --git a/libavcodec/qsvenc_hevc.c b/libavcodec/qsvenc_hevc.c
> > > index b7b2f5633e..1e31968673 100644
> > > --- a/libavcodec/qsvenc_hevc.c
> > > +++ b/libavcodec/qsvenc_hevc.c
> > > @@ -248,6 +248,7 @@ static const AVOption options[] = {
> > > { "tile_rows", "Number of rows for tiled
> > > encoding", OFFSET(qsv.tile_rows),AV_OPT_TYPE_INT, { .i64 = 0 },
> > > 0,
> > > UINT16_MAX, VE },
> > > { "recovery_point_sei", "Insert recovery point SEI
> > > messages", OFFSET(qsv.recovery_point_sei), AV_OPT_TYPE_INT, {
> > > .i64
> > > = -1 }, -1, 1, VE },
> > > { "aud", "Insert the Access Unit Delimiter NAL", OFFSET(qsv.aud),
> > > AV_OPT_TYPE_INT, { .i64 = 0 }, 0, 1, VE},
> > > +{ "pic_timing_sei","Insert picture timing SEI with
> > > pic_struct_syntax
> > > element", OFFSET(qsv.pic_timing_sei), AV_OPT_TYPE_INT, { .i64 = 1 }, 0, 1,
> > > VE
>
> It's better to use AV_OPT_TYPE_BOOL if the option is used for on/off or
> enable/disable.
>
Thanks for your comment. I'll change it to AV_OPT_TYPE_BOOL,
> I think you need to add description in the doc for the new options if
> possible.
Currently there isn't a doc for qsv decoder, we'll try to add it later.
Thanks
Haihao
>
> > > },
> > >
> > > { NULL },
> > > };
> >
> > Will apply
> >
> > -Haihao
> >
> > ___
> > ffmpeg-devel mailing list
> > ffmpeg-devel@ffmpeg.org
> > https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> >
> > To unsubscribe, visit link above, or email
> > ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
>
>
___
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 v7 01/12] avdevice/dshow: prevent NULL access
On 2021-12-23 10:54 am, Gyan Doshi wrote:
On 2021-12-23 10:39 am, Roger Pack wrote:
These LGTM, could someone apply them for me?
Thanks!
Tomorrow, if no else does, or objects.
Pushed as
7b21841ce45ef4ab486c3c94a714345b878a70fd...a1c4929f65cc75b7175622a007b1e4bd37043d41
Had to correct a few trailing whitespace errors.
Regards,
Gyan
On Tue, Dec 21, 2021 at 6:54 AM Diederick Niehorster
wrote:
list_options true would crash when both a video and an audio device
were
specified as input. Crash would occur on line 784 because
ctx->device_unique_name[otherDevType] would be NULL
Signed-off-by: Diederick Niehorster
---
libavdevice/dshow.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/libavdevice/dshow.c b/libavdevice/dshow.c
index ef78781865..cc0bef0474 100644
--- a/libavdevice/dshow.c
+++ b/libavdevice/dshow.c
@@ -708,9 +708,9 @@ dshow_list_device_options(AVFormatContext
*avctx, ICreateDevEnum *devenum,
if ((r = dshow_cycle_devices(avctx, devenum, devtype,
sourcetype, &device_filter, &device_unique_name)) < 0)
return r;
ctx->device_filter[devtype] = device_filter;
+ ctx->device_unique_name[devtype] = device_unique_name;
if ((r = dshow_cycle_pins(avctx, devtype, sourcetype,
device_filter, NULL)) < 0)
return r;
- av_freep(&device_unique_name);
return 0;
}
@@ -1143,6 +1143,7 @@ static int dshow_read_header(AVFormatContext
*avctx)
}
}
}
+ // don't exit yet, allow it to list crossbar options in
dshow_open_device
}
if (ctx->device_name[VideoDevice]) {
if ((r = dshow_open_device(avctx, devenum, VideoDevice,
VideoSourceDevice)) < 0 ||
--
2.28.0.windows.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".
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] avfilter: add anlmf filter
will apply 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] Pixel format support fixes in swscale and drawutils
On Fri, Dec 24, 2021 at 4:09 AM rcombs wrote: > > This patchset is also available as a GitHub pull request for review > simplicity: > https://github.com/FFmpeg/FFmpeg/pull/380 > > - Reduce hardcoding of pixfmt lists, preferring deriving properties from > pixdesc > - Fix big-endian support for P[N]10/P[N]16 in swscale > - Fix several drawutils issues and add new pixfmt support > - Add more defensive checks in drawutils Does this patch address https://trac.ffmpeg.org/ticket/8454, and this patch https://patchwork.ffmpeg.org/project/ffmpeg/patch/20210601040239.2690-1-val.zapod...@gmail.com/? Would be good to pick those up too if you could (not a blocker of course!) ___ 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] Optimize Mpeg4 decoding for loongarch.
./ffmpeg -i 8_mpeg4_1080p_24fps_12Mbps.avi -f rawvideo -y /dev/null -an before:376fps after :552fps avcodec: [loongarch] Optimize hpeldsp with LASX. avcodec: [loongarch] Optimize idctdstp with LASX. avcodec: [loongarch] Optimize prefetch with loongarch. ___ 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] avcodec: [loongarch] Optimize idctdstp with LASX.
./ffmpeg -i 8_mpeg4_1080p_24fps_12Mbps.avi -f rawvideo -y /dev/null -an
before:433fps
after :552fps
Change-Id: Ic233aeeb3a3b7414db294a7cb699ddbf4ca2e790
---
libavcodec/idctdsp.c | 2 +
libavcodec/idctdsp.h | 2 +
libavcodec/loongarch/Makefile | 3 +
libavcodec/loongarch/idctdsp_init_loongarch.c | 45 +++
libavcodec/loongarch/idctdsp_lasx.c | 124
libavcodec/loongarch/idctdsp_loongarch.h | 41 +++
libavcodec/loongarch/simple_idct_lasx.c | 297 ++
7 files changed, 514 insertions(+)
create mode 100644 libavcodec/loongarch/idctdsp_init_loongarch.c
create mode 100644 libavcodec/loongarch/idctdsp_lasx.c
create mode 100644 libavcodec/loongarch/idctdsp_loongarch.h
create mode 100644 libavcodec/loongarch/simple_idct_lasx.c
diff --git a/libavcodec/idctdsp.c b/libavcodec/idctdsp.c
index 846ed0b0f8..71bd03c606 100644
--- a/libavcodec/idctdsp.c
+++ b/libavcodec/idctdsp.c
@@ -315,6 +315,8 @@ av_cold void ff_idctdsp_init(IDCTDSPContext *c,
AVCodecContext *avctx)
ff_idctdsp_init_x86(c, avctx, high_bit_depth);
if (ARCH_MIPS)
ff_idctdsp_init_mips(c, avctx, high_bit_depth);
+if (ARCH_LOONGARCH)
+ff_idctdsp_init_loongarch(c, avctx, high_bit_depth);
ff_init_scantable_permutation(c->idct_permutation,
c->perm_type);
diff --git a/libavcodec/idctdsp.h b/libavcodec/idctdsp.h
index ca21a31a02..014488aec3 100644
--- a/libavcodec/idctdsp.h
+++ b/libavcodec/idctdsp.h
@@ -118,5 +118,7 @@ void ff_idctdsp_init_x86(IDCTDSPContext *c, AVCodecContext
*avctx,
unsigned high_bit_depth);
void ff_idctdsp_init_mips(IDCTDSPContext *c, AVCodecContext *avctx,
unsigned high_bit_depth);
+void ff_idctdsp_init_loongarch(IDCTDSPContext *c, AVCodecContext *avctx,
+ unsigned high_bit_depth);
#endif /* AVCODEC_IDCTDSP_H */
diff --git a/libavcodec/loongarch/Makefile b/libavcodec/loongarch/Makefile
index 07a401d883..c4d71e801b 100644
--- a/libavcodec/loongarch/Makefile
+++ b/libavcodec/loongarch/Makefile
@@ -6,6 +6,7 @@ OBJS-$(CONFIG_VP8_DECODER)+=
loongarch/vp8dsp_init_loongarch.o
OBJS-$(CONFIG_VP9_DECODER)+= loongarch/vp9dsp_init_loongarch.o
OBJS-$(CONFIG_VC1DSP) += loongarch/vc1dsp_init_loongarch.o
OBJS-$(CONFIG_HPELDSP)+= loongarch/hpeldsp_init_loongarch.o
+OBJS-$(CONFIG_IDCTDSP)+= loongarch/idctdsp_init_loongarch.o
LASX-OBJS-$(CONFIG_H264CHROMA)+= loongarch/h264chroma_lasx.o
LASX-OBJS-$(CONFIG_H264QPEL) += loongarch/h264qpel_lasx.o
LASX-OBJS-$(CONFIG_H264DSP) += loongarch/h264dsp_lasx.o \
@@ -14,6 +15,8 @@ LASX-OBJS-$(CONFIG_H264DSP) +=
loongarch/h264dsp_lasx.o \
LASX-OBJS-$(CONFIG_H264PRED) += loongarch/h264_intrapred_lasx.o
LASX-OBJS-$(CONFIG_VC1_DECODER) += loongarch/vc1dsp_lasx.o
LASX-OBJS-$(CONFIG_HPELDSP) += loongarch/hpeldsp_lasx.o
+LASX-OBJS-$(CONFIG_IDCTDSP) += loongarch/simple_idct_lasx.o \
+ loongarch/idctdsp_lasx.o
LSX-OBJS-$(CONFIG_VP8_DECODER)+= loongarch/vp8_mc_lsx.o \
loongarch/vp8_lpf_lsx.o
LSX-OBJS-$(CONFIG_VP9_DECODER)+= loongarch/vp9_mc_lsx.o \
diff --git a/libavcodec/loongarch/idctdsp_init_loongarch.c
b/libavcodec/loongarch/idctdsp_init_loongarch.c
new file mode 100644
index 00..9d1d21cc18
--- /dev/null
+++ b/libavcodec/loongarch/idctdsp_init_loongarch.c
@@ -0,0 +1,45 @@
+/*
+ * Copyright (c) 2021 Loongson Technology Corporation Limited
+ * Contributed by Hao Chen
+ *
+ * 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/loongarch/cpu.h"
+#include "idctdsp_loongarch.h"
+#include "libavcodec/xvididct.h"
+
+av_cold void ff_idctdsp_init_loongarch(IDCTDSPContext *c, AVCodecContext
*avctx,
+ unsigned high_bit_depth)
+{
+int cpu_flags = av_get_cpu_flags();
+
+if (have_lasx(cpu_flags)) {
+if ((avctx->lowres != 1) && (avctx->lowres != 2) && (avctx->lowres !=
3) &&
+(avctx->bits_per_raw_sample != 1
[FFmpeg-devel] [PATCH 1/3] avcodec: [loongarch] Optimize hpeldsp with LASX.
From: Shiyou Yin
./ffmpeg -i 8_mpeg4_1080p_24fps_12Mbps.avi -f rawvideo -y /dev/null -an
before:376fps
after :433fps
Change-Id: Ic8018562093154887323b508b81d0f489c0d265d
Signed-off-by: Hao Chen
---
libavcodec/hpeldsp.c |2 +
libavcodec/hpeldsp.h |1 +
libavcodec/loongarch/Makefile |2 +
libavcodec/loongarch/hpeldsp_init_loongarch.c | 50 +
libavcodec/loongarch/hpeldsp_lasx.c | 1289 +
libavcodec/loongarch/hpeldsp_lasx.h | 58 +
6 files changed, 1402 insertions(+)
create mode 100644 libavcodec/loongarch/hpeldsp_init_loongarch.c
create mode 100644 libavcodec/loongarch/hpeldsp_lasx.c
create mode 100644 libavcodec/loongarch/hpeldsp_lasx.h
diff --git a/libavcodec/hpeldsp.c b/libavcodec/hpeldsp.c
index 8e2fd8fcf5..843ba399c5 100644
--- a/libavcodec/hpeldsp.c
+++ b/libavcodec/hpeldsp.c
@@ -367,4 +367,6 @@ av_cold void ff_hpeldsp_init(HpelDSPContext *c, int flags)
ff_hpeldsp_init_x86(c, flags);
if (ARCH_MIPS)
ff_hpeldsp_init_mips(c, flags);
+if (ARCH_LOONGARCH64)
+ff_hpeldsp_init_loongarch(c, flags);
}
diff --git a/libavcodec/hpeldsp.h b/libavcodec/hpeldsp.h
index 768139bfc9..45e81b10a5 100644
--- a/libavcodec/hpeldsp.h
+++ b/libavcodec/hpeldsp.h
@@ -102,5 +102,6 @@ void ff_hpeldsp_init_arm(HpelDSPContext *c, int flags);
void ff_hpeldsp_init_ppc(HpelDSPContext *c, int flags);
void ff_hpeldsp_init_x86(HpelDSPContext *c, int flags);
void ff_hpeldsp_init_mips(HpelDSPContext *c, int flags);
+void ff_hpeldsp_init_loongarch(HpelDSPContext *c, int flags);
#endif /* AVCODEC_HPELDSP_H */
diff --git a/libavcodec/loongarch/Makefile b/libavcodec/loongarch/Makefile
index baf5f92e84..07a401d883 100644
--- a/libavcodec/loongarch/Makefile
+++ b/libavcodec/loongarch/Makefile
@@ -5,6 +5,7 @@ OBJS-$(CONFIG_H264PRED) +=
loongarch/h264_intrapred_init_loongarch
OBJS-$(CONFIG_VP8_DECODER)+= loongarch/vp8dsp_init_loongarch.o
OBJS-$(CONFIG_VP9_DECODER)+= loongarch/vp9dsp_init_loongarch.o
OBJS-$(CONFIG_VC1DSP) += loongarch/vc1dsp_init_loongarch.o
+OBJS-$(CONFIG_HPELDSP)+= loongarch/hpeldsp_init_loongarch.o
LASX-OBJS-$(CONFIG_H264CHROMA)+= loongarch/h264chroma_lasx.o
LASX-OBJS-$(CONFIG_H264QPEL) += loongarch/h264qpel_lasx.o
LASX-OBJS-$(CONFIG_H264DSP) += loongarch/h264dsp_lasx.o \
@@ -12,6 +13,7 @@ LASX-OBJS-$(CONFIG_H264DSP) +=
loongarch/h264dsp_lasx.o \
loongarch/h264_deblock_lasx.o
LASX-OBJS-$(CONFIG_H264PRED) += loongarch/h264_intrapred_lasx.o
LASX-OBJS-$(CONFIG_VC1_DECODER) += loongarch/vc1dsp_lasx.o
+LASX-OBJS-$(CONFIG_HPELDSP) += loongarch/hpeldsp_lasx.o
LSX-OBJS-$(CONFIG_VP8_DECODER)+= loongarch/vp8_mc_lsx.o \
loongarch/vp8_lpf_lsx.o
LSX-OBJS-$(CONFIG_VP9_DECODER)+= loongarch/vp9_mc_lsx.o \
diff --git a/libavcodec/loongarch/hpeldsp_init_loongarch.c
b/libavcodec/loongarch/hpeldsp_init_loongarch.c
new file mode 100644
index 00..1690be5438
--- /dev/null
+++ b/libavcodec/loongarch/hpeldsp_init_loongarch.c
@@ -0,0 +1,50 @@
+/*
+ * Copyright (c) 2021 Loongson Technology Corporation Limited
+ * Contributed by Shiyou Yin
+ *
+ * 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/loongarch/cpu.h"
+#include "libavcodec/hpeldsp.h"
+#include "libavcodec/loongarch/hpeldsp_lasx.h"
+
+void ff_hpeldsp_init_loongarch(HpelDSPContext *c, int flags)
+{
+int cpu_flags = av_get_cpu_flags();
+
+if (have_lasx(cpu_flags)) {
+c->put_pixels_tab[0][0] = ff_put_pixels16_8_lsx;
+c->put_pixels_tab[0][1] = ff_put_pixels16_x2_8_lasx;
+c->put_pixels_tab[0][2] = ff_put_pixels16_y2_8_lasx;
+c->put_pixels_tab[0][3] = ff_put_pixels16_xy2_8_lasx;
+
+c->put_pixels_tab[1][0] = ff_put_pixels8_8_lasx;
+c->put_pixels_tab[1][1] = ff_put_pixels8_x2_8_lasx;
+c->put_pixels_tab[1][2] = ff_put_pixels8_y2_8_lasx;
+c->put_pixels_tab[1][3] = ff_put_pixels8_xy2_8_lasx;
+c->put_no_rnd_pixels_tab[0][0] = ff_put_pixels16_8_lsx;
+c->put_no_rnd_pixels_tab[0][1
[FFmpeg-devel] [PATCH 3/3] avcodec: [loongarch] Optimize prefetch with loongarch.
From: gxw
./ffmpeg -i ../1_h264_1080p_30fps_3Mbps.mp4 -f rawvideo -y /dev/null -an
before:296
after :308
Change-Id: I748490c1551d0ecfb8b8001625cf7e4e30f28eb4
---
libavcodec/loongarch/Makefile| 1 +
libavcodec/loongarch/videodsp_init.c | 45
libavcodec/videodsp.c| 2 ++
libavcodec/videodsp.h| 1 +
4 files changed, 49 insertions(+)
create mode 100644 libavcodec/loongarch/videodsp_init.c
diff --git a/libavcodec/loongarch/Makefile b/libavcodec/loongarch/Makefile
index c4d71e801b..3c15c2edeb 100644
--- a/libavcodec/loongarch/Makefile
+++ b/libavcodec/loongarch/Makefile
@@ -7,6 +7,7 @@ OBJS-$(CONFIG_VP9_DECODER)+=
loongarch/vp9dsp_init_loongarch.o
OBJS-$(CONFIG_VC1DSP) += loongarch/vc1dsp_init_loongarch.o
OBJS-$(CONFIG_HPELDSP)+= loongarch/hpeldsp_init_loongarch.o
OBJS-$(CONFIG_IDCTDSP)+= loongarch/idctdsp_init_loongarch.o
+OBJS-$(CONFIG_VIDEODSP) += loongarch/videodsp_init.o
LASX-OBJS-$(CONFIG_H264CHROMA)+= loongarch/h264chroma_lasx.o
LASX-OBJS-$(CONFIG_H264QPEL) += loongarch/h264qpel_lasx.o
LASX-OBJS-$(CONFIG_H264DSP) += loongarch/h264dsp_lasx.o \
diff --git a/libavcodec/loongarch/videodsp_init.c
b/libavcodec/loongarch/videodsp_init.c
new file mode 100644
index 00..6cbb7763ff
--- /dev/null
+++ b/libavcodec/loongarch/videodsp_init.c
@@ -0,0 +1,45 @@
+/*
+ * Copyright (c) 2021 Loongson Technology Corporation Limited
+ * Contributed by Xiwei Gu
+ *
+ * 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 "libavcodec/videodsp.h"
+#include "libavutil/attributes.h"
+
+static void prefetch_loongarch(uint8_t *mem, ptrdiff_t stride, int h)
+{
+register const uint8_t *p = mem;
+
+__asm__ volatile (
+"1: \n\t"
+"preld 0, %[p], 0 \n\t"
+"preld 0, %[p], 32 \n\t"
+"addi.d %[h], %[h], -1 \n\t"
+"add.d %[p], %[p], %[stride] \n\t"
+
+"blt$r0, %[h], 1b \n\t"
+: [p] "+r" (p), [h] "+r" (h)
+: [stride] "r" (stride)
+);
+}
+
+av_cold void ff_videodsp_init_loongarch(VideoDSPContext *ctx, int bpc)
+{
+ctx->prefetch = prefetch_loongarch;
+}
diff --git a/libavcodec/videodsp.c b/libavcodec/videodsp.c
index ce9e9eb143..212147984f 100644
--- a/libavcodec/videodsp.c
+++ b/libavcodec/videodsp.c
@@ -54,4 +54,6 @@ av_cold void ff_videodsp_init(VideoDSPContext *ctx, int bpc)
ff_videodsp_init_x86(ctx, bpc);
if (ARCH_MIPS)
ff_videodsp_init_mips(ctx, bpc);
+if (ARCH_LOONGARCH64)
+ff_videodsp_init_loongarch(ctx, bpc);
}
diff --git a/libavcodec/videodsp.h b/libavcodec/videodsp.h
index c0545f22b0..ac971dc57f 100644
--- a/libavcodec/videodsp.h
+++ b/libavcodec/videodsp.h
@@ -84,5 +84,6 @@ void ff_videodsp_init_arm(VideoDSPContext *ctx, int bpc);
void ff_videodsp_init_ppc(VideoDSPContext *ctx, int bpc);
void ff_videodsp_init_x86(VideoDSPContext *ctx, int bpc);
void ff_videodsp_init_mips(VideoDSPContext *ctx, int bpc);
+void ff_videodsp_init_loongarch(VideoDSPContext *ctx, int bpc);
#endif /* AVCODEC_VIDEODSP_H */
--
2.20.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_hevc: add -pic_timing_sei option
On Fri, Dec 24, 2021 at 08:47:38AM +, Xiang, Haihao wrote:
> On Fri, 2021-12-24 at 16:17 +0800, lance.lmw...@gmail.com wrote:
> > On Fri, Dec 24, 2021 at 07:35:25AM +, Xiang, Haihao wrote:
> > > On Fri, 2021-08-06 at 10:10 +0800, Haihao Xiang wrote:
> > > > The SDK may insert picture timing SEI for hevc and the code to set mfx
> > > > parameter has been added in qsvenc, however the corresponding option is
> > > > missing in the hevc option array
> > > > ---
> > > > libavcodec/qsvenc_hevc.c | 1 +
> > > > 1 file changed, 1 insertion(+)
> > > >
> > > > diff --git a/libavcodec/qsvenc_hevc.c b/libavcodec/qsvenc_hevc.c
> > > > index b7b2f5633e..1e31968673 100644
> > > > --- a/libavcodec/qsvenc_hevc.c
> > > > +++ b/libavcodec/qsvenc_hevc.c
> > > > @@ -248,6 +248,7 @@ static const AVOption options[] = {
> > > > { "tile_rows", "Number of rows for tiled
> > > > encoding", OFFSET(qsv.tile_rows),AV_OPT_TYPE_INT, { .i64 = 0 },
> > > > 0,
> > > > UINT16_MAX, VE },
> > > > { "recovery_point_sei", "Insert recovery point SEI
> > > > messages", OFFSET(qsv.recovery_point_sei), AV_OPT_TYPE_INT, {
> > > > .i64
> > > > = -1 }, -1, 1, VE },
> > > > { "aud", "Insert the Access Unit Delimiter NAL", OFFSET(qsv.aud),
> > > > AV_OPT_TYPE_INT, { .i64 = 0 }, 0, 1, VE},
> > > > +{ "pic_timing_sei","Insert picture timing SEI with
> > > > pic_struct_syntax
> > > > element", OFFSET(qsv.pic_timing_sei), AV_OPT_TYPE_INT, { .i64 = 1 }, 0,
> > > > 1,
> > > > VE
> >
> > It's better to use AV_OPT_TYPE_BOOL if the option is used for on/off or
> > enable/disable.
> >
>
> Thanks for your comment. I'll change it to AV_OPT_TYPE_BOOL,
>
> > I think you need to add description in the doc for the new options if
> > possible.
>
> Currently there isn't a doc for qsv decoder, we'll try to add it later.
QSV encoder have one section in in doc/encoders.texi already although not all of
options are included.
$ grep "QSV encoders" doc/encoders.texi
@section QSV encoders
>
> Thanks
> Haihao
>
> >
> > > > },
> > > >
> > > > { NULL },
> > > > };
> > >
> > > Will apply
> > >
> > > -Haihao
> > >
> > > ___
> > > ffmpeg-devel mailing list
> > > ffmpeg-devel@ffmpeg.org
> > > https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> > >
> > > To unsubscribe, visit link above, or email
> > > ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
> >
> >
> ___
> 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".
--
Thanks,
Limin Wang
___
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/mov: skip moof and sidx before found moov
---
libavformat/mov.c | 16
1 file changed, 16 insertions(+)
diff --git a/libavformat/mov.c b/libavformat/mov.c
index 2aed6e80ef..ea2f010aa0 100644
--- a/libavformat/mov.c
+++ b/libavformat/mov.c
@@ -7366,6 +7366,21 @@ static int mov_read_default(MOVContext *c, AVIOContext
*pb, MOVAtom atom)
break;
a.size = FFMIN(a.size, atom.size - total_size);
+if (!c->found_moov) {
+static uint32_t skip_before_moov[] = {
+MKTAG('m', 'o', 'o', 'f'),
+MKTAG('s', 'i', 'd', 'x'),
+};
+for (size_t i = 0; i < FF_ARRAY_ELEMS(skip_before_moov); i++) {
+if (a.type == skip_before_moov[i]) {
+av_log(c->fc, AV_LOG_WARNING, "Skip %s atom before
moov.\n",
+ av_fourcc2str(a.type));
+parse = NULL;
+goto skip;
+}
+}
+}
+
for (i = 0; mov_default_parse_table[i].type; i++)
if (mov_default_parse_table[i].type == a.type) {
parse = mov_default_parse_table[i].parse;
@@ -7386,6 +7401,7 @@ static int mov_read_default(MOVContext *c, AVIOContext
*pb, MOVAtom atom)
parse = mov_read_keys;
}
+skip:
if (!parse) { /* skip leaf atoms data */
avio_skip(pb, a.size);
} else {
--
2.31.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/3] avformat/mov: remove always false condtion
203b0e35 made duration unsigned.
---
libavformat/mov.c | 11 ---
1 file changed, 11 deletions(-)
diff --git a/libavformat/mov.c b/libavformat/mov.c
index 63483740a0..636cfce400 100644
--- a/libavformat/mov.c
+++ b/libavformat/mov.c
@@ -3972,17 +3972,6 @@ static void mov_build_index(MOVContext *mov, AVStream
*st)
current_offset += sample_size;
stream_size += sample_size;
-
-/* A negative sample duration is invalid based on the spec,
- * but some samples need it to correct the DTS. */
-if (sc->stts_data[stts_index].duration < 0) {
-av_log(mov->fc, AV_LOG_WARNING,
- "Invalid SampleDelta %d in STTS, at %d st:%d\n",
- sc->stts_data[stts_index].duration, stts_index,
- st->index);
-dts_correction += sc->stts_data[stts_index].duration - 1;
-sc->stts_data[stts_index].duration = 1;
-}
current_dts += sc->stts_data[stts_index].duration;
if (!dts_correction || current_dts + dts_correction >
last_dts) {
current_dts += dts_correction;
--
2.31.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/3] avformat/mov: skip hoov box if strict >= normal
The samples I have got have hoov and moov both. Unknown boxes
should be skipped according to the spec. So don't treat hoov as
moov in normal mode.
For backward compatible, a log message has been added to notice
the user to relax the striction if moov doesn't exist.
Fix #8883.
---
libavformat/mov.c | 13 +
1 file changed, 9 insertions(+), 4 deletions(-)
diff --git a/libavformat/mov.c b/libavformat/mov.c
index ea2f010aa0..63483740a0 100644
--- a/libavformat/mov.c
+++ b/libavformat/mov.c
@@ -7324,10 +7324,11 @@ static int mov_read_default(MOVContext *c, AVIOContext
*pb, MOVAtom atom)
if (atom.size >= 8) {
a.size = avio_rb32(pb);
a.type = avio_rl32(pb);
-if (((a.type == MKTAG('f','r','e','e') && c->moov_retry) ||
- a.type == MKTAG('h','o','o','v')) &&
-a.size >= 8 &&
-c->fc->strict_std_compliance < FF_COMPLIANCE_STRICT) {
+if (((a.type == MKTAG('f','r','e','e') && c->moov_retry &&
+c->fc->strict_std_compliance < FF_COMPLIANCE_STRICT) ||
+ (a.type == MKTAG('h','o','o','v') &&
+c->fc->strict_std_compliance < FF_COMPLIANCE_NORMAL))
&&
+a.size >= 8) {
uint32_t type;
avio_skip(pb, 4);
type = avio_rl32(pb);
@@ -7340,6 +7341,10 @@ static int mov_read_default(MOVContext *c, AVIOContext
*pb, MOVAtom atom)
a.type = MKTAG('m','o','o','v');
}
}
+if (a.type == MKTAG('h','o','o','v') &&
+c->fc->strict_std_compliance >= FF_COMPLIANCE_NORMAL)
+av_log(c->fc, AV_LOG_INFO,
+"Skip hoov atom, try decrease -strict if moov doesn't
exist.\n");
if (atom.type != MKTAG('r','o','o','t') &&
atom.type != MKTAG('m','o','o','v')) {
if (a.type == MKTAG('t','r','a','k') ||
--
2.31.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/3] avformat/mov: skip hoov box if strict >= normal
> 2021年12月24日 下午5:58，Zhao Zhili 写道：
>
> The samples I have got have hoov and moov both. Unknown boxes
> should be skipped according to the spec. So don't treat hoov as
> moov in normal mode.
>
> For backward compatible, a log message has been added to notice
> the user to relax the striction if moov doesn't exist.
>
> Fix #8883.
> ---
> libavformat/mov.c | 13 +
> 1 file changed, 9 insertions(+), 4 deletions(-)
>
> diff --git a/libavformat/mov.c b/libavformat/mov.c
> index ea2f010aa0..63483740a0 100644
> --- a/libavformat/mov.c
> +++ b/libavformat/mov.c
> @@ -7324,10 +7324,11 @@ static int mov_read_default(MOVContext *c,
> AVIOContext *pb, MOVAtom atom)
> if (atom.size >= 8) {
> a.size = avio_rb32(pb);
> a.type = avio_rl32(pb);
> -if (((a.type == MKTAG('f','r','e','e') && c->moov_retry) ||
> - a.type == MKTAG('h','o','o','v')) &&
> -a.size >= 8 &&
> -c->fc->strict_std_compliance < FF_COMPLIANCE_STRICT) {
> +if (((a.type == MKTAG('f','r','e','e') && c->moov_retry &&
> +c->fc->strict_std_compliance < FF_COMPLIANCE_STRICT)
> ||
> + (a.type == MKTAG('h','o','o','v') &&
> +c->fc->strict_std_compliance <
> FF_COMPLIANCE_NORMAL)) &&
> +a.size >= 8) {
I prefer add one option ignore_hoov, let user choose ignore it, because it
should more clearly than use stirct.
> uint32_t type;
> avio_skip(pb, 4);
> type = avio_rl32(pb);
> @@ -7340,6 +7341,10 @@ static int mov_read_default(MOVContext *c, AVIOContext
> *pb, MOVAtom atom)
> a.type = MKTAG('m','o','o','v');
> }
> }
> +if (a.type == MKTAG('h','o','o','v') &&
> +c->fc->strict_std_compliance >= FF_COMPLIANCE_NORMAL)
> +av_log(c->fc, AV_LOG_INFO,
> +"Skip hoov atom, try decrease -strict if moov
> doesn't exist.\n");
> if (atom.type != MKTAG('r','o','o','t') &&
> atom.type != MKTAG('m','o','o','v')) {
> if (a.type == MKTAG('t','r','a','k') ||
> --
> 2.31.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".
>
Thanks
Steven Liu
___
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 3/3] avformat/mov: remove always false condtion
> 2021年12月24日 下午5:58，Zhao Zhili 写道：
>
> 203b0e35 made duration unsigned.
> ---
> libavformat/mov.c | 11 ---
> 1 file changed, 11 deletions(-)
>
> diff --git a/libavformat/mov.c b/libavformat/mov.c
> index 63483740a0..636cfce400 100644
> --- a/libavformat/mov.c
> +++ b/libavformat/mov.c
> @@ -3972,17 +3972,6 @@ static void mov_build_index(MOVContext *mov, AVStream
> *st)
>
> current_offset += sample_size;
> stream_size += sample_size;
> -
> -/* A negative sample duration is invalid based on the spec,
> - * but some samples need it to correct the DTS. */
> -if (sc->stts_data[stts_index].duration < 0) {
> -av_log(mov->fc, AV_LOG_WARNING,
> - "Invalid SampleDelta %d in STTS, at %d st:%d\n",
> - sc->stts_data[stts_index].duration, stts_index,
> - st->index);
> -dts_correction += sc->stts_data[stts_index].duration - 1;
> -sc->stts_data[stts_index].duration = 1;
> -}
> current_dts += sc->stts_data[stts_index].duration;
> if (!dts_correction || current_dts + dts_correction >
> last_dts) {
> current_dts += dts_correction;
> --
> 2.31.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".
>
Yes, this is a warning when compiling the mov.o module, but not sure if the
duration is unsigned can small than 0,
Because there have some way about unsigned int use way,not sure it corect or
not:
Eg. unsigned int example = -1;
Thanks
Steven Liu
___
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] avformat/mov: skip hoov box if strict >= normal
> On Dec 24, 2021, at 6:19 PM, Steven Liu wrote:
>
>> 2021年12月24日 下午5:58，Zhao Zhili 写道：
>>
>> The samples I have got have hoov and moov both. Unknown boxes
>> should be skipped according to the spec. So don't treat hoov as
>> moov in normal mode.
>>
>> For backward compatible, a log message has been added to notice
>> the user to relax the striction if moov doesn't exist.
>>
>> Fix #8883.
>> ---
>> libavformat/mov.c | 13 +
>> 1 file changed, 9 insertions(+), 4 deletions(-)
>>
>> diff --git a/libavformat/mov.c b/libavformat/mov.c
>> index ea2f010aa0..63483740a0 100644
>> --- a/libavformat/mov.c
>> +++ b/libavformat/mov.c
>> @@ -7324,10 +7324,11 @@ static int mov_read_default(MOVContext *c,
>> AVIOContext *pb, MOVAtom atom)
>>if (atom.size >= 8) {
>>a.size = avio_rb32(pb);
>>a.type = avio_rl32(pb);
>> -if (((a.type == MKTAG('f','r','e','e') && c->moov_retry) ||
>> - a.type == MKTAG('h','o','o','v')) &&
>> -a.size >= 8 &&
>> -c->fc->strict_std_compliance < FF_COMPLIANCE_STRICT) {
>> +if (((a.type == MKTAG('f','r','e','e') && c->moov_retry &&
>> +c->fc->strict_std_compliance <
>> FF_COMPLIANCE_STRICT) ||
>> + (a.type == MKTAG('h','o','o','v') &&
>> +c->fc->strict_std_compliance <
>> FF_COMPLIANCE_NORMAL)) &&
>> +a.size >= 8) {
>
> I prefer add one option ignore_hoov, let user choose ignore it, because it
> should more clearly than use stirct.
Add an option works for me too, but it should default to ignore hoov, because:
1. Truncated/broken files are minority compared to normal files (I hope);
2. Support normal files has higher priority than workaround broken files.
We can support both by drop fake moov info after found a real moov, but
it doesn’t deserve the complexity.
I’d like to get more opinions.
>>uint32_t type;
>>avio_skip(pb, 4);
>>type = avio_rl32(pb);
>> @@ -7340,6 +7341,10 @@ static int mov_read_default(MOVContext *c,
>> AVIOContext *pb, MOVAtom atom)
>>a.type = MKTAG('m','o','o','v');
>>}
>>}
>> +if (a.type == MKTAG('h','o','o','v') &&
>> +c->fc->strict_std_compliance >= FF_COMPLIANCE_NORMAL)
>> +av_log(c->fc, AV_LOG_INFO,
>> +"Skip hoov atom, try decrease -strict if moov
>> doesn't exist.\n");
>>if (atom.type != MKTAG('r','o','o','t') &&
>>atom.type != MKTAG('m','o','o','v')) {
>>if (a.type == MKTAG('t','r','a','k') ||
>> --
>> 2.31.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".
>>
>
> Thanks
>
> Steven Liu
>
>> 2021年12月24日 下午5:58，Zhao Zhili 写道：
>>
>> The samples I have got have hoov and moov both. Unknown boxes
>> should be skipped according to the spec. So don't treat hoov as
>> moov in normal mode.
>>
>> For backward compatible, a log message has been added to notice
>> the user to relax the striction if moov doesn't exist.
>>
>> Fix #8883.
>> ---
>> libavformat/mov.c | 13 +
>> 1 file changed, 9 insertions(+), 4 deletions(-)
>>
>> diff --git a/libavformat/mov.c b/libavformat/mov.c
>> index ea2f010aa0..63483740a0 100644
>> --- a/libavformat/mov.c
>> +++ b/libavformat/mov.c
>> @@ -7324,10 +7324,11 @@ static int mov_read_default(MOVContext *c,
>> AVIOContext *pb, MOVAtom atom)
>>if (atom.size >= 8) {
>>a.size = avio_rb32(pb);
>>a.type = avio_rl32(pb);
>> -if (((a.type == MKTAG('f','r','e','e') && c->moov_retry) ||
>> - a.type == MKTAG('h','o','o','v')) &&
>> -a.size >= 8 &&
>> -c->fc->strict_std_compliance < FF_COMPLIANCE_STRICT) {
>> +if (((a.type == MKTAG('f','r','e','e') && c->moov_retry &&
>> +c->fc->strict_std_compliance <
>> FF_COMPLIANCE_STRICT) ||
>> + (a.type == MKTAG('h','o','o','v') &&
>> +c->fc->strict_std_compliance <
>> FF_COMPLIANCE_NORMAL)) &&
>> +a.size >= 8) {
>
> I prefer add one option ignore_hoov, let user choose ignore it, because it
> should more clearly than use stirct.
>>uint32_t type;
>>avio_skip(pb, 4);
>>type = avio_rl32(pb);
>> @@ -7340,6 +7341,10 @@ static int mov_read_default(MOVContext *c,
>> AVIOContext *pb, MOVAtom atom)
>>a.type = MKTAG('m','o','o','v');
>>}
>>}
>> +if (a.type == MKTAG('h','o','o','v') &&
>> +c->fc->strict_std_compliance >= FF_COMPLIANCE_NORMAL)
>> +av_log(
Re: [FFmpeg-devel] [PATCH 2/3] avformat/mov: skip hoov box if strict >= normal
"zhilizhao(赵志立)" 于2021年12月24日周五 18:38写道：
>
>
>
> > On Dec 24, 2021, at 6:19 PM, Steven Liu wrote:
> >
> >> 2021年12月24日 下午5:58，Zhao Zhili 写道：
> >>
> >> The samples I have got have hoov and moov both. Unknown boxes
> >> should be skipped according to the spec. So don't treat hoov as
> >> moov in normal mode.
> >>
> >> For backward compatible, a log message has been added to notice
> >> the user to relax the striction if moov doesn't exist.
> >>
> >> Fix #8883.
> >> ---
> >> libavformat/mov.c | 13 +
> >> 1 file changed, 9 insertions(+), 4 deletions(-)
> >>
> >> diff --git a/libavformat/mov.c b/libavformat/mov.c
> >> index ea2f010aa0..63483740a0 100644
> >> --- a/libavformat/mov.c
> >> +++ b/libavformat/mov.c
> >> @@ -7324,10 +7324,11 @@ static int mov_read_default(MOVContext *c,
> >> AVIOContext *pb, MOVAtom atom)
> >>if (atom.size >= 8) {
> >>a.size = avio_rb32(pb);
> >>a.type = avio_rl32(pb);
> >> -if (((a.type == MKTAG('f','r','e','e') && c->moov_retry) ||
> >> - a.type == MKTAG('h','o','o','v')) &&
> >> -a.size >= 8 &&
> >> -c->fc->strict_std_compliance < FF_COMPLIANCE_STRICT) {
> >> +if (((a.type == MKTAG('f','r','e','e') && c->moov_retry &&
> >> +c->fc->strict_std_compliance <
> >> FF_COMPLIANCE_STRICT) ||
> >> + (a.type == MKTAG('h','o','o','v') &&
> >> +c->fc->strict_std_compliance <
> >> FF_COMPLIANCE_NORMAL)) &&
> >> +a.size >= 8) {
> >
> > I prefer add one option ignore_hoov, let user choose ignore it, because it
> > should more clearly than use stirct.
>
> Add an option works for me too, but it should default to ignore hoov, because:
> 1. Truncated/broken files are minority compared to normal files (I hope);
> 2. Support normal files has higher priority than workaround broken files.
>
I think about ignore hoov should not default, because it use hoov
default before.
We should attention users pay attention about this change maybe do it
like deprecate warning. Just waning need change default it ignore hoov
and use moov.
But I’m not sure ignore hoov is correct, because not sure user have
the sample file which only have one hoov and have no moov atom in the
files.
> We can support both by drop fake moov info after found a real moov, but
> it doesn’t deserve the complexity.
>
> I’d like to get more opinions.
>
>
> >>uint32_t type;
> >>avio_skip(pb, 4);
> >>type = avio_rl32(pb);
> >> @@ -7340,6 +7341,10 @@ static int mov_read_default(MOVContext *c,
> >> AVIOContext *pb, MOVAtom atom)
> >>a.type = MKTAG('m','o','o','v');
> >>}
> >>}
> >> +if (a.type == MKTAG('h','o','o','v') &&
> >> +c->fc->strict_std_compliance >= FF_COMPLIANCE_NORMAL)
> >> +av_log(c->fc, AV_LOG_INFO,
> >> +"Skip hoov atom, try decrease -strict if moov
> >> doesn't exist.\n");
> >>if (atom.type != MKTAG('r','o','o','t') &&
> >>atom.type != MKTAG('m','o','o','v')) {
> >>if (a.type == MKTAG('t','r','a','k') ||
> >> --
> >> 2.31.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".
> >>
> >
> > Thanks
> >
> > Steven Liu
> >
> >> 2021年12月24日 下午5:58，Zhao Zhili 写道：
> >>
> >> The samples I have got have hoov and moov both. Unknown boxes
> >> should be skipped according to the spec. So don't treat hoov as
> >> moov in normal mode.
> >>
> >> For backward compatible, a log message has been added to notice
> >> the user to relax the striction if moov doesn't exist.
> >>
> >> Fix #8883.
> >> ---
> >> libavformat/mov.c | 13 +
> >> 1 file changed, 9 insertions(+), 4 deletions(-)
> >>
> >> diff --git a/libavformat/mov.c b/libavformat/mov.c
> >> index ea2f010aa0..63483740a0 100644
> >> --- a/libavformat/mov.c
> >> +++ b/libavformat/mov.c
> >> @@ -7324,10 +7324,11 @@ static int mov_read_default(MOVContext *c,
> >> AVIOContext *pb, MOVAtom atom)
> >>if (atom.size >= 8) {
> >>a.size = avio_rb32(pb);
> >>a.type = avio_rl32(pb);
> >> -if (((a.type == MKTAG('f','r','e','e') && c->moov_retry) ||
> >> - a.type == MKTAG('h','o','o','v')) &&
> >> -a.size >= 8 &&
> >> -c->fc->strict_std_compliance < FF_COMPLIANCE_STRICT) {
> >> +if (((a.type == MKTAG('f','r','e','e') && c->moov_retry &&
> >> +c->fc->strict_std_compliance <
> >> FF_COMPLIANCE_STRICT) ||
> >> + (a.type == MKTAG('h','o','o','v') &&
> >> +c->fc->strict_std_compliance <
> >> FF_CO
Re: [FFmpeg-devel] [PATCH 3/3] avformat/mov: remove always false condtion
On 2021-12-24 03:52 pm, Steven Liu wrote:
2021年12月24日 下午5:58，Zhao Zhili 写道：
203b0e35 made duration unsigned.
---
libavformat/mov.c | 11 ---
1 file changed, 11 deletions(-)
diff --git a/libavformat/mov.c b/libavformat/mov.c
index 63483740a0..636cfce400 100644
--- a/libavformat/mov.c
+++ b/libavformat/mov.c
@@ -3972,17 +3972,6 @@ static void mov_build_index(MOVContext *mov, AVStream
*st)
current_offset += sample_size;
stream_size += sample_size;
-
-/* A negative sample duration is invalid based on the spec,
- * but some samples need it to correct the DTS. */
-if (sc->stts_data[stts_index].duration < 0) {
-av_log(mov->fc, AV_LOG_WARNING,
- "Invalid SampleDelta %d in STTS, at %d st:%d\n",
- sc->stts_data[stts_index].duration, stts_index,
- st->index);
-dts_correction += sc->stts_data[stts_index].duration - 1;
-sc->stts_data[stts_index].duration = 1;
-}
current_dts += sc->stts_data[stts_index].duration;
if (!dts_correction || current_dts + dts_correction >
last_dts) {
current_dts += dts_correction;
--
2.31.1
This is due to a recent change I made to the type of stts duration.
There is a pending patch to replace this check with a check in
mov_read_stts, so ignore the warning for now.
Thanks,
Gyan
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] lavc/qsvenc_hevc: add -pic_timing_sei option
On Fri, 2021-12-24 at 17:55 +0800, lance.lmw...@gmail.com wrote:
> On Fri, Dec 24, 2021 at 08:47:38AM +, Xiang, Haihao wrote:
> > On Fri, 2021-12-24 at 16:17 +0800, lance.lmw...@gmail.com wrote:
> > > On Fri, Dec 24, 2021 at 07:35:25AM +, Xiang, Haihao wrote:
> > > > On Fri, 2021-08-06 at 10:10 +0800, Haihao Xiang wrote:
> > > > > The SDK may insert picture timing SEI for hevc and the code to set mfx
> > > > > parameter has been added in qsvenc, however the corresponding option
> > > > > is
> > > > > missing in the hevc option array
> > > > > ---
> > > > > libavcodec/qsvenc_hevc.c | 1 +
> > > > > 1 file changed, 1 insertion(+)
> > > > >
> > > > > diff --git a/libavcodec/qsvenc_hevc.c b/libavcodec/qsvenc_hevc.c
> > > > > index b7b2f5633e..1e31968673 100644
> > > > > --- a/libavcodec/qsvenc_hevc.c
> > > > > +++ b/libavcodec/qsvenc_hevc.c
> > > > > @@ -248,6 +248,7 @@ static const AVOption options[] = {
> > > > > { "tile_rows", "Number of rows for tiled
> > > > > encoding", OFFSET(qsv.tile_rows),AV_OPT_TYPE_INT, { .i64 = 0
> > > > > },
> > > > > 0,
> > > > > UINT16_MAX, VE },
> > > > > { "recovery_point_sei", "Insert recovery point SEI
> > > > > messages", OFFSET(qsv.recovery_point_sei), AV_OPT_TYPE_INT,
> > > > > {
> > > > > .i64
> > > > > = -1 }, -1, 1, VE },
> > > > > { "aud", "Insert the Access Unit Delimiter NAL", OFFSET(qsv.aud),
> > > > > AV_OPT_TYPE_INT, { .i64 = 0 }, 0, 1, VE},
> > > > > +{ "pic_timing_sei","Insert picture timing SEI with
> > > > > pic_struct_syntax
> > > > > element", OFFSET(qsv.pic_timing_sei), AV_OPT_TYPE_INT, { .i64 = 1 },
> > > > > 0, 1,
> > > > > VE
> > >
> > > It's better to use AV_OPT_TYPE_BOOL if the option is used for on/off or
> > > enable/disable.
> > >
> >
> > Thanks for your comment. I'll change it to AV_OPT_TYPE_BOOL,
> >
> > > I think you need to add description in the doc for the new options if
> > > possible.
> >
> > Currently there isn't a doc for qsv decoder, we'll try to add it later.
>
> QSV encoder have one section in in doc/encoders.texi already although not all
> of
> options are included.
>
> $ grep "QSV encoders" doc/encoders.texi
> @section QSV encoders
>
Thanks for pointing it out. These are global options, not specific options for
each QSV encoder, we will add the description about specific options.
BRs
Haihao
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] avcodec/nvenc: add udu_sei option to import user data unregistered SEIs
On 24.12.2021 05:32, lance.lmw...@gmail.com wrote: From: Limin Wang Note: nvenc sdk will truncated user data unregistered SEI if the size > 503. for example, hardcode its size to 504, trace_headers will report below error: Invalid SEI message: payload_size too large (504 504 bytes). I'm amazed it even does that now. Last time I tested this, encoding straight up failed if the SEI data was too large, since the allocated packet output buffer has a fixed size, and no API to influence that size exists. Disabling unregistered SEIs by default is probably a good call, given 99% of the time it'll lead to unexpected failures and is not actually intended or used by the user. It IS technically an API break though, so not 100% sure on this. Ideally it'd be possible to just increase the buffer size, so the SEI data fits. Where exactly did you see this 503 byte truncation happening? smime.p7s Description: S/MIME Cryptographic Signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] avcodec/nvenc: add udu_sei option to import user data unregistered SEIs
On Fri, Dec 24, 2021 at 03:00:10PM +0100, Timo Rothenpieler wrote: > On 24.12.2021 05:32, lance.lmw...@gmail.com wrote: > > From: Limin Wang > > > > Note: > > nvenc sdk will truncated user data unregistered SEI if the size > 503. > > for example, hardcode its size to 504, trace_headers will report below > > error: > > Invalid SEI message: payload_size too large (504 504 bytes). > > I'm amazed it even does that now. > Last time I tested this, encoding straight up failed if the SEI data was too > large, since the allocated packet output buffer has a fixed size, and no API > to influence that size exists. I'm not sure whether it's for the sdk version, I'm using nv-codec-headers(sdk/11.0) and encoding is OK, but I can't find any user data unregistered SEIs although my testing is created by libx264(default the data has encoding information by the UDU SEIs, its size > 503 always). So I using trace_headers to trace the output and find out it's truncated. > > Disabling unregistered SEIs by default is probably a good call, given 99% of > the time it'll lead to unexpected failures and is not actually intended or > used by the user. Yes, if it's not truncated, you'll see the x264 encoding setting after using h264_nvenc encoding with libx264 encoding file, it's very misleading in fact. > > It IS technically an API break though, so not 100% sure on this. It's introduced by commit: cee9f9628fb, it's not correct to import unregistered SEIs to output default and the patch try to fix that. We can bump the minor version for the API change. > Ideally it'd be possible to just increase the buffer size, so the SEI data > fits. > > Where exactly did you see this 503 byte truncation happening? You can tested with libx264 output file, the size of unregistered SEIs(for encoding setting) will > 503 always, if you don't make the size <= 503, you'll see below error by trace_eaders filter. Invalid SEI message: payload_size too large (xxx 504 bytes). Note, libavcodec/cbs_sei_syntax_template.c line 262, I print out "get_bits_left(rw) / 8". I think the buffer size is OK, but nvenc sdk truncate the data after encoding. > ___ > 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". -- Thanks, Limin Wang ___ 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/nvenc: add udu_sei option to import user data unregistered SEIs
On 24.12.2021 15:47, lance.lmw...@gmail.com wrote: You can tested with libx264 output file, the size of unregistered SEIs(for encoding setting) will > 503 always, if you don't make the size <= 503, you'll see below error by trace_eaders filter. Invalid SEI message: payload_size too large (xxx 504 bytes). Note, libavcodec/cbs_sei_syntax_template.c line 262, I print out "get_bits_left(rw) / 8". I think the buffer size is OK, but nvenc sdk truncate the data after encoding. What exactly are you referring to by nvenc sdk? Are you looking at some Nvidia sample that does this truncating? Cause if I try this with ffmpeg right now, encoding straight up fails if a too large SEI segment is attached, since nvenc runs out of space in the output buffer. smime.p7s Description: S/MIME Cryptographic 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 5/5] avformat/mvdec: Check bytes_per_sample
On Thu, Dec 23, 2021 at 10:32:12PM -0500, John-Paul Stewart wrote: > On 2021-12-23 16:15, Michael Niedermayer wrote: > > Fixes: division by zero > > Fixes: > > 42814/clusterfuzz-testcase-minimized-ffmpeg_dem_MV_fuzzer-4787014237552640 > > > > Found-by: continuous fuzzing process > > https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg > > Signed-off-by: Michael Niedermayer > > --- > > libavformat/mvdec.c | 3 +++ > > 1 file changed, 3 insertions(+) > > > > diff --git a/libavformat/mvdec.c b/libavformat/mvdec.c > > index 1a5012e5076..390f6ba4de8 100644 > > --- a/libavformat/mvdec.c > > +++ b/libavformat/mvdec.c > > @@ -366,6 +366,9 @@ static int mv_read_header(AVFormatContext *avctx) > > avpriv_request_sample(avctx, "Audio compression (format %i)", > > v); > > } > > > > +if (bytes_per_sample <= 0) > > +return AVERROR_INVALIDDATA; > > + > > bytes_per_sample is uint32_t so it can never be less than zero. > > bytes_per_sample will be zero for movie files with no audio, so that is > not necessarily invalid data. i can change it to AVERROR_PATCHWELCOME but this codepath has already created a audio stream so the code at least belives at this point that there is audio and it will crash a few lines later > > I can't offer a better suggestion at the moment, though. I'll see if > can come up with something, unless one of you guys gets to it first. ok, ill apply this unless i see another fix first as it fixes the crash and in fact in this path requests for samples where already printed also thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB The misfortune of the wise is better than the prosperity of the fool. -- Epicurus signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 36/36] avcodec/mpegvideo_enc: Remove dead code at compile time
On Fri, Dec 24, 2021 at 04:23:32AM +0100, Andreas Rheinhardt wrote: > There are no encoders for interlaced dct that support 4:4:4. i dont remember why its not supported but why not add 4:4:4 interlaced dct support ? just thinking as you already work on the code, that would seem to me the "more interresting" route than to optimize that out nothing againt this patch of course, thats fine too thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Modern terrorism, a quick summary: Need oil, start war with country that has oil, kill hundread thousand in war. Let country fall into chaos, be surprised about raise of fundamantalists. Drop more bombs, kill more people, be surprised about them taking revenge and drop even more bombs and strip your own citizens of their rights and freedoms. to be continued 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] Pixel format support fixes in swscale and drawutils
On Thu, Dec 23, 2021 at 09:08:48PM -0600, rcombs wrote: > This patchset is also available as a GitHub pull request for review > simplicity: > https://github.com/FFmpeg/FFmpeg/pull/380 > > - Reduce hardcoding of pixfmt lists, preferring deriving properties from > pixdesc > - Fix big-endian support for P[N]10/P[N]16 in swscale > - Fix several drawutils issues and add new pixfmt support > - Add more defensive checks in drawutils I can confirm that this fixes the failed test on MIPS thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Whats the most studid thing your enemy could do ? Blow himself up Whats the most studid thing you could do ? Give up your rights and freedom because your enemy blew himself up. 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 36/36] avcodec/mpegvideo_enc: Remove dead code at compile time
Michael Niedermayer: > On Fri, Dec 24, 2021 at 04:23:32AM +0100, Andreas Rheinhardt wrote: >> There are no encoders for interlaced dct that support 4:4:4. > > i dont remember why its not supported but > why not add 4:4:4 interlaced dct support ? > > just thinking as you already work on the code, that would seem to me > the "more interresting" route than to optimize that out > > nothing againt this patch of course, thats fine too > > thx > [...] > There are two encoders that support interlaced DCT: mpeg2video and mpeg4. Our encoder for the former supports 420 and 422; the format also allows 444. I don't really know how much is missing for supporting this (it's probably more than just hardcoding a third chroma format in ff_mpeg1_encode_mb()). And honestly, I don't really want to reread the mpeg-2 spec to find out, because it is nearly 2022 and MPEG-2 is obsolete and legacy. - Andreas ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 36/36] avcodec/mpegvideo_enc: Remove dead code at compile time
On Fri, Dec 24, 2021 at 07:30:11PM +0100, Andreas Rheinhardt wrote: > Michael Niedermayer: > > On Fri, Dec 24, 2021 at 04:23:32AM +0100, Andreas Rheinhardt wrote: > >> There are no encoders for interlaced dct that support 4:4:4. > > > > i dont remember why its not supported but > > why not add 4:4:4 interlaced dct support ? > > > > just thinking as you already work on the code, that would seem to me > > the "more interresting" route than to optimize that out > > > > nothing againt this patch of course, thats fine too > > > > thx > > [...] > > > > There are two encoders that support interlaced DCT: mpeg2video and > mpeg4. Our encoder for the former supports 420 and 422; the format also > allows 444. I don't really know how much is missing for supporting this > (it's probably more than just hardcoding a third chroma format in > ff_mpeg1_encode_mb()). And honestly, I don't really want to reread the > mpeg-2 spec to find out, because it is nearly 2022 and MPEG-2 is > obsolete and legacy. our decoder should support 444 i dont remember anything special but i agree, it makes little sense for a old format unless one enjoys doing it thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Those who are too smart to engage in politics are punished by being governed by those who are dumber. -- 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".
Re: [FFmpeg-devel] [PATCH 2/3] avformat/mov: skip hoov box if strict >= normal
On 12/24/2021 10:46 AM, Steven Liu wrote: > I think about ignore hoov should not default, because it use hoov > default before. I agree - we (Vimeo) get a ton of hoov files with no moov or broken moov - much more than files with hoov and valid moov (I've never seen any). This would be quite a breaking change. > We should attention users pay attention about this change maybe do it > like deprecate warning. Just waning need change default it ignore hoov > and use moov. +1 > But I’m not sure ignore hoov is correct, because not sure user have > the sample file which only have one hoov and have no moov atom in the > files. We have a lot of files with only hoov. - Derek ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 1/3] avformat/mov: skip moof and sidx before found moov
On 12/24/2021 9:58 AM, Zhao Zhili wrote: > --- > libavformat/mov.c | 16 > 1 file changed, 16 insertions(+) When do such files exist? They're not valid. - Derek ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 5/5] avformat/mvdec: Check bytes_per_sample
On 2021-12-24 11:58, Michael Niedermayer wrote: > On Thu, Dec 23, 2021 at 10:32:12PM -0500, John-Paul Stewart wrote: >> On 2021-12-23 16:15, Michael Niedermayer wrote: >>> Fixes: division by zero >>> Fixes: >>> 42814/clusterfuzz-testcase-minimized-ffmpeg_dem_MV_fuzzer-4787014237552640 >>> >>> Found-by: continuous fuzzing process >>> https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg >>> Signed-off-by: Michael Niedermayer >>> --- >>> libavformat/mvdec.c | 3 +++ >>> 1 file changed, 3 insertions(+) >>> >>> diff --git a/libavformat/mvdec.c b/libavformat/mvdec.c >>> index 1a5012e5076..390f6ba4de8 100644 >>> --- a/libavformat/mvdec.c >>> +++ b/libavformat/mvdec.c >>> @@ -366,6 +366,9 @@ static int mv_read_header(AVFormatContext *avctx) >>> avpriv_request_sample(avctx, "Audio compression (format %i)", >>> v); >>> } >>> >>> +if (bytes_per_sample <= 0) >>> +return AVERROR_INVALIDDATA; >>> + >> >> bytes_per_sample is uint32_t so it can never be less than zero. >> >> bytes_per_sample will be zero for movie files with no audio, so that is >> not necessarily invalid data. I have to retract that comment. Sorry for the confusion. Now that I've had time to delve into it further, the Silicon Graphics format will fill in a placeholder audio track (16 bit stereo, 22050 Hz) even when there is no actual audio. So even movies with no sound will have bytes_per_sample > 0. > i can change it to AVERROR_PATCHWELCOME but this codepath has already > created a audio stream so the code at least belives at this point that > there is audio and it will crash a few lines later > >> >> I can't offer a better suggestion at the moment, though. I'll see if >> can come up with something, unless one of you guys gets to it first. > > ok, ill apply this unless i see another fix first as it fixes the crash > and in fact in this path requests for samples where already printed also The real issue is that the audio stream is always allocated even when there is no audio. Fixing that is a project for another day. Don't let me stop you from applying the above patch. And again, my apologies for the confusion. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] avfilter/vf_libvmaf: update filter for libvmaf v2.0.0
Hi,
Never followed through on this vf_libvmaf patch from last June, and
I've had several people asking about its status lately. Rebased patch
attached. It's been a while, so I guess let's start the review again.
Would be nice if we could get this in before 5.0.
Thanks,
Kyle
On Wed, Jun 30, 2021 at 6:55 AM Moritz Barsnick wrote:
>
> Hi,
>
> > -enabled libvmaf && require_pkg_config libvmaf "libvmaf >= 1.5.2"
> > libvmaf.h compute_vmaf
> > +enabled libvmaf && require_pkg_config libvmaf "libvmaf >= 2.0.0"
> > libvmaf.h vmaf_init
>
> General question: Is it acceptable to drop support for libvmaf 1.x? I
> saw that Fedora 33 is still on 1.x.
>
> > -Obtain the VMAF (Video Multi-Method Assessment Fusion)
> > -score between two input videos.
> > +Calulate the VMAF (Video Multi-Method Assessment Fusion) score for a
> > +reference/distorted pair of input videos.
>
> These documentation improvements aren't related to the actual switch to
> 2.x, and should be in a separate commit.
>
> > @code{./configure --enable-libvmaf}.
> > -If no model path is specified it uses the default model:
> > @code{vmaf_v0.6.1.pkl}.
>
> Unless they are consequences of the switch, of course.
>
> > -{"model_path", "Set the model to be used for computing vmaf.",
> > OFFSET(model_path), AV_OPT_TYPE_STRING,
> > {.str="/usr/local/share/model/vmaf_v0.6.1.pkl"}, 0, 1, FLAGS},
> > -{"log_path", "Set the file path to be used to store logs.",
> > OFFSET(log_path), AV_OPT_TYPE_STRING, {.str=NULL}, 0, 1,
> > FLAGS},
> > -{"log_fmt", "Set the format of the log (csv, json or xml).",
> > OFFSET(log_fmt), AV_OPT_TYPE_STRING, {.str=NULL}, 0, 1, FLAGS},
> > -{"enable_transform", "Enables transform for computing vmaf.",
> > OFFSET(enable_transform), AV_OPT_TYPE_BOOL, {.i64=0}, 0, 1,
> > FLAGS},
> > -{"phone_model", "Invokes the phone model that will generate higher
> > VMAF scores.", OFFSET(phone_model), AV_OPT_TYPE_BOOL, {.i64=0}, 0, 1,
> > FLAGS},
> > -{"psnr", "Enables computing psnr along with vmaf.",
> > OFFSET(psnr), AV_OPT_TYPE_BOOL, {.i64=0}, 0, 1, FLAGS},
> > -{"ssim", "Enables computing ssim along with vmaf.",
> > OFFSET(ssim), AV_OPT_TYPE_BOOL, {.i64=0}, 0, 1, FLAGS},
> > -{"ms_ssim", "Enables computing ms-ssim along with vmaf.",
> > OFFSET(ms_ssim), AV_OPT_TYPE_BOOL, {.i64=0}, 0, 1, FLAGS},
> > -{"pool", "Set the pool method to be used for computing vmaf.",
> > OFFSET(pool), AV_OPT_TYPE_STRING, {.str=NULL}, 0, 1, FLAGS},
> > -{"n_threads", "Set number of threads to be used when computing vmaf.",
> > OFFSET(n_threads), AV_OPT_TYPE_INT, {.i64=0}, 0, UINT_MAX,
> > FLAGS},
> > -{"n_subsample", "Set interval for frame subsampling used when
> > computing vmaf.", OFFSET(n_subsample), AV_OPT_TYPE_INT, {.i64=1}, 1,
> > UINT_MAX, FLAGS},
> > -{"enable_conf_interval", "Enables confidence interval.",
> > OFFSET(enable_conf_interval), AV_OPT_TYPE_BOOL, {.i64=0}, 0,
> > 1, FLAGS},
> > +{"model", "Set the model to be used for computing vmaf.",
> >OFFSET(model_cfg), AV_OPT_TYPE_STRING,
> > {.str="version=vmaf_v0.6.1"}, 0, 1, FLAGS},
> > +{"feature", "Set the feature to be used for computing vmaf.",
> >OFFSET(feature_cfg), AV_OPT_TYPE_STRING, {.str=NULL}, 0, 1,
> > FLAGS},
> > +{"log_path", "Set the file path to be used to write log.",
> >OFFSET(log_path), AV_OPT_TYPE_STRING, {.str=NULL}, 0, 1,
> > FLAGS},
> > +{"log_fmt", "Set the format of the log (csv, json, xml, or sub).",
> >OFFSET(log_fmt), AV_OPT_TYPE_STRING, {.str="xml"}, 0, 1,
> > FLAGS},
> > +{"n_threads", "Set number of threads to be used when computing vmaf.",
> >OFFSET(n_threads), AV_OPT_TYPE_INT, {.i64=0}, 0, UINT_MAX,
> > FLAGS},
> > +{"n_subsample", "Set interval for frame subsampling used when
> > computing vmaf.", OFFSET(n_subsample), AV_OPT_TYPE_INT, {.i64=1}, 1,
> > UINT_MAX, FLAGS},
>
>
> Some changes are easier to review, if you don't change all the
> whitespace initially.
>
> > +if (err) return AVERROR(ENOMEM);
>
> Line break.
>
> > +int err = 0;
> > +if (!str) return NULL;
>
> Line break.
>
> > +if (!dict) goto fail;
>
> Ditto, in several subsequent places.
>
> > +if (str_copy)
> > +av_free(str_copy);
>
> No need to check for str_copy.
>
> > +e = NULL;
> > +while (e = av_dict_get(dict[i], "", e, AV_DICT_IGNORE_SUFFIX)) {
>
> I believe the assigned value from "e = NULL" is never used.
>
> > .name = "main",
> > .type = AVMEDIA_TYPE_VIDEO,
> > -},{
> > +},
> > +{
> > .name = "reference",
>
> Unrela
Re: [FFmpeg-devel] [PATCH] avfilter/vf_libvmaf: update filter for libvmaf v2.0.0
On 24.12.2021 21:51, Kyle Swanson wrote: Hi, Never followed through on this vf_libvmaf patch from last June, and I've had several people asking about its status lately. Rebased patch attached. It's been a while, so I guess let's start the review again. Would be nice if we could get this in before 5.0. Thanks, Kyle On Wed, Jun 30, 2021 at 6:55 AM Moritz Barsnick wrote: Hi, -enabled libvmaf && require_pkg_config libvmaf "libvmaf >= 1.5.2" libvmaf.h compute_vmaf +enabled libvmaf && require_pkg_config libvmaf "libvmaf >= 2.0.0" libvmaf.h vmaf_init The primary question remains. Is dropping <2.0 support okay, when there's distros out there not having 2.0 yet? smime.p7s Description: S/MIME Cryptographic 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 3/3] libavcodec/vaapi_encode: Add async_depth to vaapi_encoder to increase performance
On 10/31/21 22:14, Chen, Wenbin wrote:
Add async_depth to increase encoder's performance. Reuse encode_fifo as
async buffer. Encoder puts all reordered frame to HW and then check
fifo size. If fifo < async_depth and the top frame is not ready, it will
return AVERROR(EAGAIN) to require more frames.
1080p transcoding (no B frames) with -async_depth=4 can increase 20%
performance on my environment.
The async increases performance but also introduces frame delay.
Signed-off-by: Wenbin Chen
---
libavcodec/vaapi_encode.c | 20 +++-
libavcodec/vaapi_encode.h | 12 ++--
2 files changed, 25 insertions(+), 7 deletions(-)
diff --git a/libavcodec/vaapi_encode.c b/libavcodec/vaapi_encode.c
index db0ae136a1..616fb7c089 100644
--- a/libavcodec/vaapi_encode.c
+++ b/libavcodec/vaapi_encode.c
@@ -1158,7 +1158,8 @@ static int
vaapi_encode_send_frame(AVCodecContext *avctx, AVFrame *frame)
if (ctx->input_order == ctx->decode_delay)
ctx->dts_pts_diff = pic->pts - ctx->first_pts;
if (ctx->output_delay > 0)
-ctx->ts_ring[ctx->input_order % (3 * ctx->output_delay)] =
pic->pts;
+ctx->ts_ring[ctx->input_order %
+(3 * ctx->output_delay + ctx->async_depth)] = pic->pts;
pic->display_order = ctx->input_order;
++ctx->input_order;
@@ -1212,7 +1213,8 @@ int
ff_vaapi_encode_receive_packet(AVCodecContext *avctx, AVPacket *pkt)
return AVERROR(EAGAIN);
}
-while (av_fifo_size(ctx->encode_fifo) <= MAX_PICTURE_REFERENCES *
sizeof(VAAPIEncodePicture *)) {
+while (av_fifo_size(ctx->encode_fifo) <
+MAX_ASYNC_DEPTH * sizeof(VAAPIEncodePicture *)) {
pic = NULL;
err = vaapi_encode_pick_next(avctx, &pic);
if (err < 0)
@@ -1234,6 +1236,14 @@ int
ff_vaapi_encode_receive_packet(AVCodecContext *avctx, AVPacket *pkt)
if (!av_fifo_size(ctx->encode_fifo))
return err;
+if (av_fifo_size(ctx->encode_fifo) < ctx->async_depth *
sizeof(VAAPIEncodePicture *) &&
+!ctx->end_of_stream) {
+av_fifo_generic_peek(ctx->encode_fifo, &pic, sizeof(pic), NULL);
+err = vaapi_encode_wait(avctx, pic, 0);
+if (err < 0)
+return err;
+}
+
av_fifo_generic_read(ctx->encode_fifo, &pic, sizeof(pic), NULL);
ctx->encode_order = pic->encode_order + 1;
@@ -1252,7 +1262,7 @@ int
ff_vaapi_encode_receive_packet(AVCodecContext *avctx, AVPacket *pkt)
pkt->dts = ctx->ts_ring[pic->encode_order] - ctx->dts_pts_diff;
} else {
pkt->dts = ctx->ts_ring[(pic->encode_order - ctx->decode_delay) %
-(3 * ctx->output_delay)];
+(3 * ctx->output_delay + ctx->async_depth)];
}
av_log(avctx, AV_LOG_DEBUG, "Output packet: pts %"PRId64"
dts %"PRId64".\n",
pkt->pts, pkt->dts);
@@ -2566,8 +2576,8 @@ av_cold int ff_vaapi_encode_init(AVCodecContext
*avctx)
}
}
-ctx->encode_fifo = av_fifo_alloc((MAX_PICTURE_REFERENCES + 1) *
- sizeof(VAAPIEncodePicture *));
+ctx->encode_fifo = av_fifo_alloc(MAX_ASYNC_DEPTH *
+ sizeof(VAAPIEncodePicture *));
if (!ctx->encode_fifo)
return AVERROR(ENOMEM);
diff --git a/libavcodec/vaapi_encode.h b/libavcodec/vaapi_encode.h
index 89fe8de466..1bf5d7c337 100644
--- a/libavcodec/vaapi_encode.h
+++ b/libavcodec/vaapi_encode.h
@@ -48,6 +48,7 @@ enum {
MAX_TILE_ROWS = 22,
// A.4.1: table A.6 allows at most 20 tile columns for any level.
MAX_TILE_COLS = 20,
+MAX_ASYNC_DEPTH= 64,
};
extern const AVCodecHWConfigInternal *const
ff_vaapi_encode_hw_configs[];
@@ -298,7 +299,8 @@ typedef struct VAAPIEncodeContext {
// Timestamp handling.
int64_t first_pts;
int64_t dts_pts_diff;
-int64_t ts_ring[MAX_REORDER_DELAY * 3];
+int64_t ts_ring[MAX_REORDER_DELAY * 3 +
+MAX_ASYNC_DEPTH];
// Slice structure.
int slice_block_rows;
@@ -348,6 +350,8 @@ typedef struct VAAPIEncodeContext {
AVFrame *frame;
AVFifoBuffer *encode_fifo;
+
+int async_depth;
} VAAPIEncodeContext;
enum {
@@ -458,7 +462,11 @@ int ff_vaapi_encode_close(AVCodecContext *avctx);
{ "b_depth", \
"Maximum B-frame reference depth", \
OFFSET(common.desired_b_depth), AV_OPT_TYPE_INT, \
- { .i64 = 1 }, 1, INT_MAX, FLAGS }
+ { .i64 = 1 }, 1, INT_MAX, FLAGS }, \
+{ "async_depth", "Maximum processing parallelism. " \
+ "Increase this to improve single channel performance", \
+ OFFSET(common.async_depth), AV_OPT_TYPE_INT, \
+ { .i64 = 4 }, 0, MAX_ASYNC_DEPTH, FLAGS }
#define VAAPI_ENCODE_RC_MODE(name, desc) \
{ #name, desc, 0, AV_OPT_TYPE_CONST, { .i64 = RC_MODE_ ## name }, \
--
2.25.1
ping
I tested this pat
Re: [FFmpeg-devel] [PATCH v14 1/2] avformat/imf: Demuxer
Looks mostly alright, just some style nits. Once they're fixed, lgtm.
On Wednesday, 22 December 2021 4:42:08 AM AEST p...@sandflow.com wrote:
> +
> +int ff_imf_xml_read_uuid(xmlNodePtr element, uint8_t uuid[16])
> +{
> +xmlChar *element_text = NULL;
> +int scanf_ret;
> +int ret = 0;
> +
> +element_text = xmlNodeListGetString(element->doc,
> element->xmlChildrenNode, 1);
> +scanf_ret = sscanf(element_text,
> + FF_IMF_UUID_FORMAT,
> + &uuid[0],
> + &uuid[1],
> + &uuid[2],
> + &uuid[3],
> + &uuid[4],
> + &uuid[5],
> + &uuid[6],
> + &uuid[7],
> + &uuid[8],
> + &uuid[9],
> + &uuid[10],
> + &uuid[11],
> + &uuid[12],
> + &uuid[13],
> + &uuid[14],
> + &uuid[15]);
I'm not the biggest fan of this, but if you're doing the libuuid refactoring
afterwards, then I'm inclined
to let it be.
> +static int fill_base_resource(xmlNodePtr resource_elem, FFIMFBaseResource
> *resource, FFIMFCPL *cpl)
> +{
> +xmlNodePtr element = NULL;
> +int ret = 0;
> +
> +/* read EditRate */
> +if (!(element = ff_imf_xml_get_child_element_by_name(resource_elem,
> "EditRate"))) {
> +resource->edit_rate = cpl->edit_rate;
> +} else if (ret = ff_imf_xml_read_rational(element,
> &resource->edit_rate)) {
When doing inline assignments, use an extra (), e.g.
if ((ret = ff_imf_xml_read_rational(element, &resource->edit_rate)))
> +av_log(NULL, AV_LOG_ERROR, "Invalid EditRate element found in a
> Resource\n");
> +return ret;
> +}
> +
> +/* read EntryPoint */
> +if (element = ff_imf_xml_get_child_element_by_name(resource_elem,
> "EntryPoint")) {
> +if (ret = ff_imf_xml_read_uint32(element, &resource->entry_point)) {
()
> +av_log(NULL, AV_LOG_ERROR, "Invalid EntryPoint element found in
> a Resource\n");
> +return ret;
> +}
> +} else {
> +resource->entry_point = 0;
> +}
> +
> +/* read IntrinsicDuration */
> +if (!(element = ff_imf_xml_get_child_element_by_name(resource_elem,
> "IntrinsicDuration"))) {
> +av_log(NULL, AV_LOG_ERROR, "IntrinsicDuration element missing from
> Resource\n");
> +return AVERROR_INVALIDDATA;
> +}
> +if (ret = ff_imf_xml_read_uint32(element, &resource->duration)) {
()
> +av_log(NULL, AV_LOG_ERROR, "Invalid IntrinsicDuration element found
> in a Resource\n");
> +return ret;
> +}
> +resource->duration -= resource->entry_point;
> +
> +/* read SourceDuration */
> +if (element = ff_imf_xml_get_child_element_by_name(resource_elem,
> "SourceDuration")) {
()
> +if (ret = ff_imf_xml_read_uint32(element, &resource->duration)) {
()
> +av_log(NULL, AV_LOG_ERROR, "SourceDuration element missing from
> Resource\n");
> +return ret;
> +}
> +}
> +
> +/* read RepeatCount */
> +if (element = ff_imf_xml_get_child_element_by_name(resource_elem,
> "RepeatCount"))
()
> +ret = ff_imf_xml_read_uint32(element, &resource->repeat_count);
> +
> +return ret;
> +}
> +
> +static int fill_trackfile_resource(xmlNodePtr tf_resource_elem,
> + FFIMFTrackFileResource *tf_resource,
> + FFIMFCPL *cpl)
> +{
> +xmlNodePtr element = NULL;
> +int ret = 0;
> +
> +if (ret = fill_base_resource(tf_resource_elem, (FFIMFBaseResource
> *)tf_resource, cpl))
()
> +return ret;
> +
> +/* read TrackFileId */
> +if (element = ff_imf_xml_get_child_element_by_name(tf_resource_elem,
> "TrackFileId")) {
> +if (ret = ff_imf_xml_read_uuid(element,
> tf_resource->track_file_uuid)) {
()
> +av_log(NULL, AV_LOG_ERROR, "Invalid TrackFileId element found in
> Resource\n");
> +return ret;
> +}
> +} else {
> +av_log(NULL, AV_LOG_ERROR, "TrackFileId element missing from
> Resource\n");
> +return AVERROR_INVALIDDATA;
> +}
> +
> +return ret;
> +}
> +
> +static int fill_marker_resource(xmlNodePtr marker_resource_elem,
> +FFIMFMarkerResource *marker_resource,
> +FFIMFCPL *cpl)
> +{
> +xmlNodePtr element = NULL;
> +int ret = 0;
> +
> +if (ret = fill_base_resource(marker_resource_elem, (FFIMFBaseResource
> *)marker_resource, cpl))
> +return ret;
> +
> +/* read markers */
> +element = xmlFirstElementChild(marker_resource_elem);
> +while (element) {
> +if (xmlStrcmp(element->name, "Marker") == 0) {
> +void *tmp;
> +
> +if (marker_resource->marker_count == UINT32_MA
Re: [FFmpeg-devel] [PATCH] avcodec/nvenc: add udu_sei option to import user data unregistered SEIs
On Fri, Dec 24, 2021 at 04:52:35PM +0100, Timo Rothenpieler wrote: > On 24.12.2021 15:47, lance.lmw...@gmail.com wrote: > > > > You can tested with libx264 output file, the size of unregistered SEIs(for > > encoding > > setting) will > 503 always, if you don't make the size <= 503, you'll see > > below > > error by trace_eaders filter. > > Invalid SEI message: payload_size too large (xxx 504 bytes). > > > > Note, libavcodec/cbs_sei_syntax_template.c line 262, I print out > > "get_bits_left(rw) / 8". > > > > I think the buffer size is OK, but nvenc sdk truncate the data after > > encoding. > > What exactly are you referring to by nvenc sdk? Are you looking at some > Nvidia sample that does this truncating? I guess it's caused by nv sdk library failed to forward the SEI data output completely. It's not related to the patch, so I tested with small size SEIs and veirfy the option working as expected. > Cause if I try this with ffmpeg right now, encoding straight up fails if a > too large SEI segment is attached, since nvenc runs out of space in the > output buffer. I haven created 5 frame by libx264 and test it, so maybe it's too short to cause encoding failed. I have used bsf filter to add user unregistered before, it haven't such limitation or issue. > ___ > 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". -- Thanks, Limin Wang ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 1/3] avformat/mov: skip moof and sidx before found moov
> On Dec 25, 2021, at 3:09 AM, Derek Buitenhuis > wrote: > > On 12/24/2021 9:58 AM, Zhao Zhili wrote: >> --- >> libavformat/mov.c | 16 >> 1 file changed, 16 insertions(+) > > When do such files exist? They're not valid. File from Steven, and another one from ticket 8883. https://trac.ffmpeg.org/ticket/8883 Put moov after moof doesn't make sense, but I’m not sure they are valid or not. Those files are generated like this: 1. Use hoov as moov to create a fragmented mp4. 2. At last, create a normal moov box. For demuxer which doesn’t know hoov (maybe don’t know moof neither), they are normal files. VLC and quicktime player can playback those samples. FFmpeg only handle the first fragment because it treat hoov as moov. gstreamer has a similar strategy but not the same: > isomp4/mux: add a fragment mode for initial moov with data > > Used by some proprietary software for their fragmented files. > > Adds some support for multi-stream fragmented files > > Flow is as follows. > 1. The first 'fragment' is written as a self-contained fragmented >mdat+moov complete with an edit list and durations, tags, etc. > 2. Subsequent fragments are written with a mdat+moof and each stream is >interleaved as data arrives (currently ignoring the interleave-* >properties). data-offsets in both the traf and the trun ensure >data is read from the correct place on demuxing. Data/chunk offsets >are also kept for writing out the final moov. > 3. On finalisation, the initial moov is invalidated to a hoov and the >size of the first mdat is extended to cover the entire file contents. >Then a moov is written as regularly would in moov-at-end mode (the >default). > > This results in a file that is playable throughout while leaving a > finalised file on completion for players that do not understand > fragmented mp4. https://gitlab.freedesktop.org/gstreamer/gst-plugins-good/-/merge_requests/643 I’m really interested to know where do those hoov files come from, so we don’t fix a case and failed for another case. > > - Derek > ___ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > https://ffmpeg.org/mailman/listinfo/ffmpeg-devel > > To unsubscribe, visit link above, or email > ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe". ___ 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] avcodec/qsvenc_hevc: use AV_OPT_TYPE_BOOL for aud option
From: Limin Wang
Signed-off-by: Limin Wang
---
I haven't tested it for no build environment for qsv.
libavcodec/qsvenc_hevc.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavcodec/qsvenc_hevc.c b/libavcodec/qsvenc_hevc.c
index 5847ea2..08aba30 100644
--- a/libavcodec/qsvenc_hevc.c
+++ b/libavcodec/qsvenc_hevc.c
@@ -250,7 +250,7 @@ static const AVOption options[] = {
{ "tile_cols", "Number of columns for tiled encoding",
OFFSET(qsv.tile_cols),AV_OPT_TYPE_INT, { .i64 = 0 }, 0, UINT16_MAX, VE },
{ "tile_rows", "Number of rows for tiled encoding",
OFFSET(qsv.tile_rows),AV_OPT_TYPE_INT, { .i64 = 0 }, 0, UINT16_MAX, VE },
{ "recovery_point_sei", "Insert recovery point SEI messages",
OFFSET(qsv.recovery_point_sei), AV_OPT_TYPE_INT, { .i64 = -1 },
-1, 1, VE },
-{ "aud", "Insert the Access Unit Delimiter NAL", OFFSET(qsv.aud),
AV_OPT_TYPE_INT, { .i64 = 0 }, 0, 1, VE},
+{ "aud", "Insert the Access Unit Delimiter NAL", OFFSET(qsv.aud),
AV_OPT_TYPE_BOOL, { .i64 = 0 }, 0, 1, VE},
{ NULL },
};
--
1.8.3.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] avcodec/qsvenc_h264: use AV_OPT_TYPE_BOOL for aud, a53cc, cavlc, look_ahead, pic_timing_sei options
From: Limin Wang
Signed-off-by: Limin Wang
---
libavcodec/qsvenc_h264.c | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/libavcodec/qsvenc_h264.c b/libavcodec/qsvenc_h264.c
index 80fe3cc..9f12760 100644
--- a/libavcodec/qsvenc_h264.c
+++ b/libavcodec/qsvenc_h264.c
@@ -103,17 +103,17 @@ static av_cold int qsv_enc_close(AVCodecContext *avctx)
static const AVOption options[] = {
QSV_COMMON_OPTS
-{ "cavlc", "Enable CAVLC",
OFFSET(qsv.cavlc), AV_OPT_TYPE_INT, { .i64 = 0 }, 0, 1, VE
},
+{ "cavlc", "Enable CAVLC",
OFFSET(qsv.cavlc), AV_OPT_TYPE_BOOL, { .i64 = 0 }, 0, 1, VE
},
#if QSV_HAVE_VCM
-{ "vcm", "Use the video conferencing mode ratecontrol",
OFFSET(qsv.vcm), AV_OPT_TYPE_INT, { .i64 = 0 }, 0, 1, VE },
+{ "vcm", "Use the video conferencing mode ratecontrol",
OFFSET(qsv.vcm), AV_OPT_TYPE_BOOL, { .i64 = 0 }, 0, 1, VE },
#endif
{ "idr_interval", "Distance (in I-frames) between IDR frames",
OFFSET(qsv.idr_interval), AV_OPT_TYPE_INT, { .i64 = 0 }, 0, INT_MAX, VE },
-{ "pic_timing_sei","Insert picture timing SEI with pic_struct_syntax
element", OFFSET(qsv.pic_timing_sei), AV_OPT_TYPE_INT, { .i64 = 1 }, 0, 1, VE },
+{ "pic_timing_sei","Insert picture timing SEI with pic_struct_syntax
element", OFFSET(qsv.pic_timing_sei), AV_OPT_TYPE_BOOL, { .i64 = 1 }, 0, 1, VE
},
{ "single_sei_nal_unit","Put all the SEI messages into one NALU",
OFFSET(qsv.single_sei_nal_unit), AV_OPT_TYPE_INT, { .i64 = -1 }, -1,
1, VE },
{ "max_dec_frame_buffering", "Maximum number of frames buffered in the
DPB", OFFSET(qsv.max_dec_frame_buffering), AV_OPT_TYPE_INT, { .i64 = 0 }, 0,
UINT16_MAX, VE },
#if QSV_HAVE_LA
-{ "look_ahead", "Use VBR algorithm with look ahead",
OFFSET(qsv.look_ahead), AV_OPT_TYPE_INT, { .i64 = 0 }, 0, 1, VE },
+{ "look_ahead", "Use VBR algorithm with look ahead",
OFFSET(qsv.look_ahead), AV_OPT_TYPE_BOOL, { .i64 = 0 }, 0, 1, VE },
{ "look_ahead_depth", "Depth of look ahead in number frames",
OFFSET(qsv.look_ahead_depth), AV_OPT_TYPE_INT, { .i64 = 0 }, 0, 100, VE },
#endif
#if QSV_HAVE_LA_DS
@@ -139,9 +139,9 @@ static const AVOption options[] = {
{ "main", NULL, 0, AV_OPT_TYPE_CONST, { .i64 = MFX_PROFILE_AVC_MAIN
}, INT_MIN, INT_MAX, VE, "profile" },
{ "high", NULL, 0, AV_OPT_TYPE_CONST, { .i64 = MFX_PROFILE_AVC_HIGH
}, INT_MIN, INT_MAX, VE, "profile" },
-{ "a53cc" , "Use A53 Closed Captions (if available)", OFFSET(qsv.a53_cc),
AV_OPT_TYPE_INT, {.i64 = 1}, 0, 1, VE},
+{ "a53cc" , "Use A53 Closed Captions (if available)", OFFSET(qsv.a53_cc),
AV_OPT_TYPE_BOOL, {.i64 = 1}, 0, 1, VE},
-{ "aud", "Insert the Access Unit Delimiter NAL", OFFSET(qsv.aud),
AV_OPT_TYPE_INT, { .i64 = 0 }, 0, 1, VE},
+{ "aud", "Insert the Access Unit Delimiter NAL", OFFSET(qsv.aud),
AV_OPT_TYPE_BOOL, { .i64 = 0 }, 0, 1, VE},
#if QSV_HAVE_MF
{ "mfmode", "Multi-Frame Mode", OFFSET(qsv.mfmode), AV_OPT_TYPE_INT, {
.i64 = MFX_MF_AUTO }, MFX_MF_DEFAULT, MFX_MF_AUTO, VE, "mfmode"},
--
1.8.3.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 3/3] libavcodec/vaapi_encode: Add async_depth to vaapi_encoder to increase performance
On Sat, 25 Dec 2021, 02:23 Ed Martin, wrote:
> On 10/31/21 22:14, Chen, Wenbin wrote:
> >> Add async_depth to increase encoder's performance. Reuse encode_fifo as
> >> async buffer. Encoder puts all reordered frame to HW and then check
> >> fifo size. If fifo < async_depth and the top frame is not ready, it will
> >> return AVERROR(EAGAIN) to require more frames.
> >>
> >> 1080p transcoding (no B frames) with -async_depth=4 can increase 20%
> >> performance on my environment.
> >> The async increases performance but also introduces frame delay.
> >>
> >> Signed-off-by: Wenbin Chen
> >> ---
> >> libavcodec/vaapi_encode.c | 20 +++-
> >> libavcodec/vaapi_encode.h | 12 ++--
> >> 2 files changed, 25 insertions(+), 7 deletions(-)
> >>
> >> diff --git a/libavcodec/vaapi_encode.c b/libavcodec/vaapi_encode.c
> >> index db0ae136a1..616fb7c089 100644
> >> --- a/libavcodec/vaapi_encode.c
> >> +++ b/libavcodec/vaapi_encode.c
> >> @@ -1158,7 +1158,8 @@ static int
> >> vaapi_encode_send_frame(AVCodecContext *avctx, AVFrame *frame)
> >> if (ctx->input_order == ctx->decode_delay)
> >> ctx->dts_pts_diff = pic->pts - ctx->first_pts;
> >> if (ctx->output_delay > 0)
> >> -ctx->ts_ring[ctx->input_order % (3 * ctx->output_delay)] =
> pic->pts;
> >> +ctx->ts_ring[ctx->input_order %
> >> +(3 * ctx->output_delay + ctx->async_depth)] =
> pic->pts;
> >>
> >> pic->display_order = ctx->input_order;
> >> ++ctx->input_order;
> >> @@ -1212,7 +1213,8 @@ int
> >> ff_vaapi_encode_receive_packet(AVCodecContext *avctx, AVPacket *pkt)
> >> return AVERROR(EAGAIN);
> >> }
> >>
> >> -while (av_fifo_size(ctx->encode_fifo) <= MAX_PICTURE_REFERENCES *
> >> sizeof(VAAPIEncodePicture *)) {
> >> +while (av_fifo_size(ctx->encode_fifo) <
> >> +MAX_ASYNC_DEPTH * sizeof(VAAPIEncodePicture *)) {
> >> pic = NULL;
> >> err = vaapi_encode_pick_next(avctx, &pic);
> >> if (err < 0)
> >> @@ -1234,6 +1236,14 @@ int
> >> ff_vaapi_encode_receive_packet(AVCodecContext *avctx, AVPacket *pkt)
> >> if (!av_fifo_size(ctx->encode_fifo))
> >> return err;
> >>
> >> +if (av_fifo_size(ctx->encode_fifo) < ctx->async_depth *
> >> sizeof(VAAPIEncodePicture *) &&
> >> +!ctx->end_of_stream) {
> >> +av_fifo_generic_peek(ctx->encode_fifo, &pic, sizeof(pic),
> NULL);
> >> +err = vaapi_encode_wait(avctx, pic, 0);
> >> +if (err < 0)
> >> +return err;
> >> +}
> >> +
> >> av_fifo_generic_read(ctx->encode_fifo, &pic, sizeof(pic), NULL);
> >> ctx->encode_order = pic->encode_order + 1;
> >>
> >> @@ -1252,7 +1262,7 @@ int
> >> ff_vaapi_encode_receive_packet(AVCodecContext *avctx, AVPacket *pkt)
> >> pkt->dts = ctx->ts_ring[pic->encode_order] -
> ctx->dts_pts_diff;
> >> } else {
> >> pkt->dts = ctx->ts_ring[(pic->encode_order -
> ctx->decode_delay) %
> >> -(3 * ctx->output_delay)];
> >> +(3 * ctx->output_delay +
> ctx->async_depth)];
> >> }
> >> av_log(avctx, AV_LOG_DEBUG, "Output packet: pts %"PRId64"
> >> dts %"PRId64".\n",
> >> pkt->pts, pkt->dts);
> >> @@ -2566,8 +2576,8 @@ av_cold int ff_vaapi_encode_init(AVCodecContext
> >> *avctx)
> >> }
> >> }
> >>
> >> -ctx->encode_fifo = av_fifo_alloc((MAX_PICTURE_REFERENCES + 1) *
> >> - sizeof(VAAPIEncodePicture *));
> >> +ctx->encode_fifo = av_fifo_alloc(MAX_ASYNC_DEPTH *
> >> + sizeof(VAAPIEncodePicture *));
> >> if (!ctx->encode_fifo)
> >> return AVERROR(ENOMEM);
> >>
> >> diff --git a/libavcodec/vaapi_encode.h b/libavcodec/vaapi_encode.h
> >> index 89fe8de466..1bf5d7c337 100644
> >> --- a/libavcodec/vaapi_encode.h
> >> +++ b/libavcodec/vaapi_encode.h
> >> @@ -48,6 +48,7 @@ enum {
> >> MAX_TILE_ROWS = 22,
> >> // A.4.1: table A.6 allows at most 20 tile columns for any level.
> >> MAX_TILE_COLS = 20,
> >> +MAX_ASYNC_DEPTH= 64,
> >> };
> >>
> >> extern const AVCodecHWConfigInternal *const
> >> ff_vaapi_encode_hw_configs[];
> >> @@ -298,7 +299,8 @@ typedef struct VAAPIEncodeContext {
> >> // Timestamp handling.
> >> int64_t first_pts;
> >> int64_t dts_pts_diff;
> >> -int64_t ts_ring[MAX_REORDER_DELAY * 3];
> >> +int64_t ts_ring[MAX_REORDER_DELAY * 3 +
> >> +MAX_ASYNC_DEPTH];
> >>
> >> // Slice structure.
> >> int slice_block_rows;
> >> @@ -348,6 +350,8 @@ typedef struct VAAPIEncodeContext {
> >> AVFrame *frame;
> >>
> >> AVFifoBuffer *encode_fifo;
> >> +
> >> +int async_depth;
> >> } VAAPIEncodeContext;
> >>
> >> enum {
> >> @@ -458,7 +462,11 @@ int ff_vaapi_encode_c
[FFmpeg-devel] [PATCH 37/39] avcodec/mpeg12enc: Also inline chroma subsampling
ff_mpeg1_encode_mb() contains two inlined calls to
mpeg1_encode_mb_internal(); these calls are supposed
to inline the properties depending upon the color space
used. Yet inlining vertical chroma subsampling (which
allows to remove complete branches and blocks depending
upon them) has been forgotten.
Signed-off-by: Andreas Rheinhardt
---
Looking at this code makes me wonder whether inlining was ever
worth it here.
libavcodec/mpeg12enc.c | 11 ++-
1 file changed, 6 insertions(+), 5 deletions(-)
diff --git a/libavcodec/mpeg12enc.c b/libavcodec/mpeg12enc.c
index 3692494713..1437ac421c 100644
--- a/libavcodec/mpeg12enc.c
+++ b/libavcodec/mpeg12enc.c
@@ -773,7 +773,8 @@ next_coef:
static av_always_inline void mpeg1_encode_mb_internal(MpegEncContext *s,
int16_t block[8][64],
int motion_x, int
motion_y,
- int mb_block_count)
+ int mb_block_count,
+ int chroma_y_shift)
{
int i, cbp;
const int mb_x = s->mb_x;
@@ -918,7 +919,7 @@ static av_always_inline void
mpeg1_encode_mb_internal(MpegEncContext *s,
s->mv_bits += get_bits_diff(s);
}
if (cbp) {
-if (s->chroma_y_shift) {
+if (chroma_y_shift) {
put_bits(&s->pb,
ff_mpeg12_mbPatTable[cbp][1],
ff_mpeg12_mbPatTable[cbp][0]);
@@ -1025,7 +1026,7 @@ static av_always_inline void
mpeg1_encode_mb_internal(MpegEncContext *s,
}
s->mv_bits += get_bits_diff(s);
if (cbp) {
-if (s->chroma_y_shift) {
+if (chroma_y_shift) {
put_bits(&s->pb,
ff_mpeg12_mbPatTable[cbp][1],
ff_mpeg12_mbPatTable[cbp][0]);
@@ -1052,9 +1053,9 @@ void ff_mpeg1_encode_mb(MpegEncContext *s, int16_t
block[8][64],
int motion_x, int motion_y)
{
if (s->chroma_format == CHROMA_420)
-mpeg1_encode_mb_internal(s, block, motion_x, motion_y, 6);
+mpeg1_encode_mb_internal(s, block, motion_x, motion_y, 6, 1);
else
-mpeg1_encode_mb_internal(s, block, motion_x, motion_y, 8);
+mpeg1_encode_mb_internal(s, block, motion_x, motion_y, 8, 0);
}
static av_cold void mpeg12_encode_init_static(void)
--
2.32.0
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH 38/39] avcodec/mpeg12enc: Partially inline whether codec is MPEG-1
MPEG-1 only supports 4:2:0, so one can optimize away the checks
for whether one encodes MPEG-1 in codepaths that encode 4:2:2.
Signed-off-by: Andreas Rheinhardt
---
libavcodec/mpeg12enc.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/libavcodec/mpeg12enc.c b/libavcodec/mpeg12enc.c
index 1437ac421c..97d497d619 100644
--- a/libavcodec/mpeg12enc.c
+++ b/libavcodec/mpeg12enc.c
@@ -776,6 +776,8 @@ static av_always_inline void
mpeg1_encode_mb_internal(MpegEncContext *s,
int mb_block_count,
int chroma_y_shift)
{
+/* MPEG-1 is always 420. */
+#define IS_MPEG1(s) (chroma_y_shift == 1 && (s)->codec_id ==
AV_CODEC_ID_MPEG1VIDEO)
int i, cbp;
const int mb_x = s->mb_x;
const int mb_y = s->mb_y;
@@ -789,7 +791,7 @@ static av_always_inline void
mpeg1_encode_mb_internal(MpegEncContext *s,
if (cbp == 0 && !first_mb && s->mv_type == MV_TYPE_16X16 &&
(mb_x != s->mb_width - 1 ||
- (mb_y != s->end_mb_y - 1 && s->codec_id == AV_CODEC_ID_MPEG1VIDEO)) &&
+ (mb_y != s->end_mb_y - 1 && IS_MPEG1(s))) &&
((s->pict_type == AV_PICTURE_TYPE_P && (motion_x | motion_y) == 0) ||
(s->pict_type == AV_PICTURE_TYPE_B && s->mv_dir == s->last_mv_dir &&
(((s->mv_dir & MV_DIR_FORWARD)
--
2.32.0
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH 39/39] avcodec/mpeg12enc: Inline constants
Signed-off-by: Andreas Rheinhardt
---
For a long time, ff_mpeg1_init_uni_ac_vlc() has only been used
to create MPEG-1/2 tables and therefore some values (namely
the number of elements) have been inlined; yet nowadays this function
is also used for speedhq whose number of elements differs.
So it seems to me that one should uninline this value
in ff_mpeg1_init_uni_ac_vlc.
libavcodec/mpeg12enc.c | 16
1 file changed, 8 insertions(+), 8 deletions(-)
diff --git a/libavcodec/mpeg12enc.c b/libavcodec/mpeg12enc.c
index 97d497d619..e28aa809d2 100644
--- a/libavcodec/mpeg12enc.c
+++ b/libavcodec/mpeg12enc.c
@@ -621,10 +621,8 @@ static inline void put_mb_modes(MpegEncContext *s, int n,
int bits,
static void mpeg1_encode_motion(MpegEncContext *s, int val, int f_or_b_code)
{
if (val == 0) {
-/* zero vector */
-put_bits(&s->pb,
- ff_mpeg12_mbMotionVectorTable[0][1],
- ff_mpeg12_mbMotionVectorTable[0][0]);
+/* zero vector, corresponds to ff_mpeg12_mbMotionVectorTable[0] */
+put_bits(&s->pb, 1, 0x01);
} else {
int code, sign, bits;
int bit_size = f_or_b_code - 1;
@@ -746,8 +744,10 @@ next_coef:
put_bits(&s->pb, table_vlc[code][1] + 1,
(table_vlc[code][0] << 1) + sign);
} else {
-/* escape seems to be pretty rare <5% so I do not optimize it
*/
-put_bits(&s->pb, table_vlc[111][1], table_vlc[111][0]);
+/* Escape seems to be pretty rare <5% so I do not optimize it;
+ * the following value is the common escape value for both
+ * possible tables (i.e. table_vlc[111]). */
+put_bits(&s->pb, 6, 0x01);
/* escape: only clip in this case */
put_bits(&s->pb, 6, run);
if (s->codec_id == AV_CODEC_ID_MPEG1VIDEO) {
@@ -1097,7 +1097,7 @@ static av_cold void mpeg12_encode_init_static(void)
int len;
if (mv == 0) {
-len = ff_mpeg12_mbMotionVectorTable[0][1];
+len = 1; /* ff_mpeg12_mbMotionVectorTable[0][1] */
} else {
int val, bit_size, code;
@@ -1112,7 +1112,7 @@ static av_cold void mpeg12_encode_init_static(void)
len = ff_mpeg12_mbMotionVectorTable[code][1] +
1 + bit_size;
else
-len = ff_mpeg12_mbMotionVectorTable[16][1] +
+len = 10 /* ff_mpeg12_mbMotionVectorTable[16][1] */ +
2 + bit_size;
}
--
2.32.0
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH v2 34/35] configure: Add new mpegvideodec CONFIG_EXTRA
This allows to remove the spurious dependencies of mpegvideo encoders on error_resilience; some other components that do not use mpegvideo to its fullest turned out to not need it either. Adding a new CONFIG_EXTRA needs a reconfigure to take effect. In order to force this a few unnecessary headers from lavfi/allfilters.c have been removed. Signed-off-by: Andreas Rheinhardt --- Moved mpegutils.c to mpegvideodec. configure| 26 ++ libavcodec/Makefile | 5 +++-- libavcodec/h264dec.c | 2 +- libavcodec/mpegvideo.c | 2 +- libavfilter/allfilters.c | 2 -- 5 files changed, 19 insertions(+), 18 deletions(-) diff --git a/configure b/configure index 23ef2abc9b..f3bdfd2920 100755 --- a/configure +++ b/configure @@ -2476,6 +2476,7 @@ CONFIG_EXTRA=" mpegaudiodsp mpegaudioheader mpegvideo +mpegvideodec mpegvideoenc mss34dsp pixblockdsp @@ -2723,7 +2724,8 @@ me_cmp_select="fdctdsp idctdsp pixblockdsp" mpeg_er_select="error_resilience" mpegaudio_select="mpegaudiodsp mpegaudioheader" mpegaudiodsp_select="dct" -mpegvideo_select="blockdsp h264chroma hpeldsp idctdsp me_cmp mpeg_er videodsp" +mpegvideo_select="blockdsp h264chroma hpeldsp idctdsp me_cmp videodsp" +mpegvideodec_select="mpegvideo mpeg_er" mpegvideoenc_select="aandcttables me_cmp mpegvideo pixblockdsp qpeldsp" vc1dsp_select="h264chroma qpeldsp startcode" rdft_select="fft" @@ -2812,9 +2814,9 @@ fraps_decoder_select="bswapdsp huffman" g2m_decoder_deps="zlib" g2m_decoder_select="blockdsp idctdsp jpegtables" g729_decoder_select="audiodsp" -h261_decoder_select="mpegvideo" +h261_decoder_select="mpegvideodec" h261_encoder_select="mpegvideoenc" -h263_decoder_select="h263_parser h263dsp mpegvideo qpeldsp" +h263_decoder_select="h263_parser h263dsp mpegvideodec qpeldsp" h263_encoder_select="h263dsp mpegvideoenc" h263i_decoder_select="h263_decoder" h263p_decoder_select="h263_decoder" @@ -2836,7 +2838,7 @@ indeo3_decoder_select="hpeldsp" indeo4_decoder_select="ividsp" indeo5_decoder_select="ividsp" interplay_video_decoder_select="hpeldsp" -ipu_decoder_select="mpegvideo" +ipu_decoder_select="mpegvideodec" jpegls_decoder_select="mjpeg_decoder" jv_decoder_select="blockdsp" lagarith_decoder_select="llviddsp" @@ -2866,10 +2868,10 @@ mp3on4_decoder_select="mpegaudio" mp3on4float_decoder_select="mpegaudio" mpc7_decoder_select="bswapdsp mpegaudiodsp" mpc8_decoder_select="mpegaudiodsp" -mpegvideo_decoder_select="mpegvideo" -mpeg1video_decoder_select="mpegvideo" +mpegvideo_decoder_select="mpegvideodec" +mpeg1video_decoder_select="mpegvideodec" mpeg1video_encoder_select="mpegvideoenc h263dsp" -mpeg2video_decoder_select="mpegvideo" +mpeg2video_decoder_select="mpegvideodec" mpeg2video_encoder_select="mpegvideoenc h263dsp" mpeg4_decoder_select="h263_decoder mpeg4video_parser" mpeg4_encoder_select="h263_encoder" @@ -2880,7 +2882,7 @@ msmpeg4v2_decoder_select="h263_decoder" msmpeg4v2_encoder_select="h263_encoder" msmpeg4v3_decoder_select="h263_decoder" msmpeg4v3_encoder_select="h263_encoder" -mss2_decoder_select="mpegvideo qpeldsp vc1_decoder" +mss2_decoder_select="mpegvideodec qpeldsp vc1_decoder" mts2_decoder_select="jpegtables mss34dsp" mv30_decoder_select="aandcttables blockdsp" mvha_decoder_deps="zlib" @@ -2913,8 +2915,8 @@ rv10_decoder_select="h263_decoder" rv10_encoder_select="h263_encoder" rv20_decoder_select="h263_decoder" rv20_encoder_select="h263_encoder" -rv30_decoder_select="golomb h264pred h264qpel mpegvideo rv34dsp" -rv40_decoder_select="golomb h264pred h264qpel mpegvideo rv34dsp" +rv30_decoder_select="golomb h264pred h264qpel mpegvideodec rv34dsp" +rv40_decoder_select="golomb h264pred h264qpel mpegvideodec rv34dsp" screenpresso_decoder_deps="zlib" shorten_decoder_select="bswapdsp" sipr_decoder_select="lsp" @@ -2950,7 +2952,7 @@ txd_decoder_select="texturedsp" utvideo_decoder_select="bswapdsp llviddsp" utvideo_encoder_select="bswapdsp huffman llvidencdsp" vble_decoder_select="llviddsp" -vc1_decoder_select="blockdsp h263_decoder h264qpel intrax8 mpegvideo vc1dsp" +vc1_decoder_select="blockdsp h263_decoder h264qpel intrax8 mpegvideodec vc1dsp" vc1image_decoder_select="vc1_decoder" vorbis_decoder_select="mdct" vorbis_encoder_select="audio_frame_queue mdct" @@ -3246,7 +3248,7 @@ h264_parser_select="atsc_a53 golomb h264dsp h264parse" hevc_parser_select="hevcparse" mpegaudio_parser_select="mpegaudioheader" mpegvideo_parser_select="mpegvideo" -mpeg4video_parser_select="h263dsp mpegvideo qpeldsp" +mpeg4video_parser_select="h263dsp mpegvideodec qpeldsp" vc1_parser_select="vc1dsp" # bitstream_filters diff --git a/libavcodec/Makefile b/libavcodec/Makefile index e7f1f110e7..4b0911e9c8 100644 --- a/libavcodec/Makefile +++ b/libavcodec/Makefile @@ -123,9 +123,10 @@ OBJS-$(CONFIG_MPEGAUDIODSP)+= mpegaudiodsp.o \ mpegaudiodsp_fixed.o \
[FFmpeg-devel] [PATCH v2 35/35] configure: Remove mpegvideo dependency on me_cmp
Forgotten in cf1e0786ed64e69614760bfb4ecd7adbde8e6094. (Both mpegvideodec as well as mpegvideoenc use me_cmp, so this doesn't affect them.) Signed-off-by: Andreas Rheinhardt --- configure | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/configure b/configure index f3bdfd2920..c89f0ae5fb 100755 --- a/configure +++ b/configure @@ -2724,7 +2724,7 @@ me_cmp_select="fdctdsp idctdsp pixblockdsp" mpeg_er_select="error_resilience" mpegaudio_select="mpegaudiodsp mpegaudioheader" mpegaudiodsp_select="dct" -mpegvideo_select="blockdsp h264chroma hpeldsp idctdsp me_cmp videodsp" +mpegvideo_select="blockdsp h264chroma hpeldsp idctdsp videodsp" mpegvideodec_select="mpegvideo mpeg_er" mpegvideoenc_select="aandcttables me_cmp mpegvideo pixblockdsp qpeldsp" vc1dsp_select="h264chroma qpeldsp startcode" -- 2.32.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] avcodec/v4l2_m2m_dec: dequeue frame if input isn't ready
On Tue, 14. Dec 02:12, Cameron Gutman wrote:
> The V4L2M2M API operates asynchronously, so multiple packets can
> be enqueued before getting a batch of frames back. Since it was
> only possible to receive a frame by submitting another packet,
> there wasn't a way to drain those excess output frames from when
> avcodec_receive_frame() returned AVERROR(EAGAIN).
>
> In my testing, this change reduced decode latency of a real-time
> 60 FPS H.264 stream by approximately 10x (200ms -> 20ms) on a
> Raspberry Pi 4.
>
> Signed-off-by: Cameron Gutman
> ---
> libavcodec/v4l2_m2m_dec.c | 8 ++--
> 1 file changed, 6 insertions(+), 2 deletions(-)
>
> diff --git a/libavcodec/v4l2_m2m_dec.c b/libavcodec/v4l2_m2m_dec.c
> index 224eb3d5e7..b0c3d30ac8 100644
> --- a/libavcodec/v4l2_m2m_dec.c
> +++ b/libavcodec/v4l2_m2m_dec.c
> @@ -142,8 +142,12 @@ static int v4l2_receive_frame(AVCodecContext *avctx,
> AVFrame *frame)
>
> if (!s->buf_pkt.size) {
> ret = ff_decode_get_packet(avctx, &s->buf_pkt);
> -if (ret < 0 && ret != AVERROR_EOF)
> -return ret;
> +if (ret < 0) {
> +if (ret == AVERROR(EAGAIN))
> +return ff_v4l2_context_dequeue_frame(capture, frame, 0);
> +else if (ret != AVERROR_EOF)
> +return ret;
> +}
> }
The change lgtm. I tested on Rpi4 and odroid xu4.
Will apply this on Sunday if no one else comments.
Thanks,
--
Andriy
___
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".
