Re: [FFmpeg-devel] [PATCH] avformat: expose avlanguage.h
Why?
On 11/27/19, Aman Gupta wrote:
> From: Aman Gupta
>
> Signed-off-by: Aman Gupta
> ---
> doc/APIchanges | 3 +++
> libavformat/Makefile | 1 +
> libavformat/avlanguage.c | 2 --
> libavformat/avlanguage.h | 5 +
> libavformat/version.h| 2 +-
> 5 files changed, 6 insertions(+), 7 deletions(-)
>
> diff --git a/doc/APIchanges b/doc/APIchanges
> index 401c65a753..0cf9a6e2a3 100644
> --- a/doc/APIchanges
> +++ b/doc/APIchanges
> @@ -15,6 +15,9 @@ libavutil: 2017-10-21
>
> API changes, most recent first:
>
> +2019-11-26 - xx - lavf 58.36.100 - avlanguage.h
> + Add av_convert_lang_to().
> +
> 2019-11-17 - 1c23abc88f - lavu 56.36.100 - eval API
>Add av_expr_count_vars().
>
> diff --git a/libavformat/Makefile b/libavformat/Makefile
> index 52f29b1a6d..7460f73fa2 100644
> --- a/libavformat/Makefile
> +++ b/libavformat/Makefile
> @@ -3,6 +3,7 @@ DESC = FFmpeg container format library
>
> HEADERS = avformat.h\
>avio.h\
> + avlanguage.h \
>version.h \
>
> OBJS = allformats.o \
> diff --git a/libavformat/avlanguage.c b/libavformat/avlanguage.c
> index f5d2ddf304..1673dc4726 100644
> --- a/libavformat/avlanguage.c
> +++ b/libavformat/avlanguage.c
> @@ -764,9 +764,7 @@ const char *ff_convert_lang_to(const char *lang, enum
> AVLangCodespace target_cod
> return NULL;
> }
>
> -#if LIBAVFORMAT_VERSION_MAJOR < 58
> const char *av_convert_lang_to(const char *lang, enum AVLangCodespace
> target_codespace)
> {
> return ff_convert_lang_to(lang, target_codespace);
> }
> -#endif
> diff --git a/libavformat/avlanguage.h b/libavformat/avlanguage.h
> index 1d72dcb3cb..00f2b15f03 100644
> --- a/libavformat/avlanguage.h
> +++ b/libavformat/avlanguage.h
> @@ -37,10 +37,7 @@ enum AVLangCodespace {
> * Convert a language code to a target codespace. The source codespace is
> guessed.
> * @return NULL if the provided lang is null or invalid.
> */
> -const char *ff_convert_lang_to(const char *lang, enum AVLangCodespace
> target_codespace);
> -#if LIBAVFORMAT_VERSION_MAJOR < 58
> -attribute_deprecated
> const char *av_convert_lang_to(const char *lang, enum AVLangCodespace
> target_codespace);
> -#endif
> +const char *ff_convert_lang_to(const char *lang, enum AVLangCodespace
> target_codespace);
>
> #endif /* AVFORMAT_AVLANGUAGE_H */
> diff --git a/libavformat/version.h b/libavformat/version.h
> index bac54aed9d..f72fb9478a 100644
> --- a/libavformat/version.h
> +++ b/libavformat/version.h
> @@ -32,7 +32,7 @@
> // Major bumping may affect Ticket5467, 5421, 5451(compatibility with
> Chromium)
> // Also please add any ticket numbers that you believe might be affected
> here
> #define LIBAVFORMAT_VERSION_MAJOR 58
> -#define LIBAVFORMAT_VERSION_MINOR 35
> +#define LIBAVFORMAT_VERSION_MINOR 36
> #define LIBAVFORMAT_VERSION_MICRO 100
>
> #define LIBAVFORMAT_VERSION_INT AV_VERSION_INT(LIBAVFORMAT_VERSION_MAJOR, \
> --
> 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 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 v6 1/2] lavf/isom: support for demuxing and remuxing of MPEG-H 3D Audio in MP4
Hi, Could you merge this patch if there is no objection? > -Original Message- > From: Tsuchiya, Yuki (SHES) > > Implemented according to the specification at > https://www.iso.org/standard/69561.html > The 'mhm1' sample entry is registered with MP4RA, which is defined as MHAS > encapsulated single stream MPEG-H 3D Audio. > 'MHAS' stands for MPEG-H audio stream, which contains encoded audio data > and corresponds metadata for decoding. > This patch enables extracting the MHAS bitstream from MP4 and remuxing > into MP4. > ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH] avformat/hlsenc: remove duplicate code block
Signed-off-by: Steven Liu
---
libavformat/hlsenc.c | 23 ---
1 file changed, 4 insertions(+), 19 deletions(-)
diff --git a/libavformat/hlsenc.c b/libavformat/hlsenc.c
index 043438368e..1105380806 100644
--- a/libavformat/hlsenc.c
+++ b/libavformat/hlsenc.c
@@ -2486,7 +2486,9 @@ static void hls_free_variant_streams(struct HLSContext
*hls)
if (vtt_oc) {
av_freep(&vs->vtt_basename);
av_freep(&vs->vtt_m3u8_name);
+avformat_free_context(vs->vtt_avf);
}
+avformat_free_context(vs->avf);
hls_free_segments(vs->segments);
hls_free_segments(vs->old_segments);
@@ -2956,31 +2958,14 @@ static int hls_init(AVFormatContext *s)
fail:
if (ret < 0) {
-av_freep(&hls->key_basename);
-for (i = 0; i < hls->nb_varstreams && hls->var_streams; i++) {
-vs = &hls->var_streams[i];
-av_freep(&vs->basename);
-av_freep(&vs->vtt_basename);
-av_freep(&vs->fmp4_init_filename);
-av_freep(&vs->m3u8_name);
-av_freep(&vs->vtt_m3u8_name);
-av_freep(&vs->streams);
-av_freep(&vs->language);
-av_freep(&vs->agroup);
-av_freep(&vs->ccgroup);
-av_freep(&vs->baseurl);
-av_freep(&vs->varname);
-if (vs->avf)
-avformat_free_context(vs->avf);
-if (vs->vtt_avf)
-avformat_free_context(vs->vtt_avf);
-}
+hls_free_variant_streams(hls);
for (i = 0; i < hls->nb_ccstreams; i++) {
ClosedCaptionsStream *ccs = &hls->cc_streams[i];
av_freep(&ccs->ccgroup);
av_freep(&ccs->instreamid);
av_freep(&ccs->language);
}
+av_freep(&hls->key_basename);
av_freep(&hls->var_streams);
av_freep(&hls->cc_streams);
av_freep(&hls->master_m3u8_url);
--
2.15.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] avfilter: Add tonemap vaapi filter for H2S
It performs HDR(High Dynamic Range) to SDR(Standard Dynamic Range) conversion
with tone-mapping. It only supports HDR10 as input temporarily.
An example command to use this filter with vaapi codecs:
FFMPEG -hwaccel vaapi -vaapi_device /dev/dri/renderD128 -hwaccel_output_format
vaapi \
-i INPUT -vf 'tonemap_vaapi=format=p010' -c:v hevc_vaapi -profile 2 OUTPUT
Signed-off-by: Xinpeng Sun
Signed-off-by: Zachary Zhou
---
configure | 2 +
doc/filters.texi | 81 +++
libavfilter/Makefile | 1 +
libavfilter/allfilters.c | 1 +
libavfilter/vf_tonemap_vaapi.c | 420 +
5 files changed, 505 insertions(+)
create mode 100644 libavfilter/vf_tonemap_vaapi.c
diff --git a/configure b/configure
index 2519e6421f..5e99de6cd9 100755
--- a/configure
+++ b/configure
@@ -3575,6 +3575,7 @@ tinterlace_filter_deps="gpl"
tinterlace_merge_test_deps="tinterlace_filter"
tinterlace_pad_test_deps="tinterlace_filter"
tonemap_filter_deps="const_nan"
+tonemap_vaapi_filter_deps="vaapi
VAProcPipelineParameterBuffer_output_hdr_metadata"
tonemap_opencl_filter_deps="opencl const_nan"
transpose_opencl_filter_deps="opencl"
transpose_vaapi_filter_deps="vaapi VAProcPipelineCaps_rotation_flags"
@@ -6575,6 +6576,7 @@ if enabled vaapi; then
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_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"
diff --git a/doc/filters.texi b/doc/filters.texi
index 16bf2df6c2..7232783256 100644
--- a/doc/filters.texi
+++ b/doc/filters.texi
@@ -20965,6 +20965,87 @@ Apply a strong blur of both luma and chroma parameters:
@c man end OPENCL VIDEO FILTERS
+@chapter VAAPI Video Filters
+@c man begin VAAPI VIDEO FILTERS
+
+VAAPI Video filters are usually used with VAAPI decoder and VAAPI encoder.
Below is a description of VAAPI video filters.
+
+To enable compilation of these filters you need to configure FFmpeg with
+@code{--enable-vaapi}.
+
+Running VAAPI filters requires you to initialize a hardware device and to pass
that device to all filters in any filter graph.
+@table @option
+
+@item -hwaccel vaapi
+Specify the hardware accelerator as @var{vaapi}.
+
+@item -vaapi_device @var{driver_path}
+Specify the vaapi driver path with @var{driver_path}.
+
+@item -hwaccel_output_format @var{vaapi}
+Specify the output format of hardware accelerator as @var{vaapi}. All VAAPI
hardware surfaces in ffmpeg are represented by the @var{vaapi} pixfmt.
+
+@end table
+
+@itemize
+@item
+Example of running tonemap_vaapi filter with default parameters on it.
+@example
+-hwaccel vaapi -vaapi_device /dev/dri/renderD128 -hwaccel_output_format vaapi
-i INPUT -vf "tonemap_vaapi, hwdownload" OUTPUT
+@end example
+@end itemize
+
+Since VAAPI filters are not able to access frame data in arbitrary memory, so
if you use a decoder other than VAAPI decoder before VAAPI filters, all frame
data needs to be uploaded(@ref{hwupload}) to hardware surfaces connected to the
appropriate device before being used. Also if you add a encoder other than
VAAPI encoder after VAAPI filters, the hardware surfaces should be
downloaded(@ref{hwdownload}) back to normal memory. Note that @ref{hwupload}
will upload to a surface with the same layout as the software frame, so it may
be necessary to add a @ref{format} filter immediately before to get the input
into the right format and @ref{hwdownload} does not support all formats on the
output - it may be necessary to insert an additional @ref{format} filter
immediately following in the graph to get the output in a supported format.
+
+@section tonemap_vappi
+
+Perform HDR(High Dynamic Range) to SDR(Standard Dynamic Range) conversion with
tone-mapping.
+It maps the dynamic range of HDR10 content to the SDR content.
+It only accepts HDR10 as input temporarily.
+
+It accepts the following parameters:
+
+@table @option
+@item format
+Specify the output pixel format.
+
+Currently supported formats are:
+@table @var
+@item p010
+@item nv12
+@end table
+
+Default is nv12.
+
+@item primaries, p
+Set the output color primaries.
+
+Default is same as input.
+
+@item transfer, t
+Set the output transfer characteristics.
+
+Default is bt709.
+
+@item matrix, m
+Set the output colorspace matrix.
+
+Default is same as input.
+
+@end table
+
+@subsection Example
+
+@itemize
+@item
+Convert HDR(HDR10) video to bt2020-transfer-characteristic p010 format
+@example
+-i INPUT -vf "hwupload,tonemap_vaapi=format=p010:t=bt2020-10,hwdownload" OUTPUT
+@end example
+@end itemize
+
+@c man end VAAPI VIDEO FILTERS
+
@chapter Video Sources
@c man begin VIDEO SOURCES
diff
[FFmpeg-devel] [PATCH] lavc/libx264: enable the PC(2^n -1) colorspace in libx264rgb
From: Jun Zhao enable the PC(2^n -1) colorspace in libx264rgb fix #8404 Signed-off-by: Jun Zhao --- libavcodec/libx264.c |5 + 1 files changed, 5 insertions(+), 0 deletions(-) diff --git a/libavcodec/libx264.c b/libavcodec/libx264.c index bfd91bb..60607ca 100644 --- a/libavcodec/libx264.c +++ b/libavcodec/libx264.c @@ -867,6 +867,11 @@ FF_ENABLE_DEPRECATION_WARNINGS x4->params.vui.b_fullrange = avctx->pix_fmt == AV_PIX_FMT_YUVJ420P || avctx->pix_fmt == AV_PIX_FMT_YUVJ422P || avctx->pix_fmt == AV_PIX_FMT_YUVJ444P || +#if CONFIG_LIBX264RGB_ENCODER + avctx->pix_fmt == AV_PIX_FMT_BGR0 || + avctx->pix_fmt == AV_PIX_FMT_BGR24 || + avctx->pix_fmt == AV_PIX_FMT_RGB24 || +#endif avctx->color_range == AVCOL_RANGE_JPEG; if (avctx->colorspace != AVCOL_SPC_UNSPECIFIED) -- 1.7.1 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH] lavc/libx264: enable the PC(2^n -1) colorspace in libx264rgb
From: Jun Zhao enable the PC(2^n -1) colorspace in libx264rgb fix #8404 Signed-off-by: Jun Zhao --- libavcodec/libx264.c |5 + 1 files changed, 5 insertions(+), 0 deletions(-) diff --git a/libavcodec/libx264.c b/libavcodec/libx264.c index bfd91bb..60607ca 100644 --- a/libavcodec/libx264.c +++ b/libavcodec/libx264.c @@ -867,6 +867,11 @@ FF_ENABLE_DEPRECATION_WARNINGS x4->params.vui.b_fullrange = avctx->pix_fmt == AV_PIX_FMT_YUVJ420P || avctx->pix_fmt == AV_PIX_FMT_YUVJ422P || avctx->pix_fmt == AV_PIX_FMT_YUVJ444P || +#if CONFIG_LIBX264RGB_ENCODER + avctx->pix_fmt == AV_PIX_FMT_BGR0 || + avctx->pix_fmt == AV_PIX_FMT_BGR24 || + avctx->pix_fmt == AV_PIX_FMT_RGB24 || +#endif avctx->color_range == AVCOL_RANGE_JPEG; if (avctx->colorspace != AVCOL_SPC_UNSPECIFIED) -- 1.7.1 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH v2] avfilter: Add tonemap vaapi filter for H2S
Am Mi., 27. Nov. 2019 um 10:51 Uhr schrieb Xinpeng Sun :
>
> It performs HDR(High Dynamic Range) to SDR(Standard Dynamic Range) conversion
> with tone-mapping. It only supports HDR10 as input temporarily.
>
> An example command to use this filter with vaapi codecs:
> FFMPEG -hwaccel vaapi -vaapi_device /dev/dri/renderD128
> -hwaccel_output_format vaapi \
> -i INPUT -vf 'tonemap_vaapi=format=p010' -c:v hevc_vaapi -profile 2 OUTPUT
Why is HDR10 -> P010 (10bit -> 10 bit) called H2S?
[...]
> +if (input_frame->color_trc != AVCOL_TRC_SMPTE2084) {
> +av_log(avctx, AV_LOG_ERROR, "Only support HDR10 as input for vaapi
> tone-mapping\n");
> +return AVERROR(EINVAL);
Shouldn't this also accept unknown trc?
(With a warning)
[...]
> +{ "format", "Output pixel format set", OFFSET(output_format_string),
> AV_OPT_TYPE_STRING, .flags = FLAGS, "format" },
Sorry if I misremember how this is done for other filters:
Shouldn't the output format be set by the filter chain or the format filter?
Carl Eugen
___
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] avfilter/vf_libvmaf: Check for av_frame_alloc failure
On Wed, Nov 27, 2019 at 11:09:23AM +0100, Nikola Pajkovsky wrote: > lance.lmw...@gmail.com writes: > > > From: Limin Wang > > > > Reviewed-by: Paul B Mahol > > Signed-off-by: Limin Wang > > --- > > Add Reviewed-by:, pleae help push it > > > > libavfilter/vf_libvmaf.c | 3 +++ > > 1 file changed, 3 insertions(+) > > > > diff --git a/libavfilter/vf_libvmaf.c b/libavfilter/vf_libvmaf.c > > index ed3a383..14c3216 100644 > > --- a/libavfilter/vf_libvmaf.c > > +++ b/libavfilter/vf_libvmaf.c > > @@ -235,6 +235,9 @@ static av_cold int init(AVFilterContext *ctx) > > > > s->gref = av_frame_alloc(); > > s->gmain = av_frame_alloc(); > > +if (!s->gref || !s->gmain) > > +return AVERROR(ENOMEM); > > + > > When av_frame_alloc() return allocated memory for s->gref and > av_frame_alloc() fails for s->gmain, it will leak memory for s->gref. > > Correct code is: > > s->gref = av_frame_alloc(); > if (!s->gref) > return AVERROR(ENOMEM); > > s->gmain = av_frame_alloc(); > if (!s->gmain) > return AVERROR(ENOMEM); Thank for your review, I recall they'll be freed in uninit function, so my patch looks simple. > > -- > Nikola ___ 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] avfilter/vf_libvmaf: Check for av_frame_alloc failure
On 11/27/19, Limin Wang wrote: > On Wed, Nov 27, 2019 at 11:09:23AM +0100, Nikola Pajkovsky wrote: >> lance.lmw...@gmail.com writes: >> >> > From: Limin Wang >> > >> > Reviewed-by: Paul B Mahol >> > Signed-off-by: Limin Wang >> > --- >> > Add Reviewed-by:, pleae help push it >> > >> > libavfilter/vf_libvmaf.c | 3 +++ >> > 1 file changed, 3 insertions(+) >> > >> > diff --git a/libavfilter/vf_libvmaf.c b/libavfilter/vf_libvmaf.c >> > index ed3a383..14c3216 100644 >> > --- a/libavfilter/vf_libvmaf.c >> > +++ b/libavfilter/vf_libvmaf.c >> > @@ -235,6 +235,9 @@ static av_cold int init(AVFilterContext *ctx) >> > >> > s->gref = av_frame_alloc(); >> > s->gmain = av_frame_alloc(); >> > +if (!s->gref || !s->gmain) >> > +return AVERROR(ENOMEM); >> > + >> >> When av_frame_alloc() return allocated memory for s->gref and >> av_frame_alloc() fails for s->gmain, it will leak memory for s->gref. >> >> Correct code is: >> >> s->gref = av_frame_alloc(); >> if (!s->gref) >> return AVERROR(ENOMEM); >> >> s->gmain = av_frame_alloc(); >> if (!s->gmain) >> return AVERROR(ENOMEM); > > Thank for your review, I recall they'll be freed in uninit function, so > my patch looks simple. > Yes, patch should be applied as is. > >> >> -- >> Nikola > ___ > 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 v1 2/2] avfilter/vf_colorconstancy: av_frame_free(&in) in case of error or direct flag is false
From: Limin Wang
Signed-off-by: Limin Wang
---
libavfilter/vf_colorconstancy.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/libavfilter/vf_colorconstancy.c b/libavfilter/vf_colorconstancy.c
index cc081e957f..9917d8993e 100644
--- a/libavfilter/vf_colorconstancy.c
+++ b/libavfilter/vf_colorconstancy.c
@@ -682,13 +682,16 @@ static int filter_frame(AVFilterLink *inlink, AVFrame *in)
AVFilterLink *outlink = ctx->outputs[0];
AVFrame *out;
int ret;
+int direct = 0;
ret = illumination_estimation(ctx, in);
if (ret) {
+av_frame_free(&in);
return ret;
}
if (av_frame_is_writable(in)) {
+direct = 1;
out = in;
} else {
out = ff_get_video_buffer(outlink, outlink->w, outlink->h);
@@ -700,6 +703,9 @@ static int filter_frame(AVFilterLink *inlink, AVFrame *in)
}
chromatic_adaptation(ctx, in, out);
+if (!direct)
+av_frame_free(&in);
+
return ff_filter_frame(outlink, out);
}
--
2.21.0
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH v1 2/2] avfilter/vf_colorconstancy: av_frame_free(&in) in case of error or direct flag is false
lgtm
On 11/27/19, lance.lmw...@gmail.com wrote:
> From: Limin Wang
>
> Signed-off-by: Limin Wang
> ---
> libavfilter/vf_colorconstancy.c | 6 ++
> 1 file changed, 6 insertions(+)
>
> diff --git a/libavfilter/vf_colorconstancy.c
> b/libavfilter/vf_colorconstancy.c
> index cc081e957f..9917d8993e 100644
> --- a/libavfilter/vf_colorconstancy.c
> +++ b/libavfilter/vf_colorconstancy.c
> @@ -682,13 +682,16 @@ static int filter_frame(AVFilterLink *inlink, AVFrame
> *in)
> AVFilterLink *outlink = ctx->outputs[0];
> AVFrame *out;
> int ret;
> +int direct = 0;
>
> ret = illumination_estimation(ctx, in);
> if (ret) {
> +av_frame_free(&in);
> return ret;
> }
>
> if (av_frame_is_writable(in)) {
> +direct = 1;
> out = in;
> } else {
> out = ff_get_video_buffer(outlink, outlink->w, outlink->h);
> @@ -700,6 +703,9 @@ static int filter_frame(AVFilterLink *inlink, AVFrame
> *in)
> }
> chromatic_adaptation(ctx, in, out);
>
> +if (!direct)
> +av_frame_free(&in);
> +
> return ff_filter_frame(outlink, out);
> }
>
> --
> 2.21.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 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 1/2] avfilter/vf_colormatrix: av_frame_free(&in) in case of error
From: Limin Wang Signed-off-by: Limin Wang --- libavfilter/vf_colormatrix.c | 1 + 1 file changed, 1 insertion(+) diff --git a/libavfilter/vf_colormatrix.c b/libavfilter/vf_colormatrix.c index 3a02e2b86e..3a0c3f01da 100644 --- a/libavfilter/vf_colormatrix.c +++ b/libavfilter/vf_colormatrix.c @@ -448,6 +448,7 @@ static int filter_frame(AVFilterLink *link, AVFrame *in) case AVCOL_SPC_BT2020_CL : source = COLOR_MODE_BT2020; break; default : av_log(ctx, AV_LOG_ERROR, "Input frame does not specify a supported colorspace, and none has been specified as source either\n"); +av_frame_free(&in); av_frame_free(&out); return AVERROR(EINVAL); } -- 2.21.0 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] lavc/libx264: enable the PC(2^n -1) colorspace in libx264rgb
> Am 27.11.2019 um 10:52 schrieb Jun Zhao : > > From: Jun Zhao > > enable the PC(2^n -1) colorspace in libx264rgb > > fix #8404 > > Signed-off-by: Jun Zhao > --- > libavcodec/libx264.c |5 + > 1 files changed, 5 insertions(+), 0 deletions(-) > > diff --git a/libavcodec/libx264.c b/libavcodec/libx264.c > index bfd91bb..60607ca 100644 > --- a/libavcodec/libx264.c > +++ b/libavcodec/libx264.c > @@ -867,6 +867,11 @@ FF_ENABLE_DEPRECATION_WARNINGS > x4->params.vui.b_fullrange = avctx->pix_fmt == AV_PIX_FMT_YUVJ420P || > avctx->pix_fmt == AV_PIX_FMT_YUVJ422P || > avctx->pix_fmt == AV_PIX_FMT_YUVJ444P || > +#if CONFIG_LIBX264RGB_ENCODER The #if looks unneeded... > + avctx->pix_fmt == AV_PIX_FMT_BGR0 || > + avctx->pix_fmt == AV_PIX_FMT_BGR24 || > + avctx->pix_fmt == AV_PIX_FMT_RGB24 || ... but why don’t you check for the actually used encoder instead? Also, you may have to check that the range wasn’t explicitly set to mpeg. > +#endif > avctx->color_range == AVCOL_RANGE_JPEG; Carl Eugen ___ 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] doc/demuxers: correct grammatical errors of m3u8_hold_counters option
> 在 2019年11月27日，15:44，Gyan 写道： > > > > On 27-11-2019 11:33 am, Steven Liu wrote: >> Suggested-by: Rodney Baker >> Signed-off-by: Steven Liu >> --- >> doc/demuxers.texi | 2 +- >> 1 file changed, 1 insertion(+), 1 deletion(-) >> >> diff --git a/doc/demuxers.texi b/doc/demuxers.texi >> index 4e1a5cb6aa..0d13bdd1b3 100644 >> --- a/doc/demuxers.texi >> +++ b/doc/demuxers.texi >> @@ -332,7 +332,7 @@ Maximum number of times a insufficient list is attempted >> to be reloaded. >> Default value is 1000. >>@item m3u8_hold_counters >> -Maximum number of times to load m3u8 when the m3u8 dose not refresh with >> new segments. >> +The maximum number of times to load m3u8 when it refreshes without new >> segments. >> Default value is 1000. >>@item http_persistent > > LGTM. > > Suggest you change the description to this in the AVOption as well. fixed locally and pushed. commit id: afee801276d5aea66057aa9d4d37a13cf7ae7372 > > 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". Thanks Steven ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] lavc/libx264: enable the PC(2^n -1) colorspace in libx264rgb
On Wed, Nov 27, 2019 at 6:58 PM Carl Eugen Hoyos wrote: > > > > > Am 27.11.2019 um 10:52 schrieb Jun Zhao : > > > > From: Jun Zhao > > > > enable the PC(2^n -1) colorspace in libx264rgb > > > > fix #8404 > > > > Signed-off-by: Jun Zhao > > --- > > libavcodec/libx264.c |5 + > > 1 files changed, 5 insertions(+), 0 deletions(-) > > > > diff --git a/libavcodec/libx264.c b/libavcodec/libx264.c > > index bfd91bb..60607ca 100644 > > --- a/libavcodec/libx264.c > > +++ b/libavcodec/libx264.c > > @@ -867,6 +867,11 @@ FF_ENABLE_DEPRECATION_WARNINGS > > x4->params.vui.b_fullrange = avctx->pix_fmt == AV_PIX_FMT_YUVJ420P || > > avctx->pix_fmt == AV_PIX_FMT_YUVJ422P || > > avctx->pix_fmt == AV_PIX_FMT_YUVJ444P || > > > +#if CONFIG_LIBX264RGB_ENCODER > > The #if looks unneeded... I perfer to keep the #if like another part for libx264rgb warpper > > > > + avctx->pix_fmt == AV_PIX_FMT_BGR0 || > > + avctx->pix_fmt == AV_PIX_FMT_BGR24 || > > + avctx->pix_fmt == AV_PIX_FMT_RGB24 || > > ... but why don’t you check for the actually used encoder instead? I don't know is it good idear to check the actually used encoder in the encoder warpper > > > Also, you may have to check that the range wasn’t explicitly set to mpeg. Will add the range check, tks > > > > +#endif > > avctx->color_range == AVCOL_RANGE_JPEG; > ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH 1/7] avformat/aviobuf: Avoid allocating buffer when using dynamic buffer
Up until now, using a dynamic buffer entailed at least three
allocations: One for the AVIOContext, one for the AVIOContext's opaque
(which, among other things, contains the small write buffer), and one
for the big buffer that is independently allocated that is returned when
calling avio_close_dyn_buf().
It is possible to avoid the third allocation if one doesn't use a
packetized dynamic buffer, if all the data written so far fit into the
write buffer and if one does not require the actual (big) buffer to have
an indefinite lifetime. This is done by making avio_get_dyn_buf() return
a pointer to the data in the write buffer if nothing has been written to
the main buffer yet. The dynamic buffer will then be freed using
ffio_free_dynamic_buffer (which needed to be modified not to call
avio_close_dyn_buf() internally).
So a typical use-case like:
size = avio_close_dyn_buf(dyn_pb, &buf);
do something with buf
av_free(buf);
can be converted to:
size = avio_get_dyn_buf(dyn_pb, &buf);
do something with buf
ffio_free_dynamic_buffer(&dyn_pb);
In more complex scenarios this can simplify freeing as well, because it
is now clear that freeing always has to be performed via
ffio_free_dynamic_buffer().
Of course, in case this saves an allocation it also saves a memcpy.
Signed-off-by: Andreas Rheinhardt
---
libavformat/aviobuf.c | 20 ++--
1 file changed, 14 insertions(+), 6 deletions(-)
diff --git a/libavformat/aviobuf.c b/libavformat/aviobuf.c
index 2dfce8af8b..70e1d2ca10 100644
--- a/libavformat/aviobuf.c
+++ b/libavformat/aviobuf.c
@@ -1443,14 +1443,19 @@ int avio_get_dyn_buf(AVIOContext *s, uint8_t **pbuffer)
{
DynBuffer *d;
-if (!s) {
+if (!s || s->error) {
*pbuffer = NULL;
return 0;
}
+d = s->opaque;
+
+if (!d->size) {
+*pbuffer = d->io_buffer;
+return FFMAX(s->buf_ptr, s->buf_ptr_max) - s->buffer;
+}
avio_flush(s);
-d = s->opaque;
*pbuffer = d->buffer;
return d->size;
@@ -1488,12 +1493,15 @@ int avio_close_dyn_buf(AVIOContext *s, uint8_t
**pbuffer)
void ffio_free_dyn_buf(AVIOContext **s)
{
-uint8_t *tmp;
+DynBuffer *d;
+
if (!*s)
return;
-avio_close_dyn_buf(*s, &tmp);
-av_free(tmp);
-*s = NULL;
+
+d = (*s)->opaque;
+av_free(d->buffer);
+av_free(d);
+avio_context_free(s);
}
static int null_buf_write(void *opaque, uint8_t *buf, int buf_size)
--
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 2/7] avformat/apetag: Avoid allocation for small tags
By using avio_get_dyn_buf() + ffio_free_dyn_buf() instead of
avio_close_dyn_buf() + av_free() one can avoid an allocation + copy for
small tags. Furthermore, it simplifies freeing.
Signed-off-by: Andreas Rheinhardt
---
libavformat/apetag.c | 12 +---
1 file changed, 5 insertions(+), 7 deletions(-)
diff --git a/libavformat/apetag.c b/libavformat/apetag.c
index 8cb3f4a23a..4e19f49bf1 100644
--- a/libavformat/apetag.c
+++ b/libavformat/apetag.c
@@ -186,11 +186,11 @@ int ff_ape_write_tag(AVFormatContext *s)
{
AVDictionaryEntry *e = NULL;
int size, ret, count = 0;
-AVIOContext *dyn_bc = NULL;
-uint8_t *dyn_buf = NULL;
+AVIOContext *dyn_bc;
+uint8_t *dyn_buf;
if ((ret = avio_open_dyn_buf(&dyn_bc)) < 0)
-goto end;
+return ret;
ff_standardize_creation_time(s);
while ((e = av_dict_get(s->metadata, "", e, AV_DICT_IGNORE_SUFFIX))) {
@@ -211,7 +211,7 @@ int ff_ape_write_tag(AVFormatContext *s)
if (!count)
goto end;
-size = avio_close_dyn_buf(dyn_bc, &dyn_buf);
+size = avio_get_dyn_buf(dyn_bc, &dyn_buf);
if (size <= 0)
goto end;
size += APE_TAG_FOOTER_BYTES;
@@ -239,9 +239,7 @@ int ff_ape_write_tag(AVFormatContext *s)
ffio_fill(s->pb, 0, 8); // reserved
end:
-if (dyn_bc && !dyn_buf)
-avio_close_dyn_buf(dyn_bc, &dyn_buf);
-av_freep(&dyn_buf);
+ffio_free_dyn_buf(&dyn_bc);
return ret;
}
--
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 3/7] avformat/av1: Avoid allocation for small headers
By using avio_get_dyn_buf() + ffio_free_dyn_buf() instead of
avio_close_dyn_buf() + av_free() one can avoid an allocation + copy for
small headers. Furthermore, it simplifies freeing.
Signed-off-by: Andreas Rheinhardt
---
libavformat/av1.c | 14 +-
1 file changed, 5 insertions(+), 9 deletions(-)
diff --git a/libavformat/av1.c b/libavformat/av1.c
index 03669dfd2a..132f4e987b 100644
--- a/libavformat/av1.c
+++ b/libavformat/av1.c
@@ -326,7 +326,7 @@ int ff_isom_write_av1c(AVIOContext *pb, const uint8_t *buf,
int size)
AV1SequenceParameters seq_params;
PutBitContext pbc;
uint8_t header[4];
-uint8_t *seq = NULL, *meta = NULL;
+uint8_t *seq, *meta;
int64_t obu_size;
int start_pos, type, temporal_id, spatial_id;
int ret, nb_seq = 0, seq_size, meta_size;
@@ -376,7 +376,7 @@ int ff_isom_write_av1c(AVIOContext *pb, const uint8_t *buf,
int size)
buf += len;
}
-seq_size = avio_close_dyn_buf(seq_pb, &seq);
+seq_size = avio_get_dyn_buf(seq_pb, &seq);
if (!seq_size) {
ret = AVERROR_INVALIDDATA;
goto fail;
@@ -401,17 +401,13 @@ int ff_isom_write_av1c(AVIOContext *pb, const uint8_t
*buf, int size)
avio_write(pb, header, sizeof(header));
avio_write(pb, seq, seq_size);
-meta_size = avio_close_dyn_buf(meta_pb, &meta);
+meta_size = avio_get_dyn_buf(meta_pb, &meta);
if (meta_size)
avio_write(pb, meta, meta_size);
fail:
-if (!seq)
-avio_close_dyn_buf(seq_pb, &seq);
-if (!meta)
-avio_close_dyn_buf(meta_pb, &meta);
-av_free(seq);
-av_free(meta);
+ffio_free_dyn_buf(&seq_pb);
+ffio_free_dyn_buf(&meta_pb);
return ret;
}
--
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 4/7] avformat/avc: Avoid allocation for small SPS/PPS arrays
By using avio_get_dyn_buf() + ffio_free_dyn_buf() instead of
avio_close_dyn_buf() + av_free() one can avoid an allocation + copy for
small extradata. Furthermore, it simplifies freeing.
Signed-off-by: Andreas Rheinhardt
---
libavformat/avc.c | 15 ++-
1 file changed, 6 insertions(+), 9 deletions(-)
diff --git a/libavformat/avc.c b/libavformat/avc.c
index a041e84357..7f9d81825b 100644
--- a/libavformat/avc.c
+++ b/libavformat/avc.c
@@ -25,6 +25,7 @@
#include "avformat.h"
#include "avio.h"
#include "avc.h"
+#include "avio_internal.h"
static const uint8_t *ff_avc_find_startcode_internal(const uint8_t *p, const
uint8_t *end)
{
@@ -109,7 +110,7 @@ int ff_isom_write_avcc(AVIOContext *pb, const uint8_t
*data, int len)
{
AVIOContext *sps_pb = NULL, *pps_pb = NULL;
uint8_t *buf = NULL, *end, *start = NULL;
-uint8_t *sps = NULL, *pps = NULL;
+uint8_t *sps, *pps;
uint32_t sps_size = 0, pps_size = 0;
int ret, nb_sps = 0, nb_pps = 0;
@@ -164,8 +165,8 @@ int ff_isom_write_avcc(AVIOContext *pb, const uint8_t
*data, int len)
buf += size;
}
-sps_size = avio_close_dyn_buf(sps_pb, &sps);
-pps_size = avio_close_dyn_buf(pps_pb, &pps);
+sps_size = avio_get_dyn_buf(sps_pb, &sps);
+pps_size = avio_get_dyn_buf(pps_pb, &pps);
if (sps_size < 6 || !pps_size) {
ret = AVERROR_INVALIDDATA;
@@ -184,12 +185,8 @@ int ff_isom_write_avcc(AVIOContext *pb, const uint8_t
*data, int len)
avio_write(pb, pps, pps_size);
fail:
-if (!sps)
-avio_close_dyn_buf(sps_pb, &sps);
-if (!pps)
-avio_close_dyn_buf(pps_pb, &pps);
-av_free(sps);
-av_free(pps);
+ffio_free_dyn_buf(&sps_pb);
+ffio_free_dyn_buf(&pps_pb);
av_free(start);
return ret;
--
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 5/7] avformat/id3v2enc: Avoid allocation for small tags
By using avio_get_dyn_buf() + ffio_free_dyn_buf() instead of
avio_close_dyn_buf() + av_free() one can avoid an allocation + copy for
small tags. Furthermore, it simplifies freeing.
Signed-off-by: Andreas Rheinhardt
---
libavformat/id3v2enc.c | 37 -
1 file changed, 16 insertions(+), 21 deletions(-)
diff --git a/libavformat/id3v2enc.c b/libavformat/id3v2enc.c
index c13b93a7d8..9040501869 100644
--- a/libavformat/id3v2enc.c
+++ b/libavformat/id3v2enc.c
@@ -81,7 +81,7 @@ static int id3v2_put_ttag(ID3v2EncContext *id3, AVIOContext
*avioc, const char *
id3v2_encode_string(dyn_buf, str1, enc);
if (str2)
id3v2_encode_string(dyn_buf, str2, enc);
-len = avio_close_dyn_buf(dyn_buf, &pb);
+len = avio_get_dyn_buf(dyn_buf, &pb);
avio_wb32(avioc, tag);
/* ID3v2.3 frame size is not sync-safe */
@@ -92,7 +92,7 @@ static int id3v2_put_ttag(ID3v2EncContext *id3, AVIOContext
*avioc, const char *
avio_wb16(avioc, 0);
avio_write(avioc, pb, len);
-av_freep(&pb);
+ffio_free_dyn_buf(&dyn_buf);
return len + ID3v2_HEADER_SIZE;
}
@@ -134,7 +134,7 @@ static int id3v2_put_priv(ID3v2EncContext *id3, AVIOContext
*avioc, const char *
}
}
-len = avio_close_dyn_buf(dyn_buf, &pb);
+len = avio_get_dyn_buf(dyn_buf, &pb);
avio_wb32(avioc, MKBETAG('P', 'R', 'I', 'V'));
if (id3->version == 3)
@@ -144,7 +144,7 @@ static int id3v2_put_priv(ID3v2EncContext *id3, AVIOContext
*avioc, const char *
avio_wb16(avioc, 0);
avio_write(avioc, pb, len);
-av_free(pb);
+ffio_free_dyn_buf(&dyn_buf);
return len + ID3v2_HEADER_SIZE;
}
@@ -257,8 +257,8 @@ static int write_metadata(AVIOContext *pb, AVDictionary
**metadata,
static int write_ctoc(AVFormatContext *s, ID3v2EncContext *id3, int enc)
{
-uint8_t *dyn_buf = NULL;
-AVIOContext *dyn_bc = NULL;
+uint8_t *dyn_buf;
+AVIOContext *dyn_bc;
char name[123];
int len, ret;
@@ -266,7 +266,7 @@ static int write_ctoc(AVFormatContext *s, ID3v2EncContext
*id3, int enc)
return 0;
if ((ret = avio_open_dyn_buf(&dyn_bc)) < 0)
-goto fail;
+return ret;
id3->len += avio_put_str(dyn_bc, "toc");
avio_w8(dyn_bc, 0x03);
@@ -275,7 +275,7 @@ static int write_ctoc(AVFormatContext *s, ID3v2EncContext
*id3, int enc)
snprintf(name, 122, "ch%d", i);
id3->len += avio_put_str(dyn_bc, name);
}
-len = avio_close_dyn_buf(dyn_bc, &dyn_buf);
+len = avio_get_dyn_buf(dyn_bc, &dyn_buf);
id3->len += 16 + ID3v2_HEADER_SIZE;
avio_wb32(s->pb, MKBETAG('C', 'T', 'O', 'C'));
@@ -283,10 +283,7 @@ static int write_ctoc(AVFormatContext *s, ID3v2EncContext
*id3, int enc)
avio_wb16(s->pb, 0);
avio_write(s->pb, dyn_buf, len);
-fail:
-if (dyn_bc && !dyn_buf)
-avio_close_dyn_buf(dyn_bc, &dyn_buf);
-av_freep(&dyn_buf);
+ffio_free_dyn_buf(&dyn_bc);
return ret;
}
@@ -295,13 +292,13 @@ static int write_chapter(AVFormatContext *s,
ID3v2EncContext *id3, int id, int e
{
const AVRational time_base = {1, 1000};
AVChapter *ch = s->chapters[id];
-uint8_t *dyn_buf = NULL;
-AVIOContext *dyn_bc = NULL;
+uint8_t *dyn_buf;
+AVIOContext *dyn_bc;
char name[123];
int len, start, end, ret;
if ((ret = avio_open_dyn_buf(&dyn_bc)) < 0)
-goto fail;
+return ret;
start = av_rescale_q(ch->start, ch->time_base, time_base);
end = av_rescale_q(ch->end, ch->time_base, time_base);
@@ -316,7 +313,7 @@ static int write_chapter(AVFormatContext *s,
ID3v2EncContext *id3, int id, int e
if ((ret = write_metadata(dyn_bc, &ch->metadata, id3, enc)) < 0)
goto fail;
-len = avio_close_dyn_buf(dyn_bc, &dyn_buf);
+len = avio_get_dyn_buf(dyn_bc, &dyn_buf);
id3->len += 16 + ID3v2_HEADER_SIZE;
avio_wb32(s->pb, MKBETAG('C', 'H', 'A', 'P'));
@@ -325,9 +322,7 @@ static int write_chapter(AVFormatContext *s,
ID3v2EncContext *id3, int id, int e
avio_write(s->pb, dyn_buf, len);
fail:
-if (dyn_bc && !dyn_buf)
-avio_close_dyn_buf(dyn_bc, &dyn_buf);
-av_freep(&dyn_buf);
+ffio_free_dyn_buf(&dyn_bc);
return ret;
}
@@ -406,7 +401,7 @@ int ff_id3v2_write_apic(AVFormatContext *s, ID3v2EncContext
*id3, AVPacket *pkt)
avio_w8(dyn_buf, type);
id3v2_encode_string(dyn_buf, desc, enc);
avio_write(dyn_buf, pkt->data, pkt->size);
-len = avio_close_dyn_buf(dyn_buf, &buf);
+len = avio_get_dyn_buf(dyn_buf, &buf);
avio_wb32(s->pb, MKBETAG('A', 'P', 'I', 'C'));
if (id3->version == 3)
@@ -415,7 +410,7 @@ int ff_id3v2_write_apic(AVFormatContext *s, ID3v2EncContext
*id3, AVPacket *pkt)
id3v2_put_size(s->pb, len);
avio_wb16(s->pb, 0);
avio_write(s->pb, buf, len);
-av_freep(&buf);
+ffio_free_dyn_buf(&dyn_buf);
id3->len += len + ID3v2_HEADER_SIZE;
--
2.20.1
__
[FFmpeg-devel] [PATCH 6/7] avformat/matroskaenc: Avoid allocation for small dynamic buffers
By using avio_get_dyn_buf() + ffio_free_dyn_buf() instead of
avio_close_dyn_buf() + av_free() one can avoid an allocation + copy for
small dynamic buffers (i.e. small master elements).
Signed-off-by: Andreas Rheinhardt
---
libavformat/matroskaenc.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/libavformat/matroskaenc.c b/libavformat/matroskaenc.c
index a38ce4325d..570f361351 100644
--- a/libavformat/matroskaenc.c
+++ b/libavformat/matroskaenc.c
@@ -845,11 +845,11 @@ static int mkv_write_codecprivate(AVFormatContext *s,
AVIOContext *pb,
ff_put_wav_header(s, dyn_cp, par,
FF_PUT_WAV_HEADER_FORCE_WAVEFORMATEX);
}
-codecpriv_size = avio_close_dyn_buf(dyn_cp, &codecpriv);
+codecpriv_size = avio_get_dyn_buf(dyn_cp, &codecpriv);
if (codecpriv_size)
put_ebml_binary(pb, MATROSKA_ID_CODECPRIVATE, codecpriv,
codecpriv_size);
-av_free(codecpriv);
+ffio_free_dyn_buf(&dyn_cp);
return ret;
}
@@ -933,13 +933,13 @@ static int mkv_write_video_color(AVIOContext *pb,
AVCodecParameters *par, AVStre
end_ebml_master(dyn_cp, meta_element);
}
-colorinfo_size = avio_close_dyn_buf(dyn_cp, &colorinfo_ptr);
+colorinfo_size = avio_get_dyn_buf(dyn_cp, &colorinfo_ptr);
if (colorinfo_size) {
ebml_master colorinfo = start_ebml_master(pb, MATROSKA_ID_VIDEOCOLOR,
colorinfo_size);
avio_write(pb, colorinfo_ptr, colorinfo_size);
end_ebml_master(pb, colorinfo);
}
-av_free(colorinfo_ptr);
+ffio_free_dyn_buf(&dyn_cp);
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".
[FFmpeg-devel] [PATCH 7/7] avformat/movenc: Avoid allocation for small dynamic buffers
By using avio_get_dyn_buf() + ffio_free_dyn_buf() instead of
avio_close_dyn_buf() + av_free() one can avoid an allocation + copy for
small dynamic buffers.
Signed-off-by: Andreas Rheinhardt
---
libavformat/movenc.c | 18 --
1 file changed, 8 insertions(+), 10 deletions(-)
diff --git a/libavformat/movenc.c b/libavformat/movenc.c
index 715bec1c2f..dd144ae20a 100644
--- a/libavformat/movenc.c
+++ b/libavformat/movenc.c
@@ -3145,12 +3145,12 @@ static int mov_write_track_udta_tag(AVIOContext *pb,
MOVMuxContext *mov,
if (mov->mode & (MODE_MP4|MODE_MOV))
mov_write_track_metadata(pb_buf, st, "name", "title");
-if ((size = avio_close_dyn_buf(pb_buf, &buf)) > 0) {
+if ((size = avio_get_dyn_buf(pb_buf, &buf)) > 0) {
avio_wb32(pb, size + 8);
ffio_wfourcc(pb, "udta");
avio_write(pb, buf, size);
}
-av_free(buf);
+ffio_free_dyn_buf(&pb_buf);
return 0;
}
@@ -3820,12 +3820,12 @@ static int mov_write_udta_tag(AVIOContext *pb,
MOVMuxContext *mov,
if (s->nb_chapters && !(mov->flags & FF_MOV_FLAG_DISABLE_CHPL))
mov_write_chpl_tag(pb_buf, s);
-if ((size = avio_close_dyn_buf(pb_buf, &buf)) > 0) {
+if ((size = avio_get_dyn_buf(pb_buf, &buf)) > 0) {
avio_wb32(pb, size + 8);
ffio_wfourcc(pb, "udta");
avio_write(pb, buf, size);
}
-av_free(buf);
+ffio_free_dyn_buf(&pb_buf);
return 0;
}
@@ -5033,12 +5033,11 @@ static int
mov_flush_fragment_interleaving(AVFormatContext *s, MOVTrack *track)
if ((ret = avio_open_dyn_buf(&mov->mdat_buf)) < 0)
return ret;
}
-buf_size = avio_close_dyn_buf(track->mdat_buf, &buf);
-track->mdat_buf = NULL;
+buf_size = avio_get_dyn_buf(track->mdat_buf, &buf);
offset = avio_tell(mov->mdat_buf);
avio_write(mov->mdat_buf, buf, buf_size);
-av_free(buf);
+ffio_free_dyn_buf(&track->mdat_buf);
for (i = track->entries_flushed; i < track->entry; i++)
track->cluster[i].pos += offset;
@@ -5135,12 +5134,11 @@ static int mov_flush_fragment(AVFormatContext *s, int
force)
return 0;
}
-buf_size = avio_close_dyn_buf(mov->mdat_buf, &buf);
-mov->mdat_buf = NULL;
+buf_size = avio_get_dyn_buf(mov->mdat_buf, &buf);
avio_wb32(s->pb, buf_size + 8);
ffio_wfourcc(s->pb, "mdat");
avio_write(s->pb, buf, buf_size);
-av_free(buf);
+ffio_free_dyn_buf(&mov->mdat_buf);
if (mov->flags & FF_MOV_FLAG_GLOBAL_SIDX)
mov->reserved_header_pos = avio_tell(s->pb);
--
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 3/7] avformat/av1: Avoid allocation for small headers
On 11/27/2019 9:22 AM, Andreas Rheinhardt wrote:
> By using avio_get_dyn_buf() + ffio_free_dyn_buf() instead of
> avio_close_dyn_buf() + av_free() one can avoid an allocation + copy for
> small headers. Furthermore, it simplifies freeing.
>
> Signed-off-by: Andreas Rheinhardt
> ---
> libavformat/av1.c | 14 +-
> 1 file changed, 5 insertions(+), 9 deletions(-)
>
> diff --git a/libavformat/av1.c b/libavformat/av1.c
> index 03669dfd2a..132f4e987b 100644
> --- a/libavformat/av1.c
> +++ b/libavformat/av1.c
> @@ -326,7 +326,7 @@ int ff_isom_write_av1c(AVIOContext *pb, const uint8_t
> *buf, int size)
> AV1SequenceParameters seq_params;
> PutBitContext pbc;
> uint8_t header[4];
> -uint8_t *seq = NULL, *meta = NULL;
> +uint8_t *seq, *meta;
> int64_t obu_size;
> int start_pos, type, temporal_id, spatial_id;
> int ret, nb_seq = 0, seq_size, meta_size;
> @@ -376,7 +376,7 @@ int ff_isom_write_av1c(AVIOContext *pb, const uint8_t
> *buf, int size)
> buf += len;
> }
>
> -seq_size = avio_close_dyn_buf(seq_pb, &seq);
> +seq_size = avio_get_dyn_buf(seq_pb, &seq);
> if (!seq_size) {
> ret = AVERROR_INVALIDDATA;
> goto fail;
> @@ -401,17 +401,13 @@ int ff_isom_write_av1c(AVIOContext *pb, const uint8_t
> *buf, int size)
> avio_write(pb, header, sizeof(header));
> avio_write(pb, seq, seq_size);
>
> -meta_size = avio_close_dyn_buf(meta_pb, &meta);
> +meta_size = avio_get_dyn_buf(meta_pb, &meta);
> if (meta_size)
> avio_write(pb, meta, meta_size);
>
> fail:
> -if (!seq)
> -avio_close_dyn_buf(seq_pb, &seq);
> -if (!meta)
> -avio_close_dyn_buf(meta_pb, &meta);
> -av_free(seq);
> -av_free(meta);
> +ffio_free_dyn_buf(&seq_pb);
> +ffio_free_dyn_buf(&meta_pb);
>
> return ret;
> }
Ah, I had this written and queued for when i pushed my avcC patch with
your suggested changes, but will apply yours instead since you actually
sent it first.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] avformat/avc: write the missing bits in the AVC Decoder Configuration Box
On 11/26/2019 10:57 AM, Andreas Rheinhardt wrote:
> On Tue, Nov 26, 2019 at 2:07 PM James Almer wrote:
>
>> Signed-off-by: James Almer
>> ---
>> libavformat/avc.c | 38 +-
>> libavformat/avc.h | 1 +
>> 2 files changed, 34 insertions(+), 5 deletions(-)
>>
>> diff --git a/libavformat/avc.c b/libavformat/avc.c
>> index a041e84357..9bd215c07f 100644
>> --- a/libavformat/avc.c
>> +++ b/libavformat/avc.c
>> @@ -107,11 +107,11 @@ int ff_avc_parse_nal_units_buf(const uint8_t
>> *buf_in, uint8_t **buf, int *size)
>>
>> int ff_isom_write_avcc(AVIOContext *pb, const uint8_t *data, int len)
>> {
>> -AVIOContext *sps_pb = NULL, *pps_pb = NULL;
>> +AVIOContext *sps_pb = NULL, *pps_pb = NULL, *sps_ext_pb = NULL;
>> uint8_t *buf = NULL, *end, *start = NULL;
>> -uint8_t *sps = NULL, *pps = NULL;
>> -uint32_t sps_size = 0, pps_size = 0;
>> -int ret, nb_sps = 0, nb_pps = 0;
>> +uint8_t *sps = NULL, *pps = NULL, *sps_ext = NULL;
>> +uint32_t sps_size = 0, pps_size = 0, sps_ext_size = 0;
>> +int ret, nb_sps = 0, nb_pps = 0, nb_sps_ext = 0;
>>
>> if (len <= 6)
>> return AVERROR_INVALIDDATA;
>> @@ -133,6 +133,9 @@ int ff_isom_write_avcc(AVIOContext *pb, const uint8_t
>> *data, int len)
>> if (ret < 0)
>> goto fail;
>> ret = avio_open_dyn_buf(&pps_pb);
>> +if (ret < 0)
>> +goto fail;
>> +ret = avio_open_dyn_buf(&sps_ext_pb);
>> if (ret < 0)
>> goto fail;
>>
>> @@ -160,12 +163,21 @@ int ff_isom_write_avcc(AVIOContext *pb, const
>> uint8_t *data, int len)
>> }
>> avio_wb16(pps_pb, size);
>> avio_write(pps_pb, buf, size);
>> +} else if (nal_type == 13) { /* SPS_EXT */
>> +nb_sps_ext++;
>> +if (size > UINT16_MAX || nb_sps_ext >= 256) {
>> +ret = AVERROR_INVALIDDATA;
>> +goto fail;
>> +}
>> +avio_wb16(sps_ext_pb, size);
>> +avio_write(sps_ext_pb, buf, size);
>> }
>>
>> buf += size;
>> }
>> sps_size = avio_close_dyn_buf(sps_pb, &sps);
>> pps_size = avio_close_dyn_buf(pps_pb, &pps);
>> +sps_ext_size = avio_close_dyn_buf(sps_ext_pb, &sps_ext);
>>
>> if (sps_size < 6 || !pps_size) {
>> ret = AVERROR_INVALIDDATA;
>> @@ -183,13 +195,29 @@ int ff_isom_write_avcc(AVIOContext *pb, const
>> uint8_t *data, int len)
>> avio_w8(pb, nb_pps); /* number of pps */
>> avio_write(pb, pps, pps_size);
>>
>> +if (sps[3] != 66 && sps[3] != 77 && sps[3] != 88) {
>> +H264SequenceParameterSet *seq = ff_avc_decode_sps(sps, sps_size);
>> +if (!seq)
>> +goto fail;
>> +avio_w8(pb, 0xfc | seq->chroma_format_idc); /* 6 bits reserved
>> (11) + chroma_format_idc */
>> +avio_w8(pb, 0xf8 | seq->bit_depth_luma - 8); /* 5 bits reserved
>> (1) + bit_depth_luma_minus8 */
>> +avio_w8(pb, 0xf8 | seq->bit_depth_chroma - 8); /* 5 bits reserved
>> (1) + bit_depth_chroma_minus8 */
>> +avio_w8(pb, nb_sps_ext); /* number of sps ext */
>> +if (nb_sps_ext)
>> +avio_write(pb, sps_ext, sps_ext_size);
>> +av_free(seq);
>> +}
>> +
>> fail:
>> if (!sps)
>> avio_close_dyn_buf(sps_pb, &sps);
>> if (!pps)
>> avio_close_dyn_buf(pps_pb, &pps);
>> +if (!sps_ext)
>> +avio_close_dyn_buf(sps_ext_pb, &sps_ext);
>>
>
> I don't like how these buffers are freed. How about the following approach:
> You don't close the dynamic buffer above; instead you just call
> avio_get_dyn_buf(). And here on fail you use ffio_free_dyn_buf()
> unconditionally instead of these combinations of avio_close_dyn_buf() and
> av_free().
Ok, will change that and apply this soon.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 3/7] avformat/av1: Avoid allocation for small headers
On 11/27/2019 9:26 AM, James Almer wrote:
> On 11/27/2019 9:22 AM, Andreas Rheinhardt wrote:
>> By using avio_get_dyn_buf() + ffio_free_dyn_buf() instead of
>> avio_close_dyn_buf() + av_free() one can avoid an allocation + copy for
>> small headers. Furthermore, it simplifies freeing.
>>
>> Signed-off-by: Andreas Rheinhardt
>> ---
>> libavformat/av1.c | 14 +-
>> 1 file changed, 5 insertions(+), 9 deletions(-)
>>
>> diff --git a/libavformat/av1.c b/libavformat/av1.c
>> index 03669dfd2a..132f4e987b 100644
>> --- a/libavformat/av1.c
>> +++ b/libavformat/av1.c
>> @@ -326,7 +326,7 @@ int ff_isom_write_av1c(AVIOContext *pb, const uint8_t
>> *buf, int size)
>> AV1SequenceParameters seq_params;
>> PutBitContext pbc;
>> uint8_t header[4];
>> -uint8_t *seq = NULL, *meta = NULL;
>> +uint8_t *seq, *meta;
>> int64_t obu_size;
>> int start_pos, type, temporal_id, spatial_id;
>> int ret, nb_seq = 0, seq_size, meta_size;
>> @@ -376,7 +376,7 @@ int ff_isom_write_av1c(AVIOContext *pb, const uint8_t
>> *buf, int size)
>> buf += len;
>> }
>>
>> -seq_size = avio_close_dyn_buf(seq_pb, &seq);
>> +seq_size = avio_get_dyn_buf(seq_pb, &seq);
>> if (!seq_size) {
>> ret = AVERROR_INVALIDDATA;
>> goto fail;
>> @@ -401,17 +401,13 @@ int ff_isom_write_av1c(AVIOContext *pb, const uint8_t
>> *buf, int size)
>> avio_write(pb, header, sizeof(header));
>> avio_write(pb, seq, seq_size);
>>
>> -meta_size = avio_close_dyn_buf(meta_pb, &meta);
>> +meta_size = avio_get_dyn_buf(meta_pb, &meta);
>> if (meta_size)
>> avio_write(pb, meta, meta_size);
>>
>> fail:
>> -if (!seq)
>> -avio_close_dyn_buf(seq_pb, &seq);
>> -if (!meta)
>> -avio_close_dyn_buf(meta_pb, &meta);
>> -av_free(seq);
>> -av_free(meta);
>> +ffio_free_dyn_buf(&seq_pb);
>> +ffio_free_dyn_buf(&meta_pb);
>>
>> return ret;
>> }
>
> Ah, I had this written and queued for when i pushed my avcC patch with
> your suggested changes, but will apply yours instead since you actually
> sent it first.
And of course i reply to the wrong patch... Was talking about Patch 4/7.
___
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_convolution:Add x86 SIMD optimizations for filter_row()
From: Xu Jun
Tested using the following command:
./ffmpeg_g -s 1280*720 -pix_fmt yuv420p -i test.yuv -vf convolution="1 2 3 4 5\
6 7 8 9:1 2 3 4 5 6 7 8 9:1 2 3 4 5 6 7 8 9:1 2 3 4 5 6 7 8 9:1/45:1/45:1/45\
:1/45:1:2:3:4:row:row:row:row" -an -vframes 1000 -f null /dev/null
The fps increases from 297 to 780 on my local mechine.
Signed-off-by: Xu Jun
---
libavfilter/x86/vf_convolution.asm| 104 ++
libavfilter/x86/vf_convolution_init.c | 10 +++
2 files changed, 114 insertions(+)
mode change 100644 => 100755 libavfilter/x86/vf_convolution.asm
diff --git a/libavfilter/x86/vf_convolution.asm
b/libavfilter/x86/vf_convolution.asm
old mode 100644
new mode 100755
index 754d4d1064..b71e9720fb
--- a/libavfilter/x86/vf_convolution.asm
+++ b/libavfilter/x86/vf_convolution.asm
@@ -154,3 +154,107 @@ cglobal filter_3x3, 4, 15, 7, dst, width, rdiv, bias,
matrix, ptr, c0, c1, c2, c
INIT_XMM sse4
FILTER_3X3
%endif
+
+; void filter_row_sse4(uint8_t *dst, int width,
+; float rdiv, float bias, const int *const matrix,
+; const uint8_t *c[], int peak, int radius,
+; int dstride, int stride)
+%if ARCH_X86_64
+INIT_XMM sse4
+%if UNIX64
+cglobal filter_row, 6, 10, 7, dst, width, matrix, ptr, mult, rad, r, x, i, ci
+%else
+cglobal filter_row, 4, 10, 7, dst, width, rdiv, bias, matrix, ptr, mult, rad,
r, x, i, ci
+%endif
+
+%if WIN64
+SWAP m0, m2
+SWAP m1, m3
+mov r2q, matrixmp
+mov r3q, ptrmp
+mov r5q, radmp
+DEFINE_ARGS dst, width, matrix, ptr, mult, rad, r, x, i, ci
+%endif
+
+movsxdifnidn radq, radd
+sal radq, 1
+add radq, 1 ; 2*radius+1
+movsxdifnidn widthq, widthd
+VBROADCASTSS m0, m0
+VBROADCASTSS m1, m1
+pxor m6, m6
+movss m5, [half]
+VBROADCASTSS m5, m5
+
+xor xq, xq
+cmp widthq, mmsize/4
+jl .loop2
+
+mov rq, widthq
+and rq, mmsize/4-1
+sub widthq, rq
+
+.loop1:
+pxor m4, m4
+xor iq, iq
+.loop1_1:
+movss m2, [matrixq + 4*iq]
+VBROADCASTSS m2, m2
+mov ciq, [ptrq + iq * gprsize]
+movss m3, [ciq + xq]
+punpcklbw m3, m6
+punpcklwd m3, m6
+pmulld m2, m3
+paddd m4, m2
+
+add iq, 1
+cmp iq, radq
+jl .loop1_1
+
+cvtdq2ps m4, m4
+mulps m4, m0 ; sum *= rdiv
+addps m4, m1 ; sum += bias
+addps m4, m5 ; sum += 0.5
+cvttps2dq m4, m4
+packssdw m4, m4
+packuswb m4, m4
+movss [dstq + xq], m4
+
+add xq, mmsize/4
+cmp xq, widthq
+jl .loop1
+
+add widthq, rq
+cmp xq, widthq
+jge .end
+
+.loop2:
+xor rd, rd
+xor iq, iq
+.loop2_2:
+mov ciq, [ptrq + iq * gprsize]
+movzx multd, byte [ciq + xq]
+imul multd, [matrixq + 4*iq]
+add rd, multd
+
+add iq, 1
+cmp iq, radq
+jl .loop2_2
+
+pxor m4, m4
+cvtsi2ss m4, rd
+mulss m4, m0 ; sum *= rdiv
+addss m4, m1 ; sum += bias
+addss m4, m5 ; sum += 0.5
+cvttps2dq m4, m4
+packssdw m4, m4
+packuswb m4, m4
+movd rd, m4
+mov [dstq + xq], rb
+
+add xq, 1
+cmp xq, widthq
+jl .loop2
+.end:
+RET
+%endif
diff --git a/libavfilter/x86/vf_convolution_init.c
b/libavfilter/x86/vf_convolution_init.c
index 51432406ed..d1e8c90ceb 100644
--- a/libavfilter/x86/vf_convolution_init.c
+++ b/libavfilter/x86/vf_convolution_init.c
@@ -29,6 +29,12 @@ void ff_filter_3x3_sse4(uint8_t *dst, int width,
const uint8_t *c[], int peak, int radius,
int dstride, int stride);
+void ff_filter_row_sse4(uint8_t *dst, int width,
+float rdiv, float bias, const int *const matrix,
+const uint8_t *c[], int peak, int radius,
+int dstride, int stride);
+
+
av_cold void ff_convolution_init_x86(ConvolutionContext *s)
{
#if ARCH_X86_64
@@ -41,6 +47,10 @@ av_cold void ff_convolution_init_x86(ConvolutionContext *s)
s->filter[i] = ff_filter_3x3_sse4;
}
}
+ if (s->mode[i] == MATRIX_ROW) {
+if (EXTERNAL_SSE4(cpu_flags))
+s->filter[i] = ff_filter_row_sse4;
+}
}
#endif
}
--
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] avformat/utils.c: allows av_read_frame to return after a timeout period.
On Tue, Nov 26, 2019 at 02:45:05PM -0300, gga wrote:
>
>
> On 26/11/19 14:31, Michael Niedermayer wrote:
> >On Thu, Nov 21, 2019 at 06:27:10PM -0300, ggarr...@gmail.com wrote:
> >>From: Gonzalo Garramuño
> >>
> >>This patch is based on a patch by bsenftner at earthlink.net.
> >>---
> >> libavformat/utils.c | 5 +
> >> 1 file changed, 5 insertions(+)
> >>
> >>diff --git a/libavformat/utils.c b/libavformat/utils.c
> >>index 8196442dd1..c3c2c77c0c 100644
> >>--- a/libavformat/utils.c
> >>+++ b/libavformat/utils.c
> >>@@ -1838,6 +1838,11 @@ int av_read_frame(AVFormatContext *s, AVPacket *pkt)
> >> }
> >> }
> >>+if (ff_check_interrupt(&s->interrupt_callback)) {
> >>+av_log(s, AV_LOG_DEBUG, "interrupted\n");
> >>+return AVERROR_EXIT;
> >>+}
> >>+
> >I think this can be moved into the if() above, which might
> >reduce the number of calls.
> >
> >thx
> >[...]
> >
> It would probably reduce only one call, as pktl (the if above) is a list
> that will get filled probably as soon as there is a packet. Or maybe I am
> reading the code wrong? Also, if it does not get filled, we probably want
> to exit anyway, too.
we want to call ff_check_interrupt() between time consuming operations
but calling it before everything seems a bit odd to me.
Why did one call av_read_frame() if one wants to interrupt before doing
anything
Now if the list is empty the loop has just been entered so why would we
interrupt here ?
maybe iam missing something but this doesnt seem to be usefull
Thanks
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
The day soldiers stop bringing you their problems is the day you have stopped
leading them. They have either lost confidence that you can help or concluded
you do not care. Either case is a failure of leadership. - Colin Powell
signature.asc
Description: PGP signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH] avformat/utils: Simplify condition in av_read_frame()
Signed-off-by: Michael Niedermayer
---
libavformat/utils.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/libavformat/utils.c b/libavformat/utils.c
index 8196442dd1..dc79987ec1 100644
--- a/libavformat/utils.c
+++ b/libavformat/utils.c
@@ -1830,8 +1830,8 @@ int av_read_frame(AVFormatContext *s, AVPacket *pkt)
/* read packet from packet buffer, if there is data */
st = s->streams[next_pkt->stream_index];
-if (!(next_pkt->pts == AV_NOPTS_VALUE && st->discard <
AVDISCARD_ALL &&
- next_pkt->dts != AV_NOPTS_VALUE && !eof)) {
+if (next_pkt->pts != AV_NOPTS_VALUE || st->discard >=
AVDISCARD_ALL ||
+next_pkt->dts == AV_NOPTS_VALUE || eof) {
ret = ff_packet_list_get(&s->internal->packet_buffer,
&s->internal->packet_buffer_end, pkt);
goto return_packet;
--
2.23.0
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] tools/target_dec_fuzzer: add support to fuzz bitstream filters
On 9/3/2019 10:49 AM, James Almer wrote:
> On 8/30/2019 1:39 PM, James Almer wrote:
>> Signed-off-by: James Almer
>> ---
>> Untested. I'm also not sure how to add the FFMPEG_BSF define to
>> tools/Makefile,
>> and have it coexist with FFMPEG_DECODER. Assuming it's needed.
>>
>> tools/target_dec_fuzzer.c | 43 +++
>> 1 file changed, 43 insertions(+)
>>
>> diff --git a/tools/target_dec_fuzzer.c b/tools/target_dec_fuzzer.c
>> index 0d10503cfb..b8fe1f2aa1 100644
>> --- a/tools/target_dec_fuzzer.c
>> +++ b/tools/target_dec_fuzzer.c
>> @@ -65,6 +65,8 @@ static void error(const char *err)
>> }
>>
>> static AVCodec *c = NULL;
>> +static AVBitStreamFilter *f = NULL;
>> +
>> static AVCodec *AVCodecInitialize(enum AVCodecID codec_id)
>> {
>> AVCodec *res;
>> @@ -102,6 +104,7 @@ int LLVMFuzzerTestOneInput(const uint8_t *data, size_t
>> size) {
>>int *got_picture_ptr,
>>const AVPacket *avpkt) = NULL;
>> AVCodecParserContext *parser = NULL;
>> +AVBSFContext *bsf = NULL;
>>
>>
>> if (!c) {
>> @@ -120,6 +123,27 @@ int LLVMFuzzerTestOneInput(const uint8_t *data, size_t
>> size) {
>> av_log_set_level(AV_LOG_PANIC);
>> }
>>
>> +if (!f) {
>> +#ifdef FFMPEG_BSF
>> +#define BSF_SYMBOL0(BSF) ff_##BSF##_bsf
>> +#define BSF_SYMBOL(BSF) BSF_SYMBOL0(BSF)
>> +extern AVBitStreamFilter BSF_SYMBOL(FFMPEG_BSF);
>> +f = &BSF_SYMBOL(FFMPEG_BSF);
>> +
>> +if (f->codec_ids) {
>> +const enum AVCodecID *ids;
>> +for (ids = f->codec_ids; *ids != AV_CODEC_ID_NONE; ids++)
>> +if (*ids == c->id)
>> +break;
>> +if (ids == AV_CODEC_ID_NONE)
>> +error("Invalid bsf");
>> +}
>> +#else
>> +extern AVBitStreamFilter ff_null_bsf;
>> +f = &ff_null_bsf;
>> +#endif
>> +}
>> +
>> switch (c->type) {
>> case AVMEDIA_TYPE_AUDIO : decode_handler = avcodec_decode_audio4;
>> break;
>> case AVMEDIA_TYPE_VIDEO : decode_handler = avcodec_decode_video2;
>> break;
>> @@ -181,6 +205,18 @@ int LLVMFuzzerTestOneInput(const uint8_t *data, size_t
>> size) {
>> }
>> parser_avctx->codec_id = ctx->codec_id;
>>
>> +res = av_bsf_alloc(f, &bsf);
>> +if (res < 0)
>> +error("Failed memory allocation");
>> +
>> +res = avcodec_parameters_from_context(bsf->par_in, ctx);
>> +if (res < 0)
>> +error("Failed memory allocation");
>> +
>> +res = av_bsf_init(bsf);
>> +if (res < 0)
>> +return 0; // Failure of av_bsf_init() does not imply that a issue
>> was found
>> +
>> int got_frame;
>> AVFrame *frame = av_frame_alloc();
>> if (!frame)
>> @@ -237,6 +273,11 @@ int LLVMFuzzerTestOneInput(const uint8_t *data, size_t
>> size) {
>> }
>>
>>// Iterate through all data
>> + res = av_bsf_send_packet(bsf, &avpkt);
>> + while (res >= 0) {
>> +res = av_bsf_receive_packet(bsf, &avpkt);
>> +if (res < 0)
>> +break;
>>while (avpkt.size > 0 && it++ < maxiteration) {
>> av_frame_unref(frame);
>> int ret = decode_handler(ctx, frame, &got_frame, &avpkt);
>> @@ -255,6 +296,7 @@ int LLVMFuzzerTestOneInput(const uint8_t *data, size_t
>> size) {
>> avpkt.size -= ret;
>>}
>>av_packet_unref(&avpkt);
>> + }
>> }
>> av_packet_unref(&parsepkt);
>> }
>> @@ -270,6 +312,7 @@ maximums_reached:
>>
>> fprintf(stderr, "pixels decoded: %"PRId64", iterations: %d\n",
>> ec_pixels, it);
>>
>> +av_bsf_free(&bsf);
>> av_frame_free(&frame);
>> avcodec_free_context(&ctx);
>> avcodec_free_context(&parser_avctx);
>
> Ping.
Another ping.
___
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_convolution: add 16-column operation for filter_column() to prepare for x86 SIMD.
From: Xu Jun
In order to add x86 SIMD for filter_column(), I write a C function which
processes 16 columns at a time.
Signed-off-by: Xu Jun
---
libavfilter/vf_convolution.c | 56 +++
libavfilter/x86/vf_convolution_init.c | 23 +++
2 files changed, 79 insertions(+)
diff --git a/libavfilter/vf_convolution.c b/libavfilter/vf_convolution.c
index d022f1a04a..5291415d48 100644
--- a/libavfilter/vf_convolution.c
+++ b/libavfilter/vf_convolution.c
@@ -520,6 +520,61 @@ static int filter_slice(AVFilterContext *ctx, void *arg,
int jobnr, int nb_jobs)
continue;
}
+if (mode == MATRIX_COLUMN && s->filter[plane] != filter_column){
+for (y = slice_start; y < slice_end - 16; y+=16) {
+const int xoff = (y - slice_start) * bpc;
+const int yoff = radius * stride;
+for (x = 0; x < radius; x++) {
+const int xoff = (y - slice_start) * bpc;
+const int yoff = x * stride;
+
+s->setup[plane](radius, c, src, stride, x, width, y,
height, bpc);
+s->filter[plane](dst + yoff + xoff, 1, rdiv,
+bias, matrix, c, 16, radius,
+dstride, stride);
+}
+s->setup[plane](radius, c, src, stride, radius, width, y,
height, bpc);
+s->filter[plane](dst + yoff + xoff, sizew - 2 * radius,
+rdiv, bias, matrix, c, 16, radius,
+dstride, stride);
+for (x = sizew - radius; x < sizew; x++) {
+const int xoff = (y - slice_start) * bpc;
+const int yoff = x * stride;
+
+s->setup[plane](radius, c, src, stride, x, width, y,
height, bpc);
+s->filter[plane](dst + yoff + xoff, 1, rdiv,
+bias, matrix, c, 16, radius,
+dstride, stride);
+}
+}
+if (y < slice_end){
+const int xoff = (y - slice_start) * bpc;
+const int yoff = radius * stride;
+for (x = 0; x < radius; x++) {
+const int xoff = (y - slice_start) * bpc;
+const int yoff = x * stride;
+
+s->setup[plane](radius, c, src, stride, x, width, y,
height, bpc);
+s->filter[plane](dst + yoff + xoff, 1, rdiv,
+bias, matrix, c, slice_end - y, radius,
+dstride, stride);
+}
+s->setup[plane](radius, c, src, stride, radius, width, y,
height, bpc);
+s->filter[plane](dst + yoff + xoff, sizew - 2 * radius,
+rdiv, bias, matrix, c, slice_end - y, radius,
+dstride, stride);
+for (x = sizew - radius; x < sizew; x++) {
+const int xoff = (y - slice_start) * bpc;
+const int yoff = x * stride;
+
+s->setup[plane](radius, c, src, stride, x, width, y,
height, bpc);
+s->filter[plane](dst + yoff + xoff, 1, rdiv,
+bias, matrix, c, slice_end - y, radius,
+dstride, stride);
+}
+}
+}
+else {
for (y = slice_start; y < slice_end; y++) {
const int xoff = mode == MATRIX_COLUMN ? (y - slice_start) * bpc :
radius * bpc;
const int yoff = mode == MATRIX_COLUMN ? radius * stride : 0;
@@ -550,6 +605,7 @@ static int filter_slice(AVFilterContext *ctx, void *arg,
int jobnr, int nb_jobs)
dst += dstride;
}
}
+}
return 0;
}
diff --git a/libavfilter/x86/vf_convolution_init.c
b/libavfilter/x86/vf_convolution_init.c
index d1e8c90ceb..6b1c2f0e9f 100644
--- a/libavfilter/x86/vf_convolution_init.c
+++ b/libavfilter/x86/vf_convolution_init.c
@@ -34,6 +34,27 @@ void ff_filter_row_sse4(uint8_t *dst, int width,
const uint8_t *c[], int peak, int radius,
int dstride, int stride);
+static void filter_column16(uint8_t *dst, int height,
+ float rdiv, float bias, const int *const matrix,
+ const uint8_t *c[], int length, int radius,
+ int dstride, int stride)
+{
+int y, off16;
+
+for (y = 0; y < height; y++) {
+for (off16 = 0; off16 < length; off16++){
+int i, sum = 0;
+
+for (i = 0; i < 2 * radius + 1; i++)
+sum += c[i][0 + y * stride + off16] * matrix[i];
+
+sum = (int)(sum * rdiv + bias + 0.5f);
+dst[off16] = av_clip_uint8(sum);
+}
+dst += dstride;
+}
+
+}
[FFmpeg-devel] [PATCH] avfilter/vf_convolution: add x86 SIMD for filter_column()
From: Xu Jun
Tested using a simple command:
./ffmpeg_g -s 1280*720 -pix_fmt yuv420p -i test.yuv -vf convolution="1 2 3 4 5
6 7 8 9:1 2 3 4 5 6 7 8 9:1 2 3 4 5 6 7 8 9:1 2 3 4 5 6 7 8
9:1/45:1/45:1/45:1/45:1:2:3:4:column:column:column:column" -an -vframes 1000 -f
null /dev/null
The fps increase from 284 to 693 on my local machine.
Signed-off-by: Xu Jun
---
libavfilter/x86/vf_convolution.asm| 129 ++
libavfilter/x86/vf_convolution_init.c | 7 ++
2 files changed, 136 insertions(+)
diff --git a/libavfilter/x86/vf_convolution.asm
b/libavfilter/x86/vf_convolution.asm
index b71e9720fb..49dfbab9c0 100755
--- a/libavfilter/x86/vf_convolution.asm
+++ b/libavfilter/x86/vf_convolution.asm
@@ -258,3 +258,132 @@ sub widthq, rq
.end:
RET
%endif
+
+; void filter_column(uint8_t *dst, int height,
+; float rdiv, float bias, const int *const matrix,
+; const uint8_t *c[], int length, int radius,
+; int dstride, int stride);
+
+%if ARCH_X86_64
+INIT_XMM sse4
+%if UNIX64
+cglobal filter_column16, 8, 15, 7, dst, height, matrix, ptr, width, rad,
dstride, stride, i, ci, dst_off, off16, c_off, sum, r
+%else
+cglobal filter_column16, 8, 15, 7, dst, height, rdiv, bias, matrix, ptr,
width, rad, dstride, stride, i, ci, dst_off, off16, c_off, sum, r
+%endif
+
+%if WIN64
+SWAP m0, m2
+SWAP m1, m3
+mov r2q, matrixmp
+mov r3q, ptrmp
+mov r4q, widthmp
+mov r5q, radmp
+mov r6q, dstridemp
+mov r7q, stridemp
+DEFINE_ARGS dst, height, matrix, ptr, width, rad, dstride, stride, i, ci,
dst_off, off16, c_off, sum, r
+%endif
+
+movsxdifnidn widthq, widthd
+movsxdifnidn radq, radd
+movsxdifnidn dstrideq, dstrided
+movsxdifnidn strideq, strided
+sal radq, 1
+add radq, 1 ;2*radius+1
+movsxdifnidn heightq, heightd
+VBROADCASTSS m0, m0
+VBROADCASTSS m1, m1
+pxor m6, m6
+movss m5, [half]
+VBROADCASTSS m5, m5
+
+xor dst_offq, dst_offq
+xor c_offq, c_offq
+
+.loopy:
+xor off16q, off16q
+cmp widthq, mmsize/4
+jl .loopr
+
+mov rq, widthq
+and rq, mmsize/4-1
+sub widthq, rq
+
+.loop16: ;parallel process 16 elements in a row
+pxor m4, m4
+xor iq, iq
+.loopi:
+movss m2, [matrixq + 4*iq]
+VBROADCASTSS m2, m2
+mov ciq, [ptrq + iq * gprsize]
+movss m3, [ciq + c_offq] ;c[i][y*stride + off16]
+punpcklbw m3, m6
+punpcklwd m3, m6
+pmulld m2, m3
+paddd m4, m2
+
+add iq, 1
+cmp iq, radq
+jl .loopi
+
+cvtdq2ps m4, m4
+mulps m4, m0 ; sum *= rdiv
+addps m4, m1 ; sum += bias
+addps m4, m5 ; sum += 0.5
+cvttps2dq m4, m4
+packssdw m4, m4
+packuswb m4, m4
+movss [dstq + dst_offq], m4
+add c_offq, mmsize/4
+add dst_offq, mmsize/4
+
+add off16q, mmsize/4
+cmp off16q, widthq
+jl .loop16
+
+add widthq, rq
+cmp off16q, widthq
+jge .paraend
+
+.loopr:
+xor sumd, sumd
+xor iq, iq
+.loopr_i:
+mov ciq, [ptrq + iq * gprsize]
+movzx rd, byte [ciq + c_offq]
+imul rd, [matrixq + 4*iq]
+add sumd, rd
+
+add iq, 1
+cmp iq, radq
+jl .loopr_i
+
+pxor m4, m4
+cvtsi2ss m4, sumd
+mulss m4, m0 ; sum *= rdiv
+addss m4, m1 ; sum += bias
+addss m4, m5 ; sum += 0.5
+cvttps2dq m4, m4
+packssdw m4, m4
+packuswb m4, m4
+movd sumd, m4
+mov [dstq + dst_offq], sumb
+add c_offq, 1
+add dst_offq, 1
+add off16q, 1
+cmp off16q, widthq
+jl .loopr
+
+.paraend:
+sub c_offq, widthq
+sub dst_offq, widthq
+add c_offq, strideq
+add dst_offq, dstrideq
+
+sub heightq, 1
+cmp heightq, 0
+jg .loopy
+
+.end:
+RET
+%endif
\ No newline at end of file
diff --git a/libavfilter/x86/vf_convolution_init.c
b/libavfilter/x86/vf_convolution_init.c
index 6b1c2f0e9f..d9e93296b9 100644
--- a/libavfilter/x86/vf_convolution_init.c
+++ b/libavfilter/x86/vf_convolution_init.c
@@ -56,6 +56,11 @@ static void filter_column16(uint8_t *dst, int height,
}
+void ff_filter_column16_sse4(uint8_t *dst, int width,
+float rdiv, float bias, const int *const matrix,
+const uint8_t *c[], int length, int radius,
+int dstride, int stride);
+
av_cold void ff_convolution_init_x86(ConvolutionContext *s)
{
#if ARCH_X86_64
@@ -74,6 +79,8 @@ av_cold void ff_convolution_init_x86(ConvolutionContext *s)
}
if (s->mode[i] == MATRIX_COLUMN)
s->filter[i] = filter_column16;
+if (EXTERNAL_SSE4(cpu_flags))
+s->filter[i] = ff_filter_column16_sse4;
}
#endif
}
--
2.17.1
Re: [FFmpeg-devel] [PATCH 03/23] avformat/matroskaenc: Use random TrackUID
On Wed, Nov 27, 2019 at 08:25:13AM +0100, Andreas Rheinhardt wrote:
> On Mon, Nov 25, 2019 at 2:57 PM Michael Niedermayer
> wrote:
>
> > On Sun, Nov 24, 2019 at 11:05:03PM +0100, Andreas Rheinhardt wrote:
> > > On Sun, Nov 24, 2019 at 8:28 PM Michael Niedermayer
> >
> > > wrote:
> > >
> > > > On Sun, Nov 24, 2019 at 09:08:00AM +, Andreas Rheinhardt wrote:
> > > > > Michael Niedermayer:
> > > > > > On Wed, Nov 06, 2019 at 03:49:02AM +0100, Andreas Rheinhardt wrote:
> > > > > >> Up until now, the TrackUID of a Matroska track which is supposed
> > to be
> > > > > >> random was not random at all: It always coincided with the
> > TrackNumber
> > > > > >> which is usually the 1-based index of the corresponding stream in
> > the
> > > > > >> array of AVStreams. This has been changed: It is now set via an
> > AVLFG
> > > > > >> if AVFMT_FLAG_BITEXACT is not set. Otherwise it is set like it is
> > set
> > > > > >> now (the only change happens if an explicit track number has been
> > > > > >> choosen via dash_track_number, because the system used in the
> > normal
> > > > > >> situation is now used, too). In particular, no FATE tests need to
> > be
> > > > > >> updated.
> > > > > >>
> > > > > >> This also fixes a bug in case the dash_track_number option was
> > used:
> > > > > >> In this case the TrackUID was set to the track number, but the
> > tags
> > > > were
> > > > > >> written with a TagTrackUID simply based upon the index, so that
> > the
> > > > tags
> > > > > >> didn't apply to the track they ought to apply to.
> > > > > >>
> > > > > >> Signed-off-by: Andreas Rheinhardt
> > > > > >> ---
> > > > > >> mkv_get_uid() might be overkill, but I simply wanted to be sure
> > that
> > > > > >> there are no collisions.
> > > > > >>
> > > > > >> libavformat/matroskaenc.c | 65
> > > > ++-
> > > > > >> 1 file changed, 57 insertions(+), 8 deletions(-)
> > > > > >>
> > > > > >> diff --git a/libavformat/matroskaenc.c b/libavformat/matroskaenc.c
> > > > > >> index de57e474be..b87d15b7ff 100644
> > > > > >> --- a/libavformat/matroskaenc.c
> > > > > >> +++ b/libavformat/matroskaenc.c
> > > > > >> @@ -94,6 +94,7 @@ typedef struct mkv_cues {
> > > > > >> typedef struct mkv_track {
> > > > > >> int write_dts;
> > > > > >> int has_cue;
> > > > > >> +uint32_tuid;
> > > > > >> int sample_rate;
> > > > > >> int64_t sample_rate_offset;
> > > > > >> int64_t last_timestamp;
> > > > > >> @@ -1199,8 +1200,7 @@ static int mkv_write_track(AVFormatContext
> > *s,
> > > > MatroskaMuxContext *mkv,
> > > > > >> track = start_ebml_master(pb, MATROSKA_ID_TRACKENTRY, 0);
> > > > > >> put_ebml_uint (pb, MATROSKA_ID_TRACKNUMBER,
> > > > > >> mkv->is_dash ? mkv->dash_track_number : i +
> > 1);
> > > > > >> -put_ebml_uint (pb, MATROSKA_ID_TRACKUID,
> > > > > >> - mkv->is_dash ? mkv->dash_track_number : i +
> > 1);
> > > > > >> +put_ebml_uint (pb, MATROSKA_ID_TRACKUID, mkv->tracks[i].uid);
> > > > > >> put_ebml_uint (pb, MATROSKA_ID_TRACKFLAGLACING , 0);// no
> > > > lacing (yet)
> > > > > >>
> > > > > >> if ((tag = av_dict_get(st->metadata, "title", NULL, 0)))
> > > > > >> @@ -1650,7 +1650,8 @@ static int mkv_write_tags(AVFormatContext
> > *s)
> > > > > >> if (!mkv_check_tag(st->metadata,
> > > > MATROSKA_ID_TAGTARGETS_TRACKUID))
> > > > > >> continue;
> > > > > >>
> > > > > >> -ret = mkv_write_tag(s, st->metadata,
> > > > MATROSKA_ID_TAGTARGETS_TRACKUID, i + 1);
> > > > > >> +ret = mkv_write_tag(s, st->metadata,
> > > > MATROSKA_ID_TAGTARGETS_TRACKUID,
> > > > > >> +mkv->tracks[i].uid);
> > > > > >> if (ret < 0) return ret;
> > > > > >> }
> > > > > >>
> > > > > >> @@ -1658,13 +1659,15 @@ static int mkv_write_tags(AVFormatContext
> > *s)
> > > > > >> for (i = 0; i < s->nb_streams; i++) {
> > > > > >> AVIOContext *pb;
> > > > > >> AVStream *st = s->streams[i];
> > > > > >> +mkv_track *track = &mkv->tracks[i];
> > > > > >> ebml_master tag_target;
> > > > > >> ebml_master tag;
> > > > > >>
> > > > > >> if (st->codecpar->codec_type ==
> > AVMEDIA_TYPE_ATTACHMENT)
> > > > > >> continue;
> > > > > >>
> > > > > >> -mkv_write_tag_targets(s,
> > > > MATROSKA_ID_TAGTARGETS_TRACKUID, i + 1, &tag_target);
> > > > > >> +mkv_write_tag_targets(s,
> > MATROSKA_ID_TAGTARGETS_TRACKUID,
> > > > > >> + track->uid, &tag_target);
> > > > > >> pb = mkv->tags_bc;
> > > > > >>
> > > > > >> tag = start_ebml_master(pb, MATROSKA_ID_SIMPLETAG,
> > 0);
> > > > > >> @@ -1863,10 +1866,6 @@ static int
> > mkv_write_header(AVFormatContext *s)
> > > > > >> version = 4;
> > > > > >> }
> > > > > >>
> > > >
Re: [FFmpeg-devel] [PATCH] tools/target_dec_fuzzer: add support to fuzz bitstream filters
On Wed, Nov 27, 2019 at 11:41:09AM -0300, James Almer wrote:
> On 9/3/2019 10:49 AM, James Almer wrote:
> > On 8/30/2019 1:39 PM, James Almer wrote:
> >> Signed-off-by: James Almer
> >> ---
> >> Untested.
i can test if it applies
> >> I'm also not sure how to add the FFMPEG_BSF define to tools/Makefile,
> >> and have it coexist with FFMPEG_DECODER. Assuming it's needed.
maybe something like
tools/target_bsf_%_fuzzer.o: tools/target_dec_fuzzer.c
$(COMPILE_C) -DFFMPEG_BSF=$*
but maybe i misunderdtand ...
> >>
> >> tools/target_dec_fuzzer.c | 43 +++
> >> 1 file changed, 43 insertions(+)
> >>
> >> diff --git a/tools/target_dec_fuzzer.c b/tools/target_dec_fuzzer.c
> >> index 0d10503cfb..b8fe1f2aa1 100644
> >> --- a/tools/target_dec_fuzzer.c
> >> +++ b/tools/target_dec_fuzzer.c
> >> @@ -65,6 +65,8 @@ static void error(const char *err)
> >> }
> >>
> >> static AVCodec *c = NULL;
> >> +static AVBitStreamFilter *f = NULL;
> >> +
> >> static AVCodec *AVCodecInitialize(enum AVCodecID codec_id)
> >> {
> >> AVCodec *res;
> >> @@ -102,6 +104,7 @@ int LLVMFuzzerTestOneInput(const uint8_t *data, size_t
> >> size) {
> >>int *got_picture_ptr,
> >>const AVPacket *avpkt) = NULL;
> >> AVCodecParserContext *parser = NULL;
> >> +AVBSFContext *bsf = NULL;
> >>
> >>
> >> if (!c) {
> >> @@ -120,6 +123,27 @@ int LLVMFuzzerTestOneInput(const uint8_t *data,
> >> size_t size) {
> >> av_log_set_level(AV_LOG_PANIC);
> >> }
> >>
> >> +if (!f) {
> >> +#ifdef FFMPEG_BSF
> >> +#define BSF_SYMBOL0(BSF) ff_##BSF##_bsf
> >> +#define BSF_SYMBOL(BSF) BSF_SYMBOL0(BSF)
> >> +extern AVBitStreamFilter BSF_SYMBOL(FFMPEG_BSF);
> >> +f = &BSF_SYMBOL(FFMPEG_BSF);
> >> +
> >> +if (f->codec_ids) {
> >> +const enum AVCodecID *ids;
> >> +for (ids = f->codec_ids; *ids != AV_CODEC_ID_NONE; ids++)
> >> +if (*ids == c->id)
> >> +break;
> >> +if (ids == AV_CODEC_ID_NONE)
> >> +error("Invalid bsf");
> >> +}
> >> +#else
> >> +extern AVBitStreamFilter ff_null_bsf;
> >> +f = &ff_null_bsf;
> >> +#endif
> >> +}
> >> +
> >> switch (c->type) {
> >> case AVMEDIA_TYPE_AUDIO : decode_handler = avcodec_decode_audio4;
> >> break;
> >> case AVMEDIA_TYPE_VIDEO : decode_handler = avcodec_decode_video2;
> >> break;
> >> @@ -181,6 +205,18 @@ int LLVMFuzzerTestOneInput(const uint8_t *data,
> >> size_t size) {
> >> }
> >> parser_avctx->codec_id = ctx->codec_id;
> >>
> >> +res = av_bsf_alloc(f, &bsf);
> >> +if (res < 0)
> >> +error("Failed memory allocation");
> >> +
> >> +res = avcodec_parameters_from_context(bsf->par_in, ctx);
> >> +if (res < 0)
> >> +error("Failed memory allocation");
> >> +
> >> +res = av_bsf_init(bsf);
> >> +if (res < 0)
> >> +return 0; // Failure of av_bsf_init() does not imply that a issue
> >> was found
> >> +
> >> int got_frame;
> >> AVFrame *frame = av_frame_alloc();
> >> if (!frame)
> >> @@ -237,6 +273,11 @@ int LLVMFuzzerTestOneInput(const uint8_t *data,
> >> size_t size) {
> >> }
> >>
> >>// Iterate through all data
> >> + res = av_bsf_send_packet(bsf, &avpkt);
> >> + while (res >= 0) {
> >> +res = av_bsf_receive_packet(bsf, &avpkt);
> >> +if (res < 0)
> >> +break;
> >>while (avpkt.size > 0 && it++ < maxiteration) {
> >> av_frame_unref(frame);
> >> int ret = decode_handler(ctx, frame, &got_frame, &avpkt);
> >> @@ -255,6 +296,7 @@ int LLVMFuzzerTestOneInput(const uint8_t *data, size_t
> >> size) {
> >> avpkt.size -= ret;
> >>}
> >>av_packet_unref(&avpkt);
> >> + }
> >> }
> >> av_packet_unref(&parsepkt);
> >> }
> >> @@ -270,6 +312,7 @@ maximums_reached:
> >>
> >> fprintf(stderr, "pixels decoded: %"PRId64", iterations: %d\n",
> >> ec_pixels, it);
> >>
> >> +av_bsf_free(&bsf);
> >> av_frame_free(&frame);
> >> avcodec_free_context(&ctx);
> >> avcodec_free_context(&parser_avctx);
> >
> > Ping.
>
> Another ping.
doesnt apply
Applying: tools/target_dec_fuzzer: add support to fuzz bitstream filters
error: sha1 information is lacking or useless (tools/target_dec_fuzzer.c).
error: could not build fake ancestor
Patch failed at 0001 tools/target_dec_fuzzer: add support to fuzz bitstream
filters
hint: Use 'git am --show-current-patch' to see the failed patch
When you have resolved this problem, run "git am --continue".
If you prefer to skip this patch, run "git am --skip" instead.
To restore the original branch and stop patching, run "git am --abort".
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
Many things micr
Re: [FFmpeg-devel] [PATCH] tools/target_dec_fuzzer: add support to fuzz bitstream filters
On 11/27/2019 1:09 PM, Michael Niedermayer wrote:
> On Wed, Nov 27, 2019 at 11:41:09AM -0300, James Almer wrote:
>> On 9/3/2019 10:49 AM, James Almer wrote:
>>> On 8/30/2019 1:39 PM, James Almer wrote:
Signed-off-by: James Almer
---
>
Untested.
>
> i can test if it applies
>
>
I'm also not sure how to add the FFMPEG_BSF define to tools/Makefile,
and have it coexist with FFMPEG_DECODER. Assuming it's needed.
>
> maybe something like
> tools/target_bsf_%_fuzzer.o: tools/target_dec_fuzzer.c
> $(COMPILE_C) -DFFMPEG_BSF=$*
>
> but maybe i misunderdtand ...
But then what's the decoder used for it? Where is FFMPEG_CODEC defined
in the absence of FFMPEG_DECODER?
>
>
>
tools/target_dec_fuzzer.c | 43 +++
1 file changed, 43 insertions(+)
diff --git a/tools/target_dec_fuzzer.c b/tools/target_dec_fuzzer.c
index 0d10503cfb..b8fe1f2aa1 100644
--- a/tools/target_dec_fuzzer.c
+++ b/tools/target_dec_fuzzer.c
@@ -65,6 +65,8 @@ static void error(const char *err)
}
static AVCodec *c = NULL;
+static AVBitStreamFilter *f = NULL;
+
static AVCodec *AVCodecInitialize(enum AVCodecID codec_id)
{
AVCodec *res;
@@ -102,6 +104,7 @@ int LLVMFuzzerTestOneInput(const uint8_t *data, size_t
size) {
int *got_picture_ptr,
const AVPacket *avpkt) = NULL;
AVCodecParserContext *parser = NULL;
+AVBSFContext *bsf = NULL;
if (!c) {
@@ -120,6 +123,27 @@ int LLVMFuzzerTestOneInput(const uint8_t *data,
size_t size) {
av_log_set_level(AV_LOG_PANIC);
}
+if (!f) {
+#ifdef FFMPEG_BSF
+#define BSF_SYMBOL0(BSF) ff_##BSF##_bsf
+#define BSF_SYMBOL(BSF) BSF_SYMBOL0(BSF)
+extern AVBitStreamFilter BSF_SYMBOL(FFMPEG_BSF);
+f = &BSF_SYMBOL(FFMPEG_BSF);
+
+if (f->codec_ids) {
+const enum AVCodecID *ids;
+for (ids = f->codec_ids; *ids != AV_CODEC_ID_NONE; ids++)
+if (*ids == c->id)
+break;
+if (ids == AV_CODEC_ID_NONE)
+error("Invalid bsf");
+}
+#else
+extern AVBitStreamFilter ff_null_bsf;
+f = &ff_null_bsf;
+#endif
+}
+
switch (c->type) {
case AVMEDIA_TYPE_AUDIO : decode_handler = avcodec_decode_audio4;
break;
case AVMEDIA_TYPE_VIDEO : decode_handler = avcodec_decode_video2;
break;
@@ -181,6 +205,18 @@ int LLVMFuzzerTestOneInput(const uint8_t *data,
size_t size) {
}
parser_avctx->codec_id = ctx->codec_id;
+res = av_bsf_alloc(f, &bsf);
+if (res < 0)
+error("Failed memory allocation");
+
+res = avcodec_parameters_from_context(bsf->par_in, ctx);
+if (res < 0)
+error("Failed memory allocation");
+
+res = av_bsf_init(bsf);
+if (res < 0)
+return 0; // Failure of av_bsf_init() does not imply that a issue
was found
+
int got_frame;
AVFrame *frame = av_frame_alloc();
if (!frame)
@@ -237,6 +273,11 @@ int LLVMFuzzerTestOneInput(const uint8_t *data,
size_t size) {
}
// Iterate through all data
+ res = av_bsf_send_packet(bsf, &avpkt);
+ while (res >= 0) {
+res = av_bsf_receive_packet(bsf, &avpkt);
+if (res < 0)
+break;
while (avpkt.size > 0 && it++ < maxiteration) {
av_frame_unref(frame);
int ret = decode_handler(ctx, frame, &got_frame, &avpkt);
@@ -255,6 +296,7 @@ int LLVMFuzzerTestOneInput(const uint8_t *data, size_t
size) {
avpkt.size -= ret;
}
av_packet_unref(&avpkt);
+ }
}
av_packet_unref(&parsepkt);
}
@@ -270,6 +312,7 @@ maximums_reached:
fprintf(stderr, "pixels decoded: %"PRId64", iterations: %d\n",
ec_pixels, it);
+av_bsf_free(&bsf);
av_frame_free(&frame);
avcodec_free_context(&ctx);
avcodec_free_context(&parser_avctx);
>>>
>>> Ping.
>>
>> Another ping.
>
> doesnt apply
>
> Applying: tools/target_dec_fuzzer: add support to fuzz bitstream filters
> error: sha1 information is lacking or useless (tools/target_dec_fuzzer.c).
> error: could not build fake ancestor
> Patch failed at 0001 tools/target_dec_fuzzer: add support to fuzz bitstream
> filters
> hint: Use 'git am --show-current-patch' to see the failed patch
> When you have resolved this problem, run "git am --continue".
> If you prefer to skip this
Re: [FFmpeg-devel] [PATCH] avfilter/vf_convolution: add 16-column operation for filter_column() to prepare for x86 SIMD.
Am Mi., 27. Nov. 2019 um 15:56 Uhr schrieb : > From: Xu Jun > > In order to add x86 SIMD for filter_column(), I write a C function which > processes 16 columns at a time. How does this perform compared to the existing C code? Carl Eugen ___ 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 03/23] avformat/matroskaenc: Use random TrackUID
On Wed, Nov 27, 2019 at 4:50 PM Michael Niedermayer
wrote:
> On Wed, Nov 27, 2019 at 08:25:13AM +0100, Andreas Rheinhardt wrote:
> > On Mon, Nov 25, 2019 at 2:57 PM Michael Niedermayer
>
> > wrote:
> >
> > > On Sun, Nov 24, 2019 at 11:05:03PM +0100, Andreas Rheinhardt wrote:
> > > > On Sun, Nov 24, 2019 at 8:28 PM Michael Niedermayer
> > >
> > > > wrote:
> > > >
> > > > > On Sun, Nov 24, 2019 at 09:08:00AM +, Andreas Rheinhardt wrote:
> > > > > > Michael Niedermayer:
> > > > > > > On Wed, Nov 06, 2019 at 03:49:02AM +0100, Andreas Rheinhardt
> wrote:
> > > > > > >> Up until now, the TrackUID of a Matroska track which is
> supposed
> > > to be
> > > > > > >> random was not random at all: It always coincided with the
> > > TrackNumber
> > > > > > >> which is usually the 1-based index of the corresponding
> stream in
> > > the
> > > > > > >> array of AVStreams. This has been changed: It is now set via
> an
> > > AVLFG
> > > > > > >> if AVFMT_FLAG_BITEXACT is not set. Otherwise it is set like
> it is
> > > set
> > > > > > >> now (the only change happens if an explicit track number has
> been
> > > > > > >> choosen via dash_track_number, because the system used in the
> > > normal
> > > > > > >> situation is now used, too). In particular, no FATE tests
> need to
> > > be
> > > > > > >> updated.
> > > > > > >>
> > > > > > >> This also fixes a bug in case the dash_track_number option was
> > > used:
> > > > > > >> In this case the TrackUID was set to the track number, but the
> > > tags
> > > > > were
> > > > > > >> written with a TagTrackUID simply based upon the index, so
> that
> > > the
> > > > > tags
> > > > > > >> didn't apply to the track they ought to apply to.
> > > > > > >>
> > > > > > >> Signed-off-by: Andreas Rheinhardt <
> andreas.rheinha...@gmail.com>
> > > > > > >> ---
> > > > > > >> mkv_get_uid() might be overkill, but I simply wanted to be
> sure
> > > that
> > > > > > >> there are no collisions.
> > > > > > >>
> > > > > > >> libavformat/matroskaenc.c | 65
> > > > > ++-
> > > > > > >> 1 file changed, 57 insertions(+), 8 deletions(-)
> > > > > > >>
> > > > > > >> diff --git a/libavformat/matroskaenc.c
> b/libavformat/matroskaenc.c
> > > > > > >> index de57e474be..b87d15b7ff 100644
> > > > > > >> --- a/libavformat/matroskaenc.c
> > > > > > >> +++ b/libavformat/matroskaenc.c
> > > > > > >> @@ -94,6 +94,7 @@ typedef struct mkv_cues {
> > > > > > >> typedef struct mkv_track {
> > > > > > >> int write_dts;
> > > > > > >> int has_cue;
> > > > > > >> +uint32_tuid;
> > > > > > >> int sample_rate;
> > > > > > >> int64_t sample_rate_offset;
> > > > > > >> int64_t last_timestamp;
> > > > > > >> @@ -1199,8 +1200,7 @@ static int
> mkv_write_track(AVFormatContext
> > > *s,
> > > > > MatroskaMuxContext *mkv,
> > > > > > >> track = start_ebml_master(pb, MATROSKA_ID_TRACKENTRY, 0);
> > > > > > >> put_ebml_uint (pb, MATROSKA_ID_TRACKNUMBER,
> > > > > > >> mkv->is_dash ? mkv->dash_track_number : i
> +
> > > 1);
> > > > > > >> -put_ebml_uint (pb, MATROSKA_ID_TRACKUID,
> > > > > > >> - mkv->is_dash ? mkv->dash_track_number : i
> +
> > > 1);
> > > > > > >> +put_ebml_uint (pb, MATROSKA_ID_TRACKUID,
> mkv->tracks[i].uid);
> > > > > > >> put_ebml_uint (pb, MATROSKA_ID_TRACKFLAGLACING , 0);
> // no
> > > > > lacing (yet)
> > > > > > >>
> > > > > > >> if ((tag = av_dict_get(st->metadata, "title", NULL, 0)))
> > > > > > >> @@ -1650,7 +1650,8 @@ static int
> mkv_write_tags(AVFormatContext
> > > *s)
> > > > > > >> if (!mkv_check_tag(st->metadata,
> > > > > MATROSKA_ID_TAGTARGETS_TRACKUID))
> > > > > > >> continue;
> > > > > > >>
> > > > > > >> -ret = mkv_write_tag(s, st->metadata,
> > > > > MATROSKA_ID_TAGTARGETS_TRACKUID, i + 1);
> > > > > > >> +ret = mkv_write_tag(s, st->metadata,
> > > > > MATROSKA_ID_TAGTARGETS_TRACKUID,
> > > > > > >> +mkv->tracks[i].uid);
> > > > > > >> if (ret < 0) return ret;
> > > > > > >> }
> > > > > > >>
> > > > > > >> @@ -1658,13 +1659,15 @@ static int
> mkv_write_tags(AVFormatContext
> > > *s)
> > > > > > >> for (i = 0; i < s->nb_streams; i++) {
> > > > > > >> AVIOContext *pb;
> > > > > > >> AVStream *st = s->streams[i];
> > > > > > >> +mkv_track *track = &mkv->tracks[i];
> > > > > > >> ebml_master tag_target;
> > > > > > >> ebml_master tag;
> > > > > > >>
> > > > > > >> if (st->codecpar->codec_type ==
> > > AVMEDIA_TYPE_ATTACHMENT)
> > > > > > >> continue;
> > > > > > >>
> > > > > > >> -mkv_write_tag_targets(s,
> > > > > MATROSKA_ID_TAGTARGETS_TRACKUID, i + 1, &tag_target);
> > > > > > >> +mkv_write_tag_targets(s,
> > > MATROSKA_ID_TAGTARGETS_TRACKUID,
> > > > > > >> +
Re: [FFmpeg-devel] [PATCH 03/23] avformat/matroskaenc: Use random TrackUID
Am Mi., 27. Nov. 2019 um 17:58 Uhr schrieb Andreas Rheinhardt : > I consider this only a slight disadvantage: E.g. the streamhash or the > framehash muxers would provide easy ways to examine whether the actual > content of the files (besides the UIDs) are different. But that wouldn't show changes in the output of the muxer. Carl Eugen ___ 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] [libdav1d.c]: Add options for spatial layers.
Disable by default to output all the layers, to match libaomdec wrapper.
Add option to select the operating point for the spatial layers.
Update the documentation with the new options.
---
doc/decoders.texi | 6 ++
libavcodec/libdav1d.c | 8
2 files changed, 14 insertions(+)
diff --git a/doc/decoders.texi b/doc/decoders.texi
index 676e062e72..86c899b5be 100644
--- a/doc/decoders.texi
+++ b/doc/decoders.texi
@@ -71,6 +71,12 @@ Set amount of tile threads to use during decoding. The
default value is 0 (autod
Apply film grain to the decoded video if present in the bitstream. Defaults to
the
internal default of the library.
+@item oppoint
+Select an operating point of a scalable AV1 bitstream (0 - 32)
+
+@item alllayer
+Output all spatial layers of a scalable AV1 bitstream. The default value is
false.
+
@end table
@section libdavs2
diff --git a/libavcodec/libdav1d.c b/libavcodec/libdav1d.c
index cf4b178f1d..ea4ef641bf 100644
--- a/libavcodec/libdav1d.c
+++ b/libavcodec/libdav1d.c
@@ -40,6 +40,8 @@ typedef struct Libdav1dContext {
int tile_threads;
int frame_threads;
int apply_grain;
+int operating_point;
+int all_layers;
} Libdav1dContext;
static const enum AVPixelFormat pix_fmt[][3] = {
@@ -134,6 +136,10 @@ static av_cold int libdav1d_init(AVCodecContext *c)
if (dav1d->apply_grain >= 0)
s.apply_grain = dav1d->apply_grain;
+s.all_layers = dav1d->all_layers;
+if (dav1d->operating_point >= 0)
+s.operating_point = dav1d->operating_point;
+
s.n_tile_threads = dav1d->tile_threads
? dav1d->tile_threads
: FFMIN(floor(sqrt(threads)), DAV1D_MAX_TILE_THREADS);
@@ -378,6 +384,8 @@ static const AVOption libdav1d_options[] = {
{ "tilethreads", "Tile threads", OFFSET(tile_threads), AV_OPT_TYPE_INT, {
.i64 = 0 }, 0, DAV1D_MAX_TILE_THREADS, VD },
{ "framethreads", "Frame threads", OFFSET(frame_threads), AV_OPT_TYPE_INT,
{ .i64 = 0 }, 0, DAV1D_MAX_FRAME_THREADS, VD },
{ "filmgrain", "Apply Film Grain", OFFSET(apply_grain), AV_OPT_TYPE_BOOL,
{ .i64 = -1 }, -1, 1, VD },
+{ "oppoint", "Select an operating point of the scalable bitstream",
OFFSET(operating_point), AV_OPT_TYPE_INT, { .i64 = -1 }, 0, 31, VD },
+{ "alllayers", "Output all spatial layers", OFFSET(all_layers),
AV_OPT_TYPE_BOOL, { .i64 = 0 }, 0, 1, VD },
{ NULL }
};
--
2.24.0.432.g9d3f5f5b63-goog
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 1/2] avcodec: add mvdv video decoder
tis 2019-11-26 klockan 20:29 +0100 skrev Paul B Mahol:
> On 11/26/19, James Almer wrote:
> > On 11/26/2019 6:47 AM, Paul B Mahol wrote:
> > > On 11/25/19, Tomas Härdin wrote:
> > > > mån 2019-11-25 klockan 22:09 +0100 skrev Paul B Mahol:
> > > > > Signed-off-by: Paul B Mahol
> > > > > +static int decode_mvdv(MidiVidContext *s, AVCodecContext *avctx,
> > > > > AVFrame
> > > > > *frame)
> > > > > +{
> > > > > +GetByteContext *gb = &s->gb;
> > > > > +GetBitContext mask;
> > > > > +GetByteContext idx9;
> > > > > +uint16_t nb_vectors, intra_flag;
> > > > > +const uint8_t *vec;
> > > > > +const uint8_t *mask_start;
> > > > > +uint8_t *skip;
> > > > > +int mask_size;
> > > > > +int idx9bits = 0;
> > > > > +int idx9val = 0;
> > > > > +int num_blocks;
> > > > > +
> > > > > +nb_vectors = bytestream2_get_le16(gb);
> > > > > +intra_flag = bytestream2_get_le16(gb);
> > > > > +if (intra_flag) {
> > > > > +num_blocks = (avctx->width / 2) * (avctx->height / 2);
> > > >
> > > > Will UB if width*height/4 > INT_MAX
> > > >
> > > > > +} else {
> > > > > +int skip_linesize;
> > > > > +
> > > > > +num_blocks = bytestream2_get_le32(gb);
> > > >
> > > > Might want to use uint32_t so this doesn't lead to weirdness on 32-bit
> > > >
> > > > > +skip_linesize = avctx->width >> 1;
> > > > > +mask_start = gb->buffer_start + bytestream2_tell(gb);
> > > > > +mask_size = (avctx->width >> 5) * (avctx->height >> 2);
> > > >
> > > > This can also UB
> > > >
> > > > /Tomas
> > > >
> > >
> > > Nothing of this can actually happen.
This assumes max_pixels will never be increased above INT_MAX. "64k"
video is most definitely within the range of possibility in the coming
years, if it isn't already. Film archival and DPX come to mind.
> > It can and i'm fairly sure it will happen as soon as the fuzzer starts
> > testing this decoder using big dimensions.
>
> I'm not that guy doing such work. Please stop bikesheding those
> patches for once.
This reads like an admission of pushing insecure code via "not my
problem"
> > You don't need asserts here, you just need to check the calculations
> > will not overflow. Do something like "if ((int64_t)avctx->width *
> > avctx->height / 4 > INT_MAX) return AVERROR_INVALIDDATA" and call it a day.
> > Also, maybe num_blocks should be unsigned, seeing you set it using
> > bytestream2_get_le32() for P-frames.
>
> No decoder does this.
zmbv does
All this is really about the lack of any way to reason about
assumptions like "dimensions can't be larger than X*Y" at compile time,
which is a thing I've been pointing out on this list for a while now.
/Tomas
___
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] [aarch64] improve performance of ff_hscale_8_to_15_neon
Hello, On Wed, Nov 27, 2019, at 19:30, Sebastian Pop wrote: > Please find attached a patch that improves the existing code in > aarch64/hscale.S > Performance test with gcc and clang shows that the patch improves > performance by 34% on Graviton A1 instances: So, that is better than the previous one. > Please let me know if I can make the patch better. Remove the commented lines. -- Jean-Baptiste Kempf - President +33 672 704 734 ___ 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] [aarch64] improve performance of ff_hscale_8_to_15_neon
On Mon, Nov 25, 2019 at 11:20 PM Jean-Baptiste Kempf wrote:
> > Is there a coding rule in ffmpeg that restricts the use of intrinsics?
>
> Yes. See doc/optimization.txt.
> Use external asm (nasm/yasm) or inline asm (__asm__()), do not use intrinsics.
Thanks for the pointer.
> Also, here, you're changing some existing code, please improve the code and
> do not duplicate code.
>
> > If that is the case, I can adapt my code to the existing asm code.
>
> Please.
Please find attached a patch that improves the existing code in aarch64/hscale.S
Performance test with gcc and clang shows that the patch improves
performance by 34% on Graviton A1 instances:
$ ffmpeg -nostats -f lavfi -i testsrc2=4k:d=2 -vf
bench=start,scale=1024x1024,bench=stop -f null -
before: t:0.040303 avg:0.040287 max:0.040371 min:0.039214
after: t:0.030079 avg:0.030102 max:0.030462 min:0.030051
Tested with `make check` on aarch64-linux.
Please let me know if I can make the patch better.
Thank you,
Sebastian
From e04f9606f7ea581d8398eb2f37df2f59add8b374 Mon Sep 17 00:00:00 2001
From: Sebastian Pop
Date: Sun, 17 Nov 2019 14:13:13 -0600
Subject: [PATCH] [aarch64] use FMA and increase vector factor to 4
This patch implements ff_hscale_8_to_15_neon with NEON fused multiply accumulate
and bumps the vectorization factor from 2 to 4.
The speedup is of 34% on Graviton A1 instances based on A-72 cpus:
$ ffmpeg -nostats -f lavfi -i testsrc2=4k:d=2 -vf bench=start,scale=1024x1024,bench=stop -f null -
before: t:0.040303 avg:0.040287 max:0.040371 min:0.039214
after: t:0.030079 avg:0.030102 max:0.030462 min:0.030051
Tested with `make check` on aarch64-linux.
---
libswscale/aarch64/hscale.S | 176 +---
1 file changed, 142 insertions(+), 34 deletions(-)
diff --git a/libswscale/aarch64/hscale.S b/libswscale/aarch64/hscale.S
index cc78c1901d..fb4de4d9a8 100644
--- a/libswscale/aarch64/hscale.S
+++ b/libswscale/aarch64/hscale.S
@@ -20,40 +20,148 @@
#include "libavutil/aarch64/asm.S"
+/* #include "arm_neon.h"
+
+void ff_hscale_8_to_15_neon(SwsContext *c, int16_t *dst, int dstW,
+const uint8_t *src, const int16_t *filter,
+const int32_t *filterPos, int filterSize);
+
+static inline int32x4_t ff_reduce(int32x4_t x) {
+ x = vpaddq_s32(x, x);
+ x = vpaddq_s32(x, x);
+ return x;
+}
+
+static inline int32x4_t ff_hscale(int32x4_t x, const uint8_t *src,
+ const int16_t *filter) {
+ uint8x8_t a = vld1_u8(src);
+ int16x8_t s = vreinterpretq_s16_u16(vshll_n_u8(a, 0));
+ int16x8_t f = vld1q_s16(filter);
+ x = vmlal_s16(x, vget_low_s16(s), vget_low_s16(f));
+ x = vmlal_high_s16(x, s, f);
+ return x;
+}
+
+static inline int32x4_t ff_zip64(int32x4_t a, int32x4_t b) {
+int64x2_t x0 = vreinterpretq_s64_s32(a);
+int64x2_t x1 = vreinterpretq_s64_s32(b);
+int64x2_t x2 = vzip1q_s64(x0, x1);
+int32x4_t x3 = vreinterpretq_s32_s64(x2);
+return x3;
+}
+
+static void ff_hscale_8_to_15_neon_1(SwsContext *c, int16_t *dst, int dstW,
+ const uint8_t *src, const int16_t *filter,
+ const int32_t *filterPos, int filterSize)
+{
+int i;
+if (dstW <= 0 || filterSize <= 0)
+ return;
+
+for (i = 0; i < dstW; i += 4) {
+int j;
+int32x4_t x0 = vdupq_n_s32(0);
+int32x4_t x1 = vdupq_n_s32(0);
+int32x4_t x2 = vdupq_n_s32(0);
+int32x4_t x3 = vdupq_n_s32(0);
+int32x4_t x4, x5, x6;
+int16x4_t x7;
+const uint8_t *src0 = src + filterPos[i];
+const uint8_t *src1 = src + filterPos[i + 1];
+const uint8_t *src2 = src + filterPos[i + 2];
+const uint8_t *src3 = src + filterPos[i + 3];
+const int16_t *filter0 = filter;
+const int16_t *filter1 = filter0 + filterSize;
+const int16_t *filter2 = filter1 + filterSize;
+const int16_t *filter3 = filter2 + filterSize;
+filter = filter3 + filterSize;
+for (j = 0; j < filterSize; j += 8) {
+x0 = ff_hscale(x0, src0 + j, filter0 + j);
+x1 = ff_hscale(x1, src1 + j, filter1 + j);
+x2 = ff_hscale(x2, src2 + j, filter2 + j);
+x3 = ff_hscale(x3, src3 + j, filter3 + j);
+}
+x0 = ff_reduce(x0);
+x1 = ff_reduce(x1);
+x2 = ff_reduce(x2);
+x3 = ff_reduce(x3);
+
+x4 = vzip1q_s32(x0, x1);
+x5 = vzip1q_s32(x2, x3);
+x6 = ff_zip64(x4, x5);
+x7 = vqshrn_n_s32(x6, 7);
+vst1_s16(&dst[i], x7);
+}
+} */
+
function ff_hscale_8_to_15_neon, export=1
-add x10, x4, w6, UXTW #1// filter2 = filter + filterSize*2 (x2 because int16)
-1: ldr w8, [x5], #4// filterPos[0]
-ldr w9, [x5], #4// filterPos[1]
-moviv4.4S, #0 // val sum part 1 (for dst[0])
-
Re: [FFmpeg-devel] [PATCH 1/2] avcodec: add mvdv video decoder
On 11/27/19, Tomas Härdin wrote:
> tis 2019-11-26 klockan 20:29 +0100 skrev Paul B Mahol:
>> On 11/26/19, James Almer wrote:
>> > On 11/26/2019 6:47 AM, Paul B Mahol wrote:
>> > > On 11/25/19, Tomas Härdin wrote:
>> > > > mån 2019-11-25 klockan 22:09 +0100 skrev Paul B Mahol:
>> > > > > Signed-off-by: Paul B Mahol
>> > > > > +static int decode_mvdv(MidiVidContext *s, AVCodecContext *avctx,
>> > > > > AVFrame
>> > > > > *frame)
>> > > > > +{
>> > > > > +GetByteContext *gb = &s->gb;
>> > > > > +GetBitContext mask;
>> > > > > +GetByteContext idx9;
>> > > > > +uint16_t nb_vectors, intra_flag;
>> > > > > +const uint8_t *vec;
>> > > > > +const uint8_t *mask_start;
>> > > > > +uint8_t *skip;
>> > > > > +int mask_size;
>> > > > > +int idx9bits = 0;
>> > > > > +int idx9val = 0;
>> > > > > +int num_blocks;
>> > > > > +
>> > > > > +nb_vectors = bytestream2_get_le16(gb);
>> > > > > +intra_flag = bytestream2_get_le16(gb);
>> > > > > +if (intra_flag) {
>> > > > > +num_blocks = (avctx->width / 2) * (avctx->height / 2);
>> > > >
>> > > > Will UB if width*height/4 > INT_MAX
>> > > >
>> > > > > +} else {
>> > > > > +int skip_linesize;
>> > > > > +
>> > > > > +num_blocks = bytestream2_get_le32(gb);
>> > > >
>> > > > Might want to use uint32_t so this doesn't lead to weirdness on
>> > > > 32-bit
>> > > >
>> > > > > +skip_linesize = avctx->width >> 1;
>> > > > > +mask_start = gb->buffer_start + bytestream2_tell(gb);
>> > > > > +mask_size = (avctx->width >> 5) * (avctx->height >> 2);
>> > > >
>> > > > This can also UB
>> > > >
>> > > > /Tomas
>> > > >
>> > >
>> > > Nothing of this can actually happen.
>
> This assumes max_pixels will never be increased above INT_MAX. "64k"
> video is most definitely within the range of possibility in the coming
> years, if it isn't already. Film archival and DPX come to mind.
>
>> > It can and i'm fairly sure it will happen as soon as the fuzzer starts
>> > testing this decoder using big dimensions.
>>
>> I'm not that guy doing such work. Please stop bikesheding those
>> patches for once.
>
> This reads like an admission of pushing insecure code via "not my
> problem"
>
>> > You don't need asserts here, you just need to check the calculations
>> > will not overflow. Do something like "if ((int64_t)avctx->width *
>> > avctx->height / 4 > INT_MAX) return AVERROR_INVALIDDATA" and call it a
>> > day.
>> > Also, maybe num_blocks should be unsigned, seeing you set it using
>> > bytestream2_get_le32() for P-frames.
>>
>> No decoder does this.
>
> zmbv does
>
> All this is really about the lack of any way to reason about
> assumptions like "dimensions can't be larger than X*Y" at compile time,
> which is a thing I've been pointing out on this list for a while now.
>
Nobody tells you not to fix it yourself.
> /Tomas
>
> ___
> 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 1/2] avcodec: add mvdv video decoder
On 11/27/2019 3:42 PM, Paul B Mahol wrote:
> On 11/27/19, Tomas Härdin wrote:
>> tis 2019-11-26 klockan 20:29 +0100 skrev Paul B Mahol:
>>> On 11/26/19, James Almer wrote:
On 11/26/2019 6:47 AM, Paul B Mahol wrote:
> On 11/25/19, Tomas Härdin wrote:
>> mån 2019-11-25 klockan 22:09 +0100 skrev Paul B Mahol:
>>> Signed-off-by: Paul B Mahol
>>> +static int decode_mvdv(MidiVidContext *s, AVCodecContext *avctx,
>>> AVFrame
>>> *frame)
>>> +{
>>> +GetByteContext *gb = &s->gb;
>>> +GetBitContext mask;
>>> +GetByteContext idx9;
>>> +uint16_t nb_vectors, intra_flag;
>>> +const uint8_t *vec;
>>> +const uint8_t *mask_start;
>>> +uint8_t *skip;
>>> +int mask_size;
>>> +int idx9bits = 0;
>>> +int idx9val = 0;
>>> +int num_blocks;
>>> +
>>> +nb_vectors = bytestream2_get_le16(gb);
>>> +intra_flag = bytestream2_get_le16(gb);
>>> +if (intra_flag) {
>>> +num_blocks = (avctx->width / 2) * (avctx->height / 2);
>>
>> Will UB if width*height/4 > INT_MAX
>>
>>> +} else {
>>> +int skip_linesize;
>>> +
>>> +num_blocks = bytestream2_get_le32(gb);
>>
>> Might want to use uint32_t so this doesn't lead to weirdness on
>> 32-bit
>>
>>> +skip_linesize = avctx->width >> 1;
>>> +mask_start = gb->buffer_start + bytestream2_tell(gb);
>>> +mask_size = (avctx->width >> 5) * (avctx->height >> 2);
>>
>> This can also UB
>>
>> /Tomas
>>
>
> Nothing of this can actually happen.
>>
>> This assumes max_pixels will never be increased above INT_MAX. "64k"
>> video is most definitely within the range of possibility in the coming
>> years, if it isn't already. Film archival and DPX come to mind.
>>
It can and i'm fairly sure it will happen as soon as the fuzzer starts
testing this decoder using big dimensions.
>>>
>>> I'm not that guy doing such work. Please stop bikesheding those
>>> patches for once.
>>
>> This reads like an admission of pushing insecure code via "not my
>> problem"
>>
You don't need asserts here, you just need to check the calculations
will not overflow. Do something like "if ((int64_t)avctx->width *
avctx->height / 4 > INT_MAX) return AVERROR_INVALIDDATA" and call it a
day.
Also, maybe num_blocks should be unsigned, seeing you set it using
bytestream2_get_le32() for P-frames.
>>>
>>> No decoder does this.
>>
>> zmbv does
>>
>> All this is really about the lack of any way to reason about
>> assumptions like "dimensions can't be larger than X*Y" at compile time,
>> which is a thing I've been pointing out on this list for a while now.
>>
>
> Nobody tells you not to fix it yourself.
Just add a the suggested overflow checks, Christ. It's a one line
addition each. What do you gain arguing like this?
___
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] [aarch64] improve performance of ff_hscale_8_to_15_neon
On Wed, Nov 27, 2019 at 12:37 PM Jean-Baptiste Kempf wrote: > > Please let me know if I can make the patch better. > > Remove the commented lines. Attached the updated patch. Thank you, Sebastian 0001-aarch64-use-FMA-and-increase-vector-factor-to-4.patch Description: Binary data ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 1/2] avcodec: add mvdv video decoder
On 11/27/19, James Almer wrote:
> On 11/27/2019 3:42 PM, Paul B Mahol wrote:
>> On 11/27/19, Tomas Härdin wrote:
>>> tis 2019-11-26 klockan 20:29 +0100 skrev Paul B Mahol:
On 11/26/19, James Almer wrote:
> On 11/26/2019 6:47 AM, Paul B Mahol wrote:
>> On 11/25/19, Tomas Härdin wrote:
>>> mån 2019-11-25 klockan 22:09 +0100 skrev Paul B Mahol:
Signed-off-by: Paul B Mahol
+static int decode_mvdv(MidiVidContext *s, AVCodecContext *avctx,
AVFrame
*frame)
+{
+GetByteContext *gb = &s->gb;
+GetBitContext mask;
+GetByteContext idx9;
+uint16_t nb_vectors, intra_flag;
+const uint8_t *vec;
+const uint8_t *mask_start;
+uint8_t *skip;
+int mask_size;
+int idx9bits = 0;
+int idx9val = 0;
+int num_blocks;
+
+nb_vectors = bytestream2_get_le16(gb);
+intra_flag = bytestream2_get_le16(gb);
+if (intra_flag) {
+num_blocks = (avctx->width / 2) * (avctx->height / 2);
>>>
>>> Will UB if width*height/4 > INT_MAX
>>>
+} else {
+int skip_linesize;
+
+num_blocks = bytestream2_get_le32(gb);
>>>
>>> Might want to use uint32_t so this doesn't lead to weirdness on
>>> 32-bit
>>>
+skip_linesize = avctx->width >> 1;
+mask_start = gb->buffer_start + bytestream2_tell(gb);
+mask_size = (avctx->width >> 5) * (avctx->height >> 2);
>>>
>>> This can also UB
>>>
>>> /Tomas
>>>
>>
>> Nothing of this can actually happen.
>>>
>>> This assumes max_pixels will never be increased above INT_MAX. "64k"
>>> video is most definitely within the range of possibility in the coming
>>> years, if it isn't already. Film archival and DPX come to mind.
>>>
> It can and i'm fairly sure it will happen as soon as the fuzzer starts
> testing this decoder using big dimensions.
I'm not that guy doing such work. Please stop bikesheding those
patches for once.
>>>
>>> This reads like an admission of pushing insecure code via "not my
>>> problem"
>>>
> You don't need asserts here, you just need to check the calculations
> will not overflow. Do something like "if ((int64_t)avctx->width *
> avctx->height / 4 > INT_MAX) return AVERROR_INVALIDDATA" and call it a
> day.
> Also, maybe num_blocks should be unsigned, seeing you set it using
> bytestream2_get_le32() for P-frames.
No decoder does this.
>>>
>>> zmbv does
>>>
>>> All this is really about the lack of any way to reason about
>>> assumptions like "dimensions can't be larger than X*Y" at compile time,
>>> which is a thing I've been pointing out on this list for a while now.
>>>
>>
>> Nobody tells you not to fix it yourself.
>
> Just add a the suggested overflow checks, Christ. It's a one line
> addition each. What do you gain arguing like this?
Than next day he or you will come with another great idea.
> ___
> 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] [aarch64] improve performance of ff_hscale_8_to_15_neon
On Wed, Nov 27, 2019, at 19:46, Sebastian Pop wrote: > On Wed, Nov 27, 2019 at 12:37 PM Jean-Baptiste Kempf > wrote: > > > Please let me know if I can make the patch better. > > > > Remove the commented lines. > > Attached the updated patch. OK for me. Cannot comment on the content. -- Jean-Baptiste Kempf - President +33 672 704 734 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] avformat/hlsenc: remove duplicate code block
On Wed, Nov 27, 2019 at 05:43:09PM +0800, Steven Liu wrote: > Signed-off-by: Steven Liu > --- > libavformat/hlsenc.c | 23 --- > 1 file changed, 4 insertions(+), 19 deletions(-) this breaks the code ./ffmpeg_g -i mm-short.mpg -i fate-suite/sub/MovText_capability_tester.mp4 -f hls -c:a aac -hls_segment_filename /tmp/file-v.low.%d.ts -t 10 /tmp/file-v.low.m3u8 ... ==5612== Invalid read of size 8 ==5612==at 0x800AC8: avformat_free_context (in ffmpeg/ffmpeg_g) ==5612==by 0x710A9B: hls_free_variant_streams.isra.12 (in ffmpeg/ffmpeg_g) ==5612==by 0x714EB3: hls_write_trailer (in ffmpeg/ffmpeg_g) ==5612==by 0x78341A: av_write_trailer (in ffmpeg/ffmpeg_g) ==5612==by 0x4D9E88: transcode (in ffmpeg/ffmpeg_g) ==5612==by 0x4B5D3C: main (in ffmpeg/ffmpeg_g) ==5612== Address 0x464b0c50 is 16 bytes inside a block of size 1,504 free'd ==5612==at 0x4C2B5D9: free (vg_replace_malloc.c:446) ==5612==by 0x800D97: avformat_free_context (in ffmpeg/ffmpeg_g) ==5612==by 0x714AF9: hls_write_trailer (in ffmpeg/ffmpeg_g) ==5612==by 0x78341A: av_write_trailer (in ffmpeg/ffmpeg_g) ==5612==by 0x4D9E88: transcode (in ffmpeg/ffmpeg_g) ==5612==by 0x4B5D3C: main (in ffmpeg/ffmpeg_g) ==5612== ==5612== Invalid read of size 8 ==5612==at 0x119430E: av_opt_free (in ffmpeg/ffmpeg_g) ==5612==by 0x800AF6: avformat_free_context (in ffmpeg/ffmpeg_g) ==5612==by 0x710A9B: hls_free_variant_streams.isra.12 (in ffmpeg/ffmpeg_g) ==5612==by 0x714EB3: hls_write_trailer (in ffmpeg/ffmpeg_g) ==5612==by 0x78341A: av_write_trailer (in ffmpeg/ffmpeg_g) ==5612==by 0x4D9E88: transcode (in ffmpeg/ffmpeg_g) ==5612==by 0x4B5D3C: main (in ffmpeg/ffmpeg_g) ==5612== Address 0x464b0c40 is 0 bytes inside a block of size 1,504 free'd ==5612==at 0x4C2B5D9: free (vg_replace_malloc.c:446) ==5612==by 0x800D97: avformat_free_context (in ffmpeg/ffmpeg_g) ==5612==by 0x714AF9: hls_write_trailer (in ffmpeg/ffmpeg_g) ==5612==by 0x78341A: av_write_trailer (in ffmpeg/ffmpeg_g) ==5612==by 0x4D9E88: transcode (in ffmpeg/ffmpeg_g) ==5612==by 0x4B5D3C: main (in ffmpeg/ffmpeg_g) ==5612== ==5612== Invalid read of size 8 ==5612==at 0x118EBA3: av_freep (in ffmpeg/ffmpeg_g) ==5612==by 0x119434E: av_opt_free (in ffmpeg/ffmpeg_g) ==5612==by 0x800AF6: avformat_free_context (in ffmpeg/ffmpeg_g) ==5612==by 0x710A9B: hls_free_variant_streams.isra.12 (in ffmpeg/ffmpeg_g) ==5612==by 0x714EB3: hls_write_trailer (in ffmpeg/ffmpeg_g) ==5612==by 0x78341A: av_write_trailer (in ffmpeg/ffmpeg_g) ==5612==by 0x4D9E88: transcode (in ffmpeg/ffmpeg_g) ==5612==by 0x4B5D3C: main (in ffmpeg/ffmpeg_g) ==5612== Address 0x464b10b8 is 1,144 bytes inside a block of size 1,504 free'd ==5612==at 0x4C2B5D9: free (vg_replace_malloc.c:446) ==5612==by 0x800D97: avformat_free_context (in ffmpeg/ffmpeg_g) ==5612==by 0x714AF9: hls_write_trailer (in ffmpeg/ffmpeg_g) ==5612==by 0x78341A: av_write_trailer (in ffmpeg/ffmpeg_g) ==5612==by 0x4D9E88: transcode (in ffmpeg/ffmpeg_g) ==5612==by 0x4B5D3C: main (in ffmpeg/ffmpeg_g) If you cannot reproduce, tell me and ill rerun this with full debug symbols (line numbers) thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Dictatorship naturally arises out of democracy, and the most aggravated form of tyranny and slavery out of the most extreme liberty. -- Plato signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 1/2] avcodec: add mvdv video decoder
ons 2019-11-27 klockan 20:00 +0100 skrev Paul B Mahol:
> On 11/27/19, James Almer wrote:
> > On 11/27/2019 3:42 PM, Paul B Mahol wrote:
> > > On 11/27/19, Tomas Härdin wrote:
> > > > tis 2019-11-26 klockan 20:29 +0100 skrev Paul B Mahol:
> > > > > On 11/26/19, James Almer wrote:
> > > > > > On 11/26/2019 6:47 AM, Paul B Mahol wrote:
> > > > > > > On 11/25/19, Tomas Härdin wrote:
> > > > > > > > mån 2019-11-25 klockan 22:09 +0100 skrev Paul B Mahol:
> > > > > > > > > Signed-off-by: Paul B Mahol
> > > > > > > > > +static int decode_mvdv(MidiVidContext *s, AVCodecContext
> > > > > > > > > *avctx,
> > > > > > > > > AVFrame
> > > > > > > > > *frame)
> > > > > > > > > +{
> > > > > > > > > +GetByteContext *gb = &s->gb;
> > > > > > > > > +GetBitContext mask;
> > > > > > > > > +GetByteContext idx9;
> > > > > > > > > +uint16_t nb_vectors, intra_flag;
> > > > > > > > > +const uint8_t *vec;
> > > > > > > > > +const uint8_t *mask_start;
> > > > > > > > > +uint8_t *skip;
> > > > > > > > > +int mask_size;
> > > > > > > > > +int idx9bits = 0;
> > > > > > > > > +int idx9val = 0;
> > > > > > > > > +int num_blocks;
> > > > > > > > > +
> > > > > > > > > +nb_vectors = bytestream2_get_le16(gb);
> > > > > > > > > +intra_flag = bytestream2_get_le16(gb);
> > > > > > > > > +if (intra_flag) {
> > > > > > > > > +num_blocks = (avctx->width / 2) * (avctx->height /
> > > > > > > > > 2);
> > > > > > > >
> > > > > > > > Will UB if width*height/4 > INT_MAX
> > > > > > > >
> > > > > > > > > +} else {
> > > > > > > > > +int skip_linesize;
> > > > > > > > > +
> > > > > > > > > +num_blocks = bytestream2_get_le32(gb);
> > > > > > > >
> > > > > > > > Might want to use uint32_t so this doesn't lead to weirdness on
> > > > > > > > 32-bit
> > > > > > > >
> > > > > > > > > +skip_linesize = avctx->width >> 1;
> > > > > > > > > +mask_start = gb->buffer_start + bytestream2_tell(gb);
> > > > > > > > > +mask_size = (avctx->width >> 5) * (avctx->height >>
> > > > > > > > > 2);
> > > > > > > >
> > > > > > > > This can also UB
> > > > > > > >
> > > > > > > > /Tomas
> > > > > > > >
> > > > > > >
> > > > > > > Nothing of this can actually happen.
> > > >
> > > > This assumes max_pixels will never be increased above INT_MAX. "64k"
> > > > video is most definitely within the range of possibility in the coming
> > > > years, if it isn't already. Film archival and DPX come to mind.
> > > >
> > > > > > It can and i'm fairly sure it will happen as soon as the fuzzer
> > > > > > starts
> > > > > > testing this decoder using big dimensions.
> > > > >
> > > > > I'm not that guy doing such work. Please stop bikesheding those
> > > > > patches for once.
> > > >
> > > > This reads like an admission of pushing insecure code via "not my
> > > > problem"
> > > >
> > > > > > You don't need asserts here, you just need to check the calculations
> > > > > > will not overflow. Do something like "if ((int64_t)avctx->width *
> > > > > > avctx->height / 4 > INT_MAX) return AVERROR_INVALIDDATA" and call
> > > > > > it a
> > > > > > day.
> > > > > > Also, maybe num_blocks should be unsigned, seeing you set it using
> > > > > > bytestream2_get_le32() for P-frames.
> > > > >
> > > > > No decoder does this.
> > > >
> > > > zmbv does
> > > >
> > > > All this is really about the lack of any way to reason about
> > > > assumptions like "dimensions can't be larger than X*Y" at compile time,
> > > > which is a thing I've been pointing out on this list for a while now.
> > > >
> > >
> > > Nobody tells you not to fix it yourself.
> >
> > Just add a the suggested overflow checks, Christ. It's a one line
> > addition each. What do you gain arguing like this?
>
> Than next day he or you will come with another great idea.
Great ideas like pushing inevitable 0days?
/Tomas
___
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] [aarch64] improve performance of ff_hscale_8_to_15_neon
On Wed, Nov 27, 2019 at 07:36:01PM +, Pop, Sebastian wrote: > Thanks Jean-Baptiste for your review and suggestions on how to improve my > patch submission. > From the git logs I found out that Clément Bœsch wrote the original aarch64 > vectorization for that function. > Maybe Clément could help to review the content of the patch? Yeah I will by the end of the week. I wrote that a few years ago so I need to take some time to get back in the context. BTW, that's quite a huge speed improvement you're bringing in, are you sure you are always allowed to read up to filter[3]? Last thing: this same optimization was also written for arm following the same pattern. You may want to adjust that one as well while waiting for my review :) Regards, -- Clément B. ___ 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] tools/target_dec_fuzzer: add support to fuzz bitstream filters
On Wed, Nov 27, 2019 at 01:17:34PM -0300, James Almer wrote: > On 11/27/2019 1:09 PM, Michael Niedermayer wrote: > > On Wed, Nov 27, 2019 at 11:41:09AM -0300, James Almer wrote: > >> On 9/3/2019 10:49 AM, James Almer wrote: > >>> On 8/30/2019 1:39 PM, James Almer wrote: > Signed-off-by: James Almer > --- > > > Untested. > > > > i can test if it applies > > > > > I'm also not sure how to add the FFMPEG_BSF define to tools/Makefile, > and have it coexist with FFMPEG_DECODER. Assuming it's needed. > > > > maybe something like > > tools/target_bsf_%_fuzzer.o: tools/target_dec_fuzzer.c > > $(COMPILE_C) -DFFMPEG_BSF=$* > > > > but maybe i misunderdtand ... > > But then what's the decoder used for it? Where is FFMPEG_CODEC defined > in the absence of FFMPEG_DECODER? do we need a decoder ? the code could take the codec_id from the bsf codec_ids [...] -- 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 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] [aarch64] improve performance of ff_hscale_8_to_15_neon
On Wed, Nov 27, 2019 at 2:13 PM Clément Bœsch wrote: > Yeah I will by the end of the week. I wrote that a few years ago so I need > to take some time to get back in the context. Thanks Clément for your help. > > BTW, that's quite a huge speed improvement you're bringing in, are you > sure you are always allowed to read up to filter[3]? I will check. Otherwise we can version the code and keep the existing code along for vector factor 2. > > Last thing: this same optimization was also written for arm following the > same pattern. You may want to adjust that one as well while waiting for my > review :) Thanks for pointing it out. I can submit a separate patch for that. I have also seen that ff_yuv2planeX_8_neon in libswscale/aarch64/output.S could be improved in a similar way, and that function appears on the critical path (for multi threaded encodes) and on the linux-perf profiles. Sebastian ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH v3 2/2] cmdutils: add show_help_protocol for get protocol options
On Wed, Nov 27, 2019 at 01:57:02PM +0800, Steven Liu wrote: > Signed-off-by: Steven Liu > --- > fftools/cmdutils.c | 14 ++ > fftools/ffmpeg_opt.c | 2 +- > 2 files changed, 15 insertions(+), 1 deletion(-) i think the patchset looks good, but maybe wait a bit before applying as it involves public API and others may have comments too Thanks [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB When the tyrant has disposed of foreign enemies by conquest or treaty, and there is nothing more to fear from them, then he is always stirring up some war or other, in order that the people may require a leader. -- Plato signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH v1 2/2] avfilter/vf_colorconstancy: av_frame_free(&in) in case of error or direct flag is false
On Wed, Nov 27, 2019 at 11:47:54AM +0100, Paul B Mahol wrote: > lgtm will apply thx [...] -- 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 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] tools/target_dec_fuzzer: add support to fuzz bitstream filters
On 11/27/2019 5:19 PM, Michael Niedermayer wrote: > On Wed, Nov 27, 2019 at 01:17:34PM -0300, James Almer wrote: >> On 11/27/2019 1:09 PM, Michael Niedermayer wrote: >>> On Wed, Nov 27, 2019 at 11:41:09AM -0300, James Almer wrote: On 9/3/2019 10:49 AM, James Almer wrote: > On 8/30/2019 1:39 PM, James Almer wrote: >> Signed-off-by: James Almer >> --- >>> >> Untested. >>> >>> i can test if it applies >>> >>> >> I'm also not sure how to add the FFMPEG_BSF define to tools/Makefile, >> and have it coexist with FFMPEG_DECODER. Assuming it's needed. >>> >>> maybe something like >>> tools/target_bsf_%_fuzzer.o: tools/target_dec_fuzzer.c >>> $(COMPILE_C) -DFFMPEG_BSF=$* >>> >>> but maybe i misunderdtand ... >> >> But then what's the decoder used for it? Where is FFMPEG_CODEC defined >> in the absence of FFMPEG_DECODER? > > do we need a decoder ? > the code could take the codec_id from the bsf codec_ids Not using a decoder would require writing a different tool just for bsfs, because the way it's implemented in this patch, it processes a packet with a bsf before passing it to a decoder. Also, some bsfs support more than one codec, so we still need to pass two arguments: a bfs, and a codec. We can't just pick the first codec_id reported by the bsf. So i again wonder how exactly does the glue work here, and how can we pass two values to any given fuzzer tool in tools/Makefile. ___ 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 03/23] avformat/matroskaenc: Use random TrackUID
On Wed, Nov 27, 2019 at 05:57:56PM +0100, Andreas Rheinhardt wrote:
> On Wed, Nov 27, 2019 at 4:50 PM Michael Niedermayer
> wrote:
>
> > On Wed, Nov 27, 2019 at 08:25:13AM +0100, Andreas Rheinhardt wrote:
> > > On Mon, Nov 25, 2019 at 2:57 PM Michael Niedermayer
> >
> > > wrote:
[...]
>
> >
> > [...]
> > > >
> > > > [...]
> > > > >
> > > > >
> > > > > > and, this
> > > > > > +/* Test the numbers from 1 to i. */
> > > > > > +for (int j = 1, k; j < i + 1; j++) {
> > > > > > +for (k = 0; k < i; k++) {
> > > > > > +if (tracks[k].uid == j)
> > > > > > +break;
> > > > > > +}
> > > > > > +if (k == i)
> > > > > > +return j;
> > > > > > +}
> > > > > >
> > > > > > just smells "wrong"
> > > > > >
> > > > > > This code would only be executed if using AVLFG would repeatedly
> > lead
> > > > to
> > > > > collisions;
> > > >
> > > > yes but this doesnt smell right
> > > > if your random number generator produces no random numbers i dont think
> > > > adding +1 is the solution.
> > > > I mean if that really happens, theres some bug either in LFG the seed
> > > > generation
> > > > or in how it is used.
> > > >
> > > > Yes, this code was only intended to be run if the random number
> > generator
> > > is completely buggy. But it seems that this can unfortunately not ruled
> > out
> > > completely (
> >
> > >
> > https://www.phoronix.com/scan.php?page=news_item&px=AMD-RdRand-Disable-15h-16h
> > > ).
> >
> > The fix to this does not belong into a caller of av_get_random_seed()
> > if thats fixed / worked around in CPU, Bios, OS, or in av_get_random_seed()
> > i dont know but definitly not the user of av_get_random_seed().
> > If av_get_random_seed() is bad thats bad and needs to be fixed
> >
> > Also lets assume av_get_random_seed() is bad and returns -1 always
> > or another constant.
> > The code still must not fail like this. the seeded PRNG must still
> > function properly and produce a few differentg values.
> > If its statistics are 100% duplicates thats a failure of the PRNG.
> >
> > First, are you saying that a caller can rely on the values being
> different so that I can simply remove the last-resort code and assert that
> everything is fine? (Or should I let the initial loop using AVLFG run until
> it has found a good value in the hope that it will terminate eventually?)
I expect the LFG to produce billions of distinct values for every seed.
If you find a seed for which it does not do this i would consider this a
bug and iam insterrested in such a case.
Distinct values may of course be non consecutive as one would expect
from random numbers
>
> Second, given that only one call to av_get_random_seed() is ever performed,
> the question of whether it always returns -1 is irrelevant here: If some
> seed exists that leads to these collisions, then it is possible for these
> collisions to happen even when the random seed is truly random (in such a
> case, it would be unlikely, of course). Is there such a seed? I don't know.
> I only know that if the state of the AVLFG is completely zero, then
> av_lfg_get() will always return zero. This is the only state with the
> property that the state is not altered by any av_lfg_get(), but this does
> not preclude the output to be e.g. periodic.
its not needed to be all zero. a pathological case already occurs if
all state values are even. I suspect that does not happen for any seed though.
its statistically unlikely.
Thanks
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
"Nothing to hide" only works if the folks in power share the values of
you and everyone you know entirely and always will -- Tom Scott
signature.asc
Description: PGP signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 1/2] avcodec: add mvdv video decoder
On 11/27/19, Tomas Härdin wrote:
> ons 2019-11-27 klockan 20:00 +0100 skrev Paul B Mahol:
>> On 11/27/19, James Almer wrote:
>> > On 11/27/2019 3:42 PM, Paul B Mahol wrote:
>> > > On 11/27/19, Tomas Härdin wrote:
>> > > > tis 2019-11-26 klockan 20:29 +0100 skrev Paul B Mahol:
>> > > > > On 11/26/19, James Almer wrote:
>> > > > > > On 11/26/2019 6:47 AM, Paul B Mahol wrote:
>> > > > > > > On 11/25/19, Tomas Härdin wrote:
>> > > > > > > > mån 2019-11-25 klockan 22:09 +0100 skrev Paul B Mahol:
>> > > > > > > > > Signed-off-by: Paul B Mahol
>> > > > > > > > > +static int decode_mvdv(MidiVidContext *s, AVCodecContext
>> > > > > > > > > *avctx,
>> > > > > > > > > AVFrame
>> > > > > > > > > *frame)
>> > > > > > > > > +{
>> > > > > > > > > +GetByteContext *gb = &s->gb;
>> > > > > > > > > +GetBitContext mask;
>> > > > > > > > > +GetByteContext idx9;
>> > > > > > > > > +uint16_t nb_vectors, intra_flag;
>> > > > > > > > > +const uint8_t *vec;
>> > > > > > > > > +const uint8_t *mask_start;
>> > > > > > > > > +uint8_t *skip;
>> > > > > > > > > +int mask_size;
>> > > > > > > > > +int idx9bits = 0;
>> > > > > > > > > +int idx9val = 0;
>> > > > > > > > > +int num_blocks;
>> > > > > > > > > +
>> > > > > > > > > +nb_vectors = bytestream2_get_le16(gb);
>> > > > > > > > > +intra_flag = bytestream2_get_le16(gb);
>> > > > > > > > > +if (intra_flag) {
>> > > > > > > > > +num_blocks = (avctx->width / 2) * (avctx->height
>> > > > > > > > > / 2);
>> > > > > > > >
>> > > > > > > > Will UB if width*height/4 > INT_MAX
>> > > > > > > >
>> > > > > > > > > +} else {
>> > > > > > > > > +int skip_linesize;
>> > > > > > > > > +
>> > > > > > > > > +num_blocks = bytestream2_get_le32(gb);
>> > > > > > > >
>> > > > > > > > Might want to use uint32_t so this doesn't lead to weirdness
>> > > > > > > > on
>> > > > > > > > 32-bit
>> > > > > > > >
>> > > > > > > > > +skip_linesize = avctx->width >> 1;
>> > > > > > > > > +mask_start = gb->buffer_start +
>> > > > > > > > > bytestream2_tell(gb);
>> > > > > > > > > +mask_size = (avctx->width >> 5) * (avctx->height
>> > > > > > > > > >> 2);
>> > > > > > > >
>> > > > > > > > This can also UB
>> > > > > > > >
>> > > > > > > > /Tomas
>> > > > > > > >
>> > > > > > >
>> > > > > > > Nothing of this can actually happen.
>> > > >
>> > > > This assumes max_pixels will never be increased above INT_MAX. "64k"
>> > > > video is most definitely within the range of possibility in the
>> > > > coming
>> > > > years, if it isn't already. Film archival and DPX come to mind.
>> > > >
>> > > > > > It can and i'm fairly sure it will happen as soon as the fuzzer
>> > > > > > starts
>> > > > > > testing this decoder using big dimensions.
>> > > > >
>> > > > > I'm not that guy doing such work. Please stop bikesheding those
>> > > > > patches for once.
>> > > >
>> > > > This reads like an admission of pushing insecure code via "not my
>> > > > problem"
>> > > >
>> > > > > > You don't need asserts here, you just need to check the
>> > > > > > calculations
>> > > > > > will not overflow. Do something like "if ((int64_t)avctx->width
>> > > > > > *
>> > > > > > avctx->height / 4 > INT_MAX) return AVERROR_INVALIDDATA" and
>> > > > > > call it a
>> > > > > > day.
>> > > > > > Also, maybe num_blocks should be unsigned, seeing you set it
>> > > > > > using
>> > > > > > bytestream2_get_le32() for P-frames.
>> > > > >
>> > > > > No decoder does this.
>> > > >
>> > > > zmbv does
>> > > >
>> > > > All this is really about the lack of any way to reason about
>> > > > assumptions like "dimensions can't be larger than X*Y" at compile
>> > > > time,
>> > > > which is a thing I've been pointing out on this list for a while
>> > > > now.
>> > > >
>> > >
>> > > Nobody tells you not to fix it yourself.
>> >
>> > Just add a the suggested overflow checks, Christ. It's a one line
>> > addition each. What do you gain arguing like this?
>>
>> Than next day he or you will come with another great idea.
>
> Great ideas like pushing inevitable 0days?
Very friendly reviews and developers.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 2/2] avfilter/vf_hqdn3d: add support for commands
Will apply. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] [libdav1d.c]: Add options for spatial layers.
On Wed, Nov 27, 2019 at 09:21:28 -0800, Thierry Foucu wrote:
> +@item oppoint
> +Select an operating point of a scalable AV1 bitstream (0 - 32)
[...]
> +{ "oppoint", "Select an operating point of the scalable bitstream",
> OFFSET(operating_point), AV_OPT_TYPE_INT, { .i64 = -1 }, 0, 31, VD },
0 to 31 or 0 to 32?
> +@item alllayer
> +Output all spatial layers of a scalable AV1 bitstream. The default value is
> false.
[...]
> +{ "alllayers", "Output all spatial layers", OFFSET(all_layers),
> AV_OPT_TYPE_BOOL, { .i64 = 0 }, 0, 1, VD },
"alllayers", not "alllayer"
Cheers,
Moritz
___
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] [libdav1d.c]: Add options for spatial layers.
On 11/27/2019 9:00 PM, Moritz Barsnick wrote:
> On Wed, Nov 27, 2019 at 09:21:28 -0800, Thierry Foucu wrote:
>> +@item oppoint
>> +Select an operating point of a scalable AV1 bitstream (0 - 32)
> [...]
>> +{ "oppoint", "Select an operating point of the scalable bitstream",
>> OFFSET(operating_point), AV_OPT_TYPE_INT, { .i64 = -1 }, 0, 31, VD },
>
> 0 to 31 or 0 to 32?
0 to 31. It's 32 operating points in total.
>
>> +@item alllayer
>> +Output all spatial layers of a scalable AV1 bitstream. The default value is
>> false.
> [...]
>> +{ "alllayers", "Output all spatial layers", OFFSET(all_layers),
>> AV_OPT_TYPE_BOOL, { .i64 = 0 }, 0, 1, VD },
> "alllayers", not "alllayer"
>
> Cheers,
> Moritz
> ___
> 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] [libdav1d.c]: Add options for spatial layers.
On Wed, Nov 27, 2019 at 4:02 PM James Almer wrote:
> On 11/27/2019 9:00 PM, Moritz Barsnick wrote:
> > On Wed, Nov 27, 2019 at 09:21:28 -0800, Thierry Foucu wrote:
> >> +@item oppoint
> >> +Select an operating point of a scalable AV1 bitstream (0 - 32)
> > [...]
> >> +{ "oppoint", "Select an operating point of the scalable
> bitstream", OFFSET(operating_point), AV_OPT_TYPE_INT, { .i64 = -1 }, 0, 31,
> VD },
> >
> > 0 to 31 or 0 to 32?
>
> 0 to 31. It's 32 operating points in total.
>
thanks..
Will update the patch
>
> >
> >> +@item alllayer
> >> +Output all spatial layers of a scalable AV1 bitstream. The default
> value is false.
> > [...]
> >> +{ "alllayers", "Output all spatial layers", OFFSET(all_layers),
> AV_OPT_TYPE_BOOL, { .i64 = 0 }, 0, 1, VD },
> > "alllayers", not "alllayer"
> >
>
Sorry, will update the patch.
> > Cheers,
> > Moritz
> > ___
> > ffmpeg-devel mailing list
> > ffmpeg-devel@ffmpeg.org
> > https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> >
> > To unsubscribe, visit link above, or email
> > ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
> >
>
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
> To unsubscribe, visit link above, or email
> ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH] [libdav1d.c]: Add options for spatial layers.
Disable by default to output all the layers, to match libaomdec wrapper.
Add option to select the operating point for the spatial layers.
Update the documentation with the new options.
---
doc/decoders.texi | 6 ++
libavcodec/libdav1d.c | 8
2 files changed, 14 insertions(+)
diff --git a/doc/decoders.texi b/doc/decoders.texi
index 676e062e72..234890e968 100644
--- a/doc/decoders.texi
+++ b/doc/decoders.texi
@@ -71,6 +71,12 @@ Set amount of tile threads to use during decoding. The
default value is 0 (autod
Apply film grain to the decoded video if present in the bitstream. Defaults to
the
internal default of the library.
+@item oppoint
+Select an operating point of a scalable AV1 bitstream (0 - 31)
+
+@item alllayers
+Output all spatial layers of a scalable AV1 bitstream. The default value is
false.
+
@end table
@section libdavs2
diff --git a/libavcodec/libdav1d.c b/libavcodec/libdav1d.c
index cf4b178f1d..ea4ef641bf 100644
--- a/libavcodec/libdav1d.c
+++ b/libavcodec/libdav1d.c
@@ -40,6 +40,8 @@ typedef struct Libdav1dContext {
int tile_threads;
int frame_threads;
int apply_grain;
+int operating_point;
+int all_layers;
} Libdav1dContext;
static const enum AVPixelFormat pix_fmt[][3] = {
@@ -134,6 +136,10 @@ static av_cold int libdav1d_init(AVCodecContext *c)
if (dav1d->apply_grain >= 0)
s.apply_grain = dav1d->apply_grain;
+s.all_layers = dav1d->all_layers;
+if (dav1d->operating_point >= 0)
+s.operating_point = dav1d->operating_point;
+
s.n_tile_threads = dav1d->tile_threads
? dav1d->tile_threads
: FFMIN(floor(sqrt(threads)), DAV1D_MAX_TILE_THREADS);
@@ -378,6 +384,8 @@ static const AVOption libdav1d_options[] = {
{ "tilethreads", "Tile threads", OFFSET(tile_threads), AV_OPT_TYPE_INT, {
.i64 = 0 }, 0, DAV1D_MAX_TILE_THREADS, VD },
{ "framethreads", "Frame threads", OFFSET(frame_threads), AV_OPT_TYPE_INT,
{ .i64 = 0 }, 0, DAV1D_MAX_FRAME_THREADS, VD },
{ "filmgrain", "Apply Film Grain", OFFSET(apply_grain), AV_OPT_TYPE_BOOL,
{ .i64 = -1 }, -1, 1, VD },
+{ "oppoint", "Select an operating point of the scalable bitstream",
OFFSET(operating_point), AV_OPT_TYPE_INT, { .i64 = -1 }, 0, 31, VD },
+{ "alllayers", "Output all spatial layers", OFFSET(all_layers),
AV_OPT_TYPE_BOOL, { .i64 = 0 }, 0, 1, VD },
{ NULL }
};
--
2.24.0.393.g34dc348eaf-goog
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] lavc/qsvenc: add Tiles encode support for HEVC
Hi,
> -Original Message-
> From: Fu, Linjie
> Sent: Tuesday, November 26, 2019 11:56
> To: ffmpeg-devel@ffmpeg.org
> Cc: Fu, Linjie
> Subject: [PATCH] lavc/qsvenc: add Tiles encode support for HEVC
>
> Add -tile_rows and -tile_cols option to specify the number of tile rows
> and columns for ICL+ (gen 11) platform.
>
> A tile must wholly contain all the slices within it. Slices cannot cross
> tile boundaries. So the slice number would be implicitly resized to the
> max(nSlice, nTile).
>
> Example:
> ffmpeg -v verbose -hwaccel qsv -init_hw_device qsv=hw
> -filter_hw_device hw -f rawvideo -s:v 1920x1080 -i ./input.nv12 -vf
> format=nv12,hwupload=extra_hw_frames=64 -c:v hevc_qsv -tile_rows 2
> -tile_cols 2 -slices 4 -y output.h265
>
> Also dump the actual quantity of encoded tiled rows and columns in run
> time.
>
> Fix the enhancement #8400.
>
> Signed-off-by: Linjie Fu
> ---
> libavcodec/qsvenc.c | 32 +++-
> libavcodec/qsvenc.h | 7 +++
> libavcodec/qsvenc_hevc.c | 3 +++
> 3 files changed, 41 insertions(+), 1 deletion(-)
>
> diff --git a/libavcodec/qsvenc.c b/libavcodec/qsvenc.c
> index e176d57..64814fc 100644
> --- a/libavcodec/qsvenc.c
> +++ b/libavcodec/qsvenc.c
> @@ -139,6 +139,9 @@ static void dump_video_param(AVCodecContext
> *avctx, QSVEncContext *q,
> #if QSV_HAVE_CO3
> mfxExtCodingOption3 *co3 = (mfxExtCodingOption3*)coding_opts[2];
> #endif
> +#if QSV_HAVE_EXT_HEVC_TILES
> +mfxExtHEVCTiles *exthevctiles = (mfxExtHEVCTiles *)coding_opts[3 +
> QSV_HAVE_CO_VPS];
> +#endif
>
> av_log(avctx, AV_LOG_VERBOSE, "profile: %s; level: %"PRIu16"\n",
> print_profile(info->CodecProfile), info->CodecLevel);
> @@ -204,6 +207,12 @@ static void dump_video_param(AVCodecContext
> *avctx, QSVEncContext *q,
> av_log(avctx, AV_LOG_VERBOSE, "RateDistortionOpt: %s\n",
> print_threestate(co->RateDistortionOpt));
>
> +#if QSV_HAVE_EXT_HEVC_TILES
> +if (avctx->codec_id == AV_CODEC_ID_HEVC)
> +av_log(avctx, AV_LOG_VERBOSE, "NumTileColumns: %"PRIu16";
> NumTileRows: %"PRIu16"\n",
> + exthevctiles->NumTileColumns, exthevctiles->NumTileRows);
> +#endif
> +
> #if QSV_HAVE_CO2
> av_log(avctx, AV_LOG_VERBOSE,
> "RecoveryPointSEI: %s IntRefType: %"PRIu16";
> IntRefCycleSize: %"PRIu16"; IntRefQPDelta: %"PRId16"\n",
> @@ -771,6 +780,16 @@ FF_ENABLE_DEPRECATION_WARNINGS
> }
> #endif
>
> +#if QSV_HAVE_EXT_HEVC_TILES
> +if (avctx->codec_id == AV_CODEC_ID_HEVC) {
> +q->exthevctiles.Header.BufferId = MFX_EXTBUFF_HEVC_TILES;
> +q->exthevctiles.Header.BufferSz = sizeof(q->exthevctiles);
> +q->exthevctiles.NumTileColumns = q->tile_cols;
> +q->exthevctiles.NumTileRows = q->tile_rows;
> +q->extparam_internal[q->nb_extparam_internal++] = (mfxExtBuffer
> *)&q->exthevctiles;
> +}
> +#endif
> +
> if (!check_enc_param(avctx,q)) {
> av_log(avctx, AV_LOG_ERROR,
> "some encoding parameters are not supported by the QSV "
> @@ -887,7 +906,14 @@ static int
> qsv_retrieve_enc_params(AVCodecContext *avctx, QSVEncContext *q)
> };
> #endif
>
> -mfxExtBuffer *ext_buffers[2 + QSV_HAVE_CO2 + QSV_HAVE_CO3 +
> QSV_HAVE_CO_VPS];
> +#if QSV_HAVE_EXT_HEVC_TILES
> +mfxExtHEVCTiles hevc_tile_buf = {
> + .Header.BufferId = MFX_EXTBUFF_HEVC_TILES,
> + .Header.BufferSz = sizeof(hevc_tile_buf),
> +};
> +#endif
> +
> +mfxExtBuffer *ext_buffers[2 + QSV_HAVE_CO2 + QSV_HAVE_CO3 +
> QSV_HAVE_CO_VPS + QSV_HAVE_EXT_HEVC_TILES];
>
> int need_pps = avctx->codec_id != AV_CODEC_ID_MPEG2VIDEO;
> int ret, ext_buf_num = 0, extradata_offset = 0;
> @@ -905,6 +931,10 @@ static int
> qsv_retrieve_enc_params(AVCodecContext *avctx, QSVEncContext *q)
> if (q->hevc_vps)
> ext_buffers[ext_buf_num++] = (mfxExtBuffer*)&extradata_vps;
> #endif
> +#if QSV_HAVE_EXT_HEVC_TILES
> +if (avctx->codec_id == AV_CODEC_ID_HEVC)
> +ext_buffers[ext_buf_num++] = (mfxExtBuffer*)&hevc_tile_buf;
> +#endif
>
> q->param.ExtParam= ext_buffers;
> q->param.NumExtParam = ext_buf_num;
> diff --git a/libavcodec/qsvenc.h b/libavcodec/qsvenc.h
> index ee35582..6609171 100644
> --- a/libavcodec/qsvenc.h
> +++ b/libavcodec/qsvenc.h
> @@ -38,6 +38,7 @@
> #define QSV_HAVE_CO3 QSV_VERSION_ATLEAST(1, 11)
> #define QSV_HAVE_CO_VPS QSV_VERSION_ATLEAST(1, 17)
>
> +#define QSV_HAVE_EXT_HEVC_TILES QSV_VERSION_ATLEAST(1, 13)
> #define QSV_HAVE_EXT_VP9_PARAM QSV_VERSION_ATLEAST(1, 26)
>
> #define QSV_HAVE_TRELLIS QSV_VERSION_ATLEAST(1, 8)
> @@ -124,6 +125,9 @@ typedef struct QSVEncContext {
> mfxExtMultiFrameParam extmfp;
> mfxExtMultiFrameControl extmfc;
> #endif
> +#if QSV_HAVE_EXT_HEVC_TILES
> +mfxExtHEVCTiles exthevctiles;
> +#endif
> #if QSV_HAVE_EXT_VP9_PARAM
> mfxExtVP9Param extvp9param;
> #endif
> @@ -161,6 +165,9 @@ typedef struct QSVEncContext {
>
[FFmpeg-devel] [PATCH v1 3/3] avfilter/vf_yadif: remove duplicate code with macro-based function
From: Limin Wang
Signed-off-by: Limin Wang
---
libavfilter/vf_yadif.c | 147 +++--
1 file changed, 54 insertions(+), 93 deletions(-)
diff --git a/libavfilter/vf_yadif.c b/libavfilter/vf_yadif.c
index f53bb77008..15d8c47b0b 100644
--- a/libavfilter/vf_yadif.c
+++ b/libavfilter/vf_yadif.c
@@ -91,101 +91,62 @@ typedef struct ThreadData {
next2++; \
}
-static void filter_line_c(void *dst1,
- void *prev1, void *cur1, void *next1,
- int w, int prefs, int mrefs, int parity, int mode)
-{
-uint8_t *dst = dst1;
-uint8_t *prev = prev1;
-uint8_t *cur = cur1;
-uint8_t *next = next1;
-int x;
-uint8_t *prev2 = parity ? prev : cur ;
-uint8_t *next2 = parity ? cur : next;
-
-/* The function is called with the pointers already pointing to data[3] and
- * with 6 subtracted from the width. This allows the FILTER macro to be
- * called so that it processes all the pixels normally. A constant value
of
- * true for is_not_edge lets the compiler ignore the if statement. */
-FILTER(0, w, 1)
+#define FILTER_LINE_FUNC(type, depth, bps)
\
+static void filter_line_c_##depth##bit(void *dst1,
\
+ void *prev1, void *cur1, void *next1,
\
+ int w, int prefs, int mrefs, int parity, int mode)
\
+{
\
+type *dst = dst1;
\
+type *prev = prev1;
\
+type *cur = cur1;
\
+type *next = next1;
\
+int x;
\
+type *prev2 = parity ? prev : cur ;
\
+type *next2 = parity ? cur : next;
\
+mrefs /= bps;
\
+prefs /= bps;
\
+
\
+/* The function is called with the pointers already pointing to data[3]
and */ \
+/* with 6 subtracted from the width. This allows the FILTER macro to be
*/\
+/* called so that it processes all the pixels normally. A constant value
of */ \
+/* true for is_not_edge lets the compiler ignore the if statement. */
\
+FILTER(0, w, 1)
\
}
+FILTER_LINE_FUNC(uint16_t, 16, 2);
+FILTER_LINE_FUNC(uint8_t, 8, 1);
#define MAX_ALIGN 8
-static void filter_edges(void *dst1, void *prev1, void *cur1, void *next1,
- int w, int prefs, int mrefs, int parity, int mode)
-{
-uint8_t *dst = dst1;
-uint8_t *prev = prev1;
-uint8_t *cur = cur1;
-uint8_t *next = next1;
-int x;
-uint8_t *prev2 = parity ? prev : cur ;
-uint8_t *next2 = parity ? cur : next;
-
-const int edge = MAX_ALIGN - 1;
-
-/* Only edge pixels need to be processed here. A constant value of false
- * for is_not_edge should let the compiler ignore the whole branch. */
-FILTER(0, 3, 0)
-
-dst = (uint8_t*)dst1 + w - edge;
-prev = (uint8_t*)prev1 + w - edge;
-cur = (uint8_t*)cur1 + w - edge;
-next = (uint8_t*)next1 + w - edge;
-prev2 = (uint8_t*)(parity ? prev : cur);
-next2 = (uint8_t*)(parity ? cur : next);
-
-FILTER(w - edge, w - 3, 1)
-FILTER(w - 3, w, 0)
-}
-
-
-static void filter_line_c_16bit(void *dst1,
-void *prev1, void *cur1, void *next1,
-int w, int prefs, int mrefs, int parity,
-int mode)
-{
-uint16_t *dst = dst1;
-uint16_t *prev = prev1;
-uint16_t *cur = cur1;
-uint16_t *next = next1;
-int x;
-uint16_t *prev2 = parity ? prev : cur ;
-uint16_t *next2 = parity ? cur : next;
-mrefs /= 2;
-prefs /= 2;
-
-FILTER(0, w, 1)
-}
-
-static void filter_edges_16bit(void *dst1, void *prev1, void *cur1, void
*next1,
- int w, int prefs, int mrefs, int parity, int
mode)
-{
-uint16_t *dst = dst1;
-uint16_t *prev = prev1;
-uint16_t *cur = cur1;
-uint16_t *next = next1;
-int x;
-uint16_t *prev2 = parity ? prev : cur ;
-uint16_t *next2 = parity ? cur : next;
-
-const int edge = MAX_ALIGN / 2 - 1;
-
-mrefs /= 2;
-prefs /= 2;
-
-FILTER(0, 3, 0)
-
-dst = (uint16_t*)dst1 + w - edge;
-prev = (uint16_t*)prev1 + w - edge;
-cur = (uint16_t*)cur1
[FFmpeg-devel] [PATCH v1 1/3] avfilter/vf_yadif: rename config_props -> config_input, link -> outlink
From: Limin Wang
Signed-off-by: Limin Wang
---
libavfilter/vf_yadif.c | 20 ++--
1 file changed, 10 insertions(+), 10 deletions(-)
diff --git a/libavfilter/vf_yadif.c b/libavfilter/vf_yadif.c
index 3107924932..0b34c5045b 100644
--- a/libavfilter/vf_yadif.c
+++ b/libavfilter/vf_yadif.c
@@ -311,26 +311,26 @@ static int query_formats(AVFilterContext *ctx)
return ff_set_common_formats(ctx, fmts_list);
}
-static int config_props(AVFilterLink *link)
+static int config_output(AVFilterLink *outlink)
{
-AVFilterContext *ctx = link->src;
+AVFilterContext *ctx = outlink->src;
YADIFContext *s = ctx->priv;
-link->time_base.num = ctx->inputs[0]->time_base.num;
-link->time_base.den = ctx->inputs[0]->time_base.den * 2;
-link->w = ctx->inputs[0]->w;
-link->h = ctx->inputs[0]->h;
+outlink->time_base.num = ctx->inputs[0]->time_base.num;
+outlink->time_base.den = ctx->inputs[0]->time_base.den * 2;
+outlink->w = ctx->inputs[0]->w;
+outlink->h = ctx->inputs[0]->h;
if(s->mode & 1)
-link->frame_rate = av_mul_q(ctx->inputs[0]->frame_rate,
+outlink->frame_rate = av_mul_q(ctx->inputs[0]->frame_rate,
(AVRational){2, 1});
-if (link->w < 3 || link->h < 3) {
+if (outlink->w < 3 || outlink->h < 3) {
av_log(ctx, AV_LOG_ERROR, "Video of less than 3 columns or lines is
not supported\n");
return AVERROR(EINVAL);
}
-s->csp = av_pix_fmt_desc_get(link->format);
+s->csp = av_pix_fmt_desc_get(outlink->format);
s->filter = filter;
if (s->csp->comp[0].depth > 8) {
s->filter_line = filter_line_c_16bit;
@@ -369,7 +369,7 @@ static const AVFilterPad avfilter_vf_yadif_outputs[] = {
.name = "default",
.type = AVMEDIA_TYPE_VIDEO,
.request_frame = ff_yadif_request_frame,
-.config_props = config_props,
+.config_props = config_output,
},
{ NULL }
};
--
2.21.0
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH v2 1/3] avfilter/vf_yadif: rename config_props -> config_output, link -> outlink
From: Limin Wang
Signed-off-by: Limin Wang
---
Sorry, fix the title typo
libavfilter/vf_yadif.c | 20 ++--
1 file changed, 10 insertions(+), 10 deletions(-)
diff --git a/libavfilter/vf_yadif.c b/libavfilter/vf_yadif.c
index 3107924932..0b34c5045b 100644
--- a/libavfilter/vf_yadif.c
+++ b/libavfilter/vf_yadif.c
@@ -311,26 +311,26 @@ static int query_formats(AVFilterContext *ctx)
return ff_set_common_formats(ctx, fmts_list);
}
-static int config_props(AVFilterLink *link)
+static int config_output(AVFilterLink *outlink)
{
-AVFilterContext *ctx = link->src;
+AVFilterContext *ctx = outlink->src;
YADIFContext *s = ctx->priv;
-link->time_base.num = ctx->inputs[0]->time_base.num;
-link->time_base.den = ctx->inputs[0]->time_base.den * 2;
-link->w = ctx->inputs[0]->w;
-link->h = ctx->inputs[0]->h;
+outlink->time_base.num = ctx->inputs[0]->time_base.num;
+outlink->time_base.den = ctx->inputs[0]->time_base.den * 2;
+outlink->w = ctx->inputs[0]->w;
+outlink->h = ctx->inputs[0]->h;
if(s->mode & 1)
-link->frame_rate = av_mul_q(ctx->inputs[0]->frame_rate,
+outlink->frame_rate = av_mul_q(ctx->inputs[0]->frame_rate,
(AVRational){2, 1});
-if (link->w < 3 || link->h < 3) {
+if (outlink->w < 3 || outlink->h < 3) {
av_log(ctx, AV_LOG_ERROR, "Video of less than 3 columns or lines is
not supported\n");
return AVERROR(EINVAL);
}
-s->csp = av_pix_fmt_desc_get(link->format);
+s->csp = av_pix_fmt_desc_get(outlink->format);
s->filter = filter;
if (s->csp->comp[0].depth > 8) {
s->filter_line = filter_line_c_16bit;
@@ -369,7 +369,7 @@ static const AVFilterPad avfilter_vf_yadif_outputs[] = {
.name = "default",
.type = AVMEDIA_TYPE_VIDEO,
.request_frame = ff_yadif_request_frame,
-.config_props = config_props,
+.config_props = config_output,
},
{ NULL }
};
--
2.21.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 v1 2/3] avfilter/vf_yadif: cosmetics
From: Limin Wang
Signed-off-by: Limin Wang
---
libavfilter/vf_yadif.c | 47 +++---
1 file changed, 12 insertions(+), 35 deletions(-)
diff --git a/libavfilter/vf_yadif.c b/libavfilter/vf_yadif.c
index 0b34c5045b..f53bb77008 100644
--- a/libavfilter/vf_yadif.c
+++ b/libavfilter/vf_yadif.c
@@ -265,42 +265,19 @@ static av_cold void uninit(AVFilterContext *ctx)
static int query_formats(AVFilterContext *ctx)
{
static const enum AVPixelFormat pix_fmts[] = {
-AV_PIX_FMT_YUV420P,
-AV_PIX_FMT_YUV422P,
-AV_PIX_FMT_YUV444P,
-AV_PIX_FMT_YUV410P,
-AV_PIX_FMT_YUV411P,
-AV_PIX_FMT_GRAY8,
-AV_PIX_FMT_YUVJ420P,
-AV_PIX_FMT_YUVJ422P,
-AV_PIX_FMT_YUVJ444P,
-AV_PIX_FMT_GRAY16,
-AV_PIX_FMT_YUV440P,
+AV_PIX_FMT_YUV420P, AV_PIX_FMT_YUV422P, AV_PIX_FMT_YUV444P,
+AV_PIX_FMT_YUV410P, AV_PIX_FMT_YUV411P, AV_PIX_FMT_YUV440P,
+AV_PIX_FMT_GRAY8, AV_PIX_FMT_GRAY16,
+AV_PIX_FMT_YUVJ420P, AV_PIX_FMT_YUVJ422P, AV_PIX_FMT_YUVJ444P,
AV_PIX_FMT_YUVJ440P,
-AV_PIX_FMT_YUV420P9,
-AV_PIX_FMT_YUV422P9,
-AV_PIX_FMT_YUV444P9,
-AV_PIX_FMT_YUV420P10,
-AV_PIX_FMT_YUV422P10,
-AV_PIX_FMT_YUV444P10,
-AV_PIX_FMT_YUV420P12,
-AV_PIX_FMT_YUV422P12,
-AV_PIX_FMT_YUV444P12,
-AV_PIX_FMT_YUV420P14,
-AV_PIX_FMT_YUV422P14,
-AV_PIX_FMT_YUV444P14,
-AV_PIX_FMT_YUV420P16,
-AV_PIX_FMT_YUV422P16,
-AV_PIX_FMT_YUV444P16,
-AV_PIX_FMT_YUVA420P,
-AV_PIX_FMT_YUVA422P,
-AV_PIX_FMT_YUVA444P,
-AV_PIX_FMT_GBRP,
-AV_PIX_FMT_GBRP9,
-AV_PIX_FMT_GBRP10,
-AV_PIX_FMT_GBRP12,
-AV_PIX_FMT_GBRP14,
-AV_PIX_FMT_GBRP16,
+AV_PIX_FMT_YUV420P9, AV_PIX_FMT_YUV422P9, AV_PIX_FMT_YUV444P9,
+AV_PIX_FMT_YUV420P10, AV_PIX_FMT_YUV422P10, AV_PIX_FMT_YUV444P10,
+AV_PIX_FMT_YUV420P12, AV_PIX_FMT_YUV422P12, AV_PIX_FMT_YUV444P12,
+AV_PIX_FMT_YUV420P14, AV_PIX_FMT_YUV422P14, AV_PIX_FMT_YUV444P14,
+AV_PIX_FMT_YUV420P16, AV_PIX_FMT_YUV422P16, AV_PIX_FMT_YUV444P16,
+AV_PIX_FMT_YUVA420P, AV_PIX_FMT_YUVA422P, AV_PIX_FMT_YUVA444P,
+AV_PIX_FMT_GBRP, AV_PIX_FMT_GBRP9, AV_PIX_FMT_GBRP10,
+AV_PIX_FMT_GBRP12, AV_PIX_FMT_GBRP14, AV_PIX_FMT_GBRP16,
AV_PIX_FMT_GBRAP,
AV_PIX_FMT_NONE
};
--
2.21.0
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH v1] avcodec/vaapi: set more flags for VASurfaceAttrib
Ping for the 2nd time. Thanks.
> -Original Message-
> From: Wang, Fei W
> Sent: Friday, November 22, 2019 1:45 PM
> To: FFmpeg development discussions and patches de...@ffmpeg.org>; myp...@gmail.com
> Subject: RE: [FFmpeg-devel] [PATCH v1] avcodec/vaapi: set more flags for
> VASurfaceAttrib
>
> Ping, any other comments of this patch? Thanks.
>
> > -Original Message-
> > From: ffmpeg-devel On Behalf Of
> > Wang, Fei W
> > Sent: Wednesday, November 20, 2019 10:40 AM
> > To: myp...@gmail.com; FFmpeg development discussions and patches
> >
> > Subject: 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/li
> > nux/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/d73f06270600c37c74beeceac37f5
> > 93838ced383/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".
___
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] lavf/movenc: Replace dts by pts to calculate duration
In this case, the input video is of dynamic frame rate and we don't want to
duplicate or drop frames, but the output video duration calculated by DTS is
incorrect, I solved it by using PTS.
There are many UGC videos with dynamic frame rates, which are represented by
PTS jumps. After transcoding with ffmpeg -vsync 0 or -vsync 2, the output
video duration becomes longer.By reading the code of x264/encoder/encoder.c,
I found that in order to predict the B frame, x264 needs to ensure that there
are enough reference frames when DTS = 0, so the DTS of these reference frames
will subtract the cache time. However, the cache time includes the part of PTS
jumps, which results in the abnormal small DTS.
Signed-off-by: Mengyang Yuan
---
libavformat/movenc.c | 23 ++-
libavformat/movenc.h | 2 ++
tests/ref/fate/binsub-movtextenc | 2 +-
tests/ref/fate/movenc| 20 ++--
tests/ref/lavf/mov | 4 ++--
tests/ref/lavf/mp4 | 4 ++--
6 files changed, 31 insertions(+), 24 deletions(-)
diff --git a/libavformat/movenc.c b/libavformat/movenc.c
index 715bec1c2f..206aa48d8c 100644
--- a/libavformat/movenc.c
+++ b/libavformat/movenc.c
@@ -1015,7 +1015,7 @@ static int get_cluster_duration(MOVTrack *track, int
cluster_idx)
return 0;
if (cluster_idx + 1 == track->entry)
-next_dts = track->track_duration + track->start_dts;
+next_dts = track->end_dts;
else
next_dts = track->cluster[cluster_idx + 1].dts;
@@ -5149,8 +5149,7 @@ static int mov_flush_fragment(AVFormatContext *s, int
force)
mov->mdat_size = 0;
for (i = 0; i < mov->nb_streams; i++) {
if (mov->tracks[i].entry)
-mov->tracks[i].frag_start += mov->tracks[i].start_dts +
- mov->tracks[i].track_duration -
+mov->tracks[i].frag_start += mov->tracks[i].end_dts -
mov->tracks[i].cluster[0].dts;
mov->tracks[i].entry = 0;
mov->tracks[i].end_reliable = 0;
@@ -5208,7 +5207,7 @@ static int mov_flush_fragment(AVFormatContext *s, int
force)
int64_t duration = 0;
if (track->entry)
-duration = track->start_dts + track->track_duration -
+duration = track->end_dts -
track->cluster[0].dts;
if (mov->flags & FF_MOV_FLAG_SEPARATE_MOOF) {
if (!track->mdat_buf)
@@ -5281,7 +5280,7 @@ static int check_pkt(AVFormatContext *s, AVPacket *pkt)
ref = trk->cluster[trk->entry - 1].dts;
} else if ( trk->start_dts != AV_NOPTS_VALUE
&& !trk->frag_discont) {
-ref = trk->start_dts + trk->track_duration;
+ref = trk->end_dts;
} else
ref = pkt->dts; // Skip tests for the first packet
@@ -5494,7 +5493,7 @@ int ff_mov_write_packet(AVFormatContext *s, AVPacket *pkt)
* of the last packet of the previous fragment based on
track_duration,
* which might not exactly match our dts. Therefore adjust the dts
* of this packet to be what the previous packets duration
implies. */
-trk->cluster[trk->entry].dts = trk->start_dts +
trk->track_duration;
+trk->cluster[trk->entry].dts = trk->end_dts;
/* We also may have written the pts and the corresponding duration
* in sidx/tfrf/tfxd tags; make sure the sidx pts and duration
match up with
* the next fragment. This means the cts of the first sample must
@@ -5546,13 +5545,17 @@ int ff_mov_write_packet(AVFormatContext *s, AVPacket
*pkt)
"this case.\n",
pkt->stream_index, pkt->dts);
}
-trk->track_duration = pkt->dts - trk->start_dts + pkt->duration;
-trk->last_sample_is_subtitle_end = 0;
-
if (pkt->pts == AV_NOPTS_VALUE) {
av_log(s, AV_LOG_WARNING, "pts has no value\n");
pkt->pts = pkt->dts;
}
+if (trk->start_pts == AV_NOPTS_VALUE) {
+trk->start_pts = pkt->pts;
+}
+trk->track_duration = FFMAX(pkt->pts - trk->start_pts + pkt->duration,
trk->track_duration);
+trk->end_dts = pkt->dts + pkt->duration;
+trk->last_sample_is_subtitle_end = 0;
+
if (pkt->dts != pkt->pts)
trk->flags |= MOV_TRACK_CTTS;
trk->cluster[trk->entry].cts = pkt->pts - pkt->dts;
@@ -6295,7 +6298,9 @@ static int mov_init(AVFormatContext *s)
* this is updated. */
track->hint_track = -1;
track->start_dts = AV_NOPTS_VALUE;
+track->start_pts = AV_NOPTS_VALUE;
track->start_cts = AV_NOPTS_VALUE;
+track->end_dts= AV_NOPTS_VALUE;
track->end_pts= AV_NOPTS_VALUE;
track->dts_shift = AV_NOPTS_VALUE;
if (st->codecpar->codec_type == AVMEDIA_TYPE_VIDEO) {
diff --git a/libavformat/movenc.h b/libavformat/movenc.h
index 68d6f23a5a..ddad263
Re: [FFmpeg-devel] [PATCH] avformat/hlsenc: remove duplicate code block
> 在 2019年11月28日，04:06，Michael Niedermayer 写道： > > mm-short.mpg Hi Michael, Where should i download the file mm-short.mpg? Thanks Steven ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH v2] avfilter: Add tonemap vaapi filter for H2S
Hi Carl,
> -Original Message-
> From: ffmpeg-devel On Behalf Of Carl
> Eugen Hoyos
> Sent: Wednesday, November 27, 2019 6:14 PM
> To: FFmpeg development discussions and patches
> Subject: Re: [FFmpeg-devel] [PATCH v2] avfilter: Add tonemap vaapi filter for
> H2S
>
> Am Mi., 27. Nov. 2019 um 10:51 Uhr schrieb Xinpeng Sun
> :
> >
> > It performs HDR(High Dynamic Range) to SDR(Standard Dynamic Range)
> > conversion with tone-mapping. It only supports HDR10 as input temporarily.
> >
> > An example command to use this filter with vaapi codecs:
> > FFMPEG -hwaccel vaapi -vaapi_device /dev/dri/renderD128
> > -hwaccel_output_format vaapi \ -i INPUT -vf
> > 'tonemap_vaapi=format=p010' -c:v hevc_vaapi -profile 2 OUTPUT
>
> Why is HDR10 -> P010 (10bit -> 10 bit) called H2S?
It is P010 SDR here. SDR is not necessarily related to 8bit or 10bit.
Here is a reference you might be interested in:
https://www.itu.int/pub/R-REP-BT.2390
>
> [...]
>
> > +if (input_frame->color_trc != AVCOL_TRC_SMPTE2084) {
> > +av_log(avctx, AV_LOG_ERROR, "Only support HDR10 as input for vaapi
> tone-mapping\n");
> > +return AVERROR(EINVAL);
>
> Shouldn't this also accept unknown trc?
> (With a warning)
Sorry if I misunderstand "unknown trc". Did you mean the trc undefined by
ffmpeg or the trc unsupported by the driver?
If it is the former, it has been checked in tonemap_vaapi_init().
>
> [...]
>
> > +{ "format", "Output pixel format set",
> > + OFFSET(output_format_string), AV_OPT_TYPE_STRING, .flags = FLAGS,
> > + "format" },
>
> Sorry if I misremember how this is done for other filters:
> Shouldn't the output format be set by the filter chain or the format filter?
>
> Carl Eugen
If I got it correctly, what you mean is setting the filter parameters by
-vf"tonemap_vaapi, format=p010" instead of -vf"tonemap_vaapi=format=p010"?
In my opinion, from the perspective of transcoding, it is better to finish the
complete pipeline in hw. This "format" option is used to set hw output surface
format
for the tonemap_vaapi filter, so that the trancode pipeline can work in video
memory without any sw color space convertion.
Thanks,
Xinpeng
> ___
> 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] [libdav1d.c]: Add options for spatial layers.
Thierry Foucu:
> Disable by default to output all the layers, to match libaomdec wrapper.
> Add option to select the operating point for the spatial layers.
> Update the documentation with the new options.
> ---
> doc/decoders.texi | 6 ++
> libavcodec/libdav1d.c | 8
> 2 files changed, 14 insertions(+)
>
> diff --git a/doc/decoders.texi b/doc/decoders.texi
> index 676e062e72..86c899b5be 100644
> --- a/doc/decoders.texi
> +++ b/doc/decoders.texi
> @@ -71,6 +71,12 @@ Set amount of tile threads to use during decoding. The
> default value is 0 (autod
> Apply film grain to the decoded video if present in the bitstream. Defaults
> to the
> internal default of the library.
>
> +@item oppoint
> +Select an operating point of a scalable AV1 bitstream (0 - 32)
Should be 0 - 31.
> +
> +@item alllayer
> +Output all spatial layers of a scalable AV1 bitstream. The default value is
> false.
> +
> @end table
>
> @section libdavs2
> diff --git a/libavcodec/libdav1d.c b/libavcodec/libdav1d.c
> index cf4b178f1d..ea4ef641bf 100644
> --- a/libavcodec/libdav1d.c
> +++ b/libavcodec/libdav1d.c
> @@ -40,6 +40,8 @@ typedef struct Libdav1dContext {
> int tile_threads;
> int frame_threads;
> int apply_grain;
> +int operating_point;
> +int all_layers;
> } Libdav1dContext;
>
> static const enum AVPixelFormat pix_fmt[][3] = {
> @@ -134,6 +136,10 @@ static av_cold int libdav1d_init(AVCodecContext *c)
> if (dav1d->apply_grain >= 0)
> s.apply_grain = dav1d->apply_grain;
>
> +s.all_layers = dav1d->all_layers;
> +if (dav1d->operating_point >= 0)
> +s.operating_point = dav1d->operating_point;
> +
> s.n_tile_threads = dav1d->tile_threads
> ? dav1d->tile_threads
> : FFMIN(floor(sqrt(threads)), DAV1D_MAX_TILE_THREADS);
> @@ -378,6 +384,8 @@ static const AVOption libdav1d_options[] = {
> { "tilethreads", "Tile threads", OFFSET(tile_threads), AV_OPT_TYPE_INT,
> { .i64 = 0 }, 0, DAV1D_MAX_TILE_THREADS, VD },
> { "framethreads", "Frame threads", OFFSET(frame_threads),
> AV_OPT_TYPE_INT, { .i64 = 0 }, 0, DAV1D_MAX_FRAME_THREADS, VD },
> { "filmgrain", "Apply Film Grain", OFFSET(apply_grain),
> AV_OPT_TYPE_BOOL, { .i64 = -1 }, -1, 1, VD },
> +{ "oppoint", "Select an operating point of the scalable bitstream",
> OFFSET(operating_point), AV_OPT_TYPE_INT, { .i64 = -1 }, 0, 31, VD },
If I am not mistaken, it is not possible (you get an error message and
the default value is not set) to have a default value outside of the
range of allowed values. That is because write_number() which performs
the range checks in libavutil/opt.c is also called to write the
default values. Would be nice if you could make having a default value
outside of the range of allowed values work.
I can't comment on the rest of the patch, being entirely unfamiliar
with dav1d.
- Andreas
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH 2/2] libswscale/x86/yuv2rgb: add ssse3 version
Signed-off-by: Ting Fu --- libswscale/x86/yuv2rgb.c | 5 + libswscale/x86/yuv2rgb_template.c | 58 ++- libswscale/x86/yuv_2_rgb.asm | 163 +++--- 3 files changed, 208 insertions(+), 18 deletions(-) diff --git a/libswscale/x86/yuv2rgb.c b/libswscale/x86/yuv2rgb.c index 70412a3914..d983934762 100644 --- a/libswscale/x86/yuv2rgb.c +++ b/libswscale/x86/yuv2rgb.c @@ -61,6 +61,11 @@ DECLARE_ASM_CONST(8, uint64_t, pb_07) = 0x0707070707070707ULL; #define COMPILE_TEMPLATE_MMXEXT 1 #endif /* HAVE_MMXEXT */ +//SSSE3 versions +#if HAVE_SSSE3 +#define COMPILE_TEMPLATE_SSSE3 1 +#endif + #include "yuv2rgb_template.c" av_cold SwsFunc ff_yuv2rgb_init_x86(SwsContext *c) diff --git a/libswscale/x86/yuv2rgb_template.c b/libswscale/x86/yuv2rgb_template.c index efe6356f30..fe586047f0 100644 --- a/libswscale/x86/yuv2rgb_template.c +++ b/libswscale/x86/yuv2rgb_template.c @@ -40,6 +40,30 @@ const uint8_t *pv = src[2] + (y >> vshift) * srcStride[2]; \ x86_reg index = -h_size / 2; \ +extern void ff_yuv_420_rgb24_ssse3(x86_reg index, uint8_t *image, const uint8_t *pu_index, + const uint8_t *pv_index, const uint8_t *pointer_c_dither, + const uint8_t *py_2index); +extern void ff_yuv_420_bgr24_ssse3(x86_reg index, uint8_t *image, const uint8_t *pu_index, + const uint8_t *pv_index, const uint8_t *pointer_c_dither, + const uint8_t *py_2index); +extern void ff_yuv_420_rgb15_ssse3(x86_reg index, uint8_t *image, const uint8_t *pu_index, + const uint8_t *pv_index, const uint8_t *pointer_c_dither, + const uint8_t *py_2index); +extern void ff_yuv_420_rgb16_ssse3(x86_reg index, uint8_t *image, const uint8_t *pu_index, + const uint8_t *pv_index, const uint8_t *pointer_c_dither, + const uint8_t *py_2index); +extern void ff_yuv_420_rgb32_ssse3(x86_reg index, uint8_t *image, const uint8_t *pu_index, + const uint8_t *pv_index, const uint8_t *pointer_c_dither, + const uint8_t *py_2index); +extern void ff_yuv_420_bgr32_ssse3(x86_reg index, uint8_t *image, const uint8_t *pu_index, + const uint8_t *pv_index, const uint8_t *pointer_c_dither, + const uint8_t *py_2index); +extern void ff_yuva_420_rgb32_ssse3(x86_reg index, uint8_t *image, const uint8_t *pu_index, +const uint8_t *pv_index, const uint8_t *pointer_c_dither, +const uint8_t *py_2index, const uint8_t *pa_2index); +extern void ff_yuva_420_bgr32_ssse3(x86_reg index, uint8_t *image, const uint8_t *pu_index, +const uint8_t *pv_index, const uint8_t *pointer_c_dither, +const uint8_t *py_2index, const uint8_t *pa_2index); extern void ff_yuv_420_rgb24_mmxext(x86_reg index, uint8_t *image, const uint8_t *pu_index, const uint8_t *pv_index, const uint8_t *pointer_c_dither, const uint8_t *py_2index); @@ -84,7 +108,12 @@ static inline int yuv420_rgb15(SwsContext *c, const uint8_t *src[], c->greenDither = ff_dither8[y & 1]; c->redDither = ff_dither8[(y + 1) & 1]; #endif + +#if COMPILE_TEMPLATE_SSSE3 +ff_yuv_420_rgb15_ssse3(index, image, pu - index, pv - index, &(c->redDither), py - 2 * index); +#else ff_yuv_420_rgb15_mmx(index, image, pu - index, pv - index, &(c->redDither), py - 2 * index); +#endif } return srcSliceH; } @@ -102,7 +131,12 @@ static inline int yuv420_rgb16(SwsContext *c, const uint8_t *src[], c->greenDither = ff_dither4[y & 1]; c->redDither = ff_dither8[(y + 1) & 1]; #endif + +#if COMPILE_TEMPLATE_SSSE3 +ff_yuv_420_rgb16_ssse3(index, image, pu - index, pv - index, &(c->redDither), py - 2 * index); +#else ff_yuv_420_rgb16_mmx(index, image, pu - index, pv - index, &(c->redDither), py - 2 * index); +#endif } return srcSliceH; } @@ -115,7 +149,9 @@ static inline int yuv420_rgb24(SwsContext *c, const uint8_t *src[], int y, h_size, vshift; YUV2RGB_LOOP(3) -#if COMPILE_TEMPLATE_MMXEXT +#if COMPILE_TEMPLATE_SSSE3 +ff_yuv_420_rgb24_ssse3(index, image, pu - index, pv - index, &(c->redDither), py - 2 * index); +#elif COMPILE_TEMPLATE_MMXEXT ff_yuv_420_rgb24_mmxext(index, image, pu - index, pv - index, &(c->redDither), py - 2 * index); #else ff_yuv_420_rgb24_mmx(index, image, pu - index, pv - index, &(c->redDither), py - 2 * index); @@ -132,7 +168,9 @@ static inline int yuv420_bgr24(SwsContext *c, const uint8_t *src[], int y, h_size, vshif
[FFmpeg-devel] [PATCH 1/2] libswscale/x86/yuv2rgb: Change inline assembly into nasm code
Signed-off-by: Ting Fu
---
libswscale/x86/Makefile | 1 +
libswscale/x86/swscale.c | 16 +-
libswscale/x86/yuv2rgb.c | 81 ++
libswscale/x86/yuv2rgb_template.c | 441 ++
libswscale/x86/yuv_2_rgb.asm | 270 ++
5 files changed, 394 insertions(+), 415 deletions(-)
create mode 100644 libswscale/x86/yuv_2_rgb.asm
diff --git a/libswscale/x86/Makefile b/libswscale/x86/Makefile
index f317d5dd9b..831d5359aa 100644
--- a/libswscale/x86/Makefile
+++ b/libswscale/x86/Makefile
@@ -12,3 +12,4 @@ X86ASM-OBJS += x86/input.o
\
x86/output.o \
x86/scale.o \
x86/rgb_2_rgb.o \
+ x86/yuv_2_rgb.o \
diff --git a/libswscale/x86/swscale.c b/libswscale/x86/swscale.c
index 0eed4f18d5..e9d474a1e8 100644
--- a/libswscale/x86/swscale.c
+++ b/libswscale/x86/swscale.c
@@ -29,6 +29,14 @@
#include "libavutil/cpu.h"
#include "libavutil/pixdesc.h"
+const DECLARE_ALIGNED(8, uint64_t, ff_dither4)[2] = {
+0x0103010301030103LL,
+0x0200020002000200LL,};
+
+const DECLARE_ALIGNED(8, uint64_t, ff_dither8)[2] = {
+0x0602060206020602LL,
+0x0004000400040004LL,};
+
#if HAVE_INLINE_ASM
#define DITHER1XBPP
@@ -38,14 +46,6 @@ DECLARE_ASM_CONST(8, uint64_t, bFC)=
0xFCFCFCFCFCFCFCFCLL;
DECLARE_ASM_CONST(8, uint64_t, w10)= 0x0010001000100010LL;
DECLARE_ASM_CONST(8, uint64_t, w02)= 0x0002000200020002LL;
-const DECLARE_ALIGNED(8, uint64_t, ff_dither4)[2] = {
-0x0103010301030103LL,
-0x0200020002000200LL,};
-
-const DECLARE_ALIGNED(8, uint64_t, ff_dither8)[2] = {
-0x0602060206020602LL,
-0x0004000400040004LL,};
-
DECLARE_ASM_CONST(8, uint64_t, b16Mask)= 0x001F001F001F001FLL;
DECLARE_ASM_CONST(8, uint64_t, g16Mask)= 0x07E007E007E007E0LL;
DECLARE_ASM_CONST(8, uint64_t, r16Mask)= 0xF800F800F800F800LL;
diff --git a/libswscale/x86/yuv2rgb.c b/libswscale/x86/yuv2rgb.c
index 5e2f77c20f..70412a3914 100644
--- a/libswscale/x86/yuv2rgb.c
+++ b/libswscale/x86/yuv2rgb.c
@@ -37,7 +37,7 @@
#include "libavutil/x86/cpu.h"
#include "libavutil/cpu.h"
-#if HAVE_INLINE_ASM
+#if HAVE_X86ASM
#define DITHER1XBPP // only for MMX
@@ -50,70 +50,49 @@ DECLARE_ASM_CONST(8, uint64_t, pb_03) =
0x0303030303030303ULL;
DECLARE_ASM_CONST(8, uint64_t, pb_07) = 0x0707070707070707ULL;
//MMX versions
-#if HAVE_MMX_INLINE && HAVE_6REGS
-#undef RENAME
+#if HAVE_MMX
#undef COMPILE_TEMPLATE_MMXEXT
#define COMPILE_TEMPLATE_MMXEXT 0
-#define RENAME(a) a ## _mmx
-#include "yuv2rgb_template.c"
-#endif /* HAVE_MMX_INLINE && HAVE_6REGS */
+#endif /* HAVE_MMX */
// MMXEXT versions
-#if HAVE_MMXEXT_INLINE && HAVE_6REGS
-#undef RENAME
+#if HAVE_MMXEXT
#undef COMPILE_TEMPLATE_MMXEXT
#define COMPILE_TEMPLATE_MMXEXT 1
-#define RENAME(a) a ## _mmxext
-#include "yuv2rgb_template.c"
-#endif /* HAVE_MMXEXT_INLINE && HAVE_6REGS */
+#endif /* HAVE_MMXEXT */
-#endif /* HAVE_INLINE_ASM */
+#include "yuv2rgb_template.c"
av_cold SwsFunc ff_yuv2rgb_init_x86(SwsContext *c)
{
-#if HAVE_MMX_INLINE && HAVE_6REGS
int cpu_flags = av_get_cpu_flags();
-#if HAVE_MMXEXT_INLINE
-if (INLINE_MMXEXT(cpu_flags)) {
-switch (c->dstFormat) {
-case AV_PIX_FMT_RGB24:
-return yuv420_rgb24_mmxext;
-case AV_PIX_FMT_BGR24:
-return yuv420_bgr24_mmxext;
-}
-}
+switch (c->dstFormat) {
+case AV_PIX_FMT_RGB32:
+if (c->srcFormat == AV_PIX_FMT_YUVA420P) {
+#if CONFIG_SWSCALE_ALPHA
+return yuva420_rgb32;
#endif
-
-if (INLINE_MMX(cpu_flags)) {
-switch (c->dstFormat) {
-case AV_PIX_FMT_RGB32:
-if (c->srcFormat == AV_PIX_FMT_YUVA420P) {
-#if HAVE_7REGS && CONFIG_SWSCALE_ALPHA
-return yuva420_rgb32_mmx;
-#endif
-break;
-} else
-return yuv420_rgb32_mmx;
-case AV_PIX_FMT_BGR32:
-if (c->srcFormat == AV_PIX_FMT_YUVA420P) {
-#if HAVE_7REGS && CONFIG_SWSCALE_ALPHA
-return yuva420_bgr32_mmx;
+break;
+} else
+return yuv420_rgb32;
+case AV_PIX_FMT_BGR32:
+if (c->srcFormat == AV_PIX_FMT_YUVA420P) {
+#if CONFIG_SWSCALE_ALPHA
+return yuva420_bgr32;
#endif
-break;
-} else
-return yuv420_bgr32_mmx;
-case AV_PIX_FMT_RGB24:
-return yuv420_rgb24_mmx;
-case AV_PIX_FMT_BGR24:
-return yuv420_bgr24_mmx;
-case AV_PIX_FMT_RGB565:
-return yuv420_rgb16_mmx;
-case AV_PIX_FMT_RGB555:
-return yuv420_rgb15_mmx;
+break;
+} else
+
Re: [FFmpeg-devel] [PATCH 2/2] libswscale/x86/yuv2rgb: add ssse3 version
> Am 28.11.2019 um 07:07 schrieb Ting Fu : > > +#if HAVE_SSSE3 > +#define COMPILE_TEMPLATE_SSSE3 1 > +#endif Please add a line about performance to the commit message. Carl Eugen ___ 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] avfilter: Add tonemap vaapi filter for H2S
> Am 28.11.2019 um 06:37 schrieb Sun, Xinpeng :
>
>>>
>>> +if (input_frame->color_trc != AVCOL_TRC_SMPTE2084) {
>>> +av_log(avctx, AV_LOG_ERROR, "Only support HDR10 as input for vaapi
>>> tone-mapping\n");
>>> +return AVERROR(EINVAL);
>>
>> Shouldn't this also accept unknown trc?
>> (With a warning)
>
> Sorry if I misunderstand "unknown trc". Did you mean the trc undefined by
> ffmpeg or the trc unsupported by the driver?
My question is:
If input_frame->color_trc is AVCOL_TRC_UNSPECIFIED, will the above fail? But
shouldn’t the user be able to use the filter in this case?
Thank you for the explanations, Carl Eugen
___
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] lavf/movenc: Replace dts by pts to calculate duration
> Am 28.11.2019 um 03:34 schrieb manuelyuan : > > In this case, the input video is of dynamic frame rate and we don't want to > duplicate or drop frames, but the output video duration calculated by DTS is > incorrect, I solved it by using PTS. > There are many UGC videos with dynamic frame rates, which are represented by > PTS jumps. After transcoding with ffmpeg -vsync 0 or -vsync 2, the output > video duration becomes longer.By reading the code of x264/encoder/encoder.c, > I found that in order to predict the B frame, x264 needs to ensure that there > are enough reference frames when DTS = 0, so the DTS of these reference frames > will subtract the cache time. However, the cache time includes the part of PTS > jumps, which results in the abnormal small DTS. Do you have access to a stream analyser to verify the output file with your patch? Carl Eugen ___ 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] avfilter: Add tonemap vaapi filter for H2S
> -Original Message-
> From: ffmpeg-devel On Behalf Of
> Carl Eugen Hoyos
> Sent: Thursday, November 28, 2019 2:37 PM
> To: FFmpeg development discussions and patches de...@ffmpeg.org>
> Subject: Re: [FFmpeg-devel] [PATCH v2] avfilter: Add tonemap vaapi filter for
> H2S
>
>
>
> > Am 28.11.2019 um 06:37 schrieb Sun, Xinpeng :
> >
> >>>
> >>> +if (input_frame->color_trc != AVCOL_TRC_SMPTE2084) {
> >>> +av_log(avctx, AV_LOG_ERROR, "Only support HDR10 as input for
> vaapi tone-mapping\n");
> >>> +return AVERROR(EINVAL);
> >>
> >> Shouldn't this also accept unknown trc?
> >> (With a warning)
> >
> > Sorry if I misunderstand "unknown trc". Did you mean the trc undefined by
> ffmpeg or the trc unsupported by the driver?
>
> My question is:
> If input_frame->color_trc is AVCOL_TRC_UNSPECIFIED, will the above fail?
> But shouldn’t the user be able to use the filter in this case?
Hi Carl,
I am not sure if assuming the input is using SMPTE2084 sounds more acceptable
in case of unspecified? If yes, I think we can change as you suggested.
I suggested Xinpeng to follow the behavior of tonemap_opencl for such case,
i.e. to fail explicitly for cases other than SMPTE2084. Because people may get
incorrect color.
Ruiling
>
> Thank you for the explanations, Carl Eugen
> ___
> 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] [aarch64] improve performance of ff_hscale_8_to_15_neon
Hi,
On Wed, Nov 27, 2019 at 3:28 PM Sebastian Pop wrote:
> On Wed, Nov 27, 2019 at 2:13 PM Clément Bœsch wrote:
> > Yeah I will by the end of the week. I wrote that a few years ago so I
> need
> > to take some time to get back in the context.
>
> Thanks Clément for your help.
>
> >
> > BTW, that's quite a huge speed improvement you're bringing in, are you
> > sure you are always allowed to read up to filter[3]?
>
> I will check.
> Otherwise we can version the code and keep the existing code along for
> vector factor 2.
utils.c allocates h{Chr,Lum}Filter and they appear to be padded.
Ronald
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 2/2] libswscale/x86/yuv2rgb: add ssse3 version
> -Original Message- > From: ffmpeg-devel On Behalf Of Carl > Eugen Hoyos > Sent: Thursday, November 28, 2019 02:29 PM > To: FFmpeg development discussions and patches > Subject: Re: [FFmpeg-devel] [PATCH 2/2] libswscale/x86/yuv2rgb: add ssse3 > version > > > > > Am 28.11.2019 um 07:07 schrieb Ting Fu : > > > > +#if HAVE_SSSE3 > > +#define COMPILE_TEMPLATE_SSSE3 1 > > +#endif > > Please add a line about performance to the commit message. > > Carl Eugen Hi Carl, Sorry for the missing performance info, I tested it with raw YUV format video, the command is: ./ffmpeg -pix_fmt yuv420p -s 1920*1080 -i input.yuv -vcodec rawvideo -s 1920*1080 -pix_fmt rgb24 -f null /dev/null The outputs are as follows on my local machine: output fmt RGB24: mmx: 337fps ssse3: 634fps output fmt RGB32: mmx: 375fps ssse3: 653fps output fmt RGB555: mmx: 427fps ssse3: 917fps And I will add these infos in the PATCH V2. Tank you Tin Fu > ___ > 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] [aarch64] improve performance of ff_hscale_8_to_15_neon
Hi,
On Thu, Nov 28, 2019 at 2:08 AM Ronald S. Bultje wrote:
> Hi,
>
> On Wed, Nov 27, 2019 at 3:28 PM Sebastian Pop wrote:
>
>> On Wed, Nov 27, 2019 at 2:13 PM Clément Bœsch wrote:
>> > Yeah I will by the end of the week. I wrote that a few years ago so I
>> need
>> > to take some time to get back in the context.
>>
>> Thanks Clément for your help.
>>
>> >
>> > BTW, that's quite a huge speed improvement you're bringing in, are you
>> > sure you are always allowed to read up to filter[3]?
>>
>> I will check.
>> Otherwise we can version the code and keep the existing code along for
>> vector factor 2.
>
>
> utils.c allocates h{Chr,Lum}Filter and they appear to be padded.
>
Figure I should be more specific heresince there's multiple allocation
paths. I mean this one:
// NOTE: the +3 is for the MMX(+1) / SSE(+3) scaler which reads over
the end
FF_ALLOC_ARRAY_OR_GOTO(NULL, *filterPos, (dstW + 3),
sizeof(**filterPos), fail);
Ronald
___
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".
