Re: [FFmpeg-devel] [PATCH, v2] lavc/vaapi_encode: grow packet if vaMapBuffer returns multiple buffers
On Sun, Sep 29, 2019 at 3:19 AM Fu, Linjie wrote:
> > -Original Message-
> > From: Li, Zhong
> > Sent: Friday, September 13, 2019 00:05
> > To: FFmpeg development discussions and patches > de...@ffmpeg.org>
> > Cc: Fu, Linjie
> > Subject: RE: [FFmpeg-devel] [PATCH, v2] lavc/vaapi_encode: grow packet if
> > vaMapBuffer returns multiple buffers
> >
> > > From: ffmpeg-devel On Behalf Of
> > Linjie Fu
> > > Sent: Friday, May 31, 2019 8:35 AM
> > > To: ffmpeg-devel@ffmpeg.org
> > > Cc: Fu, Linjie
> > > Subject: [FFmpeg-devel] [PATCH, v2] lavc/vaapi_encode: grow packet if
> > > vaMapBuffer returns multiple buffers
> > >
> > > It seems that VA_CODED_BUF_STATUS_SINGLE_NALU allows driver to
> > map
> > > buffer for each slice.
> > >
> > > Currently, assigning new buffer for pkt when multiple buffer returns
> from
> > > vaMapBuffer will cover the previous encoded pkt data and lead to encode
> > issues.
> > >
> > > Iterate through the buf_list first to find out the total buffer size
> needed for
> > the
> > > pkt, allocate the whole pkt to avoid repeated reallocation and memcpy,
> > then copy
> > > data from each buf to pkt.
> > >
> > > Signed-off-by: Linjie Fu
> > > ---
> > > [v2]: allocate the whole pkt to avoid repeated reallocation and memcpy
> > >
> > > libavcodec/vaapi_encode.c | 18 +-
> > > 1 file changed, 13 insertions(+), 5 deletions(-)
> > >
> > > diff --git a/libavcodec/vaapi_encode.c b/libavcodec/vaapi_encode.c
> index
> > > 2dda451..9c9e5dd 100644
> > > --- a/libavcodec/vaapi_encode.c
> > > +++ b/libavcodec/vaapi_encode.c
> > > @@ -489,6 +489,8 @@ static int vaapi_encode_output(AVCodecContext
> > *avctx,
> > > VAAPIEncodeContext *ctx = avctx->priv_data;
> > > VACodedBufferSegment *buf_list, *buf;
> > > VAStatus vas;
> > > +int total_size = 0;
> > > +uint8_t *ptr;
> > > int err;
> > >
> > > err = vaapi_encode_wait(avctx, pic); @@ -505,15 +507,21 @@ static
> int
> > > vaapi_encode_output(AVCodecContext *avctx,
> > > goto fail;
> > > }
> > >
> > > +for (buf = buf_list; buf; buf = buf->next)
> > > +total_size += buf->size;
> > > +
> > > +err = av_new_packet(pkt, total_size);
> > > +ptr = pkt->data;
> > > +
> > > +if (err < 0)
> > > +goto fail_mapped;
> > > +
> > > for (buf = buf_list; buf; buf = buf->next) {
> > > av_log(avctx, AV_LOG_DEBUG, "Output buffer: %u bytes "
> > > "(status %08x).\n", buf->size, buf->status);
> > >
> > > -err = av_new_packet(pkt, buf->size);
> > > -if (err < 0)
> > > -goto fail_mapped;
> > > -
> > > -memcpy(pkt->data, buf->buf, buf->size);
> > > +memcpy(ptr, buf->buf, buf->size);
> > > +ptr += buf->size;
> > > }
> > >
> > > if (pic->type == PICTURE_TYPE_IDR)
> > > --
> > > 2.7.4
> >
> > LGTM
>
> Thanks for review.
> A kindly ping.
>
> - linjie
>
LGTM
regards
Max
___
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 2/2] lavc/vaapi_decode: recreate hw_frames_ctx for vp9 without destroy va_context
On Fri, Sep 20, 2019 at 5:12 AM Fu, Linjie wrote:
> > -Original Message-
> > From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf
> > Of Fu, Linjie
> > Sent: Wednesday, September 11, 2019 00:02
> > To: ffmpeg-devel@ffmpeg.org
> > Subject: Re: [FFmpeg-devel] [PATCH, v2 2/2] lavc/vaapi_decode: recreate
> > hw_frames_ctx for vp9 without destroy va_context
> >
> > > -Original Message-
> > > From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On
> > Behalf
> > > Of Mark Thompson
> > > Sent: Tuesday, September 10, 2019 08:02
> > > To: ffmpeg-devel@ffmpeg.org
> > > Subject: Re: [FFmpeg-devel] [PATCH, v2 2/2] lavc/vaapi_decode: recreate
> > > hw_frames_ctx for vp9 without destroy va_context
> > >
> > > On 09/09/2019 16:40, Fu, Linjie wrote:
> > > >> -Original Message-
> > > >> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On
> > > Behalf
> > > >> Of Fu, Linjie
> > > >> Sent: Friday, August 30, 2019 16:05
> > > >> To: FFmpeg development discussions and patches > > >> de...@ffmpeg.org>
> > > >> Subject: Re: [FFmpeg-devel] [PATCH, v2 2/2] lavc/vaapi_decode:
> > recreate
> > > >> hw_frames_ctx for vp9 without destroy va_context
> > > >>
> > > >>> -Original Message-
> > > >>> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On
> > > >> Behalf
> > > >>> Of Fu, Linjie
> > > >>> Sent: Friday, August 9, 2019 19:47
> > > >>> To: FFmpeg development discussions and patches > > >>> de...@ffmpeg.org>
> > > >>> Subject: Re: [FFmpeg-devel] [PATCH, v2 2/2] lavc/vaapi_decode:
> > > recreate
> > > >>> hw_frames_ctx for vp9 without destroy va_context
> > > >>>
> > > -Original Message-
> > > From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On
> > > >>> Behalf
> > > Of Hendrik Leppkes
> > > Sent: Friday, August 9, 2019 17:40
> > > To: FFmpeg development discussions and patches > > de...@ffmpeg.org>
> > > Subject: Re: [FFmpeg-devel] [PATCH, v2 2/2] lavc/vaapi_decode:
> > > >> recreate
> > > hw_frames_ctx for vp9 without destroy va_context
> > >
> > > On Tue, Aug 6, 2019 at 10:55 AM Fu, Linjie
> > wrote:
> > > >
> > > >> -Original Message-
> > > >> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org]
> > > On
> > > Behalf
> > > >> Of Hendrik Leppkes
> > > >> Sent: Tuesday, August 6, 2019 16:27
> > > >> To: FFmpeg development discussions and patches > > >> de...@ffmpeg.org>
> > > >> Subject: Re: [FFmpeg-devel] [PATCH, v2 2/2] lavc/vaapi_decode:
> > > recreate
> > > >> hw_frames_ctx for vp9 without destroy va_context
> > > >>
> > > >> On Thu, Jul 11, 2019 at 10:20 AM Linjie Fu >
> > > wrote:
> > > >>>
> > > >>> VP9 allows resolution changes per frame. Currently in VAAPI,
> > > >>> resolution
> > > >>> changes leads to va context destroy and reinit. This will cause
> > > >>> reference frame surface lost and produce garbage.
> > > >>>
> > > >>> Though refs surface id could be passed to media driver and
> found
> > > in
> > > >>> RTtbl, vp9RefList[] in hal layer has already been destroyed.
> Thus
> > > the
> > > >>> new created VaContext could only got an empty RefList.
> > > >>>
> > > >>> As libva allows re-create surface separately without changing
> the
> > > >>> context, this issue could be handled by only recreating
> > > >>> hw_frames_ctx.
> > > >>>
> > > >>> Set hwaccel_priv_data_keeping flag for vp9 to only recreating
> > > >>> hw_frame_ctx when dynamic resolution changing happens.
> > > >>>
> > > >>> Could be verified by:
> > > >>> ffmpeg -hwaccel vaapi -hwaccel_device /dev/dri/renderD128 -i
> > > >>> ./resolutions.ivf -pix_fmt p010le -f rawvideo -vframes 20 -y
> > > >> vaapi.yuv
> > > >>>
> > > >>> Signed-off-by: Linjie Fu
> > > >>> ---
> > > >>> libavcodec/decode.c| 10 +-
> > > >>> libavcodec/internal.h | 1 +
> > > >>> libavcodec/pthread_frame.c | 2 ++
> > > >>> libavcodec/vaapi_decode.c | 40 ++
> > --
> > > -
> > > >> --
> > > >>> --
> > > -
> > > >> --
> > > >>> libavcodec/vaapi_vp9.c | 4
> > > >>> 5 files changed, 34 insertions(+), 23 deletions(-)
> > > >>>
> > > >>> diff --git a/libavcodec/decode.c b/libavcodec/decode.c
> > > >>> index 0863b82..7b15fa5 100644
> > > >>> --- a/libavcodec/decode.c
> > > >>> +++ b/libavcodec/decode.c
> > > >>> @@ -1254,7 +1254,6 @@ int
> > > >> ff_decode_get_hw_frames_ctx(AVCodecContext *avctx,
> > > >>>
> > > >>> frames_ctx = (AVHWFramesContext*)avctx->hw_frames_ctx-
> > > data;
> > > >>>
> > > >>> -
> > > >>> if (frames_ctx->initial_pool_size) {
> > > >>> // We guarantee 4 base work surfaces. The function
> above
> > > guarantees
> > > >> 1
> > > >>> // (the absolute minimum), so add the
Re: [FFmpeg-devel] vp9_qsv encoder
i9-9900k is coffee lake IIRC, but vp9_qsv encoder just be supported since Ice lake. BTW, such question should be moved to FFmpeg-user channel. Alex <3.1...@ukr.net> 于2019年11月20日周三 上午2:14写道： > > Is it vp9_qsv encoder will work on i9-9900k Intel CPU or we need to wait for > new CPU release from Intel? > ___ > 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 v1] avcodec/vaapi: set more flags for VASurfaceAttrib
> On Tue, Nov 19, 2019 at 4:24 PM Wangfei wrote:
> >
> > flags and value.type is needed when pass VASurfaceAttrib to driver.
> > Otherwise the attribute will be considered invalid in driver.
> >
> > Signed-off-by: Wangfei
> > ---
> > libavcodec/vaapi_decode.c | 2 ++
> > 1 file changed, 2 insertions(+)
> >
> > diff --git a/libavcodec/vaapi_decode.c b/libavcodec/vaapi_decode.c
> > index 69512e1d45..a93aba5a5d 100644
> > --- a/libavcodec/vaapi_decode.c
> > +++ b/libavcodec/vaapi_decode.c
> > @@ -350,6 +350,8 @@ static int
> > vaapi_decode_find_best_format(AVCodecContext *avctx,
> >
> > ctx->pixel_format_attribute = (VASurfaceAttrib) {
> > .type = VASurfaceAttribPixelFormat,
> > +.flags = VA_SURFACE_ATTRIB_SETTABLE,
> > +.value.type= VAGenericValueTypeInteger,
> I can't found any description in libva about this part, do you have any other
> docs?
I checked the logic of vaCreateSurfaces implementation in media-driver, it will
check flags and value.type in VASurfaceAttrib when using it. If leaks of the
info, it will consider the attribute is invalid or assert(in this case, flags
checked first, so no assert occurred.):
https://github.com/intel/media-driver/blob/8a8b8ae263a04cb5dd384d4625215cf296d2cc59/media_driver/linux/common/ddi/media_libva.cpp#L2149
On the other hand, there is another place in ffmpeg-vaapi that sets
VASurfaceAttrib, and it filled flags and value.type:
https://github.com/FFmpeg/FFmpeg/blob/d73f06270600c37c74beeceac37f593838ced383/libavutil/hwcontext_vaapi.c#L527
So I believe here we need do the same thing.
> > .value.value.i = best_fourcc,
> > };
> >
> > --
> > 2.17.1
> >
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] avfilter/vf_nlmeans: add >8 bit support
On Wed, Nov 20, 2019 at 6:43 AM Paul B Mahol wrote:
>
> Signed-off-by: Paul B Mahol
> ---
> libavfilter/aarch64/vf_nlmeans_init.c | 4 +-
> libavfilter/nlmeans_template.c| 366 ++
> libavfilter/vf_nlmeans.c | 526 ++
> libavfilter/vf_nlmeans.h | 44 ++-
> 4 files changed, 520 insertions(+), 420 deletions(-)
> create mode 100644 libavfilter/nlmeans_template.c
>
> diff --git a/libavfilter/aarch64/vf_nlmeans_init.c
> b/libavfilter/aarch64/vf_nlmeans_init.c
> index a1edefb144..ee87c88dd6 100644
> --- a/libavfilter/aarch64/vf_nlmeans_init.c
> +++ b/libavfilter/aarch64/vf_nlmeans_init.c
> @@ -24,10 +24,10 @@ void ff_compute_safe_ssd_integral_image_neon(uint32_t
> *dst, ptrdiff_t dst_linesi
> const uint8_t *s2, ptrdiff_t
> linesize2,
> int w, int h);
>
> -av_cold void ff_nlmeans_init_aarch64(NLMeansDSPContext *dsp)
> +av_cold void ff_nlmeans_init_aarch64(NLMeansDSPContext *dsp, int depth)
> {
> int cpu_flags = av_get_cpu_flags();
>
> -if (have_neon(cpu_flags))
> +if (have_neon(cpu_flags) && depth == 8)
> dsp->compute_safe_ssd_integral_image =
> ff_compute_safe_ssd_integral_image_neon;
> }
> diff --git a/libavfilter/nlmeans_template.c b/libavfilter/nlmeans_template.c
> new file mode 100644
> index 00..64ac2e9e9b
> --- /dev/null
> +++ b/libavfilter/nlmeans_template.c
> @@ -0,0 +1,366 @@
> +/*
> + * Copyright (c) 2016 Clément Bœsch
> + *
> + * 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 "avfilter.h"
> +#include "formats.h"
> +#include "internal.h"
> +#include "vf_nlmeans.h"
> +#include "video.h"
> +
> +#undef pixel
> +#undef integral
> +#if DEPTH <= 8
> +#define pixel uint8_t
> +#define integral uint32_t
> +#else
> +#define pixel uint16_t
> +#define integral uint64_t
> +#endif
> +
> +#define fn3(a,b) a##b
> +#define fn2(a,b) fn3(a,b)
> +#define fn(a) fn2(a, DEPTH)
> +
> +/**
> + * Compute squared difference of the safe area (the zone where s1 and s2
> + * overlap). It is likely the largest integral zone, so it is interesting to
> do
> + * as little checks as possible; contrary to the unsafe version of this
> + * function, we do not need any clipping here.
> + *
> + * The line above dst and the column to its left are always readable.
> + */
> +static void fn(compute_safe_ssd_integral_image_c)(uint32_t *ddst, ptrdiff_t
> dst_linesize_32,
> + const uint8_t *ss1,
> ptrdiff_t linesize1,
> + const uint8_t *ss2,
> ptrdiff_t linesize2,
> + int w, int h)
> +{
> +const pixel *s1 = (const pixel *)ss1;
> +const pixel *s2 = (const pixel *)ss2;
> +int x, y;
> +integral *dst = (integral *)ddst;
> +const integral *dst_top = dst - dst_linesize_32;
> +
> +linesize1 /= sizeof(pixel);
> +linesize2 /= sizeof(pixel);
> +
> +/* SIMD-friendly assumptions allowed here */
> +av_assert2(!(w & 0xf) && w >= 16 && h >= 1);
> +
> +for (y = 0; y < h; y++) {
> +for (x = 0; x < w; x += 4) {
> +const int d0 = s1[x] - s2[x];
> +const int d1 = s1[x + 1] - s2[x + 1];
> +const int d2 = s1[x + 2] - s2[x + 2];
> +const int d3 = s1[x + 3] - s2[x + 3];
> +
> +dst[x] = dst_top[x] - dst_top[x - 1] + d0*d0;
> +dst[x + 1] = dst_top[x + 1] - dst_top[x] + d1*d1;
> +dst[x + 2] = dst_top[x + 2] - dst_top[x + 1] + d2*d2;
> +dst[x + 3] = dst_top[x + 3] - dst_top[x + 2] + d3*d3;
> +
> +dst[x] += dst[x - 1];
> +dst[x + 1] += dst[x];
> +dst[x + 2] += dst[x + 1];
> +dst[x + 3] += dst[x + 2];
> +}
> +s1 += linesize1;
> +s2 += linesize2;
> +dst += dst_linesize_32;
> +dst_top += dst_linesize_32;
> +}
> +}
> +
> +/**
> + * Compute squared difference of an unsafe area (the zone nor s1 nor s2 could
> + * be readable).
> + *
> + * On the other hand, the line
Re: [FFmpeg-devel] [PATCH 2/2] avcodec/dvdec: Use av_clip_uint8 instead of ff_crop_tab
On Mon, Nov 18, 2019 at 09:02:48AM -0800, Baptiste Coudurier wrote:
>
> > On Nov 15, 2019, at 3:10 PM, Michael Niedermayer
> > wrote:
> >
> > Fixes: out of array access
> > Fixes:
> > 18788/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_DVVIDEO_fuzzer-6254863113781248
> >
> > Found-by: continuous fuzzing process
> > https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
> > Signed-off-by: Michael Niedermayer
> > ---
> > libavcodec/dvdec.c | 3 +--
> > 1 file changed, 1 insertion(+), 2 deletions(-)
> >
> > diff --git a/libavcodec/dvdec.c b/libavcodec/dvdec.c
> > index 578d7f505f..c526091eb4 100644
> > --- a/libavcodec/dvdec.c
> > +++ b/libavcodec/dvdec.c
> > @@ -272,11 +272,10 @@ static inline void bit_copy(PutBitContext *pb,
> > GetBitContext *gb)
> > static av_always_inline void put_block_8x4(int16_t *block, uint8_t
> > *av_restrict p, int stride)
> > {
> > int i, j;
> > -const uint8_t *cm = ff_crop_tab + MAX_NEG_CROP;
> >
> > for (i = 0; i < 4; i++) {
> > for (j = 0; j < 8; j++)
> > -p[j] = cm[block[j]];
> > +p[j] = av_clip_uint8(block[j]);
> > block += 8;
> > p += stride;
> > }
>
> LGTM
will apply
thx
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
No great genius has ever existed without some touch of madness. -- Aristotle
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] Allow using primary CUDA device context
On 19.11.2019 17:42, Oleg Dobkin wrote: Any more comments? Only thing I'm still wondering is if it would make sense to use the primary context by default. I can't think of any obvious downsides, other than weakened isolation, which really shouldn't be a huge concern. And there apparently are some potential performance gains. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH] avfilter/vf_nlmeans: add >8 bit support
Signed-off-by: Paul B Mahol
---
libavfilter/aarch64/vf_nlmeans_init.c | 4 +-
libavfilter/nlmeans_template.c| 366 ++
libavfilter/vf_nlmeans.c | 526 ++
libavfilter/vf_nlmeans.h | 44 ++-
4 files changed, 520 insertions(+), 420 deletions(-)
create mode 100644 libavfilter/nlmeans_template.c
diff --git a/libavfilter/aarch64/vf_nlmeans_init.c
b/libavfilter/aarch64/vf_nlmeans_init.c
index a1edefb144..ee87c88dd6 100644
--- a/libavfilter/aarch64/vf_nlmeans_init.c
+++ b/libavfilter/aarch64/vf_nlmeans_init.c
@@ -24,10 +24,10 @@ void ff_compute_safe_ssd_integral_image_neon(uint32_t *dst,
ptrdiff_t dst_linesi
const uint8_t *s2, ptrdiff_t
linesize2,
int w, int h);
-av_cold void ff_nlmeans_init_aarch64(NLMeansDSPContext *dsp)
+av_cold void ff_nlmeans_init_aarch64(NLMeansDSPContext *dsp, int depth)
{
int cpu_flags = av_get_cpu_flags();
-if (have_neon(cpu_flags))
+if (have_neon(cpu_flags) && depth == 8)
dsp->compute_safe_ssd_integral_image =
ff_compute_safe_ssd_integral_image_neon;
}
diff --git a/libavfilter/nlmeans_template.c b/libavfilter/nlmeans_template.c
new file mode 100644
index 00..64ac2e9e9b
--- /dev/null
+++ b/libavfilter/nlmeans_template.c
@@ -0,0 +1,366 @@
+/*
+ * Copyright (c) 2016 Clément Bœsch
+ *
+ * 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 "avfilter.h"
+#include "formats.h"
+#include "internal.h"
+#include "vf_nlmeans.h"
+#include "video.h"
+
+#undef pixel
+#undef integral
+#if DEPTH <= 8
+#define pixel uint8_t
+#define integral uint32_t
+#else
+#define pixel uint16_t
+#define integral uint64_t
+#endif
+
+#define fn3(a,b) a##b
+#define fn2(a,b) fn3(a,b)
+#define fn(a) fn2(a, DEPTH)
+
+/**
+ * Compute squared difference of the safe area (the zone where s1 and s2
+ * overlap). It is likely the largest integral zone, so it is interesting to do
+ * as little checks as possible; contrary to the unsafe version of this
+ * function, we do not need any clipping here.
+ *
+ * The line above dst and the column to its left are always readable.
+ */
+static void fn(compute_safe_ssd_integral_image_c)(uint32_t *ddst, ptrdiff_t
dst_linesize_32,
+ const uint8_t *ss1,
ptrdiff_t linesize1,
+ const uint8_t *ss2,
ptrdiff_t linesize2,
+ int w, int h)
+{
+const pixel *s1 = (const pixel *)ss1;
+const pixel *s2 = (const pixel *)ss2;
+int x, y;
+integral *dst = (integral *)ddst;
+const integral *dst_top = dst - dst_linesize_32;
+
+linesize1 /= sizeof(pixel);
+linesize2 /= sizeof(pixel);
+
+/* SIMD-friendly assumptions allowed here */
+av_assert2(!(w & 0xf) && w >= 16 && h >= 1);
+
+for (y = 0; y < h; y++) {
+for (x = 0; x < w; x += 4) {
+const int d0 = s1[x] - s2[x];
+const int d1 = s1[x + 1] - s2[x + 1];
+const int d2 = s1[x + 2] - s2[x + 2];
+const int d3 = s1[x + 3] - s2[x + 3];
+
+dst[x] = dst_top[x] - dst_top[x - 1] + d0*d0;
+dst[x + 1] = dst_top[x + 1] - dst_top[x] + d1*d1;
+dst[x + 2] = dst_top[x + 2] - dst_top[x + 1] + d2*d2;
+dst[x + 3] = dst_top[x + 3] - dst_top[x + 2] + d3*d3;
+
+dst[x] += dst[x - 1];
+dst[x + 1] += dst[x];
+dst[x + 2] += dst[x + 1];
+dst[x + 3] += dst[x + 2];
+}
+s1 += linesize1;
+s2 += linesize2;
+dst += dst_linesize_32;
+dst_top += dst_linesize_32;
+}
+}
+
+/**
+ * Compute squared difference of an unsafe area (the zone nor s1 nor s2 could
+ * be readable).
+ *
+ * On the other hand, the line above dst and the column to its left are always
+ * readable.
+ *
+ * There is little point in having this function SIMDified as it is likely too
+ * complex and only handle small portions of the image.
+ *
+ * @param dst integral image
+ * @param dst_linesize_32 integral image linesize (in 32-bit integers
[FFmpeg-devel] headers for gapless playback
Hi Guys, We just did some research on gapless playback across multiple client devices, and could not find support for adding gapless metadata headers in ffmpeg. Our interest is specifically in AAC/MP4, and we ended up shifting to the fdk-aac package, which exposes options for adding moov/edts/elst headers (which are the ones we used) as well as iTunSMPB. So, I wanted to open a discussion with the team on ffmpeg support for gapless metadata. I’m not sure if you guys have discussed before, so here are a few opening questions to get me up to speed… 1. Does ffmpeg support addition of gapless metadata in any form currently, and we missed the doc as to how to specify it? 2. If not, have you discussed previously? If so, what were the results? (I.e. rejected as evil, put on roadmap but in future, currently in development, etc.) 3. If support is still in the future, would you be open to me contributing a patch that implements it? Any comments would be welcome. Thanks, John ___ 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] fate/cbs: add initial AV1 tests
On 11/18/2019 12:02 AM, James Almer wrote: > Signed-off-by: James Almer > --- > tests/fate/cbs.mak| 26 ++- > .../fate/cbs-av1-av1-1-b10-23-film_grain-50 | 1 + > tests/ref/fate/cbs-av1-av1-1-b8-02-allintra | 1 + > tests/ref/fate/cbs-av1-av1-1-b8-03-sizedown | 1 + > tests/ref/fate/cbs-av1-av1-1-b8-03-sizeup | 1 + > tests/ref/fate/cbs-av1-av1-1-b8-04-cdfupdate | 1 + > tests/ref/fate/cbs-av1-av1-1-b8-05-mv | 1 + > tests/ref/fate/cbs-av1-av1-1-b8-06-mfmv | 1 + > .../fate/cbs-av1-av1-1-b8-23-film_grain-50| 1 + > .../fate/cbs-av1-frames_refs_short_signaling | 1 + > tests/ref/fate/cbs-av1-non_uniform_tiling | 1 + > tests/ref/fate/cbs-av1-seq_hdr_op_param_info | 1 + > 12 files changed, 36 insertions(+), 1 deletion(-) > create mode 100644 tests/ref/fate/cbs-av1-av1-1-b10-23-film_grain-50 > create mode 100644 tests/ref/fate/cbs-av1-av1-1-b8-02-allintra > create mode 100644 tests/ref/fate/cbs-av1-av1-1-b8-03-sizedown > create mode 100644 tests/ref/fate/cbs-av1-av1-1-b8-03-sizeup > create mode 100644 tests/ref/fate/cbs-av1-av1-1-b8-04-cdfupdate > create mode 100644 tests/ref/fate/cbs-av1-av1-1-b8-05-mv > create mode 100644 tests/ref/fate/cbs-av1-av1-1-b8-06-mfmv > create mode 100644 tests/ref/fate/cbs-av1-av1-1-b8-23-film_grain-50 > create mode 100644 tests/ref/fate/cbs-av1-frames_refs_short_signaling > create mode 100644 tests/ref/fate/cbs-av1-non_uniform_tiling > create mode 100644 tests/ref/fate/cbs-av1-seq_hdr_op_param_info Applied. ___ 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] vp9_qsv encoder
Is it vp9_qsv encoder will work on i9-9900k Intel CPU or we need to wait for new CPU release from Intel? ___ 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] av_read_frame timeout
On Sun, Nov 17, 2019 at 06:37:58PM -0300, gga wrote:
> The following patch adds a timeout interrupt to av_read_frame to prevent it
> from hanging up the application. This patch was proposed some years ago but
> was not applied back then. I believe it is useful and should be considered
> for approval.
>
> diff --git a/libavformat/utils.c b/libavformat/utils.c
> index 8196442dd1..d98ebe46a4 100644
> --- a/libavformat/utils.c
> +++ b/libavformat/utils.c
> @@ -1792,6 +1792,12 @@ int av_read_frame(AVFormatContext *s, AVPacket *pkt)
> }
>
> for (;;) {
> +if (ff_check_interrupt(>interrupt_callback)) {
> + ret = AVERROR_EXIT;
> + av_log(s, AV_LOG_DEBUG, "interrupted\n");
> + return ret;
> +}
> +
> AVPacketList *pktl = s->internal->packet_buffer;
In principle i dont see why this change would be bad (if it fixes some
use case)
but a few things needs to be corrected
the author of the commit has to be corrected
the indention is inconsistent
the ret variable is unneeded
also this mixes declarations and statements, it should be moved down
and i would move this so ff_check_interrupt() is only called if the loop
iterates and not on the first iteration
thx
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
it is not once nor twice but times without number that the same ideas make
their appearance in the world. -- Aristotle
signature.asc
Description: PGP signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH v2 5/6] avcodec/cbs_jpeg: Write scan data directly
This commit makes use of the fact that the final unit buffer is now
allocated within write_unit to avoid a memcpy of scan data: It is now no
longer copied into an intermediate buffer before being written into the
final buffer, but directly written into the final buffer.
Writing the scan element in cbs_jpeg used an intermediate buffer
to write the scan header followed by the scan data that was copied
into said buffer. Afterwards, the final buffer for the element was
allocated and everything copied into this buffer. But it is trivial to
compute the needed size of the final buffer after having written the
header, so one can allocate the final buffer immediately and copy the
scan data directly into it, avoiding a memcpy.
Signed-off-by: Andreas Rheinhardt
---
libavcodec/cbs_jpeg.c | 33 +++--
1 file changed, 23 insertions(+), 10 deletions(-)
diff --git a/libavcodec/cbs_jpeg.c b/libavcodec/cbs_jpeg.c
index da22bdf720..dacdfa985b 100644
--- a/libavcodec/cbs_jpeg.c
+++ b/libavcodec/cbs_jpeg.c
@@ -330,24 +330,37 @@ static int cbs_jpeg_write_scan(CodedBitstreamContext *ctx,
PutBitContext *pbc)
{
JPEGRawScan *scan = unit->content;
+size_t header_size, size;
int err;
err = cbs_jpeg_write_scan_header(ctx, pbc, >header);
if (err < 0)
return err;
-if (scan->data) {
-if (scan->data_size * 8 > put_bits_left(pbc))
-return AVERROR(ENOSPC);
+av_assert0(put_bits_count(pbc) % 8 == 0);
-av_assert0(put_bits_count(pbc) % 8 == 0);
+flush_put_bits(pbc);
+header_size = size = put_bits_count(pbc) / 8;
-flush_put_bits(pbc);
+if (scan->data) {
+if (scan->data_size > INT_MAX - AV_INPUT_BUFFER_PADDING_SIZE
+ - header_size)
+return AVERROR(ENOMEM);
-memcpy(put_bits_ptr(pbc), scan->data, scan->data_size);
-skip_put_bytes(pbc, scan->data_size);
+size += scan->data_size;
}
+err = ff_cbs_alloc_unit_data(ctx, unit, size);
+if (err < 0)
+return err;
+
+unit->data_bit_padding = 0;
+
+memcpy(unit->data, pbc->buf, header_size);
+
+if (scan->data)
+memcpy(unit->data + header_size, scan->data, scan->data_size);
+
return 0;
}
@@ -387,9 +400,9 @@ static int cbs_jpeg_write_unit(CodedBitstreamContext *ctx,
int err;
if (unit->type == JPEG_MARKER_SOS)
-err = cbs_jpeg_write_scan (ctx, unit, pbc);
-else
-err = cbs_jpeg_write_segment(ctx, unit, pbc);
+return cbs_jpeg_write_scan(ctx, unit, pbc);
+
+err = cbs_jpeg_write_segment(ctx, unit, pbc);
if (err < 0)
return err;
--
2.20.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] Allow using primary CUDA device context
Any more comments? On Mon, 2019-11-18 at 15:39 +0200, Oleg Dobkin wrote: > Updated > > On Mon, 2019-11-18 at 13:51 +0100, Timo Rothenpieler wrote: > > On 18/11/2019 12:25, Oleg Dobkin wrote: > > FFmpeg supports multiple tracks of the Video Codec SDK, to support > older > drivers and legacy GPUs that way. > Since the version number only tracks the Video SDK Version, and not > the > CUDA loader version, what needs to be done is to set the new minimum > version for each supported track. > So far, there was no need to add explicit checks for SDK 9.1, but > that > will be required for this. > Also, since SDK 8.0 is effectively dead, it can be dropped. > > I immediately bump the version on ffnvcodec git after every release, > so > the correct versions to check for in configure right now are: > 9.1.23.1, 9.0.18.3, 8.2.15.10 and 8.1.24.11 > > I'm not sure I understand this. As I see - ffmpeg wouldn't compile > without the latest version of ffnvcodec, which would be 9.1.23.2 > after > the change is merged, so this is the only check that needs to be > performed, regardless of the supported Video SDK versions, isn't it? > > ffmpeg will compile with the latest version of each Video SDK Version > track. > ___ > 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 3/6] avcodec/cbs_vp9: Write frame data directly
Writing a unit (always a frame) in cbs_vp9 used an intermediate buffer
to write the frame header followed by the frame data that was copied
into said buffer. Afterwards, the final buffer for the frame was
allocated and everything copied into this buffer. But it is trivial to
compute the needed size of the final buffer after having written the
header, so one can allocate the final buffer immediately and copy the
frame data directly into it.
Signed-off-by: Andreas Rheinhardt
---
libavcodec/cbs_vp9.c | 25 +++--
1 file changed, 19 insertions(+), 6 deletions(-)
diff --git a/libavcodec/cbs_vp9.c b/libavcodec/cbs_vp9.c
index a74c4f4cec..c58589f07f 100644
--- a/libavcodec/cbs_vp9.c
+++ b/libavcodec/cbs_vp9.c
@@ -526,6 +526,7 @@ static int cbs_vp9_write_unit(CodedBitstreamContext *ctx,
PutBitContext *pbc)
{
VP9RawFrame *frame = unit->content;
+size_t data_size, header_size;
int err;
err = cbs_vp9_write_frame(ctx, pbc, frame);
@@ -535,16 +536,28 @@ static int cbs_vp9_write_unit(CodedBitstreamContext *ctx,
// Frame must be byte-aligned.
av_assert0(put_bits_count(pbc) % 8 == 0);
+flush_put_bits(pbc);
+data_size = header_size = put_bits_count(pbc) / 8;
+unit->data_bit_padding = 0;
+
if (frame->data) {
-if (frame->data_size > put_bits_left(pbc) / 8)
-return AVERROR(ENOSPC);
+if (frame->data_size > INT_MAX - AV_INPUT_BUFFER_PADDING_SIZE
+ - header_size)
+return AVERROR(ENOMEM);
-flush_put_bits(pbc);
-memcpy(put_bits_ptr(pbc), frame->data, frame->data_size);
-skip_put_bytes(pbc, frame->data_size);
+data_size += frame->data_size;
}
-return ff_cbs_default_write_unit_data(ctx, unit, pbc);
+err = ff_cbs_alloc_unit_data(ctx, unit, data_size);
+if (err < 0)
+return err;
+
+memcpy(unit->data, pbc->buf, header_size);
+
+if (frame->data)
+memcpy(unit->data + header_size, frame->data, frame->data_size);
+
+return 0;
}
static int cbs_vp9_assemble_fragment(CodedBitstreamContext *ctx,
--
2.20.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH v2 6/6] avcodec/cbs_av1: Write tile data directly
This commit makes use of the fact that the final unit buffer is now
allocated within write_unit to avoid a memcpy of tile data: It is now no
longer copied into an intermediate buffer before being written into the
final buffer, but directly written into the final buffer.
Signed-off-by: Andreas Rheinhardt
---
libavcodec/cbs_av1.c | 89 +---
1 file changed, 42 insertions(+), 47 deletions(-)
diff --git a/libavcodec/cbs_av1.c b/libavcodec/cbs_av1.c
index 7ff5539fb8..54687f93d2 100644
--- a/libavcodec/cbs_av1.c
+++ b/libavcodec/cbs_av1.c
@@ -1060,28 +1060,9 @@ static int cbs_av1_write_obu(CodedBitstreamContext *ctx,
CodedBitstreamAV1Context *priv = ctx->priv_data;
AV1RawOBU *obu = unit->content;
PutBitContext pbc_tmp;
-AV1RawTileData *td;
-size_t header_size;
-int err, start_pos, end_pos, data_pos;
-
-// OBUs in the normal bitstream format must contain a size field
-// in every OBU (in annex B it is optional, but we don't support
-// writing that).
-obu->header.obu_has_size_field = 1;
-
-err = cbs_av1_write_obu_header(ctx, pbc, >header);
-if (err < 0)
-return err;
-
-if (obu->header.obu_has_size_field) {
-pbc_tmp = *pbc;
-// Add space for the size field to fill later.
-put_bits32(pbc, 0);
-put_bits32(pbc, 0);
-}
-
-td = NULL;
-start_pos = put_bits_count(pbc);
+AV1RawTileData *td = NULL;
+size_t header_size, obu_header_size, size, td_offset;
+int err, end_pos;
priv->ref = (AV1ReferenceFrameState *)>write_ref;
@@ -1168,8 +1149,9 @@ static int cbs_av1_write_obu(CodedBitstreamContext *ctx,
}
end_pos = put_bits_count(pbc);
-header_size = (end_pos - start_pos + 7) / 8;
+header_size = (end_pos + 7) / 8;
if (td) {
+// The possible overflow here is checked below.
obu->obu_size = header_size + td->data_size;
} else if (header_size > 0) {
// Add trailing bits and recalculate.
@@ -1177,47 +1159,60 @@ static int cbs_av1_write_obu(CodedBitstreamContext *ctx,
if (err < 0)
return err;
end_pos = put_bits_count(pbc);
-obu->obu_size = header_size = (end_pos - start_pos + 7) / 8;
+obu->obu_size = header_size = (end_pos + 7) / 8;
} else {
// Empty OBU.
obu->obu_size = 0;
}
-end_pos = put_bits_count(pbc);
// Must now be byte-aligned.
av_assert0(end_pos % 8 == 0);
flush_put_bits(pbc);
-start_pos /= 8;
-end_pos /= 8;
-*pbc = pbc_tmp;
-err = cbs_av1_write_leb128(ctx, pbc, "obu_size", obu->obu_size);
+obu_header_size = 1 + !!obu->header.obu_extension_flag
++ (av_log2(obu->obu_size) + 7) / 7;
+
+// The size of everything except the tile data.
+size = td_offset = obu_header_size + header_size;
+
+if (td) {
+if (td->data_size > INT_MAX - AV_INPUT_BUFFER_PADDING_SIZE
+- size)
+return AVERROR(ENOMEM);
+
+// If we are here, header_size + td->data_size fits into an int,
+// so a fortiori no overflow happened in the calculation of
+// obu->obu_size which also fits in an int.
+size += td->data_size;
+}
+
+err = ff_cbs_alloc_unit_data(ctx, unit, size);
if (err < 0)
return err;
-data_pos = put_bits_count(pbc) / 8;
-flush_put_bits(pbc);
-av_assert0(data_pos <= start_pos);
+unit->data_bit_padding = 0;
-if (8 * obu->obu_size > put_bits_left(pbc))
-return AVERROR(ENOSPC);
+init_put_bits(_tmp, unit->data, obu_header_size);
-if (obu->obu_size > 0) {
-memmove(pbc->buf + data_pos,
-pbc->buf + start_pos, header_size);
-skip_put_bytes(pbc, header_size);
+// OBUs in the normal bitstream format must contain a size field
+// in every OBU (in annex B it is optional, but we don't support
+// writing that).
+obu->header.obu_has_size_field = 1;
-if (td) {
-memcpy(pbc->buf + data_pos + header_size,
- td->data, td->data_size);
-skip_put_bytes(pbc, td->data_size);
-}
-}
+err = cbs_av1_write_obu_header(ctx, _tmp, >header);
+if (err < 0)
+return err;
-// OBU data must be byte-aligned.
-av_assert0(put_bits_count(pbc) % 8 == 0);
+err = cbs_av1_write_leb128(ctx, _tmp, "obu_size", obu->obu_size);
+av_assert0(err >= 0 && put_bits_left(_tmp) == 0);
+flush_put_bits(_tmp);
-return ff_cbs_default_write_unit_data(ctx, unit, pbc);
+memcpy(unit->data + obu_header_size, pbc->buf, header_size);
+
+if (td)
+memcpy(unit->data + td_offset, td->data, td->data_size);
+
+return 0;
}
static int cbs_av1_assemble_fragment(CodedBitstreamContext *ctx,
--
2.20.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
[FFmpeg-devel] [PATCH v2 2/6] avcodec/cbs: Move allocation of unit data into write_unit
when writing a unit from content.
Writing a unit (i.e. assembling it from its decomposed form) currently
always uses an intermediate buffer; only after the unit has been
completely assembled in this buffer (so that, in particular, the needed
size is known), is the final buffer allocated and the data copied.
This works well for most types of units except one: The slice/frame
units that usually make up the bulk of the whole data. Only their
headers are reassembled from content. Their actual data are mostly just
copied into the write buffer. Given that the size of the actual data is
known, one has a very good estimate on the needed size after having
assembled the slice/frame header only. If one allocated the necessary
buffer now and directly copied the frame header and frame data into it,
one can avoid copying the data into the temporary buffer.
This commit lays the groundwork for doing so by moving the data buffer's
allocation into the (codec-dependent) write_unit function. It does not
avoid copying yet.
Signed-off-by: Andreas Rheinhardt
---
libavcodec/cbs.c | 38 ++
libavcodec/cbs_av1.c | 2 +-
libavcodec/cbs_h2645.c| 4 ++--
libavcodec/cbs_internal.h | 12 +++-
libavcodec/cbs_jpeg.c | 10 --
libavcodec/cbs_mpeg2.c| 10 --
libavcodec/cbs_vp9.c | 2 +-
7 files changed, 53 insertions(+), 25 deletions(-)
diff --git a/libavcodec/cbs.c b/libavcodec/cbs.c
index 0badb192d9..aa2e4904d0 100644
--- a/libavcodec/cbs.c
+++ b/libavcodec/cbs.c
@@ -283,6 +283,28 @@ int ff_cbs_read(CodedBitstreamContext *ctx,
return cbs_read_fragment_content(ctx, frag);
}
+int ff_cbs_default_write_unit_data(CodedBitstreamContext *ctx,
+ CodedBitstreamUnit *unit,
+ PutBitContext *pbc)
+{
+int err;
+
+if (put_bits_count(pbc) % 8)
+unit->data_bit_padding = 8 - put_bits_count(pbc) % 8;
+else
+unit->data_bit_padding = 0;
+
+flush_put_bits(pbc);
+
+err = ff_cbs_alloc_unit_data(ctx, unit, put_bits_count(pbc) / 8);
+if (err < 0)
+return err;
+
+memcpy(unit->data, pbc->buf, unit->data_size);
+
+return 0;
+}
+
static int cbs_write_unit_data(CodedBitstreamContext *ctx,
CodedBitstreamUnit *unit)
{
@@ -318,22 +340,6 @@ static int cbs_write_unit_data(CodedBitstreamContext *ctx,
return ret;
}
-// Overflow but we didn't notice.
-av_assert0(put_bits_count() <= 8 * ctx->write_buffer_size);
-
-if (put_bits_count() % 8)
-unit->data_bit_padding = 8 - put_bits_count() % 8;
-else
-unit->data_bit_padding = 0;
-
-flush_put_bits();
-
-ret = ff_cbs_alloc_unit_data(ctx, unit, put_bits_count() / 8);
-if (ret < 0)
-return ret;
-
-memcpy(unit->data, ctx->write_buffer, unit->data_size);
-
return 0;
}
diff --git a/libavcodec/cbs_av1.c b/libavcodec/cbs_av1.c
index bbe4461130..7ff5539fb8 100644
--- a/libavcodec/cbs_av1.c
+++ b/libavcodec/cbs_av1.c
@@ -1217,7 +1217,7 @@ static int cbs_av1_write_obu(CodedBitstreamContext *ctx,
// OBU data must be byte-aligned.
av_assert0(put_bits_count(pbc) % 8 == 0);
-return 0;
+return ff_cbs_default_write_unit_data(ctx, unit, pbc);
}
static int cbs_av1_assemble_fragment(CodedBitstreamContext *ctx,
diff --git a/libavcodec/cbs_h2645.c b/libavcodec/cbs_h2645.c
index 88fa0029cd..d3d5342bad 100644
--- a/libavcodec/cbs_h2645.c
+++ b/libavcodec/cbs_h2645.c
@@ -1265,7 +1265,7 @@ static int cbs_h264_write_nal_unit(CodedBitstreamContext
*ctx,
return AVERROR_PATCHWELCOME;
}
-return 0;
+return ff_cbs_default_write_unit_data(ctx, unit, pbc);
}
static int cbs_h265_write_nal_unit(CodedBitstreamContext *ctx,
@@ -1377,7 +1377,7 @@ static int cbs_h265_write_nal_unit(CodedBitstreamContext
*ctx,
return AVERROR_PATCHWELCOME;
}
-return 0;
+return ff_cbs_default_write_unit_data(ctx, unit, pbc);
}
static int cbs_h2645_assemble_fragment(CodedBitstreamContext *ctx,
diff --git a/libavcodec/cbs_internal.h b/libavcodec/cbs_internal.h
index 4c5a535ca6..96c2a1ac80 100644
--- a/libavcodec/cbs_internal.h
+++ b/libavcodec/cbs_internal.h
@@ -44,7 +44,9 @@ typedef struct CodedBitstreamType {
int (*read_unit)(CodedBitstreamContext *ctx,
CodedBitstreamUnit *unit);
-// Write the data bitstream from unit->content into pbc.
+// Write the data bitstream from unit->content. This includes
+// allocating the buffer as well as setting all of unit's data-fields.
+// The supplied PutBitContext may be used as temporary buffer.
// Return value AVERROR(ENOSPC) indicates that pbc was too small.
int (*write_unit)(CodedBitstreamContext *ctx,
CodedBitstreamUnit *unit,
@@ -60,6 +62,14 @@ typedef struct CodedBitstreamType {
} CodedBitstreamType;
+// Helper function to convert pbc's content
[FFmpeg-devel] [PATCH v2 4/6] avcodec/cbs_h2645: Write slice data directly
Up until now, writing the data of a slice uses an intermediate buffer
into which the unit (both header as well as the rest) is assembled
before being copied into a freshly allocated buffer. But given that one
has a very good upper bound on the size needed before one starts copying
the slice data, one can allocate the buffer in advance, copy the already
written header into it and directly assemble the rest of the unit in
this buffer.
It proved easier to potentially allocate one byte more and decrement
the size afterwards if it needs to be decremented than to calculate the
exact amount in advance. It is even easier than the current way of
determining whether the last byte needs to be written or not.
Signed-off-by: Andreas Rheinhardt
---
libavcodec/cbs_h2645.c | 64 --
1 file changed, 31 insertions(+), 33 deletions(-)
diff --git a/libavcodec/cbs_h2645.c b/libavcodec/cbs_h2645.c
index d3d5342bad..81d0c478ec 100644
--- a/libavcodec/cbs_h2645.c
+++ b/libavcodec/cbs_h2645.c
@@ -1094,24 +1094,33 @@ static int cbs_h265_read_nal_unit(CodedBitstreamContext
*ctx,
}
static int cbs_h2645_write_slice_data(CodedBitstreamContext *ctx,
+ CodedBitstreamUnit *unit,
PutBitContext *pbc, const uint8_t *data,
size_t data_size, int data_bit_start)
{
size_t rest = data_size - (data_bit_start + 7) / 8;
+int size = (put_bits_count(pbc) - data_bit_start + 7) / 8;
const uint8_t *pos = data + data_bit_start / 8;
+int err;
av_assert0(data_bit_start >= 0 &&
data_size > data_bit_start / 8);
-if (data_size * 8 + 8 > put_bits_left(pbc))
-return AVERROR(ENOSPC);
+if (data_size > INT_MAX / 8 - size)
+return AVERROR(ENOMEM);
+
+// size might be one too big if in- and output are misaligned.
+size += data_size;
+
+err = ff_cbs_alloc_unit_data(ctx, unit, size);
+if (err < 0)
+return err;
-if (!rest)
-goto rbsp_stop_one_bit;
+// Rebase pbc onto the new buffer.
+memcpy(unit->data, pbc->buf, put_bits_ptr(pbc) - pbc->buf);
+rebase_put_bits(pbc, unit->data, size);
-// First copy the remaining bits of the first byte
-// The above check ensures that we do not accidentally
-// copy beyond the rbsp_stop_one_bit.
+// First copy the remaining bits of the first byte.
if (data_bit_start % 8)
put_bits(pbc, 8 - data_bit_start % 8,
*pos++ & MAX_UINT_BITS(8 - data_bit_start % 8));
@@ -1122,32 +1131,25 @@ static int
cbs_h2645_write_slice_data(CodedBitstreamContext *ctx,
// This happens normally for CABAC.
flush_put_bits(pbc);
memcpy(put_bits_ptr(pbc), pos, rest);
-skip_put_bytes(pbc, rest);
} else {
// If not, we have to copy manually.
-// rbsp_stop_one_bit forces us to special-case
-// the last byte.
-uint8_t temp;
-int i;
-for (; rest > 4; rest -= 4, pos += 4)
+for (; rest >= 4; rest -= 4, pos += 4)
put_bits32(pbc, AV_RB32(pos));
-for (; rest > 1; rest--, pos++)
+for (; rest > 0; rest--, pos++)
put_bits(pbc, 8, *pos);
-rbsp_stop_one_bit:
-temp = rest ? *pos : *pos & MAX_UINT_BITS(8 - data_bit_start % 8);
+// Pad with zeroes
+flush_put_bits(pbc);
-av_assert0(temp);
-i = ff_ctz(*pos);
-temp = temp >> i;
-i = rest ? (8 - i) : (8 - i - data_bit_start % 8);
-put_bits(pbc, i, temp);
-if (put_bits_count(pbc) % 8)
-put_bits(pbc, 8 - put_bits_count(pbc) % 8, 0);
+// Correct size if it is too big because of misalignment.
+if (!unit->data[size - 1])
+unit->data_size = size - 1;
}
+unit->data_bit_padding = 0;
+
return 0;
}
@@ -1207,11 +1209,9 @@ static int cbs_h264_write_nal_unit(CodedBitstreamContext
*ctx,
return err;
if (slice->data) {
-err = cbs_h2645_write_slice_data(ctx, pbc, slice->data,
- slice->data_size,
- slice->data_bit_start);
-if (err < 0)
-return err;
+return cbs_h2645_write_slice_data(ctx, unit, pbc, slice->data,
+ slice->data_size,
+ slice->data_bit_start);
} else {
// No slice data - that was just the header.
// (Bitstream may be unaligned!)
@@ -1341,11 +1341,9 @@ static int cbs_h265_write_nal_unit(CodedBitstreamContext
*ctx,
return err;
if (slice->data) {
-err = cbs_h2645_write_slice_data(ctx, pbc, slice->data,
-
[FFmpeg-devel] [PATCH v2 1/6] avcodec/cbs_jpeg: Use memcpy when writing pictures
This is possible because the size of a scan header is always a multiple
of a byte.
Signed-off-by: Andreas Rheinhardt
---
libavcodec/cbs_jpeg.c | 10 +++---
1 file changed, 7 insertions(+), 3 deletions(-)
diff --git a/libavcodec/cbs_jpeg.c b/libavcodec/cbs_jpeg.c
index b189cbd9b7..64fe70beab 100644
--- a/libavcodec/cbs_jpeg.c
+++ b/libavcodec/cbs_jpeg.c
@@ -330,7 +330,7 @@ static int cbs_jpeg_write_scan(CodedBitstreamContext *ctx,
PutBitContext *pbc)
{
JPEGRawScan *scan = unit->content;
-int i, err;
+int err;
err = cbs_jpeg_write_scan_header(ctx, pbc, >header);
if (err < 0)
@@ -340,8 +340,12 @@ static int cbs_jpeg_write_scan(CodedBitstreamContext *ctx,
if (scan->data_size * 8 > put_bits_left(pbc))
return AVERROR(ENOSPC);
-for (i = 0; i < scan->data_size; i++)
-put_bits(pbc, 8, scan->data[i]);
+av_assert0(put_bits_count(pbc) % 8 == 0);
+
+flush_put_bits(pbc);
+
+memcpy(put_bits_ptr(pbc), scan->data, scan->data_size);
+skip_put_bytes(pbc, scan->data_size);
}
return 0;
--
2.20.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] avfilter/vf_chromakey: add >8 bit support
On 18.11.2019 12:09, Paul B Mahol wrote: Signed-off-by: Paul B Mahol --- libavfilter/vf_chromakey.c | 142 +++-- 1 file changed, 137 insertions(+), 5 deletions(-) No complaints about the code. I don't have files to test with, but assuming you have tested this, it LGTM. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH] avdevice/xcbgrab: Improve non-shm performance
Use AVBufferPool.
before:
$ ffmpeg -benchmark -f x11grab -video_size 1920x1200 -r 200 -t 3 -i +0,0 -f
null -
...
frame= 600 fps=102 q=-0.0 Lsize=N/A time=00:00:03.00 bitrate=N/A speed=0.51x
video:314kB audio:0kB subtitle:0kB other streams:0kB global headers:0kB muxing
overhead: unknown
bench: utime=1.551s stime=3.428s rtime=5.884s
bench: maxrss=40132kB
after:
$ ffmpeg -benchmark -f x11grab -video_size 1920x1200 -r 200 -t 3 -i +0,0 -f
null -
...
frame= 600 fps=138 q=-0.0 Lsize=N/A time=00:00:03.00 bitrate=N/A speed=0.69x
video:314kB audio:0kB subtitle:0kB other streams:0kB global headers:0kB muxing
overhead: unknown
bench: utime=1.231s stime=2.407s rtime=4.349s
bench: maxrss=40096kB
Signed-off-by: Kusanagi Kouichi
---
libavdevice/xcbgrab.c | 38 +++---
1 file changed, 31 insertions(+), 7 deletions(-)
diff --git a/libavdevice/xcbgrab.c b/libavdevice/xcbgrab.c
index b7e689343e..fde9c534cd 100644
--- a/libavdevice/xcbgrab.c
+++ b/libavdevice/xcbgrab.c
@@ -42,6 +42,7 @@
#include "libavutil/opt.h"
#include "libavutil/parseutils.h"
#include "libavutil/time.h"
+#include "libavutil/buffer.h"
#include "libavformat/avformat.h"
#include "libavformat/internal.h"
@@ -71,6 +72,8 @@ typedef struct XCBGrabContext {
int region_border;
int centered;
+AVBufferPool *buf_pool;
+
const char *video_size;
const char *framerate;
@@ -146,6 +149,16 @@ static int xcbgrab_reposition(AVFormatContext *s,
return 0;
}
+static AVBufferRef *xcbgrab_allocate_buffer(const int size)
+{
+AVPacket pkt;
+
+if (av_new_packet(, size))
+return NULL;
+
+return pkt.buf;
+}
+
static int xcbgrab_frame(AVFormatContext *s, AVPacket *pkt)
{
XCBGrabContext *c = s->priv_data;
@@ -154,7 +167,7 @@ static int xcbgrab_frame(AVFormatContext *s, AVPacket *pkt)
xcb_drawable_t drawable = c->screen->root;
xcb_generic_error_t *e = NULL;
uint8_t *data;
-int length, ret;
+int length;
iq = xcb_get_image(c->conn, XCB_IMAGE_FORMAT_Z_PIXMAP, drawable,
c->x, c->y, c->width, c->height, ~0);
@@ -174,17 +187,21 @@ static int xcbgrab_frame(AVFormatContext *s, AVPacket
*pkt)
if (!img)
return AVERROR(EAGAIN);
+pkt->buf = av_buffer_pool_get(c->buf_pool);
+if (!pkt->buf) {
+free(img);
+return AVERROR(ENOMEM);
+}
+
data = xcb_get_image_data(img);
length = xcb_get_image_data_length(img);
-ret = av_new_packet(pkt, length);
-
-if (!ret)
-memcpy(pkt->data, data, length);
-
+memcpy(pkt->buf->data, data, length);
free(img);
+pkt->data = pkt->buf->data;
+pkt->size = pkt->buf->size;
-return ret;
+return 0;
}
static void wait_frame(AVFormatContext *s, AVPacket *pkt)
@@ -442,6 +459,7 @@ static av_cold int xcbgrab_read_close(AVFormatContext *s)
#endif
xcb_disconnect(ctx->conn);
+av_buffer_pool_uninit(>buf_pool);
return 0;
}
@@ -665,6 +683,12 @@ static av_cold int xcbgrab_read_header(AVFormatContext *s)
return ret;
}
+c->buf_pool = av_buffer_pool_init(c->frame_size, xcbgrab_allocate_buffer);
+if (ret < 0) {
+xcbgrab_read_close(s);
+return AVERROR(ENOMEM);
+}
+
#if CONFIG_LIBXCB_SHM
if ((c->has_shm = check_shm(c->conn)))
c->segment = xcb_generate_id(c->conn);
--
2.24.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] avdevice/xcbgrab: Handle reply and error properly
Fix a NULL dereference and leaks.
Signed-off-by: Kusanagi Kouichi
---
libavdevice/xcbgrab.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/libavdevice/xcbgrab.c b/libavdevice/xcbgrab.c
index b7e689343e..063fecf838 100644
--- a/libavdevice/xcbgrab.c
+++ b/libavdevice/xcbgrab.c
@@ -168,6 +168,7 @@ static int xcbgrab_frame(AVFormatContext *s, AVPacket *pkt)
"sequence:%u resource_id:%u minor_code:%u major_code:%u.\n",
e->response_type, e->error_code,
e->sequence, e->resource_id, e->minor_code, e->major_code);
+free(e);
return AVERROR(EACCES);
}
@@ -276,6 +277,7 @@ static int xcbgrab_frame_shm(AVFormatContext *s, AVPacket
*pkt)
e->response_type, e->error_code,
e->sequence, e->resource_id, e->minor_code, e->major_code);
+free(e);
return AVERROR(EACCES);
}
@@ -537,6 +539,8 @@ static int create_stream(AVFormatContext *s)
gc = xcb_get_geometry(c->conn, c->screen->root);
geo = xcb_get_geometry_reply(c->conn, gc, NULL);
+if (!geo)
+return AVERROR_EXTERNAL;
if (c->x + c->width > geo->width ||
c->y + c->height > geo->height) {
@@ -546,6 +550,7 @@ static int create_stream(AVFormatContext *s)
c->width, c->height,
c->x, c->y,
geo->width, geo->height);
+free(geo);
return AVERROR(EINVAL);
}
--
2.24.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] avfilter/vf_fade: add support for gbrp/gbrap formats
Signed-off-by: Paul B Mahol
---
libavfilter/vf_fade.c | 49 ++-
1 file changed, 44 insertions(+), 5 deletions(-)
diff --git a/libavfilter/vf_fade.c b/libavfilter/vf_fade.c
index bec765a09e..12b0d0c876 100644
--- a/libavfilter/vf_fade.c
+++ b/libavfilter/vf_fade.c
@@ -56,9 +56,11 @@ typedef struct FadeContext {
int start_frame, nb_frames;
int hsub, vsub, bpp;
unsigned int black_level, black_level_scaled;
+uint8_t is_rgb;
uint8_t is_packed_rgb;
uint8_t rgba_map[4];
int alpha;
+int is_planar;
uint64_t start_time, duration;
enum {VF_FADE_WAITING=0, VF_FADE_FADING, VF_FADE_DONE} fade_state;
uint8_t color_rgba[4]; ///< fade color
@@ -107,23 +109,27 @@ static int query_formats(AVFilterContext *ctx)
AV_PIX_FMT_RGB24,AV_PIX_FMT_BGR24,
AV_PIX_FMT_ARGB, AV_PIX_FMT_ABGR,
AV_PIX_FMT_RGBA, AV_PIX_FMT_BGRA,
+AV_PIX_FMT_GBRP, AV_PIX_FMT_GBRAP,
AV_PIX_FMT_NONE
};
static const enum AVPixelFormat pix_fmts_rgb[] = {
AV_PIX_FMT_RGB24,AV_PIX_FMT_BGR24,
AV_PIX_FMT_ARGB, AV_PIX_FMT_ABGR,
AV_PIX_FMT_RGBA, AV_PIX_FMT_BGRA,
+AV_PIX_FMT_GBRP,
AV_PIX_FMT_NONE
};
static const enum AVPixelFormat pix_fmts_alpha[] = {
AV_PIX_FMT_YUVA420P, AV_PIX_FMT_YUVA422P, AV_PIX_FMT_YUVA444P,
AV_PIX_FMT_ARGB, AV_PIX_FMT_ABGR,
AV_PIX_FMT_RGBA, AV_PIX_FMT_BGRA,
+AV_PIX_FMT_GBRAP,
AV_PIX_FMT_NONE
};
static const enum AVPixelFormat pix_fmts_rgba[] = {
AV_PIX_FMT_ARGB, AV_PIX_FMT_ABGR,
AV_PIX_FMT_RGBA, AV_PIX_FMT_BGRA,
+AV_PIX_FMT_GBRAP,
AV_PIX_FMT_NONE
};
AVFilterFormats *fmts_list;
@@ -159,11 +165,15 @@ static int config_props(AVFilterLink *inlink)
s->hsub = pixdesc->log2_chroma_w;
s->vsub = pixdesc->log2_chroma_h;
+ff_fill_rgba_map(s->rgba_map, inlink->format);
+
s->bpp = pixdesc->flags & AV_PIX_FMT_FLAG_PLANAR ?
1 :
av_get_bits_per_pixel(pixdesc) >> 3;
s->alpha &= !!(pixdesc->flags & AV_PIX_FMT_FLAG_ALPHA);
-s->is_packed_rgb = ff_fill_rgba_map(s->rgba_map, inlink->format) >= 0;
+s->is_planar = pixdesc->flags & AV_PIX_FMT_FLAG_PLANAR;
+s->is_rgb = pixdesc->flags & AV_PIX_FMT_FLAG_RGB;
+s->is_packed_rgb = !s->is_planar && s->is_rgb;
/* use CCIR601/709 black level for studio-level pixel non-alpha components
*/
s->black_level =
@@ -199,6 +209,29 @@ static av_always_inline void filter_rgb(FadeContext *s,
const AVFrame *frame,
}
}
+static av_always_inline void filter_rgb_planar(FadeContext *s, const AVFrame
*frame,
+ int slice_start, int slice_end,
+ int do_alpha)
+{
+int i, j;
+const uint8_t *c = s->color_rgba;
+
+for (i = slice_start; i < slice_end; i++) {
+uint8_t *pg = frame->data[0] + i * frame->linesize[0];
+uint8_t *pb = frame->data[1] + i * frame->linesize[1];
+uint8_t *pr = frame->data[2] + i * frame->linesize[2];
+uint8_t *pa = frame->data[3] + i * frame->linesize[3];
+for (j = 0; j < frame->width; j++) {
+#define INTERPP(c_name, c_idx) av_clip_uint8(((c[c_idx]<<16) + ((int)c_name -
(int)c[c_idx]) * s->factor + (1<<15)) >> 16)
+pr[j] = INTERPP(pr[j], 1);
+pg[j] = INTERPP(pg[j], 0);
+pb[j] = INTERPP(pb[j], 2);
+if (do_alpha)
+pa[j] = INTERPP(pa[j], 3);
+}
+}
+}
+
static int filter_slice_rgb(AVFilterContext *ctx, void *arg, int jobnr,
int nb_jobs)
{
@@ -207,7 +240,11 @@ static int filter_slice_rgb(AVFilterContext *ctx, void
*arg, int jobnr,
int slice_start = (frame->height * jobnr ) / nb_jobs;
int slice_end = (frame->height * (jobnr+1)) / nb_jobs;
-if (s->alpha)filter_rgb(s, frame, slice_start, slice_end, 1, 4);
+if (s->is_planar && s->alpha)
+ filter_rgb_planar(s, frame, slice_start, slice_end,
1);
+else if (s->is_planar)
+ filter_rgb_planar(s, frame, slice_start, slice_end,
0);
+else if (s->alpha)filter_rgb(s, frame, slice_start, slice_end, 1, 4);
else if (s->bpp == 3) filter_rgb(s, frame, slice_start, slice_end, 0, 3);
else if (s->bpp == 4) filter_rgb(s, frame, slice_start, slice_end, 0, 4);
else av_assert0(0);
@@ -224,8 +261,9 @@ static int filter_slice_luma(AVFilterContext *ctx, void
*arg, int jobnr,
int slice_end = (frame->height * (jobnr+1)) / nb_jobs;
int i, j;
+for (int k = 0; k < 1 + 2 * (s->is_planar && s->is_rgb); k++) {
for (i = slice_start; i < slice_end; i++) {
-uint8_t *p = frame->data[0] + i * frame->linesize[0];
+uint8_t *p = frame->data[k] + i * frame->linesize[k];
for
Re: [FFmpeg-devel] [IMP] Decisions...
I hereby here declare against this "Decisions" and will act against them.
On 11/19/19, Jean-Baptiste Kempf wrote:
> Hello fellow developers,
>
> Last week, a large number of us met during VDD
> (https://www.videolan.org/videolan/events/vdd19/), as I had announced
> previously on this very mailing list.
>
> The meeting was long but productive, as we talked about the organization of
> our community.
> Quite a few people were present, physically, a bit more than a dozen joined
> on the IRC channel, and 8 or 9 participated in the hangouts session. And we
> took a few decisions, that I will detail here.
>
> This mail is a bit long, but please read everything before reacting.
>
> But first, the people present were:
> - Thilo
> - Kyle
> - Ronald
> - Vittorio
> - Josh
> - Rodger (nonvoting)
> - Kieran
> - James Darnley
> - Sergio (nonvoting)
> - Steven Liu
> - Jan Ekström
> - Nikki (nonvoting)
> - Thierry Foucu
> - Carl Eugen
> - Lynne
> - Janne
> - Martin
> - Diego (nonvoting)
> - Anton (nonvoting)
> - Luca (nonvoting)
> - Jessica (nonvoting)
> - Michael Bradshaw
> - Lydia (nonvoting)
> - jb (nonvoting)
>
> On the hangouts and IRC, 3 people voted remotely, through jb, as a prox:
> - Michael
> - Jamrial
> - Kurosu
>
> --
>
> We voted about a few things to organize the community.
>
> First, we decided that we needed to act, and bootstrap some actions that
> will lead to more structured organization in the future.
> Of course, nothing is immutable, but we needed to start somewhere.
>
> Note that all the decisions taken will be validated in 2 months, during the
> FOSDEM meeting. See the appendix of this email.
>
> 1) The first main decision was to define who would be allowed to vote on the
> future votes.
> Aka "Who are the electors?"
>
> Several options were presented, including: random(), old committee, active
> developers (as defined as more than 20 non-trivial commits in the last 36
> months) and a few fixed people helping - like roots, jb + lydia.
>
> The votes were almost unanimous for the "active developers", as defined
> currently as:
> - developers who have more than 20 non-trivial (changing the output of the
> compiler) committed patches in the last 36 months and a handful of fixed
> non-developer people (like roots)
> One vote was for the old committee, for information.
>
> Note that some people who voted for this method are de facto excluded from
> voting because of this very method :)
>
> Those people are collectively defined as the Developer General Assembly, aka
> GA, the electors.
> The GA will vote in referendums that are impacting the whole project
> ("Should the license be LGPLv4?", "Should the codebase be moved to Go?",
> "Should the bike shed be blue?") and will vote for their representatives in
> the committees.
>
> 2) What voting mechanism should we use?
>
> This discussion was complex, and mentioned FPTP, ranked-voting, approval
> voting, 2-turns, random.
> Rodger seemed to master the subject more than we did and a few other people
> shared opinions and
>
> We voted on the method of voting and decided, in a very very large majority
> to use a ranked-voting system, similar to what other free software projects
> are using.
> If people care strongly about which type of ranked-voting we should use,
> please contact Rodger and find a consensus, so we can use that in the
> future.
>
> 3) Technical Resolution Committee
>
> We then elected, with the new method, the members for the Technical
> Resolution Committee, made of 5 people. (TC)
>
> This committee is here to arbitrate conflicts on technical matters ("Should
> we use 2 parameters to this function?" "Should this be a filter or a
> demuxer?", "Should this structure be split?") when discussion happens on
> the mailing list and there is no simple answer, and the whole thread start
> to derive into nastiness.
>
> This committee is not here to decide on directions or vision, or decide on
> generic topics, since this is the mandate of the GA.
> However, the decisions from this committees are binding, therefore, you must
> apply the committee decision.
> Reopening discussions later are always possible, at a GA meeting.
>
> The conflict resolution process will be discussed later, and a proper
> document will be defined, but I fear this is outside of the scope of the
> current mail.
>
> The vote was very long to count, because of ranked choice done manually
> (thanks Rodger!), but with little surprise, the people elected were:
> - Michael
> - James Almer
> - Ronald
> - Martin
> - Anton
>
> In the future, we will have an extra step of asking the people elected to
> agree to their charges.
> This being a bootstrap, with a very limited amount of time available, and
> with newer elections in less than 3 months, we skipped that part, for this
> first vote.
>
> 4) Community Conflict committee
>
> We finally elected, with the new method, the members of the Community
> Committee, made of 5 people. (CC)
>
> This committee is here to arbitrate personal
[FFmpeg-devel] [IMP] Decisions...
Hello fellow developers,
Last week, a large number of us met during VDD
(https://www.videolan.org/videolan/events/vdd19/), as I had announced
previously on this very mailing list.
The meeting was long but productive, as we talked about the organization of our
community.
Quite a few people were present, physically, a bit more than a dozen joined on
the IRC channel, and 8 or 9 participated in the hangouts session. And we took a
few decisions, that I will detail here.
This mail is a bit long, but please read everything before reacting.
But first, the people present were:
- Thilo
- Kyle
- Ronald
- Vittorio
- Josh
- Rodger (nonvoting)
- Kieran
- James Darnley
- Sergio (nonvoting)
- Steven Liu
- Jan Ekström
- Nikki (nonvoting)
- Thierry Foucu
- Carl Eugen
- Lynne
- Janne
- Martin
- Diego (nonvoting)
- Anton (nonvoting)
- Luca (nonvoting)
- Jessica (nonvoting)
- Michael Bradshaw
- Lydia (nonvoting)
- jb (nonvoting)
On the hangouts and IRC, 3 people voted remotely, through jb, as a prox:
- Michael
- Jamrial
- Kurosu
--
We voted about a few things to organize the community.
First, we decided that we needed to act, and bootstrap some actions that will
lead to more structured organization in the future.
Of course, nothing is immutable, but we needed to start somewhere.
Note that all the decisions taken will be validated in 2 months, during the
FOSDEM meeting. See the appendix of this email.
1) The first main decision was to define who would be allowed to vote on the
future votes.
Aka "Who are the electors?"
Several options were presented, including: random(), old committee, active
developers (as defined as more than 20 non-trivial commits in the last 36
months) and a few fixed people helping - like roots, jb + lydia.
The votes were almost unanimous for the "active developers", as defined
currently as:
- developers who have more than 20 non-trivial (changing the output of the
compiler) committed patches in the last 36 months and a handful of fixed
non-developer people (like roots)
One vote was for the old committee, for information.
Note that some people who voted for this method are de facto excluded from
voting because of this very method :)
Those people are collectively defined as the Developer General Assembly, aka
GA, the electors.
The GA will vote in referendums that are impacting the whole project ("Should
the license be LGPLv4?", "Should the codebase be moved to Go?", "Should the
bike shed be blue?") and will vote for their representatives in the committees.
2) What voting mechanism should we use?
This discussion was complex, and mentioned FPTP, ranked-voting, approval
voting, 2-turns, random.
Rodger seemed to master the subject more than we did and a few other people
shared opinions and
We voted on the method of voting and decided, in a very very large majority to
use a ranked-voting system, similar to what other free software projects are
using.
If people care strongly about which type of ranked-voting we should use, please
contact Rodger and find a consensus, so we can use that in the future.
3) Technical Resolution Committee
We then elected, with the new method, the members for the Technical Resolution
Committee, made of 5 people. (TC)
This committee is here to arbitrate conflicts on technical matters ("Should we
use 2 parameters to this function?" "Should this be a filter or a demuxer?",
"Should this structure be split?") when discussion happens on the mailing list
and there is no simple answer, and the whole thread start to derive into
nastiness.
This committee is not here to decide on directions or vision, or decide on
generic topics, since this is the mandate of the GA.
However, the decisions from this committees are binding, therefore, you must
apply the committee decision.
Reopening discussions later are always possible, at a GA meeting.
The conflict resolution process will be discussed later, and a proper document
will be defined, but I fear this is outside of the scope of the current mail.
The vote was very long to count, because of ranked choice done manually (thanks
Rodger!), but with little surprise, the people elected were:
- Michael
- James Almer
- Ronald
- Martin
- Anton
In the future, we will have an extra step of asking the people elected to agree
to their charges.
This being a bootstrap, with a very limited amount of time available, and with
newer elections in less than 3 months, we skipped that part, for this first
vote.
4) Community Conflict committee
We finally elected, with the new method, the members of the Community
Committee, made of 5 people. (CC)
This committee is here to arbitrate personal conflicts between members of the
community, and take actions (read: "kick butts") if people do not behave
nicely. You do not have to like everyone, but you can act like grown-ups.
Again, CC resolutions are binding, but GA has full control and override of the
CC.
The process and rules about the community will be debated
Re: [FFmpeg-devel] [PATCH] fate/filter-video: add test for dnn_processing with model halve_first_channel
> -Original Message- > From: Guo, Yejun > Sent: Wednesday, November 13, 2019 1:41 PM > To: ffmpeg-devel@ffmpeg.org > Cc: Guo, Yejun > Subject: [PATCH] fate/filter-video: add test for dnn_processing with model > halve_first_channel > > Signed-off-by: Guo, Yejun > --- > tests/fate/filter-video.mak| 3 ++ > .../fate/filter-dnn_processing-halve_first_channel | 55 > ++ > 2 files changed, 58 insertions(+) > create mode 100644 tests/ref/fate/filter-dnn_processing-halve_first_channel > please ignore this patch, I might do a change to the filter, 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] avfilter/Makefile: add missing dependency for chromashift
Please revert it, it is incorrect patch, On 11/19/19, Gyan wrote: > > > On 19-11-2019 12:55 pm, Carl Eugen Hoyos wrote: >> Am Di., 19. Nov. 2019 um 08:14 Uhr schrieb Gyan : >> >> [...] >> >> lgtm > > Thanks. Pushed as ef479ee660e4dfbf2645fe3a50d8639fdc22ab1b > > Gyan > ___ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > https://ffmpeg.org/mailman/listinfo/ffmpeg-devel > > To unsubscribe, visit link above, or email > ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe". ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH v1] avcodec/vaapi: set more flags for VASurfaceAttrib
On Tue, Nov 19, 2019 at 4:24 PM Wangfei wrote:
>
> flags and value.type is needed when pass VASurfaceAttrib to driver.
> Otherwise the attribute will be considered invalid in driver.
>
> Signed-off-by: Wangfei
> ---
> libavcodec/vaapi_decode.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/libavcodec/vaapi_decode.c b/libavcodec/vaapi_decode.c
> index 69512e1d45..a93aba5a5d 100644
> --- a/libavcodec/vaapi_decode.c
> +++ b/libavcodec/vaapi_decode.c
> @@ -350,6 +350,8 @@ static int vaapi_decode_find_best_format(AVCodecContext
> *avctx,
>
> ctx->pixel_format_attribute = (VASurfaceAttrib) {
> .type = VASurfaceAttribPixelFormat,
> +.flags = VA_SURFACE_ATTRIB_SETTABLE,
> +.value.type= VAGenericValueTypeInteger,
I can't found any description in libva about this part, do you have
any other docs?
> .value.value.i = best_fourcc,
> };
>
> --
> 2.17.1
>
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] avfilter/Makefile: add missing dependency for lut3d
On 19-11-2019 12:54 pm, Carl Eugen Hoyos wrote: Am Di., 19. Nov. 2019 um 08:14 Uhr schrieb Gyan : [...] lgtm Thanks. Pushed as 0cfda90b34844ee7e050978db09b529e0a0c Gyan ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] avfilter/Makefile: add missing dependency for chromashift
On 19-11-2019 12:55 pm, Carl Eugen Hoyos wrote: Am Di., 19. Nov. 2019 um 08:14 Uhr schrieb Gyan : [...] lgtm Thanks. Pushed as ef479ee660e4dfbf2645fe3a50d8639fdc22ab1b Gyan ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH v1] avcodec/vaapi: set more flags for VASurfaceAttrib
flags and value.type is needed when pass VASurfaceAttrib to driver.
Otherwise the attribute will be considered invalid in driver.
Signed-off-by: Wangfei
---
libavcodec/vaapi_decode.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/libavcodec/vaapi_decode.c b/libavcodec/vaapi_decode.c
index 69512e1d45..a93aba5a5d 100644
--- a/libavcodec/vaapi_decode.c
+++ b/libavcodec/vaapi_decode.c
@@ -350,6 +350,8 @@ static int vaapi_decode_find_best_format(AVCodecContext
*avctx,
ctx->pixel_format_attribute = (VASurfaceAttrib) {
.type = VASurfaceAttribPixelFormat,
+.flags = VA_SURFACE_ATTRIB_SETTABLE,
+.value.type= VAGenericValueTypeInteger,
.value.value.i = best_fourcc,
};
--
2.17.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
