[FFmpeg-devel] [PATCH] avformat/img2dec: Option to play sequence backwards
Signed-off-by: Sergio Acereda
---
This patch should allow to play a image sequence in backwards direction,
without needing to apply a reverse filter.
$ ffmpeg -i sequence%05.png forward.mkv
$ ffmpeg -reverse 1 sequence%05.png backward.mkv
---
libavformat/img2.h| 1 +
libavformat/img2dec.c | 32 ++--
2 files changed, 23 insertions(+), 10 deletions(-)
diff --git a/libavformat/img2.h b/libavformat/img2.h
index 5fd8ff77fc..3d01c00537 100644
--- a/libavformat/img2.h
+++ b/libavformat/img2.h
@@ -59,6 +59,7 @@ typedef struct VideoDemuxData {
#endif
int start_number;
int start_number_range;
+int reverse;
int frame_size;
int ts_from_file;
int export_path_metadata; /**< enabled when set to 1. */
diff --git a/libavformat/img2dec.c b/libavformat/img2dec.c
index 8608252d83..90465441f1 100644
--- a/libavformat/img2dec.c
+++ b/libavformat/img2dec.c
@@ -105,10 +105,12 @@ static int is_glob(const char *path)
* @param plast_index pointer to index updated with the last number in the
range
* @param path path which has to be matched by the image files in the
range
* @param start_index minimum accepted value for the first index in the range
+ * @param start_index_range range for looking at the first sequence number
+ * @param reverse play backwards
* @return -1 if no image file could be found
*/
static int find_image_range(AVIOContext *pb, int *pfirst_index, int
*plast_index,
-const char *path, int start_index, int
start_index_range)
+const char *path, int start_index, int
start_index_range, int reverse)
{
char buf[1024];
int range, last_index, range1, first_index;
@@ -152,8 +154,14 @@ static int find_image_range(AVIOContext *pb, int
*pfirst_index, int *plast_index
break;
last_index += range;
}
-*pfirst_index = first_index;
-*plast_index = last_index;
+if (reverse) {
+*pfirst_index = last_index;
+*plast_index = first_index;
+}
+else {
+*pfirst_index = first_index;
+*plast_index = last_index;
+}
return 0;
fail:
@@ -274,7 +282,7 @@ int ff_img_read_header(AVFormatContext *s1)
}
if ((s->pattern_type == PT_GLOB_SEQUENCE && !s->use_glob) ||
s->pattern_type == PT_SEQUENCE) {
if (find_image_range(s1->pb, &first_index, &last_index, s->path,
- s->start_number, s->start_number_range) < 0) {
+ s->start_number, s->start_number_range,
s->reverse) < 0) {
av_log(s1, AV_LOG_ERROR,
"Could find no file with path '%s' and index in the
range %d-%d\n",
s->path, s->start_number, s->start_number +
s->start_number_range - 1);
@@ -307,7 +315,7 @@ int ff_img_read_header(AVFormatContext *s1)
/* compute duration */
if (!s->ts_from_file) {
st->start_time = 0;
-st->duration = last_index - first_index + 1;
+st->duration = abs(last_index - first_index) + 1;
}
}
@@ -413,11 +421,12 @@ int ff_img_read_packet(AVFormatContext *s1, AVPacket *pkt)
AVCodecParameters *par = s1->streams[0]->codecpar;
if (!s->is_pipe) {
+int bad = s->reverse? (s->img_number < s->img_last) : (s->img_number >
s->img_last);
/* loop over input */
-if (s->loop && s->img_number > s->img_last) {
+if (s->loop && bad) {
s->img_number = s->img_first;
}
-if (s->img_number > s->img_last)
+if (bad)
return AVERROR_EOF;
if (s->pattern_type == PT_NONE) {
av_strlcpy(filename_bytes, s->path, sizeof(filename_bytes));
@@ -554,8 +563,9 @@ int ff_img_read_packet(AVFormatContext *s1, AVPacket *pkt)
}
goto fail;
} else {
+int step = s->reverse? -1 : 1;
s->img_count++;
-s->img_number++;
+s->img_number += step;
s->pts++;
return 0;
}
@@ -594,9 +604,10 @@ static int img_read_seek(AVFormatContext *s, int
stream_index, int64_t timestamp
return 0;
}
-if (timestamp < 0 || !s1->loop && timestamp > s1->img_last - s1->img_first)
+int bad = s1->reverse? (timestamp < s1->img_last) : (timestamp >
s1->img_last);
+if (timestamp < 0 || !s1->loop && bad)
return -1;
-s1->img_number = timestamp%(s1->img_last - s1->img_first + 1) +
s1->img_first;
+s1->img_number = timestamp%abs(s1->img_last - s1->img_first + 1) +
s1->img_first;
s1->pts = timestamp;
return 0;
}
@@ -619,6 +630,7 @@ const AVOption ff_img_options[] = {
{ "none", "disable pattern matching",0,
AV_OPT_TYPE_CONST, {.i64=PT_NONE }, INT_MIN, INT_MAX, DEC,
"pattern_type" },
{ "start_number", "set first number in the sequence",
OFFSET(start_number), AV_OPT_TYPE_INT,{.i64 = 0 }, INT_MIN, INT_MAX, DEC
},
{ "start_number_range", "set range
[FFmpeg-devel] GSoC 2022
Hi! GSoC 2022 just started the org application phase. As usual, we'll send an application and need to gather project ideas for GSoC 2022. There is the 2022 GSoC page in our wiki now [1], please add your project idea before the application deadline there or send it to the ML for discussion. Application deadline is Feb. 21st. See the detailed timeline [2]. Furthermore, the project conditions as well as eligibility for contributors changed (again) this year. GSoC is not only for students anymore and project scope & schedule can be more freely choosen. See [3] for details! Thanks, Thilo [1] https://trac.ffmpeg.org/wiki/SponsoringPrograms/GSoC/2022 [2] https://developers.google.com/open-source/gsoc/timeline [3] https://opensource.googleblog.com/2021/11/expanding-google-summer-of-code-in-2022.html ___ 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] libavfilter: zscale performance optimization >4x
By ffmpeg threading support implementation via frame slicing and doing
zimg_filter_graph_build that used to take 30-60% of each frame processig
only if necessary (some parameters changed)
the performance increase vs original version
in video downscale and color conversion >4x is seen
on 64 cores Intel Xeon, 3x on i7-6700K (4 cores with HT)
Signed-off-by: Victoria Zhislina
---
libavfilter/vf_zscale.c | 786
1 file changed, 475 insertions(+), 311 deletions(-)
diff --git a/libavfilter/vf_zscale.c b/libavfilter/vf_zscale.c
index 1288c5efc1..ce4c0b2c76 100644
--- a/libavfilter/vf_zscale.c
+++ b/libavfilter/vf_zscale.c
@@ -1,6 +1,7 @@
/*
* Copyright (c) 2015 Paul B Mahol
- *
+ * * 2022 Victoria Zhislina, Intel - performance optimization
+
* This file is part of FFmpeg.
*
* FFmpeg is free software; you can redistribute it and/or
@@ -44,6 +45,8 @@
#include "libavutil/imgutils.h"
#define ZIMG_ALIGNMENT 32
+#define MIN_TILESIZE 64
+#define MAX_THREADS 64
static const char *const var_names[] = {
"in_w", "iw",
@@ -113,13 +116,17 @@ typedef struct ZScaleContext {
int force_original_aspect_ratio;
-void *tmp;
-size_t tmp_size;
+void *tmp[MAX_THREADS]; //separate for each thread;
+ int nb_threads;
+int slice_h;
zimg_image_format src_format, dst_format;
zimg_image_format alpha_src_format, alpha_dst_format;
+zimg_image_format src_format_tmp, dst_format_tmp;
+zimg_image_format alpha_src_format_tmp, alpha_dst_format_tmp;
zimg_graph_builder_params alpha_params, params;
-zimg_filter_graph *alpha_graph, *graph;
+zimg_graph_builder_params alpha_params_tmp, params_tmp;
+zimg_filter_graph *alpha_graph[MAX_THREADS], *graph[MAX_THREADS];
enum AVColorSpace in_colorspace, out_colorspace;
enum AVColorTransferCharacteristic in_trc, out_trc;
@@ -128,10 +135,181 @@ typedef struct ZScaleContext {
enum AVChromaLocation in_chromal, out_chromal;
} ZScaleContext;
+
+typedef struct ThreadData {
+const AVPixFmtDescriptor *desc, *odesc;
+AVFrame *in, *out;
+} ThreadData;
+
+static int convert_chroma_location(enum AVChromaLocation chroma_location)
+{
+switch (chroma_location) {
+case AVCHROMA_LOC_UNSPECIFIED:
+case AVCHROMA_LOC_LEFT:
+return ZIMG_CHROMA_LEFT;
+case AVCHROMA_LOC_CENTER:
+return ZIMG_CHROMA_CENTER;
+case AVCHROMA_LOC_TOPLEFT:
+return ZIMG_CHROMA_TOP_LEFT;
+case AVCHROMA_LOC_TOP:
+return ZIMG_CHROMA_TOP;
+case AVCHROMA_LOC_BOTTOMLEFT:
+return ZIMG_CHROMA_BOTTOM_LEFT;
+case AVCHROMA_LOC_BOTTOM:
+return ZIMG_CHROMA_BOTTOM;
+}
+return ZIMG_CHROMA_LEFT;
+}
+
+static int convert_matrix(enum AVColorSpace colorspace)
+{
+switch (colorspace) {
+case AVCOL_SPC_RGB:
+return ZIMG_MATRIX_RGB;
+case AVCOL_SPC_BT709:
+return ZIMG_MATRIX_709;
+case AVCOL_SPC_UNSPECIFIED:
+return ZIMG_MATRIX_UNSPECIFIED;
+case AVCOL_SPC_FCC:
+return ZIMG_MATRIX_FCC;
+case AVCOL_SPC_BT470BG:
+return ZIMG_MATRIX_470BG;
+case AVCOL_SPC_SMPTE170M:
+return ZIMG_MATRIX_170M;
+case AVCOL_SPC_SMPTE240M:
+return ZIMG_MATRIX_240M;
+case AVCOL_SPC_YCGCO:
+return ZIMG_MATRIX_YCGCO;
+case AVCOL_SPC_BT2020_NCL:
+return ZIMG_MATRIX_2020_NCL;
+case AVCOL_SPC_BT2020_CL:
+return ZIMG_MATRIX_2020_CL;
+case AVCOL_SPC_CHROMA_DERIVED_NCL:
+return ZIMG_MATRIX_CHROMATICITY_DERIVED_NCL;
+case AVCOL_SPC_CHROMA_DERIVED_CL:
+return ZIMG_MATRIX_CHROMATICITY_DERIVED_CL;
+case AVCOL_SPC_ICTCP:
+return ZIMG_MATRIX_ICTCP;
+}
+return ZIMG_MATRIX_UNSPECIFIED;
+}
+
+static int convert_trc(enum AVColorTransferCharacteristic color_trc)
+{
+switch (color_trc) {
+case AVCOL_TRC_UNSPECIFIED:
+return ZIMG_TRANSFER_UNSPECIFIED;
+case AVCOL_TRC_BT709:
+return ZIMG_TRANSFER_709;
+case AVCOL_TRC_GAMMA22:
+return ZIMG_TRANSFER_470_M;
+case AVCOL_TRC_GAMMA28:
+return ZIMG_TRANSFER_470_BG;
+case AVCOL_TRC_SMPTE170M:
+return ZIMG_TRANSFER_601;
+case AVCOL_TRC_SMPTE240M:
+return ZIMG_TRANSFER_240M;
+case AVCOL_TRC_LINEAR:
+return ZIMG_TRANSFER_LINEAR;
+case AVCOL_TRC_LOG:
+return ZIMG_TRANSFER_LOG_100;
+case AVCOL_TRC_LOG_SQRT:
+return ZIMG_TRANSFER_LOG_316;
+case AVCOL_TRC_IEC61966_2_4:
+return ZIMG_TRANSFER_IEC_61966_2_4;
+case AVCOL_TRC_BT2020_10:
+return ZIMG_TRANSFER_2020_10;
+case AVCOL_TRC_BT2020_12:
+return ZIMG_TRANSFER_2020_12;
+case AVCOL_TRC_SMPTE2084:
+return ZIMG_TRANSFER_ST2084;
+case AVCOL_TRC_ARIB_STD_B67:
+return ZIMG_TRANSFER_ARIB_B67;
+case AVCOL_TRC_IEC61966_2_1:
+return ZIMG_TRANSFER_IEC_61966_2_1;
+}
+return ZIMG_TRANSFER_UNSPECIFIED;
+}
+
+static int convert_primaries(enum AVColorPrimaries c
Re: [FFmpeg-devel] [PATCH] avformat/img2dec: Option to play sequence backwards
On 2022-02-10 03:01 pm, Sergio Acereda wrote: Signed-off-by: Sergio Acereda --- This patch should allow to play a image sequence in backwards direction, without needing to apply a reverse filter. Have you considered this: https://stackoverflow.com/a/40479257/ ? Regards, Gyan ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] avcodec/pngdec: Cleanup generically on init failure
Andreas Rheinhardt:
> Signed-off-by: Andreas Rheinhardt
> ---
> I did not add these codecs the last time I searched for codecs
> to add the FF_CODEC_CAP_INIT_CLEANUP because I was unsure whether
> calling ff_thread_release_buffer() on a NULL frame was safe
> (it is).
>
> libavcodec/pngdec.c | 9 +++--
> 1 file changed, 3 insertions(+), 6 deletions(-)
>
> diff --git a/libavcodec/pngdec.c b/libavcodec/pngdec.c
> index 3c7907..6a22f8d9d8 100644
> --- a/libavcodec/pngdec.c
> +++ b/libavcodec/pngdec.c
> @@ -1696,11 +1696,8 @@ static av_cold int png_dec_init(AVCodecContext *avctx)
> s->avctx = avctx;
> s->last_picture.f = av_frame_alloc();
> s->picture.f = av_frame_alloc();
> -if (!s->last_picture.f || !s->picture.f) {
> -av_frame_free(&s->last_picture.f);
> -av_frame_free(&s->picture.f);
> +if (!s->last_picture.f || !s->picture.f)
> return AVERROR(ENOMEM);
> -}
>
> ff_pngdsp_init(&s->dsp);
>
> @@ -1741,7 +1738,7 @@ const AVCodec ff_apng_decoder = {
> .decode = decode_frame_apng,
> .update_thread_context = ONLY_IF_THREADS_ENABLED(update_thread_context),
> .capabilities = AV_CODEC_CAP_DR1 | AV_CODEC_CAP_FRAME_THREADS /*|
> AV_CODEC_CAP_DRAW_HORIZ_BAND*/,
> -.caps_internal = FF_CODEC_CAP_INIT_THREADSAFE |
> +.caps_internal = FF_CODEC_CAP_INIT_THREADSAFE |
> FF_CODEC_CAP_INIT_CLEANUP |
>FF_CODEC_CAP_ALLOCATE_PROGRESS,
> };
> #endif
> @@ -1759,6 +1756,6 @@ const AVCodec ff_png_decoder = {
> .update_thread_context = ONLY_IF_THREADS_ENABLED(update_thread_context),
> .capabilities = AV_CODEC_CAP_DR1 | AV_CODEC_CAP_FRAME_THREADS /*|
> AV_CODEC_CAP_DRAW_HORIZ_BAND*/,
> .caps_internal = FF_CODEC_CAP_SKIP_FRAME_FILL_PARAM |
> FF_CODEC_CAP_INIT_THREADSAFE |
> - FF_CODEC_CAP_ALLOCATE_PROGRESS,
> + FF_CODEC_CAP_ALLOCATE_PROGRESS |
> FF_CODEC_CAP_INIT_CLEANUP,
> };
> #endif
Will apply this later today unless there are objections.
- Andreas
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] zscale video filter performance optimization 4x
Yes,yes,yes, moreover the graph should be rebuilt if some other parameters change - interpolation method etc, also when a single input splitted by zscaling to 2 different resolution streams. So I've submitted a new patch version that fixes everything. It has a lot of checks inside but they are absolutely necessary. They save 30-60% of performance in a single threading case! On Wed, Feb 9, 2022 at 12:38 PM Guillaume POIRIER wrote: > Hello Victoria, > > On Sun, 6 Feb 2022 at 16:12, Victoria Zhislina wrote: > > > I wasn't aware of the cases where width/height can change between frames > - > > never seen them in real life, but right you are, iI will change my code > > accordingly - to make re-init if some change happened. > > > If you want to create such a sample, take 2 short HEVC clips with > different resolutions, extract the ES, and concat them together: > > ffmpeg -i INPUT1.mp4 -codec copy -bsf:v hevc_mp4toannexb OUTPUT1.265 > ffmpeg -i INPUT2.mp4 -codec copy -bsf:v hevc_mp4toannexb OUTPUT2.265 > > cat OUTPUT1.265 OUTPUT2.265 > mixed_res.265 > > Guillaume > ___ > 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 2/2] avcodec/libuavs3d: Check ff_set_dimensions() for failure
Untested, no testcase
Signed-off-by: Michael Niedermayer
---
libavcodec/libuavs3d.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/libavcodec/libuavs3d.c b/libavcodec/libuavs3d.c
index 0b5c6268a4..d8d09cacbc 100644
--- a/libavcodec/libuavs3d.c
+++ b/libavcodec/libuavs3d.c
@@ -208,7 +208,9 @@ static int libuavs3d_decode_frame(AVCodecContext *avctx,
void *data, int *got_fr
}
avctx->has_b_frames = !seqh->low_delay;
avctx->pix_fmt = seqh->bit_depth_internal == 8 ?
AV_PIX_FMT_YUV420P : AV_PIX_FMT_YUV420P10LE;
-ff_set_dimensions(avctx, seqh->horizontal_size,
seqh->vertical_size);
+ret = ff_set_dimensions(avctx, seqh->horizontal_size,
seqh->vertical_size);
+if (ret < 0)
+return ret;
h->got_seqhdr = 1;
if (seqh->colour_description) {
--
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/mpegts: initialize max_packet_size when sub-demuxer
On 2022-02-08 04:33 pm, Gyan Doshi wrote: On 2022-02-07 09:34 am, Gyan Doshi wrote: On 2022-02-07 03:59 am, Marton Balint wrote: On Sat, 5 Feb 2022, Gyan Doshi wrote: bca30570d2 added a user option to set max_packet_size replacing a hardcoded value. This had a side-effect of leaving the field set to 0 when packet demuxing is carried out from another demuxer using avpriv functions, which could lead to demux failure. Hardcoded max_packet_size inside avpriv_mpegts_parse_open to 2048000 to avoid this. Value chosen to be 10x that of default value to accommodate large payloads. I don't understand why the default is different from the normal mpegts case. Large payloads can happen there as well, and previously it was assumed that splitting is OK, because it will be parsed anyway. The option was added because MPEG-TS allows any codec to be carried as a private stream and when demuxing that, the parser isn't inserted, even when forcing a decoder, hence the need to not have split packets. In this case, the user can't tune the value, so I went with an expansive one. Plan to push tomorrow. Pushed as b6bb6b9f22ff519644b16dcc71a4b92ee3979c1b Regards, Gyan ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH 1/2] avformat/mov: Corner case encryption error cleanup in mov_read_senc()
Fixes: memleak
Fixes:
42341/clusterfuzz-testcase-minimized-ffmpeg_dem_MOV_fuzzer-4566632823914496
Found-by: continuous fuzzing process
https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer
---
libavformat/mov.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/libavformat/mov.c b/libavformat/mov.c
index a80fcc1606..5e26267810 100644
--- a/libavformat/mov.c
+++ b/libavformat/mov.c
@@ -6105,6 +6105,8 @@ static int mov_read_senc(MOVContext *c, AVIOContext *pb,
MOVAtom atom)
}
if (pb->eof_reached) {
av_log(c->fc, AV_LOG_ERROR, "Hit EOF while reading senc\n");
+if (ret >= 0)
+
av_encryption_info_free(encryption_index->encrypted_samples[i]);
ret = AVERROR_INVALIDDATA;
}
--
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] avutil/hwcontext: check the null pointer input value before use it
> 2022年2月10日 下午8:20，Steven Liu 写道：
>
> because the src, src->hw_frames_ctx and src->hw_frames_ctx->data can be
> set to null when the user calling av_hwframe_transfer_data, this will
> get crash if they are null.
>
Reported-by: TOTE Robot
> Signed-off-by: Steven Liu
> ---
> libavutil/hwcontext.c | 5 -
> 1 file changed, 4 insertions(+), 1 deletion(-)
>
> diff --git a/libavutil/hwcontext.c b/libavutil/hwcontext.c
> index 31c7840dba..b42a3a6d4d 100644
> --- a/libavutil/hwcontext.c
> +++ b/libavutil/hwcontext.c
> @@ -396,10 +396,13 @@ int av_hwframe_transfer_get_formats(AVBufferRef
> *hwframe_ref,
>
> static int transfer_data_alloc(AVFrame *dst, const AVFrame *src, int flags)
> {
> -AVHWFramesContext *ctx = (AVHWFramesContext*)src->hw_frames_ctx->data;
> +AVHWFramesContext *ctx = NULL;
> AVFrame *frame_tmp;
> int ret = 0;
>
> +if (!src || !src->hw_frames_ctx || !src->hw_frames_ctx->data)
> +return AVERROR(EINVAL);
> +ctx = (AVHWFramesContext*)src->hw_frames_ctx->data;
> frame_tmp = av_frame_alloc();
> if (!frame_tmp)
> return AVERROR(ENOMEM);
> --
> 2.25.0
>
Thanks
Steven Liu
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH] avutil/hwcontext: check the null pointer input value before use it
because the src, src->hw_frames_ctx and src->hw_frames_ctx->data can be
set to null when the user calling av_hwframe_transfer_data, this will
get crash if they are null.
Signed-off-by: Steven Liu
---
libavutil/hwcontext.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/libavutil/hwcontext.c b/libavutil/hwcontext.c
index 31c7840dba..b42a3a6d4d 100644
--- a/libavutil/hwcontext.c
+++ b/libavutil/hwcontext.c
@@ -396,10 +396,13 @@ int av_hwframe_transfer_get_formats(AVBufferRef
*hwframe_ref,
static int transfer_data_alloc(AVFrame *dst, const AVFrame *src, int flags)
{
-AVHWFramesContext *ctx = (AVHWFramesContext*)src->hw_frames_ctx->data;
+AVHWFramesContext *ctx = NULL;
AVFrame *frame_tmp;
int ret = 0;
+if (!src || !src->hw_frames_ctx || !src->hw_frames_ctx->data)
+return AVERROR(EINVAL);
+ctx = (AVHWFramesContext*)src->hw_frames_ctx->data;
frame_tmp = av_frame_alloc();
if (!frame_tmp)
return AVERROR(ENOMEM);
--
2.25.0
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] avutil/hwcontext: check the null pointer input value before use it
On 2/10/2022 9:20 AM, Steven Liu wrote:
because the src, src->hw_frames_ctx and src->hw_frames_ctx->data can be
set to null when the user calling av_hwframe_transfer_data, this will
get crash if they are null.
src can not be NULL. The doxy doesn't allow it.
And if transfer_data_alloc() is called, it's because dst is "clean", and
src must then have a hw_frames_ctx (The doxy explicitly states "At least
one of dst/src must have an AVHWFramesContext attached").
Signed-off-by: Steven Liu
---
libavutil/hwcontext.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/libavutil/hwcontext.c b/libavutil/hwcontext.c
index 31c7840dba..b42a3a6d4d 100644
--- a/libavutil/hwcontext.c
+++ b/libavutil/hwcontext.c
@@ -396,10 +396,13 @@ int av_hwframe_transfer_get_formats(AVBufferRef
*hwframe_ref,
static int transfer_data_alloc(AVFrame *dst, const AVFrame *src, int flags)
{
-AVHWFramesContext *ctx = (AVHWFramesContext*)src->hw_frames_ctx->data;
+AVHWFramesContext *ctx = NULL;
AVFrame *frame_tmp;
int ret = 0;
+if (!src || !src->hw_frames_ctx || !src->hw_frames_ctx->data)
+return AVERROR(EINVAL);
+ctx = (AVHWFramesContext*)src->hw_frames_ctx->data;
frame_tmp = av_frame_alloc();
if (!frame_tmp)
return AVERROR(ENOMEM);
___
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/img2dec: Option to play sequence backwards
Yes, I tried, but this only works if your sequence has the '-' before the numeric elements. You can see they comment that in the thread, by saying you have to remove the '-' from the expression. $ ffmpeg -v debug -start_number -24 -i Comentaris_prova_%05d.png out.mkv ffmpeg version 2020-10-17-git-62073cfa97-essentials_build-www.gyan.dev Copyright (c) 2000-2020 the FFmpeg developers built with gcc 10.2.0 (Rev3, Built by MSYS2 project) configuration: --enable-gpl --enable-version3 --enable-static --disable-w32threads --disable-autodetect --enable-fontconfig --enable-iconv --enable-gnutls --enable-libxml2 --enable-gmp --enable-lzma --enable-zlib --enable-libsrt --enable-libssh --enable-libzmq --enable-avisynth --enable-sdl2 --enable-libwebp --enable-libx264 --enable-libx265 --enable-libxvid --enable-libaom --enable-libopenjpeg --enable-libvpx --enable-libass --enable-libfreetype --enable-libfribidi --enable-libvidstab --enable-libvmaf --enable-libzimg --enable-amf --enable-cuda-llvm --enable-cuvid --enable-ffnvcodec --enable-nvdec --enable-nvenc --enable-d3d11va --enable-dxva2 --enable-libmfx --enable-libgme --enable-libopenmpt --enable-libopencore-amrwb --enable-libmp3lame --enable-libtheora --enable-libvo-amrwbenc --enable-libgsm --enable-libopencore-amrnb --enable-libopus --enable-libspeex --enable-libvorbis --enable-librubberband libavutil 56. 60.100 / 56. 60.100 libavcodec 58.111.101 / 58.111.101 libavformat58. 62.100 / 58. 62.100 libavdevice58. 11.102 / 58. 11.102 libavfilter 7. 87.100 / 7. 87.100 libswscale 5. 8.100 / 5. 8.100 libswresample 3. 8.100 / 3. 8.100 libpostproc55. 8.100 / 55. 8.100 Splitting the commandline. Reading option '-v' ... matched as option 'v' (set logging level) with argument 'debug'. Reading option '-start_number' ... matched as AVOption 'start_number' with argument '-24'. Reading option '-i' ... matched as input url with argument 'Comentaris_prova_%05d.png'. Reading option 'out.mkv' ... matched as output url. Finished splitting the commandline. Parsing a group of options: global . Applying option v (set logging level) with argument debug. Successfully parsed a group of options. Parsing a group of options: input url Comentaris_prova_%05d.png. Successfully parsed a group of options. Opening an input file: Comentaris_prova_%05d.png. [image2 @ 01742817d100] Could find no file with path 'Comentaris_prova_%05d.png' and index in the range -24--20 Comentaris_prova_%05d.png: No such file or directory ___ 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/img2dec: Option to play sequence backwards
By the way, is there any problem with the patch itself? Not sure why it says 'Failed to apply patch'. Did my email client break it somehow? > ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH v3 1/3] avformat/udp: use one setsockopt for ipv4/ipv6
On Sat, Feb 05, 2022 at 08:31:46PM +0800, lance.lmw...@gmail.com wrote:
> From: Limin Wang
>
> Signed-off-by: Limin Wang
> ---
> libavformat/udp.c | 32
> 1 file changed, 20 insertions(+), 12 deletions(-)
>
> diff --git a/libavformat/udp.c b/libavformat/udp.c
> index 83c042d..8178d0e 100644
> --- a/libavformat/udp.c
> +++ b/libavformat/udp.c
> @@ -162,22 +162,30 @@ static int udp_set_multicast_ttl(int sockfd, int
> mcastTTL,
> struct sockaddr *addr,
> void *logctx)
> {
> +int protocol, cmd;
> +
> +switch (addr->sa_family) {
> #ifdef IP_MULTICAST_TTL
> -if (addr->sa_family == AF_INET) {
> -if (setsockopt(sockfd, IPPROTO_IP, IP_MULTICAST_TTL, &mcastTTL,
> sizeof(mcastTTL)) < 0) {
> -ff_log_net_error(logctx, AV_LOG_ERROR,
> "setsockopt(IP_MULTICAST_TTL)");
> -return ff_neterrno();
> -}
> -}
> +case AF_INET:
> +protocol = IPPROTO_IP;
> +cmd = IP_MULTICAST_TTL;
> +break;
> #endif
> #if defined(IPPROTO_IPV6) && defined(IPV6_MULTICAST_HOPS)
> -if (addr->sa_family == AF_INET6) {
> -if (setsockopt(sockfd, IPPROTO_IPV6, IPV6_MULTICAST_HOPS, &mcastTTL,
> sizeof(mcastTTL)) < 0) {
> -ff_log_net_error(logctx, AV_LOG_ERROR,
> "setsockopt(IPV6_MULTICAST_HOPS)");
> -return ff_neterrno();
> -}
> -}
> +case AF_INET6:
> +protocol = IPPROTO_IPV6;
> +cmd = IPV6_MULTICAST_HOPS;
> +break;
> #endif
> +default:
> +return 0;
> +}
> +
> +if (setsockopt(sockfd, protocol, cmd, &mcastTTL, sizeof(mcastTTL)) < 0) {
> +ff_log_net_error(logctx, AV_LOG_ERROR, "setsockopt(IPV4/IPV6
> MULTICAST TTL)");
> +return ff_neterrno();
> +}
> +
> return 0;
> }
>
> --
> 1.8.3.1
>
will apply tomorrow with one pending ttl range check patch if no further
comments.
--
Thanks,
Limin Wang
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] avutil/hwcontext: check the null pointer input value before use it
> 2022年2月10日 下午8:27，James Almer 写道：
>
> On 2/10/2022 9:20 AM, Steven Liu wrote:
>> because the src, src->hw_frames_ctx and src->hw_frames_ctx->data can be
>> set to null when the user calling av_hwframe_transfer_data, this will
>> get crash if they are null.
>
> src can not be NULL. The doxy doesn't allow it.
Hi James,
User call av_hwframe_transfer_data like this:
av_hwframe_transfer_data(dst, NULL, 0);
It will crash when dst->buf[0] is null.
Because dst->buf[0] is null and src is null, it will call transfer_data_alloc,
but the first line is ctx = (AVHWFramesContext*)src->hw_frames_ctx->data; in
transfer_data_alloc,
It using src->hw_frames_ctx.
av_hwframe_transfer_data is av_*, it is API to user.
Maybe this is not logic problem, looks like a security problem.
>
> And if transfer_data_alloc() is called, it's because dst is "clean", and src
> must then have a hw_frames_ctx (The doxy explicitly states "At least one of
> dst/src must have an AVHWFramesContext attached").
>
>> Signed-off-by: Steven Liu
>> ---
>> libavutil/hwcontext.c | 5 -
>> 1 file changed, 4 insertions(+), 1 deletion(-)
>> diff --git a/libavutil/hwcontext.c b/libavutil/hwcontext.c
>> index 31c7840dba..b42a3a6d4d 100644
>> --- a/libavutil/hwcontext.c
>> +++ b/libavutil/hwcontext.c
>> @@ -396,10 +396,13 @@ int av_hwframe_transfer_get_formats(AVBufferRef
>> *hwframe_ref,
>>static int transfer_data_alloc(AVFrame *dst, const AVFrame *src, int
>> flags)
>> {
>> -AVHWFramesContext *ctx = (AVHWFramesContext*)src->hw_frames_ctx->data;
>> +AVHWFramesContext *ctx = NULL;
>> AVFrame *frame_tmp;
>> int ret = 0;
>> +if (!src || !src->hw_frames_ctx || !src->hw_frames_ctx->data)
>> +return AVERROR(EINVAL);
>> +ctx = (AVHWFramesContext*)src->hw_frames_ctx->data;
>> frame_tmp = av_frame_alloc();
>> if (!frame_tmp)
>> return AVERROR(ENOMEM);
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
> To unsubscribe, visit link above, or email
> ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
>
Thanks
Steven Liu
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] avutil/hwcontext: check the null pointer input value before use it
On 2/10/2022 10:43 PM, Steven Liu wrote:
2022年2月10日 下午8:27，James Almer 写道：
On 2/10/2022 9:20 AM, Steven Liu wrote:
because the src, src->hw_frames_ctx and src->hw_frames_ctx->data can be
set to null when the user calling av_hwframe_transfer_data, this will
get crash if they are null.
src can not be NULL. The doxy doesn't allow it.
Hi James,
User call av_hwframe_transfer_data like this:
av_hwframe_transfer_data(dst, NULL, 0);
It will crash when dst->buf[0] is null.
Because dst->buf[0] is null and src is null, it will call transfer_data_alloc, but
the first line is ctx = (AVHWFramesContext*)src->hw_frames_ctx->data; in
transfer_data_alloc,
It using src->hw_frames_ctx.
av_hwframe_transfer_data is av_*, it is API to user.
Maybe this is not logic problem, looks like a security problem.
I know what happens when you pass NULL as src argument. My point is that
it's not a security problem because that's an API violation and an
explicitly forbidden scenario: Neither src or dst can be NULL, and at
least one of them must have an AVHWFramesContext attached. Any
application not following that is faulty and buggy, and needs to be fixed.
And you can get crashes by passing NULL arguments to lots of public
libav* functions, not just this one.
And if transfer_data_alloc() is called, it's because dst is "clean", and src must then
have a hw_frames_ctx (The doxy explicitly states "At least one of dst/src must have an
AVHWFramesContext attached").
Signed-off-by: Steven Liu
---
libavutil/hwcontext.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/libavutil/hwcontext.c b/libavutil/hwcontext.c
index 31c7840dba..b42a3a6d4d 100644
--- a/libavutil/hwcontext.c
+++ b/libavutil/hwcontext.c
@@ -396,10 +396,13 @@ int av_hwframe_transfer_get_formats(AVBufferRef
*hwframe_ref,
static int transfer_data_alloc(AVFrame *dst, const AVFrame *src, int flags)
{
-AVHWFramesContext *ctx = (AVHWFramesContext*)src->hw_frames_ctx->data;
+AVHWFramesContext *ctx = NULL;
AVFrame *frame_tmp;
int ret = 0;
+if (!src || !src->hw_frames_ctx || !src->hw_frames_ctx->data)
+return AVERROR(EINVAL);
+ctx = (AVHWFramesContext*)src->hw_frames_ctx->data;
frame_tmp = av_frame_alloc();
if (!frame_tmp)
return AVERROR(ENOMEM);
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Thanks
Steven Liu
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] avutil/hwcontext: check the null pointer input value before use it
> 2022年2月11日 上午10:01，James Almer 写道： > > On 2/10/2022 10:43 PM, Steven Liu wrote: >>> 2022年2月10日 下午8:27，James Almer 写道： >>> >>> On 2/10/2022 9:20 AM, Steven Liu wrote: because the src, src->hw_frames_ctx and src->hw_frames_ctx->data can be set to null when the user calling av_hwframe_transfer_data, this will get crash if they are null. >>> >>> src can not be NULL. The doxy doesn't allow it. >> Hi James, >> User call av_hwframe_transfer_data like this: >> av_hwframe_transfer_data(dst, NULL, 0); >> It will crash when dst->buf[0] is null. >> Because dst->buf[0] is null and src is null, it will call >> transfer_data_alloc, but the first line is ctx = >> (AVHWFramesContext*)src->hw_frames_ctx->data; in transfer_data_alloc, >> It using src->hw_frames_ctx. >> av_hwframe_transfer_data is av_*, it is API to user. >> Maybe this is not logic problem, looks like a security problem. > > I know what happens when you pass NULL as src argument. My point is that it's > not a security problem because that's an API violation and an explicitly > forbidden scenario: Neither src or dst can be NULL, and at least one of them > must have an AVHWFramesContext attached. Any application not following that > is faulty and buggy, and needs to be fixed. > > And you can get crashes by passing NULL arguments to lots of public libav* > functions, not just this one. Won’t we fix them? Thanks Steven Liu ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] avutil/hwcontext: check the null pointer input value before use it
On 2/10/2022 11:03 PM, Steven Liu wrote: 2022年2月11日 上午10:01，James Almer 写道： On 2/10/2022 10:43 PM, Steven Liu wrote: 2022年2月10日 下午8:27，James Almer 写道： On 2/10/2022 9:20 AM, Steven Liu wrote: because the src, src->hw_frames_ctx and src->hw_frames_ctx->data can be set to null when the user calling av_hwframe_transfer_data, this will get crash if they are null. src can not be NULL. The doxy doesn't allow it. Hi James, User call av_hwframe_transfer_data like this: av_hwframe_transfer_data(dst, NULL, 0); It will crash when dst->buf[0] is null. Because dst->buf[0] is null and src is null, it will call transfer_data_alloc, but the first line is ctx = (AVHWFramesContext*)src->hw_frames_ctx->data; in transfer_data_alloc, It using src->hw_frames_ctx. av_hwframe_transfer_data is av_*, it is API to user. Maybe this is not logic problem, looks like a security problem. I know what happens when you pass NULL as src argument. My point is that it's not a security problem because that's an API violation and an explicitly forbidden scenario: Neither src or dst can be NULL, and at least one of them must have an AVHWFramesContext attached. Any application not following that is faulty and buggy, and needs to be fixed. And you can get crashes by passing NULL arguments to lots of public libav* functions, not just this one. Won’t we fix them? We have nothing to fix. If someone writes an application that calls avcodec_open2(NULL, NULL, NULL) despite it being strictly forbidden, then it's their fault and they deserve the segfaults they will get. Thanks Steven Liu ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe". ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] avutil/hwcontext: check the null pointer input value before use it
> 2022年2月11日 上午10:10，James Almer 写道： > > > > On 2/10/2022 11:03 PM, Steven Liu wrote: >>> 2022年2月11日 上午10:01，James Almer 写道： >>> >>> On 2/10/2022 10:43 PM, Steven Liu wrote: > 2022年2月10日 下午8:27，James Almer 写道： > > On 2/10/2022 9:20 AM, Steven Liu wrote: >> because the src, src->hw_frames_ctx and src->hw_frames_ctx->data can be >> set to null when the user calling av_hwframe_transfer_data, this will >> get crash if they are null. > > src can not be NULL. The doxy doesn't allow it. Hi James, User call av_hwframe_transfer_data like this: av_hwframe_transfer_data(dst, NULL, 0); It will crash when dst->buf[0] is null. Because dst->buf[0] is null and src is null, it will call transfer_data_alloc, but the first line is ctx = (AVHWFramesContext*)src->hw_frames_ctx->data; in transfer_data_alloc, It using src->hw_frames_ctx. av_hwframe_transfer_data is av_*, it is API to user. Maybe this is not logic problem, looks like a security problem. >>> >>> I know what happens when you pass NULL as src argument. My point is that >>> it's not a security problem because that's an API violation and an >>> explicitly forbidden scenario: Neither src or dst can be NULL, and at least >>> one of them must have an AVHWFramesContext attached. Any application not >>> following that is faulty and buggy, and needs to be fixed. >>> >>> And you can get crashes by passing NULL arguments to lots of public libav* >>> functions, not just this one. >> Won’t we fix them? > > We have nothing to fix. If someone writes an application that calls > avcodec_open2(NULL, NULL, NULL) despite it being strictly forbidden, then > it's their fault and they deserve the segfaults they will get. I think API should give the caller an error message or failed value, because segfault is an exception and that means API is not robust, the return value should EINVAL if the user input arguments incorrect. Thanks Steven Liu ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH] libavcodec/qsvdec: use the parameter from decodeHeader to configure surface
MSDK recognizes both yuv420p10 and yuv420p9 as MFX_FOURCC_P010, but
parameters are different. When decode yuv420p9 video, ffmpeg-qsv will use
yuv420p10le to configure surface which is different with param from
DecoderHeader and this will lead to error. Now change it use
param from decoderHeader to configure surface.
Signed-off-by: Wenbin Chen
---
libavcodec/qsvdec.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/libavcodec/qsvdec.c b/libavcodec/qsvdec.c
index f81737ab6d..6236391357 100644
--- a/libavcodec/qsvdec.c
+++ b/libavcodec/qsvdec.c
@@ -423,13 +423,13 @@ static int alloc_frame(AVCodecContext *avctx, QSVContext
*q, QSVFrame *frame)
if (frame->frame->format == AV_PIX_FMT_QSV) {
frame->surface = *(mfxFrameSurface1*)frame->frame->data[3];
} else {
-frame->surface.Info = q->frame_info;
-
frame->surface.Data.PitchLow = frame->frame->linesize[0];
frame->surface.Data.Y= frame->frame->data[0];
frame->surface.Data.UV = frame->frame->data[1];
}
+frame->surface.Info = q->frame_info;
+
if (q->frames_ctx.mids) {
ret = ff_qsv_find_surface_idx(&q->frames_ctx, frame);
if (ret < 0)
--
2.32.0
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] avutil/hwcontext: check the null pointer input value before use it
On 2/10/2022 11:16 PM, Steven Liu wrote: 2022年2月11日 上午10:10，James Almer 写道： On 2/10/2022 11:03 PM, Steven Liu wrote: 2022年2月11日 上午10:01，James Almer 写道： On 2/10/2022 10:43 PM, Steven Liu wrote: 2022年2月10日 下午8:27，James Almer 写道： On 2/10/2022 9:20 AM, Steven Liu wrote: because the src, src->hw_frames_ctx and src->hw_frames_ctx->data can be set to null when the user calling av_hwframe_transfer_data, this will get crash if they are null. src can not be NULL. The doxy doesn't allow it. Hi James, User call av_hwframe_transfer_data like this: av_hwframe_transfer_data(dst, NULL, 0); It will crash when dst->buf[0] is null. Because dst->buf[0] is null and src is null, it will call transfer_data_alloc, but the first line is ctx = (AVHWFramesContext*)src->hw_frames_ctx->data; in transfer_data_alloc, It using src->hw_frames_ctx. av_hwframe_transfer_data is av_*, it is API to user. Maybe this is not logic problem, looks like a security problem. I know what happens when you pass NULL as src argument. My point is that it's not a security problem because that's an API violation and an explicitly forbidden scenario: Neither src or dst can be NULL, and at least one of them must have an AVHWFramesContext attached. Any application not following that is faulty and buggy, and needs to be fixed. And you can get crashes by passing NULL arguments to lots of public libav* functions, not just this one. Won’t we fix them? We have nothing to fix. If someone writes an application that calls avcodec_open2(NULL, NULL, NULL) despite it being strictly forbidden, then it's their fault and they deserve the segfaults they will get. I think API should give the caller an error message or failed value, because segfault is an exception and that means API is not robust, the return value should EINVAL if the user input arguments incorrect. I disagree. Returning EINVAL at runtime lets the user know they probably did something wrong, like trying to open a decoder context using a decoder that's not in the whitelist. That's not API misuse, that's an invalid argument that could realistically happen in an application exposing such settings to the user. But passing a NULL AVCodecContext? That's not the user doing something wrong, that's the application developer doing something wrong. A graceful failure in that case is misleading. With av_hwframe_transfer_data() you transfer data from something to something else. If src is NULL, what are you transferring data from? Why did your application ever try to do that? You need to fix it so it never happens. Thanks Steven Liu ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe". ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH V3 1/3] libavcodec/vaapi_encode: Add new API adaption to vaapi_encode
On Tue, 2022-02-08 at 11:05 +0800, Wenbin Chen wrote:
> Add vaSyncBuffer to VAAPI encoder. Old version API vaSyncSurface wait
> surface to complete. When surface is used for multiple operation, it
> waits all operations to finish. vaSyncBuffer only wait one channel to
> finish.
>
> Add wait param to vaapi_encode_wait() to prepare for the async_depth
> option. "wait=1" means wait until operation ready. "wait=0" means
> query operation's status. If it is ready return 0, if it is still
> in progress return EAGAIN.
>
> Signed-off-by: Wenbin Chen
> ---
> libavcodec/vaapi_encode.c | 47 +--
> 1 file changed, 40 insertions(+), 7 deletions(-)
>
> diff --git a/libavcodec/vaapi_encode.c b/libavcodec/vaapi_encode.c
> index 3bf379b1a0..b87b58a42b 100644
> --- a/libavcodec/vaapi_encode.c
> +++ b/libavcodec/vaapi_encode.c
> @@ -134,7 +134,8 @@ static int
> vaapi_encode_make_misc_param_buffer(AVCodecContext *avctx,
> }
>
> static int vaapi_encode_wait(AVCodecContext *avctx,
> - VAAPIEncodePicture *pic)
> + VAAPIEncodePicture *pic,
> + uint8_t wait)
> {
> VAAPIEncodeContext *ctx = avctx->priv_data;
> VAStatus vas;
> @@ -150,11 +151,43 @@ static int vaapi_encode_wait(AVCodecContext *avctx,
> "(input surface %#x).\n", pic->display_order,
> pic->encode_order, pic->input_surface);
>
> -vas = vaSyncSurface(ctx->hwctx->display, pic->input_surface);
> -if (vas != VA_STATUS_SUCCESS) {
> -av_log(avctx, AV_LOG_ERROR, "Failed to sync to picture completion: "
> - "%d (%s).\n", vas, vaErrorStr(vas));
> +#if VA_CHECK_VERSION(1, 9, 0)
> +// Try vaSyncBuffer.
> +vas = vaSyncBuffer(ctx->hwctx->display,
> + pic->output_buffer,
> + wait ? VA_TIMEOUT_INFINITE : 0);
> +if (vas == VA_STATUS_ERROR_TIMEDOUT) {
> +return AVERROR(EAGAIN);
> +} else if (vas != VA_STATUS_SUCCESS && vas !=
> VA_STATUS_ERROR_UNIMPLEMENTED) {
> +av_log(avctx, AV_LOG_ERROR, "Failed to sync to output buffer
> completion: "
> +"%d (%s).\n", vas, vaErrorStr(vas));
> return AVERROR(EIO);
We may add has_sync_buffer_func flag in this patch, and run the above code when
ctx->has_sync_buffer_func is true. If so, we needn't check whether vaSyncBuffer
is implemented again.
Thanks
Haihao
> +} else if (vas == VA_STATUS_ERROR_UNIMPLEMENTED)
> +// If vaSyncBuffer is not implemented, try old version API.
> +#endif
> +{
> +if (!wait) {
> +VASurfaceStatus surface_status;
> +vas = vaQuerySurfaceStatus(ctx->hwctx->display,
> +pic->input_surface,
> +&surface_status);
> +if (vas == VA_STATUS_SUCCESS &&
> +surface_status != VASurfaceReady &&
> +surface_status != VASurfaceSkipped) {
> +return AVERROR(EAGAIN);
> +} else if (vas != VA_STATUS_SUCCESS) {
> +av_log(avctx, AV_LOG_ERROR, "Failed to query surface status:
> "
> +"%d (%s).\n", vas, vaErrorStr(vas));
> +return AVERROR(EIO);
> +}
> +} else {
> +vas = vaSyncSurface(ctx->hwctx->display, pic->input_surface);
> +if (vas != VA_STATUS_SUCCESS) {
> +av_log(avctx, AV_LOG_ERROR, "Failed to sync to picture
> completion: "
> +"%d (%s).\n", vas, vaErrorStr(vas));
> +return AVERROR(EIO);
> +}
> +}
> }
>
> // Input is definitely finished with now.
> @@ -633,7 +666,7 @@ static int vaapi_encode_output(AVCodecContext *avctx,
> uint8_t *ptr;
> int err;
>
> -err = vaapi_encode_wait(avctx, pic);
> +err = vaapi_encode_wait(avctx, pic, 1);
> if (err < 0)
> return err;
>
> @@ -695,7 +728,7 @@ fail:
> static int vaapi_encode_discard(AVCodecContext *avctx,
> VAAPIEncodePicture *pic)
> {
> -vaapi_encode_wait(avctx, pic);
> +vaapi_encode_wait(avctx, pic, 1);
>
> if (pic->output_buffer_ref) {
> av_log(avctx, AV_LOG_DEBUG, "Discard output for pic "
___
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/3] libavcodec/vaapi_encode: Change the way to call async to increase performance
On Tue, 2022-02-08 at 11:05 +0800, Wenbin Chen wrote:
> Fix: #7706. After commit 5fdcf85bbffe7451c2, vaapi encoder's performance
> decrease. The reason is that vaRenderPicture() and vaSyncBuffer() are
> called at the same time (vaRenderPicture() always followed by a
> vaSyncBuffer()). When we encode stream with B frames, we need buffer to
> reorder frames, so we can send serveral frames to HW at once to increase
> performance. Now I changed them to be called in a asynchronous way, which
> will make better use of hardware. 1080p transcoding increases about 17%
> fps on my environment.
>
> This change fits vaSyncBuffer(), so if driver does not support
> vaSyncBuffer, it will keep previous operation.
>
> Signed-off-by: Wenbin Chen
> ---
> libavcodec/vaapi_encode.c | 64 ---
> libavcodec/vaapi_encode.h | 5 +++
> 2 files changed, 58 insertions(+), 11 deletions(-)
>
> diff --git a/libavcodec/vaapi_encode.c b/libavcodec/vaapi_encode.c
> index b87b58a42b..15ddbbaa4a 100644
> --- a/libavcodec/vaapi_encode.c
> +++ b/libavcodec/vaapi_encode.c
> @@ -984,8 +984,10 @@ static int vaapi_encode_pick_next(AVCodecContext *avctx,
> if (!pic && ctx->end_of_stream) {
> --b_counter;
> pic = ctx->pic_end;
> -if (pic->encode_issued)
> +if (pic->encode_complete)
> return AVERROR_EOF;
> +else if (pic->encode_issued)
> +return AVERROR(EAGAIN);
> }
>
> if (!pic) {
> @@ -1210,18 +1212,44 @@ int ff_vaapi_encode_receive_packet(AVCodecContext
> *avctx, AVPacket *pkt)
> return AVERROR(EAGAIN);
> }
>
> -pic = NULL;
> -err = vaapi_encode_pick_next(avctx, &pic);
> -if (err < 0)
> -return err;
> -av_assert0(pic);
> +#if VA_CHECK_VERSION(1, 9, 0)
Needn't check the version at compile time because vaSyncBuffer is not called
directly in the code below.
> +if (ctx->has_sync_buffer_func) {
> +while (av_fifo_can_read(ctx->encode_fifo) <= MAX_PICTURE_REFERENCES)
> {
> +pic = NULL;
> +err = vaapi_encode_pick_next(avctx, &pic);
> +if (err < 0)
> +break;
> +
> +av_assert0(pic);
> +pic->encode_order = ctx->encode_order +
> +av_fifo_can_read(ctx->encode_fifo);
> +err = vaapi_encode_issue(avctx, pic);
> +if (err < 0) {
> +av_log(avctx, AV_LOG_ERROR, "Encode failed: %d.\n", err);
> +return err;
> +}
> +av_fifo_write(ctx->encode_fifo, &pic, 1);
> +}
> +if (!av_fifo_can_read(ctx->encode_fifo))
> +return err;
> +av_fifo_read(ctx->encode_fifo, &pic, 1);
> +ctx->encode_order = pic->encode_order + 1;
> +} else
> +#endif
> +{
> +pic = NULL;
> +err = vaapi_encode_pick_next(avctx, &pic);
> +if (err < 0)
> +return err;
> +av_assert0(pic);
>
> -pic->encode_order = ctx->encode_order++;
> +pic->encode_order = ctx->encode_order++;
>
> -err = vaapi_encode_issue(avctx, pic);
> -if (err < 0) {
> -av_log(avctx, AV_LOG_ERROR, "Encode failed: %d.\n", err);
> -return err;
> +err = vaapi_encode_issue(avctx, pic);
> +if (err < 0) {
> +av_log(avctx, AV_LOG_ERROR, "Encode failed: %d.\n", err);
> +return err;
> +}
> }
>
> err = vaapi_encode_output(avctx, pic, pkt);
> @@ -2555,6 +2583,19 @@ av_cold int ff_vaapi_encode_init(AVCodecContext *avctx)
> }
> }
>
> +#if VA_CHECK_VERSION(1, 9, 0)
> +//check vaSyncBuffer function
> +vas = vaSyncBuffer(ctx->hwctx->display, 0, 0);
Buf id 0 (the 2nd parameter) might be valid, however we needn't synchronize with
a real buf here, we may use VA_INVALID_ID instead
> +if (vas != VA_STATUS_ERROR_UNIMPLEMENTED) {
> +ctx->has_sync_buffer_func = 1;
> +ctx->encode_fifo = av_fifo_alloc2(MAX_PICTURE_REFERENCES + 1,
> + sizeof(VAAPIEncodePicture *),
> + 0);
> +if (!ctx->encode_fifo)
> +return AVERROR(ENOMEM);
> +}
> +#endif
> +
> return 0;
>
> fail:
> @@ -2592,6 +2633,7 @@ av_cold int ff_vaapi_encode_close(AVCodecContext *avctx)
>
> av_freep(&ctx->codec_sequence_params);
> av_freep(&ctx->codec_picture_params);
> +av_fifo_freep2(&ctx->encode_fifo);
>
> av_buffer_unref(&ctx->recon_frames_ref);
> av_buffer_unref(&ctx->input_frames_ref);
> diff --git a/libavcodec/vaapi_encode.h b/libavcodec/vaapi_encode.h
> index b41604a883..d33a486cb8 100644
> --- a/libavcodec/vaapi_encode.h
> +++ b/libavcodec/vaapi_encode.h
> @@ -29,6 +29,7 @@
>
> #include "libavutil/hwcontext.h"
> #include "libavutil/hwcontext_vaapi.h"
> +#include "libavutil/fifo.h"
>
> #include "avcodec.h"
> #include "hwconfig.h"
> @@ -345,6 +346,10 @@ typedef
Re: [FFmpeg-devel] [PATCH V3 3/3] libavcodec/vaapi_encode: Add async_depth to vaapi_encoder to increase performance
> Add async_depth to increase encoder's performance. Reuse encode_fifo as
> async buffer. Encoder puts all reordered frame to HW and then check
> fifo size. If fifo < async_depth and the top frame is not ready, it will
> return AVERROR(EAGAIN) to require more frames.
>
> 1080p transcoding (no B frames) with -async_depth=4 can increase 20%
> performance on my environment.
> The async increases performance but also introduces frame delay.
>
> Signed-off-by: Wenbin Chen
> ---
> libavcodec/vaapi_encode.c | 16
> libavcodec/vaapi_encode.h | 12 ++--
> 2 files changed, 22 insertions(+), 6 deletions(-)
>
> diff --git a/libavcodec/vaapi_encode.c b/libavcodec/vaapi_encode.c
> index 15ddbbaa4a..432abf31f7 100644
> --- a/libavcodec/vaapi_encode.c
> +++ b/libavcodec/vaapi_encode.c
> @@ -1158,7 +1158,8 @@ static int vaapi_encode_send_frame(AVCodecContext
> *avctx, AVFrame *frame)
> if (ctx->input_order == ctx->decode_delay)
> ctx->dts_pts_diff = pic->pts - ctx->first_pts;
> if (ctx->output_delay > 0)
> -ctx->ts_ring[ctx->input_order % (3 * ctx->output_delay)] = pic-
> >pts;
> +ctx->ts_ring[ctx->input_order %
> +(3 * ctx->output_delay + ctx->async_depth)] = pic-
> >pts;
>
> pic->display_order = ctx->input_order;
> ++ctx->input_order;
> @@ -1214,7 +1215,7 @@ int ff_vaapi_encode_receive_packet(AVCodecContext
> *avctx, AVPacket *pkt)
>
> #if VA_CHECK_VERSION(1, 9, 0)
> if (ctx->has_sync_buffer_func) {
> -while (av_fifo_can_read(ctx->encode_fifo) <= MAX_PICTURE_REFERENCES)
> {
> +while (av_fifo_can_read(ctx->encode_fifo) <= MAX_ASYNC_DEPTH) {
> pic = NULL;
> err = vaapi_encode_pick_next(avctx, &pic);
> if (err < 0)
> @@ -1232,6 +1233,13 @@ int ff_vaapi_encode_receive_packet(AVCodecContext
> *avctx, AVPacket *pkt)
> }
> if (!av_fifo_can_read(ctx->encode_fifo))
> return err;
> +if (av_fifo_can_read(ctx->encode_fifo) < ctx->async_depth &&
> +!ctx->end_of_stream) {
> +av_fifo_peek(ctx->encode_fifo, &pic, 1, 0);
> +err = vaapi_encode_wait(avctx, pic, 0);
> +if (err < 0)
> +return err;
> +}
> av_fifo_read(ctx->encode_fifo, &pic, 1);
> ctx->encode_order = pic->encode_order + 1;
> } else
> @@ -1267,7 +1275,7 @@ int ff_vaapi_encode_receive_packet(AVCodecContext
> *avctx, AVPacket *pkt)
> pkt->dts = ctx->ts_ring[pic->encode_order] - ctx->dts_pts_diff;
> } else {
> pkt->dts = ctx->ts_ring[(pic->encode_order - ctx->decode_delay) %
> -(3 * ctx->output_delay)];
> +(3 * ctx->output_delay + ctx->async_depth)];
> }
> av_log(avctx, AV_LOG_DEBUG, "Output packet: pts %"PRId64" dts
> %"PRId64".\n",
> pkt->pts, pkt->dts);
> @@ -2588,7 +2596,7 @@ av_cold int ff_vaapi_encode_init(AVCodecContext *avctx)
> vas = vaSyncBuffer(ctx->hwctx->display, 0, 0);
> if (vas != VA_STATUS_ERROR_UNIMPLEMENTED) {
> ctx->has_sync_buffer_func = 1;
> -ctx->encode_fifo = av_fifo_alloc2(MAX_PICTURE_REFERENCES + 1,
> +ctx->encode_fifo = av_fifo_alloc2(MAX_ASYNC_DEPTH,
>sizeof(VAAPIEncodePicture *),
>0);
> if (!ctx->encode_fifo)
> diff --git a/libavcodec/vaapi_encode.h b/libavcodec/vaapi_encode.h
> index d33a486cb8..691521387d 100644
> --- a/libavcodec/vaapi_encode.h
> +++ b/libavcodec/vaapi_encode.h
> @@ -48,6 +48,7 @@ enum {
> MAX_TILE_ROWS = 22,
> // A.4.1: table A.6 allows at most 20 tile columns for any level.
> MAX_TILE_COLS = 20,
> +MAX_ASYNC_DEPTH= 64,
> };
>
> extern const AVCodecHWConfigInternal *const ff_vaapi_encode_hw_configs[];
> @@ -298,7 +299,8 @@ typedef struct VAAPIEncodeContext {
> // Timestamp handling.
> int64_t first_pts;
> int64_t dts_pts_diff;
> -int64_t ts_ring[MAX_REORDER_DELAY * 3];
> +int64_t ts_ring[MAX_REORDER_DELAY * 3 +
> +MAX_ASYNC_DEPTH];
>
> // Slice structure.
> int slice_block_rows;
> @@ -350,6 +352,8 @@ typedef struct VAAPIEncodeContext {
> AVFifo *encode_fifo;
> //Whether the driver support vaSyncBuffer
> int has_sync_buffer_func;
> +//Max number of frame buffered in encoder.
> +int async_depth;
> } VAAPIEncodeContext;
>
> enum {
> @@ -460,7 +464,11 @@ int ff_vaapi_encode_close(AVCodecContext *avctx);
> { "b_depth", \
>"Maximum B-frame reference depth", \
>OFFSET(common.desired_b_depth), AV_OPT_TYPE_INT, \
> - { .i64 = 1 }, 1, INT_MAX, FLAGS }
> + { .i64 = 1 }, 1, INT_MAX, FLAGS }, \
> +{ "async_depth", "Maximum processing parallelism. " \
> + "Increase this to i
Re: [FFmpeg-devel] [PATCH V3 1/3] libavcodec/vaapi_encode: Add new API adaption to vaapi_encode
> On Tue, 2022-02-08 at 11:05 +0800, Wenbin Chen wrote:
> > Add vaSyncBuffer to VAAPI encoder. Old version API vaSyncSurface wait
> > surface to complete. When surface is used for multiple operation, it
> > waits all operations to finish. vaSyncBuffer only wait one channel to
> > finish.
> >
> > Add wait param to vaapi_encode_wait() to prepare for the async_depth
> > option. "wait=1" means wait until operation ready. "wait=0" means
> > query operation's status. If it is ready return 0, if it is still
> > in progress return EAGAIN.
> >
> > Signed-off-by: Wenbin Chen
> > ---
> > libavcodec/vaapi_encode.c | 47 +---
> ---
> > 1 file changed, 40 insertions(+), 7 deletions(-)
> >
> > diff --git a/libavcodec/vaapi_encode.c b/libavcodec/vaapi_encode.c
> > index 3bf379b1a0..b87b58a42b 100644
> > --- a/libavcodec/vaapi_encode.c
> > +++ b/libavcodec/vaapi_encode.c
> > @@ -134,7 +134,8 @@ static int
> > vaapi_encode_make_misc_param_buffer(AVCodecContext *avctx,
> > }
> >
> > static int vaapi_encode_wait(AVCodecContext *avctx,
> > - VAAPIEncodePicture *pic)
> > + VAAPIEncodePicture *pic,
> > + uint8_t wait)
> > {
> > VAAPIEncodeContext *ctx = avctx->priv_data;
> > VAStatus vas;
> > @@ -150,11 +151,43 @@ static int vaapi_encode_wait(AVCodecContext
> *avctx,
> > "(input surface %#x).\n", pic->display_order,
> > pic->encode_order, pic->input_surface);
> >
> > -vas = vaSyncSurface(ctx->hwctx->display, pic->input_surface);
> > -if (vas != VA_STATUS_SUCCESS) {
> > -av_log(avctx, AV_LOG_ERROR, "Failed to sync to picture completion:
> > "
> > - "%d (%s).\n", vas, vaErrorStr(vas));
> > +#if VA_CHECK_VERSION(1, 9, 0)
> > +// Try vaSyncBuffer.
> > +vas = vaSyncBuffer(ctx->hwctx->display,
> > + pic->output_buffer,
> > + wait ? VA_TIMEOUT_INFINITE : 0);
> > +if (vas == VA_STATUS_ERROR_TIMEDOUT) {
> > +return AVERROR(EAGAIN);
> > +} else if (vas != VA_STATUS_SUCCESS && vas !=
> > VA_STATUS_ERROR_UNIMPLEMENTED) {
> > +av_log(avctx, AV_LOG_ERROR, "Failed to sync to output buffer
> > completion: "
> > +"%d (%s).\n", vas, vaErrorStr(vas));
> > return AVERROR(EIO);
>
> We may add has_sync_buffer_func flag in this patch, and run the above code
> when
> ctx->has_sync_buffer_func is true. If so, we needn't check whether
> vaSyncBuffer
> is implemented again.
>
> Thanks
> Haihao
Thanks for your review. I will update the patchset.
Thanks
Wenbin
>
>
> > +} else if (vas == VA_STATUS_ERROR_UNIMPLEMENTED)
> > +// If vaSyncBuffer is not implemented, try old version API.
> > +#endif
> > +{
> > +if (!wait) {
> > +VASurfaceStatus surface_status;
> > +vas = vaQuerySurfaceStatus(ctx->hwctx->display,
> > +pic->input_surface,
> > +&surface_status);
> > +if (vas == VA_STATUS_SUCCESS &&
> > +surface_status != VASurfaceReady &&
> > +surface_status != VASurfaceSkipped) {
> > +return AVERROR(EAGAIN);
> > +} else if (vas != VA_STATUS_SUCCESS) {
> > +av_log(avctx, AV_LOG_ERROR, "Failed to query surface
> > status:
> > "
> > +"%d (%s).\n", vas, vaErrorStr(vas));
> > +return AVERROR(EIO);
> > +}
> > +} else {
> > +vas = vaSyncSurface(ctx->hwctx->display, pic->input_surface);
> > +if (vas != VA_STATUS_SUCCESS) {
> > +av_log(avctx, AV_LOG_ERROR, "Failed to sync to picture
> > completion: "
> > +"%d (%s).\n", vas, vaErrorStr(vas));
> > +return AVERROR(EIO);
> > +}
> > +}
> > }
> >
> > // Input is definitely finished with now.
> > @@ -633,7 +666,7 @@ static int vaapi_encode_output(AVCodecContext
> *avctx,
> > uint8_t *ptr;
> > int err;
> >
> > -err = vaapi_encode_wait(avctx, pic);
> > +err = vaapi_encode_wait(avctx, pic, 1);
> > if (err < 0)
> > return err;
> >
> > @@ -695,7 +728,7 @@ fail:
> > static int vaapi_encode_discard(AVCodecContext *avctx,
> > VAAPIEncodePicture *pic)
> > {
> > -vaapi_encode_wait(avctx, pic);
> > +vaapi_encode_wait(avctx, pic, 1);
> >
> > if (pic->output_buffer_ref) {
> > av_log(avctx, AV_LOG_DEBUG, "Discard output for pic "
> ___
> 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/mailma
[FFmpeg-devel] [PATCH] avformat/gnutls: Use the systems default crypto policy
We should use the systems crypto policy by default. If there is no
system policy, gnutls will use the "NORMAL" policy.
Signed-off-by: Andreas Schneider
---
libavformat/tls_gnutls.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavformat/tls_gnutls.c b/libavformat/tls_gnutls.c
index 741578a596..2ab38a199b 100644
--- a/libavformat/tls_gnutls.c
+++ b/libavformat/tls_gnutls.c
@@ -192,7 +192,7 @@ static int tls_open(URLContext *h, const char *uri, int
flags, AVDictionary **op
gnutls_transport_set_pull_function(p->session, gnutls_url_pull);
gnutls_transport_set_push_function(p->session, gnutls_url_push);
gnutls_transport_set_ptr(p->session, p);
-gnutls_priority_set_direct(p->session, "NORMAL", NULL);
+gnutls_set_default_priority(p->session);
do {
if (ff_check_interrupt(&h->interrupt_callback)) {
ret = AVERROR_EXIT;
--
2.34.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".
