[FFmpeg-devel] [PATCH V1] avfilter: Add tonemap vaapi filter
It supports ICL platform.
H2H (HDR to HDR): P010 -> RGB10
H2S (HDR to SDR): P010 -> RGB8
libva commit for HDR10
https://github.com/intel/libva/commit/cf11abe5e1b9c93ee75cf974076957162c1605b9
Signed-off-by: Zachary Zhou
---
configure | 2 +
libavfilter/Makefile | 1 +
libavfilter/allfilters.c | 1 +
libavfilter/vaapi_vpp.c| 29 ++
libavfilter/vaapi_vpp.h| 8 +
libavfilter/vf_tonemap_vaapi.c | 539 +
libavutil/hwcontext_vaapi.c| 1 +
7 files changed, 581 insertions(+)
create mode 100644 libavfilter/vf_tonemap_vaapi.c
diff --git a/configure b/configure
index be49c19b88..04375015c2 100755
--- a/configure
+++ b/configure
@@ -3480,6 +3480,7 @@ tinterlace_merge_test_deps="tinterlace_filter"
tinterlace_pad_test_deps="tinterlace_filter"
tonemap_filter_deps="const_nan"
tonemap_opencl_filter_deps="opencl const_nan"
+tonemap_vaapi_filter_deps="vaapi
VAProcPipelineParameterBuffer_output_hdr_metadata"
transpose_opencl_filter_deps="opencl"
unsharp_opencl_filter_deps="opencl"
uspp_filter_deps="gpl avcodec"
@@ -5984,6 +5985,7 @@ check_type "d3d9.h dxva2api.h" DXVA2_ConfigPictureDecode
-D_WIN32_WINNT=0x0602
check_type "va/va.h va/va_dec_hevc.h" "VAPictureParameterBufferHEVC"
check_struct "va/va.h" "VADecPictureParameterBufferVP9" bit_depth
+check_struct "va/va.h va/va_vpp.h" "VAProcPipelineParameterBuffer"
output_hdr_metadata
check_type "va/va.h va/va_enc_hevc.h" "VAEncPictureParameterBufferHEVC"
check_type "va/va.h va/va_enc_jpeg.h" "VAEncPictureParameterBufferJPEG"
check_type "va/va.h va/va_enc_vp8.h" "VAEncPictureParameterBufferVP8"
diff --git a/libavfilter/Makefile b/libavfilter/Makefile
index 6e2658186d..f6894209d1 100644
--- a/libavfilter/Makefile
+++ b/libavfilter/Makefile
@@ -390,6 +390,7 @@ OBJS-$(CONFIG_TMIX_FILTER) += vf_mix.o
framesync.o
OBJS-$(CONFIG_TONEMAP_FILTER)+= vf_tonemap.o colorspace.o
OBJS-$(CONFIG_TONEMAP_OPENCL_FILTER) += vf_tonemap_opencl.o
colorspace.o opencl.o \
opencl/tonemap.o
opencl/colorspace_common.o
+OBJS-$(CONFIG_TONEMAP_VAAPI_FILTER) += vf_tonemap_vaapi.o vaapi_vpp.o
OBJS-$(CONFIG_TPAD_FILTER) += vf_tpad.o
OBJS-$(CONFIG_TRANSPOSE_FILTER) += vf_transpose.o
OBJS-$(CONFIG_TRANSPOSE_NPP_FILTER) += vf_transpose_npp.o cuda_check.o
diff --git a/libavfilter/allfilters.c b/libavfilter/allfilters.c
index a600069500..754b84819d 100644
--- a/libavfilter/allfilters.c
+++ b/libavfilter/allfilters.c
@@ -369,6 +369,7 @@ extern AVFilter ff_vf_tlut2;
extern AVFilter ff_vf_tmix;
extern AVFilter ff_vf_tonemap;
extern AVFilter ff_vf_tonemap_opencl;
+extern AVFilter ff_vf_tonemap_vaapi;
extern AVFilter ff_vf_tpad;
extern AVFilter ff_vf_transpose;
extern AVFilter ff_vf_transpose_npp;
diff --git a/libavfilter/vaapi_vpp.c b/libavfilter/vaapi_vpp.c
index c5bbc3b85b..7389ebd9d5 100644
--- a/libavfilter/vaapi_vpp.c
+++ b/libavfilter/vaapi_vpp.c
@@ -276,6 +276,35 @@ int ff_vaapi_vpp_make_param_buffers(AVFilterContext *avctx,
return 0;
}
+int ff_vaapi_vpp_make_param_buffers2(AVFilterContext *avctx,
+ int type,
+ const void *data,
+ size_t size,
+ int count,
+ VABufferID *buffer_id)
+{
+VAStatus vas;
+VABufferID buffer;
+VAAPIVPPContext *ctx = avctx->priv;
+
+av_assert0(ctx->nb_filter_buffers + 1 <= VAProcFilterCount);
+
+vas = vaCreateBuffer(ctx->hwctx->display, ctx->va_context,
+ type, size, count, (void*)data, );
+if (vas != VA_STATUS_SUCCESS) {
+av_log(avctx, AV_LOG_ERROR, "Failed to create parameter "
+ "buffer (type %d): %d (%s).\n",
+ type, vas, vaErrorStr(vas));
+return AVERROR(EIO);
+}
+
+ctx->filter_buffers[ctx->nb_filter_buffers++] = buffer;
+*buffer_id = buffer;
+
+av_log(avctx, AV_LOG_DEBUG, "Param buffer (type %d, %zu bytes, count %d) "
+ "is %#x.\n", type, size, count, buffer);
+return 0;
+}
int ff_vaapi_vpp_render_picture(AVFilterContext *avctx,
VAProcPipelineParameterBuffer *params,
diff --git a/libavfilter/vaapi_vpp.h b/libavfilter/vaapi_vpp.h
index 0bc31018d4..e920c10591 100644
--- a/libavfilter/vaapi_vpp.h
+++ b/libavfilter/vaapi_vpp.h
@@ -72,6 +72,14 @@ int ff_vaapi_vpp_make_param_buffers(AVFilterContext *avctx,
size_t size,
int count);
+int ff_vaapi_vpp_make_param_buffers2(AVFilterContext *avctx,
+ int type,
+ const void *data,
+ size_t size,
+ int count,
+
[FFmpeg-devel] [PATCH V7] libavfilter: add transpose_vaapi filter
Swap width and height when do clock/cclock rotation
Add reversal/reversal_flip options
ffmpeg -hwaccel vaapi -vaapi_device /dev/dri/renderD128
-hwaccel_output_format vaapi -i input.264 -vf "transpose_vaapi=clock_flip"
-c:v h264_vaapi output.h264
Signed-off-by: Zachary Zhou
---
configure| 2 +
libavfilter/Makefile | 1 +
libavfilter/allfilters.c | 1 +
libavfilter/transpose.h | 2 +
libavfilter/vf_transpose_vaapi.c | 338 +++
5 files changed, 344 insertions(+)
create mode 100644 libavfilter/vf_transpose_vaapi.c
diff --git a/configure b/configure
index be49c19b88..04ee671a60 100755
--- a/configure
+++ b/configure
@@ -3481,6 +3481,7 @@ tinterlace_pad_test_deps="tinterlace_filter"
tonemap_filter_deps="const_nan"
tonemap_opencl_filter_deps="opencl const_nan"
transpose_opencl_filter_deps="opencl"
+transpose_vaapi_filter_deps="vaapi VAProcPipelineCaps_rotation_flags"
unsharp_opencl_filter_deps="opencl"
uspp_filter_deps="gpl avcodec"
vaguedenoiser_filter_deps="gpl"
@@ -5984,6 +5985,7 @@ check_type "d3d9.h dxva2api.h" DXVA2_ConfigPictureDecode
-D_WIN32_WINNT=0x0602
check_type "va/va.h va/va_dec_hevc.h" "VAPictureParameterBufferHEVC"
check_struct "va/va.h" "VADecPictureParameterBufferVP9" bit_depth
+check_struct "va/va.h va/va_vpp.h" "VAProcPipelineCaps" rotation_flags
check_type "va/va.h va/va_enc_hevc.h" "VAEncPictureParameterBufferHEVC"
check_type "va/va.h va/va_enc_jpeg.h" "VAEncPictureParameterBufferJPEG"
check_type "va/va.h va/va_enc_vp8.h" "VAEncPictureParameterBufferVP8"
diff --git a/libavfilter/Makefile b/libavfilter/Makefile
index 6e2658186d..4246d3480f 100644
--- a/libavfilter/Makefile
+++ b/libavfilter/Makefile
@@ -394,6 +394,7 @@ OBJS-$(CONFIG_TPAD_FILTER) += vf_tpad.o
OBJS-$(CONFIG_TRANSPOSE_FILTER) += vf_transpose.o
OBJS-$(CONFIG_TRANSPOSE_NPP_FILTER) += vf_transpose_npp.o cuda_check.o
OBJS-$(CONFIG_TRANSPOSE_OPENCL_FILTER) += vf_transpose_opencl.o opencl.o
opencl/transpose.o
+OBJS-$(CONFIG_TRANSPOSE_VAAPI_FILTER)+= vf_transpose_vaapi.o
vaapi_vpp.o
OBJS-$(CONFIG_TRIM_FILTER) += trim.o
OBJS-$(CONFIG_UNPREMULTIPLY_FILTER) += vf_premultiply.o framesync.o
OBJS-$(CONFIG_UNSHARP_FILTER)+= vf_unsharp.o
diff --git a/libavfilter/allfilters.c b/libavfilter/allfilters.c
index a600069500..0b82ff7ced 100644
--- a/libavfilter/allfilters.c
+++ b/libavfilter/allfilters.c
@@ -373,6 +373,7 @@ extern AVFilter ff_vf_tpad;
extern AVFilter ff_vf_transpose;
extern AVFilter ff_vf_transpose_npp;
extern AVFilter ff_vf_transpose_opencl;
+extern AVFilter ff_vf_transpose_vaapi;
extern AVFilter ff_vf_trim;
extern AVFilter ff_vf_unpremultiply;
extern AVFilter ff_vf_unsharp;
diff --git a/libavfilter/transpose.h b/libavfilter/transpose.h
index d4bb4da1ae..87936d0512 100644
--- a/libavfilter/transpose.h
+++ b/libavfilter/transpose.h
@@ -29,6 +29,8 @@ enum TransposeDir {
TRANSPOSE_CLOCK,
TRANSPOSE_CCLOCK,
TRANSPOSE_CLOCK_FLIP,
+TRANSPOSE_REVERSAL,
+TRANSPOSE_REVERSAL_FLIP,
};
#endif
diff --git a/libavfilter/vf_transpose_vaapi.c b/libavfilter/vf_transpose_vaapi.c
new file mode 100644
index 00..1c7bb0c1a7
--- /dev/null
+++ b/libavfilter/vf_transpose_vaapi.c
@@ -0,0 +1,338 @@
+/*
+ * 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 "libavutil/avassert.h"
+#include "libavutil/mem.h"
+#include "libavutil/opt.h"
+#include "libavutil/pixdesc.h"
+
+#include "avfilter.h"
+#include "formats.h"
+#include "internal.h"
+#include "vaapi_vpp.h"
+#include "transpose.h"
+
+typedef struct TransposeVAAPIContext {
+VAAPIVPPContext vpp_ctx; // must be the first field
+int passthrough; // PassthroughType, landscape passthrough mode
enabled
+int dir; // TransposeDir
+
+int rotation_state;
+int mirror_state;
+} TransposeVAAPIContext;
+
+static int transpose_vaapi_build_filter_params(AVFilterContext *avctx)
+{
+VAAPIVPPContext *vpp_ctx = avctx->priv;
+TransposeVAAPIContext *ctx = avctx->priv;
+VAStatus vas;
+int support_flag;
+VAProcPipelineCaps pipeline_caps;
+
+memset(_caps, 0, sizeof(pipeline_caps));
+
[FFmpeg-devel] [PATCH V1] avfilter: Add constant VAAPI_VPP_BACKGROUND_BLACK
Signed-off-by: Zachary Zhou
---
libavfilter/vaapi_vpp.h| 2 ++
libavfilter/vf_deinterlace_vaapi.c | 2 +-
libavfilter/vf_misc_vaapi.c| 2 +-
libavfilter/vf_procamp_vaapi.c | 2 +-
libavfilter/vf_scale_vaapi.c | 2 +-
5 files changed, 6 insertions(+), 4 deletions(-)
diff --git a/libavfilter/vaapi_vpp.h b/libavfilter/vaapi_vpp.h
index 0bc31018d4..bdf3bbaccc 100644
--- a/libavfilter/vaapi_vpp.h
+++ b/libavfilter/vaapi_vpp.h
@@ -27,6 +27,8 @@
#include "avfilter.h"
+#define VAAPI_VPP_BACKGROUND_BLACK 0xff00 //Black in ARGB format
+
typedef struct VAAPIVPPContext {
const AVClass *class;
diff --git a/libavfilter/vf_deinterlace_vaapi.c
b/libavfilter/vf_deinterlace_vaapi.c
index f7a262d0c6..97aee6588f 100644
--- a/libavfilter/vf_deinterlace_vaapi.c
+++ b/libavfilter/vf_deinterlace_vaapi.c
@@ -256,7 +256,7 @@ static int deint_vaapi_filter_frame(AVFilterLink *inlink,
AVFrame *input_frame)
ff_vaapi_vpp_colour_standard(input_frame->colorspace);
params.output_region = NULL;
-params.output_background_color = 0xff00;
+params.output_background_color = VAAPI_VPP_BACKGROUND_BLACK;
params.output_color_standard = params.surface_color_standard;
params.pipeline_flags = 0;
diff --git a/libavfilter/vf_misc_vaapi.c b/libavfilter/vf_misc_vaapi.c
index 30b808a993..e227c9ff6b 100644
--- a/libavfilter/vf_misc_vaapi.c
+++ b/libavfilter/vf_misc_vaapi.c
@@ -174,7 +174,7 @@ static int misc_vaapi_filter_frame(AVFilterLink *inlink,
AVFrame *input_frame)
ff_vaapi_vpp_colour_standard(input_frame->colorspace);
params.output_region = NULL;
-params.output_background_color = 0xff00;
+params.output_background_color = VAAPI_VPP_BACKGROUND_BLACK;
params.output_color_standard = params.surface_color_standard;
params.pipeline_flags = 0;
diff --git a/libavfilter/vf_procamp_vaapi.c b/libavfilter/vf_procamp_vaapi.c
index 10eccbe97d..46f3ab6465 100644
--- a/libavfilter/vf_procamp_vaapi.c
+++ b/libavfilter/vf_procamp_vaapi.c
@@ -171,7 +171,7 @@ static int procamp_vaapi_filter_frame(AVFilterLink *inlink,
AVFrame *input_frame
ff_vaapi_vpp_colour_standard(input_frame->colorspace);
params.output_region = NULL;
-params.output_background_color = 0xff00;
+params.output_background_color = VAAPI_VPP_BACKGROUND_BLACK;
params.output_color_standard = params.surface_color_standard;
params.pipeline_flags = 0;
diff --git a/libavfilter/vf_scale_vaapi.c b/libavfilter/vf_scale_vaapi.c
index b06ae764bf..3699363140 100644
--- a/libavfilter/vf_scale_vaapi.c
+++ b/libavfilter/vf_scale_vaapi.c
@@ -133,7 +133,7 @@ static int scale_vaapi_filter_frame(AVFilterLink *inlink,
AVFrame *input_frame)
ff_vaapi_vpp_colour_standard(input_frame->colorspace);
params.output_region = 0;
-params.output_background_color = 0xff00;
+params.output_background_color = VAAPI_VPP_BACKGROUND_BLACK;
params.output_color_standard = params.surface_color_standard;
params.pipeline_flags = 0;
--
2.17.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH v2] avcodec/fft_template: libavcodec/fft_template: improve performance of the ff_fft_init in fft_template
> 在 2018年12月25日，上午1:28，Paul B Mahol 写道：
>
> On 12/24/18, Michael Niedermayer wrote:
>> On Fri, Dec 21, 2018 at 06:09:50PM +0800, Steven Liu wrote:
>>> Before patch:
>>> init nbits = 17, get 1 samples, average cost: 16105 us
>>> After patch:
>>> init nbits = 17, get 1 samples, average cost: 15221 us
>>>
>>> Signed-off-by: Steven Liu
>>> ---
>>> libavcodec/fft_template.c | 26 +++---
>>> 1 file changed, 15 insertions(+), 11 deletions(-)
>>>
>>> diff --git a/libavcodec/fft_template.c b/libavcodec/fft_template.c
>>> index 762c014bc8..2b528be882 100644
>>> --- a/libavcodec/fft_template.c
>>> +++ b/libavcodec/fft_template.c
>>> @@ -261,17 +261,21 @@ av_cold int ff_fft_init(FFTContext *s, int nbits,
>>> int inverse)
>>> if (s->fft_permutation == FF_FFT_PERM_AVX) {
>>> fft_perm_avx(s);
>>> } else {
>>> -for(i=0; i>> -int k;
>>> -j = i;
>>> -if (s->fft_permutation == FF_FFT_PERM_SWAP_LSBS)
>>> -j = (j&~3) | ((j>>1)&1) | ((j<<1)&2);
>>> -k = -split_radix_permutation(i, n, s->inverse) & (n-1);
>>> -if (s->revtab)
>>> -s->revtab[k] = j;
>>> -if (s->revtab32)
>>> -s->revtab32[k] = j;
>>> -}
>>> +#define SPLIT_RADIX_PERMUTATION(num) do { \
>>> +for(i=0; i>> +int k;\
>>> +j = i;\
>>
>>> +if (s->fft_permutation == FF_FFT_PERM_SWAP_LSBS)\
>>
>> maybe this if() should be factored out too ?
>>
>> the change looks good though, and iam not sure this is speed relevant
>> enough
>
> Well, it helps. But this code is partially going to be rewritten
> anyway in future.
Hi Paul,
So what i should do? Go on update this patch with Michael’s comment or
waiting for your rewritten?
Thanks
Steven
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] Add a new channel layout API
On Mon, Dec 24, 2018 at 06:34:30PM +0100, Paul B Mahol wrote:
[...]
> -static const char *get_channel_name(int channel_id)
> +const char *av_channel_name(enum AVChannel channel_id)
> {
> if (channel_id < 0 || channel_id >= FF_ARRAY_ELEMS(channel_names))
> return NULL;
> +if ((unsigned) channel_id >= FF_ARRAY_ELEMS(channel_names))
> +return "?";
this looks like a untended duplicate check
[...]
> +/**
> + * Check whether two channel layouts are semantically the same, i.e. the same
> + * channels are present on the same positions in both.
> + *
> + * If one of the channel layouts is AV_CHANNEL_ORDER_UNSPEC, while the other
> is
> + * not, they are considered to be unequal. If both are
> AV_CHANNEL_ORDER_UNSPEC,
> + * they are considered equal iff the channel counts are the same in both.
> + *
> + * @param chl input channel layout
> + * @param chl1 input channel layout
> + * @return 0 if chl and chl1 are equal, 1 if they are not equal. A negative
> + * AVERROR code if one or both are invalid.
> + */
> +int av_channel_layout_compare(const AVChannelLayout *chl, const
> AVChannelLayout *chl1);
It could be usefull if this is a full compare function that allows
sorting/ordering
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
The worst form of inequality is to try to make unequal things equal.
-- Aristotle
signature.asc
Description: PGP signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH, v3] lavc/hevc_parser: cope with more leading_zero_8bits and update FATE
> -Original Message-
> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf
> Of Fu, Linjie
> Sent: Tuesday, December 18, 2018 08:52
> To: FFmpeg development discussions and patches de...@ffmpeg.org>
> Subject: Re: [FFmpeg-devel] [PATCH, v3] lavc/hevc_parser: cope with more
> leading_zero_8bits and update FATE
>
> > -Original Message-
> > From: Fu, Linjie
> > Sent: Monday, December 10, 2018 18:24
> > To: ffmpeg-devel@ffmpeg.org
> > Cc: Fu, Linjie
> > Subject: [PATCH,v3] lavc/hevc_parser: cope with more leading_zero_8bits
> > and update FATE
> >
> > Given that leading_zero_8bits can be included many times at the beginning
> > of a NAL unit, blindly taking the startcode as 3 bytes will leave 0x00
> > in last frame and may lead to some warnings in parse_nal_units when s-
> > >flags
> > is set to PARSER_FLAG_COMPLETE_FRAMES.
> >
> > Modify to put all of the zeroes between two frames into the second frame.
> > Modify the code to print the buf_size like in H264 and reduce the
> duplication.
> >
> > Update the FATE checksum for fate-hevc-bsf-mp4toannexb:
> > The ref output has redundant 0x00 at the end of the SUFFIX_SEI:
> > { 50 01 84 31 00 19 39 77 d0 7b 3f bd 1e 09 38 9a 79 41
> > c0 16 11 da 18 aa 0a db 2b 19 fa 47 3f 0f 67 4a 91 9c a1
> > 12 72 67 d6 f0 8f 66 ee 95 f9 e2 b9 ba 23 9a e8 80 00 }
> >
> > To verify the output of FATE:
> > ffmpeg -i hevc-conformance/WPP_A_ericsson_MAIN10_2.bit -c copy -flags
> \
> > +bitexact hevc-mp4.mov
> > ffmpeg -i hevc-mp4.mov -c:v copy -fflags +bitexact -f hevc hevc.out
> >
> > Signed-off-by: Linjie Fu
> > ---
> > [v2]: Update FATE checksum.
> > [v3]: Cope with more leading_zero_8bits cases.
> >
> > libavcodec/hevc_parser.c | 14 +-
> > tests/fate/hevc.mak | 2 +-
> > 2 files changed, 10 insertions(+), 6 deletions(-)
> >
> > diff --git a/libavcodec/hevc_parser.c b/libavcodec/hevc_parser.c
> > index 369d1338d0..62100ac654 100644
> > --- a/libavcodec/hevc_parser.c
> > +++ b/libavcodec/hevc_parser.c
> > @@ -239,7 +239,7 @@ static int parse_nal_units(AVCodecParserContext *s,
> > const uint8_t *buf,
> > }
> > }
> > /* didn't find a picture! */
> > -av_log(avctx, AV_LOG_ERROR, "missing picture in access unit\n");
> > +av_log(avctx, AV_LOG_ERROR, "missing picture in access unit with
> > size %d\n", buf_size);
> > return -1;
> > }
> >
> > @@ -267,8 +267,7 @@ static int
> > hevc_find_frame_end(AVCodecParserContext *s, const uint8_t *buf,
> > if ((nut >= HEVC_NAL_VPS && nut <= HEVC_NAL_EOB_NUT) || nut ==
> > HEVC_NAL_SEI_PREFIX ||
> > (nut >= 41 && nut <= 44) || (nut >= 48 && nut <= 55)) {
> > if (pc->frame_start_found) {
> > -pc->frame_start_found = 0;
> > -return i - 5;
> > +goto found;
> > }
> > } else if (nut <= HEVC_NAL_RASL_R ||
> > (nut >= HEVC_NAL_BLA_W_LP && nut <= HEVC_NAL_CRA_NUT))
> {
> > @@ -277,14 +276,19 @@ static int
> > hevc_find_frame_end(AVCodecParserContext *s, const uint8_t *buf,
> > if (!pc->frame_start_found) {
> > pc->frame_start_found = 1;
> > } else { // First slice of next frame found
> > -pc->frame_start_found = 0;
> > -return i - 5;
> > +goto found;
> > }
> > }
> > }
> > }
> >
> > return END_NOT_FOUND;
> > +
> > +found:
> > +pc->frame_start_found = 0;
> > +while (i - 6 >= 0 && !buf[i - 6])
> > +i--;
> > +return i - 5;
> > }
> >
> > static int hevc_parse(AVCodecParserContext *s, AVCodecContext *avctx,
> > diff --git a/tests/fate/hevc.mak b/tests/fate/hevc.mak
> > index db3ea19340..ab8da53535 100644
> > --- a/tests/fate/hevc.mak
> > +++ b/tests/fate/hevc.mak
> > @@ -238,7 +238,7 @@ FATE_HEVC-$(call ALLYES, HEVC_DEMUXER
> > MOV_DEMUXER HEVC_MP4TOANNEXB_BSF MOV_MUXER
> > fate-hevc-bsf-mp4toannexb: tests/data/hevc-mp4.mov
> > fate-hevc-bsf-mp4toannexb: CMD = md5 -i
> > $(TARGET_PATH)/tests/data/hevc-mp4.mov -c:v copy -fflags +bitexact -f
> > hevc
> > fate-hevc-bsf-mp4toannexb: CMP = oneline
> > -fate-hevc-bsf-mp4toannexb: REF = 1873662a3af1848c37e4eb25722c8df9
> > +fate-hevc-bsf-mp4toannexb: REF = 73019329ed7f81c24f9af67c34c640c0
> >
> > fate-hevc-skiploopfilter: CMD = framemd5 -skip_loop_filter nokey -i
> > $(TARGET_SAMPLES)/hevc-conformance/SAO_D_Samsung_5.bit -
> sws_flags
> > bitexact
> > FATE_HEVC += fate-hevc-skiploopfilter
> > --
> > 2.17.1
> Ping?
Another ping.
Any comments on this change in hevc_parser and fate?
---
Thanks,
Linjie
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 2/3] avcodec/lagarith: Optimize case with singleton probability distribution
> > commit 0ca7a8deeffd33e05ae15a447259b32b6678c727 (HEAD -> master) > Author: Michael Niedermayer > Date: Mon Dec 24 01:14:50 2018 +0100 > > avcodec/lagarith: Optimize case with singleton probability distribution > > Fixes: Timeout > Fixes: > 10554/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_LAGARITH_fuzzer-5739938067251200 > > In case of a Denial of Service attack, the attacker wants to maximize > the load on the target > per byte transmitted from the attacker. > For such a DoS attack it is best for the attacker to setup the > probabilities so that the > arithmetic decoder does not advance in the bytestream that way the > attacker only needs to > transmit the initial bytes and header for an arbitrary large frame. > This patch here optimizes this codepath and avoids executing the > arithmetic decoder more than > once. It thus reduces the load causes by this codepath on the target. > We also could completely disallow this codepath but it appears such > odd probability > distributions are not invalid. > > Found-by: continuous fuzzing process > https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg > Signed-off-by: Michael Niedermayer > This is a nonsense argument, a user could send a frame that was x in dimensions, would have the same effect. The calling application should manage timeouts themselves in a sandbox or container or similar. Merry Xmas. Kieran ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 3/3] avcodec/utils: Optimize ff_color_frame()
On Mon, Dec 24, 2018 at 04:41:02PM +, Derek Buitenhuis wrote: > On 24/12/2018 00:14, Michael Niedermayer wrote: > > Fixes: Timeout > > Fixes: > > 10709/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_H264_fuzzer-5630617975259136 > > > > Found-by: continuous fuzzing > > processhttps://github.com/google/oss-fuzz/tree/master/projects/ffmpeg > > Signed-off-by: Michael Niedermayer > > --- > > libavcodec/utils.c | 9 +++-- > > 1 file changed, 7 insertions(+), 2 deletions(-) > > Comments and stats please... I can change the commit message as below? or add the timing data from fate from the other mail was that what you had in mind ? avcodec/utils: Optimize ff_color_frame() Fixes: Timeout Fixes: 10709/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_H264_fuzzer-5630617975259136 Before change: Executed clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_H264_fuzzer-5630617975259136 in 28285 ms After change: Executed clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_H264_fuzzer-5630617975259136 in 11830 ms Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg Signed-off-by: Michael Niedermayer [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Those who are best at talking, realize last or never when they are wrong. signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 3/3] avcodec/utils: Optimize ff_color_frame()
On Mon, Dec 24, 2018 at 05:44:26PM +0100, Paul B Mahol wrote: > On 12/24/18, Michael Niedermayer wrote: > > Fixes: Timeout > > Fixes: > > 10709/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_H264_fuzzer-5630617975259136 > > > > Found-by: continuous fuzzing process > > https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg > > Signed-off-by: Michael Niedermayer > > --- > > libavcodec/utils.c | 9 +++-- > > 1 file changed, 7 insertions(+), 2 deletions(-) > > Ugly, set first row and use memcpy for rest of rows. That would increase the load on the data cache memcpy has to read the line each time and write it each time otherwise the code just writes the line. This should become especially noticable if something else accesses the data cache like a 2nd core/thread with just a single thread mempcpy is faster than this simple method a slightly more complex implementation beats memcpy even single thread though (at least in my quick test here) of course if people prefer memcpy() (because its simpler) i can do that what is preferred ? code as in the patch ? memcpy ? even more messy but slightly beating memcpy ? (i have to actually clean this up and retest as it does a aliasing violation if people want this one) and of course there are more options like with asm to implement that memcpy: 5585847 decicycles in A, 4 runs, 0 skips ugly: 5696222 decicycles in A, 4 runs, 0 skips ugly and messy: 5527612 decicycles in A, 4 runs, 0 skips original: 14953532 decicycles in A, 4 runs, 0 skips tested with: fate-suite//h264/SonyXAVC_LongGOP_green_pixelation_early_Frames.MXF thanks [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Does the universe only have a finite lifespan? No, its going to go on forever, its just that you wont like living in it. -- Hiranya Peiri signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 2/3] avcodec/lagarith: Optimize case with singleton probability distribution
On Mon, Dec 24, 2018 at 04:40:11PM +, Derek Buitenhuis wrote: > On 24/12/2018 00:14, Michael Niedermayer wrote: > > Fixes: Timeout > > Fixes: > > 10554/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_LAGARITH_fuzzer-5739938067251200 > > > > Found-by: continuous fuzzing > > processhttps://github.com/google/oss-fuzz/tree/master/projects/ffmpeg > > Signed-off-by: Michael Niedermayer > > --- > > libavcodec/lagarith.c| 36 > > libavcodec/lagarithrac.h | 1 + > > 2 files changed, 37 insertions(+) > > This adds a load of completely uncommented and confusing code; it murders > readability for... what? Making a 'timeout' in a specific fuzzer go away? > > Is there a real benefit or reason to pollute the code with this? Measurable > and > useful speedup? Yes, ive documented that more verbosly now below i tend to be a bit terse by default on these fixes so as not to explain too detailedly on how to abuse/exploit the code commit 0ca7a8deeffd33e05ae15a447259b32b6678c727 (HEAD -> master) Author: Michael Niedermayer Date: Mon Dec 24 01:14:50 2018 +0100 avcodec/lagarith: Optimize case with singleton probability distribution Fixes: Timeout Fixes: 10554/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_LAGARITH_fuzzer-5739938067251200 In case of a Denial of Service attack, the attacker wants to maximize the load on the target per byte transmitted from the attacker. For such a DoS attack it is best for the attacker to setup the probabilities so that the arithmetic decoder does not advance in the bytestream that way the attacker only needs to transmit the initial bytes and header for an arbitrary large frame. This patch here optimizes this codepath and avoids executing the arithmetic decoder more than once. It thus reduces the load causes by this codepath on the target. We also could completely disallow this codepath but it appears such odd probability distributions are not invalid. Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg Signed-off-by: Michael Niedermayer [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB No snowflake in an avalanche ever feels responsible. -- Voltaire signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avcodec/libvpxenc: add VP8/9 sharpness config option
On Fri, Dec 21, 2018 at 7:38 PM James Zern wrote: > > On Fri, Dec 21, 2018 at 1:36 PM Rene Claus > wrote: > > > > This commit adds configuration options to libvpxenc.c that can be used to > > tune the sharpness parameter for VP8 and VP9. > > > > Signed-off-by: Rene Claus > > --- > > doc/encoders.texi | 4 > > libavcodec/libvpxenc.c | 6 ++ > > 2 files changed, 10 insertions(+) > > > > lgtm. I'll submit this soon if there aren't any further comments. applied, thanks for the patch. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH v3] avcodec/mips: Fix failed case: hevc-conformance-AMP_A_Samsung_* when enable msa
On Mon, Dec 24, 2018 at 07:03:45PM +, Derek Buitenhuis wrote: > On 24/12/2018 06:07, gxw wrote: > > The AV_INPUT_BUFFER_PADDING_SIZE has been increased to 64, but the value is > > still 32 > > in function ff_hevc_sao_edge_filter_8_msa. So, use > > AV_INPUT_BUFFER_PADDING_SIZE directly. > > Also, use MAX_PB_SIZE directly instead of 64. Fate tests passed. > > --- > > libavcodec/mips/hevc_lpf_sao_msa.c | 2 +- > > 1 file changed, 1 insertion(+), 1 deletion(-) > > Probably OK. tested on qemu-mips will apply thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB He who knows, does not speak. He who speaks, does not know. -- Lao Tsu signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH v2] mov: Remove duration-of-last-frame heuristic hack
This breaks totally valid files that get caught in its heuristic. This, according to the commit message, is my own doing, having asked Michael to implement this check and providing a sample that was "wrong". I am now atoning for my sins, and removing this hack, having seen the light (aka that this was silly to do in the first place). Resotores correct behavior on valid files. This reverts commit 8e5e84c2a2a21a979b48e80c5a8dd44754ab3f21. Signed-off-by: Derek Buitenhuis --- v1 had accidentally removed a cast. Woops. libavformat/mov.c | 6 -- 1 file changed, 6 deletions(-) diff --git a/libavformat/mov.c b/libavformat/mov.c index 825738127b..970cd87f70 100644 --- a/libavformat/mov.c +++ b/libavformat/mov.c @@ -2923,12 +2923,6 @@ static int mov_read_stts(MOVContext *c, AVIOContext *pb, MOVAtom atom) av_log(c->fc, AV_LOG_TRACE, "sample_count=%d, sample_duration=%d\n", sample_count, sample_duration); -if ( i+1 == entries -&& i -&& sample_count == 1 -&& total_sample_count > 100 -&& sample_duration/10 > duration / total_sample_count) -sample_duration = duration / total_sample_count; duration+=(int64_t)sample_duration*(uint64_t)sample_count; total_sample_count+=sample_count; } -- 2.20.1 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] mov: Remove duration-of-last-frame heuristic hack
This breaks totally valid files that get caught in its heuristic. This, according to the commit message, is my own doing, having asked Michael to implement this check and providing a sample that was "wrong". I am now atoning for my sins, and removing this hack, having seen the light (aka that this was silly to do in the first place). Resotores correct behavior on valid files. This reverts commit 8e5e84c2a2a21a979b48e80c5a8dd44754ab3f21. Signed-off-by: Derek Buitenhuis --- libavformat/mov.c | 8 +--- 1 file changed, 1 insertion(+), 7 deletions(-) diff --git a/libavformat/mov.c b/libavformat/mov.c index 825738127b..0f1b6bf475 100644 --- a/libavformat/mov.c +++ b/libavformat/mov.c @@ -2923,13 +2923,7 @@ static int mov_read_stts(MOVContext *c, AVIOContext *pb, MOVAtom atom) av_log(c->fc, AV_LOG_TRACE, "sample_count=%d, sample_duration=%d\n", sample_count, sample_duration); -if ( i+1 == entries -&& i -&& sample_count == 1 -&& total_sample_count > 100 -&& sample_duration/10 > duration / total_sample_count) -sample_duration = duration / total_sample_count; -duration+=(int64_t)sample_duration*(uint64_t)sample_count; +duration+=(int64_t)sample_duration*sample_count; total_sample_count+=sample_count; } -- 2.20.1 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH v3] avcodec/mips: Fix failed case: hevc-conformance-AMP_A_Samsung_* when enable msa
On 24/12/2018 06:07, gxw wrote: > The AV_INPUT_BUFFER_PADDING_SIZE has been increased to 64, but the value is > still 32 > in function ff_hevc_sao_edge_filter_8_msa. So, use > AV_INPUT_BUFFER_PADDING_SIZE directly. > Also, use MAX_PB_SIZE directly instead of 64. Fate tests passed. > --- > libavcodec/mips/hevc_lpf_sao_msa.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) Probably OK. - Derek ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] patch for failing on WavPack DSD files
On 24/12/2018 17:47, David Bryant wrote: > I want to do that, but am swamped at work right now, so it will probably be a > few months before I can get to that. > > In the meantime, I think this patch would be a safe stopgap (and prevent the > Kodi crash). I think it's OK for the meantime (my opinion). - Derek ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] patch for failing on WavPack DSD files
On 12/24/18 12:21 AM, Paul B Mahol wrote: > On 12/24/18, David Bryant wrote: >> On 11/21/18 9:50 PM, David Bryant wrote: >>> On 11/20/18 10:58 PM, Peter Ross wrote: On Tue, Nov 20, 2018 at 09:23:03PM -0800, David Bryant wrote: > Hi, > > Was made aware of this problem on Kodi: > > https://github.com/xbmc/xbmc/issues/14771 > > I'm going to try to add full WavPack DSD support, but thought in the > meantime it would be a good idea to detect and error out early. > > Thanks! cool. is this dst-based, or your own algorithm? -- Peter (A907 E02F A6E5 0CD2 34CD 20D2 6760 79C5 AC40 DD6B) ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel >>> This is my own algorithm. Actually there are two: one is a byte-based >>> algorithm that is very fast and the other is bit-based >>> (like DST) that is slower but compresses better (and still uses less CPU >>> than DST). If I had to make a rough estimation of the >>> average compression ratios, it would be about 0.6 for the fast mode, 0.5 >>> for the high mode, and 0.4 for DST. >>> >>> -David >>> >>> >>> ___ >>> ffmpeg-devel mailing list >>> ffmpeg-devel@ffmpeg.org >>> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel >> Hi. Is there anything else I can provide to help this along? >> >> The behavior of FFmpeg encountering WavPack DSD files without this patch is >> pretty ugly... > Yes, post full patch that adds DSD support in WavPack. > ___ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel I want to do that, but am swamped at work right now, so it will probably be a few months before I can get to that. In the meantime, I think this patch would be a safe stopgap (and prevent the Kodi crash). Thanks! -David ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH v2] swscale/output: Altivec-optimize float yuv2plane1
On Sun, 16 Dec 2018 11:06:53 +0200 Lauri Kasanen wrote: > This function wouldn't benefit from VSX instructions, so I put it > under altivec. > > ./ffmpeg_g -f rawvideo -pix_fmt rgb24 -s hd1080 -i /dev/zero -pix_fmt > grayf32le \ > -f null -vframes 100 -v error -nostats - > > 3743 UNITS in planar1, 65495 runs, 41 skips > > -cpuflags 0 > > 23511 UNITS in planar1, 65530 runs, 6 skips > > grayf32be > > 4647 UNITS in planar1, 65449 runs, 87 skips > > -cpuflags 0 > > 28608 UNITS in planar1, 65530 runs, 6 skips > > The native speedup is 6.28133, and the bswapping one 6.15623. > Fate passes, each format tested with an image to video conversion. > > Signed-off-by: Lauri Kasanen > --- > > Tested on POWER8 LE. Testing on earlier ppc and/or BE appreciated. > > v2: Added #undef vzero, that define broke the build on older gcc. Thanks > Michael Ping. And of course it's not gcc version dependant, but rather it was the BE ifdef; it was too early in the morning. - Lauri ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] Add a new channel layout API
The new API is more extensible and allows for custom layouts.
More accurate information is exported, eg for decoders that do not
set a channel layout, lavc will not make one up for them.
Deprecate the old API working with just uint64_t bitmasks.
Original commit by Anton Khirnov .
Expanded and completed by Vittorio Giovara .
Adopted for FFmpeg by Paul B Mahol .
Signed-off-by: Anton Khirnov
Signed-off-by: Vittorio Giovara
Signed-off-by: Paul B Mahol
---
libavutil/channel_layout.c | 387 --
libavutil/channel_layout.h | 411 ++---
libavutil/version.h| 3 +
3 files changed, 711 insertions(+), 90 deletions(-)
diff --git a/libavutil/channel_layout.c b/libavutil/channel_layout.c
index 3bd5ee29b7..a52f78bb9f 100644
--- a/libavutil/channel_layout.c
+++ b/libavutil/channel_layout.c
@@ -37,75 +37,89 @@ struct channel_name {
};
static const struct channel_name channel_names[] = {
- [0] = { "FL","front left"},
- [1] = { "FR","front right" },
- [2] = { "FC","front center" },
- [3] = { "LFE", "low frequency" },
- [4] = { "BL","back left" },
- [5] = { "BR","back right"},
- [6] = { "FLC", "front left-of-center" },
- [7] = { "FRC", "front right-of-center" },
- [8] = { "BC","back center" },
- [9] = { "SL","side left" },
-[10] = { "SR","side right"},
-[11] = { "TC","top center"},
-[12] = { "TFL", "top front left"},
-[13] = { "TFC", "top front center" },
-[14] = { "TFR", "top front right" },
-[15] = { "TBL", "top back left" },
-[16] = { "TBC", "top back center" },
-[17] = { "TBR", "top back right"},
-[29] = { "DL","downmix left" },
-[30] = { "DR","downmix right" },
-[31] = { "WL","wide left" },
-[32] = { "WR","wide right"},
-[33] = { "SDL", "surround direct left" },
-[34] = { "SDR", "surround direct right" },
-[35] = { "LFE2", "low frequency 2" },
+[AV_CHAN_FRONT_LEFT ] = { "FL" },
+[AV_CHAN_FRONT_RIGHT ] = { "FR" },
+[AV_CHAN_FRONT_CENTER] = { "FC" },
+[AV_CHAN_LOW_FREQUENCY ] = { "LFE" },
+[AV_CHAN_BACK_LEFT ] = { "BL" },
+[AV_CHAN_BACK_RIGHT ] = { "BR" },
+[AV_CHAN_FRONT_LEFT_OF_CENTER] = { "FLC" },
+[AV_CHAN_FRONT_RIGHT_OF_CENTER ] = { "FRC" },
+[AV_CHAN_BACK_CENTER ] = { "BC" },
+[AV_CHAN_SIDE_LEFT ] = { "SL" },
+[AV_CHAN_SIDE_RIGHT ] = { "SR" },
+[AV_CHAN_TOP_CENTER ] = { "TC" },
+[AV_CHAN_TOP_FRONT_LEFT ] = { "TFL" },
+[AV_CHAN_TOP_FRONT_CENTER] = { "TFC" },
+[AV_CHAN_TOP_FRONT_RIGHT ] = { "TFR" },
+[AV_CHAN_TOP_BACK_LEFT ] = { "TBL" },
+[AV_CHAN_TOP_BACK_CENTER ] = { "TBC" },
+[AV_CHAN_TOP_BACK_RIGHT ] = { "TBR" },
+[AV_CHAN_STEREO_LEFT ] = { "DL" },
+[AV_CHAN_STEREO_RIGHT] = { "DR" },
+[AV_CHAN_WIDE_LEFT ] = { "WL" },
+[AV_CHAN_WIDE_RIGHT ] = { "WR" },
+[AV_CHAN_SURROUND_DIRECT_LEFT] = { "SDL" },
+[AV_CHAN_SURROUND_DIRECT_RIGHT ] = { "SDR" },
+[AV_CHAN_LOW_FREQUENCY_2 ] = { "LFE2" },
+[AV_CHAN_SILENCE ] = { "PAD" },
};
-static const char *get_channel_name(int channel_id)
+const char *av_channel_name(enum AVChannel channel_id)
{
if (channel_id < 0 || channel_id >= FF_ARRAY_ELEMS(channel_names))
return NULL;
+if ((unsigned) channel_id >= FF_ARRAY_ELEMS(channel_names))
+return "?";
return channel_names[channel_id].name;
}
+int av_channel_from_string(const char *str)
+{
+for (int i = 0; i < FF_ARRAY_ELEMS(channel_names); i++) {
+if (channel_names[i].name && !strcmp(str, channel_names[i].name)) {
+return i;
+}
+}
+return AVERROR(EINVAL);
+}
+
static const struct {
const char *name;
-int nb_channels;
-uint64_t layout;
+AVChannelLayout layout;
} channel_layout_map[] = {
-{ "mono",1, AV_CH_LAYOUT_MONO },
-{ "stereo", 2, AV_CH_LAYOUT_STEREO },
-{ "2.1", 3, AV_CH_LAYOUT_2POINT1 },
-{ "3.0", 3, AV_CH_LAYOUT_SURROUND },
-{ "3.0(back)", 3, AV_CH_LAYOUT_2_1 },
-{ "4.0", 4, AV_CH_LAYOUT_4POINT0 },
-{ "quad",4, AV_CH_LAYOUT_QUAD },
-{ "quad(side)", 4, AV_CH_LAYOUT_2_2 },
-{ "3.1", 4, AV_CH_LAYOUT_3POINT1 },
-{ "5.0", 5, AV_CH_LAYOUT_5POINT0_BACK },
-{ "5.0(side)", 5, AV_CH_LAYOUT_5POINT0 },
-{
Re: [FFmpeg-devel] [PATCH v2] avcodec/fft_template: libavcodec/fft_template: improve performance of the ff_fft_init in fft_template
On 12/24/18, Michael Niedermayer wrote:
> On Fri, Dec 21, 2018 at 06:09:50PM +0800, Steven Liu wrote:
>> Before patch:
>> init nbits = 17, get 1 samples, average cost: 16105 us
>> After patch:
>> init nbits = 17, get 1 samples, average cost: 15221 us
>>
>> Signed-off-by: Steven Liu
>> ---
>> libavcodec/fft_template.c | 26 +++---
>> 1 file changed, 15 insertions(+), 11 deletions(-)
>>
>> diff --git a/libavcodec/fft_template.c b/libavcodec/fft_template.c
>> index 762c014bc8..2b528be882 100644
>> --- a/libavcodec/fft_template.c
>> +++ b/libavcodec/fft_template.c
>> @@ -261,17 +261,21 @@ av_cold int ff_fft_init(FFTContext *s, int nbits,
>> int inverse)
>> if (s->fft_permutation == FF_FFT_PERM_AVX) {
>> fft_perm_avx(s);
>> } else {
>> -for(i=0; i> -int k;
>> -j = i;
>> -if (s->fft_permutation == FF_FFT_PERM_SWAP_LSBS)
>> -j = (j&~3) | ((j>>1)&1) | ((j<<1)&2);
>> -k = -split_radix_permutation(i, n, s->inverse) & (n-1);
>> -if (s->revtab)
>> -s->revtab[k] = j;
>> -if (s->revtab32)
>> -s->revtab32[k] = j;
>> -}
>> +#define SPLIT_RADIX_PERMUTATION(num) do { \
>> +for(i=0; i> +int k;\
>> +j = i;\
>
>> +if (s->fft_permutation == FF_FFT_PERM_SWAP_LSBS)\
>
> maybe this if() should be factored out too ?
>
> the change looks good though, and iam not sure this is speed relevant
> enough
Well, it helps. But this code is partially going to be rewritten
anyway in future.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH v2] avcodec/fft_template: libavcodec/fft_template: improve performance of the ff_fft_init in fft_template
On Fri, Dec 21, 2018 at 06:09:50PM +0800, Steven Liu wrote:
> Before patch:
> init nbits = 17, get 1 samples, average cost: 16105 us
> After patch:
> init nbits = 17, get 1 samples, average cost: 15221 us
>
> Signed-off-by: Steven Liu
> ---
> libavcodec/fft_template.c | 26 +++---
> 1 file changed, 15 insertions(+), 11 deletions(-)
>
> diff --git a/libavcodec/fft_template.c b/libavcodec/fft_template.c
> index 762c014bc8..2b528be882 100644
> --- a/libavcodec/fft_template.c
> +++ b/libavcodec/fft_template.c
> @@ -261,17 +261,21 @@ av_cold int ff_fft_init(FFTContext *s, int nbits, int
> inverse)
> if (s->fft_permutation == FF_FFT_PERM_AVX) {
> fft_perm_avx(s);
> } else {
> -for(i=0; i -int k;
> -j = i;
> -if (s->fft_permutation == FF_FFT_PERM_SWAP_LSBS)
> -j = (j&~3) | ((j>>1)&1) | ((j<<1)&2);
> -k = -split_radix_permutation(i, n, s->inverse) & (n-1);
> -if (s->revtab)
> -s->revtab[k] = j;
> -if (s->revtab32)
> -s->revtab32[k] = j;
> -}
> +#define SPLIT_RADIX_PERMUTATION(num) do { \
> +for(i=0; i +int k;\
> +j = i;\
> +if (s->fft_permutation == FF_FFT_PERM_SWAP_LSBS)\
maybe this if() should be factored out too ?
the change looks good though, and iam not sure this is speed relevant
enough
thx
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
Never trust a computer, one day, it may think you are the virus. -- Compn
signature.asc
Description: PGP signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/3] vcodec/lagarith: Remove duplicate check
On 24/12/2018 00:14, Michael Niedermayer wrote: > Signed-off-by: Michael Niedermayer > --- > libavcodec/lagarith.c | 3 --- > 1 file changed, 3 deletions(-) OK. (Can you tell it's Christmas, and I have free time now...? :V) - Derek ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 2/3] avcodec/lagarith: Optimize case with singleton probability distribution
On 24/12/2018 00:14, Michael Niedermayer wrote: > Fixes: Timeout > Fixes: > 10554/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_LAGARITH_fuzzer-5739938067251200 > > Found-by: continuous fuzzing > processhttps://github.com/google/oss-fuzz/tree/master/projects/ffmpeg > Signed-off-by: Michael Niedermayer > --- > libavcodec/lagarith.c| 36 > libavcodec/lagarithrac.h | 1 + > 2 files changed, 37 insertions(+) This adds a load of completely uncommented and confusing code; it murders readability for... what? Making a 'timeout' in a specific fuzzer go away? Is there a real benefit or reason to pollute the code with this? Measurable and useful speedup? - Derek ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/2] add support for ROI-based encoding
On 24/12/2018 08:41, Guo, Yejun wrote: >>> +size_t nb_rois = frame->rois_buf->size / >>> + sizeof(AVFrameROI); >> >> I think we have some macros that do this already. > > I tried a code search and do not find one, there is a similar macro which > does not work for this case: #define FF_ARRAY_ELEMS(a) (sizeof(a) / > sizeof((a)[0])) > I might miss it, I'll try again to see if any luck. Right, I was thinking of FF_ARRAY_ELEMS, and you're right. You can disregard this comment from me. > thanks, the new idea is to use an integer value instead of the enum. OK. I'll take a look when teh new patch lands. Thanks! ROI support is something avcodec has needed for a while. Cheers, - Derek ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 3/3] avcodec/utils: Optimize ff_color_frame()
On 12/24/18, Michael Niedermayer wrote: > Fixes: Timeout > Fixes: > 10709/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_H264_fuzzer-5630617975259136 > > Found-by: continuous fuzzing process > https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg > Signed-off-by: Michael Niedermayer > --- > libavcodec/utils.c | 9 +++-- > 1 file changed, 7 insertions(+), 2 deletions(-) Ugly, set first row and use memcpy for rest of rows. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 2/3] flvdec: Mark the demuxer as allowing discontinuous timestamps
On 26/11/2018 13:51, Derek Buitenhuis wrote: > On 23/11/2018 02:16, Michael Niedermayer wrote: >> do we have some sample flv files that require this patchset / that have >> discontinuites. > > I have many. I've mailed you one privately, while I work on getting a public > one. > >> another thing i just realize now, why is this discontinuity issues coming up >> now? flv support is very old. This should be a long standing issue > > Probably not many codebases check the DISCONT flag. I only just added proper > discontinuity handling to some codebases this year, and that's why *I* > noticed. > Chances are most people use the ffmpeg cli which seems to handle stuff > differently, > and doesn't necessarily care about the flag. In my case, I only try to 'fix' > discontinuities if they appear to be in a format that allows them, during > indexing. > > I could add a workaround specific to FLV, or some threshold stuff, but I'd > prefer > that demuxers which may output discontinuous timestamps say they do. Ping. Is there a decision on eitehr what to do or to ignore this? I'll update my downstream code with an FLV edge case if need be. - Derek ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 3/3] avcodec/utils: Optimize ff_color_frame()
On 24/12/2018 00:14, Michael Niedermayer wrote: > Fixes: Timeout > Fixes: > 10709/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_H264_fuzzer-5630617975259136 > > Found-by: continuous fuzzing > processhttps://github.com/google/oss-fuzz/tree/master/projects/ffmpeg > Signed-off-by: Michael Niedermayer > --- > libavcodec/utils.c | 9 +++-- > 1 file changed, 7 insertions(+), 2 deletions(-) Comments and stats please... - Derek ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH v3 1/2] lavf: Add general API for IO buffer synchronization.
On 12/21/18 2:48 AM, Michael Niedermayer wrote: On Thu, Dec 20, 2018 at 11:00:32AM +0100, Nicolas George wrote: Andrey Semashev (2018-12-10): This commit adds a new set of functions to avio and url subsystems, which allow users to invoke IO buffer synchronization with the underlying media. The most obvious target for this extension if the filesystem streams. Invoking IO synchronization allows user applications to ensure that all written content has reached the filesystem on the media and can be observed by other processes. The public API for this is avio_sync() function, which can be called on AVIOContext. The internal, lower layer API is ffurl_sync(), which works directly on the underlying URLContext. URLContext backends can add support for this new API by setting the sync handler to the new url_sync member of URLProtocol. When no handler is set then the sync operation is a no-op, the result code is AVERROR(ENOSYS). --- libavformat/avio.c| 7 +++ libavformat/avio.h| 20 libavformat/aviobuf.c | 17 + libavformat/url.h | 12 4 files changed, 56 insertions(+) I have no more objections to the patch as it is, thanks. But I have no opinion in favor of it either; it is useful in principle, but I do not know if it is worth the extra maintenance for a use case like this project. I will leave the judgement to others. IMHO, it looks useful and extra maintaince needed seems not major So, will this patchset be merged then? ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avformat/hls.c: Properly free prev_segments dynarray after playlist parsing
> 在 2018年12月24日，下午6:25，Liu Steven 写道：
>
>
>
>> 在 2018年12月24日，下午5:24，Valery Kot 写道：
>>
>> Updated commit message for hls.c memory leak fix
>> <0001-avformat-hls.c-Properly-free-prev_segments-dynarray-.txt>___
>
> Looking at the free_segment_dynarray:
>
> static void free_segment_dynarray(struct segment **segments, int n_segments)
> {
>int i;
>for (i = 0; i < n_segments; i++) {
>av_freep([i]->key);
>av_freep([i]->url);
>av_freep([i]);
>}
> }
>
> perhaps the segments have been free?
Ah, ok, i see, you are right.
Patch will push after 24 hours if there have no objections.
Thanks
Steven
>
> Thanks
>> ffmpeg-devel mailing list
>> ffmpeg-devel@ffmpeg.org
>> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
>
>
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avformat/hls.c: Properly free prev_segments dynarray after playlist parsing
> 在 2018年12月24日，下午5:24，Valery Kot 写道：
>
> Updated commit message for hls.c memory leak fix
> <0001-avformat-hls.c-Properly-free-prev_segments-dynarray-.txt>___
Looking at the free_segment_dynarray:
static void free_segment_dynarray(struct segment **segments, int n_segments)
{
int i;
for (i = 0; i < n_segments; i++) {
av_freep([i]->key);
av_freep([i]->url);
av_freep([i]);
}
}
perhaps the segments have been free?
Thanks
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] avformat/hls.c: Fix memory leak
> 在 2018年12月24日，下午5:28，Valery Kot 写道： > > On Sat, Dec 22, 2018 at 6:33 PM Derek Buitenhuis > wrote: >> Can you add to the commit message to explain what exactly is >> changed and why? 'Fix leak' isn't very useful. > > Submitted a patch > (http://ffmpeg.org/pipermail/ffmpeg-devel/2018-December/238093.html) > with updated commit message, Or is there a way to edit commit message > of an already sumitted patch? AFAIK no, i always resend patch :D Thanks Steven > > Valery > ___ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] fate: add tests/fate/hlsenc.mak for hls FATE
init add three test examples: 1. check no endlist at the end 2. check endlist at the end 3. check hls_list_size 0 full list Signed-off-by: Steven Liu --- tests/Makefile| 1 + tests/fate/hlsenc.mak | 43 +++ 2 files changed, 44 insertions(+) create mode 100644 tests/fate/hlsenc.mak diff --git a/tests/Makefile b/tests/Makefile index 24680b8150..90801b42b2 100644 --- a/tests/Makefile +++ b/tests/Makefile @@ -131,6 +131,7 @@ include $(SRC_PATH)/tests/fate/gif.mak include $(SRC_PATH)/tests/fate/h264.mak include $(SRC_PATH)/tests/fate/hap.mak include $(SRC_PATH)/tests/fate/hevc.mak +include $(SRC_PATH)/tests/fate/hlsenc.mak include $(SRC_PATH)/tests/fate/hw.mak include $(SRC_PATH)/tests/fate/id3v2.mak include $(SRC_PATH)/tests/fate/image.mak diff --git a/tests/fate/hlsenc.mak b/tests/fate/hlsenc.mak new file mode 100644 index 00..80536239fc --- /dev/null +++ b/tests/fate/hlsenc.mak @@ -0,0 +1,43 @@ +tests/data/live_no_endlist.m3u8: TAG = GEN +tests/data/live_no_endlist.m3u8: ffmpeg$(PROGSSUF)$(EXESUF) | tests/data + $(M)$(TARGET_EXEC) $(TARGET_PATH)/$< \ +-f lavfi -v verbose -i "aevalsrc=cos(2*PI*t)*sin(2*PI*(440+4*t)*t):d=20" -f hls -hls_time 3 -map 0 \ +-hls_flags omit_endlist -codec:a mp2fixed -hls_segment_filename $(TARGET_PATH)/tests/data/live_no_endlist_%03d.ts \ +$(TARGET_PATH)/tests/data/live_no_endlist.m3u8 2>/dev/null + +FATE_AFILTER-$(call ALLYES, HLS_DEMUXER MPEGTS_MUXER MPEGTS_DEMUXER AEVALSRC_FILTER LAVFI_INDEV MP2FIXED_ENCODER) += fate-hls-live-no-endlist +fate-hls-live-no-endlist: tests/data/live_no_endlist.m3u8 +fate-hls-live-no-endlist: SRC = $(TARGET_PATH)/tests/data/live_no_endlist.m3u8 +fate-hls-live-no-endlist: CMD = md5 -i $(SRC) -af hdcd=process_stereo=false -t 6 -f s24le +fate-hls-live-no-endlist: CMP = oneline +fate-hls-live-no-endlist: REF = e038bb8e65d4c1745b9b3ed643e607a3 + +tests/data/live_last_endlist.m3u8: TAG = GEN +tests/data/live_last_endlist.m3u8: ffmpeg$(PROGSSUF)$(EXESUF) | tests/data + $(M)$(TARGET_EXEC) $(TARGET_PATH)/$< \ +-f lavfi -v verbose -i "aevalsrc=cos(2*PI*t)*sin(2*PI*(440+4*t)*t):d=20" -f hls -hls_time 3 -map 0 \ +-codec:a mp2fixed -hls_segment_filename $(TARGET_PATH)/tests/data/live_last_endlist_%03d.ts \ +$(TARGET_PATH)/tests/data/live_last_endlist.m3u8 2>/dev/null + +FATE_AFILTER-$(call ALLYES, HLS_DEMUXER MPEGTS_MUXER MPEGTS_DEMUXER AEVALSRC_FILTER LAVFI_INDEV MP2FIXED_ENCODER) += fate-hls-live-last-endlist +fate-hls-live-last-endlist: tests/data/live_last_endlist.m3u8 +fate-hls-live-last-endlist: SRC = $(TARGET_PATH)/tests/data/live_last_endlist.m3u8 +fate-hls-live-last-endlist: CMD = md5 -i $(SRC) -af hdcd=process_stereo=false -t 6 -f s24le +fate-hls-live-last-endlist: CMP = oneline +fate-hls-live-last-endlist: REF = 2ca8567092dcf01e37bedd50454d1ab7 + + +tests/data/live_endlist.m3u8: TAG = GEN +tests/data/live_endlist.m3u8: ffmpeg$(PROGSSUF)$(EXESUF) | tests/data + $(M)$(TARGET_EXEC) $(TARGET_PATH)/$< \ +-f lavfi -i "aevalsrc=cos(2*PI*t)*sin(2*PI*(440+4*t)*t):d=20" -f hls -hls_time 3 -map 0 \ +-hls_list_size 0 -codec:a mp2fixed -hls_segment_filename $(TARGET_PATH)/tests/data/live_endlist_%d.ts \ +$(TARGET_PATH)/tests/data/live_endlist.m3u8 2>/dev/null + +FATE_AFILTER-$(call ALLYES, HLS_DEMUXER MPEGTS_MUXER MPEGTS_DEMUXER AEVALSRC_FILTER LAVFI_INDEV MP2FIXED_ENCODER) += fate-hls-live-endlist +fate-hls-live-endlist: tests/data/live_endlist.m3u8 +fate-hls-live-endlist: SRC = $(TARGET_PATH)/tests/data/live_endlist.m3u8 +fate-hls-live-endlist: CMD = md5 -i $(SRC) -af hdcd=process_stereo=false -t 20 -f s24le +fate-hls-live-endlist: CMP = oneline +fate-hls-live-endlist: REF = e189ce781d9c87882f58e3929455167b + -- 2.15.2 (Apple Git-101.1) ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] avformat/hls.c: Fix memory leak
On Sat, Dec 22, 2018 at 6:33 PM Derek Buitenhuis wrote: > Can you add to the commit message to explain what exactly is > changed and why? 'Fix leak' isn't very useful. Submitted a patch (http://ffmpeg.org/pipermail/ffmpeg-devel/2018-December/238093.html) with updated commit message, Or is there a way to edit commit message of an already sumitted patch? Valery ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] avformat/hls.c: Properly free prev_segments dynarray after playlist parsing
Updated commit message for hls.c memory leak fix From 0bb8c4a17f9de7167f3aafc59fc309f581e00e0b Mon Sep 17 00:00:00 2001 From: vkot Date: Mon, 24 Dec 2018 10:19:55 +0100 Subject: [PATCH] avformat/hls.c: Properly free prev_segments dynarray after playlist parsing --- libavformat/hls.c | 1 + 1 file changed, 1 insertion(+) diff --git a/libavformat/hls.c b/libavformat/hls.c index 8ad08baaed..63e1abe789 100644 --- a/libavformat/hls.c +++ b/libavformat/hls.c @@ -931,6 +931,7 @@ static int parse_playlist(HLSContext *c, const char *url, prev_start_seq_no, pls->start_seq_no); } free_segment_dynarray(prev_segments, prev_n_segments); +av_freep(_segments); } if (pls) pls->last_load_time = av_gettime_relative(); -- 2.15.1.windows.2 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/2] add support for ROI-based encoding
> -Original Message-
> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf
> Of Derek Buitenhuis
> Sent: Saturday, December 22, 2018 12:36 AM
> To: ffmpeg-devel@ffmpeg.org
> Subject: Re: [FFmpeg-devel] [PATCH 1/2] add support for ROI-based
> encoding
>
> A few comments below.
>
> On 12/12/2018 16:26, Guo, Yejun wrote:
> > +if (frame->rois_buf != NULL) {
> > +if (x4->params.rc.i_aq_mode == X264_AQ_NONE) {
> > +av_log(ctx, AV_LOG_ERROR, "Adaptive quantization must
> > + be enabled to use ROI encoding, skipping ROI.\n");
>
> This should, in my opinion, return an error and fail hard.
>
> If people want it to continue anyway, it should be AV_LOG_WARNING.
thanks, WARNING is better, will change to it.
>
> > +} else {
> > +if (frame->interlaced_frame == 0) {
> > +const static int MBSIZE = 16;
>
> I think we generally use defines for this stuff.
will change to define.
>
> > +size_t mbx = (frame->width + MBSIZE - 1) / MBSIZE;
> > +size_t mby = (frame->height + MBSIZE - 1) /
> > + MBSIZE;
>
>
> > +float* qoffsets = (float*)av_malloc(sizeof(float)
> > + * mbx * mby);
>
> Convention in FFmpeg is to use sizeof(*var).
ok, I'll follow it.
>
> > +memset(qoffsets, 0, sizeof(float) * mbx * mby);
>
> Missing NULL check for alloc failure.
thanks, will add the check.
>
> > +
> > +size_t nb_rois = frame->rois_buf->size /
> > + sizeof(AVFrameROI);
>
> I think we have some macros that do this already.
I tried a code search and do not find one, there is a similar macro which does
not work for this case: #define FF_ARRAY_ELEMS(a) (sizeof(a) / sizeof((a)[0]))
I might miss it, I'll try again to see if any luck.
>
> > +AVFrameROI* rois = (AVFrameROI*)frame->rois_buf->data;
> > +for (size_t roi = 0; roi < nb_rois; ++roi) {
>
> Nit/convention: roi++
ok, will change.
>
> > +int starty = FFMIN(mby, rois[roi].top / MBSIZE);
> > +int endy = FFMIN(mby, (rois[roi].bottom + MBSIZE -
> > 1)/
> MBSIZE);
> > +int startx = FFMIN(mbx, rois[roi].left / MBSIZE);
> > +int endx = FFMIN(mbx, (rois[roi].right + MBSIZE -
> > 1)/ MBSIZE);
> > +for (int y = starty; y < endy; ++y) {
> > +for (int x = startx; x < endx; ++x) {
and will also change to x++ and y ++
> > +qoffsets[x + y*mbx] = get_roi_qoffset(ctx,
> rois[roi].quality);
> > +}
> > +}
> > +}
> > +
> > +x4->pic.prop.quant_offsets = qoffsets;
> > +x4->pic.prop.quant_offsets_free = av_free;
> > +} else {
> > +av_log(ctx, AV_LOG_ERROR, "interlaced_frame not
> > + supported for ROI encoding yet, skipping ROI.\n");
>
> Same comment as befor: return error or change to warning.
will change to warning.
>
>
>
> > +enum AVRoiQuality {
>
> Probably should be AVROIQuality.
>
> > +AV_RQ_NONE = 0,
> > +AV_RQ_BETTER = 1,
> > +AV_RQ_BEST = 2,
> > +};
> > +
> > +typedef struct AVFrameROI {
> > +/* coordinates at frame pixel level.
> > + * it will be extended internally if the codec requirs an alignment
> > + */
> > +size_t top;
> > +size_t bottom;
> > +size_t left;
> > +size_t right;
> > +enum AVRoiQuality quality;
> > +} AVFrameROI;
>
> Are we not going to allow the API to set an actual offset? This really limits
> what someone can do. (I say this as a user of x264's ROI API, in my own
> codebase, at least.)
thanks, the new idea is to use an integer value instead of the enum.
>
> Cheers,
> - Derek
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/2] add support for ROI-based encoding
> -Original Message-
> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf
> Of Mark Thompson
> Sent: Friday, December 21, 2018 5:08 AM
> To: ffmpeg-devel@ffmpeg.org
> Subject: Re: [FFmpeg-devel] [PATCH 1/2] add support for ROI-based
> encoding
>
> On 12/12/2018 16:26, Guo, Yejun wrote:
> > This patchset contains two patches.
> > - the first patch (this patch) finished the code and ask for upstream.
> > - the second patch is just a quick example on how to generate ROI info.
> >
> > The encoders such as libx264 support different QPs offset for
> > different MBs, it makes possible for ROI-based encoding. It makes
> > sense to add support within ffmpeg to generate/accept ROI infos and pass
> into encoders.
> >
> > Typical usage: After AVFrame is decoded, a ffmpeg filter or user's
> > code generates ROI info for that frame, and the encoder finally does
> > the ROI-based encoding. And so I choose to maintain the ROI info
> > (AVFrameROI) within AVFrame struct.
> >
> > Since the ROI info generator might more focus on the domain knowledge
> > of the interest regions, instead of the encoding detail, the
> > AVFrameROI is designed to be more friend for ffmpeg users.
> >
> > This patch just enabled the path from ffmpeg to libx264, the more
> > encoders can be added later.
> >
> > Signed-off-by: Guo, Yejun
> > ---
> > libavcodec/libx264.c | 56
>
> > libavutil/frame.c| 8
> > libavutil/frame.h| 24 ++
> > 3 files changed, 88 insertions(+)
> >
> > ...
> > diff --git a/libavutil/frame.c b/libavutil/frame.c index
> > 9b3fb13..dbc4b0a 100644
> > --- a/libavutil/frame.c
> > +++ b/libavutil/frame.c
> > @@ -425,6 +425,13 @@ FF_DISABLE_DEPRECATION_WARNINGS
> > FF_ENABLE_DEPRECATION_WARNINGS #endif
> >
> > +av_buffer_unref(>rois_buf);
> > +if (src->rois_buf) {
> > +dst->rois_buf = av_buffer_ref(src->rois_buf);
> > +if (!dst->rois_buf)
> > +return AVERROR(ENOMEM);
> > +}
> > +
> > av_buffer_unref(>opaque_ref);
> > av_buffer_unref(>private_ref);
> > if (src->opaque_ref) {
> > @@ -571,6 +578,7 @@ FF_DISABLE_DEPRECATION_WARNINGS
> > FF_ENABLE_DEPRECATION_WARNINGS #endif
> >
> > +av_buffer_unref(>rois_buf);
> > av_buffer_unref(>hw_frames_ctx);
> >
> > av_buffer_unref(>opaque_ref);
> > diff --git a/libavutil/frame.h b/libavutil/frame.h index
> > 66f27f4..00d509d 100644
> > --- a/libavutil/frame.h
> > +++ b/libavutil/frame.h
> > @@ -193,6 +193,23 @@ typedef struct AVFrameSideData {
> > AVBufferRef *buf;
> > } AVFrameSideData;
> >
> > +enum AVRoiQuality {
> > +AV_RQ_NONE = 0,
> > +AV_RQ_BETTER = 1,
> > +AV_RQ_BEST = 2,
> > +};
>
> I don't think I like this enum - an integer value without directly specifying
> this
> meaning would seem best for future flexibility? Negative values might be
> meaningful. A greater range would also allow ranking if there are many
> regions, which may be needed if some are discarded (because of hardware
> constraints, for example - VAAPI makes this visible).
thanks, yes, the enum method also has disadvantages.
I'll change the interface to export an integer value.
>
> > +
> > +typedef struct AVFrameROI {
> > +/* coordinates at frame pixel level.
> > + * it will be extended internally if the codec requirs an alignment
> > + */
>
> What is intended to happen if regions overlap? (In the above you have it
> using the last value in the list.)
Yes, the last value will be used if regions overlap.
My idea is that the ROI generator is responsible to keep the order. I will add
notes here.
>
> > +size_t top;
> > +size_t bottom;
> > +size_t left;
> > +size_t right;
> > +enum AVRoiQuality quality;
> > +} AVFrameROI;
> > +
> > /**
> > * This structure describes decoded (raw) audio or video data.
> > *
> > @@ -556,6 +573,13 @@ typedef struct AVFrame {
> > attribute_deprecated
> > AVBufferRef *qp_table_buf;
> > #endif
> > +
> > +/**
> > + * For ROI-based encoding, the number of ROI area is implied
> > + * in the size of buf.
> > + */
> > +AVBufferRef *rois_buf;
>
> This should be a new type of AVFrameSideData, not a new field in AVFrame.
thanks, will change to it.
>
> > +
> > /**
> > * For hwaccel-format frames, this should be a reference to the
> > * AVHWFramesContext describing the frame.
> >
>
> - Mark
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] patch for failing on WavPack DSD files
On 12/24/18, David Bryant wrote: > On 11/21/18 9:50 PM, David Bryant wrote: >> On 11/20/18 10:58 PM, Peter Ross wrote: >>> On Tue, Nov 20, 2018 at 09:23:03PM -0800, David Bryant wrote: Hi, Was made aware of this problem on Kodi: https://github.com/xbmc/xbmc/issues/14771 I'm going to try to add full WavPack DSD support, but thought in the meantime it would be a good idea to detect and error out early. Thanks! >>> cool. is this dst-based, or your own algorithm? >>> >>> -- Peter >>> (A907 E02F A6E5 0CD2 34CD 20D2 6760 79C5 AC40 DD6B) >>> >>> ___ >>> ffmpeg-devel mailing list >>> ffmpeg-devel@ffmpeg.org >>> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel >> This is my own algorithm. Actually there are two: one is a byte-based >> algorithm that is very fast and the other is bit-based >> (like DST) that is slower but compresses better (and still uses less CPU >> than DST). If I had to make a rough estimation of the >> average compression ratios, it would be about 0.6 for the fast mode, 0.5 >> for the high mode, and 0.4 for DST. >> >> -David >> >> >> ___ >> ffmpeg-devel mailing list >> ffmpeg-devel@ffmpeg.org >> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel > > Hi. Is there anything else I can provide to help this along? > > The behavior of FFmpeg encountering WavPack DSD files without this patch is > pretty ugly... Yes, post full patch that adds DSD support in WavPack. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
