Re: [FFmpeg-devel] [PATCH v1 1/6] avcodec/evc: Set the AV_FRAME_FLAG_KEY flag for a decoded frame when the decoded packet contains a keyframe
> -Original Message-
> From: ffmpeg-devel On Behalf Of James
> Almer
> Sent: środa, 17 kwietnia 2024 14:39
> To: ffmpeg-devel@ffmpeg.org
> Subject: Re: [FFmpeg-devel] [PATCH v1 1/6] avcodec/evc: Set the
> AV_FRAME_FLAG_KEY flag for a decoded frame when the decoded packet
> contains a keyframe
>
> On 4/17/2024 2:22 AM, Dawid Kozinski wrote:
> > Signed-off-by: Dawid Kozinski
> > ---
> > libavcodec/libxevd.c | 5 +
> > 1 file changed, 5 insertions(+)
> >
> > diff --git a/libavcodec/libxevd.c b/libavcodec/libxevd.c index
> > c6c7327e65..e864bd5200 100644
> > --- a/libavcodec/libxevd.c
> > +++ b/libavcodec/libxevd.c
> > @@ -391,6 +391,11 @@ static int libxevd_receive_frame(AVCodecContext
> *avctx, AVFrame *frame)
> > if (stat.read != nalu_size)
> > av_log(avctx, AV_LOG_INFO, "Different reading of
> > bitstream (in:%d, read:%d)\n,", nalu_size, stat.read);
> >
> > +if (stat.stype == XEVD_ST_I) {
> > +frame->pict_type = AV_PICTURE_TYPE_I;
> > +frame->flags |= AV_FRAME_FLAG_KEY;
> > +}
>
> Shouldn't this be inside the stat.fnum >= 0 block below?
You're right. I will move it.
>
> > +
> > // stat.fnum - has negative value if the decoded data is
not frame
> > if (stat.fnum >= 0) {
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://protect2.fireeye.com/v1/url?k=a29889eb-c3139cd2-a29902a4-
> 000babffae10-eb1fef97e1007353&q=1&e=c04d8490-c1e2-4395-83d3-
> 7ea762e16a64&u=https%3A%2F%2Fffmpeg.org%2Fmailman%2Flistinfo%2Fffmp
> eg-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] (no subject)
v2: Fixed build errors in [PATCH 2/2] Subject: [PATCH V2][Loongarch]Optimize aac decode/encode for Loongarch by LSX In-Reply-To: ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH v2 2/2] avcodec/loongarch: add LSX optimization for aac audio encode
Add functions:
ff_abs_pow34_lsx
ff_aac_quantize_bands_lsx
./ffmpeg -f s16le -ac 2 -i ../../1.pcm -c:a aac -f null -
before:37.5x
after:48.1x
---
libavcodec/aacencdsp.h| 3 +
libavcodec/loongarch/Makefile | 2 +
.../loongarch/aacencdsp_init_loongarch.c | 33 +++
libavcodec/loongarch/aacencdsp_loongarch.S| 254 ++
libavcodec/loongarch/aacencdsp_loongarch.h| 35 +++
5 files changed, 327 insertions(+)
create mode 100644 libavcodec/loongarch/aacencdsp_init_loongarch.c
create mode 100644 libavcodec/loongarch/aacencdsp_loongarch.S
create mode 100644 libavcodec/loongarch/aacencdsp_loongarch.h
diff --git a/libavcodec/aacencdsp.h b/libavcodec/aacencdsp.h
index 67836d8cf7..5db27a95a9 100644
--- a/libavcodec/aacencdsp.h
+++ b/libavcodec/aacencdsp.h
@@ -34,6 +34,7 @@ typedef struct AACEncDSPContext {
void ff_aacenc_dsp_init_riscv(AACEncDSPContext *s);
void ff_aacenc_dsp_init_x86(AACEncDSPContext *s);
+void ff_aacenc_dsp_init_loongarch(AACEncDSPContext *s);
static inline void abs_pow34_v(float *out, const float *in, const int size)
{
@@ -66,6 +67,8 @@ static inline void ff_aacenc_dsp_init(AACEncDSPContext *s)
ff_aacenc_dsp_init_riscv(s);
#elif ARCH_X86
ff_aacenc_dsp_init_x86(s);
+#elif ARCH_LOONGARCH64
+ff_aacenc_dsp_init_loongarch(s);
#endif
}
diff --git a/libavcodec/loongarch/Makefile b/libavcodec/loongarch/Makefile
index 07da2964e4..068fd61810 100644
--- a/libavcodec/loongarch/Makefile
+++ b/libavcodec/loongarch/Makefile
@@ -9,6 +9,7 @@ OBJS-$(CONFIG_HPELDSP)+=
loongarch/hpeldsp_init_loongarch.o
OBJS-$(CONFIG_IDCTDSP)+= loongarch/idctdsp_init_loongarch.o
OBJS-$(CONFIG_VIDEODSP) += loongarch/videodsp_init.o
OBJS-$(CONFIG_HEVC_DECODER) += loongarch/hevcdsp_init_loongarch.o
+OBJS-$(CONFIG_AAC_ENCODER)+= loongarch/aacencdsp_init_loongarch.o
LASX-OBJS-$(CONFIG_H264QPEL) += loongarch/h264qpel_lasx.o
LASX-OBJS-$(CONFIG_H264DSP) += loongarch/h264dsp_lasx.o \
loongarch/h264_deblock_lasx.o
@@ -38,3 +39,4 @@ LSX-OBJS-$(CONFIG_H264QPEL) += loongarch/h264qpel.o
\
loongarch/h264qpel_lsx.o
LSX-OBJS-$(CONFIG_H264CHROMA) += loongarch/h264chroma.o
LSX-OBJS-$(CONFIG_H264PRED) += loongarch/h264intrapred.o
+LSX-OBJS-$(CONFIG_AAC_ENCODER)+= loongarch/aacencdsp_loongarch.o
diff --git a/libavcodec/loongarch/aacencdsp_init_loongarch.c
b/libavcodec/loongarch/aacencdsp_init_loongarch.c
new file mode 100644
index 00..5f67a5857d
--- /dev/null
+++ b/libavcodec/loongarch/aacencdsp_init_loongarch.c
@@ -0,0 +1,33 @@
+/*
+ * AAC encoder assembly optimizations
+ * Copyright (c) 2024 Loongson Technology Corporation Limited
+ * Contributed by PengXu
+ *
+ * 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 "aacencdsp_loongarch.h"
+
+av_cold void ff_aacenc_dsp_init_loongarch(AACEncDSPContext *s)
+{
+int cpu_flags = av_get_cpu_flags();
+
+if (have_lsx(cpu_flags)) {
+s->abs_pow34 = ff_abs_pow34_lsx;
+s->quant_bands = ff_aac_quantize_bands_lsx;
+}
+}
\ No newline at end of file
diff --git a/libavcodec/loongarch/aacencdsp_loongarch.S
b/libavcodec/loongarch/aacencdsp_loongarch.S
new file mode 100644
index 00..b80bb98aa9
--- /dev/null
+++ b/libavcodec/loongarch/aacencdsp_loongarch.S
@@ -0,0 +1,254 @@
+/*
+ * Loongarch LASX/LSX optimizeds AAC encoder DSP functions
+ *
+ * Copyright (c) 2024 Loongson Technology Corporation Limited
+ * Contributed by PengXu
+ *
+ * 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 Pu
[FFmpeg-devel] [PATCH v2 1/2] avutil/loongarch: add LSX optimization for aac audio decode
Add functions: vector_fmul_window_lsx butterflies_float_lsx vector_fmul_scalar_lsx ./ffmpeg -i ../../1.aac -f null - before:482x after:523x --- libavutil/float_dsp.c | 2 + libavutil/float_dsp.h | 1 + libavutil/loongarch/Makefile | 5 +- libavutil/loongarch/float_dsp.S | 287 ++ libavutil/loongarch/float_dsp.h | 32 ++ .../loongarch/float_dsp_init_loongarch.c | 35 +++ 6 files changed, 361 insertions(+), 1 deletion(-) create mode 100644 libavutil/loongarch/float_dsp.S create mode 100644 libavutil/loongarch/float_dsp.h create mode 100644 libavutil/loongarch/float_dsp_init_loongarch.c diff --git a/libavutil/float_dsp.c b/libavutil/float_dsp.c index e9fb023466..7128ff3f96 100644 --- a/libavutil/float_dsp.c +++ b/libavutil/float_dsp.c @@ -162,6 +162,8 @@ av_cold AVFloatDSPContext *avpriv_float_dsp_alloc(int bit_exact) ff_float_dsp_init_x86(fdsp); #elif ARCH_MIPS ff_float_dsp_init_mips(fdsp); +#elif ARCH_LOONGARCH64 +ff_float_dsp_init_loongarch(fdsp); #endif return fdsp; } diff --git a/libavutil/float_dsp.h b/libavutil/float_dsp.h index 342a8715c5..679a930eab 100644 --- a/libavutil/float_dsp.h +++ b/libavutil/float_dsp.h @@ -206,6 +206,7 @@ void ff_float_dsp_init_ppc(AVFloatDSPContext *fdsp, int strict); void ff_float_dsp_init_riscv(AVFloatDSPContext *fdsp); void ff_float_dsp_init_x86(AVFloatDSPContext *fdsp); void ff_float_dsp_init_mips(AVFloatDSPContext *fdsp); +void ff_float_dsp_init_loongarch(AVFloatDSPContext *fdsp); /** * Allocate a float DSP context. diff --git a/libavutil/loongarch/Makefile b/libavutil/loongarch/Makefile index 2addd9351c..ae710f0515 100644 --- a/libavutil/loongarch/Makefile +++ b/libavutil/loongarch/Makefile @@ -1 +1,4 @@ -OBJS += loongarch/cpu.o +OBJS += loongarch/cpu.o \ + loongarch/float_dsp_init_loongarch.o + +LSX-OBJS += loongarch/float_dsp.o diff --git a/libavutil/loongarch/float_dsp.S b/libavutil/loongarch/float_dsp.S new file mode 100644 index 00..5073c8424f --- /dev/null +++ b/libavutil/loongarch/float_dsp.S @@ -0,0 +1,287 @@ +/* + * Loongarch LASX/LSX optimizeds dsp + * + * Copyright (c) 2024 Loongson Technology Corporation Limited + * Contributed by PengXu + * + * 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/loongarch/loongson_asm.S" + + +/* void vector_fmul_window(float *dst, const float *src0, + const float *src1, const float *win, int len) */ +function vector_fmul_window_lsx +addi.d sp, sp, -8 +st.d$r23, sp, 0 + +movet4, a0 +movet5, a1 +movet6, a2 +movet7, a3 +movet8, a4 +slli.d t8, t8, 2 + +add.d t4, t4, t8 +add.d t7, t7, t8 +add.d t5, t5, t8 + +add.d a6, $r0,t8 +addi.d a7, t8, -4 + +movea5, $r0 +srai.d t0, a4, 2 +beq a5, t0, .VFW02 + +.VFW01: +sub.d t1, t5, a6 +addi.d t2, a7, -12 +vld vr1,t1, 0x00 //s0 +vldxvr2,a2, t2//s1 + +sub.d t1, t7, a6 +vld vr3,t1, 0x00 //wi +vldxvr4,t7, t2//wj + +vpermi.wvr2,vr2,0x1b +vpermi.wvr4,vr4,0x1b + +vfmul.s vr5,vr2,vr3 +vfmsub.svr5,vr1,vr4,vr5 //dsti + +vfmul.s vr6,vr2,vr4 +vfmadd.svr6,vr1,vr3,vr6 //dstj + +vpermi.wvr6,vr6,0x1b + +sub.d t1, t4, a6 +vst vr5,t1, 0x00 +vstxvr6,t4, t2 + +addi.d a6, a6, -16 +addi.d a7, a7, -16 + +addi.d a5, a5, 1 +blt a5, t0, .VFW01 + +.VFW02: +andit0, a4, 2 +beq $r0,t0, .VFW03 + +sub.d t0, t5, a6 +addi.d t1, a7, -4 +add.d t1, t5, t1 + +sub.d t2, t7, a6 +addi.d t3, a7, -4 +
Re: [FFmpeg-devel] [RFC] 5 year plan & Inovation
On date Wednesday 2024-04-17 17:24:02 +0100, Andrew Sayers wrote:
> On 17/04/2024 14:58, Michael Niedermayer wrote:
[...]
> I've occasionally tried getting into ffmpeg for over a decade now, and have
> lurked here for the past few months as I put in the effort to grok it.
> On behalf of people who could contribute but don't, I'd like to suggest
> ffmpeg focus on *learnability*.
>
> Whenever I've tried to learn ffmpeg, I've always been rebuffed by
> documentation that seems needlessly hard to use. I understand some of
> these reflect deeper issues - for example there's a reason the words
> "ffmpeg" and "libav" are used ambiguously, even though it makes it
> hard to differentiate between the library and the command-line tool.
> But other issues seem like quick wins - for example I've lost count of
> all the times I typed two functions into Google, spent hours trying to
> make them work together, then finally realised I was looking at the
> documentation for 3.0 in one tab and 5.0 in the other. Surely you can
> just add a line to the top of the documentation like "click here to see
> the trunk version of this file"?
Functions are documented in doxygen, so they depend on the major.minor
version, while you seem to refer to the FFmpeg version. Also on the
website we usually only have the latest mainline documentation, so I
don't understand how can you have different versions in different tabs
(unless you didn't update that tab since months/years).
If you mean that we should ship documentatation for the latest
supported releases, in addition to latest mainline, I tend to agree.
> Here's a small example to demonstrate the larger issue -
> what does it mean for something to be a "context"?
> When I started learning how to write ffmpeg code, I read through the
> docs and saw various things calling themselves "context" structs, but
> never found a link to explain what that meant. If I was a young
> developer, I would probably have just assumed it was standard
> programming jargon I was too dumb to know, and walked away to find
> something more my speed. But I'm old and stubborn and have nothing
> better to do right now, so I kept going...
>
> I tried to learn by going through the examples, but the nearest thing
> to an explanation was e.g. `transcode.c` making up a new type and
> calling it a `FilteringContext`. I ignored the AVClass documentation
> for a long time because the name made me think it was some kind of
> GObject-style C-with-classes thing. It was only when I noticed that
> it says it describes "the class of an AVClass context structure" that
> I realised what I was looking at. And it was only when I convinced
> myself that the documentation for AVOptions was using
> "AVOptions-enabled struct" to mean the same thing as "AVClass context
> structure" that I felt able to disregard the `FilteringContext`. So
> my current opinion is that "AVOptions-enabled struct", "AVClass
> context structure" and "context structure" are different terms for the
> same thing - but now I've said that publicly, I will no doubt find an
> "SwrClass context structure" or something tomorrow.
In general, a "context" in the FFmpeg jargon is usually a data
structure providing the context/state/configuration for a given
operation, which can be muxing, demuxing, decoding, encoding,
filtering etc.
You need to fill the "context" with the configuration parameters and
with the data needed for the specific operation.
In general, when setting up a context, you also want some facilities
to avoid to repeat logic again and again:
- you want to provide means to send log messages
- you want an interface to query, set, and get options
- you want a "private" internal context, with options/parameters
specific for a particular instance of a generic context. For example
you might want to set specific options which only apply to a given
encoder (these are so-called "private" options)
This is done through the AVClass structure, which being generic is
used in various parts of FFmpeg.
The AVOption interface wass added later, so depending on your usage,
you might be directly setting a field in the context of set an option
through the AVOption programming interface.
Currently this is the documentation for AVCodecContext:
/**
* main external API structure.
* New fields can be added to the end with minor version bumps.
* Removal, reordering and changes to existing fields require a major
* version bump.
* You can use AVOptions (av_opt* / av_set/get*()) to access these fields from
user
* applications.
* The name string for AVOptions options matches the associated command line
* parameter name and can be found in libavcodec/options_table.h
* The AVOption/command line parameter names differ in some cases from the C
* structure field names for historic reasons or brevity.
* sizeof(AVCodecContext) must not be used outside libav*.
*/
typedef struct AVCodecContext {
I agree this might be improved/updated, "main external API st
[FFmpeg-devel] [PATCH v1] lavc/qsvdec: Use FFmpeg default 1/25 framerate if can't derive it from bitstream
From: Fei Wang
Fix error:
$ ffmpeg -hwaccel qsv -i input.h265 -f null -
...
[null @ 0x55da1a629200] Application provided invalid, non monotonically
increasing dts to muxer in stream 0: 3 >= 3
Signed-off-by: Fei Wang
---
libavcodec/qsvdec.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/libavcodec/qsvdec.c b/libavcodec/qsvdec.c
index fd9267c6f4..218ca59e08 100644
--- a/libavcodec/qsvdec.c
+++ b/libavcodec/qsvdec.c
@@ -440,6 +440,11 @@ static int qsv_decode_header(AVCodecContext *avctx,
QSVContext *q,
param->ExtParam= q->ext_buffers;
param->NumExtParam = q->nb_ext_buffers;
+if (param->mfx.FrameInfo.FrameRateExtN == 0 ||
param->mfx.FrameInfo.FrameRateExtD == 0) {
+param->mfx.FrameInfo.FrameRateExtN = 25;
+param->mfx.FrameInfo.FrameRateExtD = 1;
+}
+
#if QSV_VERSION_ATLEAST(1, 34)
if (QSV_RUNTIME_VERSION_ATLEAST(q->ver, 1, 34) && avctx->codec_id ==
AV_CODEC_ID_AV1)
param->mfx.FilmGrain = (avctx->export_side_data &
AV_CODEC_EXPORT_DATA_FILM_GRAIN) ? 0 : param->mfx.FilmGrain;
--
2.25.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [RFC] 5 year plan & Inovation
On date Wednesday 2024-04-17 19:21:39 -0700, Aidan wrote: > The best option is to figure stuff out. [...] > I use FFmpeg to download HLS streams from the internet or convert files > like probably most people do. FFmpeg is the ultimate way of doing this > because there is no better option. > > But there are issues: [...] > I submitted a patch for a TTML decoder because I thought it would be great. > It was completely ignored. Please ping the patch or send a new one. > If my patch was seriously bad, then fine. But seriously *no one cared*. I think contribution management is a serious issue here. What happens when you send a patch is that if you're lucky someone will be interested and put some effort to review and eventually get it pushed, which depending on several factors might require several interactions. Sometimes contributors are side-tracked or frustrated and the review process is interrupted. Sometimes the reviewer won't reply, and the review also might be stuck (in this case you might want to ping the patch). Sometimes there is no qualified or interested developer around, or maybe those ones are busy with other things (and it's easy to miss a patch, especially if you don't check emails since a few days and you got hundreds of backlog emails). In general, this is done on a best effort basis (read as: most developers are volunteers and they might have job/families/stuff to tend to), there is no guarantee that a patch might be reviewed in a timely fashion. This is not a problem specific with FFmpeg, but in general with most FLOSS projects. Probably we should find ways to fund such activites, so that a developer can spend more time on reviewing work, but this comes with other risks/issues (since managing money is also complex of potential tensions in a mostly volunteering-based project). It's also very difficult to track the sent patches, and that's why having a Pull-Request process a-la github has been proposed several times; we cannot switch to github for several reasons (licensing and affilitation issues with platform owner) and handling your own gitlab is costly and we lack volunteers at the moment. We are using patchwork to mitigate the tracking issue: https://patchwork.ffmpeg.org/project/ffmpeg/list/ but that's not really providing an effective workflow. Personally I find the status tracking confusing, e.g.: https://patchwork.ffmpeg.org/project/ffmpeg/list/?series=&submitter=&state=&q=TTML&archive=both&delegate= I cannot easily figure out what was integrated and what not. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH v3 1/2] lavc/vaapi_encode_h265: Map HEVC AV REXT profile to VA REXT profile
On Tue, 2024-04-16 at 04:57 +, Wang, Fei W wrote:
> On Mon, 2024-04-15 at 23:07 +0100, Mark Thompson wrote:
> > On 15/04/2024 02:21, Xiang, Haihao wrote:
> > > On Ma, 2024-03-18 at 12:21 +0800,
> > > fei.w.wang-at-intel@ffmpeg.org wrote:
> > > > From: Fei Wang
> > > >
> > > > There is no Main8/10 profile defined in HEVC REXT profiles. Use
> > > > Main12
> > > > which is compatible with 8/10bit.
> > > >
> > > > Signed-off-by: Fei Wang
> > > > ---
> > > > libavcodec/vaapi_encode_h265.c | 4 ++--
> > > > 1 file changed, 2 insertions(+), 2 deletions(-)
> > > >
> > > > diff --git a/libavcodec/vaapi_encode_h265.c
> > > > b/libavcodec/vaapi_encode_h265.c
> > > > index c4aabbf5ed..43755e2188 100644
> > > > --- a/libavcodec/vaapi_encode_h265.c
> > > > +++ b/libavcodec/vaapi_encode_h265.c
> > > > @@ -1305,12 +1305,12 @@ static av_cold int
> > > > vaapi_encode_h265_configure(AVCodecContext *avctx)
> > > >
> > > > static const VAAPIEncodeProfile vaapi_encode_h265_profiles[] =
> > > > {
> > > > { AV_PROFILE_HEVC_MAIN, 8, 3, 1, 1,
> > > > VAProfileHEVCMain },
> > > > -{ AV_PROFILE_HEVC_REXT, 8, 3, 1, 1,
> > > > VAProfileHEVCMain },
> > > > #if VA_CHECK_VERSION(0, 37, 0)
> > > > { AV_PROFILE_HEVC_MAIN_10, 10, 3, 1, 1,
> > > > VAProfileHEVCMain10 },
> > > > -{ AV_PROFILE_HEVC_REXT,10, 3, 1, 1,
> > > > VAProfileHEVCMain10 },
> > > > #endif
> > > > #if VA_CHECK_VERSION(1, 2, 0)
> > > > +{ AV_PROFILE_HEVC_REXT, 8, 3, 1, 1,
> > > > VAProfileHEVCMain12
> > > > },
> > > > +{ AV_PROFILE_HEVC_REXT,10, 3, 1, 1,
> > > > VAProfileHEVCMain12
> > > > },
> > > > { AV_PROFILE_HEVC_REXT,12, 3, 1, 1,
> > > > VAProfileHEVCMain12
> > > > },
> > > > { AV_PROFILE_HEVC_REXT, 8, 3, 1, 0,
> > > > VAProfileHEVCMain422_10 },
> > > > { AV_PROFILE_HEVC_REXT,10, 3, 1, 0,
> > > > VAProfileHEVCMain422_10 },
> > >
> > > Patchset LGTM, I'll push it if there are no comments.
> >
> > Why is this change helpful?
>
> Together with 2/2 fix on the hw support VAAPI main12 decode and
> encode:
>
> $ ffmpeg -hwaccel vaapi -f lavfi -i testsrc -vf
> 'format=nv12,hwupload'
> -c:v hevc_vaapi -profile:v rext -vframes 30 -y out.mp4
>
> $ ffmpeg -hwaccel vaapi -i out.mp4 -f null -
> ...
> [hevc @ 0x55b4fda0a780] HEVC profile is not found.
> [hevc @ 0x55b4fda0a780] No support for codec hevc profile 4.
> [hevc @ 0x55b4fda0a780] Failed setup for format vaapi: hwaccel
> initialisation returned error.
>
> Same for p010le as input of encoder.
Hi
Any further comments on this patchset?
Thanks
Fei
>
> Thanks
> Fei
> > We don't use the rext features allowed in these cases (unlike in
> > the
> > decoder where we have to support them), so Main / Main 10 encoders
> > will be able to produce a compatible stream without pointlessly
> > requiring Main 12 support which many devices do not have.
> >
> > Thanks,
> >
> > - Mark
> > ___
> > 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] [PATCH v2 1/6] avcodec/evc: Set the AV_FRAME_FLAG_KEY flag for a decoded frame when the decoded packet contains a keyframe
Signed-off-by: Dawid Kozinski
---
libavcodec/libxevd.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/libavcodec/libxevd.c b/libavcodec/libxevd.c
index c6c7327e65..e864bd5200 100644
--- a/libavcodec/libxevd.c
+++ b/libavcodec/libxevd.c
@@ -391,6 +391,11 @@ static int libxevd_receive_frame(AVCodecContext *avctx,
AVFrame *frame)
if (stat.read != nalu_size)
av_log(avctx, AV_LOG_INFO, "Different reading of bitstream
(in:%d, read:%d)\n,", nalu_size, stat.read);
+if (stat.stype == XEVD_ST_I) {
+frame->pict_type = AV_PICTURE_TYPE_I;
+frame->flags |= AV_FRAME_FLAG_KEY;
+}
+
// stat.fnum - has negative value if the decoded data is not frame
if (stat.fnum >= 0) {
--
2.25.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH v2 2/6] avformat/nut: Added EVC codec tag to the list of supported codec_id-codec_tag pairs for NUT muxer
Signed-off-by: Dawid Kozinski
---
libavformat/nut.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/libavformat/nut.c b/libavformat/nut.c
index 9692336ece..8c536719b1 100644
--- a/libavformat/nut.c
+++ b/libavformat/nut.c
@@ -47,6 +47,7 @@ const AVCodecTag ff_nut_video_tags[] = {
{ AV_CODEC_ID_VP9, MKTAG('V', 'P', '9', '0') },
{ AV_CODEC_ID_HEVC, MKTAG('H', 'E', 'V', 'C') },
{ AV_CODEC_ID_CPIA, MKTAG('C', 'P', 'i', 'A') },
+{ AV_CODEC_ID_EVC, MKTAG('e', 'v', 'c', '1') },
{ AV_CODEC_ID_RAWVIDEO, MKTAG('R', 'G', 'B', 15 ) },
{ AV_CODEC_ID_RAWVIDEO, MKTAG('B', 'G', 'R', 15 ) },
{ AV_CODEC_ID_RAWVIDEO, MKTAG('R', 'G', 'B', 16 ) },
--
2.25.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH v2 3/6] avcodec/bitstream_filters: Declaration of the ff_evc_frame_merge_bsf variable has been moved to the appropriate following the alphabetical order
Signed-off-by: Dawid Kozinski --- libavcodec/bitstream_filters.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/libavcodec/bitstream_filters.c b/libavcodec/bitstream_filters.c index 12860c332b..138246c50e 100644 --- a/libavcodec/bitstream_filters.c +++ b/libavcodec/bitstream_filters.c @@ -34,6 +34,7 @@ extern const FFBitStreamFilter ff_dca_core_bsf; extern const FFBitStreamFilter ff_dts2pts_bsf; extern const FFBitStreamFilter ff_dv_error_marker_bsf; extern const FFBitStreamFilter ff_eac3_core_bsf; +extern const FFBitStreamFilter ff_evc_frame_merge_bsf; extern const FFBitStreamFilter ff_extract_extradata_bsf; extern const FFBitStreamFilter ff_filter_units_bsf; extern const FFBitStreamFilter ff_h264_metadata_bsf; @@ -67,7 +68,6 @@ extern const FFBitStreamFilter ff_vp9_superframe_bsf; extern const FFBitStreamFilter ff_vp9_superframe_split_bsf; extern const FFBitStreamFilter ff_vvc_metadata_bsf; extern const FFBitStreamFilter ff_vvc_mp4toannexb_bsf; -extern const FFBitStreamFilter ff_evc_frame_merge_bsf; #include "libavcodec/bsf_list.c" -- 2.25.1 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH v2 4/6] avformat/avi: Added EVC codec tag to the list of supported codec_id-codec_tag pairs for AVI muxer
Signed-off-by: Dawid Kozinski
---
libavformat/riff.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/libavformat/riff.c b/libavformat/riff.c
index 157976583c..306dc3b47a 100644
--- a/libavformat/riff.c
+++ b/libavformat/riff.c
@@ -506,6 +506,7 @@ const AVCodecTag ff_codec_bmp_tags[] = {
{ AV_CODEC_ID_RTV1, MKTAG('R', 'T', 'V', '1') },
{ AV_CODEC_ID_VMIX, MKTAG('V', 'M', 'X', '1') },
{ AV_CODEC_ID_LEAD, MKTAG('L', 'E', 'A', 'D') },
+{ AV_CODEC_ID_EVC, MKTAG('e', 'v', 'c', '1') },
{ AV_CODEC_ID_NONE, 0 }
};
--
2.25.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH v2 5/6] avcodec/evc: Reference to ISO_IEC_23094-1-2020 document section for EVC_MAX_APS_COUNT enum has been fixed
Signed-off-by: Dawid Kozinski
---
libavcodec/evc.h | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/libavcodec/evc.h b/libavcodec/evc.h
index e493455a42..d68dc74997 100644
--- a/libavcodec/evc.h
+++ b/libavcodec/evc.h
@@ -106,15 +106,15 @@ enum EVCSliceType {
};
enum {
-// 7.4.3.2: aps_video_parameter_set_id is u(4).
-EVC_MAX_APS_COUNT = 32,
-
// 7.4.3.1: sps_seq_parameter_set_id is in [0, 15].
EVC_MAX_SPS_COUNT = 16,
// 7.4.3.2: pps_pic_parameter_set_id is in [0, 63].
EVC_MAX_PPS_COUNT = 64,
+// 7.4.3.3: adaptional_parameter_set_id is in [0, 31].
+EVC_MAX_APS_COUNT = 32,
+
// 7.4.5: slice header slice_pic_parameter_set_id in [0, 63]
EVC_MAX_SH_COUNT = 64,
--
2.25.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH v2 6/6] avformat/evc: Small fixes in documentation
Signed-off-by: Dawid Kozinski --- libavformat/evc.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/libavformat/evc.c b/libavformat/evc.c index fabccb054c..2f4c74fe51 100644 --- a/libavformat/evc.c +++ b/libavformat/evc.c @@ -233,7 +233,7 @@ static int evcc_write(AVIOContext *pb, EVCDecoderConfigurationRecord *evcc) /* unsigned int(8) profile_idc */ avio_w8(pb, evcc->profile_idc); -/* unsigned int(8) profile_idc */ +/* unsigned int(8) level_idc */ avio_w8(pb, evcc->level_idc); /* unsigned int(32) toolset_idc_h */ @@ -254,7 +254,7 @@ static int evcc_write(AVIOContext *pb, EVCDecoderConfigurationRecord *evcc) /* unsigned int(16) pic_width_in_luma_samples; */ avio_wb16(pb, evcc->pic_width_in_luma_samples); -/* unsigned int(16) pic_width_in_luma_samples; */ +/* unsigned int(16) pic_height_in_luma_samples; */ avio_wb16(pb, evcc->pic_height_in_luma_samples); /* -- 2.25.1 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [RFC] 5 year plan & Inovation
On date Wednesday 2024-04-17 15:58:32 +0200, Michael Niedermayer wrote: > Hi all > > The pace of inovation in FFmpeg has been slowing down. > Most work is concentarted nowadays on code refactoring, and adding > support for new codecs and formats. > > Should we > * make a list of longer term goals > * vote on them > * and then together work towards implementing them > ? > > (The idea here is to increase the success of larger efforts > than adding codecs and refactoring code) > It would then also not be possible for individuals to object > to a previously agreed goal. > And it would add ideas for which we can try to get funding/grants for > > (larger scale changes need consensus first that we as a whole want > them before we would be able to ask for funding/grants for them) > > Some ideas and why they would help FFmpeg: > [...] > * client side / in browser support > (expand towards webapps, webpages using ffmpeg client side in the browser) > bring in more users and developers, and it will be costly for us > if we let others take this area as its important and significant There are already several projects on github, the most prominent one: https://github.com/ffmpegwasm/ffmpeg.wasm/ In general it would be useful to provide libav* bindings to other languages, for example: https://github.com/PyAV-Org/PyAV https://github.com/zmwangx/rust-ffmpeg Not sure these should be really moved to FFmpeg though. One option I'm currenly exploring is having a python filter enabling to specify a custom filter implemented in python (needed for custom ad-hoc logic you don't really want to implement in C since it's not generic enough) and to enable using python modules when effiency is not an 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".
[FFmpeg-devel] [PATCH] avformat/http: return error when error occurs during gzip inflating
when there is error in http gizp data, return 0 will cause endless
and meanningless loop in retry_transfer_wrapper function.
---
libavformat/http.c | 7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/libavformat/http.c b/libavformat/http.c
index ed20359552..6e712383c1 100644
--- a/libavformat/http.c
+++ b/libavformat/http.c
@@ -1657,10 +1657,11 @@ static int http_buf_read_compressed(URLContext *h,
uint8_t *buf, int size)
s->inflate_stream.next_out = buf;
ret = inflate(&s->inflate_stream, Z_SYNC_FLUSH);
-if (ret != Z_OK && ret != Z_STREAM_END)
-av_log(h, AV_LOG_WARNING, "inflate return value: %d, %s\n",
+if (ret != Z_OK && ret != Z_STREAM_END) {
+ av_log(h, AV_LOG_WARNING, "inflate return value: %d, %s\n",
ret, s->inflate_stream.msg);
-
+ return AVERROR(EIO);
+}
return size - s->inflate_stream.avail_out;
}
#endif /* CONFIG_ZLIB */
--
2.39.3 (Apple Git-145)
___
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 v8 01/15] avcodec/vaapi_encode: introduce a base layer for vaapi encode
From: Tong Wu
Since VAAPI and future D3D12VA implementation may share some common parameters,
a base layer encode context is introduced as vaapi context's base.
Signed-off-by: Tong Wu
---
libavcodec/hw_base_encode.h | 52 +
libavcodec/vaapi_encode.h | 36 -
2 files changed, 57 insertions(+), 31 deletions(-)
create mode 100644 libavcodec/hw_base_encode.h
diff --git a/libavcodec/hw_base_encode.h b/libavcodec/hw_base_encode.h
new file mode 100644
index 00..3d1974bba3
--- /dev/null
+++ b/libavcodec/hw_base_encode.h
@@ -0,0 +1,52 @@
+/*
+ * 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
+ */
+
+#ifndef AVCODEC_HW_BASE_ENCODE_H
+#define AVCODEC_HW_BASE_ENCODE_H
+
+#define MAX_DPB_SIZE 16
+#define MAX_PICTURE_REFERENCES 2
+#define MAX_REORDER_DELAY 16
+#define MAX_ASYNC_DEPTH 64
+#define MAX_REFERENCE_LIST_NUM 2
+
+enum {
+PICTURE_TYPE_IDR = 0,
+PICTURE_TYPE_I = 1,
+PICTURE_TYPE_P = 2,
+PICTURE_TYPE_B = 3,
+};
+
+enum {
+// Codec supports controlling the subdivision of pictures into slices.
+FLAG_SLICE_CONTROL = 1 << 0,
+// Codec only supports constant quality (no rate control).
+FLAG_CONSTANT_QUALITY_ONLY = 1 << 1,
+// Codec is intra-only.
+FLAG_INTRA_ONLY= 1 << 2,
+// Codec supports B-pictures.
+FLAG_B_PICTURES= 1 << 3,
+// Codec supports referencing B-pictures.
+FLAG_B_PICTURE_REFERENCES = 1 << 4,
+// Codec supports non-IDR key pictures (that is, key pictures do
+// not necessarily empty the DPB).
+FLAG_NON_IDR_KEY_PICTURES = 1 << 5,
+};
+
+#endif /* AVCODEC_HW_BASE_ENCODE_H */
+
diff --git a/libavcodec/vaapi_encode.h b/libavcodec/vaapi_encode.h
index 0eed9691ca..5e18f374a7 100644
--- a/libavcodec/vaapi_encode.h
+++ b/libavcodec/vaapi_encode.h
@@ -33,34 +33,27 @@
#include "avcodec.h"
#include "hwconfig.h"
+#include "hw_base_encode.h"
struct VAAPIEncodeType;
struct VAAPIEncodePicture;
+// Codec output packet without timestamp delay, which means the
+// output packet has same PTS and DTS.
+#define FLAG_TIMESTAMP_NO_DELAY 1 << 6
+
enum {
MAX_CONFIG_ATTRIBUTES = 4,
MAX_GLOBAL_PARAMS = 4,
-MAX_DPB_SIZE = 16,
-MAX_PICTURE_REFERENCES = 2,
-MAX_REORDER_DELAY = 16,
MAX_PARAM_BUFFER_SIZE = 1024,
// A.4.1: table A.6 allows at most 22 tile rows for any level.
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,
-MAX_REFERENCE_LIST_NUM = 2,
};
extern const AVCodecHWConfigInternal *const ff_vaapi_encode_hw_configs[];
-enum {
-PICTURE_TYPE_IDR = 0,
-PICTURE_TYPE_I = 1,
-PICTURE_TYPE_P = 2,
-PICTURE_TYPE_B = 3,
-};
-
typedef struct VAAPIEncodeSlice {
int index;
int row_start;
@@ -397,25 +390,6 @@ typedef struct VAAPIEncodeContext {
AVPacket*tail_pkt;
} VAAPIEncodeContext;
-enum {
-// Codec supports controlling the subdivision of pictures into slices.
-FLAG_SLICE_CONTROL = 1 << 0,
-// Codec only supports constant quality (no rate control).
-FLAG_CONSTANT_QUALITY_ONLY = 1 << 1,
-// Codec is intra-only.
-FLAG_INTRA_ONLY= 1 << 2,
-// Codec supports B-pictures.
-FLAG_B_PICTURES= 1 << 3,
-// Codec supports referencing B-pictures.
-FLAG_B_PICTURE_REFERENCES = 1 << 4,
-// Codec supports non-IDR key pictures (that is, key pictures do
-// not necessarily empty the DPB).
-FLAG_NON_IDR_KEY_PICTURES = 1 << 5,
-// Codec output packet without timestamp delay, which means the
-// output packet has same PTS and DTS.
-FLAG_TIMESTAMP_NO_DELAY= 1 << 6,
-};
-
typedef struct VAAPIEncodeType {
// List of supported profiles and corresponding VAAPI profiles.
// (Must end with AV_PROFILE_UNKNOWN.)
--
2.41.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] [PATCH v8 02/15] avcodec/vaapi_encode: add async_depth to common options
From: Tong Wu
Signed-off-by: Tong Wu
---
libavcodec/hw_base_encode.h | 14 +-
libavcodec/vaapi_encode.c | 13 -
libavcodec/vaapi_encode.h | 10 ++
libavcodec/vaapi_encode_av1.c | 1 +
libavcodec/vaapi_encode_h264.c | 1 +
libavcodec/vaapi_encode_h265.c | 1 +
libavcodec/vaapi_encode_mjpeg.c | 1 +
libavcodec/vaapi_encode_mpeg2.c | 1 +
libavcodec/vaapi_encode_vp8.c | 1 +
libavcodec/vaapi_encode_vp9.c | 1 +
10 files changed, 30 insertions(+), 14 deletions(-)
diff --git a/libavcodec/hw_base_encode.h b/libavcodec/hw_base_encode.h
index 3d1974bba3..5272f2836d 100644
--- a/libavcodec/hw_base_encode.h
+++ b/libavcodec/hw_base_encode.h
@@ -48,5 +48,17 @@ enum {
FLAG_NON_IDR_KEY_PICTURES = 1 << 5,
};
-#endif /* AVCODEC_HW_BASE_ENCODE_H */
+typedef struct HWBaseEncodeContext {
+const AVClass *class;
+
+// Max number of frame buffered in encoder.
+int async_depth;
+} HWBaseEncodeContext;
+#define HW_BASE_ENCODE_COMMON_OPTIONS \
+{ "async_depth", "Maximum processing parallelism. " \
+ "Increase this to improve single channel performance.", \
+ OFFSET(common.base.async_depth), AV_OPT_TYPE_INT, \
+ { .i64 = 2 }, 1, MAX_ASYNC_DEPTH, FLAGS }
+
+#endif /* AVCODEC_HW_BASE_ENCODE_H */
diff --git a/libavcodec/vaapi_encode.c b/libavcodec/vaapi_encode.c
index f54b2579ec..9373512417 100644
--- a/libavcodec/vaapi_encode.c
+++ b/libavcodec/vaapi_encode.c
@@ -669,7 +669,8 @@ static int vaapi_encode_set_output_property(AVCodecContext
*avctx,
VAAPIEncodePicture *pic,
AVPacket *pkt)
{
-VAAPIEncodeContext *ctx = avctx->priv_data;
+HWBaseEncodeContext *base_ctx = avctx->priv_data;
+VAAPIEncodeContext *ctx = avctx->priv_data;
if (pic->type == PICTURE_TYPE_IDR)
pkt->flags |= AV_PKT_FLAG_KEY;
@@ -699,7 +700,7 @@ static int vaapi_encode_set_output_property(AVCodecContext
*avctx,
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 + ctx->async_depth)];
+(3 * ctx->output_delay +
base_ctx->async_depth)];
}
return 0;
@@ -1320,6 +1321,7 @@ static int vaapi_encode_check_frame(AVCodecContext *avctx,
static int vaapi_encode_send_frame(AVCodecContext *avctx, AVFrame *frame)
{
+HWBaseEncodeContext *base_ctx = avctx->priv_data;
VAAPIEncodeContext *ctx = avctx->priv_data;
VAAPIEncodePicture *pic;
int err;
@@ -1365,7 +1367,7 @@ static int vaapi_encode_send_frame(AVCodecContext *avctx,
AVFrame *frame)
ctx->dts_pts_diff = pic->pts - ctx->first_pts;
if (ctx->output_delay > 0)
ctx->ts_ring[ctx->input_order %
-(3 * ctx->output_delay + ctx->async_depth)] = pic->pts;
+(3 * ctx->output_delay + base_ctx->async_depth)] =
pic->pts;
pic->display_order = ctx->input_order;
++ctx->input_order;
@@ -2773,7 +2775,8 @@ static av_cold int
vaapi_encode_create_recon_frames(AVCodecContext *avctx)
av_cold int ff_vaapi_encode_init(AVCodecContext *avctx)
{
-VAAPIEncodeContext *ctx = avctx->priv_data;
+HWBaseEncodeContext *base_ctx = avctx->priv_data;
+VAAPIEncodeContext *ctx = avctx->priv_data;
AVVAAPIFramesContext *recon_hwctx = NULL;
VAStatus vas;
int err;
@@ -2966,7 +2969,7 @@ av_cold int ff_vaapi_encode_init(AVCodecContext *avctx)
vas = vaSyncBuffer(ctx->hwctx->display, VA_INVALID_ID, 0);
if (vas != VA_STATUS_ERROR_UNIMPLEMENTED) {
ctx->has_sync_buffer_func = 1;
-ctx->encode_fifo = av_fifo_alloc2(ctx->async_depth,
+ctx->encode_fifo = av_fifo_alloc2(base_ctx->async_depth,
sizeof(VAAPIEncodePicture *),
0);
if (!ctx->encode_fifo)
diff --git a/libavcodec/vaapi_encode.h b/libavcodec/vaapi_encode.h
index 5e18f374a7..02410c72ec 100644
--- a/libavcodec/vaapi_encode.h
+++ b/libavcodec/vaapi_encode.h
@@ -186,7 +186,8 @@ typedef struct VAAPIEncodeRCMode {
} VAAPIEncodeRCMode;
typedef struct VAAPIEncodeContext {
-const AVClass *class;
+// Base context.
+HWBaseEncodeContext base;
// Codec-specific hooks.
const struct VAAPIEncodeType *codec;
@@ -373,8 +374,6 @@ typedef struct VAAPIEncodeContext {
int has_sync_buffer_func;
// Store buffered pic
AVFifo *encode_fifo;
-// Max number of frame buffered in encoder.
-int async_depth;
/** Head data for current output pkt, used only for AV1. */
//void *header_data;
@@ -490,11 +489,6 @@ int ff_vaapi_encode_close(AVCodecContext *avctx);
"Maximum B-frame reference depth", \
OFFSET(common.desire
[FFmpeg-devel] [PATCH v8 03/15] avcodec/vaapi_encode: add picture type name to base
From: Tong Wu
Signed-off-by: Tong Wu
---
libavcodec/hw_base_encode.h | 5 +
libavcodec/vaapi_encode.c | 4 +---
2 files changed, 6 insertions(+), 3 deletions(-)
diff --git a/libavcodec/hw_base_encode.h b/libavcodec/hw_base_encode.h
index 5272f2836d..a578db8c06 100644
--- a/libavcodec/hw_base_encode.h
+++ b/libavcodec/hw_base_encode.h
@@ -25,6 +25,11 @@
#define MAX_ASYNC_DEPTH 64
#define MAX_REFERENCE_LIST_NUM 2
+static inline const char *ff_hw_base_encode_get_pictype_name(const int type) {
+const char * const picture_type_name[] = { "IDR", "I", "P", "B" };
+return picture_type_name[type];
+}
+
enum {
PICTURE_TYPE_IDR = 0,
PICTURE_TYPE_I = 1,
diff --git a/libavcodec/vaapi_encode.c b/libavcodec/vaapi_encode.c
index 9373512417..2d22e4bd85 100644
--- a/libavcodec/vaapi_encode.c
+++ b/libavcodec/vaapi_encode.c
@@ -38,8 +38,6 @@ const AVCodecHWConfigInternal *const
ff_vaapi_encode_hw_configs[] = {
NULL,
};
-static const char * const picture_type_name[] = { "IDR", "I", "P", "B" };
-
static int vaapi_encode_make_packed_header(AVCodecContext *avctx,
VAAPIEncodePicture *pic,
int type, char *data, size_t
bit_len)
@@ -277,7 +275,7 @@ static int vaapi_encode_issue(AVCodecContext *avctx,
av_log(avctx, AV_LOG_DEBUG, "Issuing encode for pic %"PRId64"/%"PRId64" "
"as type %s.\n", pic->display_order, pic->encode_order,
- picture_type_name[pic->type]);
+ ff_hw_base_encode_get_pictype_name(pic->type));
if (pic->nb_refs[0] == 0 && pic->nb_refs[1] == 0) {
av_log(avctx, AV_LOG_DEBUG, "No reference pictures.\n");
} else {
--
2.41.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] [PATCH v8 04/15] avcodec/vaapi_encode: move pic->input_surface initialization to encode_alloc
From: Tong Wu
When allocating the VAAPIEncodePicture, pic->input_surface can be
initialized right in the place. This movement simplifies the send_frame
logic and is the preparation for moving vaapi_encode_send_frame to the base
layer.
Signed-off-by: Tong Wu
---
libavcodec/vaapi_encode.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/libavcodec/vaapi_encode.c b/libavcodec/vaapi_encode.c
index 2d22e4bd85..227cccae64 100644
--- a/libavcodec/vaapi_encode.c
+++ b/libavcodec/vaapi_encode.c
@@ -878,7 +878,8 @@ static int vaapi_encode_discard(AVCodecContext *avctx,
return 0;
}
-static VAAPIEncodePicture *vaapi_encode_alloc(AVCodecContext *avctx)
+static VAAPIEncodePicture *vaapi_encode_alloc(AVCodecContext *avctx,
+ const AVFrame *frame)
{
VAAPIEncodeContext *ctx = avctx->priv_data;
VAAPIEncodePicture *pic;
@@ -895,7 +896,7 @@ static VAAPIEncodePicture
*vaapi_encode_alloc(AVCodecContext *avctx)
}
}
-pic->input_surface = VA_INVALID_ID;
+pic->input_surface = (VASurfaceID)(uintptr_t)frame->data[3];
pic->recon_surface = VA_INVALID_ID;
pic->output_buffer = VA_INVALID_ID;
@@ -1332,7 +1333,7 @@ static int vaapi_encode_send_frame(AVCodecContext *avctx,
AVFrame *frame)
if (err < 0)
return err;
-pic = vaapi_encode_alloc(avctx);
+pic = vaapi_encode_alloc(avctx, frame);
if (!pic)
return AVERROR(ENOMEM);
@@ -1345,7 +1346,6 @@ static int vaapi_encode_send_frame(AVCodecContext *avctx,
AVFrame *frame)
if (ctx->input_order == 0 || frame->pict_type == AV_PICTURE_TYPE_I)
pic->force_idr = 1;
-pic->input_surface = (VASurfaceID)(uintptr_t)frame->data[3];
pic->pts = frame->pts;
pic->duration = frame->duration;
--
2.41.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] [PATCH v8 05/15] avcodec/vaapi_encode: move the dpb logic from VAAPI to base layer
From: Tong Wu
Move receive_packet function to base. This requires adding *alloc,
*issue, *output, *free as hardware callbacks. HWBaseEncodePicture is
introduced as the base layer structure. The related parameters in
VAAPIEncodeContext are also extracted to HWBaseEncodeContext. Then DPB
management logic can be fully extracted to base layer as-is.
Signed-off-by: Tong Wu
---
libavcodec/Makefile | 2 +-
libavcodec/hw_base_encode.c | 600
libavcodec/hw_base_encode.h | 123 +
libavcodec/vaapi_encode.c | 793 +---
libavcodec/vaapi_encode.h | 102 +---
libavcodec/vaapi_encode_av1.c | 51 +-
libavcodec/vaapi_encode_h264.c | 176 +++
libavcodec/vaapi_encode_h265.c | 121 ++---
libavcodec/vaapi_encode_mjpeg.c | 7 +-
libavcodec/vaapi_encode_mpeg2.c | 47 +-
libavcodec/vaapi_encode_vp8.c | 18 +-
libavcodec/vaapi_encode_vp9.c | 54 +--
12 files changed, 1097 insertions(+), 997 deletions(-)
create mode 100644 libavcodec/hw_base_encode.c
diff --git a/libavcodec/Makefile b/libavcodec/Makefile
index 7f6de4470e..a2174dcb2f 100644
--- a/libavcodec/Makefile
+++ b/libavcodec/Makefile
@@ -162,7 +162,7 @@ OBJS-$(CONFIG_STARTCODE) += startcode.o
OBJS-$(CONFIG_TEXTUREDSP) += texturedsp.o
OBJS-$(CONFIG_TEXTUREDSPENC) += texturedspenc.o
OBJS-$(CONFIG_TPELDSP) += tpeldsp.o
-OBJS-$(CONFIG_VAAPI_ENCODE)+= vaapi_encode.o
+OBJS-$(CONFIG_VAAPI_ENCODE)+= vaapi_encode.o hw_base_encode.o
OBJS-$(CONFIG_AV1_AMF_ENCODER) += amfenc_av1.o
OBJS-$(CONFIG_VC1DSP) += vc1dsp.o
OBJS-$(CONFIG_VIDEODSP)+= videodsp.o
diff --git a/libavcodec/hw_base_encode.c b/libavcodec/hw_base_encode.c
new file mode 100644
index 00..1d9a255f69
--- /dev/null
+++ b/libavcodec/hw_base_encode.c
@@ -0,0 +1,600 @@
+/*
+ * 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/avassert.h"
+#include "libavutil/common.h"
+#include "libavutil/internal.h"
+#include "libavutil/log.h"
+#include "libavutil/mem.h"
+#include "libavutil/pixdesc.h"
+
+#include "encode.h"
+#include "avcodec.h"
+#include "hw_base_encode.h"
+
+static void hw_base_encode_add_ref(AVCodecContext *avctx,
+ HWBaseEncodePicture *pic,
+ HWBaseEncodePicture *target,
+ int is_ref, int in_dpb, int prev)
+{
+int refs = 0;
+
+if (is_ref) {
+av_assert0(pic != target);
+av_assert0(pic->nb_refs[0] < MAX_PICTURE_REFERENCES &&
+ pic->nb_refs[1] < MAX_PICTURE_REFERENCES);
+if (target->display_order < pic->display_order)
+pic->refs[0][pic->nb_refs[0]++] = target;
+else
+pic->refs[1][pic->nb_refs[1]++] = target;
+++refs;
+}
+
+if (in_dpb) {
+av_assert0(pic->nb_dpb_pics < MAX_DPB_SIZE);
+pic->dpb[pic->nb_dpb_pics++] = target;
+++refs;
+}
+
+if (prev) {
+av_assert0(!pic->prev);
+pic->prev = target;
+++refs;
+}
+
+target->ref_count[0] += refs;
+target->ref_count[1] += refs;
+}
+
+static void hw_base_encode_remove_refs(AVCodecContext *avctx,
+ HWBaseEncodePicture *pic,
+ int level)
+{
+int i;
+
+if (pic->ref_removed[level])
+return;
+
+for (i = 0; i < pic->nb_refs[0]; i++) {
+av_assert0(pic->refs[0][i]);
+--pic->refs[0][i]->ref_count[level];
+av_assert0(pic->refs[0][i]->ref_count[level] >= 0);
+}
+
+for (i = 0; i < pic->nb_refs[1]; i++) {
+av_assert0(pic->refs[1][i]);
+--pic->refs[1][i]->ref_count[level];
+av_assert0(pic->refs[1][i]->ref_count[level] >= 0);
+}
+
+for (i = 0; i < pic->nb_dpb_pics; i++) {
+av_assert0(pic->dpb[i]);
+--pic->dpb[i]->ref_count[level];
+av_assert0(pic->dpb[i]->ref_count[level] >= 0);
+}
+
+av_assert0(pic->prev || pic->type == PICTURE_TYPE_IDR);
+if (pic->prev) {
+--pic->prev->ref_count[level];
+av_assert0(pic->prev->ref_count[level] >= 0);
+}
+
+pic->ref_re
[FFmpeg-devel] [PATCH v8 06/15] avcodec/vaapi_encode: extract the init function to base layer
From: Tong Wu
Related parameters are also moved to base layer.
Signed-off-by: Tong Wu
---
libavcodec/hw_base_encode.c | 33
libavcodec/hw_base_encode.h | 11 ++
libavcodec/vaapi_encode.c | 68 ++---
libavcodec/vaapi_encode.h | 6 ---
libavcodec/vaapi_encode_av1.c | 2 +-
libavcodec/vaapi_encode_h264.c | 2 +-
libavcodec/vaapi_encode_h265.c | 2 +-
libavcodec/vaapi_encode_mjpeg.c | 6 ++-
8 files changed, 72 insertions(+), 58 deletions(-)
diff --git a/libavcodec/hw_base_encode.c b/libavcodec/hw_base_encode.c
index 1d9a255f69..14f3ecfc94 100644
--- a/libavcodec/hw_base_encode.c
+++ b/libavcodec/hw_base_encode.c
@@ -598,3 +598,36 @@ end:
return 0;
}
+
+int ff_hw_base_encode_init(AVCodecContext *avctx)
+{
+HWBaseEncodeContext *ctx = avctx->priv_data;
+
+ctx->frame = av_frame_alloc();
+if (!ctx->frame)
+return AVERROR(ENOMEM);
+
+if (!avctx->hw_frames_ctx) {
+av_log(avctx, AV_LOG_ERROR, "A hardware frames reference is "
+ "required to associate the encoding device.\n");
+return AVERROR(EINVAL);
+}
+
+ctx->input_frames_ref = av_buffer_ref(avctx->hw_frames_ctx);
+if (!ctx->input_frames_ref)
+return AVERROR(ENOMEM);
+
+ctx->input_frames = (AVHWFramesContext *)ctx->input_frames_ref->data;
+
+ctx->device_ref = av_buffer_ref(ctx->input_frames->device_ref);
+if (!ctx->device_ref)
+return AVERROR(ENOMEM);
+
+ctx->device = (AVHWDeviceContext *)ctx->device_ref->data;
+
+ctx->tail_pkt = av_packet_alloc();
+if (!ctx->tail_pkt)
+return AVERROR(ENOMEM);
+
+return 0;
+}
diff --git a/libavcodec/hw_base_encode.h b/libavcodec/hw_base_encode.h
index b5b676b9a8..f7e385e840 100644
--- a/libavcodec/hw_base_encode.h
+++ b/libavcodec/hw_base_encode.h
@@ -19,6 +19,7 @@
#ifndef AVCODEC_HW_BASE_ENCODE_H
#define AVCODEC_HW_BASE_ENCODE_H
+#include "libavutil/hwcontext.h"
#include "libavutil/fifo.h"
#define MAX_DPB_SIZE 16
@@ -117,6 +118,14 @@ typedef struct HWBaseEncodeContext {
// Hardware-specific hooks.
const struct HWEncodePictureOperation *op;
+// The hardware device context.
+AVBufferRef*device_ref;
+AVHWDeviceContext *device;
+
+// The hardware frame context containing the input frames.
+AVBufferRef*input_frames_ref;
+AVHWFramesContext *input_frames;
+
// Current encoding window, in display (input) order.
HWBaseEncodePicture *pic_start, *pic_end;
// The next picture to use as the previous reference picture in
@@ -183,6 +192,8 @@ typedef struct HWBaseEncodeContext {
int ff_hw_base_encode_receive_packet(AVCodecContext *avctx, AVPacket *pkt);
+int ff_hw_base_encode_init(AVCodecContext *avctx);
+
#define HW_BASE_ENCODE_COMMON_OPTIONS \
{ "async_depth", "Maximum processing parallelism. " \
"Increase this to improve single channel performance.", \
diff --git a/libavcodec/vaapi_encode.c b/libavcodec/vaapi_encode.c
index 18966596e1..c7488ad150 100644
--- a/libavcodec/vaapi_encode.c
+++ b/libavcodec/vaapi_encode.c
@@ -996,9 +996,10 @@ static const VAEntrypoint
vaapi_encode_entrypoints_low_power[] = {
static av_cold int vaapi_encode_profile_entrypoint(AVCodecContext *avctx)
{
-VAAPIEncodeContext *ctx = avctx->priv_data;
-VAProfile*va_profiles= NULL;
-VAEntrypoint *va_entrypoints = NULL;
+HWBaseEncodeContext *base_ctx = avctx->priv_data;
+VAAPIEncodeContext *ctx = avctx->priv_data;
+VAProfile *va_profiles= NULL;
+VAEntrypoint *va_entrypoints = NULL;
VAStatus vas;
const VAEntrypoint *usable_entrypoints;
const VAAPIEncodeProfile *profile;
@@ -1021,10 +1022,10 @@ static av_cold int
vaapi_encode_profile_entrypoint(AVCodecContext *avctx)
usable_entrypoints = vaapi_encode_entrypoints_normal;
}
-desc = av_pix_fmt_desc_get(ctx->input_frames->sw_format);
+desc = av_pix_fmt_desc_get(base_ctx->input_frames->sw_format);
if (!desc) {
av_log(avctx, AV_LOG_ERROR, "Invalid input pixfmt (%d).\n",
- ctx->input_frames->sw_format);
+ base_ctx->input_frames->sw_format);
return AVERROR(EINVAL);
}
depth = desc->comp[0].depth;
@@ -2131,20 +2132,21 @@ static int
vaapi_encode_alloc_output_buffer(FFRefStructOpaque opaque, void *obj)
static av_cold int vaapi_encode_create_recon_frames(AVCodecContext *avctx)
{
-VAAPIEncodeContext *ctx = avctx->priv_data;
+HWBaseEncodeContext *base_ctx = avctx->priv_data;
+VAAPIEncodeContext *ctx = avctx->priv_data;
AVVAAPIHWConfig *hwconfig = NULL;
AVHWFramesConstraints *constraints = NULL;
enum AVPixelFormat recon_format;
int err, i;
-hwconfig = av_hwdevice_hwconfig_alloc(ctx->device_ref);
+hwconfig = av_hwdevice_hwconfig_alloc(base_ctx->device_ref);
if (!hwconfig) {
err = AVERROR(ENOMEM);
goto fail;
}
hw
[FFmpeg-devel] [PATCH v8 09/15] avcodec/vaapi_encode: extract a close function for base layer
From: Tong Wu
Signed-off-by: Tong Wu
---
libavcodec/hw_base_encode.c | 16
libavcodec/hw_base_encode.h | 2 ++
libavcodec/vaapi_encode.c | 8 +---
3 files changed, 19 insertions(+), 7 deletions(-)
diff --git a/libavcodec/hw_base_encode.c b/libavcodec/hw_base_encode.c
index 6e450f9dca..fa954d984d 100644
--- a/libavcodec/hw_base_encode.c
+++ b/libavcodec/hw_base_encode.c
@@ -685,3 +685,19 @@ int ff_hw_base_encode_init(AVCodecContext *avctx)
return 0;
}
+
+int ff_hw_base_encode_close(AVCodecContext *avctx)
+{
+HWBaseEncodeContext *ctx = avctx->priv_data;
+
+av_fifo_freep2(&ctx->encode_fifo);
+
+av_frame_free(&ctx->frame);
+av_packet_free(&ctx->tail_pkt);
+
+av_buffer_unref(&ctx->device_ref);
+av_buffer_unref(&ctx->input_frames_ref);
+av_buffer_unref(&ctx->recon_frames_ref);
+
+return 0;
+}
diff --git a/libavcodec/hw_base_encode.h b/libavcodec/hw_base_encode.h
index 3eea3ef998..d822175fcf 100644
--- a/libavcodec/hw_base_encode.h
+++ b/libavcodec/hw_base_encode.h
@@ -209,6 +209,8 @@ int ff_hw_base_init_gop_structure(AVCodecContext *avctx,
uint32_t ref_l0, uint32
int ff_hw_base_encode_init(AVCodecContext *avctx);
+int ff_hw_base_encode_close(AVCodecContext *avctx);
+
#define HW_BASE_ENCODE_COMMON_OPTIONS \
{ "idr_interval", \
"Distance (in I-frames) between key frames", \
diff --git a/libavcodec/vaapi_encode.c b/libavcodec/vaapi_encode.c
index 8640a888b7..41d0d0f2bc 100644
--- a/libavcodec/vaapi_encode.c
+++ b/libavcodec/vaapi_encode.c
@@ -2397,16 +2397,10 @@ av_cold int ff_vaapi_encode_close(AVCodecContext *avctx)
ctx->va_config = VA_INVALID_ID;
}
-av_frame_free(&base_ctx->frame);
-av_packet_free(&base_ctx->tail_pkt);
-
av_freep(&ctx->codec_sequence_params);
av_freep(&ctx->codec_picture_params);
-av_fifo_freep2(&base_ctx->encode_fifo);
-av_buffer_unref(&base_ctx->recon_frames_ref);
-av_buffer_unref(&base_ctx->input_frames_ref);
-av_buffer_unref(&base_ctx->device_ref);
+ff_hw_base_encode_close(avctx);
return 0;
}
--
2.41.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] [PATCH v8 07/15] avcodec/vaapi_encode: extract gop configuration and two options to base layer
From: Tong Wu
idr_interval and desired_b_depth are moved to HW_BASE_ENCODE_COMMON_OPTIONS.
Signed-off-by: Tong Wu
---
libavcodec/hw_base_encode.c | 54 +
libavcodec/hw_base_encode.h | 19 +
libavcodec/vaapi_encode.c | 52 +++
libavcodec/vaapi_encode.h | 16 ---
4 files changed, 77 insertions(+), 64 deletions(-)
diff --git a/libavcodec/hw_base_encode.c b/libavcodec/hw_base_encode.c
index 14f3ecfc94..6e450f9dca 100644
--- a/libavcodec/hw_base_encode.c
+++ b/libavcodec/hw_base_encode.c
@@ -599,6 +599,60 @@ end:
return 0;
}
+int ff_hw_base_init_gop_structure(AVCodecContext *avctx, uint32_t ref_l0,
uint32_t ref_l1,
+ int flags, int prediction_pre_only)
+{
+HWBaseEncodeContext *ctx = avctx->priv_data;
+
+if (flags & FLAG_INTRA_ONLY || avctx->gop_size <= 1) {
+av_log(avctx, AV_LOG_VERBOSE, "Using intra frames only.\n");
+ctx->gop_size = 1;
+} else if (ref_l0 < 1) {
+av_log(avctx, AV_LOG_ERROR, "Driver does not support any "
+ "reference frames.\n");
+return AVERROR(EINVAL);
+} else if (!(flags & FLAG_B_PICTURES) || ref_l1 < 1 ||
+ avctx->max_b_frames < 1 || prediction_pre_only) {
+if (ctx->p_to_gpb)
+ av_log(avctx, AV_LOG_VERBOSE, "Using intra and B-frames "
+ "(supported references: %d / %d).\n",
+ ref_l0, ref_l1);
+else
+av_log(avctx, AV_LOG_VERBOSE, "Using intra and P-frames "
+ "(supported references: %d / %d).\n", ref_l0, ref_l1);
+ctx->gop_size = avctx->gop_size;
+ctx->p_per_i = INT_MAX;
+ctx->b_per_p = 0;
+} else {
+ if (ctx->p_to_gpb)
+ av_log(avctx, AV_LOG_VERBOSE, "Using intra and B-frames "
+ "(supported references: %d / %d).\n",
+ ref_l0, ref_l1);
+ else
+ av_log(avctx, AV_LOG_VERBOSE, "Using intra, P- and B-frames "
+ "(supported references: %d / %d).\n", ref_l0, ref_l1);
+ctx->gop_size = avctx->gop_size;
+ctx->p_per_i = INT_MAX;
+ctx->b_per_p = avctx->max_b_frames;
+if (flags & FLAG_B_PICTURE_REFERENCES) {
+ctx->max_b_depth = FFMIN(ctx->desired_b_depth,
+ av_log2(ctx->b_per_p) + 1);
+} else {
+ctx->max_b_depth = 1;
+}
+}
+
+if (flags & FLAG_NON_IDR_KEY_PICTURES) {
+ctx->closed_gop = !!(avctx->flags & AV_CODEC_FLAG_CLOSED_GOP);
+ctx->gop_per_idr = ctx->idr_interval + 1;
+} else {
+ctx->closed_gop = 1;
+ctx->gop_per_idr = 1;
+}
+
+return 0;
+}
+
int ff_hw_base_encode_init(AVCodecContext *avctx)
{
HWBaseEncodeContext *ctx = avctx->priv_data;
diff --git a/libavcodec/hw_base_encode.h b/libavcodec/hw_base_encode.h
index f7e385e840..1f6d7882bc 100644
--- a/libavcodec/hw_base_encode.h
+++ b/libavcodec/hw_base_encode.h
@@ -118,6 +118,14 @@ typedef struct HWBaseEncodeContext {
// Hardware-specific hooks.
const struct HWEncodePictureOperation *op;
+// Global options.
+
+// Number of I frames between IDR frames.
+int idr_interval;
+
+// Desired B frame reference depth.
+int desired_b_depth;
+
// The hardware device context.
AVBufferRef*device_ref;
AVHWDeviceContext *device;
@@ -192,9 +200,20 @@ typedef struct HWBaseEncodeContext {
int ff_hw_base_encode_receive_packet(AVCodecContext *avctx, AVPacket *pkt);
+int ff_hw_base_init_gop_structure(AVCodecContext *avctx, uint32_t ref_l0,
uint32_t ref_l1,
+ int flags, int prediction_pre_only);
+
int ff_hw_base_encode_init(AVCodecContext *avctx);
#define HW_BASE_ENCODE_COMMON_OPTIONS \
+{ "idr_interval", \
+ "Distance (in I-frames) between key frames", \
+ OFFSET(common.base.idr_interval), AV_OPT_TYPE_INT, \
+ { .i64 = 0 }, 0, INT_MAX, FLAGS }, \
+{ "b_depth", \
+ "Maximum B-frame reference depth", \
+ OFFSET(common.base.desired_b_depth), AV_OPT_TYPE_INT, \
+ { .i64 = 1 }, 1, INT_MAX, FLAGS }, \
{ "async_depth", "Maximum processing parallelism. " \
"Increase this to improve single channel performance.", \
OFFSET(common.base.async_depth), AV_OPT_TYPE_INT, \
diff --git a/libavcodec/vaapi_encode.c b/libavcodec/vaapi_encode.c
index c7488ad150..993b2640a9 100644
--- a/libavcodec/vaapi_encode.c
+++ b/libavcodec/vaapi_encode.c
@@ -1638,7 +1638,7 @@ static av_cold int
vaapi_encode_init_gop_structure(AVCodecContext *avctx)
VAStatus vas;
VAConfigAttrib attr = { VAConfigAttribEncMaxRefFrames };
uint32_t ref_l0, ref_l1;
-int prediction_pre_only;
+int prediction_pre_only, err;
vas = vaGetConfigAttributes(ctx->hwctx->display,
ctx->va_profile,
@@ -1702,53 +1702,9 @@ static
[FFmpeg-devel] [PATCH v8 10/15] avcodec/vaapi_encode: extract set_output_property to base layer
From: Tong Wu
Signed-off-by: Tong Wu
---
libavcodec/hw_base_encode.c | 40 +
libavcodec/hw_base_encode.h | 3 +++
libavcodec/vaapi_encode.c | 44 ++---
3 files changed, 45 insertions(+), 42 deletions(-)
diff --git a/libavcodec/hw_base_encode.c b/libavcodec/hw_base_encode.c
index fa954d984d..a4223d90f0 100644
--- a/libavcodec/hw_base_encode.c
+++ b/libavcodec/hw_base_encode.c
@@ -491,6 +491,46 @@ fail:
return err;
}
+int ff_hw_base_encode_set_output_property(AVCodecContext *avctx,
+ HWBaseEncodePicture *pic,
+ AVPacket *pkt, int flag_no_delay)
+{
+HWBaseEncodeContext *ctx = avctx->priv_data;
+
+if (pic->type == PICTURE_TYPE_IDR)
+pkt->flags |= AV_PKT_FLAG_KEY;
+
+pkt->pts = pic->pts;
+pkt->duration = pic->duration;
+
+// for no-delay encoders this is handled in generic codec
+if (avctx->codec->capabilities & AV_CODEC_CAP_DELAY &&
+avctx->flags & AV_CODEC_FLAG_COPY_OPAQUE) {
+pkt->opaque = pic->opaque;
+pkt->opaque_ref = pic->opaque_ref;
+pic->opaque_ref = NULL;
+}
+
+if (flag_no_delay) {
+pkt->dts = pkt->pts;
+return 0;
+}
+
+if (ctx->output_delay == 0) {
+pkt->dts = pkt->pts;
+} else if (pic->encode_order < ctx->decode_delay) {
+if (ctx->ts_ring[pic->encode_order] < INT64_MIN + ctx->dts_pts_diff)
+pkt->dts = INT64_MIN;
+else
+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 + ctx->async_depth)];
+}
+
+return 0;
+}
+
int ff_hw_base_encode_receive_packet(AVCodecContext *avctx, AVPacket *pkt)
{
HWBaseEncodeContext *ctx = avctx->priv_data;
diff --git a/libavcodec/hw_base_encode.h b/libavcodec/hw_base_encode.h
index d822175fcf..d717f955d8 100644
--- a/libavcodec/hw_base_encode.h
+++ b/libavcodec/hw_base_encode.h
@@ -202,6 +202,9 @@ typedef struct HWBaseEncodeContext {
AVPacket*tail_pkt;
} HWBaseEncodeContext;
+int ff_hw_base_encode_set_output_property(AVCodecContext *avctx,
HWBaseEncodePicture *pic,
+ AVPacket *pkt, int flag_no_delay);
+
int ff_hw_base_encode_receive_packet(AVCodecContext *avctx, AVPacket *pkt);
int ff_hw_base_init_gop_structure(AVCodecContext *avctx, uint32_t ref_l0,
uint32_t ref_l1,
diff --git a/libavcodec/vaapi_encode.c b/libavcodec/vaapi_encode.c
index 41d0d0f2bc..ec4cde3c37 100644
--- a/libavcodec/vaapi_encode.c
+++ b/libavcodec/vaapi_encode.c
@@ -660,47 +660,6 @@ fail_at_end:
return err;
}
-static int vaapi_encode_set_output_property(AVCodecContext *avctx,
-HWBaseEncodePicture *pic,
-AVPacket *pkt)
-{
-HWBaseEncodeContext *base_ctx = avctx->priv_data;
-VAAPIEncodeContext *ctx = avctx->priv_data;
-
-if (pic->type == PICTURE_TYPE_IDR)
-pkt->flags |= AV_PKT_FLAG_KEY;
-
-pkt->pts = pic->pts;
-pkt->duration = pic->duration;
-
-// for no-delay encoders this is handled in generic codec
-if (avctx->codec->capabilities & AV_CODEC_CAP_DELAY &&
-avctx->flags & AV_CODEC_FLAG_COPY_OPAQUE) {
-pkt->opaque = pic->opaque;
-pkt->opaque_ref = pic->opaque_ref;
-pic->opaque_ref = NULL;
-}
-
-if (ctx->codec->flags & FLAG_TIMESTAMP_NO_DELAY) {
-pkt->dts = pkt->pts;
-return 0;
-}
-
-if (base_ctx->output_delay == 0) {
-pkt->dts = pkt->pts;
-} else if (pic->encode_order < base_ctx->decode_delay) {
-if (base_ctx->ts_ring[pic->encode_order] < INT64_MIN +
base_ctx->dts_pts_diff)
-pkt->dts = INT64_MIN;
-else
-pkt->dts = base_ctx->ts_ring[pic->encode_order] -
base_ctx->dts_pts_diff;
-} else {
-pkt->dts = base_ctx->ts_ring[(pic->encode_order -
base_ctx->decode_delay) %
- (3 * base_ctx->output_delay +
base_ctx->async_depth)];
-}
-
-return 0;
-}
-
static int vaapi_encode_get_coded_buffer_size(AVCodecContext *avctx,
VABufferID buf_id)
{
VAAPIEncodeContext *ctx = avctx->priv_data;
@@ -852,7 +811,8 @@ static int vaapi_encode_output(AVCodecContext *avctx,
av_log(avctx, AV_LOG_DEBUG, "Output read for pic %"PRId64"/%"PRId64".\n",
base_pic->display_order, base_pic->encode_order);
-vaapi_encode_set_output_property(avctx, (HWBaseEncodePicture*)pic,
pkt_ptr);
+ff_hw_base_encode_set_output_property(avctx,
(HWBaseEncodePicture*)base_pic, pkt_ptr,
+ ctx->codec->flags &
FLAG_TIMESTAMP_NO_DELAY);
end:
ff_refstruct_unref(&pic->output_buffer_ref);
--
2.41.0.windows.1
_
[FFmpeg-devel] [PATCH v8 11/15] avcodec/vaapi_encode: extract a get_recon_format function to base layer
From: Tong Wu
Surface size and block size parameters are also moved to base layer.
Signed-off-by: Tong Wu
---
libavcodec/hw_base_encode.c | 58 +++
libavcodec/hw_base_encode.h | 12 +
libavcodec/vaapi_encode.c | 81 -
libavcodec/vaapi_encode.h | 10
libavcodec/vaapi_encode_av1.c | 10 ++--
libavcodec/vaapi_encode_h264.c | 11 +++--
libavcodec/vaapi_encode_h265.c | 25 +-
libavcodec/vaapi_encode_mjpeg.c | 5 +-
libavcodec/vaapi_encode_vp9.c | 6 +--
9 files changed, 118 insertions(+), 100 deletions(-)
diff --git a/libavcodec/hw_base_encode.c b/libavcodec/hw_base_encode.c
index a4223d90f0..af85bb99aa 100644
--- a/libavcodec/hw_base_encode.c
+++ b/libavcodec/hw_base_encode.c
@@ -693,6 +693,64 @@ int ff_hw_base_init_gop_structure(AVCodecContext *avctx,
uint32_t ref_l0, uint32
return 0;
}
+int ff_hw_base_get_recon_format(AVCodecContext *avctx, const void *hwconfig,
enum AVPixelFormat *fmt)
+{
+HWBaseEncodeContext *ctx = avctx->priv_data;
+AVHWFramesConstraints *constraints = NULL;
+enum AVPixelFormat recon_format;
+int err, i;
+
+constraints = av_hwdevice_get_hwframe_constraints(ctx->device_ref,
+ hwconfig);
+if (!constraints) {
+err = AVERROR(ENOMEM);
+goto fail;
+}
+
+// Probably we can use the input surface format as the surface format
+// of the reconstructed frames. If not, we just pick the first (only?)
+// format in the valid list and hope that it all works.
+recon_format = AV_PIX_FMT_NONE;
+if (constraints->valid_sw_formats) {
+for (i = 0; constraints->valid_sw_formats[i] != AV_PIX_FMT_NONE; i++) {
+if (ctx->input_frames->sw_format ==
+constraints->valid_sw_formats[i]) {
+recon_format = ctx->input_frames->sw_format;
+break;
+}
+}
+if (recon_format == AV_PIX_FMT_NONE) {
+// No match. Just use the first in the supported list and
+// hope for the best.
+recon_format = constraints->valid_sw_formats[0];
+}
+} else {
+// No idea what to use; copy input format.
+recon_format = ctx->input_frames->sw_format;
+}
+av_log(avctx, AV_LOG_DEBUG, "Using %s as format of "
+ "reconstructed frames.\n", av_get_pix_fmt_name(recon_format));
+
+if (ctx->surface_width < constraints->min_width ||
+ctx->surface_height < constraints->min_height ||
+ctx->surface_width > constraints->max_width ||
+ctx->surface_height > constraints->max_height) {
+av_log(avctx, AV_LOG_ERROR, "Hardware does not support encoding at "
+ "size %dx%d (constraints: width %d-%d height %d-%d).\n",
+ ctx->surface_width, ctx->surface_height,
+ constraints->min_width, constraints->max_width,
+ constraints->min_height, constraints->max_height);
+err = AVERROR(EINVAL);
+goto fail;
+}
+
+*fmt = recon_format;
+err = 0;
+fail:
+av_hwframe_constraints_free(&constraints);
+return err;
+}
+
int ff_hw_base_encode_init(AVCodecContext *avctx)
{
HWBaseEncodeContext *ctx = avctx->priv_data;
diff --git a/libavcodec/hw_base_encode.h b/libavcodec/hw_base_encode.h
index d717f955d8..7686cf9501 100644
--- a/libavcodec/hw_base_encode.h
+++ b/libavcodec/hw_base_encode.h
@@ -126,6 +126,16 @@ typedef struct HWBaseEncodeContext {
// Desired B frame reference depth.
int desired_b_depth;
+// The required size of surfaces. This is probably the input
+// size (AVCodecContext.width|height) aligned up to whatever
+// block size is required by the codec.
+int surface_width;
+int surface_height;
+
+// The block size for slice calculations.
+int slice_block_width;
+int slice_block_height;
+
// The hardware device context.
AVBufferRef*device_ref;
AVHWDeviceContext *device;
@@ -210,6 +220,8 @@ int ff_hw_base_encode_receive_packet(AVCodecContext *avctx,
AVPacket *pkt);
int ff_hw_base_init_gop_structure(AVCodecContext *avctx, uint32_t ref_l0,
uint32_t ref_l1,
int flags, int prediction_pre_only);
+int ff_hw_base_get_recon_format(AVCodecContext *avctx, const void *hwconfig,
enum AVPixelFormat *fmt);
+
int ff_hw_base_encode_init(AVCodecContext *avctx);
int ff_hw_base_encode_close(AVCodecContext *avctx);
diff --git a/libavcodec/vaapi_encode.c b/libavcodec/vaapi_encode.c
index ec4cde3c37..ee4cf42baf 100644
--- a/libavcodec/vaapi_encode.c
+++ b/libavcodec/vaapi_encode.c
@@ -1777,6 +1777,7 @@ static av_cold int
vaapi_encode_init_tile_slice_structure(AVCodecContext *avctx,
static av_cold int vaapi_encode_init_slice_structure(AVCodecContext *avctx)
{
+HWBaseEncodeContext *base_ctx = avctx->pr
[FFmpeg-devel] [PATCH v8 08/15] avcodec/vaapi_encode: move two reconstructed frames parameters to base layer
From: Tong Wu
Signed-off-by: Tong Wu
---
libavcodec/hw_base_encode.h | 4
libavcodec/vaapi_encode.c | 22 +++---
libavcodec/vaapi_encode.h | 4
3 files changed, 15 insertions(+), 15 deletions(-)
diff --git a/libavcodec/hw_base_encode.h b/libavcodec/hw_base_encode.h
index 1f6d7882bc..3eea3ef998 100644
--- a/libavcodec/hw_base_encode.h
+++ b/libavcodec/hw_base_encode.h
@@ -134,6 +134,10 @@ typedef struct HWBaseEncodeContext {
AVBufferRef*input_frames_ref;
AVHWFramesContext *input_frames;
+// The hardware frame context containing the reconstructed frames.
+AVBufferRef*recon_frames_ref;
+AVHWFramesContext *recon_frames;
+
// Current encoding window, in display (input) order.
HWBaseEncodePicture *pic_start, *pic_end;
// The next picture to use as the previous reference picture in
diff --git a/libavcodec/vaapi_encode.c b/libavcodec/vaapi_encode.c
index 993b2640a9..8640a888b7 100644
--- a/libavcodec/vaapi_encode.c
+++ b/libavcodec/vaapi_encode.c
@@ -314,7 +314,7 @@ static int vaapi_encode_issue(AVCodecContext *avctx,
av_log(avctx, AV_LOG_DEBUG, "Input surface is %#x.\n", pic->input_surface);
-err = av_hwframe_get_buffer(ctx->recon_frames_ref, base_pic->recon_image,
0);
+err = av_hwframe_get_buffer(base_ctx->recon_frames_ref,
base_pic->recon_image, 0);
if (err < 0) {
err = AVERROR(ENOMEM);
goto fail;
@@ -2149,19 +2149,19 @@ static av_cold int
vaapi_encode_create_recon_frames(AVCodecContext *avctx)
av_freep(&hwconfig);
av_hwframe_constraints_free(&constraints);
-ctx->recon_frames_ref = av_hwframe_ctx_alloc(base_ctx->device_ref);
-if (!ctx->recon_frames_ref) {
+base_ctx->recon_frames_ref = av_hwframe_ctx_alloc(base_ctx->device_ref);
+if (!base_ctx->recon_frames_ref) {
err = AVERROR(ENOMEM);
goto fail;
}
-ctx->recon_frames = (AVHWFramesContext*)ctx->recon_frames_ref->data;
+base_ctx->recon_frames =
(AVHWFramesContext*)base_ctx->recon_frames_ref->data;
-ctx->recon_frames->format= AV_PIX_FMT_VAAPI;
-ctx->recon_frames->sw_format = recon_format;
-ctx->recon_frames->width = ctx->surface_width;
-ctx->recon_frames->height= ctx->surface_height;
+base_ctx->recon_frames->format= AV_PIX_FMT_VAAPI;
+base_ctx->recon_frames->sw_format = recon_format;
+base_ctx->recon_frames->width = ctx->surface_width;
+base_ctx->recon_frames->height= ctx->surface_height;
-err = av_hwframe_ctx_init(ctx->recon_frames_ref);
+err = av_hwframe_ctx_init(base_ctx->recon_frames_ref);
if (err < 0) {
av_log(avctx, AV_LOG_ERROR, "Failed to initialise reconstructed "
"frame context: %d.\n", err);
@@ -2269,7 +2269,7 @@ av_cold int ff_vaapi_encode_init(AVCodecContext *avctx)
if (err < 0)
goto fail;
-recon_hwctx = ctx->recon_frames->hwctx;
+recon_hwctx = base_ctx->recon_frames->hwctx;
vas = vaCreateContext(ctx->hwctx->display, ctx->va_config,
ctx->surface_width, ctx->surface_height,
VA_PROGRESSIVE,
@@ -2404,7 +2404,7 @@ av_cold int ff_vaapi_encode_close(AVCodecContext *avctx)
av_freep(&ctx->codec_picture_params);
av_fifo_freep2(&base_ctx->encode_fifo);
-av_buffer_unref(&ctx->recon_frames_ref);
+av_buffer_unref(&base_ctx->recon_frames_ref);
av_buffer_unref(&base_ctx->input_frames_ref);
av_buffer_unref(&base_ctx->device_ref);
diff --git a/libavcodec/vaapi_encode.h b/libavcodec/vaapi_encode.h
index 0d3d8e2ed0..76fb645d71 100644
--- a/libavcodec/vaapi_encode.h
+++ b/libavcodec/vaapi_encode.h
@@ -213,10 +213,6 @@ typedef struct VAAPIEncodeContext {
AVVAAPIDeviceContext *hwctx;
-// The hardware frame context containing the reconstructed frames.
-AVBufferRef*recon_frames_ref;
-AVHWFramesContext *recon_frames;
-
// Pool of (reusable) bitstream output buffers.
struct FFRefStructPool *output_buffer_pool;
--
2.41.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] [PATCH v8 12/15] avcodec/vaapi_encode: extract a free funtion to base layer
From: Tong Wu
Signed-off-by: Tong Wu
---
libavcodec/hw_base_encode.c | 11 +++
libavcodec/hw_base_encode.h | 2 ++
libavcodec/vaapi_encode.c | 6 +-
3 files changed, 14 insertions(+), 5 deletions(-)
diff --git a/libavcodec/hw_base_encode.c b/libavcodec/hw_base_encode.c
index af85bb99aa..812668f3f2 100644
--- a/libavcodec/hw_base_encode.c
+++ b/libavcodec/hw_base_encode.c
@@ -751,6 +751,17 @@ fail:
return err;
}
+int ff_hw_base_encode_free(AVCodecContext *avctx, HWBaseEncodePicture *pic)
+{
+av_frame_free(&pic->input_image);
+av_frame_free(&pic->recon_image);
+
+av_buffer_unref(&pic->opaque_ref);
+av_freep(&pic->priv_data);
+
+return 0;
+}
+
int ff_hw_base_encode_init(AVCodecContext *avctx)
{
HWBaseEncodeContext *ctx = avctx->priv_data;
diff --git a/libavcodec/hw_base_encode.h b/libavcodec/hw_base_encode.h
index 7686cf9501..d566980efc 100644
--- a/libavcodec/hw_base_encode.h
+++ b/libavcodec/hw_base_encode.h
@@ -222,6 +222,8 @@ int ff_hw_base_init_gop_structure(AVCodecContext *avctx,
uint32_t ref_l0, uint32
int ff_hw_base_get_recon_format(AVCodecContext *avctx, const void *hwconfig,
enum AVPixelFormat *fmt);
+int ff_hw_base_encode_free(AVCodecContext *avctx, HWBaseEncodePicture *pic);
+
int ff_hw_base_encode_init(AVCodecContext *avctx);
int ff_hw_base_encode_close(AVCodecContext *avctx);
diff --git a/libavcodec/vaapi_encode.c b/libavcodec/vaapi_encode.c
index ee4cf42baf..08792c07c5 100644
--- a/libavcodec/vaapi_encode.c
+++ b/libavcodec/vaapi_encode.c
@@ -878,17 +878,13 @@ static int vaapi_encode_free(AVCodecContext *avctx,
av_freep(&pic->slices[i].codec_slice_params);
}
-av_frame_free(&base_pic->input_image);
-av_frame_free(&base_pic->recon_image);
-
-av_buffer_unref(&base_pic->opaque_ref);
+ff_hw_base_encode_free(avctx, base_pic);
av_freep(&pic->param_buffers);
av_freep(&pic->slices);
// Output buffer should already be destroyed.
av_assert0(pic->output_buffer == VA_INVALID_ID);
-av_freep(&base_pic->priv_data);
av_freep(&pic->codec_picture_params);
av_freep(&pic->roi);
--
2.41.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] [PATCH v8 13/15] avutil/hwcontext_d3d12va: add Flags for resource creation
From: Tong Wu
Flags field is added to support diffferent resource creation.
Signed-off-by: Tong Wu
---
doc/APIchanges| 3 +++
libavutil/hwcontext_d3d12va.c | 2 +-
libavutil/hwcontext_d3d12va.h | 8
libavutil/version.h | 2 +-
4 files changed, 13 insertions(+), 2 deletions(-)
diff --git a/doc/APIchanges b/doc/APIchanges
index 63e7a47126..ebf645dda8 100644
--- a/doc/APIchanges
+++ b/doc/APIchanges
@@ -2,6 +2,9 @@ The last version increases of all libraries were on 2024-03-07
API changes, most recent first:
+2024-01-xx - xx - lavu 59.16.100 - hwcontext_d3d12va.h
+ Add AVD3D12VAFramesContext.flags
+
2024-04-11 - xx - lavc 61.5.102 - avcodec.h
AVCodecContext.decoded_side_data may now be set by libavcodec after
calling avcodec_open2().
diff --git a/libavutil/hwcontext_d3d12va.c b/libavutil/hwcontext_d3d12va.c
index cfc016315d..6507cf69c1 100644
--- a/libavutil/hwcontext_d3d12va.c
+++ b/libavutil/hwcontext_d3d12va.c
@@ -247,7 +247,7 @@ static AVBufferRef *d3d12va_pool_alloc(void *opaque, size_t
size)
.Format = hwctx->format,
.SampleDesc = {.Count = 1, .Quality = 0 },
.Layout = D3D12_TEXTURE_LAYOUT_UNKNOWN,
-.Flags= D3D12_RESOURCE_FLAG_NONE,
+.Flags= hwctx->flags,
};
frame = av_mallocz(sizeof(AVD3D12VAFrame));
diff --git a/libavutil/hwcontext_d3d12va.h b/libavutil/hwcontext_d3d12va.h
index ff06e6f2ef..608dbac97f 100644
--- a/libavutil/hwcontext_d3d12va.h
+++ b/libavutil/hwcontext_d3d12va.h
@@ -129,6 +129,14 @@ typedef struct AVD3D12VAFramesContext {
* If unset, will be automatically set.
*/
DXGI_FORMAT format;
+
+/**
+ * This field is used to specify options for working with resources.
+ * If unset, this will be D3D12_RESOURCE_FLAG_NONE.
+ *
+ * @see:
https://learn.microsoft.com/en-us/windows/win32/api/d3d12/ne-d3d12-d3d12_resource_flags.
+ */
+D3D12_RESOURCE_FLAGS flags;
} AVD3D12VAFramesContext;
#endif /* AVUTIL_HWCONTEXT_D3D12VA_H */
diff --git a/libavutil/version.h b/libavutil/version.h
index 1f2bddc022..ea289c406f 100644
--- a/libavutil/version.h
+++ b/libavutil/version.h
@@ -79,7 +79,7 @@
*/
#define LIBAVUTIL_VERSION_MAJOR 59
-#define LIBAVUTIL_VERSION_MINOR 15
+#define LIBAVUTIL_VERSION_MINOR 16
#define LIBAVUTIL_VERSION_MICRO 100
#define LIBAVUTIL_VERSION_INT AV_VERSION_INT(LIBAVUTIL_VERSION_MAJOR, \
--
2.41.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] [PATCH v8 15/15] Changelog: add D3D12VA HEVC encoder changelog
From: Tong Wu Signed-off-by: Tong Wu --- Changelog | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Changelog b/Changelog index 8db14f02b4..573e356a96 100644 --- a/Changelog +++ b/Changelog @@ -7,7 +7,7 @@ version : - ffmpeg CLI filtergraph chaining - LC3/LC3plus demuxer and muxer - pad_vaapi, drawbox_vaapi filters - +- D3D12VA HEVC encoder version 7.0: - DXV DXT1 encoder -- 2.41.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] [PATCH v8 14/15] avcodec: add D3D12VA hardware HEVC encoder
From: Tong Wu This implementation is based on D3D12 Video Encoding Spec: https://microsoft.github.io/DirectX-Specs/d3d/D3D12VideoEncoding.html Sample command line for transcoding: ffmpeg.exe -hwaccel d3d12va -hwaccel_output_format d3d12 -i input.mp4 -c:v hevc_d3d12va output.mp4 Signed-off-by: Tong Wu --- configure|6 + libavcodec/Makefile |4 +- libavcodec/allcodecs.c |1 + libavcodec/d3d12va_encode.c | 1558 ++ libavcodec/d3d12va_encode.h | 339 +++ libavcodec/d3d12va_encode_hevc.c | 1007 +++ 6 files changed, 2914 insertions(+), 1 deletion(-) create mode 100644 libavcodec/d3d12va_encode.c create mode 100644 libavcodec/d3d12va_encode.h create mode 100644 libavcodec/d3d12va_encode_hevc.c diff --git a/configure b/configure index 18eeca89f2..f11b256c80 100755 --- a/configure +++ b/configure @@ -2547,6 +2547,7 @@ CONFIG_EXTRA=" cbs_mpeg2 cbs_vp8 cbs_vp9 +d3d12va_encode deflate_wrapper dirac_parse dnn @@ -3274,6 +3275,7 @@ wmv3_vaapi_hwaccel_select="vc1_vaapi_hwaccel" wmv3_vdpau_hwaccel_select="vc1_vdpau_hwaccel" # hardware-accelerated codecs +d3d12va_encode_deps="d3d12va ID3D12VideoEncoder d3d12_encoder_feature" mediafoundation_deps="mftransform_h MFCreateAlignedMemoryBuffer" omx_deps="libdl pthreads" omx_rpi_select="omx" @@ -3340,6 +3342,7 @@ h264_v4l2m2m_encoder_deps="v4l2_m2m h264_v4l2_m2m" hevc_amf_encoder_deps="amf" hevc_cuvid_decoder_deps="cuvid" hevc_cuvid_decoder_select="hevc_mp4toannexb_bsf" +hevc_d3d12va_encoder_select="cbs_h265 d3d12va_encode" hevc_mediacodec_decoder_deps="mediacodec" hevc_mediacodec_decoder_select="hevc_mp4toannexb_bsf hevc_parser" hevc_mediacodec_encoder_deps="mediacodec" @@ -6697,6 +6700,9 @@ check_type "windows.h d3d11.h" "ID3D11VideoDecoder" check_type "windows.h d3d11.h" "ID3D11VideoContext" check_type "windows.h d3d12.h" "ID3D12Device" check_type "windows.h d3d12video.h" "ID3D12VideoDecoder" +check_type "windows.h d3d12video.h" "ID3D12VideoEncoder" +test_code cc "windows.h d3d12video.h" "D3D12_FEATURE_VIDEO feature = D3D12_FEATURE_VIDEO_ENCODER_CODEC" && \ +test_code cc "windows.h d3d12video.h" "D3D12_FEATURE_DATA_VIDEO_ENCODER_RESOURCE_REQUIREMENTS req" && enable d3d12_encoder_feature check_type "windows.h" "DPI_AWARENESS_CONTEXT" -D_WIN32_WINNT=0x0A00 check_type "d3d9.h dxva2api.h" DXVA2_ConfigPictureDecode -D_WIN32_WINNT=0x0602 check_func_headers mfapi.h MFCreateAlignedMemoryBuffer -lmfplat diff --git a/libavcodec/Makefile b/libavcodec/Makefile index a2174dcb2f..ed1fa62f92 100644 --- a/libavcodec/Makefile +++ b/libavcodec/Makefile @@ -84,6 +84,7 @@ OBJS-$(CONFIG_CBS_JPEG)+= cbs_jpeg.o OBJS-$(CONFIG_CBS_MPEG2) += cbs_mpeg2.o OBJS-$(CONFIG_CBS_VP8) += cbs_vp8.o vp8data.o OBJS-$(CONFIG_CBS_VP9) += cbs_vp9.o +OBJS-$(CONFIG_D3D12VA_ENCODE) += d3d12va_encode.o hw_base_encode.o OBJS-$(CONFIG_DEFLATE_WRAPPER) += zlib_wrapper.o OBJS-$(CONFIG_DOVI_RPU)+= dovi_rpu.o OBJS-$(CONFIG_ERROR_RESILIENCE)+= error_resilience.o @@ -435,6 +436,7 @@ OBJS-$(CONFIG_HEVC_DECODER)+= hevcdec.o hevc_mvs.o \ h274.o aom_film_grain.o OBJS-$(CONFIG_HEVC_AMF_ENCODER)+= amfenc_hevc.o OBJS-$(CONFIG_HEVC_CUVID_DECODER) += cuviddec.o +OBJS-$(CONFIG_HEVC_D3D12VA_ENCODER)+= d3d12va_encode_hevc.o OBJS-$(CONFIG_HEVC_MEDIACODEC_DECODER) += mediacodecdec.o OBJS-$(CONFIG_HEVC_MEDIACODEC_ENCODER) += mediacodecenc.o OBJS-$(CONFIG_HEVC_MF_ENCODER) += mfenc.o mf_utils.o @@ -1264,7 +1266,7 @@ SKIPHEADERS+= %_tablegen.h \ SKIPHEADERS-$(CONFIG_AMF) += amfenc.h SKIPHEADERS-$(CONFIG_D3D11VA) += d3d11va.h dxva2_internal.h -SKIPHEADERS-$(CONFIG_D3D12VA) += d3d12va_decode.h +SKIPHEADERS-$(CONFIG_D3D12VA) += d3d12va_decode.h d3d12va_encode.h SKIPHEADERS-$(CONFIG_DXVA2)+= dxva2.h dxva2_internal.h SKIPHEADERS-$(CONFIG_JNI) += ffjni.h SKIPHEADERS-$(CONFIG_LCMS2)+= fflcms2.h diff --git a/libavcodec/allcodecs.c b/libavcodec/allcodecs.c index f4705651fb..de08eb722b 100644 --- a/libavcodec/allcodecs.c +++ b/libavcodec/allcodecs.c @@ -857,6 +857,7 @@ extern const FFCodec ff_h264_vaapi_encoder; extern const FFCodec ff_h264_videotoolbox_encoder; extern const FFCodec ff_hevc_amf_encoder; extern const FFCodec ff_hevc_cuvid_decoder; +extern const FFCodec ff_hevc_d3d12va_encoder; extern const FFCodec ff_hevc_mediacodec_decoder; extern const FFCodec ff_hevc_mediacodec_encoder; extern const FFCodec ff_hevc_mf_encoder; diff --git a/libavcodec/d3d12va_encode.c b/libavcodec/d3d12va_encode.c new file mode 100644 index 00..1ef9c7a16f --- /dev/null +++ b/libavcodec/d3d12va_encode.c @@ -0,0 +1,1558 @@ +/* + * Direct3D 12 HW acceleration v
Re: [FFmpeg-devel] [RFC] 5 year plan & Inovation
On 18 Apr 2024, at 9:52, Stefano Sabatini wrote: > On date Wednesday 2024-04-17 17:24:02 +0100, Andrew Sayers wrote: >> On 17/04/2024 14:58, Michael Niedermayer wrote: > [...] >> I've occasionally tried getting into ffmpeg for over a decade now, and have >> lurked here for the past few months as I put in the effort to grok it. >> On behalf of people who could contribute but don't, I'd like to suggest >> ffmpeg focus on *learnability*. >> > >> Whenever I've tried to learn ffmpeg, I've always been rebuffed by >> documentation that seems needlessly hard to use. I understand some of >> these reflect deeper issues - for example there's a reason the words >> "ffmpeg" and "libav" are used ambiguously, even though it makes it >> hard to differentiate between the library and the command-line tool. > >> But other issues seem like quick wins - for example I've lost count of >> all the times I typed two functions into Google, spent hours trying to >> make them work together, then finally realised I was looking at the >> documentation for 3.0 in one tab and 5.0 in the other. Surely you can >> just add a line to the top of the documentation like "click here to see >> the trunk version of this file"? > > Functions are documented in doxygen, so they depend on the major.minor > version, while you seem to refer to the FFmpeg version. Also on the > website we usually only have the latest mainline documentation, so I > don't understand how can you have different versions in different tabs > (unless you didn't update that tab since months/years). Thats not true and same things has happened to me multiple times, thats why I always have to check the URL to make sure the docs are the ones for master or latest release I am working with. For example see this ancient documentation here: https://ffmpeg.org/doxygen/1.2/index.html We generate those for each FFmpeg version afaik, not MAJOR-MINOR of the libraries: https://ffmpeg.org/doxygen/6.0/index.html Maybe Michael can clarify, as I have no way to check how these are actually generated for the website, if this is by branch of some other logic or completely manual. I do agree with OP that it would be VERY helpful to have some note there on old docs or some overview of the different versions at least, so that its clear you are looking at older ones… > > If you mean that we should ship documentatation for the latest > supported releases, in addition to latest mainline, I tend to agree. > >> Here's a small example to demonstrate the larger issue - >> what does it mean for something to be a "context"? >> When I started learning how to write ffmpeg code, I read through the >> docs and saw various things calling themselves "context" structs, but >> never found a link to explain what that meant. If I was a young >> developer, I would probably have just assumed it was standard >> programming jargon I was too dumb to know, and walked away to find >> something more my speed. But I'm old and stubborn and have nothing >> better to do right now, so I kept going... >> >> I tried to learn by going through the examples, but the nearest thing >> to an explanation was e.g. `transcode.c` making up a new type and >> calling it a `FilteringContext`. I ignored the AVClass documentation >> for a long time because the name made me think it was some kind of >> GObject-style C-with-classes thing. It was only when I noticed that >> it says it describes "the class of an AVClass context structure" that >> I realised what I was looking at. And it was only when I convinced >> myself that the documentation for AVOptions was using > >> "AVOptions-enabled struct" to mean the same thing as "AVClass context >> structure" that I felt able to disregard the `FilteringContext`. So >> my current opinion is that "AVOptions-enabled struct", "AVClass >> context structure" and "context structure" are different terms for the >> same thing - but now I've said that publicly, I will no doubt find an >> "SwrClass context structure" or something tomorrow. > > In general, a "context" in the FFmpeg jargon is usually a data > structure providing the context/state/configuration for a given > operation, which can be muxing, demuxing, decoding, encoding, > filtering etc. > > You need to fill the "context" with the configuration parameters and > with the data needed for the specific operation. > > In general, when setting up a context, you also want some facilities > to avoid to repeat logic again and again: > - you want to provide means to send log messages > - you want an interface to query, set, and get options > - you want a "private" internal context, with options/parameters > specific for a particular instance of a generic context. For example > you might want to set specific options which only apply to a given > encoder (these are so-called "private" options) > > This is done through the AVClass structure, which being generic is > used in various parts of FFmpeg. > > The AVOption interface wass added later, so
Re: [FFmpeg-devel] [RFC] 5 year plan & Inovation
On 18 Apr 2024, at 10:46, Stefano Sabatini wrote: > On date Wednesday 2024-04-17 15:58:32 +0200, Michael Niedermayer wrote: >> Hi all >> >> The pace of inovation in FFmpeg has been slowing down. >> Most work is concentarted nowadays on code refactoring, and adding >> support for new codecs and formats. >> >> Should we >> * make a list of longer term goals >> * vote on them >> * and then together work towards implementing them >> ? >> >> (The idea here is to increase the success of larger efforts >> than adding codecs and refactoring code) >> It would then also not be possible for individuals to object >> to a previously agreed goal. >> And it would add ideas for which we can try to get funding/grants for >> >> (larger scale changes need consensus first that we as a whole want >> them before we would be able to ask for funding/grants for them) >> >> Some ideas and why they would help FFmpeg: >> > [...] >> * client side / in browser support >> (expand towards webapps, webpages using ffmpeg client side in the >> browser) >> bring in more users and developers, and it will be costly for us >> if we let others take this area as its important and significant > > There are already several projects on github, the most prominent one: > https://github.com/ffmpegwasm/ffmpeg.wasm/ > > In general it would be useful to provide libav* bindings to other > languages, for example: > https://github.com/PyAV-Org/PyAV > https://github.com/zmwangx/rust-ffmpeg > > Not sure these should be really moved to FFmpeg though. > > One option I'm currenly exploring is having a python filter enabling > to specify a custom filter implemented in python (needed for custom > ad-hoc logic you don't really want to implement in C since it's not > generic enough) and to enable using python modules when effiency is > not an issue. Lua would probably be a better choice for this from ease of integration and also speed PoV last I checked. IIRC Python had some rather complex threading implications when used in a library. But I agree having something like this in general seems nice for some prototyping and debugging with filters as well. > ___ > 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] [RFC] 5 year plan & Inovation
Hello world, > [your idea here] Fully async API which provides a means to receive a notification when a frame is decoded / processed by filter etc. Be it a callback, conditional variable etc. чт, 18 апр. 2024 г. в 12:22, : > > > On 18 Apr 2024, at 10:46, Stefano Sabatini wrote: > > > On date Wednesday 2024-04-17 15:58:32 +0200, Michael Niedermayer wrote: > >> Hi all > >> > >> The pace of inovation in FFmpeg has been slowing down. > >> Most work is concentarted nowadays on code refactoring, and adding > >> support for new codecs and formats. > >> > >> Should we > >> * make a list of longer term goals > >> * vote on them > >> * and then together work towards implementing them > >> ? > >> > >> (The idea here is to increase the success of larger efforts > >> than adding codecs and refactoring code) > >> It would then also not be possible for individuals to object > >> to a previously agreed goal. > >> And it would add ideas for which we can try to get funding/grants for > >> > >> (larger scale changes need consensus first that we as a whole want > >> them before we would be able to ask for funding/grants for them) > >> > >> Some ideas and why they would help FFmpeg: > >> > > [...] > >> * client side / in browser support > >> (expand towards webapps, webpages using ffmpeg client side in the > browser) > >> bring in more users and developers, and it will be costly for us > >> if we let others take this area as its important and significant > > > > There are already several projects on github, the most prominent one: > > https://github.com/ffmpegwasm/ffmpeg.wasm/ > > > > In general it would be useful to provide libav* bindings to other > > languages, for example: > > https://github.com/PyAV-Org/PyAV > > https://github.com/zmwangx/rust-ffmpeg > > > > Not sure these should be really moved to FFmpeg though. > > > > One option I'm currenly exploring is having a python filter enabling > > to specify a custom filter implemented in python (needed for custom > > ad-hoc logic you don't really want to implement in C since it's not > > generic enough) and to enable using python modules when effiency is > > not an issue. > > Lua would probably be a better choice for this from ease of integration > and also speed PoV last I checked. IIRC Python had some rather complex > threading implications when used in a library. > > But I agree having something like this in general seems nice for some > prototyping and debugging with filters as well. > > > ___ > > 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] (no subject)
v2: Fixed fate errors in [Patch 2/2] v3: Fixed fate errors in [Patch 2/2] Subject:[PATCH V3][Loongarch]Optimize aac decode/encode for Loongarch by LSX In-Reply-To: ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH v3 1/2] avutil/loongarch: add LSX optimization for aac audio decode
Add functions: vector_fmul_window_lsx butterflies_float_lsx vector_fmul_scalar_lsx ./ffmpeg -i ../../1.aac -f null - before:482x after:523x --- libavutil/float_dsp.c | 2 + libavutil/float_dsp.h | 1 + libavutil/loongarch/Makefile | 5 +- libavutil/loongarch/float_dsp.S | 287 ++ libavutil/loongarch/float_dsp.h | 32 ++ .../loongarch/float_dsp_init_loongarch.c | 35 +++ 6 files changed, 361 insertions(+), 1 deletion(-) create mode 100644 libavutil/loongarch/float_dsp.S create mode 100644 libavutil/loongarch/float_dsp.h create mode 100644 libavutil/loongarch/float_dsp_init_loongarch.c diff --git a/libavutil/float_dsp.c b/libavutil/float_dsp.c index e9fb023466..7128ff3f96 100644 --- a/libavutil/float_dsp.c +++ b/libavutil/float_dsp.c @@ -162,6 +162,8 @@ av_cold AVFloatDSPContext *avpriv_float_dsp_alloc(int bit_exact) ff_float_dsp_init_x86(fdsp); #elif ARCH_MIPS ff_float_dsp_init_mips(fdsp); +#elif ARCH_LOONGARCH64 +ff_float_dsp_init_loongarch(fdsp); #endif return fdsp; } diff --git a/libavutil/float_dsp.h b/libavutil/float_dsp.h index 342a8715c5..679a930eab 100644 --- a/libavutil/float_dsp.h +++ b/libavutil/float_dsp.h @@ -206,6 +206,7 @@ void ff_float_dsp_init_ppc(AVFloatDSPContext *fdsp, int strict); void ff_float_dsp_init_riscv(AVFloatDSPContext *fdsp); void ff_float_dsp_init_x86(AVFloatDSPContext *fdsp); void ff_float_dsp_init_mips(AVFloatDSPContext *fdsp); +void ff_float_dsp_init_loongarch(AVFloatDSPContext *fdsp); /** * Allocate a float DSP context. diff --git a/libavutil/loongarch/Makefile b/libavutil/loongarch/Makefile index 2addd9351c..ae710f0515 100644 --- a/libavutil/loongarch/Makefile +++ b/libavutil/loongarch/Makefile @@ -1 +1,4 @@ -OBJS += loongarch/cpu.o +OBJS += loongarch/cpu.o \ + loongarch/float_dsp_init_loongarch.o + +LSX-OBJS += loongarch/float_dsp.o diff --git a/libavutil/loongarch/float_dsp.S b/libavutil/loongarch/float_dsp.S new file mode 100644 index 00..5073c8424f --- /dev/null +++ b/libavutil/loongarch/float_dsp.S @@ -0,0 +1,287 @@ +/* + * Loongarch LASX/LSX optimizeds dsp + * + * Copyright (c) 2024 Loongson Technology Corporation Limited + * Contributed by PengXu + * + * 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/loongarch/loongson_asm.S" + + +/* void vector_fmul_window(float *dst, const float *src0, + const float *src1, const float *win, int len) */ +function vector_fmul_window_lsx +addi.d sp, sp, -8 +st.d$r23, sp, 0 + +movet4, a0 +movet5, a1 +movet6, a2 +movet7, a3 +movet8, a4 +slli.d t8, t8, 2 + +add.d t4, t4, t8 +add.d t7, t7, t8 +add.d t5, t5, t8 + +add.d a6, $r0,t8 +addi.d a7, t8, -4 + +movea5, $r0 +srai.d t0, a4, 2 +beq a5, t0, .VFW02 + +.VFW01: +sub.d t1, t5, a6 +addi.d t2, a7, -12 +vld vr1,t1, 0x00 //s0 +vldxvr2,a2, t2//s1 + +sub.d t1, t7, a6 +vld vr3,t1, 0x00 //wi +vldxvr4,t7, t2//wj + +vpermi.wvr2,vr2,0x1b +vpermi.wvr4,vr4,0x1b + +vfmul.s vr5,vr2,vr3 +vfmsub.svr5,vr1,vr4,vr5 //dsti + +vfmul.s vr6,vr2,vr4 +vfmadd.svr6,vr1,vr3,vr6 //dstj + +vpermi.wvr6,vr6,0x1b + +sub.d t1, t4, a6 +vst vr5,t1, 0x00 +vstxvr6,t4, t2 + +addi.d a6, a6, -16 +addi.d a7, a7, -16 + +addi.d a5, a5, 1 +blt a5, t0, .VFW01 + +.VFW02: +andit0, a4, 2 +beq $r0,t0, .VFW03 + +sub.d t0, t5, a6 +addi.d t1, a7, -4 +add.d t1, t5, t1 + +sub.d t2, t7, a6 +addi.d t3, a7, -4 +
[FFmpeg-devel] [PATCH v3 2/2] avcodec/loongarch: add LSX optimization for aac audio encode
Add functions:
ff_abs_pow34_lsx
ff_aac_quantize_bands_lsx
./ffmpeg -f s16le -ac 2 -i ../../1.pcm -c:a aac -f null -
before:37.5x
after:48.1x
---
libavcodec/aacencdsp.h| 3 +
libavcodec/loongarch/Makefile | 2 +
.../loongarch/aacencdsp_init_loongarch.c | 44 +++
libavcodec/loongarch/aacencdsp_loongarch.S| 254 ++
4 files changed, 303 insertions(+)
create mode 100644 libavcodec/loongarch/aacencdsp_init_loongarch.c
create mode 100644 libavcodec/loongarch/aacencdsp_loongarch.S
diff --git a/libavcodec/aacencdsp.h b/libavcodec/aacencdsp.h
index 67836d8cf7..5db27a95a9 100644
--- a/libavcodec/aacencdsp.h
+++ b/libavcodec/aacencdsp.h
@@ -34,6 +34,7 @@ typedef struct AACEncDSPContext {
void ff_aacenc_dsp_init_riscv(AACEncDSPContext *s);
void ff_aacenc_dsp_init_x86(AACEncDSPContext *s);
+void ff_aacenc_dsp_init_loongarch(AACEncDSPContext *s);
static inline void abs_pow34_v(float *out, const float *in, const int size)
{
@@ -66,6 +67,8 @@ static inline void ff_aacenc_dsp_init(AACEncDSPContext *s)
ff_aacenc_dsp_init_riscv(s);
#elif ARCH_X86
ff_aacenc_dsp_init_x86(s);
+#elif ARCH_LOONGARCH64
+ff_aacenc_dsp_init_loongarch(s);
#endif
}
diff --git a/libavcodec/loongarch/Makefile b/libavcodec/loongarch/Makefile
index 07da2964e4..068fd61810 100644
--- a/libavcodec/loongarch/Makefile
+++ b/libavcodec/loongarch/Makefile
@@ -9,6 +9,7 @@ OBJS-$(CONFIG_HPELDSP)+=
loongarch/hpeldsp_init_loongarch.o
OBJS-$(CONFIG_IDCTDSP)+= loongarch/idctdsp_init_loongarch.o
OBJS-$(CONFIG_VIDEODSP) += loongarch/videodsp_init.o
OBJS-$(CONFIG_HEVC_DECODER) += loongarch/hevcdsp_init_loongarch.o
+OBJS-$(CONFIG_AAC_ENCODER)+= loongarch/aacencdsp_init_loongarch.o
LASX-OBJS-$(CONFIG_H264QPEL) += loongarch/h264qpel_lasx.o
LASX-OBJS-$(CONFIG_H264DSP) += loongarch/h264dsp_lasx.o \
loongarch/h264_deblock_lasx.o
@@ -38,3 +39,4 @@ LSX-OBJS-$(CONFIG_H264QPEL) += loongarch/h264qpel.o
\
loongarch/h264qpel_lsx.o
LSX-OBJS-$(CONFIG_H264CHROMA) += loongarch/h264chroma.o
LSX-OBJS-$(CONFIG_H264PRED) += loongarch/h264intrapred.o
+LSX-OBJS-$(CONFIG_AAC_ENCODER)+= loongarch/aacencdsp_loongarch.o
diff --git a/libavcodec/loongarch/aacencdsp_init_loongarch.c
b/libavcodec/loongarch/aacencdsp_init_loongarch.c
new file mode 100644
index 00..b5422d85b5
--- /dev/null
+++ b/libavcodec/loongarch/aacencdsp_init_loongarch.c
@@ -0,0 +1,44 @@
+/*
+ * AAC encoder assembly optimizations
+ * Copyright (c) 2024 Loongson Technology Corporation Limited
+ * Contributed by PengXu
+ *
+ * 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
+ */
+
+#ifndef AVCODEC_LOONGARCH_AACENC_H
+#define AVCODEC_LOONGARCH_AACENC_H
+
+#include "libavutil/loongarch/cpu.h"
+#include "libavcodec/aacenc.h"
+
+void ff_abs_pow34_lsx(float *out, const float *in, const int size);
+void ff_aac_quantize_bands_lsx(int *out, const float *in, const float *scaled,
+ int size, int is_signed, int maxval, const
float Q34,
+ const float rounding);
+
+av_cold void ff_aacenc_dsp_init_loongarch(AACEncDSPContext *s)
+{
+int cpu_flags = av_get_cpu_flags();
+
+if (have_lsx(cpu_flags)) {
+s->abs_pow34 = ff_abs_pow34_lsx;
+s->quant_bands = ff_aac_quantize_bands_lsx;
+}
+}
+
+#endif /* AVCODEC_LOONGARCH_AACENC_H */
\ No newline at end of file
diff --git a/libavcodec/loongarch/aacencdsp_loongarch.S
b/libavcodec/loongarch/aacencdsp_loongarch.S
new file mode 100644
index 00..b80bb98aa9
--- /dev/null
+++ b/libavcodec/loongarch/aacencdsp_loongarch.S
@@ -0,0 +1,254 @@
+/*
+ * Loongarch LASX/LSX optimizeds AAC encoder DSP functions
+ *
+ * Copyright (c) 2024 Loongson Technology Corporation Limited
+ * Contributed by PengXu
+ *
+ * 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 versio
Re: [FFmpeg-devel] [PATCH 4/6] doc/muxers: add mkvtimestamp_v2
On date Tuesday 2024-04-16 20:09:19 +0200, Andreas Rheinhardt wrote:
> Stefano Sabatini:
> > On date Tuesday 2024-04-16 12:50:19 +0200, Andreas Rheinhardt wrote:
> >> Stefano Sabatini:
> >>> ---
> >>> doc/muxers.texi | 8
> >>> 1 file changed, 8 insertions(+)
> >>>
> >>> diff --git a/doc/muxers.texi b/doc/muxers.texi
> >>> index f94513527d..490d5557bf 100644
> >>> --- a/doc/muxers.texi
> >>> +++ b/doc/muxers.texi
> >>> @@ -2933,6 +2933,14 @@ MicroDVD subtitle format muxer.
> >>>
> >>> This muxer accepts a single @samp{microdvd} subtitles stream.
> >>>
> >>> +@section mkvtimestamp_v2
> >>> +mkvtoolnix v2 timecode format muxer.
> >>> +
> >>> +Write the PTS rawvideo frame to the output, as supported by the
> >>> +@command{mkvextact} tool from the @command{mkvtoolnix} suite.
> >>> +
> >>> +This muxer accepts a single @samp{rawvideo} stream.
> >>> +
> >>> @section mp3
> >>>
> >>> The MP3 muxer writes a raw MP3 stream with the following optional
> >>> features:
> >>
> >
> >> This is wrong: MKVToolNix switched to "# timestamp format v2" a long
> >> time ago (we still write the old "# timecode format v2" header);
> >> furthermore, MKVToolNix actually uses pts (which it reorders to be
> >> ascending), not dts like our muxer. Furthermore MKVToolNix does not
> >> force a 1ms precision on timestamps.
> >
> > Correct.
> >
> > I compared the output of the muxer and of mkvtoolnix extract
> > timestamp_v2 and I'm not yet clear about the timestamp differences I'm
> > observing (the muxer output maps with the timestamps, the mkvtoolnix
> > timestamps differ by a few ms). But I think also mkvtoolnix use a 1ms
> > timebase.
>
> The accuracy of the timestamps output by mkvextract is determined by the
> TimestampScale of the file in question; it is most often 1ms when the
> file has video.
> You need to provide more details if you want these discrepancies to be
> analyzed.
Probably not worth the effort.
> > Also, IIRC there is no generic way to reorder PTSs, so this might
> > account for another difference which might be difficult to implement
> > generically.
>
> Write them into a buffer and reorder them at the end?
> (No, I have no intention to actually implement this. I am rather leaning
> to "this muxer should not exist".)
I also think we have better tools at this point (one being ffprobe
-show_packets) but we should not drop it before deprecating it.
Plan: av_tree to insert elements in a constant-size buffer or store in
a buffer sorted once at the end. We probably should skip PTS=NA
elements.
Dropping the doc patch as the implementation is broken.
Will apply the rest of the patchset soon.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 1/6] doc/muxers/matroskaenc: add missing options, apply misc style fixes
Stefano Sabatini:
> ---
> doc/muxers.texi | 44 +---
> 1 file changed, 37 insertions(+), 7 deletions(-)
>
> diff --git a/doc/muxers.texi b/doc/muxers.texi
> index a77472ef1b..a162ab4075 100644
> --- a/doc/muxers.texi
> +++ b/doc/muxers.texi
> @@ -2846,8 +2846,44 @@ the initially reserved space turns out to be
> insufficient.
>
> This option is ignored if the output is unseekable.
>
> +@item cluster_size_limit @var{size}
> +Store at most the provided amount of bytes in a cluster.
> +
> +If not specified, the limit is set automatically to a sensible
> +hardcoded fixed value.
> +
> +@item cluster_time_limit @var{duration}
> +Store at most the provided number of milliseconds in a cluster.
> +
> +If not specified, the limit is set automatically to a sensible
> +hardcoded fixed value.
> +
> +@item dash @var{bool}
> +Create a WebM file conforming to WebM DASH specification. By default
> +it is set to @code{false}.
> +
> +@item dash_track_number @var{index}
> +Track number for the DASH stream. By default it is set to @code{1}.
> +
> +@item live @var{bool}
> +Write files assuming it is a live stream. By default it is set to
> +@code{false}.
> +
> +@item allow_raw_vfw @var{bool}
> +Allow raw VFW mode. By default it is set to @code{false}.
> +
> +@item flipped_raw_rgb @var{bool}
> +If set to @code{true}, store positive height for raw RGB bitmaps, which
> indicates
> +bitmap is stored bottom-up. Note that this option does not flip the bitmap
> +which has to be done manually beforehand, e.g. by using the @samp{vflip}
> filter.
> +Default is @code{false} and indicates bitmap is stored top down.
> +
> +@item write_crc32 @var{bool}
> +Write a CRC32 element inside every Level 1 element. By default it is
> +set to @code{true}.
> +
State that this option is ignored fro WebM.
> @item default_mode @var{mode}
> -This option controls how the FlagDefault of the output tracks will be set.
> +Control how the FlagDefault of the output tracks will be set.
> It influences which tracks players should play by default. The default mode
> is @samp{passthrough}.
> @table @samp
> @@ -2865,12 +2901,6 @@ disposition default exists, no subtitle track will be
> marked as default.
> In this mode the FlagDefault is set if and only if the AV_DISPOSITION_DEFAULT
> flag is set in the disposition of the corresponding stream.
> @end table
> -
> -@item flipped_raw_rgb @var{bool}
> -If set to true, store positive height for raw RGB bitmaps, which indicates
> -bitmap is stored bottom-up. Note that this option does not flip the bitmap
> -which has to be done manually beforehand, e.g. by using the vflip filter.
> -Default is @var{false} and indicates bitmap is stored top down.
> @end table
>
> @anchor{md5}
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [RFC] 5 year plan & Inovation
> > On date Wednesday 2024-04-17 19:21:39 -0700, Aidan wrote: > > I submitted a patch for a TTML decoder because I thought it would be > great. > > It was completely ignored. > Please ping the patch or send a new one > I should probably redo my patch at this point. It's a year old. It's kind of a complicated patch because TTML is a huge format. It would be great to have a TTML decoder existing in FFmpeg. I guess if I do submit one, I will be more annoying about pinging. There is nowhere saying bumping every few weeks is ok. I read all documentation related to sending a patch. > > If my patch was seriously bad, then fine. But seriously *no one cared*. I think contribution management is a serious issue here. What happens when you send a patch is that if you're lucky someone > will be interested and put some effort to review and eventually get it > pushed, which depending on several factors might require several > interactions. > The only few times I've been completely ignored while trying to contribute to FLOSS software was software that ended up being forked with a better alternative because it was run by shitty people. However I am not saying that FFmpeg is that way. > Sometimes contributors are side-tracked or frustrated and the review > process is interrupted. Sometimes the reviewer won't reply, and the > review also might be stuck (in this case you might want to ping the > patch). > > Sometimes there is no qualified or interested developer around, or > maybe those ones are busy with other things (and it's easy to miss > a patch, especially if you don't check emails since a few days and you > got hundreds of backlog emails). > > In general, this is done on a best effort basis (read as: most > developers are volunteers and they might have job/families/stuff to > tend to), there is no guarantee that a patch might be reviewed in a > timely fashion. > > This is not a problem specific with FFmpeg, but in general with most > FLOSS projects. > > Probably we should find ways to fund such activites, so that a > developer can spend more time on reviewing work, but this comes with > other risks/issues (since managing money is also complex of potential > tensions in a mostly volunteering-based project) Yep, you are completely right. I cannot say you aren't right. > It's also very difficult to track the sent patches, and that's why > having a Pull-Request process a-la github has been proposed several > times; we cannot switch to github for several reasons (licensing and > affilitation issues with platform owner) and handling your own gitlab > is costly and we lack volunteers at the moment. I saw that conversation. It just sounds like over-complication for this project. Email can be okay if done right. Not user-friendly but if its documented good then its mostly fine. > > We are using patchwork to mitigate the tracking issue: > https://patchwork.ffmpeg.org/project/ffmpeg/list/ > > but that's not really providing an effective workflow. > > Personally I find the status tracking confusing, e.g.: > > https://patchwork.ffmpeg.org/project/ffmpeg/list/?series=&submitter=&state=&q=TTML&archive=both&delegate= > > I cannot easily figure out what was integrated and what not. > Funny to see my old patch on that list. Kind regards, Aidan / TheDaChicken ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [RFC] 5 year plan & Inovation
On 18/04/2024 10:13, epira...@gmail.com wrote: On 18 Apr 2024, at 9:52, Stefano Sabatini wrote: On date Wednesday 2024-04-17 17:24:02 +0100, Andrew Sayers wrote: On 17/04/2024 14:58, Michael Niedermayer wrote: [...] I've occasionally tried getting into ffmpeg for over a decade now, and have lurked here for the past few months as I put in the effort to grok it. On behalf of people who could contribute but don't, I'd like to suggest ffmpeg focus on *learnability*. [...] But other issues seem like quick wins - for example I've lost count of all the times I typed two functions into Google, spent hours trying to make them work together, then finally realised I was looking at the documentation for 3.0 in one tab and 5.0 in the other. Surely you can just add a line to the top of the documentation like "click here to see the trunk version of this file"? Functions are documented in doxygen, so they depend on the major.minor version, while you seem to refer to the FFmpeg version. Also on the website we usually only have the latest mainline documentation, so I don't understand how can you have different versions in different tabs (unless you didn't update that tab since months/years). Thats not true and same things has happened to me multiple times, thats why I always have to check the URL to make sure the docs are the ones for master or latest release I am working with. For example see this ancient documentation here: https://ffmpeg.org/doxygen/1.2/index.html I'm glad I'm not the only one making that mistake! In fact, older versions don't just exist, they're often the first link in Google. For example, typing "avformat_init_output" into Google and clicking on the first link takes me to [1] (version 3.2). The website doesn't have documentation for 6.1 or 7.0 ([2] and [3]), which might have made it look like only trunk is supported? I agree older versions should be documented (and 6.1/7.0 added), because sometimes you need to develop software that works with older versions, so you *want* to compare documentation between two tabs. If people reading the documentation should think in terms of major.minor, how about automatically editing the PROJECT_NUMBER in doc/Doxyfile to include that information? That wouldn't be obvious enough to solve the "two tabs" problem (e.g. I've had it with 1.0 documentation before now, even though the formatting is completely different), but it would at least mean the information is available on the page. We generate those for each FFmpeg version afaik, not MAJOR-MINOR of the libraries: https://ffmpeg.org/doxygen/6.0/index.html Maybe Michael can clarify, as I have no way to check how these are actually generated for the website, if this is by branch of some other logic or completely manual. I do agree with OP that it would be VERY helpful to have some note there on old docs or some overview of the different versions at least, so that its clear you are looking at older ones… Without getting too far off-topic, I would also be interested in knowing how docs are actually generated in practice. I've tried generating documentation locally and making cross-references between versions, but some functionality is hidden behind #ifdef's (e.g. deprecations), and I've never been able to work out the exact magic words the site uses. Also, the anchors for individual functions on the site don't always match the ones generated locally, so I can't e.g. create my own docs and link to the public ones. [snip - useful information about contexts] Well now I guess I have to stop procrastinating! I'll write up my understanding (which is probably still a bit wrong) and send in a patch for discussion. To bring this back to ffmpeg development - I made a note to write a patch saying they were synonyms and linking that explanation from e.g. AVCodecContext, but the job has been rotting away in my todo list for a month now waiting for me to be "sure I've got it right" (i.e. to give up a perfect excuse for procrastination). To be blunt, on some level it feels like I've put more in than I've got out of that problem, and haven't been able to psych myself up to submit a patch that could get me laughed out of the room (or worse, politely ignored). If the project was otherwise easy-to-learn, I would have felt a much stronger sense of obligation to pay that back. This looks like the usual pattern: experienced API developers don't feel the need to improve the docs, so they have no real incentives to do so; outsiders might need to improve it, but this means to understand the intricacies of the framework, and by the time they got it they probably don't need it anymore. Also writing good documentation - as writing good prose - is *hard*, but in general bad is better than nothing. I agree writing good documentation is hard, but IMHO FFmpeg's problem is just about optimisation, which people round here are excellent at. Whether optimising code or docs, you step through the process the hardware
Re: [FFmpeg-devel] [PATCH] avcodec/nvenc: High bit depth encoding for HEVC
Hi Timo,
Thank you for your review. Please check my answers below.
Best regards,
Diego
On 17.04.24, 16:27, "Timo Rothenpieler" wrote:
External email: Use caution opening links or attachments
On 15/04/2024 16:39, Diego Felix de Souza via ffmpeg-devel wrote:
> From: Diego Felix de Souza
>
> Adding 10-bit encoding support for HEVC if the input is 8-bit. In
> case of 8-bit input content, NVENC performs an internal CUDA 8 to
> 10-bit conversion of the input prior to encoding. Currently, only
> AV1 supports encoding 8-bit content as 10-bit.
I'm not sure about this one.
Since it's just "SW", or rather CUDA based, conversion, this job could
also be done by scale_cuda, outside of some niche formats it doesn't
support yet.
Which would also allow for more consistent command lines across versions.
Although it is a software-based solution, the conversion is integrated with
other kernels
inside the driver. In this way, it will demand fewer memory accesses and better
Streaming
Multiprocessor (SM) utilization, leading to a improved performance and a lower
latency
compared to the scale_cuda approach. Moreover, the proposed approach overall
consumes
less memory since it only requires an 8-bit per channel frame as input and no
extra 10-bit frames.
> Signed-off-by: Diego Felix de Souza
> ---
> libavcodec/nvenc.c | 8
> libavcodec/nvenc_hevc.c | 1 +
> 2 files changed, 5 insertions(+), 4 deletions(-)
>
> diff --git a/libavcodec/nvenc.c b/libavcodec/nvenc.c
> index 794174a53f..c302cc7dc4 100644
> --- a/libavcodec/nvenc.c
> +++ b/libavcodec/nvenc.c
> @@ -514,7 +514,7 @@ static int nvenc_check_capabilities(AVCodecContext *avctx)
> }
>
> ret = nvenc_check_cap(avctx, NV_ENC_CAPS_SUPPORT_10BIT_ENCODE);
> -if (IS_10BIT(ctx->data_pix_fmt) && ret <= 0) {
> +if ((IS_10BIT(ctx->data_pix_fmt) || ctx->highbitdepth) && ret <= 0) {
> av_log(avctx, AV_LOG_WARNING, "10 bit encode not supported\n");
> return AVERROR(ENOSYS);
> }
> @@ -1421,7 +1421,7 @@ static av_cold int
> nvenc_setup_hevc_config(AVCodecContext *avctx)
> }
>
> // force setting profile as main10 if input is 10 bit
> -if (IS_10BIT(ctx->data_pix_fmt)) {
> +if (IS_10BIT(ctx->data_pix_fmt) || ctx->highbitdepth) {
Won't this need guarded behind the NVENC_HAVE_NEW_BIT_DEPTH_API as well?
Or would this also work fine with older headers, by just setting this?
For older SDK versions, the HEVC main 10 profile would be selected, but the
encoded bitstream
would be still 8-bits. For the sake of consistence and clarity, I will put it
behind the
NVENC_HAVE_NEW_BIT_DEPTH_API as you suggested.
> cc->profileGUID = NV_ENC_HEVC_PROFILE_MAIN10_GUID;
> avctx->profile = AV_PROFILE_HEVC_MAIN_10;
> }
> @@ -1435,8 +1435,8 @@ static av_cold int
> nvenc_setup_hevc_config(AVCodecContext *avctx)
> hevc->chromaFormatIDC = IS_YUV444(ctx->data_pix_fmt) ? 3 : 1;
>
> #ifdef NVENC_HAVE_NEW_BIT_DEPTH_API
> -hevc->inputBitDepth = hevc->outputBitDepth =
> -IS_10BIT(ctx->data_pix_fmt) ? NV_ENC_BIT_DEPTH_10 :
> NV_ENC_BIT_DEPTH_8;
> +hevc->inputBitDepth = IS_10BIT(ctx->data_pix_fmt) ? NV_ENC_BIT_DEPTH_10
> : NV_ENC_BIT_DEPTH_8;
> +hevc->outputBitDepth = (IS_10BIT(ctx->data_pix_fmt) ||
> ctx->highbitdepth) ? NV_ENC_BIT_DEPTH_10 : NV_ENC_BIT_DEPTH_8;
> #else
> hevc->pixelBitDepthMinus8 = IS_10BIT(ctx->data_pix_fmt) ? 2 : 0;
> #endif
> diff --git a/libavcodec/nvenc_hevc.c b/libavcodec/nvenc_hevc.c
> index b949cb1bd7..02e9c9c8eb 100644
> --- a/libavcodec/nvenc_hevc.c
> +++ b/libavcodec/nvenc_hevc.c
> @@ -183,6 +183,7 @@ static const AVOption options[] = {
> { "fullres", "Two Pass encoding is enabled where first Pass is
> full resolution",
> 0,
> AV_OPT_TYPE_CONST, { .i64 = NV_ENC_TWO_PASS_FULL_RESOLUTION },0,
> 0, VE, .unit =
> "multipass" },
> #endif
> +{ "highbitdepth", "Enable 10 bit encode for 8 bit
> input",OFFSET(highbitdepth),AV_OPT_TYPE_BOOL, { .i64 = 0 }, 0, 1, VE },
Same question as above, does this always work, even without the new bit
depth API?
If not, it also needs the #ifdef.
Same as above, it would give the wrong impression to the user. I will put it
behind the NVENC_HAVE_NEW_BIT_DEPTH_API.
> #ifdef NVENC_HAVE_LDKFS
> { "ldkfs","Low delay key frame scale; Specifies the Scene
> Change frame size increase allowed in case of single frame VBV and CBR",
> OFFSET(ldkfs),
> AV_OPT_TYPE_INT, { .i64 = 0 }, 0, UCHAR_MAX, VE },
> --
> 2.34.1
>
> ---
> NVIDIA GmbH
> Wuerselen
> Amtsgericht Aachen
> HRB 8361
> Managing Directors: Rebecca Peters, Donald Robertson, Janet Hall, Ludwig von
> Reiche
>
> -
Re: [FFmpeg-devel] [PATCH] avformat/httpauth.c Support RFC7616 [Style fixed]
On date Monday 2024-04-15 19:56:48 +0200, Stefano Sabatini wrote:
> On date Monday 2024-04-15 02:32:14 +, �� | Eugene wrote:
> > Update digest authentication in httpauth.c
> >
> > - Refactor make_digest_auth() to support RFC 2617 and RFC 7617
> > - Add support for SHA-256 and SHA-512/256 algorithms along with MD5
> > - MD5 and SHA-256 tested, but SHA-512/256 untested due to lack of server
> > - Replace AVMD5 structure with AVHashContext for hash algorithm flexibility
> > - Rename update_md5_strings() to update_hash_strings() for consistency
> > - Address coding style feedback from reviewer:
> >
> > This is a feature update focused on digest authentication enhancements.
> > Some lint issues in the existing code remain unaddressed in this patch.
> >
> > Signed-off-by: Eugene-bitsensing
> > ---
>
> > libavformat/httpauth.c | 102 +
> > 1 file changed, 53 insertions(+), 49 deletions(-)
>
> add entry to Changelog?
Updated the patch with a few fixes, please check in attachment.
[...]
> nit++: to avoid semantic overlap I'd rather name this
> selected_algorithm
>
> > +if (!*algorithm) {
> > +algorithm = "MD5"; // if empty, use MD5 as Default
> > +hashing_algorithm = "MD5";
> > +} else if (av_stristr(algorithm, "MD5")) {
> > +hashing_algorithm = "MD5";
> > +} else if (av_stristr(algorithm, "sha256") || av_stristr(algorithm,
> > "sha-256")) {
> > +hashing_algorithm = "SHA256";
> > +len_hash = 65; // SHA-2: 64 characters.
> > +} else if (av_stristr(algorithm, "sha512-256") ||
> > av_stristr(algorithm, "sha-512-256")) {
> > +hashing_algorithm = "SHA512_256";
> > +len_hash = 65; // SHA-2: 64 characters.
I'm concerned by this, as it will never be reached because the "sha256"
branch is always selected instead, that's why this should be made an
exact match?
>From 2b88a2f64569bb83c0f519983385c35c217bbf9c Mon Sep 17 00:00:00 2001
From: "eug...@bitsensing.com"
Date: Mon, 15 Apr 2024 02:32:14 +
Subject: [PATCH] avformat/httpauth.c: support RFC7616 authentication
- Refactor make_digest_auth() to support RFC 2617 and RFC 7617
- Add support for SHA-256 and SHA-512/256 algorithms along with MD5
- MD5 and SHA-256 tested, but SHA-512/256 untested due to lack of server
- Replace AVMD5 structure with AVHashContext for hash algorithm flexibility
- Rename update_md5_strings() to update_hash_strings() for consistency
Signed-off-by: Eugene-bitsensing
---
Changelog | 1 +
libavformat/httpauth.c | 104 +
2 files changed, 55 insertions(+), 50 deletions(-)
diff --git a/Changelog b/Changelog
index 8db14f02b4..5db501f8c4 100644
--- a/Changelog
+++ b/Changelog
@@ -7,6 +7,7 @@ version :
- ffmpeg CLI filtergraph chaining
- LC3/LC3plus demuxer and muxer
- pad_vaapi, drawbox_vaapi filters
+- HTTP protocol RFC7617 authentication
version 7.0:
diff --git a/libavformat/httpauth.c b/libavformat/httpauth.c
index 9048362509..90210e6179 100644
--- a/libavformat/httpauth.c
+++ b/libavformat/httpauth.c
@@ -25,7 +25,7 @@
#include "libavutil/mem.h"
#include "internal.h"
#include "libavutil/random_seed.h"
-#include "libavutil/md5.h"
+#include "libavutil/hash.h"
#include "urldecode.h"
static void handle_basic_params(HTTPAuthState *state, const char *key,
@@ -118,36 +118,36 @@ void ff_http_auth_handle_header(HTTPAuthState *state, const char *key,
}
}
-
-static void update_md5_strings(struct AVMD5 *md5ctx, ...)
+static void update_hash_strings(struct AVHashContext *hash_ctx, ...)
{
va_list vl;
-va_start(vl, md5ctx);
+va_start(vl, hash_ctx);
while (1) {
-const char* str = va_arg(vl, const char*);
+const char *str = va_arg(vl, const char*);
if (!str)
break;
-av_md5_update(md5ctx, str, strlen(str));
+av_hash_update(hash_ctx, (const uint8_t *)str, strlen(str));
}
va_end(vl);
}
-/* Generate a digest reply, according to RFC 2617. */
+/* Generate a digest reply, according to RFC 2617/7617 */
static char *make_digest_auth(HTTPAuthState *state, const char *username,
const char *password, const char *uri,
const char *method)
{
DigestParams *digest = &state->digest_params;
-int len;
+size_t len;
uint32_t cnonce_buf[2];
char cnonce[17];
char nc[9];
-int i;
-char A1hash[33], A2hash[33], response[33];
-struct AVMD5 *md5ctx;
-uint8_t hash[16];
+int i, ret;
+char a1_hash[65], a2_hash[65], response[65];
+struct AVHashContext *hash_ctx = NULL;
+size_t len_hash = 33; // Modifiable hash length, MD5:32, SHA-2:64
char *authstr;
+const char *algorithm, *hashing_algorithm;
digest->nc++;
snprintf(nc, sizeof(nc), "%08x", digest->nc);
@@ -157,52 +157,56 @@ static char *make_digest_auth(HTTPAuthState *state, const char *username,
cno
[FFmpeg-devel] [PATCH v3 1/5] avcodec/evc: Set the AV_FRAME_FLAG_KEY flag for a decoded frame when the decoded packet contains a keyframe
Signed-off-by: Dawid Kozinski
---
libavcodec/libxevd.c | 4
1 file changed, 4 insertions(+)
diff --git a/libavcodec/libxevd.c b/libavcodec/libxevd.c
index c6c7327e65..de641d85f4 100644
--- a/libavcodec/libxevd.c
+++ b/libavcodec/libxevd.c
@@ -415,6 +415,10 @@ static int libxevd_receive_frame(AVCodecContext *avctx,
AVFrame *frame)
return AVERROR(EAGAIN);
}
} else {
+if (stat.stype == XEVD_ST_I) {
+frame->pict_type = AV_PICTURE_TYPE_I;
+frame->flags |= AV_FRAME_FLAG_KEY;
+}
return libxevd_return_frame(avctx, frame, imgb,
&pkt_au);
}
}
--
2.25.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH v3 2/5] avcodec/bitstream_filters: Declaration of the ff_evc_frame_merge_bsf variable has been moved to the appropriate following the alphabetical order
Signed-off-by: Dawid Kozinski --- libavcodec/bitstream_filters.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/libavcodec/bitstream_filters.c b/libavcodec/bitstream_filters.c index 12860c332b..138246c50e 100644 --- a/libavcodec/bitstream_filters.c +++ b/libavcodec/bitstream_filters.c @@ -34,6 +34,7 @@ extern const FFBitStreamFilter ff_dca_core_bsf; extern const FFBitStreamFilter ff_dts2pts_bsf; extern const FFBitStreamFilter ff_dv_error_marker_bsf; extern const FFBitStreamFilter ff_eac3_core_bsf; +extern const FFBitStreamFilter ff_evc_frame_merge_bsf; extern const FFBitStreamFilter ff_extract_extradata_bsf; extern const FFBitStreamFilter ff_filter_units_bsf; extern const FFBitStreamFilter ff_h264_metadata_bsf; @@ -67,7 +68,6 @@ extern const FFBitStreamFilter ff_vp9_superframe_bsf; extern const FFBitStreamFilter ff_vp9_superframe_split_bsf; extern const FFBitStreamFilter ff_vvc_metadata_bsf; extern const FFBitStreamFilter ff_vvc_mp4toannexb_bsf; -extern const FFBitStreamFilter ff_evc_frame_merge_bsf; #include "libavcodec/bsf_list.c" -- 2.25.1 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH v3 3/5] avformat/avi: Added EVC codec tag to the list of supported codec_id-codec_tag pairs for AVI muxer
Signed-off-by: Dawid Kozinski
---
libavformat/riff.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/libavformat/riff.c b/libavformat/riff.c
index 157976583c..306dc3b47a 100644
--- a/libavformat/riff.c
+++ b/libavformat/riff.c
@@ -506,6 +506,7 @@ const AVCodecTag ff_codec_bmp_tags[] = {
{ AV_CODEC_ID_RTV1, MKTAG('R', 'T', 'V', '1') },
{ AV_CODEC_ID_VMIX, MKTAG('V', 'M', 'X', '1') },
{ AV_CODEC_ID_LEAD, MKTAG('L', 'E', 'A', 'D') },
+{ AV_CODEC_ID_EVC, MKTAG('e', 'v', 'c', '1') },
{ AV_CODEC_ID_NONE, 0 }
};
--
2.25.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH v3 4/5] avcodec/evc: Reference to ISO_IEC_23094-1-2020 document section for EVC_MAX_APS_COUNT enum has been fixed
Signed-off-by: Dawid Kozinski
---
libavcodec/evc.h | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/libavcodec/evc.h b/libavcodec/evc.h
index e493455a42..d68dc74997 100644
--- a/libavcodec/evc.h
+++ b/libavcodec/evc.h
@@ -106,15 +106,15 @@ enum EVCSliceType {
};
enum {
-// 7.4.3.2: aps_video_parameter_set_id is u(4).
-EVC_MAX_APS_COUNT = 32,
-
// 7.4.3.1: sps_seq_parameter_set_id is in [0, 15].
EVC_MAX_SPS_COUNT = 16,
// 7.4.3.2: pps_pic_parameter_set_id is in [0, 63].
EVC_MAX_PPS_COUNT = 64,
+// 7.4.3.3: adaptional_parameter_set_id is in [0, 31].
+EVC_MAX_APS_COUNT = 32,
+
// 7.4.5: slice header slice_pic_parameter_set_id in [0, 63]
EVC_MAX_SH_COUNT = 64,
--
2.25.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH v3 5/5] avformat/evc: Small fixes in documentation
Signed-off-by: Dawid Kozinski --- libavformat/evc.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/libavformat/evc.c b/libavformat/evc.c index fabccb054c..2f4c74fe51 100644 --- a/libavformat/evc.c +++ b/libavformat/evc.c @@ -233,7 +233,7 @@ static int evcc_write(AVIOContext *pb, EVCDecoderConfigurationRecord *evcc) /* unsigned int(8) profile_idc */ avio_w8(pb, evcc->profile_idc); -/* unsigned int(8) profile_idc */ +/* unsigned int(8) level_idc */ avio_w8(pb, evcc->level_idc); /* unsigned int(32) toolset_idc_h */ @@ -254,7 +254,7 @@ static int evcc_write(AVIOContext *pb, EVCDecoderConfigurationRecord *evcc) /* unsigned int(16) pic_width_in_luma_samples; */ avio_wb16(pb, evcc->pic_width_in_luma_samples); -/* unsigned int(16) pic_width_in_luma_samples; */ +/* unsigned int(16) pic_height_in_luma_samples; */ avio_wb16(pb, evcc->pic_height_in_luma_samples); /* -- 2.25.1 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH v3 08/13] avcodec/dovi_rpudec: make `enable` also affect decoding
On Thu, 18 Apr 2024 13:30:39 +0200 Andreas Rheinhardt
wrote:
> Niklas Haas:
> > From: Niklas Haas
> >
> > This could be used by codecs to selectively disable parsing Dolby Vision
> > RPUs, and is cheap to support.
> > ---
> > libavcodec/av1dec.c | 1 +
> > libavcodec/dovi_rpu.h| 2 ++
> > libavcodec/dovi_rpudec.c | 6 ++
> > libavcodec/hevcdec.c | 1 +
> > libavcodec/libdav1d.c| 1 +
> > 5 files changed, 11 insertions(+)
> >
> > diff --git a/libavcodec/av1dec.c b/libavcodec/av1dec.c
> > index 4c1405df77..20865b4f12 100644
> > --- a/libavcodec/av1dec.c
> > +++ b/libavcodec/av1dec.c
> > @@ -1551,6 +1551,7 @@ static void av1_decode_flush(AVCodecContext *avctx)
> > static const AVOption av1_options[] = {
> > { "operating_point", "Select an operating point of the scalable
> > bitstream",
> >OFFSET(operating_point), AV_OPT_TYPE_INT, { .i64
> > = 0 }, 0, AV1_MAX_OPERATING_POINTS - 1, VD },
> > +{ "dolbyvision", "Decode Dolby Vision RPUs", OFFSET(dovi.enable),
> > AV_OPT_TYPE_BOOL, {.i64 = 1 }, 0, 1, VD },
> > { NULL }
> > };
> >
> > diff --git a/libavcodec/dovi_rpu.h b/libavcodec/dovi_rpu.h
> > index 3e80647422..8f8905b96b 100644
> > --- a/libavcodec/dovi_rpu.h
> > +++ b/libavcodec/dovi_rpu.h
> > @@ -37,6 +37,8 @@ typedef struct DOVIContext {
> > *
> > * For encoding, FF_DOVI_AUTOMATIC enables Dolby Vision only if
> > * avctx->decoded_side_data contains an AVDOVIMetadata.
> > + *
> > + * For decoding, FF_DOVI_AUTOMATIC has the same meaning as 1.
> > */
> > #define FF_DOVI_AUTOMATIC -1
> > int enable;
> > diff --git a/libavcodec/dovi_rpudec.c b/libavcodec/dovi_rpudec.c
> > index 7c7eda9d09..978d5dfc2b 100644
> > --- a/libavcodec/dovi_rpudec.c
> > +++ b/libavcodec/dovi_rpudec.c
> > @@ -37,6 +37,9 @@ int ff_dovi_attach_side_data(DOVIContext *s, AVFrame
> > *frame)
> > AVDOVIMetadata *dovi;
> > size_t dovi_size, ext_sz;
> >
> > +if (!s->enable)
> > +return 0;
> > +
> > if (!s->mapping || !s->color)
> > return 0; /* incomplete dovi metadata */
> >
> > @@ -306,6 +309,9 @@ int ff_dovi_rpu_parse(DOVIContext *s, const uint8_t
> > *rpu, size_t rpu_size,
> > uint8_t use_nlq;
> > uint8_t profile;
> >
> > +if (!s->enable)
> > +return 0;
> > +
> > if (rpu_size < 5)
> > goto fail;
> >
> > diff --git a/libavcodec/hevcdec.c b/libavcodec/hevcdec.c
> > index 7825efe2e6..c622a48b94 100644
> > --- a/libavcodec/hevcdec.c
> > +++ b/libavcodec/hevcdec.c
> > @@ -3694,6 +3694,7 @@ static const AVOption options[] = {
> > AV_OPT_TYPE_BOOL, {.i64 = 0}, 0, 1, PAR },
> > { "strict-displaywin", "stricly apply default display window size",
> > OFFSET(apply_defdispwin),
> > AV_OPT_TYPE_BOOL, {.i64 = 0}, 0, 1, PAR },
> > +{ "dolbyvision", "Decode Dolby Vision RPUs", OFFSET(dovi_ctx.enable),
> > AV_OPT_TYPE_BOOL, {.i64 = 1 }, 0, 1, PAR },
> > { NULL },
> > };
> >
> > diff --git a/libavcodec/libdav1d.c b/libavcodec/libdav1d.c
> > index 09fe767fb8..f9e1a181fc 100644
> > --- a/libavcodec/libdav1d.c
> > +++ b/libavcodec/libdav1d.c
> > @@ -674,6 +674,7 @@ static const AVOption libdav1d_options[] = {
> > { "filmgrain", "Apply Film Grain", OFFSET(apply_grain),
> > AV_OPT_TYPE_BOOL, { .i64 = -1 }, -1, 1, VD | AV_OPT_FLAG_DEPRECATED },
> > { "oppoint", "Select an operating point of the scalable bitstream",
> > OFFSET(operating_point), AV_OPT_TYPE_INT, { .i64 = -1 }, -1, 31, VD },
> > { "alllayers", "Output all spatial layers", OFFSET(all_layers),
> > AV_OPT_TYPE_BOOL, { .i64 = 0 }, 0, 1, VD },
> > +{ "dolbyvision", "Decode Dolby Vision RPUs", OFFSET(dovi.enable),
> > AV_OPT_TYPE_BOOL, {.i64 = 1 }, 0, 1, VD },
> > { NULL }
> > };
> >
>
> Is parsing this stuff very expensive? If not, I don't really see a
> reason to add an option for it (we also do not add options for lots of
> other side data types).
>
> - Andreas
It's not expensive, no. Well, having DV metadata present technically
alters the interpretation of the video quite substantially (e.g. SDR
streams now displaying as HDR), so users may want *some* way of
"globally" disabling it.
That said, it's probably better to relegate that to `vf_sidedata`.
I'll drop this commit from the series, then.
>
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
> To unsubscribe, visit link above, or email
> ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] avcodec/nvenc: High bit depth encoding for HEVC
Hi Diego,
Asking for my own education.
As far as you've explained, the 8 > 10 bit conversion happens within the
driver, that's understandable.
But how does it influence the output? Does it perform some sort of
proprietary SDR > HDR conversion under the hood that maps the ranges?
What's gonna be the user observable difference between these 2 scenarios?
1) 8 bit input > HEVC 8 bit profile > 8 bit HEVC output
2) 8 bit input > 10 bit up conversion > HEVC 10 bit profile > 10 bit HEVC
output
Better visual quality? Smaller compressed file size?
In other words, what's the purpose of this feature except enabling new
Video Codec SDK capability?
чт, 18 апр. 2024 г. в 13:44, Diego Felix de Souza via ffmpeg-devel <
ffmpeg-devel@ffmpeg.org>:
> Hi Timo,
>
> Thank you for your review. Please check my answers below.
>
> Best regards,
>
> Diego
>
> On 17.04.24, 16:27, "Timo Rothenpieler" wrote:
>
> External email: Use caution opening links or attachments
>
>
> On 15/04/2024 16:39, Diego Felix de Souza via ffmpeg-devel wrote:
> > From: Diego Felix de Souza
> >
> > Adding 10-bit encoding support for HEVC if the input is 8-bit. In
> > case of 8-bit input content, NVENC performs an internal CUDA 8 to
> > 10-bit conversion of the input prior to encoding. Currently, only
> > AV1 supports encoding 8-bit content as 10-bit.
>
> I'm not sure about this one.
> Since it's just "SW", or rather CUDA based, conversion, this job could
> also be done by scale_cuda, outside of some niche formats it doesn't
> support yet.
> Which would also allow for more consistent command lines across versions.
>
>
> Although it is a software-based solution, the conversion is integrated
> with other kernels
> inside the driver. In this way, it will demand fewer memory accesses and
> better Streaming
> Multiprocessor (SM) utilization, leading to a improved performance and a
> lower latency
> compared to the scale_cuda approach. Moreover, the proposed approach
> overall consumes
> less memory since it only requires an 8-bit per channel frame as input and
> no extra 10-bit frames.
>
>
> > Signed-off-by: Diego Felix de Souza
> > ---
> > libavcodec/nvenc.c | 8
> > libavcodec/nvenc_hevc.c | 1 +
> > 2 files changed, 5 insertions(+), 4 deletions(-)
> >
> > diff --git a/libavcodec/nvenc.c b/libavcodec/nvenc.c
> > index 794174a53f..c302cc7dc4 100644
> > --- a/libavcodec/nvenc.c
> > +++ b/libavcodec/nvenc.c
> > @@ -514,7 +514,7 @@ static int nvenc_check_capabilities(AVCodecContext
> *avctx)
> > }
> >
> > ret = nvenc_check_cap(avctx, NV_ENC_CAPS_SUPPORT_10BIT_ENCODE);
> > -if (IS_10BIT(ctx->data_pix_fmt) && ret <= 0) {
> > +if ((IS_10BIT(ctx->data_pix_fmt) || ctx->highbitdepth) && ret <= 0)
> {
> > av_log(avctx, AV_LOG_WARNING, "10 bit encode not supported\n");
> > return AVERROR(ENOSYS);
> > }
> > @@ -1421,7 +1421,7 @@ static av_cold int
> nvenc_setup_hevc_config(AVCodecContext *avctx)
> > }
> >
> > // force setting profile as main10 if input is 10 bit
> > -if (IS_10BIT(ctx->data_pix_fmt)) {
> > +if (IS_10BIT(ctx->data_pix_fmt) || ctx->highbitdepth) {
>
> Won't this need guarded behind the NVENC_HAVE_NEW_BIT_DEPTH_API as well?
> Or would this also work fine with older headers, by just setting this?
>
> For older SDK versions, the HEVC main 10 profile would be selected, but
> the encoded bitstream
> would be still 8-bits. For the sake of consistence and clarity, I will put
> it behind the
> NVENC_HAVE_NEW_BIT_DEPTH_API as you suggested.
>
> > cc->profileGUID = NV_ENC_HEVC_PROFILE_MAIN10_GUID;
> > avctx->profile = AV_PROFILE_HEVC_MAIN_10;
> > }
> > @@ -1435,8 +1435,8 @@ static av_cold int
> nvenc_setup_hevc_config(AVCodecContext *avctx)
> > hevc->chromaFormatIDC = IS_YUV444(ctx->data_pix_fmt) ? 3 : 1;
> >
> > #ifdef NVENC_HAVE_NEW_BIT_DEPTH_API
> > -hevc->inputBitDepth = hevc->outputBitDepth =
> > -IS_10BIT(ctx->data_pix_fmt) ? NV_ENC_BIT_DEPTH_10 :
> NV_ENC_BIT_DEPTH_8;
> > +hevc->inputBitDepth = IS_10BIT(ctx->data_pix_fmt) ?
> NV_ENC_BIT_DEPTH_10 : NV_ENC_BIT_DEPTH_8;
> > +hevc->outputBitDepth = (IS_10BIT(ctx->data_pix_fmt) ||
> ctx->highbitdepth) ? NV_ENC_BIT_DEPTH_10 : NV_ENC_BIT_DEPTH_8;
> > #else
> > hevc->pixelBitDepthMinus8 = IS_10BIT(ctx->data_pix_fmt) ? 2 : 0;
> > #endif
> > diff --git a/libavcodec/nvenc_hevc.c b/libavcodec/nvenc_hevc.c
> > index b949cb1bd7..02e9c9c8eb 100644
> > --- a/libavcodec/nvenc_hevc.c
> > +++ b/libavcodec/nvenc_hevc.c
> > @@ -183,6 +183,7 @@ static const AVOption options[] = {
> > { "fullres", "Two Pass encoding is enabled where first Pass
> is full resolution",
> > 0,
> AV_OPT_TYPE_CONST, { .i64 = NV_ENC_TWO_PASS_FULL_RESOLUTION },
> 0, 0, VE, .unit =
> "multipass" },
> > #endif
> > +{ "highbitdepth", "Enable 10 bit encode for 8 bit
>
Re: [FFmpeg-devel] [PATCH] avcodec/nvenc: High bit depth encoding for HEVC
On 18/04/2024 14:29, Roman Arzumanyan wrote: Hi Diego, Asking for my own education. As far as you've explained, the 8 > 10 bit conversion happens within the driver, that's understandable. But how does it influence the output? Does it perform some sort of proprietary SDR > HDR conversion under the hood that maps the ranges? What's gonna be the user observable difference between these 2 scenarios? 1) 8 bit input > HEVC 8 bit profile > 8 bit HEVC output 2) 8 bit input > 10 bit up conversion > HEVC 10 bit profile > 10 bit HEVC output Better visual quality? Smaller compressed file size? In other words, what's the purpose of this feature except enabling new Video Codec SDK capability? Video Codecs tend to be more efficient with 10 bit, even if it's just 8 bit content that's been up-converted to 10 bit. I.e. yes, it'll (Or can, at least. Not sure if it's a given.) produce smaller/higher quality content for the same input. As for the exact reason, I can't explain, but it's a well known concept. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [RFC] 5 year plan & Inovation
On Wed, 17 Apr 2024 15:58:32 +0200 Michael Niedermayer wrote: > Hi all > > The pace of inovation in FFmpeg has been slowing down. > Most work is concentarted nowadays on code refactoring, and adding > support for new codecs and formats. > > Should we > * make a list of longer term goals > * vote on them > * and then together work towards implementing them > ? > > (The idea here is to increase the success of larger efforts > than adding codecs and refactoring code) > It would then also not be possible for individuals to object > to a previously agreed goal. > And it would add ideas for which we can try to get funding/grants for > > (larger scale changes need consensus first that we as a whole want > them before we would be able to ask for funding/grants for them) > > Some ideas and why they would help FFmpeg: > > * Switch to a plugin architecture > (Increase the number of developers willing to contribute and reduce > friction as the team and community grows) This would almost surely hurt productivity as it will require exposing, versioning, documenting and maintaining a vast number of internal APIs which we are currently at the liberty of modifying freely. > * ffchat > (expand into realtime chat / zoom) this would > bring in more users and developers, and we basically have almost > all parts for it already but some people where against it This seems like a user application on top of FFmpeg, not something that should be part of FFmpeg core. Can you explain what modifications in FFmpeg would be necessary for something like this? > * client side / in browser support > (expand towards webapps, webpages using ffmpeg client side in the browser) > bring in more users and developers, and it will be costly for us > if we let others take this area as its important and significant I don't understand this point - don't all major browsers already vendor FFmpeg for decoding? > * AI / neural network filters and codecs > The future seems to be AI based. Future Filters and Codecs will use > neural networks. FFmpeg can be at the forefront, developing these We already have TensorFlow support, no? (vf_sr etc.) What more is needed? > * [your idea here] > > thx > > -- > Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB > > It is what and why we do it that matters, not just one of them. > ___ > 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/3] doc: Explain what "context" means
Based largely on the explanation by Stefano Sabatini:
https://ffmpeg.org/pipermail/ffmpeg-devel/2024-April/325854.html
---
doc/jargon.md | 96 +++
1 file changed, 96 insertions(+)
create mode 100644 doc/jargon.md
diff --git a/doc/jargon.md b/doc/jargon.md
new file mode 100644
index 00..3b78ffb61f
--- /dev/null
+++ b/doc/jargon.md
@@ -0,0 +1,96 @@
+# Jargon
+
+Terms used throughout the code that developers may need to know.
+
+@anchor context
+
+## Context
+
+A design pattern that stores the context (e.g. configuration) for a series
+of operations in a "context" structure, and moves other information elsewhere.
+
+Consider a trivial program to print uppercase text:
+
+```c
+/*
+ * Contextual information about where to print a series of messages
+ */
+struct UpperCasePrinterContext {
+FILE* out;
+};
+
+/*
+ * Extra information about messages to print.
+ * This could be used multiple times in a single context,
+ * or reused several times across multiple contexts.
+ */
+struct PrintInfo {
+char* str;
+};
+
+void print(
+struct UpperCasePrinterContext * ctx,
+struct PrintInfo * info
+) {
+for ( char* c = info->str; *c; ++c ) {
+char C = toupper(*c);
+fwrite( &C, 1, 1, ctx->out );
+}
+}
+
+int main()
+{
+struct PrintInfo hello, world;
+struct UpperCasePrinterContext ctx;
+
+hello.str = "hello, ";
+world.str = "world!\n";
+
+ctx.out = stdout;
+
+print( &ctx, &hello );
+print( &ctx, &world );
+
+return 0;
+}
+```
+
+The `UpperCasePrinterContext` object contains the information that's about
+the context of the current job (i.e. printing things to standard output).
+Information with a lifetime different than that of the context is moved
+to the `PrintInfo` object.
+
+FFmpeg's main context structures all happen to face some common problems:
+
+- querying, setting and getting options
+- handling "private" internal context, including options for
+ a particular instance of the generic context
+- configuring log message verbosity and content
+
+FFmpeg gradually converged on the AVClass struct to store this information,
+then converged on the @ref avoptions "AVOptions" system to manipulate it,
+so modern code often uses the terms "context", "AVClass context structure"
+and "AVOptions-enabled struct" interchangeably. But it is occasionally
+necessary to distinguish between them - for example, AVMediaCodecContext
+is a context that does not use AVClass.
+
+To understand how this all works, consider some requirements for the
+`libx264` encoder:
+
+- it has to support common encoder options like "bitrate"
+- it has to support encoder-specific options like "profile"
+- it has to provide useful feedback about unsupported options
+
+Common encoder options like "bitrate" are stored in the AVCodecContext class,
+while encoder-specific options like "profile" are stored in an X264Context
+instance in AVCodecContext::priv_data. These options are then exposed to
+users through a tree of AVOption objects, which include user-visible help
+text and machine-readable information about the memory location to read/write
+each option. Common @ref avoptions "AVOptions" functionality lets you get
+and set those values, and provides readable feedback about errors. Although
+X264Context can be set by users, it is not part of the public interface,
+so new releases can modify it without affecting the API version.
+
+FFmpeg itself uses context structures to handle FFmpeg-specific problems,
+but the design pattern, as well as the AVClass and @ref avoptions "AVOptions"
+implementations, are general solutions you can use for any purpose.
--
2.43.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 2/3] lavu: Clarify relationship between AVClass, AVOption and context
---
libavutil/log.h | 11 ---
libavutil/opt.h | 7 ---
2 files changed, 12 insertions(+), 6 deletions(-)
diff --git a/libavutil/log.h b/libavutil/log.h
index ab7ceabe22..b5c739dab1 100644
--- a/libavutil/log.h
+++ b/libavutil/log.h
@@ -59,9 +59,14 @@ typedef enum {
struct AVOptionRanges;
/**
- * Describe the class of an AVClass context structure. That is an
- * arbitrary struct of which the first field is a pointer to an
- * AVClass struct (e.g. AVCodecContext, AVFormatContext etc.).
+ * Metadata about an arbitrary data structure
+ *
+ * A @ref context "context struct" whose first member is a pointer
+ * to an AVClass object is called an "AVClass context structure"
+ * (e.g. AVCodecContext, AVFormatContext etc.).
+ *
+ * AVClass is often combined with @ref avoptions "AVOptions" to create
+ * "AVOptions-enabled structs" that can be easily configured by users.
*/
typedef struct AVClass {
/**
diff --git a/libavutil/opt.h b/libavutil/opt.h
index e6013662f6..b817d15554 100644
--- a/libavutil/opt.h
+++ b/libavutil/opt.h
@@ -39,9 +39,10 @@
* @defgroup avoptions AVOptions
* @ingroup lavu_data
* @{
- * AVOptions provide a generic system to declare options on arbitrary structs
- * ("objects"). An option can have a help text, a type and a range of possible
- * values. Options may then be enumerated, read and written to.
+ * Builds on AVClass, adding a generic system to declare options.
+ *
+ * An option can have a help text, a type and a range of possible values.
+ * Options may then be enumerated, read and written to.
*
* There are two modes of access to members of AVOption and its child structs.
* One is called 'native access', and refers to access from the code that
--
2.43.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 3/3] all: Link to "context" from all contexts with documentation
Some headings needed to be rewritten to accomodate the text,
(hopefully) without changing the meaning.
---
libavcodec/aacdec.h | 2 +-
libavcodec/aacenc.h | 2 +-
libavcodec/ac3enc.h | 2 +-
libavcodec/amfenc.h | 2 +-
libavcodec/atrac.h | 2 +-
libavcodec/avcodec.h | 3 ++-
libavcodec/bsf.h | 2 +-
libavcodec/d3d11va.h | 3 +--
libavcodec/mediacodec.h | 2 +-
libavcodec/qsv.h | 6 --
libavcodec/sbr.h | 2 +-
libavcodec/vdpau.h | 3 ++-
libavcodec/videotoolbox.h| 5 +++--
libavfilter/avfilter.h | 2 +-
libavformat/avformat.h | 3 ++-
libavformat/avio.h | 3 ++-
libavutil/hwcontext.h| 21 -
libavutil/hwcontext_cuda.h | 2 +-
libavutil/hwcontext_d3d11va.h| 4 ++--
libavutil/hwcontext_d3d12va.h| 6 +++---
libavutil/hwcontext_drm.h| 2 +-
libavutil/hwcontext_dxva2.h | 4 ++--
libavutil/hwcontext_mediacodec.h | 2 +-
libavutil/hwcontext_opencl.h | 4 ++--
libavutil/hwcontext_qsv.h| 4 ++--
libavutil/hwcontext_vaapi.h | 6 +++---
libavutil/hwcontext_vdpau.h | 2 +-
libavutil/hwcontext_vulkan.h | 4 ++--
28 files changed, 57 insertions(+), 48 deletions(-)
diff --git a/libavcodec/aacdec.h b/libavcodec/aacdec.h
index 1b245f9258..3a5317cd54 100644
--- a/libavcodec/aacdec.h
+++ b/libavcodec/aacdec.h
@@ -181,7 +181,7 @@ typedef struct DynamicRangeControl {
} DynamicRangeControl;
/**
- * main AAC decoding context
+ * main AAC decoding @ref context "context"
*/
typedef struct AACDecContext {
const struct AVClass *class;
diff --git a/libavcodec/aacenc.h b/libavcodec/aacenc.h
index 8899f90ac7..c91f99bc6c 100644
--- a/libavcodec/aacenc.h
+++ b/libavcodec/aacenc.h
@@ -193,7 +193,7 @@ typedef struct AACPCEInfo {
} AACPCEInfo;
/**
- * AAC encoder context
+ * AAC encoder @ref context "context"
*/
typedef struct AACEncContext {
AVClass *av_class;
diff --git a/libavcodec/ac3enc.h b/libavcodec/ac3enc.h
index 227744d27f..68d8736f7a 100644
--- a/libavcodec/ac3enc.h
+++ b/libavcodec/ac3enc.h
@@ -151,7 +151,7 @@ typedef struct AC3Block {
} AC3Block;
/**
- * AC-3 encoder private context.
+ * AC-3 encoder private @ref context "context"
*/
typedef struct AC3EncodeContext {
AVClass *av_class; ///< AVClass used for AVOption
diff --git a/libavcodec/amfenc.h b/libavcodec/amfenc.h
index 2dbd378ef8..71138e7f76 100644
--- a/libavcodec/amfenc.h
+++ b/libavcodec/amfenc.h
@@ -43,7 +43,7 @@ typedef struct AmfTraceWriter {
} AmfTraceWriter;
/**
-* AMF encoder context
+* AMF encoder @ref context "context"
*/
typedef struct AmfContext {
diff --git a/libavcodec/atrac.h b/libavcodec/atrac.h
index 05208bbee6..acdd0a741a 100644
--- a/libavcodec/atrac.h
+++ b/libavcodec/atrac.h
@@ -39,7 +39,7 @@ typedef struct AtracGainInfo {
} AtracGainInfo;
/**
- * Gain compensation context structure.
+ * Gain compensation @ref context "context"
*/
typedef struct AtracGCContext {
float gain_tab1[16]; ///< gain compensation level table
diff --git a/libavcodec/avcodec.h b/libavcodec/avcodec.h
index 968009a192..a1f1430dde 100644
--- a/libavcodec/avcodec.h
+++ b/libavcodec/avcodec.h
@@ -430,7 +430,8 @@ typedef struct RcOverride{
#define AV_GET_ENCODE_BUFFER_FLAG_REF (1 << 0)
/**
- * main external API structure.
+ * @ref context "Context" for an encode or decode session
+ *
* New fields can be added to the end with minor version bumps.
* Removal, reordering and changes to existing fields require a major
* version bump.
diff --git a/libavcodec/bsf.h b/libavcodec/bsf.h
index a09c69f242..23c3cc87e4 100644
--- a/libavcodec/bsf.h
+++ b/libavcodec/bsf.h
@@ -56,7 +56,7 @@
*/
/**
- * The bitstream filter state.
+ * Bitstream filter @ref context "context"
*
* This struct must be allocated with av_bsf_alloc() and freed with
* av_bsf_free().
diff --git a/libavcodec/d3d11va.h b/libavcodec/d3d11va.h
index 27f40e5519..087c99f161 100644
--- a/libavcodec/d3d11va.h
+++ b/libavcodec/d3d11va.h
@@ -46,8 +46,7 @@
*/
/**
- * This structure is used to provides the necessary configurations and data
- * to the Direct3D11 FFmpeg HWAccel implementation.
+ * @ref context "Context" for the Direct3D11 FFmpeg HWAccel implementation
*
* The application must make it available as AVCodecContext.hwaccel_context.
*
diff --git a/libavcodec/mediacodec.h b/libavcodec/mediacodec.h
index 4e9b56a618..d983e7ff1a 100644
--- a/libavcodec/mediacodec.h
+++ b/libavcodec/mediacodec.h
@@ -26,7 +26,7 @@
#include "libavcodec/avcodec.h"
/**
- * This structure holds a reference to a android/view/Surface object that will
+ * @ref context "Context" for the android/view/Surface object that will
* be used as output by the decoder.
*
*/
diff --git a/libavcodec/qsv.h b/libavcodec/qsv.h
index c156
[FFmpeg-devel] [PATCH] avutil/frame: remove comment about avcodec_get_frame_class()
The function was deprecated a while back and deleted last year.
---
libavutil/frame.h | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/libavutil/frame.h b/libavutil/frame.h
index 68a2ad1555..60bb966f8b 100644
--- a/libavutil/frame.h
+++ b/libavutil/frame.h
@@ -369,8 +369,7 @@ typedef struct AVRegionOfInterest {
* to the end with a minor bump.
*
* Fields can be accessed through AVOptions, the name string used, matches the
- * C structure field name for fields accessible through AVOptions. The AVClass
- * for AVFrame can be obtained from avcodec_get_frame_class()
+ * C structure field name for fields accessible through AVOptions.
*/
typedef struct AVFrame {
#define AV_NUM_DATA_POINTERS 8
--
2.43.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] avutil/frame: remove comment about avcodec_get_frame_class()
On 4/18/2024 12:17 PM, Andrew Sayers wrote:
The function was deprecated a while back and deleted last year.
---
libavutil/frame.h | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/libavutil/frame.h b/libavutil/frame.h
index 68a2ad1555..60bb966f8b 100644
--- a/libavutil/frame.h
+++ b/libavutil/frame.h
@@ -369,8 +369,7 @@ typedef struct AVRegionOfInterest {
* to the end with a minor bump.
*
* Fields can be accessed through AVOptions, the name string used, matches the
- * C structure field name for fields accessible through AVOptions. The AVClass
- * for AVFrame can be obtained from avcodec_get_frame_class()
+ * C structure field name for fields accessible through AVOptions.
*/
typedef struct AVFrame {
#define AV_NUM_DATA_POINTERS 8
Applied, thanks.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] avformat/mov: ignore old infe box versions
On 4/13/2024 10:11 AM, James Almer wrote:
Some files with no image items have them, and were working prior to the recent
HEIF parsing overhaul.
Ignore such boxes instead, to recover the old behavior.
Fixes a regression since d9fed9df2a9e70c9375d3b2591db35c09303d369.
Signed-off-by: James Almer
---
libavformat/mov.c | 13 -
1 file changed, 8 insertions(+), 5 deletions(-)
diff --git a/libavformat/mov.c b/libavformat/mov.c
index 0c892b56c8..160e0b14fb 100644
--- a/libavformat/mov.c
+++ b/libavformat/mov.c
@@ -8137,8 +8137,8 @@ static int mov_read_infe(MOVContext *c, AVIOContext *pb,
MOVAtom atom, int idx)
size -= 4;
if (version < 2) {
-av_log(c->fc, AV_LOG_ERROR, "infe: version < 2 not supported\n");
-return AVERROR_PATCHWELCOME;
+avpriv_report_missing_feature(c->fc, "infe version < 2");
+return 1;
}
item_id = version > 2 ? avio_rb32(pb) : avio_rb16(pb);
@@ -8209,6 +8209,8 @@ static int mov_read_iinf(MOVContext *c, AVIOContext *pb,
MOVAtom atom)
ret = mov_read_infe(c, pb, infe, i);
if (ret < 0)
return ret;
+if (ret)
+return 0;
}
c->found_iinf = 1;
@@ -9508,14 +9510,15 @@ static int mov_read_header(AVFormatContext *s)
av_log(s, AV_LOG_ERROR, "error reading header\n");
return err;
}
-} while ((pb->seekable & AVIO_SEEKABLE_NORMAL) && !mov->found_moov &&
!mov->found_iloc && !mov->moov_retry++);
-if (!mov->found_moov && !mov->found_iloc) {
+} while ((pb->seekable & AVIO_SEEKABLE_NORMAL) &&
+ !mov->found_moov && !mov->found_iloc && !mov->found_iinf &&
!mov->moov_retry++);
+if (!mov->found_moov && !mov->found_iloc && !mov->found_iinf) {
av_log(s, AV_LOG_ERROR, "moov atom not found\n");
return AVERROR_INVALIDDATA;
}
av_log(mov->fc, AV_LOG_TRACE, "on_parse_exit_offset=%"PRId64"\n",
avio_tell(pb));
-if (mov->found_iloc) {
+if (mov->found_iloc && mov->found_iinf) {
for (i = 0; i < mov->nb_heif_item; i++) {
HEIFItem *item = &mov->heif_item[i];
MOVStreamContext *sc;
Will apply.
___
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 v12 0/8] [WIP] webp: add support for animated WebP decoding
Hi, On 17.04.24 00:52, James Zern via ffmpeg-devel wrote: On Wed, Apr 17, 2024 at 12:20 PM Thilo Borgmann via ffmpeg-devel wrote: From: Thilo Borgmann Marked WIP because we'd want to introduce private bsf's first; review welcome before that though VP8 decoder decoupled again The whole animated sequence goes into one packet The (currently public) bitstream filter splits animations up into non-conformant packets Now with XMP metadata support (as string, like MOV) Tests mostly work for me. There are a few images (that I reported earlier) that give: thanks for testing! Canvas change detected. The output will be damaged. Use -threads 1 to try decoding with best effort. They don't animate without that option and with it render incorrectly. That issue yields from the canvas frame being the synchronization object (ThreadFrame) - doing so prevents the canvas size changed mid-stream. _Maybe_ this can be fixed switching the whole frame multithreading away from ThreadFrame to sth else, not sure though and no experience with the alternatives (AVExecutor?). Maybe Andreas can predict if it's worth/valid to change that whole part of it? I'm not against putting more effort into it to get it right. A few other notes: - should ffprobe report anything with files containing xmp? It does, it is put into the frame metadata as a blob. ./ffprobe -show_frames will reveal it. - 0 duration behaves differently than web browsers, which use the gif behavior and set it to 10; as long as it's consistent in ffmpeg between the two either is fine to me. We are consistent to GIF in ffmpeg. Both do assume 100ms default delay. Notice the defaults in their defines (ms for webp, fps for gif) in the demuxers: #define WEBP_DEFAULT_DELAY 100 #define GIF_DEFAULT_DELAY 10 - The files in https://crbug.com/690848 don't exit cleanly from ffplay, other corrupt files do; ffmpeg exits, so maybe it's a non-issue. ffplay always crashes after any file on osx for me. If ffmpeg terminates fine, it's a non-issue for that patchset. I'll however look into it once I can, I hear people saying their ffplay not always crashes... Thanks! -Thilo ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH] lavc/vvc: Skip enhancement layer NAL units
The native VVC decoder does not yet support quality/spatial/multiview
scalability. Bitstreams requiring this feature could cause crashes.
Patch fixes this by skipping NAL units which are not in the base layer,
warning the user while doing so.
Signed-off-by: Frank Plowman
---
libavcodec/vvc/dec.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/libavcodec/vvc/dec.c b/libavcodec/vvc/dec.c
index a4fc40b40a..5249ddf989 100644
--- a/libavcodec/vvc/dec.c
+++ b/libavcodec/vvc/dec.c
@@ -785,6 +785,11 @@ static int decode_nal_unit(VVCContext *s, VVCFrameContext
*fc, const H2645NAL *n
s->temporal_id = nal->temporal_id;
+if (nal->nuh_layer_id > 0) {
+avpriv_report_missing_feature(fc->log_ctx, "Multilayer");
+return AVERROR_PATCHWELCOME;
+}
+
switch (unit->type) {
case VVC_VPS_NUT:
case VVC_SPS_NUT:
--
2.44.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 v12 0/8] [WIP] webp: add support for animated WebP decoding
On Thu, Apr 18, 2024 at 11:21 AM Thilo Borgmann via ffmpeg-devel wrote: > > Hi, > > On 17.04.24 00:52, James Zern via ffmpeg-devel wrote: > > On Wed, Apr 17, 2024 at 12:20 PM Thilo Borgmann via ffmpeg-devel > > wrote: > >> > >> From: Thilo Borgmann > >> > >> Marked WIP because we'd want to introduce private bsf's first; review > >> welcome before that though > >> VP8 decoder decoupled again > >> The whole animated sequence goes into one packet > >> The (currently public) bitstream filter splits animations up into > >> non-conformant packets > >> Now with XMP metadata support (as string, like MOV) > >> > > > > Tests mostly work for me. There are a few images (that I reported > > earlier) that give: > > thanks for testing! > > > >Canvas change detected. The output will be damaged. Use -threads 1 > > to try decoding with best effort. > > They don't animate without that option and with it render incorrectly. > > That issue yields from the canvas frame being the synchronization object > (ThreadFrame) - doing so prevents the canvas size changed mid-stream. > _Maybe_ this can be fixed switching the whole frame multithreading away > from ThreadFrame to sth else, not sure though and no experience with the > alternatives (AVExecutor?). Maybe Andreas can predict if it's > worth/valid to change that whole part of it? I'm not against putting > more effort into it to get it right. > > > > A few other notes: > > - should ffprobe report anything with files containing xmp? > > It does, it is put into the frame metadata as a blob. > ./ffprobe -show_frames > will reveal it. > Thanks. I didn't try that option. > > > - 0 duration behaves differently than web browsers, which use the gif > > behavior and set it to 10; as long as it's consistent in ffmpeg > > between the two either is fine to me. > > We are consistent to GIF in ffmpeg. Both do assume 100ms default delay. > Notice the defaults in their defines (ms for webp, fps for gif) in the > demuxers: > > #define WEBP_DEFAULT_DELAY 100 > #define GIF_DEFAULT_DELAY 10 > It doesn't seem the default delay is getting applied to this file: http://littlesvr.ca/apng/images/SteamEngine.webp Or at least the rendering is off in ffplay. The duration of all frames are 0 in that file. > > > > - The files in https://crbug.com/690848 don't exit cleanly from > > ffplay, other corrupt files do; ffmpeg exits, so maybe it's a > > non-issue. > > ffplay always crashes after any file on osx for me. If ffmpeg terminates > fine, it's a non-issue for that patchset. I'll however look into it once > I can, I hear people saying their ffplay not always crashes... > > Thanks! > -Thilo > ___ > 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/vvc: Skip enhancement layer NAL units
On 4/18/2024 3:59 PM, Frank Plowman wrote:
The native VVC decoder does not yet support quality/spatial/multiview
scalability. Bitstreams requiring this feature could cause crashes.
Patch fixes this by skipping NAL units which are not in the base layer,
warning the user while doing so.
Signed-off-by: Frank Plowman
---
libavcodec/vvc/dec.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/libavcodec/vvc/dec.c b/libavcodec/vvc/dec.c
index a4fc40b40a..5249ddf989 100644
--- a/libavcodec/vvc/dec.c
+++ b/libavcodec/vvc/dec.c
@@ -785,6 +785,11 @@ static int decode_nal_unit(VVCContext *s, VVCFrameContext
*fc, const H2645NAL *n
s->temporal_id = nal->temporal_id;
+if (nal->nuh_layer_id > 0) {
+avpriv_report_missing_feature(fc->log_ctx, "Multilayer");
A more verbose message would be better.
+return AVERROR_PATCHWELCOME;
+}
+
switch (unit->type) {
case VVC_VPS_NUT:
case VVC_SPS_NUT:
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [RFC] 5 year plan & Inovation
On Thu, Apr 18, 2024 at 11:22:09AM +0100, Andrew Sayers wrote: > On 18/04/2024 10:13, epira...@gmail.com wrote: > > On 18 Apr 2024, at 9:52, Stefano Sabatini wrote: > > > On date Wednesday 2024-04-17 17:24:02 +0100, Andrew Sayers wrote: > > > > On 17/04/2024 14:58, Michael Niedermayer wrote: > > > [...] > > > > I've occasionally tried getting into ffmpeg for over a decade now, and > > > > have > > > > lurked here for the past few months as I put in the effort to grok it. > > > > On behalf of people who could contribute but don't, I'd like to suggest > > > > ffmpeg focus on *learnability*. > > > > > [...] > > > > But other issues seem like quick wins - for example I've lost count of > > > > all the times I typed two functions into Google, spent hours trying to > > > > make them work together, then finally realised I was looking at the > > > > documentation for 3.0 in one tab and 5.0 in the other. Surely you can > > > > just add a line to the top of the documentation like "click here to see > > > > the trunk version of this file"? > > > Functions are documented in doxygen, so they depend on the major.minor > > > version, while you seem to refer to the FFmpeg version. Also on the > > > website we usually only have the latest mainline documentation, so I > > > don't understand how can you have different versions in different tabs > > > (unless you didn't update that tab since months/years). > > Thats not true and same things has happened to me multiple times, > > thats why I always have to check the URL to make sure the docs > > are the ones for master or latest release I am working with. > > > > For example see this ancient documentation here: > > https://ffmpeg.org/doxygen/1.2/index.html > > I'm glad I'm not the only one making that mistake! In fact, older versions > don't just exist, they're often the first link in Google. For example, > typing "avformat_init_output" into Google and clicking on the first link > takes me to [1] (version 3.2). > > The website doesn't have documentation for 6.1 or 7.0 ([2] and [3]), the docs for master are generated by a cronjob the docs for releases are manually generated, thx for reminding me about it, ive generated the 6.1 and 7.0 ones now [...] > Without getting too far off-topic, I would also be interested in knowing how > docs are actually generated in practice. I've tried generating documentation its just running doxygen with a Doxyfile the Doxyfile is not doc/Doxyfile from git because that could be a security issue. But its a very similar file thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Dictatorship: All citizens are under surveillance, all their steps and actions recorded, for the politicians to enforce control. Democracy: All politicians are under surveillance, all their steps and actions recorded, for the citizens to enforce control. 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] [RFC] 5 year plan & Inovation
On 4/18/2024 4:50 PM, Michael Niedermayer wrote: On Thu, Apr 18, 2024 at 11:22:09AM +0100, Andrew Sayers wrote: On 18/04/2024 10:13, epira...@gmail.com wrote: On 18 Apr 2024, at 9:52, Stefano Sabatini wrote: On date Wednesday 2024-04-17 17:24:02 +0100, Andrew Sayers wrote: On 17/04/2024 14:58, Michael Niedermayer wrote: [...] I've occasionally tried getting into ffmpeg for over a decade now, and have lurked here for the past few months as I put in the effort to grok it. On behalf of people who could contribute but don't, I'd like to suggest ffmpeg focus on *learnability*. [...] But other issues seem like quick wins - for example I've lost count of all the times I typed two functions into Google, spent hours trying to make them work together, then finally realised I was looking at the documentation for 3.0 in one tab and 5.0 in the other. Surely you can just add a line to the top of the documentation like "click here to see the trunk version of this file"? Functions are documented in doxygen, so they depend on the major.minor version, while you seem to refer to the FFmpeg version. Also on the website we usually only have the latest mainline documentation, so I don't understand how can you have different versions in different tabs (unless you didn't update that tab since months/years). Thats not true and same things has happened to me multiple times, thats why I always have to check the URL to make sure the docs are the ones for master or latest release I am working with. For example see this ancient documentation here: https://ffmpeg.org/doxygen/1.2/index.html I'm glad I'm not the only one making that mistake! In fact, older versions don't just exist, they're often the first link in Google. For example, typing "avformat_init_output" into Google and clicking on the first link takes me to [1] (version 3.2). The website doesn't have documentation for 6.1 or 7.0 ([2] and [3]), the docs for master are generated by a cronjob the docs for releases are manually generated, thx for reminding me about it, ive generated the 6.1 and 7.0 ones now I updated https://ffmpeg.org/documentation.html with links to them. [...] Without getting too far off-topic, I would also be interested in knowing how docs are actually generated in practice. I've tried generating documentation its just running doxygen with a Doxyfile the Doxyfile is not doc/Doxyfile from git because that could be a security issue. But its a very similar file thx [...] ___ 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] [RFC] 5 year plan & Inovation
On Thu, Apr 18, 2024 at 10:19:50AM +0200, Stefano Sabatini wrote: > On date Wednesday 2024-04-17 19:21:39 -0700, Aidan wrote: > > The best option is to figure stuff out. > [...] > > I use FFmpeg to download HLS streams from the internet or convert files > > like probably most people do. FFmpeg is the ultimate way of doing this > > because there is no better option. > > > > But there are issues: > [...] > > > I submitted a patch for a TTML decoder because I thought it would be great. > > It was completely ignored. > > Please ping the patch or send a new one. > > > If my patch was seriously bad, then fine. But seriously *no one cared*. > > I think contribution management is a serious issue here. > > What happens when you send a patch is that if you're lucky someone > will be interested and put some effort to review and eventually get it > pushed, which depending on several factors might require several > interactions. > > Sometimes contributors are side-tracked or frustrated and the review > process is interrupted. Sometimes the reviewer won't reply, and the > review also might be stuck (in this case you might want to ping the > patch). > > Sometimes there is no qualified or interested developer around, or > maybe those ones are busy with other things (and it's easy to miss > a patch, especially if you don't check emails since a few days and you > got hundreds of backlog emails). > > In general, this is done on a best effort basis (read as: most > developers are volunteers and they might have job/families/stuff to > tend to), there is no guarantee that a patch might be reviewed in a > timely fashion. > > This is not a problem specific with FFmpeg, but in general with most > FLOSS projects. > > Probably we should find ways to fund such activites, so that a > developer can spend more time on reviewing work, but this comes with > other risks/issues (since managing money is also complex of potential > tensions in a mostly volunteering-based project). > > It's also very difficult to track the sent patches, and that's why > having a Pull-Request process a-la github has been proposed several > times; we cannot switch to github for several reasons (licensing and > affilitation issues with platform owner) and handling your own gitlab > is costly and we lack volunteers at the moment. > > We are using patchwork to mitigate the tracking issue: > https://patchwork.ffmpeg.org/project/ffmpeg/list/ > > but that's not really providing an effective workflow. > > Personally I find the status tracking confusing, e.g.: > https://patchwork.ffmpeg.org/project/ffmpeg/list/?series=&submitter=&state=&q=TTML&archive=both&delegate= > > I cannot easily figure out what was integrated and what not. Would it help if i add a "patch" type to trac.ffmpeg.org ? If patches are missed on patchwork or its confusing, then patch authors could open such a ticket type=patch that points to the patchwork patch as tickets have all the metadata from keywords over priority to component and do also allow voting. It may help keeping track of patches and also allow the community to express their preferance with voting. thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB When the tyrant has disposed of foreign enemies by conquest or treaty, and there is nothing more to fear from them, then he is always stirring up some war or other, in order that the people may require a leader. -- Plato signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] lavc/vvc: Skip enhancement layer NAL units
On 18/04/2024 20:43, James Almer wrote:
> On 4/18/2024 3:59 PM, Frank Plowman wrote:
>> The native VVC decoder does not yet support quality/spatial/multiview
>> scalability. Bitstreams requiring this feature could cause crashes.
>> Patch fixes this by skipping NAL units which are not in the base layer,
>> warning the user while doing so.
>>
>> Signed-off-by: Frank Plowman
>> ---
>> libavcodec/vvc/dec.c | 5 +
>> 1 file changed, 5 insertions(+)
>>
>> diff --git a/libavcodec/vvc/dec.c b/libavcodec/vvc/dec.c
>> index a4fc40b40a..5249ddf989 100644
>> --- a/libavcodec/vvc/dec.c
>> +++ b/libavcodec/vvc/dec.c
>> @@ -785,6 +785,11 @@ static int decode_nal_unit(VVCContext *s,
>> VVCFrameContext *fc, const H2645NAL *n
>> s->temporal_id = nal->temporal_id;
>> + if (nal->nuh_layer_id > 0) {
>> + avpriv_report_missing_feature(fc->log_ctx, "Multilayer");
>
> A more verbose message would be better.
>
Thanks for your review James.
Would "Quality/spatial/multiview scalability" be better or do you have
some other suggestion? The message is put in a template by
avpriv_report_missing_feature, e.g.
[vvc @ 0x61803c80] Multilayer is not implemented. Update your FFmpeg
version to the newest one from Git. If the problem still occurs, it
means that your file has a feature which has not been implemented.
so the string passed to avpriv_report_missing_feature must be a noun.
--
Frank
___
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/vvc: Skip enhancement layer NAL units
On 4/18/2024 5:19 PM, Frank Plowman wrote:
On 18/04/2024 20:43, James Almer wrote:
On 4/18/2024 3:59 PM, Frank Plowman wrote:
The native VVC decoder does not yet support quality/spatial/multiview
scalability. Bitstreams requiring this feature could cause crashes.
Patch fixes this by skipping NAL units which are not in the base layer,
warning the user while doing so.
Signed-off-by: Frank Plowman
---
libavcodec/vvc/dec.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/libavcodec/vvc/dec.c b/libavcodec/vvc/dec.c
index a4fc40b40a..5249ddf989 100644
--- a/libavcodec/vvc/dec.c
+++ b/libavcodec/vvc/dec.c
@@ -785,6 +785,11 @@ static int decode_nal_unit(VVCContext *s,
VVCFrameContext *fc, const H2645NAL *n
s->temporal_id = nal->temporal_id;
+ if (nal->nuh_layer_id > 0) {
+ avpriv_report_missing_feature(fc->log_ctx, "Multilayer");
A more verbose message would be better.
Thanks for your review James.
Would "Quality/spatial/multiview scalability" be better or do you have
some other suggestion? The message is put in a template by
avpriv_report_missing_feature, e.g.
[vvc @ 0x61803c80] Multilayer is not implemented. Update your FFmpeg
version to the newest one from Git. If the problem still occurs, it
means that your file has a feature which has not been implemented.
so the string passed to avpriv_report_missing_feature must be a noun.
Maybe "Decoding of multilayer bitstreams".
___
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] lavc/vvc: Skip enhancement layer NAL units
The native VVC decoder does not yet support quality/spatial/multiview
scalability. Bitstreams requiring this feature could cause crashes.
Patch fixes this by skipping NAL units which are not in the base layer,
warning the user while doing so.
Signed-off-by: Frank Plowman
---
Changes since v1:
* Change missing feature string from "Multilayer" to "Decoding of
multilayer bitstreams" for clarity.
libavcodec/vvc/dec.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/libavcodec/vvc/dec.c b/libavcodec/vvc/dec.c
index a4fc40b40a..6aeec27eaf 100644
--- a/libavcodec/vvc/dec.c
+++ b/libavcodec/vvc/dec.c
@@ -785,6 +785,12 @@ static int decode_nal_unit(VVCContext *s, VVCFrameContext
*fc, const H2645NAL *n
s->temporal_id = nal->temporal_id;
+if (nal->nuh_layer_id > 0) {
+avpriv_report_missing_feature(fc->log_ctx,
+"Decoding of multilayer bitstreams");
+return AVERROR_PATCHWELCOME;
+}
+
switch (unit->type) {
case VVC_VPS_NUT:
case VVC_SPS_NUT:
--
2.44.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] lavc/vvc: Skip enhancement layer NAL units
On 18/04/2024 21:23, James Almer wrote:
> On 4/18/2024 5:19 PM, Frank Plowman wrote:
>> On 18/04/2024 20:43, James Almer wrote:
>>> On 4/18/2024 3:59 PM, Frank Plowman wrote:
The native VVC decoder does not yet support quality/spatial/multiview
scalability. Bitstreams requiring this feature could cause crashes.
Patch fixes this by skipping NAL units which are not in the base layer,
warning the user while doing so.
Signed-off-by: Frank Plowman
---
libavcodec/vvc/dec.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/libavcodec/vvc/dec.c b/libavcodec/vvc/dec.c
index a4fc40b40a..5249ddf989 100644
--- a/libavcodec/vvc/dec.c
+++ b/libavcodec/vvc/dec.c
@@ -785,6 +785,11 @@ static int decode_nal_unit(VVCContext *s,
VVCFrameContext *fc, const H2645NAL *n
s->temporal_id = nal->temporal_id;
+ if (nal->nuh_layer_id > 0) {
+ avpriv_report_missing_feature(fc->log_ctx, "Multilayer");
>>>
>>> A more verbose message would be better.
>>>
>>
>> Thanks for your review James.
>>
>> Would "Quality/spatial/multiview scalability" be better or do you have
>> some other suggestion? The message is put in a template by
>> avpriv_report_missing_feature, e.g.
>>
>> [vvc @ 0x61803c80] Multilayer is not implemented. Update your FFmpeg
>> version to the newest one from Git. If the problem still occurs, it
>> means that your file has a feature which has not been implemented.
>>
>> so the string passed to avpriv_report_missing_feature must be a noun.
>
> Maybe "Decoding of multilayer bitstreams".
Agreed, that's a bit clearer. v2 sent.
Thanks,
--
Frank
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH v2] lavc/vvc: Skip enhancement layer NAL units
On 4/18/2024 5:26 PM, Frank Plowman wrote:
The native VVC decoder does not yet support quality/spatial/multiview
scalability. Bitstreams requiring this feature could cause crashes.
Patch fixes this by skipping NAL units which are not in the base layer,
warning the user while doing so.
Signed-off-by: Frank Plowman
---
Changes since v1:
* Change missing feature string from "Multilayer" to "Decoding of
multilayer bitstreams" for clarity.
libavcodec/vvc/dec.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/libavcodec/vvc/dec.c b/libavcodec/vvc/dec.c
index a4fc40b40a..6aeec27eaf 100644
--- a/libavcodec/vvc/dec.c
+++ b/libavcodec/vvc/dec.c
@@ -785,6 +785,12 @@ static int decode_nal_unit(VVCContext *s, VVCFrameContext
*fc, const H2645NAL *n
s->temporal_id = nal->temporal_id;
+if (nal->nuh_layer_id > 0) {
+avpriv_report_missing_feature(fc->log_ctx,
+"Decoding of multilayer bitstreams");
+return AVERROR_PATCHWELCOME;
+}
+
switch (unit->type) {
case VVC_VPS_NUT:
case VVC_SPS_NUT:
Applied, thanks.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH v2 01/27] avcodec/threadprogress: Add new API for frame-threaded progress
Andreas Rheinhardt:
> The API is similar to the ThreadFrame API, with the exception
> that it no longer has an included AVFrame and that it has its
> own mutexes and condition variables which makes it more independent
> of pthread_frame.c. One can wait on anything via a ThreadProgress.
> One just has to ensure that the lifetime of the object containing
> the ThreadProgress is long enough. This will typically be solved
> by putting a ThreadProgress in a refcounted structure that is
> shared between threads.
>
> Signed-off-by: Andreas Rheinhardt
> ---
> Now including its own mutex and condition variable. Hopefully
> no system has constraints on the number of mutexes and condition
> variables it supports.
>
> libavcodec/threadprogress.c | 73 +
> libavcodec/threadprogress.h | 91 +
> 2 files changed, 164 insertions(+)
> create mode 100644 libavcodec/threadprogress.c
> create mode 100644 libavcodec/threadprogress.h
>
> diff --git a/libavcodec/threadprogress.c b/libavcodec/threadprogress.c
> new file mode 100644
> index 00..dd2a4d2336
> --- /dev/null
> +++ b/libavcodec/threadprogress.c
> @@ -0,0 +1,73 @@
> +/*
> + * Copyright (c) 2022 Andreas Rheinhardt
> + *
> + * This file is part of FFmpeg.
> + *
> + * FFmpeg is free software; you can redistribute it and/or
> + * modify it under the terms of the GNU Lesser General Public
> + * License as published by the Free Software Foundation; either
> + * version 2.1 of the License, or (at your option) any later version.
> + *
> + * FFmpeg is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
> + * Lesser General Public License for more details.
> + *
> + * You should have received a copy of the GNU Lesser General Public
> + * License along with FFmpeg; if not, write to the Free Software
> + * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301
> USA
> + */
> +
> +#include
> +#include
> +
> +#include "pthread_internal.h"
> +#include "threadprogress.h"
> +#include "libavutil/attributes.h"
> +
> +DEFINE_OFFSET_ARRAY(ThreadProgress, thread_progress, init,
> +(offsetof(ThreadProgress, progress_mutex)),
> +(offsetof(ThreadProgress, progress_cond)));
> +
> +av_cold int ff_thread_progress_init(ThreadProgress *pro, int init_mode)
> +{
> +atomic_init(&pro->progress, init_mode ? -1 : INT_MAX);
> +if (!init_mode) {
> +pro->init = 0;
> +return 0;
> +}
> +return ff_pthread_init(pro, thread_progress_offsets);
> +}
> +
> +av_cold void ff_thread_progress_destroy(ThreadProgress *pro)
> +{
> +ff_pthread_free(pro, thread_progress_offsets);
> +}
> +
> +void ff_thread_progress_report(ThreadProgress *pro, int n)
> +{
> +if (atomic_load_explicit(&pro->progress, memory_order_relaxed) >= n)
> +return;
> +
> +atomic_store_explicit(&pro->progress, n, memory_order_release);
> +
> +pthread_mutex_lock(&pro->progress_mutex);
> +pthread_cond_broadcast(&pro->progress_cond);
> +pthread_mutex_unlock(&pro->progress_mutex);
> +}
> +
> +void ff_thread_progress_await(const ThreadProgress *pro_c, int n)
> +{
> +/* Casting const away here is safe, because we only read from progress
> + * and will leave pro_c in the same state upon leaving the function
> + * as it had at the beginning. */
> +ThreadProgress *pro = (ThreadProgress*)pro_c;
> +
> +if (atomic_load_explicit(&pro->progress, memory_order_acquire) >= n)
> +return;
> +
> +pthread_mutex_lock(&pro->progress_mutex);
> +while (atomic_load_explicit(&pro->progress, memory_order_relaxed) < n)
> +pthread_cond_wait(&pro->progress_cond, &pro->progress_mutex);
> +pthread_mutex_unlock(&pro->progress_mutex);
> +}
> diff --git a/libavcodec/threadprogress.h b/libavcodec/threadprogress.h
> new file mode 100644
> index 00..786802cbf1
> --- /dev/null
> +++ b/libavcodec/threadprogress.h
> @@ -0,0 +1,91 @@
> +/*
> + * Copyright (c) 2022 Andreas Rheinhardt
> + *
> + * 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
> + */
> +
> +#ifndef AVCODEC_
Re: [FFmpeg-devel] [RFC] 5 year plan & Inovation
On Thu, Apr 18, 2024 at 04:02:07PM +0200, Niklas Haas wrote: > On Wed, 17 Apr 2024 15:58:32 +0200 Michael Niedermayer > wrote: > > Hi all > > > > The pace of inovation in FFmpeg has been slowing down. > > Most work is concentarted nowadays on code refactoring, and adding > > support for new codecs and formats. > > > > Should we > > * make a list of longer term goals > > * vote on them > > * and then together work towards implementing them > > ? > > > > (The idea here is to increase the success of larger efforts > > than adding codecs and refactoring code) > > It would then also not be possible for individuals to object > > to a previously agreed goal. > > And it would add ideas for which we can try to get funding/grants for > > > > (larger scale changes need consensus first that we as a whole want > > them before we would be able to ask for funding/grants for them) > > > > Some ideas and why they would help FFmpeg: > > > > * Switch to a plugin architecture > > (Increase the number of developers willing to contribute and reduce > > friction as the team and community grows) > > This would almost surely hurt productivity i dont agree, ill elaborae below > as it will require exposing, > versioning, documenting and maintaining a vast number of internal APIs yes to some extend that is needed. It can be more or less depending on how things are implemented > which we are currently at the liberty of modifying freely. we are modifying these APIs for decades. That modification of APIs their documentation and all code using them costs time. More so we have issues with patch-management. And i claim this is not the mailing list but a lack of time and in some cases a lack of interrest in many areas. A plugin system moves this patch-management to people who actually care, that is the authors of the codecs and (de)muxers. Our productivity as is, is not good, many patches are ignored. The people caring about these patches are their Authors and yet they are powerless as they must sometimes wait many months for reviews Besides that, developers are leaving for various reasons and they are forced to setup full forks not being able to maintain their code in any other way. IMO A plugin system would improve productivity as everyone could work on their own terms. No week or month long delays and weekly pinging patches No risk about patches being rejected or ignored No need to read every other discussion on the ML. One can just simply work on their own plugin looking just at the API documentation ... > > > * ffchat > > (expand into realtime chat / zoom) this would > > bring in more users and developers, and we basically have almost > > all parts for it already but some people where against it > > This seems like a user application on top of FFmpeg, not something that > should be part of FFmpeg core. Can you explain what modifications in > FFmpeg would be necessary for something like this? ffmpeg, ffplay, ffprobe are also user applications. > > > * client side / in browser support > > (expand towards webapps, webpages using ffmpeg client side in the > > browser) > > bring in more users and developers, and it will be costly for us > > if we let others take this area as its important and significant > > I don't understand this point - don't all major browsers already vendor > FFmpeg for decoding? FFmpeg does more than decoding. > > > * AI / neural network filters and codecs > > The future seems to be AI based. Future Filters and Codecs will use > > neural networks. FFmpeg can be at the forefront, developing these > > We already have TensorFlow support, no? (vf_sr etc.) What more is > needed? more of that AND more convenience lets pick a comparission to run fate you write "make fate" if you want to do it with the samples its make fate-rsync ; make fate if you want to use vf_sr, its reading the docs, looking at some scripts reading their docs and i presume selecting a training set ? creating a model ? how many people do that ? thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB I have often repented speaking, but never of holding my tongue. -- Xenocrates 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] [RFC] 5 year plan & Inovation
On 18 Apr 2024, at 22:15, Michael Niedermayer wrote: > On Thu, Apr 18, 2024 at 10:19:50AM +0200, Stefano Sabatini wrote: >> On date Wednesday 2024-04-17 19:21:39 -0700, Aidan wrote: >>> The best option is to figure stuff out. >> [...] >>> I use FFmpeg to download HLS streams from the internet or convert files >>> like probably most people do. FFmpeg is the ultimate way of doing this >>> because there is no better option. >>> >>> But there are issues: >> [...] >> >>> I submitted a patch for a TTML decoder because I thought it would be great. >>> It was completely ignored. >> >> Please ping the patch or send a new one. >> >>> If my patch was seriously bad, then fine. But seriously *no one cared*. >> >> I think contribution management is a serious issue here. >> >> What happens when you send a patch is that if you're lucky someone >> will be interested and put some effort to review and eventually get it >> pushed, which depending on several factors might require several >> interactions. >> >> Sometimes contributors are side-tracked or frustrated and the review >> process is interrupted. Sometimes the reviewer won't reply, and the >> review also might be stuck (in this case you might want to ping the >> patch). >> >> Sometimes there is no qualified or interested developer around, or >> maybe those ones are busy with other things (and it's easy to miss >> a patch, especially if you don't check emails since a few days and you >> got hundreds of backlog emails). >> >> In general, this is done on a best effort basis (read as: most >> developers are volunteers and they might have job/families/stuff to >> tend to), there is no guarantee that a patch might be reviewed in a >> timely fashion. >> >> This is not a problem specific with FFmpeg, but in general with most >> FLOSS projects. >> >> Probably we should find ways to fund such activites, so that a >> developer can spend more time on reviewing work, but this comes with >> other risks/issues (since managing money is also complex of potential >> tensions in a mostly volunteering-based project). >> >> It's also very difficult to track the sent patches, and that's why >> having a Pull-Request process a-la github has been proposed several >> times; we cannot switch to github for several reasons (licensing and >> affilitation issues with platform owner) and handling your own gitlab >> is costly and we lack volunteers at the moment. >> >> We are using patchwork to mitigate the tracking issue: >> https://patchwork.ffmpeg.org/project/ffmpeg/list/ >> >> but that's not really providing an effective workflow. >> >> Personally I find the status tracking confusing, e.g.: >> https://patchwork.ffmpeg.org/project/ffmpeg/list/?series=&submitter=&state=&q=TTML&archive=both&delegate= >> >> I cannot easily figure out what was integrated and what not. > > Would it help if i add a "patch" type to trac.ffmpeg.org ? > > If patches are missed on patchwork or its confusing, then > patch authors could open such a ticket type=patch that points to the > patchwork patch > > as tickets have all the metadata from keywords over priority to component > and do also allow voting. It may help keeping track of patches and also > allow the community to express their preferance with voting. Just stating the obvious here but GitLab/Gitea/Forgejo or similar would solve this without needing absolutely weird workarounds like this… > > thx > > [...] > -- > Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB > > When the tyrant has disposed of foreign enemies by conquest or treaty, and > there is nothing more to fear from them, then he is always stirring up > some war or other, in order that the people may require a leader. -- Plato > ___ > 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] avcodec/pthread_frame: Fix leak of coded side data
Happens in the mov-elst-ends-betn-b-and-i FATE test with frame-threading. Signed-off-by: Andreas Rheinhardt --- libavcodec/pthread_frame.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/libavcodec/pthread_frame.c b/libavcodec/pthread_frame.c index f19571f6f8..a984ff94d5 100644 --- a/libavcodec/pthread_frame.c +++ b/libavcodec/pthread_frame.c @@ -731,6 +731,8 @@ void ff_frame_thread_free(AVCodecContext *avctx, int thread_count) av_packet_free(&ctx->internal->last_pkt_props); av_freep(&ctx->internal); av_buffer_unref(&ctx->hw_frames_ctx); +av_frame_side_data_free(&ctx->decoded_side_data, +&ctx->nb_decoded_side_data); } av_frame_free(&p->frame); -- 2.40.1 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH v2 01/27] avcodec/threadprogress: Add new API for frame-threaded progress
On 18 Apr 2024, at 22:40, Andreas Rheinhardt wrote:
> Andreas Rheinhardt:
>> The API is similar to the ThreadFrame API, with the exception
>> that it no longer has an included AVFrame and that it has its
>> own mutexes and condition variables which makes it more independent
>> of pthread_frame.c. One can wait on anything via a ThreadProgress.
>> One just has to ensure that the lifetime of the object containing
>> the ThreadProgress is long enough. This will typically be solved
>> by putting a ThreadProgress in a refcounted structure that is
>> shared between threads.
>>
>> Signed-off-by: Andreas Rheinhardt
>> ---
>> Now including its own mutex and condition variable. Hopefully
>> no system has constraints on the number of mutexes and condition
>> variables it supports.
>>
>> libavcodec/threadprogress.c | 73 +
>> libavcodec/threadprogress.h | 91 +
>> 2 files changed, 164 insertions(+)
>> create mode 100644 libavcodec/threadprogress.c
>> create mode 100644 libavcodec/threadprogress.h
>>
>> diff --git a/libavcodec/threadprogress.c b/libavcodec/threadprogress.c
>> new file mode 100644
>> index 00..dd2a4d2336
>> --- /dev/null
>> +++ b/libavcodec/threadprogress.c
>> @@ -0,0 +1,73 @@
>> +/*
>> + * Copyright (c) 2022 Andreas Rheinhardt
>> + *
>> + * This file is part of FFmpeg.
>> + *
>> + * FFmpeg is free software; you can redistribute it and/or
>> + * modify it under the terms of the GNU Lesser General Public
>> + * License as published by the Free Software Foundation; either
>> + * version 2.1 of the License, or (at your option) any later version.
>> + *
>> + * FFmpeg is distributed in the hope that it will be useful,
>> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
>> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
>> + * Lesser General Public License for more details.
>> + *
>> + * You should have received a copy of the GNU Lesser General Public
>> + * License along with FFmpeg; if not, write to the Free Software
>> + * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301
>> USA
>> + */
>> +
>> +#include
>> +#include
>> +
>> +#include "pthread_internal.h"
>> +#include "threadprogress.h"
>> +#include "libavutil/attributes.h"
>> +
>> +DEFINE_OFFSET_ARRAY(ThreadProgress, thread_progress, init,
>> +(offsetof(ThreadProgress, progress_mutex)),
>> +(offsetof(ThreadProgress, progress_cond)));
>> +
>> +av_cold int ff_thread_progress_init(ThreadProgress *pro, int init_mode)
>> +{
>> +atomic_init(&pro->progress, init_mode ? -1 : INT_MAX);
>> +if (!init_mode) {
>> +pro->init = 0;
>> +return 0;
>> +}
>> +return ff_pthread_init(pro, thread_progress_offsets);
>> +}
>> +
>> +av_cold void ff_thread_progress_destroy(ThreadProgress *pro)
>> +{
>> +ff_pthread_free(pro, thread_progress_offsets);
>> +}
>> +
>> +void ff_thread_progress_report(ThreadProgress *pro, int n)
>> +{
>> +if (atomic_load_explicit(&pro->progress, memory_order_relaxed) >= n)
>> +return;
>> +
>> +atomic_store_explicit(&pro->progress, n, memory_order_release);
>> +
>> +pthread_mutex_lock(&pro->progress_mutex);
>> +pthread_cond_broadcast(&pro->progress_cond);
>> +pthread_mutex_unlock(&pro->progress_mutex);
>> +}
>> +
>> +void ff_thread_progress_await(const ThreadProgress *pro_c, int n)
>> +{
>> +/* Casting const away here is safe, because we only read from progress
>> + * and will leave pro_c in the same state upon leaving the function
>> + * as it had at the beginning. */
>> +ThreadProgress *pro = (ThreadProgress*)pro_c;
>> +
>> +if (atomic_load_explicit(&pro->progress, memory_order_acquire) >= n)
>> +return;
>> +
>> +pthread_mutex_lock(&pro->progress_mutex);
>> +while (atomic_load_explicit(&pro->progress, memory_order_relaxed) < n)
>> +pthread_cond_wait(&pro->progress_cond, &pro->progress_mutex);
>> +pthread_mutex_unlock(&pro->progress_mutex);
>> +}
>> diff --git a/libavcodec/threadprogress.h b/libavcodec/threadprogress.h
>> new file mode 100644
>> index 00..786802cbf1
>> --- /dev/null
>> +++ b/libavcodec/threadprogress.h
>> @@ -0,0 +1,91 @@
>> +/*
>> + * Copyright (c) 2022 Andreas Rheinhardt
>> + *
>> + * 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
>> + *
Re: [FFmpeg-devel] resignation from CC
On Sat, Apr 13, 2024 at 12:29 PM Steven Liu wrote: > Anton Khirnov 于2024年4月13日周六 17:58写道： > > > > Hi all, > > I am hereby resigning from my position as a CC member, since I do not > > want to be associated with the CC's utter lack of initiative and > > meaningful action. > What's happened? Perhaps have some misunderstand with some body or some > things? > > Also some more prominent figures just left ffmpeg-devel IRC channel. Some very serious internal fights, nothing like external-public troll-fest. > > Thanks > Steven > ___ > 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] [RFC] 5 year plan & Inovation
On 18/04/2024 20:50, Michael Niedermayer wrote: [...] Without getting too far off-topic, I would also be interested in knowing how docs are actually generated in practice. I've tried generating documentation its just running doxygen with a Doxyfile the Doxyfile is not doc/Doxyfile from git because that could be a security issue. But its a very similar file thx Aha! But it's running doxygen i386, right? I've been building the docs with an x86_64 machine, and the links to most functions are different. Installing doxygen:i386 seems to fix it. Assuming the security issue is just that people could inject arbitrary code into the Doxyfile, is it possible to upload that file somewhere, then link to it (and mention the architecture thing) from e.g. the README? To be clear - it's definitely the right move to run a version of doxygen that generates links that are compatible with older releases, but it would have saved me some time if that was written somewhere :) - Andrew Sayers ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [RFC] 5 year plan & Inovation
On Thu, Apr 18, 2024 at 11:15:48PM +0200, epira...@gmail.com wrote: > > > On 18 Apr 2024, at 22:15, Michael Niedermayer wrote: > > > On Thu, Apr 18, 2024 at 10:19:50AM +0200, Stefano Sabatini wrote: > >> On date Wednesday 2024-04-17 19:21:39 -0700, Aidan wrote: > >>> The best option is to figure stuff out. > >> [...] > >>> I use FFmpeg to download HLS streams from the internet or convert files > >>> like probably most people do. FFmpeg is the ultimate way of doing this > >>> because there is no better option. > >>> > >>> But there are issues: > >> [...] > >> > >>> I submitted a patch for a TTML decoder because I thought it would be > >>> great. > >>> It was completely ignored. > >> > >> Please ping the patch or send a new one. > >> > >>> If my patch was seriously bad, then fine. But seriously *no one cared*. > >> > >> I think contribution management is a serious issue here. > >> > >> What happens when you send a patch is that if you're lucky someone > >> will be interested and put some effort to review and eventually get it > >> pushed, which depending on several factors might require several > >> interactions. > >> > >> Sometimes contributors are side-tracked or frustrated and the review > >> process is interrupted. Sometimes the reviewer won't reply, and the > >> review also might be stuck (in this case you might want to ping the > >> patch). > >> > >> Sometimes there is no qualified or interested developer around, or > >> maybe those ones are busy with other things (and it's easy to miss > >> a patch, especially if you don't check emails since a few days and you > >> got hundreds of backlog emails). > >> > >> In general, this is done on a best effort basis (read as: most > >> developers are volunteers and they might have job/families/stuff to > >> tend to), there is no guarantee that a patch might be reviewed in a > >> timely fashion. > >> > >> This is not a problem specific with FFmpeg, but in general with most > >> FLOSS projects. > >> > >> Probably we should find ways to fund such activites, so that a > >> developer can spend more time on reviewing work, but this comes with > >> other risks/issues (since managing money is also complex of potential > >> tensions in a mostly volunteering-based project). > >> > >> It's also very difficult to track the sent patches, and that's why > >> having a Pull-Request process a-la github has been proposed several > >> times; we cannot switch to github for several reasons (licensing and > >> affilitation issues with platform owner) and handling your own gitlab > >> is costly and we lack volunteers at the moment. > >> > >> We are using patchwork to mitigate the tracking issue: > >> https://patchwork.ffmpeg.org/project/ffmpeg/list/ > >> > >> but that's not really providing an effective workflow. > >> > >> Personally I find the status tracking confusing, e.g.: > >> https://patchwork.ffmpeg.org/project/ffmpeg/list/?series=&submitter=&state=&q=TTML&archive=both&delegate= > >> > >> I cannot easily figure out what was integrated and what not. > > > > Would it help if i add a "patch" type to trac.ffmpeg.org ? > > > > If patches are missed on patchwork or its confusing, then > > patch authors could open such a ticket type=patch that points to the > > patchwork patch > > > > as tickets have all the metadata from keywords over priority to component > > and do also allow voting. It may help keeping track of patches and also > > allow the community to express their preferance with voting. > > Just stating the obvious here but GitLab/Gitea/Forgejo or similar > would solve this without needing absolutely weird workarounds > like this… a small change to trac is easy to do and easy to undo, if it helps, iam not sure a switch to GitLab/Gitea/Forgejo will happen, or even if it is a good idea. we lack people with time and interrest to review and apply patches switching the tools will cost more time, and working with these tools would also add burden (at least to me) other projects also seem not to have switched if i look at LKML for example IMO, if we can keep the mailing list workflow and at the same time provide people who prefer it a "in browser" way to interact with patches, submit, approve and so on. That would be best. It seems patchwork does not fully fill this role. Can something be done to improve patchwork so it works better maybe ? thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Dictatorship: All citizens are under surveillance, all their steps and actions recorded, for the politicians to enforce control. Democracy: All politicians are under surveillance, all their steps and actions recorded, for the citizens to enforce control. 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] [RFC] 5 year plan & Inovation
On Thu, Apr 18, 2024 at 06:13:40PM -0300, James Almer wrote: > On 4/18/2024 5:53 PM, Michael Niedermayer wrote: > > On Thu, Apr 18, 2024 at 04:02:07PM +0200, Niklas Haas wrote: > > > On Wed, 17 Apr 2024 15:58:32 +0200 Michael Niedermayer > > > wrote: > > > > Hi all > > > > > > > > The pace of inovation in FFmpeg has been slowing down. > > > > Most work is concentarted nowadays on code refactoring, and adding > > > > support for new codecs and formats. > > > > > > > > Should we > > > > * make a list of longer term goals > > > > * vote on them > > > > * and then together work towards implementing them > > > > ? > > > > > > > > (The idea here is to increase the success of larger efforts > > > > than adding codecs and refactoring code) > > > > It would then also not be possible for individuals to object > > > > to a previously agreed goal. > > > > And it would add ideas for which we can try to get funding/grants for > > > > > > > > (larger scale changes need consensus first that we as a whole want > > > > them before we would be able to ask for funding/grants for them) > > > > > > > > Some ideas and why they would help FFmpeg: > > > > > > > > * Switch to a plugin architecture > > > > (Increase the number of developers willing to contribute and reduce > > > > friction as the team and community grows) > > > > > > This would almost surely hurt productivity > > > > i dont agree, ill elaborae below > > > > > > > as it will require exposing, > > > versioning, documenting and maintaining a vast number of internal APIs > > > > yes to some extend that is needed. It can be more or less depending > > on how things are implemented > > > > > > > which we are currently at the liberty of modifying freely. > > > > we are modifying these APIs for decades. That modification of APIs > > their documentation and all code using them costs time. > > The AVCodec hooks being internal allowed us to add autoinserted bsfs and to > painlessly rewrite the decouple I/O callbacks to work as a pure pull based > interface. Were said internals public, that wouldn't have been possible. A decoder API needs packet in, frame out. AVPacket and AVFrame are public. (and a bunch of key-value data like width / height / timebase / pixelformat / aspect / ... teh struct for that is also public since a long time) I dont see the problem. you have the decoder API facing the user, that causes no problems, i dont agree that having a decoder API (or encoder, muxer, demuxer, ...) facing a plugin would be a bigger problem than the APIs we already have public sure there are details, sure there are things that need one to think about and sleep over and all that but these are from a high level point of view simple and also the same interfaces to what we already have public > > > > > More so we have issues with patch-management. And i claim this is > > not the mailing list but a lack of time and in some cases a lack of > > interrest in many areas. > > > > A plugin system moves this patch-management to people who actually > > care, that is the authors of the codecs and (de)muxers. > > > > Our productivity as is, is not good, many patches are ignored. > > A lot of patches fall through the cracks rather than being ignored. > There are people that send patchsets unthreaded (Because of misconfigured > git send-email i suppose), and it makes browsing your mailbox hard. well i can say that i dont review many patches anymore because i just dont have the time, its not that i cant keep track of what i wanted to review. either i make a note in a TODO list or i keep the patch marked as NEW in my mail user agent. trac in some sense or patchwork are just more public TODO lists that can be shared between people so if one doesnt do it another developer sees it and can do it. > > > The people caring about these patches are their Authors and yet they > > are powerless as they must sometimes wait many months for reviews > > Besides that, developers are leaving for various reasons and they > > are forced to setup full forks not being able to maintain their > > code in any other way. > > IMO A plugin system would improve productivity as everyone could work > > on their own terms. > > You say the ML is not the problem, but it sort of is. An MR based > development would greatly improve this problem. People historically where very opposed to merge requests But, having a public git repo (that people already have) asking for it to be merged. You get a merge commit and someone will probably feel offended by that. (thats not what you meant i guess) but i would 100% support doing git merge requests. (there are good arguments from people much smarter than me why merging is better than rebasing) > > > No week or month long delays and weekly pinging patches > > No risk about patches being rejected or ignored > > No need to read every other discussion on the ML. One can just > > simply work on their own plugin looking just at the API documentatio
Re: [FFmpeg-devel] [RFC] 5 year plan & Inovation
On Fri, Apr 19, 2024 at 1:19 AM Michael Niedermayer wrote: > On Thu, Apr 18, 2024 at 06:13:40PM -0300, James Almer wrote: > > On 4/18/2024 5:53 PM, Michael Niedermayer wrote: > > > On Thu, Apr 18, 2024 at 04:02:07PM +0200, Niklas Haas wrote: > > > > On Wed, 17 Apr 2024 15:58:32 +0200 Michael Niedermayer < > mich...@niedermayer.cc> wrote: > > > > > Hi all > > > > > > > > > > The pace of inovation in FFmpeg has been slowing down. > > > > > Most work is concentarted nowadays on code refactoring, and adding > > > > > support for new codecs and formats. > > > > > > > > > > Should we > > > > > * make a list of longer term goals > > > > > * vote on them > > > > > * and then together work towards implementing them > > > > > ? > > > > > > > > > > (The idea here is to increase the success of larger efforts > > > > > than adding codecs and refactoring code) > > > > > It would then also not be possible for individuals to object > > > > > to a previously agreed goal. > > > > > And it would add ideas for which we can try to get funding/grants > for > > > > > > > > > > (larger scale changes need consensus first that we as a whole want > > > > > them before we would be able to ask for funding/grants for them) > > > > > > > > > > Some ideas and why they would help FFmpeg: > > > > > > > > > > * Switch to a plugin architecture > > > > > (Increase the number of developers willing to contribute and > reduce > > > > > friction as the team and community grows) > > > > > > > > This would almost surely hurt productivity > > > > > > i dont agree, ill elaborae below > > > > > > > > > > as it will require exposing, > > > > versioning, documenting and maintaining a vast number of internal > APIs > > > > > > yes to some extend that is needed. It can be more or less depending > > > on how things are implemented > > > > > > > > > > which we are currently at the liberty of modifying freely. > > > > > > we are modifying these APIs for decades. That modification of APIs > > > their documentation and all code using them costs time. > > > > The AVCodec hooks being internal allowed us to add autoinserted bsfs and > to > > painlessly rewrite the decouple I/O callbacks to work as a pure pull > based > > interface. Were said internals public, that wouldn't have been possible. > > A decoder API needs packet in, frame out. > AVPacket and AVFrame are public. > (and a bunch of key-value data like width / height / timebase / > pixelformat / aspect / ... > teh struct for that is also public since a long time) > I dont see the problem. > > you have the decoder API facing the user, that causes no problems, > i dont agree that having a decoder API (or encoder, muxer, demuxer, ...) > facing a plugin would be a bigger problem than the APIs we already have > public > sure there are details, sure there are things that need one to think about > and sleep over and all that but these are from a high level point of > view simple and also the same interfaces to what we already have public > > > > > > > > > > More so we have issues with patch-management. And i claim this is > > > not the mailing list but a lack of time and in some cases a lack of > > > interrest in many areas. > > > > > > A plugin system moves this patch-management to people who actually > > > care, that is the authors of the codecs and (de)muxers. > > > > > > Our productivity as is, is not good, many patches are ignored. > > > > A lot of patches fall through the cracks rather than being ignored. > > There are people that send patchsets unthreaded (Because of misconfigured > > git send-email i suppose), and it makes browsing your mailbox hard. > > well i can say that i dont review many patches anymore because i just dont > have > the time, its not that i cant keep track of what i wanted to review. > > either i make a note in a TODO list or i keep the patch marked as NEW > in my mail user agent. > > trac in some sense or patchwork are just more public TODO lists > that can be shared between people so if one doesnt do it another > developer sees it and can do it. > > > > > > > The people caring about these patches are their Authors and yet they > > > are powerless as they must sometimes wait many months for reviews > > > Besides that, developers are leaving for various reasons and they > > > are forced to setup full forks not being able to maintain their > > > code in any other way. > > > IMO A plugin system would improve productivity as everyone could work > > > on their own terms. > > > > You say the ML is not the problem, but it sort of is. An MR based > > development would greatly improve this problem. > > People historically where very opposed to merge requests > > But, having a public git repo (that people already have) > asking for it to be merged. You get a merge commit and someone will > probably > feel offended by that. (thats not what you meant i guess) > but i would 100% support doing git merge requests. > (there are good arguments from people much smarter than me why >
