Re: [FFmpeg-devel] [PATCH] avcodec: Add MediaFoundation encoder wrapper
What's next? Decoders? ___ 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 1/2] avformat/ftp: Fix for invalid use of av_strtok
On Sat, Apr 18, 2020 at 12:19:30PM +0800, lance.lmw...@gmail.com wrote:
> From: Limin Wang
>
> By the av_strtok() description:
> * On the first call to av_strtok(), s should point to the string to
> * parse, and the value of saveptr is ignored. In subsequent calls, s
> * should be NULL, and saveptr should be unchanged since the previous
> * call.
>
> Signed-off-by: Limin Wang
> ---
> libavformat/ftp.c | 14 --
> 1 file changed, 8 insertions(+), 6 deletions(-)
>
> diff --git a/libavformat/ftp.c b/libavformat/ftp.c
> index e3d194d..caeea42 100644
> --- a/libavformat/ftp.c
> +++ b/libavformat/ftp.c
> @@ -333,15 +333,15 @@ static int ftp_passive_mode(FTPContext *s)
> *end = '\0';
> /* skip ip */
> if (!av_strtok(start, ",", &end)) goto fail;
> -if (!av_strtok(end, ",", &end)) goto fail;
> -if (!av_strtok(end, ",", &end)) goto fail;
> -if (!av_strtok(end, ",", &end)) goto fail;
> +if (!av_strtok(NULL, ",", &end)) goto fail;
> +if (!av_strtok(NULL, ",", &end)) goto fail;
> +if (!av_strtok(NULL, ",", &end)) goto fail;
>
> /* parse port number */
> -start = av_strtok(end, ",", &end);
> +start = av_strtok(NULL, ",", &end);
> if (!start) goto fail;
> s->server_data_port = atoi(start) * 256;
> -start = av_strtok(end, ",", &end);
> +start = av_strtok(NULL, ",", &end);
> if (!start) goto fail;
> s->server_data_port += atoi(start);
> ff_dlog(s, "Server data port: %d\n", s->server_data_port);
> @@ -963,8 +963,10 @@ static int ftp_parse_entry_nlst(char *line, AVIODirEntry
> *next)
> static int ftp_parse_entry_mlsd(char *mlsd, AVIODirEntry *next)
> {
> char *fact, *value;
> +char *saveptr = NULL, *p = mlsd;
> ff_dlog(NULL, "%s\n", mlsd);
> -while(fact = av_strtok(mlsd, ";", &mlsd)) {
> +while(fact = av_strtok(p, ";", &saveptr)) {
> +p = NULL;
> if (fact[0] == ' ') {
> next->name = av_strdup(&fact[1]);
> continue;
> --
> 2.9.5
>
will apply the patchset tomorrow if no more 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 1/2] avformat/vividas: simplify, use av_rescale_q() instead
On Tue, Apr 28, 2020 at 11:49:16AM +0800, lance.lmw...@gmail.com wrote: > From: Limin Wang > > note it'll cause a small difference in accuracy for the pts, please see the > testing result below: > $ wget > http://samples.ffmpeg.org/archive/all/unknown+unknown+unknown+unknown+5029_paramount_en_1250.viv > $ ./ffmpeg -t 0.04 -i > ./unknown+unknown+unknown+unknown+5029_paramount_en_1250.viv -f null - > old: > pts: 522 > pts: 1044 > pts: 1567 > pts: 3918 > pts: 8097 > pts: 12277 > pts: 16457 > ... > > new: > pts: 522 > pts: 1045 > pts: 1567 > pts: 3918 > pts: 8098 > pts: 12278 > pts: 16457 > ... > > Signed-off-by: Limin Wang > --- > libavformat/vividas.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/libavformat/vividas.c b/libavformat/vividas.c > index 4f54a4302e..b0f9f35ac2 100644 > --- a/libavformat/vividas.c > +++ b/libavformat/vividas.c > @@ -646,7 +646,7 @@ static int viv_read_packet(AVFormatContext *s, > pkt->stream_index = 1; > astream = s->streams[pkt->stream_index]; > > -pkt->pts = av_rescale(viv->audio_sample, astream->time_base.den, > astream->time_base.num) / astream->codecpar->sample_rate; > +pkt->pts = av_rescale_q(viv->audio_sample, av_make_q(1, > astream->codecpar->sample_rate), astream->time_base); > viv->audio_sample += > viv->audio_subpackets[viv->current_audio_subpacket].pcm_bytes / 2 / > astream->codecpar->channels; > pkt->flags |= AV_PKT_FLAG_KEY; > viv->current_audio_subpacket++; > -- > 2.21.0 > will apply the patchset tomorrow. -- 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 v1 5/5] avfilter/vf_signalstats: reindent after last commit
On Mon, Dec 30, 2019 at 07:09:58PM +0800, lance.lmw...@gmail.com wrote: > From: Limin Wang > > Signed-off-by: Limin Wang > --- > libavfilter/vf_signalstats.c | 12 ++-- > 1 file changed, 6 insertions(+), 6 deletions(-) > > diff --git a/libavfilter/vf_signalstats.c b/libavfilter/vf_signalstats.c > index 8b2a9ca7c2..1ccc16dd38 100644 > --- a/libavfilter/vf_signalstats.c > +++ b/libavfilter/vf_signalstats.c > @@ -168,13 +168,13 @@ static int config_output(AVFilterLink *outlink) > s->vsub = desc->log2_chroma_h; > s->depth = desc->comp[0].depth; > s->maxsize = 1 << s->depth; > -s->histy = av_malloc_array(s->maxsize, sizeof(*s->histy)); > -s->histu = av_malloc_array(s->maxsize, sizeof(*s->histu)); > -s->histv = av_malloc_array(s->maxsize, sizeof(*s->histv)); > -s->histsat = av_malloc_array(s->maxsize, sizeof(*s->histsat)); > +s->histy = av_malloc_array(s->maxsize, sizeof(*s->histy)); > +s->histu = av_malloc_array(s->maxsize, sizeof(*s->histu)); > +s->histv = av_malloc_array(s->maxsize, sizeof(*s->histv)); > +s->histsat = av_malloc_array(s->maxsize, sizeof(*s->histsat)); > > -if (!s->histy || !s->histu || !s->histv || !s->histsat) > -return AVERROR(ENOMEM); > +if (!s->histy || !s->histu || !s->histv || !s->histsat) > +return AVERROR(ENOMEM); > > outlink->w = inlink->w; > outlink->h = inlink->h; > -- > 2.21.0 > will apply the patchset tomorrow if no 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 5/6] avformat/hlsenc: Simplify setting basename with av_asprintf()
> 2020年5月10日 上午3:15，Andreas Rheinhardt 写道：
>
> Signed-off-by: Andreas Rheinhardt
> ---
> libavformat/hlsenc.c | 43 ++-
> 1 file changed, 14 insertions(+), 29 deletions(-)
>
> diff --git a/libavformat/hlsenc.c b/libavformat/hlsenc.c
> index 5517cb4354..d80852739e 100644
> --- a/libavformat/hlsenc.c
> +++ b/libavformat/hlsenc.c
> @@ -2739,15 +2739,21 @@ static int hls_init(AVFormatContext *s)
> int i = 0;
> int j = 0;
> HLSContext *hls = s->priv_data;
> -const char *pattern = "%d.ts";
> +const char *pattern;
> VariantStream *vs = NULL;
> -int basename_size = 0;
> -const char *pattern_localtime_fmt = get_default_pattern_localtime_fmt(s);
> const char *vtt_pattern = hls->flags & HLS_SINGLE_FILE ? ".vtt" :
> "%d.vtt";
> char *p = NULL;
> int http_base_proto = ff_is_http_proto(s->url);
> int fmp4_init_filename_len = strlen(hls->fmp4_init_filename) + 1;
>
> +if (hls->use_localtime) {
> +pattern = get_default_pattern_localtime_fmt(s);
> +} else {
> +pattern = hls->segment_type == SEGMENT_TYPE_FMP4 ? "%d.m4s" :
> "%d.ts";
> +if (hls->flags & HLS_SINGLE_FILE)
> +pattern += 2;
> +}
> +
> hls->has_default_key = 0;
> hls->has_video_m3u8 = 0;
> ret = update_variant_stream_info(s);
> @@ -2792,9 +2798,6 @@ static int hls_init(AVFormatContext *s)
> }
> }
>
> -if (hls->segment_type == SEGMENT_TYPE_FMP4) {
> -pattern = "%d.m4s";
> -}
> if ((hls->start_sequence_source_type ==
> HLS_START_SEQUENCE_AS_SECONDS_SINCE_EPOCH) ||
> (hls->start_sequence_source_type ==
> HLS_START_SEQUENCE_AS_MICROSECONDS_SINCE_EPOCH) ||
> (hls->start_sequence_source_type ==
> HLS_START_SEQUENCE_AS_FORMATTED_DATETIME)) {
> @@ -2868,34 +2871,16 @@ static int hls_init(AVFormatContext *s)
> if (ret < 0)
> return ret;
> } else {
> -if (hls->flags & HLS_SINGLE_FILE) {
> -if (hls->segment_type == SEGMENT_TYPE_FMP4) {
> -pattern = ".m4s";
> -} else {
> -pattern = ".ts";
> -}
> -}
> -
> -if (hls->use_localtime) {
> -basename_size = strlen(vs->m3u8_name) +
> strlen(pattern_localtime_fmt) + 1;
> -} else {
> -basename_size = strlen(vs->m3u8_name) + strlen(pattern) + 1;
> -}
> +p = strrchr(vs->m3u8_name, '.');
> +if (p)
> +*p = '\0';
>
> -vs->basename = av_malloc(basename_size);
> +vs->basename = av_asprintf("%s%s", vs->m3u8_name, pattern);
> if (!vs->basename)
> return AVERROR(ENOMEM);
>
> -av_strlcpy(vs->basename, vs->m3u8_name, basename_size);
> -
> -p = strrchr(vs->basename, '.');
> if (p)
> -*p = '\0';
> -if (hls->use_localtime) {
> -av_strlcat(vs->basename, pattern_localtime_fmt,
> basename_size);
> -} else {
> -av_strlcat(vs->basename, pattern, basename_size);
> -}
> +*p = '.';
> }
>
> if (hls->segment_type == SEGMENT_TYPE_FMP4) {
> --
> 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".
LGTM
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 4/6] avformat/hlsenc: Simplify setting subtitle basename with av_asprintf
> 2020年5月10日 上午3:15，Andreas Rheinhardt 写道：
>
> Signed-off-by: Andreas Rheinhardt
> ---
> This patch is designed not to change the output at all. Yet I wonder if
> instead of p = strrchr(vs->m3u8_name, '.') it should not better be p =
> strrchr(av_basename(vs->m3u8_name), '.'). Otherwise in a path like
> "./hlsstream/master" everything after '.' will be treated as extension
> which does not seem to be intended. The same remark also applies to e.g.
> the next patch.
>
> libavformat/hlsenc.c | 20
> 1 file changed, 8 insertions(+), 12 deletions(-)
>
> diff --git a/libavformat/hlsenc.c b/libavformat/hlsenc.c
> index 2a0d17baea..5517cb4354 100644
> --- a/libavformat/hlsenc.c
> +++ b/libavformat/hlsenc.c
> @@ -2743,9 +2743,8 @@ static int hls_init(AVFormatContext *s)
> VariantStream *vs = NULL;
> int basename_size = 0;
> const char *pattern_localtime_fmt = get_default_pattern_localtime_fmt(s);
> -const char *vtt_pattern = "%d.vtt";
> +const char *vtt_pattern = hls->flags & HLS_SINGLE_FILE ? ".vtt" :
> "%d.vtt";
> char *p = NULL;
> -int vtt_basename_size = 0;
> int http_base_proto = ff_is_http_proto(s->url);
> int fmp4_init_filename_len = strlen(hls->fmp4_init_filename) + 1;
>
> @@ -2954,28 +2953,25 @@ static int hls_init(AVFormatContext *s)
> if (!vs->vtt_oformat)
> return AVERROR_MUXER_NOT_FOUND;
>
> -if (hls->flags & HLS_SINGLE_FILE)
> -vtt_pattern = ".vtt";
> -vtt_basename_size = strlen(vs->m3u8_name) + strlen(vtt_pattern)
> + 1;
> +p = strrchr(vs->m3u8_name, '.');
> +if (p)
> +*p = '\0';
>
> -vs->vtt_basename = av_malloc(vtt_basename_size);
> +vs->vtt_basename = av_asprintf("%s%s", vs->m3u8_name,
> vtt_pattern);
> if (!vs->vtt_basename)
> return AVERROR(ENOMEM);
> -av_strlcpy(vs->vtt_basename, vs->m3u8_name, vtt_basename_size);
> -p = strrchr(vs->vtt_basename, '.');
> -if (p)
> -*p = '\0';
>
> if (hls->subtitle_filename) {
> ret = format_name(hls->subtitle_filename, &vs->vtt_m3u8_name,
> i, vs->varname);
> if (ret < 0)
> return ret;
> } else {
> -vs->vtt_m3u8_name = av_asprintf("%s_vtt.m3u8",
> vs->vtt_basename);
> +vs->vtt_m3u8_name = av_asprintf("%s_vtt.m3u8",
> vs->m3u8_name);
> if (!vs->vtt_m3u8_name)
> return AVERROR(ENOMEM);
> }
> -av_strlcat(vs->vtt_basename, vtt_pattern, vtt_basename_size);
> +if (p)
> +*p = '.';
> }
>
> if (hls->baseurl) {
> --
> 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".
LGTM
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 6/6] avformat/hlsenc: Simplify setting base_output_dirname
> 2020年5月10日 上午3:15，Andreas Rheinhardt 写道：
>
> Signed-off-by: Andreas Rheinhardt
> ---
> The usage of fmp4_init_filename_len is weird: It is basically used for
> two different purposes: The length of vs->fmp4_init_filename_len and the
> length of vs->base_output_dirname (this name is btw misleading because
> it is not a dirname at all). And given that it's scope is the whole
> function, the second time vs->fmp4_init_filename was allocated it also
> contained enough space to contain the whole of vs->m3u8_name.
>
> Furthermore, there seems to be a misconception in the way the
> fmp4_init_filename_len is calculated in case of more than one
> varstreams: It is incremented by strlen("_%d"), yet the string is not
> built by inserting "_%d" into the other string; instead if no %v is
> present in the string and if there is more than varstream, then it is
> created by inserting "_%d", where %d is replace by the actual index of
> the varstream. And this can take more than three bytes. But it is not
> dangerous: fmp4_init_filename_len is incremented by strlen("_%d") on
> every iteration of the loop.
>
> I also pondered using av_append_path_component() in the case that p is
> not NULL below; yet this might swallow a "/" and I don't know if it
> would make a difference. (Is it actually allowed to use an absolute path
> for hls->fmp4_init_filename? If one does so, said path will still be
> treated as relative to the directory of vs->m3u8_name.)
>
> I can also give vs->fmp4_init_filename a similar treatment; yet before
> doing so I'd like to know if it is intentional that a "%v" in
> hls->fmp4_init_filename only gets replaced if there is more than one
> varstream (in other cases a %v also gets replaced when one only has one
> varstream).
>
> libavformat/hlsenc.c | 24 +---
> 1 file changed, 9 insertions(+), 15 deletions(-)
>
> diff --git a/libavformat/hlsenc.c b/libavformat/hlsenc.c
> index d80852739e..be54957e9d 100644
> --- a/libavformat/hlsenc.c
> +++ b/libavformat/hlsenc.c
> @@ -2908,24 +2908,18 @@ static int hls_init(AVFormatContext *s)
> return ret;
> }
>
> -fmp4_init_filename_len = strlen(vs->m3u8_name) +
> -strlen(vs->fmp4_init_filename) + 1;
> -
> -vs->base_output_dirname = av_malloc(fmp4_init_filename_len);
> -if (!vs->base_output_dirname)
> -return AVERROR(ENOMEM);
> -
> -av_strlcpy(vs->base_output_dirname, vs->m3u8_name,
> - fmp4_init_filename_len);
> -p = strrchr(vs->base_output_dirname, '/');
> +p = strrchr(vs->m3u8_name, '/');
> if (p) {
> -*(p + 1) = '\0';
> -av_strlcat(vs->base_output_dirname,
> vs->fmp4_init_filename,
> - fmp4_init_filename_len);
> +char tmp = *(++p);
> +*p = '\0';
> +vs->base_output_dirname = av_asprintf("%s%s",
> vs->m3u8_name,
> +
> vs->fmp4_init_filename);
> +*p = tmp;
> } else {
> -av_strlcpy(vs->base_output_dirname,
> vs->fmp4_init_filename,
> - fmp4_init_filename_len);
> +vs->base_output_dirname =
> av_strdup(vs->fmp4_init_filename);
> }
> +if (!vs->base_output_dirname)
> +return AVERROR(ENOMEM);
> }
> }
>
> --
> 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".
LGTM
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 v2] avcodec/exr: output float pixels in float pixel format
From: Mark Reid
changes since v1
- default behavior, no longer hidden behind decoder parameter
- updated tests to reflect change
---
libavcodec/exr.c | 244 +-
tests/fate/image.mak | 120 -
tests/ref/fate/exr-rgb-b44a-half-negative-4x4 | 2 +-
.../exr-rgb-scanline-b44-half-float-12x8-l1 | 2 +-
.../exr-rgb-scanline-b44-half-float-12x8-l2 | 2 +-
tests/ref/fate/exr-rgb-scanline-float-b44 | 2 +-
.../ref/fate/exr-rgb-scanline-float-piz-48x32 | 2 +-
tests/ref/fate/exr-rgb-scanline-half-b44-12x8 | 2 +-
tests/ref/fate/exr-rgb-scanline-half-b44-13x9 | 2 +-
tests/ref/fate/exr-rgb-scanline-half-piz-bw | 2 +-
.../ref/fate/exr-rgb-scanline-half-piz-color | 2 +-
.../ref/fate/exr-rgb-scanline-half-piz-dw-t01 | 2 +-
.../ref/fate/exr-rgb-scanline-half-piz-dw-t08 | 2 +-
.../fate/exr-rgb-scanline-none-negative-red | 2 +-
.../fate/exr-rgb-scanline-pxr24-float-12x8| 2 +-
.../fate/exr-rgb-scanline-pxr24-float-half-l1 | 2 +-
.../fate/exr-rgb-scanline-pxr24-float-half-l2 | 2 +-
.../fate/exr-rgb-scanline-pxr24-half-float-l1 | 2 +-
.../fate/exr-rgb-scanline-pxr24-half-float-l2 | 2 +-
.../exr-rgb-scanline-pxr24-half-uint32-13x9 | 2 +-
.../fate/exr-rgb-scanline-raw-half-float-l1 | 2 +-
.../fate/exr-rgb-scanline-raw-half-float-l2 | 2 +-
.../fate/exr-rgb-scanline-rle-half-float-l1 | 2 +-
.../fate/exr-rgb-scanline-rle-half-float-l2 | 2 +-
.../fate/exr-rgb-scanline-zip-half-float-l1 | 2 +-
.../fate/exr-rgb-scanline-zip-half-float-l2 | 2 +-
.../fate/exr-rgb-scanline-zip1-half-float-l1 | 2 +-
...b-scanline-zip1-half-float-l1-zero-offsets | 2 +-
.../fate/exr-rgb-scanline-zip1-half-float-l2 | 2 +-
tests/ref/fate/exr-rgb-tile-float-raw-12x8| 2 +-
tests/ref/fate/exr-rgb-tile-float-raw-150x130 | 2 +-
.../fate/exr-rgb-tile-half-float-b44-12x8-l1 | 2 +-
.../fate/exr-rgb-tile-half-float-b44-12x8-l2 | 2 +-
tests/ref/fate/exr-rgb-tile-half-raw-12x8 | 2 +-
.../ref/fate/exr-rgb-tile-pxr24-float-half-l1 | 2 +-
.../ref/fate/exr-rgb-tile-pxr24-float-half-l2 | 2 +-
.../ref/fate/exr-rgb-tile-pxr24-half-float-l1 | 2 +-
.../ref/fate/exr-rgb-tile-pxr24-half-float-l2 | 2 +-
tests/ref/fate/exr-rgb-tile-raw-half-float-l1 | 2 +-
tests/ref/fate/exr-rgb-tile-raw-half-float-l2 | 2 +-
tests/ref/fate/exr-rgb-tile-rle-half-float-l1 | 2 +-
tests/ref/fate/exr-rgb-tile-rle-half-float-l2 | 2 +-
tests/ref/fate/exr-rgb-tile-zip-half-float-l1 | 2 +-
tests/ref/fate/exr-rgb-tile-zip-half-float-l2 | 2 +-
.../ref/fate/exr-rgb-tile-zip1-half-float-l1 | 2 +-
.../ref/fate/exr-rgb-tile-zip1-half-float-l2 | 2 +-
.../ref/fate/exr-rgba-multiscanline-half-b44 | 2 +-
.../exr-rgba-scanline-float-half-b44-12x8-l1 | 2 +-
.../exr-rgba-scanline-float-half-b44-12x8-l2 | 2 +-
.../exr-rgba-scanline-float-half-b44-13x9-l1 | 2 +-
.../exr-rgba-scanline-float-half-b44-13x9-l2 | 2 +-
.../exr-rgba-scanline-float-half-b44a-12x8-l1 | 2 +-
.../exr-rgba-scanline-float-half-b44a-12x8-l2 | 2 +-
.../exr-rgba-scanline-float-half-b44a-13x9-l1 | 2 +-
.../exr-rgba-scanline-float-half-b44a-13x9-l2 | 2 +-
tests/ref/fate/exr-rgba-zip16-16x32-flag4 | 2 +-
tests/ref/fate/exr-slice-pxr24| 2 +-
tests/ref/fate/exr-slice-raw | 2 +-
tests/ref/fate/exr-slice-rle | 2 +-
tests/ref/fate/exr-slice-zip1 | 2 +-
tests/ref/fate/exr-slice-zip16| 2 +-
tests/ref/fate/exr-y-scanline-zip-half-12x8 | 2 +-
tests/ref/fate/exr-y-tile-zip-half-12x8 | 2 +-
63 files changed, 246 insertions(+), 240 deletions(-)
diff --git a/libavcodec/exr.c b/libavcodec/exr.c
index 73419eadb1..68d5befa40 100644
--- a/libavcodec/exr.c
+++ b/libavcodec/exr.c
@@ -30,7 +30,6 @@
* For more information on the OpenEXR format, visit:
* http://openexr.com/
*
- * exr_flt2uint() and exr_halflt2uint() is credited to Reimar Döffinger.
* exr_half2float() is credited to Aaftab Munshi, Dan Ginsburg, Dave Shreiner.
*/
@@ -160,7 +159,7 @@ typedef struct EXRContext {
enum AVColorTransferCharacteristic apply_trc_type;
float gamma;
-uint16_t gamma_table[65536];
+union av_intfloat32 gamma_table[65536];
} EXRContext;
/* -15 stored using a single precision bias of 127 */
@@ -225,47 +224,6 @@ static union av_intfloat32 exr_half2float(uint16_t hf)
return f;
}
-
-/**
- * Convert from 32-bit float as uint32_t to uint16_t.
- *
- * @param v 32-bit float
- *
- * @return normalized 16-bit unsigned int
- */
-static inline uint16_t exr_flt2uint(int32_t v)
-{
-int32_t exp = v >> 23;
-// "HACK": negative values result in exp< 0, so clipping them to 0
-// is also handled by this condition, avoids explicit check for sign bit.
-if (exp <= 127 + 7 - 24) // we would shift out all bits anyway
-return 0;
-if (exp >= 127)
-ret
Re: [FFmpeg-devel] [PATCH 2/6] avformat/hlsenc: Remove redundant initializations
> 2020年5月10日 上午3:15，Andreas Rheinhardt 写道： > > For every variantstream vs, vs->packets_written is set to one, only to be > set to zero a few lines below. Given that the relevant structure has > been zeroed during the allocation, this commit removes both assignments. > A redundant initialization for vs->init_range_length has been removed as > well a few lines below. Given that the relevant structure has been > zeroed during the allocation, this commit removes both assignments. A > redundant initialization for vs->init_range_length has been removed as > well. > > Signed-off-by: Andreas Rheinhardt > --- > libavformat/hlsenc.c | 4 > 1 file changed, 4 deletions(-) > > diff --git a/libavformat/hlsenc.c b/libavformat/hlsenc.c > index a796c124dd..afb4d2a0c0 100644 > --- a/libavformat/hlsenc.c > +++ b/libavformat/hlsenc.c > @@ -833,7 +833,6 @@ static int hls_mux_init(AVFormatContext *s, VariantStream > *vs) > av_dict_copy(&st->metadata, vs->streams[i]->metadata, 0); > } > > -vs->packets_written = 1; > vs->start_pos = 0; > vs->new_start = 1; > > @@ -848,9 +847,6 @@ static int hls_mux_init(AVFormatContext *s, VariantStream > *vs) > } > } > > -vs->packets_written = 0; > -vs->init_range_length = 0; > - > if ((ret = avio_open_dyn_buf(&oc->pb)) < 0) > 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". LGTM 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 3/6] avformat/hlsenc: Don't cast const away
> 2020年5月10日 上午3:15，Andreas Rheinhardt 写道：
>
> Signed-off-by: Andreas Rheinhardt
> ---
> libavformat/hlsenc.c | 8
> 1 file changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/libavformat/hlsenc.c b/libavformat/hlsenc.c
> index afb4d2a0c0..2a0d17baea 100644
> --- a/libavformat/hlsenc.c
> +++ b/libavformat/hlsenc.c
> @@ -525,10 +525,10 @@ static int hls_delete_old_segments(AVFormatContext *s,
> HLSContext *hls,
> int ret = 0;
> int segment_cnt = 0;
> AVBPrint path;
> -char *dirname = NULL;
> +const char *dirname = NULL;
> char *dirname_r = NULL;
> char *dirname_repl = NULL;
> -char *vtt_dirname = NULL;
> +const char *vtt_dirname = NULL;
> char *vtt_dirname_r = NULL;
> const char *proto = NULL;
>
> @@ -559,7 +559,7 @@ static int hls_delete_old_segments(AVFormatContext *s,
> HLSContext *hls,
>
> if (segment && !hls->use_localtime_mkdir) {
> dirname_r = hls->segment_filename ? av_strdup(hls->segment_filename):
> av_strdup(vs->avf->url);
> -dirname = (char*)av_dirname(dirname_r);
> +dirname = av_dirname(dirname_r);
> }
>
> /* if %v is present in the file's directory
> @@ -598,7 +598,7 @@ static int hls_delete_old_segments(AVFormatContext *s,
> HLSContext *hls,
>
> if ((segment->sub_filename[0] != '\0')) {
> vtt_dirname_r = av_strdup(vs->vtt_avf->url);
> -vtt_dirname = (char*)av_dirname(vtt_dirname_r);
> +vtt_dirname = av_dirname(vtt_dirname_r);
>
> av_bprint_clear(&path);
> av_bprintf(&path, "%s%c%s", vtt_dirname, SEPARATOR,
> --
> 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".
LGTM
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 1/6] avformat/hlsenc: Don't reset AVIOContext pointer manually a second time
> 2020年5月10日 上午3:15，Andreas Rheinhardt 写道：
>
> ff_format_io_close() already does it for us.
>
> Signed-off-by: Andreas Rheinhardt
> ---
> libavformat/hlsenc.c | 1 -
> 1 file changed, 1 deletion(-)
>
> diff --git a/libavformat/hlsenc.c b/libavformat/hlsenc.c
> index 7b289c060f..a796c124dd 100644
> --- a/libavformat/hlsenc.c
> +++ b/libavformat/hlsenc.c
> @@ -2497,7 +2497,6 @@ static int hls_write_packet(AVFormatContext *s,
> AVPacket *pkt)
> if ((ret = hls_window(s, 0, vs)) < 0) {
> av_log(s, AV_LOG_WARNING, "upload playlist failed, will retry
> with a new http session.\n");
> ff_format_io_close(s, &vs->out);
> -vs->out = NULL;
> if ((ret = hls_window(s, 0, vs)) < 0) {
> av_freep(&old_filename);
> 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".
LGTM
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] [EXT] [PATCH 1/2] avcodec/v4l2_context: Drop empty packet while draining
On Tue, 05. May 17:29, Andriy Gelman wrote:
> On Thu, 30. Apr 01:39, Ming Qian wrote:
> > > From: Andriy Gelman
> > >
> > > v4l2_m2m devices may send an empty packet/frame while draining to indicate
> > > that all capture buffers have been flushed.
> > >
> > > Currently, the empty packet/frame is not handled correctly:
> > > When encoding, the empty packet is forwarded to the muxer, usually
> > > creating
> > > warnings.
> > > When decoding, a reference to the memory is created anyway.. Since in the
> > > past this memory contained a decoded frame, it results in an extra frame
> > > being
> > > decoded.
> > >
> > > This commit discards the empty packet/frame.
> > >
> > > References:
> > > linux/Documentation/media/uapi/v4l/dev-decoder.rst:
> > >
> > > "The last buffer may be empty (with :c:type:`v4l2_buffer` bytesused =
> > > 0)
> > > and in that case it must be ignored by the client, as it does not
> > > contain a decoded frame."
> > >
> > > linux/Documentation/media/uapi/media/v4l/vidioc-encoder-cmd.rst:
> > >
> > > "...This buffer may be empty, indicated by the
> > > driver setting the ``bytesused`` field to 0."
> > >
> > > Signed-off-by: Andriy Gelman
> > > ---
> > > libavcodec/v4l2_context.c | 9 +
> > > 1 file changed, 9 insertions(+)
> > >
> > > diff --git a/libavcodec/v4l2_context.c b/libavcodec/v4l2_context.c index
> > > 6c2db5c849..f0ecc18ebd 100644
> > > --- a/libavcodec/v4l2_context.c
> > > +++ b/libavcodec/v4l2_context.c
> > > @@ -393,6 +393,15 @@ dequeue:
> > > return NULL;
> > > }
> > >
> > > +if (ctx_to_m2mctx(ctx)->draining
> > > && !V4L2_TYPE_IS_OUTPUT(ctx->type)) {
> > > +int bytesused = V4L2_TYPE_IS_MULTIPLANAR(buf.type) ?
> > > +buf.m.planes[0].bytesused : buf.bytesused;
> > > +if (bytesused == 0) {
> > > +ctx->done = 1;
> > > +return NULL;
> > > +}
> > > +}
> > > +
> > > avbuf = &ctx->buffers[buf.index];
> > > avbuf->status = V4L2BUF_AVAILABLE;
> > > avbuf->buf = buf;
> > > --
> > > 2.25.1
> > >
>
> >
> > Lgtm
> >
>
> Thanks.
> Will apply both patches on Friday if no one objects.
>
Applied both patches.
Thanks,
--
Andriy
___
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/decode: remove unused AVCodecInternal compat_decode field
On 3/9/2020 9:09 AM, James Almer wrote:
> On 3/9/2020 6:09 AM, Hendrik Leppkes wrote:
>> On Mon, Mar 9, 2020 at 3:20 AM James Almer wrote:
>>>
>>> Signed-off-by: James Almer
>>> ---
>>> libavcodec/decode.c | 1 -
>>> libavcodec/internal.h | 1 -
>>> 2 files changed, 2 deletions(-)
>>>
>>> diff --git a/libavcodec/decode.c b/libavcodec/decode.c
>>> index 03b9da25f9..0e3d7e17e4 100644
>>> --- a/libavcodec/decode.c
>>> +++ b/libavcodec/decode.c
>>> @@ -826,7 +826,6 @@ static int compat_decode(AVCodecContext *avctx, AVFrame
>>> *frame,
>>> }
>>>
>>> *got_frame = 0;
>>> -avci->compat_decode = 1;
>>>
>>> if (avci->compat_decode_partial_size > 0 &&
>>> avci->compat_decode_partial_size != pkt->size) {
>>> diff --git a/libavcodec/internal.h b/libavcodec/internal.h
>>> index bccd9222d4..972e93bcfa 100644
>>> --- a/libavcodec/internal.h
>>> +++ b/libavcodec/internal.h
>>> @@ -208,7 +208,6 @@ typedef struct AVCodecInternal {
>>> AVFrame *buffer_frame;
>>> int draining_done;
>>> /* set to 1 when the caller is using the old decoding API */
>>> -int compat_decode;
>>> int compat_decode_warned;
>>> /* this variable is set by the decoder internals to signal to the old
>>> * API compat wrappers the amount of data consumed from the last
>>> packet */
>>
>> The comment above it seems to want to reference the removed field?
>
> Good catch. Removed locally.
Applied.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH v4 03/11] libavutil/hwcontext_d3d11va: adding more texture information to the D3D11 hwcontext API
> -Original Message- > From: ffmpeg-devel On Behalf Of > Artem Galin > Sent: Sunday, May 10, 2020 1:19 AM > To: FFmpeg development discussions and patches de...@ffmpeg.org> > Subject: Re: [FFmpeg-devel] [PATCH v4 03/11] libavutil/hwcontext_d3d11va: > adding more texture information to the D3D11 hwcontext API > > On Sat, 9 May 2020 at 22:29, Soft Works wrote: > > > You replied: > > > yes, it is only a hint for D11 when possible. > > > > I would understand 'when possible' in a way that D3D9 would be used > > 'when not possible'. > > > > If that's true, it means, that an ffmpeg user executing a command line > > cannot be sure whether D3D9 or DX11 will be used. That would mean that > > the behavior is not deterministic. > > > This is not true, it is your assumptions. > Behavior is deterministic: > DX11 by default. > DX9 if user selects it explicitly via command line. > > > > But still, even with your patch: What will happen when DX11 is not > > > > available? > > > > > > > > Will it > > > > > > > Please read the patch > > > > > 1. fail? > > > Yes Thanks for confirming this. Deterministic behavior instead of auto-selection Is important and should not be changed. But on the other side, it needs to be clear to everybody, that this once again adds even more to the list of situations that the patch will break: In this case, it's all Windows versions where DX11 is not available. Best regards, softworkz ___ 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 v4 03/11] libavutil/hwcontext_d3d11va: adding more texture information to the D3D11 hwcontext API
On Sat, 9 May 2020 at 22:29, Soft Works wrote: > > -Original Message- > > From: ffmpeg-devel On Behalf Of > > Max Dmitrichenko > > Sent: Saturday, May 9, 2020 10:42 PM > > To: FFmpeg development discussions and patches > de...@ffmpeg.org> > > Subject: Re: [FFmpeg-devel] [PATCH v4 03/11] libavutil/hwcontext_d3d11va: > > adding more texture information to the D3D11 hwcontext API > > > > > You can document that wherever you want, but for existing users, > > > command lines that have always been working before will stop working > > > in a significant number of cases. > > > > > > > > not sure where it goes: if a user uses new version - there are new > aspects to > > consider > > Is that so? Whether or not that is acceptable for ffmpeg is not up to me > to decide, though. I'm just trying to illustrate the consequences. > > > > > But still, even with your patch: What will happen when DX11 is not > > > available? > > > > > > Will it > > > > Please read the patch > > > 1. fail? > Yes > > > 2. or will it use D3D9 instead? > No automatic fallback to D3D9, D3D9 is selected by explicit command line only > > > > > > > > there should be no secrets here - implementation is available, do you see > > fallback implementation? > > Yes, I'm seeing that indeed: > > Mark Thompson asked: > >> > +mfxIMPL impl = MFX_IMPL_AUTO_ANY | MFX_IMPL_VIA_D3D11; > >> > >> Does that still do the right thing on systems where only D3D9 works? > yes, it works with DX9. This flag is mandatory only for DX11. > > You replied: > > yes, it is only a hint for D11 when possible. > > I would understand 'when possible' in a way that D3D9 would be used > 'when not possible'. > > If that's true, it means, that an ffmpeg user executing a command line > cannot be sure whether D3D9 or DX11 will be used. That would mean > that the behavior is not deterministic. > This is not true, it is your assumptions. Behavior is deterministic: DX11 by default. DX9 if user selects it explicitly via command line. > > Regards, > softworkz > > > > ___ > 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". Regards, Artem. ___ 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: move init file write code block to hls_write_header
> 2020年5月10日 上午3:21，Andreas Rheinhardt 写道：
>
> Steven Liu:
>> Signed-off-by: Steven Liu
>> ---
>> libavformat/hlsenc.c | 37 -
>> 1 file changed, 20 insertions(+), 17 deletions(-)
>>
>> diff --git a/libavformat/hlsenc.c b/libavformat/hlsenc.c
>> index 5695c6cc95..a1eddade7b 100644
>> --- a/libavformat/hlsenc.c
>> +++ b/libavformat/hlsenc.c
>> @@ -2266,6 +2266,26 @@ static int hls_write_header(AVFormatContext *s)
>> }
>> }
>> }
>> +if (hls->segment_type == SEGMENT_TYPE_FMP4 &&
>> !vs->init_range_length) {
>> +int range_length = 0;
>> +int byterange_mode = (hls->flags & HLS_SINGLE_FILE) ||
>> (hls->max_seg_size > 0);
>> +av_write_frame(vs->avf, NULL); /* Flush any buffered data */
>> +avio_tell(vs->avf->pb);
>> +avio_flush(vs->avf->pb);
>> +range_length = avio_close_dyn_buf(vs->avf->pb,
>> &vs->init_buffer);
>> +if (range_length <= 0)
>> +return AVERROR(EINVAL);
>> +avio_write(vs->out, vs->init_buffer, range_length);
>> +if (!hls->resend_init_file)
>> +av_freep(&vs->init_buffer);
>> +vs->init_range_length = range_length;
>> +avio_open_dyn_buf(&vs->avf->pb);
>> +vs->packets_written = 0;
>> +vs->start_pos = range_length;
>> +if (!byterange_mode) {
>> +hlsenc_io_close(s, &vs->out, vs->base_output_dirname);
>> +}
>> +}
>> }
>>
>> return ret;
>> @@ -2383,23 +2403,6 @@ static int hls_write_packet(AVFormatContext *s,
>> AVPacket *pkt)
>> new_start_pos = avio_tell(oc->pb);
>> vs->size = new_start_pos - vs->start_pos;
>> avio_flush(oc->pb);
>> -if (hls->segment_type == SEGMENT_TYPE_FMP4) {
>> -if (!vs->init_range_length) {
>> -range_length = avio_close_dyn_buf(oc->pb, &vs->init_buffer);
>> -if (range_length <= 0)
>> -return AVERROR(EINVAL);
>> -avio_write(vs->out, vs->init_buffer, range_length);
>> -if (!hls->resend_init_file)
>> -av_freep(&vs->init_buffer);
>> -vs->init_range_length = range_length;
>> -avio_open_dyn_buf(&oc->pb);
>> -vs->packets_written = 0;
>> -vs->start_pos = range_length;
>> -if (!byterange_mode) {
>> -hlsenc_io_close(s, &vs->out, vs->base_output_dirname);
>> -}
>> -}
>> -}
>> if (!byterange_mode) {
>> if (vs->vtt_avf) {
>> hlsenc_io_close(s, &vs->vtt_avf->pb, vs->vtt_avf->url);
>>
>
> 1. Delaying writing the header was introduced in commit
> 880b299381de1e66f8248abd6c320c7c490466a2 to fix ticket 6825 (where the
> number of channels in the input stream switches).
Ok, I get it, this is a good point.
> Have you tested
> whether your patch breaks said ticket again?
> 2. You don't need to check for vs->init_range_length being zero when
> writing the header as this is automatically fulfilled. (After all, one
> calls avformat_write_header() only once.)
> 3. There is also code in hls_write_trailer() that duplicates the code to
> write the init file (should actually have been factored out into a
> common function...). It has been added in commit
> 76b8e42c1f0453215244c45114d5aa302e2add7b to address ticket #7166 and if
> you always write the init file in write_header, you should also remove
> the code in write_trailer.
> 4. Commit 880b299381de1e66f8248abd6c320c7c490466a2 also added the
> packets_written member; it was initialized to 0 in mp4 mode and to 1 in
> non-mp4 mode. Since cff309097a3af4f7f2acb5b5f9fb914ba9ae45c3 this was
> set to 1 initially just in order to be reset to 0 a few lines below.
> Maybe packets_written should be removed completely? (I made a patch [2]
> to remove the currently redundant initializations.)
> 5. The current way of writing the init header (that you intend to remove
> in this commit) has a serious issue: If you have a subtitle and an audio
> stream, yet no video stream and if the audio is delayed sufficiently,
> then a subtitle packet triggers the output of the mp4 init header. But
> subtitles are output directly and not via dynamic buffers and yet the
> code presumes that the AVIOContext for output is a dynamic buffer. This
> leads to segfaults. (If you remember, this is point 6 in [1].) This
> patch seems to fix this; but if you drop this patch because of 1., this
> still needs to addressed.
I Get your point.
Let me think about how to move it out of hls_write_packet,
Maybe hlsenc cannot support LowLatency HLS if it always in hls_write_packet.
Or maybe need modify some code in movenc, I want try only modify in hlsenc.
>
> - Andreas
>
> [1]: https://ffmpeg.org/pipermail/ffmpeg-devel/2019-December/254420.html
> [2]: https://ffm
Re: [FFmpeg-devel] [PATCH 1/2] avformat/thp: Require a video stream
On Wed, Apr 15, 2020 at 09:18:41PM +0200, Michael Niedermayer wrote: > The demuxer code assumes the existence of a video stream > > Fixes: assertion failure > Fixes: > 21512/clusterfuzz-testcase-minimized-ffmpeg_DEMUXER_fuzzer-5699660783288320 > > Found-by: continuous fuzzing process > https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg > Signed-off-by: Michael Niedermayer > --- > libavformat/thp.c | 3 +++ > 1 file changed, 3 insertions(+) will apply patchset [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB The real ebay dictionary, page 1 "Used only once"- "Some unspecified defect prevented a second use" "In good condition" - "Can be repaird by experienced expert" "As is" - "You wouldnt want it even if you were payed for it, if you knew ..." 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] avformat/mpeg: Decrease score by 1 for files with very little valid data
On Tue, Apr 14, 2020 at 02:15:45AM +0200, Michael Niedermayer wrote: > Fixes: 8233/PPY6574574605_cut.mp3 > > Signed-off-by: Michael Niedermayer > --- > libavformat/mpeg.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) will apply [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB it is not once nor twice but times without number that the same ideas make their appearance in the world. -- Aristotle signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 1/2] avcodec/pngdec: Check length in fdAT
On Tue, Apr 07, 2020 at 10:53:52PM +0200, Michael Niedermayer wrote: > Fixes: > 21089/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_APNG_fuzzer-5135981419429888 > Fixes: out of array read > > Found-by: continuous fuzzing process > https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg > Signed-off-by: Michael Niedermayer > --- > libavcodec/pngdec.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) will apply patchset [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB There will always be a question for which you do not know the correct answer. 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/hapdec: Check tex_size more strictly and before using it
On Sun, Apr 05, 2020 at 11:10:44PM +0200, Michael Niedermayer wrote: > Fixes: OOM > Fixes: > 20774/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_HAP_fuzzer-5678608951803904 > Fixes: > 20956/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_HAP_fuzzer-5713643025203200 > > Found-by: continuous fuzzing process > https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg > Signed-off-by: Michael Niedermayer > --- > libavcodec/hapdec.c | 23 ++- > 1 file changed, 14 insertions(+), 9 deletions(-) will apply patchset [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB The greatest way to live with honor in this world is to be what we pretend to be. -- Socrates 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] avcodec: Add MediaFoundation encoder wrapper
From: wm4 This contains encoder wrappers for H264, HEVC, AAC, AC3 and MP3. This is based on top of an original patch by wm4 . The original patch supported both encoding and decoding, but this patch only includes encoding. The patch contains further changes by Paweł Wegner (primarily for splitting out the encoding parts of the original patch) and further cleanup, build compatibility fixes and tweaks for use with Qualcomm encoders by Martin Storsjö. --- This allows access to the HW video encoder on Windows on ARM64 on Qualcomm platforms. However, to actually use that, one has to manually choose nv12 as input pixel format, otherwise the encoder format negotiation fails. I've tried to read up on the feedback this patch got the earlier times it was posted and address those issues. In particular, this is enabled automatically if suitable headers are available. The built binary still runs on Vista (even if the required MF functionality isn't available there). Building succeeds with MSVC, old and new mingw-w64 toolchains, and isn't detected nor enabled on mingw.org toolchains. The configure check looks for one of the API details used; mingw-w64 versions from before that feature was added won't try to build the code, while newer ones should have enough features to build it successfully. --- configure | 11 + libavcodec/Makefile|1 + libavcodec/allcodecs.c |5 + libavcodec/mf_utils.c | 677 +++ libavcodec/mf_utils.h | 138 + libavcodec/mfenc.c | 1181 libavcodec/version.h |2 +- 7 files changed, 2014 insertions(+), 1 deletion(-) create mode 100644 libavcodec/mf_utils.c create mode 100644 libavcodec/mf_utils.h create mode 100644 libavcodec/mfenc.c diff --git a/configure b/configure index e7162dbc56..a52d1ebed5 100755 --- a/configure +++ b/configure @@ -304,6 +304,7 @@ External library support: --enable-mbedtls enable mbedTLS, needed for https support if openssl, gnutls or libtls is not used [no] --enable-mediacodec enable Android MediaCodec support [no] + --enable-mf enable decoding via MediaFoundation [auto] --enable-libmysofa enable libmysofa, needed for sofalizer filter [no] --enable-openal enable OpenAL 1.1 capture support [no] --enable-opencl enable OpenCL processing [no] @@ -1704,6 +1705,7 @@ EXTERNAL_AUTODETECT_LIBRARY_LIST=" libxcb_shape libxcb_xfixes lzma +mf schannel sdl2 securetransport @@ -3013,6 +3015,8 @@ wmv3_vaapi_hwaccel_select="vc1_vaapi_hwaccel" wmv3_vdpau_hwaccel_select="vc1_vdpau_hwaccel" # hardware-accelerated codecs +mf_deps="mftransform_h MFCreateAlignedMemoryBuffer" +mf_extralibs="-lmfplat -lmfuuid -lole32 -lstrmiids" omx_deps="libdl pthreads" omx_rpi_select="omx" qsv_deps="libmfx" @@ -3037,6 +3041,8 @@ nvenc_deps="ffnvcodec" nvenc_deps_any="libdl LoadLibrary" nvenc_encoder_deps="nvenc" +aac_mf_encoder_deps="mf" +ac3_mf_encoder_deps="mf" h263_v4l2m2m_decoder_deps="v4l2_m2m h263_v4l2_m2m" h263_v4l2m2m_encoder_deps="v4l2_m2m h263_v4l2_m2m" h264_amf_encoder_deps="amf" @@ -3045,6 +3051,7 @@ h264_cuvid_decoder_deps="cuvid" h264_cuvid_decoder_select="h264_mp4toannexb_bsf" h264_mediacodec_decoder_deps="mediacodec" h264_mediacodec_decoder_select="h264_mp4toannexb_bsf h264_parser" +h264_mf_encoder_deps="mf" h264_mmal_decoder_deps="mmal" h264_nvenc_encoder_deps="nvenc" h264_omx_encoder_deps="omx" @@ -3061,6 +3068,7 @@ hevc_cuvid_decoder_deps="cuvid" hevc_cuvid_decoder_select="hevc_mp4toannexb_bsf" hevc_mediacodec_decoder_deps="mediacodec" hevc_mediacodec_decoder_select="hevc_mp4toannexb_bsf hevc_parser" +hevc_mf_encoder_deps="mf" hevc_nvenc_encoder_deps="nvenc" hevc_qsv_decoder_select="hevc_mp4toannexb_bsf qsvdec" hevc_qsv_encoder_select="hevcparse qsvenc" @@ -3077,6 +3085,7 @@ mjpeg_qsv_encoder_deps="libmfx" mjpeg_qsv_encoder_select="qsvenc" mjpeg_vaapi_encoder_deps="VAEncPictureParameterBufferJPEG" mjpeg_vaapi_encoder_select="cbs_jpeg jpegtables vaapi_encode" +mp3_mf_encoder_deps="mf" mpeg1_cuvid_decoder_deps="cuvid" mpeg1_v4l2m2m_decoder_deps="v4l2_m2m mpeg1_v4l2_m2m" mpeg2_crystalhd_decoder_select="crystalhd" @@ -6099,6 +6108,7 @@ check_headers io.h check_headers linux/perf_event.h check_headers libcrystalhd/libcrystalhd_if.h check_headers malloc.h +check_headers mftransform.h check_headers net/udplite.h check_headers poll.h check_headers sys/param.h @@ -6161,6 +6171,7 @@ check_type "windows.h dxva.h" "DXVA_PicParams_VP9" -DWINAPI_FAMILY=WINAPI_FAMILY check_type "windows.h d3d11.h" "ID3D11VideoDecoder" check_type "windows.h d3d11.h" "ID3D11VideoContext" check_type "d3d9.h dxva2api.h" DXVA2_ConfigPictureDecode -D_WIN32_WINNT=0x0602 +check_func_headers mfapi.h MFCreateAlignedMemoryBuffer -lmfplat check_type "vdpau/vdpau.h" "VdpPictureInfoHEVC" check_type "vdpau/vdpau.h" "VdpPictureInfoVP9" diff --git a/libavcodec/
Re: [FFmpeg-devel] [PATCH v4 03/11] libavutil/hwcontext_d3d11va: adding more texture information to the D3D11 hwcontext API
> -Original Message- > From: ffmpeg-devel On Behalf Of > Max Dmitrichenko > Sent: Saturday, May 9, 2020 10:42 PM > To: FFmpeg development discussions and patches de...@ffmpeg.org> > Subject: Re: [FFmpeg-devel] [PATCH v4 03/11] libavutil/hwcontext_d3d11va: > adding more texture information to the D3D11 hwcontext API > > > You can document that wherever you want, but for existing users, > > command lines that have always been working before will stop working > > in a significant number of cases. > > > > > not sure where it goes: if a user uses new version - there are new aspects to > consider Is that so? Whether or not that is acceptable for ffmpeg is not up to me to decide, though. I'm just trying to illustrate the consequences. > > But still, even with your patch: What will happen when DX11 is not > > available? > > > > Will it > > > > 1. fail? > > 2. or will it use D3D9 instead? > > > > > there should be no secrets here - implementation is available, do you see > fallback implementation? Yes, I'm seeing that indeed: Mark Thompson asked: >> > +mfxIMPL impl = MFX_IMPL_AUTO_ANY | MFX_IMPL_VIA_D3D11; >> >> Does that still do the right thing on systems where only D3D9 works? You replied: > yes, it is only a hint for D11 when possible. I would understand 'when possible' in a way that D3D9 would be used 'when not possible'. If that's true, it means, that an ffmpeg user executing a command line cannot be sure whether D3D9 or DX11 will be used. That would mean that the behavior is not deterministic. Regards, softworkz ___ 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 v4 03/11] libavutil/hwcontext_d3d11va: adding more texture information to the D3D11 hwcontext API
On Sat, May 9, 2020 at 5:09 PM Mark Thompson wrote:
> On 08/05/2020 21:26, Hendrik Leppkes wrote:
> > On Fri, May 8, 2020 at 5:51 PM wrote:
> >>
> >> From: Artem Galin
> >>
> >> Added AVD3D11FrameDescriptors array to store array of single textures
> in case if there is no way
> >> to allocate array texture with BindFlags = D3D11_BIND_RENDER_TARGET.
> >>
> >> Signed-off-by: Artem Galin
> >> ---
> >> libavutil/hwcontext_d3d11va.c | 26 --
> >> libavutil/hwcontext_d3d11va.h | 9 +
> >> 2 files changed, 29 insertions(+), 6 deletions(-)
> >>
> >> ...
> >> diff --git a/libavutil/hwcontext_d3d11va.h
> b/libavutil/hwcontext_d3d11va.h
> >> index 9f91e9b1b6..295bdcd90d 100644
> >> --- a/libavutil/hwcontext_d3d11va.h
> >> +++ b/libavutil/hwcontext_d3d11va.h
> >> @@ -164,6 +164,15 @@ typedef struct AVD3D11VAFramesContext {
> >> * This field is ignored/invalid if a user-allocated texture is
> provided.
> >> */
> >> UINT MiscFlags;
> >> +
> >> +/**
> >> + * In case if texture structure member above is not NULL contains
> the same texture
> >> + * pointer for all elements and different indexes into the array
> texture.
> >> + * In case if texture structure member above is NULL, all elements
> contains
> >> + * pointers to separate non-array textures and 0 indexes.
> >> + * This field is ignored/invalid if a user-allocated texture is
> provided.
> >> + */
> >> +AVD3D11FrameDescriptor *texture_infos;
> >> } AVD3D11VAFramesContext;
> >>
> >
> >
> > I'm not really a fan of this. Only supporting array textures was an
> > intentional design decision back when D3D11VA was defined, because it
> > greatly simplified the entire design - and as far as I know the
> > d3d11va decoder, for example, doesnt even support decoding into
> > anything else.
>
> For an decoder, yes, because the set of things to render to can easily be
> constrained.
>
> For an encoder, you want to support more cases then just textures
> generated by a decoder, and ideally that would allow arbitrary textures
> with the right properties so that the encoder is not weirdly gimped
> (compare NVENC, which does accept any texture). The barrier to making that
> work is this horrible texture preregistration requirement where we need to
> be able to find all of the textures which might be used up front, not the
> single/array texture difference. While changing the API here is not fun,
> following the method used for the same problem with D3D9 surfaces seems
> like the simplest way to make it all work nicely.
>
> Possibly I am not understanding something here, though - I don't see what
> this has to do with the setting of D3D11_BIND_RENDER_TARGET (and in
> particular why the code discards the array index if this flag is set).
>
>
D3D11_BIND_RENDER_TARGET are not required for decode/encode but
later filters/VPP:
https://github.com/Intel-Media-SDK/MediaSDK/blob/9890dff6064a7f8fe738899fc0c39b33a2d181b5/samples/sample_common/src/d3d11_allocator.cpp#L461
I am re-checking if this is really a MUST condition by any of the
requirements
regards
Max
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH v4 03/11] libavutil/hwcontext_d3d11va: adding more texture information to the D3D11 hwcontext API
On Sat, May 9, 2020 at 10:32 PM Soft Works wrote: > > -Original Message- > > From: ffmpeg-devel On Behalf Of > > Max Dmitrichenko > > Sent: Saturday, May 9, 2020 10:16 PM > > To: FFmpeg development discussions and patches > de...@ffmpeg.org> > > Subject: Re: [FFmpeg-devel] [PATCH v4 03/11] libavutil/hwcontext_d3d11va: > > adding more texture information to the D3D11 hwcontext API > > > > On Sat, May 9, 2020 at 8:13 PM Soft Works wrote: > > > > > > -Original Message- > > > > From: ffmpeg-devel On Behalf Of > > > > Hendrik Leppkes > > > > > > > > > > > > > > > > Of course there is a choice. Only support the new stuff. Afterall > > > > > we havent supported it at all for years now, so only supporting it > > > > > on newer drivers isn't the end of the world. > > > > > > > > > > > > > To give an example for consistency: > > > > > > > > d3d11va decoding will only ever decode into array-textures. So when > > > > I use d3d11va decoding, and then try to encode with qsvenc, it still > > > > fails on > > > such > > > > systems, right? > > > > And not only that, it'll fail in mysterious ways. > > > > > > > > When I'm decoding with qsvdec and it produces a list of textures, > > > > and > > > the API > > > > user does not handle them, since its a new feature and a API change, > > > it'll > > > > break mysteriously again. > > > > > > Nothing will break when ffmpeg supports non-array textures, neither > > > expected nor mysteriously. > > > > > > > > it is not matter of this patches list, > > can it be discussed in other patch review thread? > > It is very relevant to this patch set, because supporting non-array > textures > or not has a big impact on the number of cases that your patch will break. > > this patch is not offering "non-array textures" support for DX11 and decode/encode. would it be only reasonable to discuss such topic with "non-array textures" patch ? > Making DX11 the default AND not making sure that command lines will > keep working widely (with driver versions as are deployed in the real world > and not just the very latest ones), that are two things that do not > go together very well, IMHO. > > Regards, > softworkz > > > regards Max ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH v4 03/11] libavutil/hwcontext_d3d11va: adding more texture information to the D3D11 hwcontext API
On Sat, May 9, 2020 at 10:26 PM Soft Works wrote: > > -Original Message- > > From: ffmpeg-devel On Behalf Of > > Max Dmitrichenko > > Sent: Saturday, May 9, 2020 10:13 PM > > To: FFmpeg development discussions and patches > de...@ffmpeg.org> > > Subject: Re: [FFmpeg-devel] [PATCH v4 03/11] libavutil/hwcontext_d3d11va: > > adding more texture information to the D3D11 hwcontext API > > > > On Sat, May 9, 2020 at 8:31 PM Soft Works wrote: > > > > > > -Original Message- > > > > From: ffmpeg-devel On Behalf Of > > > > Hendrik Leppkes > > > > Sent: Saturday, May 9, 2020 7:54 PM > > > > To: FFmpeg development discussions and patches > > > de...@ffmpeg.org> > > > > Subject: Re: [FFmpeg-devel] [PATCH v4 03/11] > > libavutil/hwcontext_d3d11va: > > > > adding more texture information to the D3D11 hwcontext API > > > > > > > > On Sat, May 9, 2020 at 7:41 PM Soft Works > > wrote: > > > > > > > > > > > -Original Message- > > > > > > From: ffmpeg-devel On > > Behalf > > > > > > Of Hendrik Leppkes > > > > > > Sent: Saturday, May 9, 2020 9:08 AM > > > > > > To: FFmpeg development discussions and patches > > > > > de...@ffmpeg.org> > > > > > > Subject: Re: [FFmpeg-devel] [PATCH v4 03/11] > > > > libavutil/hwcontext_d3d11va: > > > > > > adding more texture information to the D3D11 hwcontext API > > > > > > > > > > > > > > > > > > > > > > > > > > > I'm not really a fan of this. Only supporting array textures > > > > > > > > was an intentional design decision back when D3D11VA was > > > > > > > > defined, because it greatly simplified the entire design - > > > > > > > > and as far as I know the d3d11va decoder, for example, > > > > > > > > doesnt even support decoding into > > > > > > anything else. > > > > > > > > > > > > > > > > - Hendrik > > > > > > > > > > > > > > It's not like there would be a choice. The Intel MSDK uses an > > > > > > > allocator mechanism and when it asks for a non-array DX11 > > > > > > > texture it has to > > > > > > be given one. > > > > > > > > > > > > > > > > > > > Of course there is a choice. Only support the new stuff. > > > > > > Afterall we havent supported it at all for years now, so only > > > > > > supporting it on newer drivers isn't the end of the world. > > > > > > > > > > It _IS_ the end of the world when at the same time, the default > > > > > will be switched to DX11 because this will automatically create > > > > > many cases where things will fail which have been working > previously. > > > > > > > > > > An automatic fallback is not a good alternative either because > > > > > that would break specific adapter selection by adapter number > > > > > because the numbering is different between D3D9 and DX11. > > > > > > > > > > Assuming that everybody would have the latest driver is not > > > > > matching the situation in the real world. See here for an example: > > > > > https://github.com/softworkz/ffmpeg_dx11/issues/1 > > > > > > > > > > > > > According to your own documentation, even the proposed DX11 version > > > > will still fail on various systems (only bullet point 3 is solved > > > > from the > > > list in issue > > > > 2, leaving 1 and 2) So either you have a fallback, or DX11 should > > > probably just > > > > not be the default at all then. > > > > > > From a perspective of a normal ffmpeg command line user, my position > > > is that DX11 should not be made the default because it will break > > > command lines that have been working before. (in a significant amount > > > of cases) > > > > > > > > This switch is documented and explained with reasons. > > a normal ffmpeg command line user has no association like with headless > HW > > setup and DX11. > > You can document that wherever you want, but for existing users, > command lines that have always been working before will stop working > in a significant number of cases. > > not sure where it goes: if a user uses new version - there are new aspects to consider > > > Even more important, though: The behavior should be deterministic, > > > which means that ffmpeg should not make an automatic decision > > > (consider the device selection by adapter number). > > > > > > > > behavior stays deterministic with option for explicit selection of DX > version. > > also, no drop of DX9 is considered. > > That was primarily a response to Hendrik's thought about automatically > falling back to D3D9. > > But still, even with your patch: What will happen when DX11 is not > available? > > Will it > > 1. fail? > 2. or will it use D3D9 instead? > > there should be no secrets here - implementation is available, do you see fallback implementation? we shouldn't forget that target app that uses FFMPEG can have the own preferences and configuration, with this patch - it is possible to use DX11, unlike before. > In case of 2, it's non-deterministic, and when the user has specified an > adapter number for DX11, it might use the wrong adapter when ffmpeg > uses D3D9 instead (because D3D9 and DX11 are counting adap
Re: [FFmpeg-devel] [PATCH v4 03/11] libavutil/hwcontext_d3d11va: adding more texture information to the D3D11 hwcontext API
> -Original Message- > From: ffmpeg-devel On Behalf Of > Max Dmitrichenko > Sent: Saturday, May 9, 2020 10:16 PM > To: FFmpeg development discussions and patches de...@ffmpeg.org> > Subject: Re: [FFmpeg-devel] [PATCH v4 03/11] libavutil/hwcontext_d3d11va: > adding more texture information to the D3D11 hwcontext API > > On Sat, May 9, 2020 at 8:13 PM Soft Works wrote: > > > > -Original Message- > > > From: ffmpeg-devel On Behalf Of > > > Hendrik Leppkes > > > > > > > > > > > > > Of course there is a choice. Only support the new stuff. Afterall > > > > we havent supported it at all for years now, so only supporting it > > > > on newer drivers isn't the end of the world. > > > > > > > > > > To give an example for consistency: > > > > > > d3d11va decoding will only ever decode into array-textures. So when > > > I use d3d11va decoding, and then try to encode with qsvenc, it still > > > fails on > > such > > > systems, right? > > > And not only that, it'll fail in mysterious ways. > > > > > > When I'm decoding with qsvdec and it produces a list of textures, > > > and > > the API > > > user does not handle them, since its a new feature and a API change, > > it'll > > > break mysteriously again. > > > > Nothing will break when ffmpeg supports non-array textures, neither > > expected nor mysteriously. > > > > > it is not matter of this patches list, > can it be discussed in other patch review thread? It is very relevant to this patch set, because supporting non-array textures or not has a big impact on the number of cases that your patch will break. Making DX11 the default AND not making sure that command lines will keep working widely (with driver versions as are deployed in the real world and not just the very latest ones), that are two things that do not go together very well, IMHO. Regards, softworkz ___ 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 v4 03/11] libavutil/hwcontext_d3d11va: adding more texture information to the D3D11 hwcontext API
> -Original Message- > From: ffmpeg-devel On Behalf Of > Max Dmitrichenko > Sent: Saturday, May 9, 2020 10:13 PM > To: FFmpeg development discussions and patches de...@ffmpeg.org> > Subject: Re: [FFmpeg-devel] [PATCH v4 03/11] libavutil/hwcontext_d3d11va: > adding more texture information to the D3D11 hwcontext API > > On Sat, May 9, 2020 at 8:31 PM Soft Works wrote: > > > > -Original Message- > > > From: ffmpeg-devel On Behalf Of > > > Hendrik Leppkes > > > Sent: Saturday, May 9, 2020 7:54 PM > > > To: FFmpeg development discussions and patches > > de...@ffmpeg.org> > > > Subject: Re: [FFmpeg-devel] [PATCH v4 03/11] > libavutil/hwcontext_d3d11va: > > > adding more texture information to the D3D11 hwcontext API > > > > > > On Sat, May 9, 2020 at 7:41 PM Soft Works > wrote: > > > > > > > > > -Original Message- > > > > > From: ffmpeg-devel On > Behalf > > > > > Of Hendrik Leppkes > > > > > Sent: Saturday, May 9, 2020 9:08 AM > > > > > To: FFmpeg development discussions and patches > > > > de...@ffmpeg.org> > > > > > Subject: Re: [FFmpeg-devel] [PATCH v4 03/11] > > > libavutil/hwcontext_d3d11va: > > > > > adding more texture information to the D3D11 hwcontext API > > > > > > > > > > > > > > > > > > > > > > > I'm not really a fan of this. Only supporting array textures > > > > > > > was an intentional design decision back when D3D11VA was > > > > > > > defined, because it greatly simplified the entire design - > > > > > > > and as far as I know the d3d11va decoder, for example, > > > > > > > doesnt even support decoding into > > > > > anything else. > > > > > > > > > > > > > > - Hendrik > > > > > > > > > > > > It's not like there would be a choice. The Intel MSDK uses an > > > > > > allocator mechanism and when it asks for a non-array DX11 > > > > > > texture it has to > > > > > be given one. > > > > > > > > > > > > > > > > Of course there is a choice. Only support the new stuff. > > > > > Afterall we havent supported it at all for years now, so only > > > > > supporting it on newer drivers isn't the end of the world. > > > > > > > > It _IS_ the end of the world when at the same time, the default > > > > will be switched to DX11 because this will automatically create > > > > many cases where things will fail which have been working previously. > > > > > > > > An automatic fallback is not a good alternative either because > > > > that would break specific adapter selection by adapter number > > > > because the numbering is different between D3D9 and DX11. > > > > > > > > Assuming that everybody would have the latest driver is not > > > > matching the situation in the real world. See here for an example: > > > > https://github.com/softworkz/ffmpeg_dx11/issues/1 > > > > > > > > > > According to your own documentation, even the proposed DX11 version > > > will still fail on various systems (only bullet point 3 is solved > > > from the > > list in issue > > > 2, leaving 1 and 2) So either you have a fallback, or DX11 should > > probably just > > > not be the default at all then. > > > > From a perspective of a normal ffmpeg command line user, my position > > is that DX11 should not be made the default because it will break > > command lines that have been working before. (in a significant amount > > of cases) > > > > > This switch is documented and explained with reasons. > a normal ffmpeg command line user has no association like with headless HW > setup and DX11. You can document that wherever you want, but for existing users, command lines that have always been working before will stop working in a significant number of cases. > > Even more important, though: The behavior should be deterministic, > > which means that ffmpeg should not make an automatic decision > > (consider the device selection by adapter number). > > > > > behavior stays deterministic with option for explicit selection of DX version. > also, no drop of DX9 is considered. That was primarily a response to Hendrik's thought about automatically falling back to D3D9. But still, even with your patch: What will happen when DX11 is not available? Will it 1. fail? 2. or will it use D3D9 instead? In case of 2, it's non-deterministic, and when the user has specified an adapter number for DX11, it might use the wrong adapter when ffmpeg uses D3D9 instead (because D3D9 and DX11 are counting adapters differently) Regards, softworkz ___ 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/mux: Remove unnecessary unreferencing of AVPacket
Since commit c5324d92c5f206dcdc2cf93ae237eaa7c1ad0a40 all custom
interleave_packet() functions always return clean packets (even on
error), so that unreferencing manually can be removed.
Signed-off-by: Andreas Rheinhardt
---
libavformat/mux.c | 5 +
1 file changed, 1 insertion(+), 4 deletions(-)
diff --git a/libavformat/mux.c b/libavformat/mux.c
index f2de73af9b..c17686c0a6 100644
--- a/libavformat/mux.c
+++ b/libavformat/mux.c
@@ -1075,10 +1075,7 @@ int ff_interleaved_peek(AVFormatContext *s, int stream,
static int interleave_packet(AVFormatContext *s, AVPacket *out, AVPacket *in,
int flush)
{
if (s->oformat->interleave_packet) {
-int ret = s->oformat->interleave_packet(s, out, in, flush);
-if (in)
-av_packet_unref(in);
-return ret;
+return s->oformat->interleave_packet(s, out, in, flush);
} else
return ff_interleave_packet_per_dts(s, out, in, flush);
}
--
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 v4 03/11] libavutil/hwcontext_d3d11va: adding more texture information to the D3D11 hwcontext API
On Sat, May 9, 2020 at 8:13 PM Soft Works wrote: > > -Original Message- > > From: ffmpeg-devel On Behalf Of > > Hendrik Leppkes > > > > > > > > > > Of course there is a choice. Only support the new stuff. Afterall we > > > havent supported it at all for years now, so only supporting it on > > > newer drivers isn't the end of the world. > > > > > > > To give an example for consistency: > > > > d3d11va decoding will only ever decode into array-textures. So when I use > > d3d11va decoding, and then try to encode with qsvenc, it still fails on > such > > systems, right? > > And not only that, it'll fail in mysterious ways. > > > > When I'm decoding with qsvdec and it produces a list of textures, and > the API > > user does not handle them, since its a new feature and a API change, > it'll > > break mysteriously again. > > Nothing will break when ffmpeg supports non-array textures, neither > expected > nor mysteriously. > > it is not matter of this patches list, can it be discussed in other patch review thread? > > Adding a confusing alternate way to store textures in the context seems > less > > then ideal, even more so since its not necessary for up-to-date drivers. > Let > > It's not a confusing alternate way; non-array textures are just an > alternate way > that hasn't been implemented in the ffmpeg code so far, that's all. > > If you don't like the way how it's done, here's an alternate way that is > probably > a bit cleaner but also more verbose: > https://github.com/softworkz/ffmpeg_dx11/commit/c09cc37ce7f513717493e060df740aa0e7374257 > > (if you wonder about the disabled locking: it's not required at all - > neither for Intel, > Nvidia or AMD D3D11VA decoders, we could discuss that separately if you > wish) > > Best regards, > softworkz > > ___ > 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". regards Max ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH v4 03/11] libavutil/hwcontext_d3d11va: adding more texture information to the D3D11 hwcontext API
On Sat, May 9, 2020 at 8:31 PM Soft Works wrote:
> > -Original Message-
> > From: ffmpeg-devel On Behalf Of
> > Hendrik Leppkes
> > Sent: Saturday, May 9, 2020 7:54 PM
> > To: FFmpeg development discussions and patches > de...@ffmpeg.org>
> > Subject: Re: [FFmpeg-devel] [PATCH v4 03/11] libavutil/hwcontext_d3d11va:
> > adding more texture information to the D3D11 hwcontext API
> >
> > On Sat, May 9, 2020 at 7:41 PM Soft Works wrote:
> > >
> > > > -Original Message-
> > > > From: ffmpeg-devel On Behalf Of
> > > > Hendrik Leppkes
> > > > Sent: Saturday, May 9, 2020 9:08 AM
> > > > To: FFmpeg development discussions and patches > > > de...@ffmpeg.org>
> > > > Subject: Re: [FFmpeg-devel] [PATCH v4 03/11]
> > libavutil/hwcontext_d3d11va:
> > > > adding more texture information to the D3D11 hwcontext API
> > > >
> > >
> > > > > >
> > > > > > I'm not really a fan of this. Only supporting array textures was
> > > > > > an intentional design decision back when D3D11VA was defined,
> > > > > > because it greatly simplified the entire design - and as far as
> > > > > > I know the d3d11va decoder, for example, doesnt even support
> > > > > > decoding into
> > > > anything else.
> > > > > >
> > > > > > - Hendrik
> > > > >
> > > > > It's not like there would be a choice. The Intel MSDK uses an
> > > > > allocator mechanism and when it asks for a non-array DX11 texture
> > > > > it has to
> > > > be given one.
> > > > >
> > > >
> > > > Of course there is a choice. Only support the new stuff. Afterall we
> > > > havent supported it at all for years now, so only supporting it on
> > > > newer drivers isn't the end of the world.
> > >
> > > It _IS_ the end of the world when at the same time, the default will
> > > be switched to DX11 because this will automatically create many cases
> > > where things will fail which have been working previously.
> > >
> > > An automatic fallback is not a good alternative either because that
> > > would break specific adapter selection by adapter number because the
> > > numbering is different between D3D9 and DX11.
> > >
> > > Assuming that everybody would have the latest driver is not matching
> > > the situation in the real world. See here for an example:
> > > https://github.com/softworkz/ffmpeg_dx11/issues/1
> > >
> >
> > According to your own documentation, even the proposed DX11 version will
> > still fail on various systems (only bullet point 3 is solved from the
> list in issue
> > 2, leaving 1 and 2) So either you have a fallback, or DX11 should
> probably just
> > not be the default at all then.
>
> From a perspective of a normal ffmpeg command line user, my position is
> that DX11 should not be made the default because it will break command
> lines that have been working before. (in a significant amount of cases)
>
>
This switch is documented and explained with reasons.
a normal ffmpeg command line user has no association like with headless HW
setup and DX11.
Even, as stated below, discrete graphics adapters setup will benefit from
default'ing to DX11.
it has to be reasonable decision but not purely focusing on support of
somehow aged HW,
before 6th Gen Intel(R) Core(TM) processor family (Codename Skylake).
> Even more important, though: The behavior should be deterministic, which
> means that ffmpeg should not make an automatic decision (consider the
> device selection by adapter number).
>
>
behavior stays deterministic with option for explicit selection of DX
version.
also, no drop of DX9 is considered.
> Intel discrete graphic adapters are coming this year, so device selection
> will become even more important than before as you will be able to have
> even multiple Intel graphics adapters.
>
> Regarding your question above ("only the 3rd bullet point is addressed"):
> We implemented a comprehensive device detection which gives us detailed
> Information about all hardware devices, their drivers, supported codecs and
> capabilities.
> This allows us to detect Intel adapters having drivers below MSDK version
> 1.21,
> and for those we're using D3D9 only.
>
> But for all other versions (MSDK 1.21 to 1.31), we _want_ to be able to use
> DX11 because it allows using without a connected display and without an
> active user session (e.g. Windows service).
>
>
are there prepared patch to consider?
> So, the impact is two-fold:
> - We would be in the position to choose D3D9, but we "want" to have it
> working on all the other driver versions
> - For a regular user, who cannot easily determine the MSDK version (or
> should
> not be needed to bother doing so), the resulting ffmpeg behavior would
> be failure in a lot of cases
>
> softworkz
>
> ___
> 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".
regards
Max
___
Re: [FFmpeg-devel] [PATCH] avformat/hlsenc: move init file write code block to hls_write_header
Steven Liu:
> Signed-off-by: Steven Liu
> ---
> libavformat/hlsenc.c | 37 -
> 1 file changed, 20 insertions(+), 17 deletions(-)
>
> diff --git a/libavformat/hlsenc.c b/libavformat/hlsenc.c
> index 5695c6cc95..a1eddade7b 100644
> --- a/libavformat/hlsenc.c
> +++ b/libavformat/hlsenc.c
> @@ -2266,6 +2266,26 @@ static int hls_write_header(AVFormatContext *s)
> }
> }
> }
> +if (hls->segment_type == SEGMENT_TYPE_FMP4 &&
> !vs->init_range_length) {
> +int range_length = 0;
> +int byterange_mode = (hls->flags & HLS_SINGLE_FILE) ||
> (hls->max_seg_size > 0);
> +av_write_frame(vs->avf, NULL); /* Flush any buffered data */
> +avio_tell(vs->avf->pb);
> +avio_flush(vs->avf->pb);
> +range_length = avio_close_dyn_buf(vs->avf->pb, &vs->init_buffer);
> +if (range_length <= 0)
> +return AVERROR(EINVAL);
> +avio_write(vs->out, vs->init_buffer, range_length);
> +if (!hls->resend_init_file)
> +av_freep(&vs->init_buffer);
> +vs->init_range_length = range_length;
> +avio_open_dyn_buf(&vs->avf->pb);
> +vs->packets_written = 0;
> +vs->start_pos = range_length;
> +if (!byterange_mode) {
> +hlsenc_io_close(s, &vs->out, vs->base_output_dirname);
> +}
> +}
> }
>
> return ret;
> @@ -2383,23 +2403,6 @@ static int hls_write_packet(AVFormatContext *s,
> AVPacket *pkt)
> new_start_pos = avio_tell(oc->pb);
> vs->size = new_start_pos - vs->start_pos;
> avio_flush(oc->pb);
> -if (hls->segment_type == SEGMENT_TYPE_FMP4) {
> -if (!vs->init_range_length) {
> -range_length = avio_close_dyn_buf(oc->pb, &vs->init_buffer);
> -if (range_length <= 0)
> -return AVERROR(EINVAL);
> -avio_write(vs->out, vs->init_buffer, range_length);
> -if (!hls->resend_init_file)
> -av_freep(&vs->init_buffer);
> -vs->init_range_length = range_length;
> -avio_open_dyn_buf(&oc->pb);
> -vs->packets_written = 0;
> -vs->start_pos = range_length;
> -if (!byterange_mode) {
> -hlsenc_io_close(s, &vs->out, vs->base_output_dirname);
> -}
> -}
> -}
> if (!byterange_mode) {
> if (vs->vtt_avf) {
> hlsenc_io_close(s, &vs->vtt_avf->pb, vs->vtt_avf->url);
>
1. Delaying writing the header was introduced in commit
880b299381de1e66f8248abd6c320c7c490466a2 to fix ticket 6825 (where the
number of channels in the input stream switches). Have you tested
whether your patch breaks said ticket again?
2. You don't need to check for vs->init_range_length being zero when
writing the header as this is automatically fulfilled. (After all, one
calls avformat_write_header() only once.)
3. There is also code in hls_write_trailer() that duplicates the code to
write the init file (should actually have been factored out into a
common function...). It has been added in commit
76b8e42c1f0453215244c45114d5aa302e2add7b to address ticket #7166 and if
you always write the init file in write_header, you should also remove
the code in write_trailer.
4. Commit 880b299381de1e66f8248abd6c320c7c490466a2 also added the
packets_written member; it was initialized to 0 in mp4 mode and to 1 in
non-mp4 mode. Since cff309097a3af4f7f2acb5b5f9fb914ba9ae45c3 this was
set to 1 initially just in order to be reset to 0 a few lines below.
Maybe packets_written should be removed completely? (I made a patch [2]
to remove the currently redundant initializations.)
5. The current way of writing the init header (that you intend to remove
in this commit) has a serious issue: If you have a subtitle and an audio
stream, yet no video stream and if the audio is delayed sufficiently,
then a subtitle packet triggers the output of the mp4 init header. But
subtitles are output directly and not via dynamic buffers and yet the
code presumes that the AVIOContext for output is a dynamic buffer. This
leads to segfaults. (If you remember, this is point 6 in [1].) This
patch seems to fix this; but if you drop this patch because of 1., this
still needs to addressed.
- Andreas
[1]: https://ffmpeg.org/pipermail/ffmpeg-devel/2019-December/254420.html
[2]: https://ffmpeg.org/pipermail/ffmpeg-devel/2020-May/262385.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 6/6] avformat/hlsenc: Simplify setting base_output_dirname
Signed-off-by: Andreas Rheinhardt
---
The usage of fmp4_init_filename_len is weird: It is basically used for
two different purposes: The length of vs->fmp4_init_filename_len and the
length of vs->base_output_dirname (this name is btw misleading because
it is not a dirname at all). And given that it's scope is the whole
function, the second time vs->fmp4_init_filename was allocated it also
contained enough space to contain the whole of vs->m3u8_name.
Furthermore, there seems to be a misconception in the way the
fmp4_init_filename_len is calculated in case of more than one
varstreams: It is incremented by strlen("_%d"), yet the string is not
built by inserting "_%d" into the other string; instead if no %v is
present in the string and if there is more than varstream, then it is
created by inserting "_%d", where %d is replace by the actual index of
the varstream. And this can take more than three bytes. But it is not
dangerous: fmp4_init_filename_len is incremented by strlen("_%d") on
every iteration of the loop.
I also pondered using av_append_path_component() in the case that p is
not NULL below; yet this might swallow a "/" and I don't know if it
would make a difference. (Is it actually allowed to use an absolute path
for hls->fmp4_init_filename? If one does so, said path will still be
treated as relative to the directory of vs->m3u8_name.)
I can also give vs->fmp4_init_filename a similar treatment; yet before
doing so I'd like to know if it is intentional that a "%v" in
hls->fmp4_init_filename only gets replaced if there is more than one
varstream (in other cases a %v also gets replaced when one only has one
varstream).
libavformat/hlsenc.c | 24 +---
1 file changed, 9 insertions(+), 15 deletions(-)
diff --git a/libavformat/hlsenc.c b/libavformat/hlsenc.c
index d80852739e..be54957e9d 100644
--- a/libavformat/hlsenc.c
+++ b/libavformat/hlsenc.c
@@ -2908,24 +2908,18 @@ static int hls_init(AVFormatContext *s)
return ret;
}
-fmp4_init_filename_len = strlen(vs->m3u8_name) +
-strlen(vs->fmp4_init_filename) + 1;
-
-vs->base_output_dirname = av_malloc(fmp4_init_filename_len);
-if (!vs->base_output_dirname)
-return AVERROR(ENOMEM);
-
-av_strlcpy(vs->base_output_dirname, vs->m3u8_name,
- fmp4_init_filename_len);
-p = strrchr(vs->base_output_dirname, '/');
+p = strrchr(vs->m3u8_name, '/');
if (p) {
-*(p + 1) = '\0';
-av_strlcat(vs->base_output_dirname, vs->fmp4_init_filename,
- fmp4_init_filename_len);
+char tmp = *(++p);
+*p = '\0';
+vs->base_output_dirname = av_asprintf("%s%s",
vs->m3u8_name,
+
vs->fmp4_init_filename);
+*p = tmp;
} else {
-av_strlcpy(vs->base_output_dirname, vs->fmp4_init_filename,
- fmp4_init_filename_len);
+vs->base_output_dirname =
av_strdup(vs->fmp4_init_filename);
}
+if (!vs->base_output_dirname)
+return AVERROR(ENOMEM);
}
}
--
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/6] avformat/hlsenc: Remove redundant initializations
For every variantstream vs, vs->packets_written is set to one, only to be set to zero a few lines below. Given that the relevant structure has been zeroed during the allocation, this commit removes both assignments. A redundant initialization for vs->init_range_length has been removed as well a few lines below. Given that the relevant structure has been zeroed during the allocation, this commit removes both assignments. A redundant initialization for vs->init_range_length has been removed as well. Signed-off-by: Andreas Rheinhardt --- libavformat/hlsenc.c | 4 1 file changed, 4 deletions(-) diff --git a/libavformat/hlsenc.c b/libavformat/hlsenc.c index a796c124dd..afb4d2a0c0 100644 --- a/libavformat/hlsenc.c +++ b/libavformat/hlsenc.c @@ -833,7 +833,6 @@ static int hls_mux_init(AVFormatContext *s, VariantStream *vs) av_dict_copy(&st->metadata, vs->streams[i]->metadata, 0); } -vs->packets_written = 1; vs->start_pos = 0; vs->new_start = 1; @@ -848,9 +847,6 @@ static int hls_mux_init(AVFormatContext *s, VariantStream *vs) } } -vs->packets_written = 0; -vs->init_range_length = 0; - if ((ret = avio_open_dyn_buf(&oc->pb)) < 0) 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/6] avformat/hlsenc: Simplify setting basename with av_asprintf()
Signed-off-by: Andreas Rheinhardt
---
libavformat/hlsenc.c | 43 ++-
1 file changed, 14 insertions(+), 29 deletions(-)
diff --git a/libavformat/hlsenc.c b/libavformat/hlsenc.c
index 5517cb4354..d80852739e 100644
--- a/libavformat/hlsenc.c
+++ b/libavformat/hlsenc.c
@@ -2739,15 +2739,21 @@ static int hls_init(AVFormatContext *s)
int i = 0;
int j = 0;
HLSContext *hls = s->priv_data;
-const char *pattern = "%d.ts";
+const char *pattern;
VariantStream *vs = NULL;
-int basename_size = 0;
-const char *pattern_localtime_fmt = get_default_pattern_localtime_fmt(s);
const char *vtt_pattern = hls->flags & HLS_SINGLE_FILE ? ".vtt" : "%d.vtt";
char *p = NULL;
int http_base_proto = ff_is_http_proto(s->url);
int fmp4_init_filename_len = strlen(hls->fmp4_init_filename) + 1;
+if (hls->use_localtime) {
+pattern = get_default_pattern_localtime_fmt(s);
+} else {
+pattern = hls->segment_type == SEGMENT_TYPE_FMP4 ? "%d.m4s" : "%d.ts";
+if (hls->flags & HLS_SINGLE_FILE)
+pattern += 2;
+}
+
hls->has_default_key = 0;
hls->has_video_m3u8 = 0;
ret = update_variant_stream_info(s);
@@ -2792,9 +2798,6 @@ static int hls_init(AVFormatContext *s)
}
}
-if (hls->segment_type == SEGMENT_TYPE_FMP4) {
-pattern = "%d.m4s";
-}
if ((hls->start_sequence_source_type ==
HLS_START_SEQUENCE_AS_SECONDS_SINCE_EPOCH) ||
(hls->start_sequence_source_type ==
HLS_START_SEQUENCE_AS_MICROSECONDS_SINCE_EPOCH) ||
(hls->start_sequence_source_type ==
HLS_START_SEQUENCE_AS_FORMATTED_DATETIME)) {
@@ -2868,34 +2871,16 @@ static int hls_init(AVFormatContext *s)
if (ret < 0)
return ret;
} else {
-if (hls->flags & HLS_SINGLE_FILE) {
-if (hls->segment_type == SEGMENT_TYPE_FMP4) {
-pattern = ".m4s";
-} else {
-pattern = ".ts";
-}
-}
-
-if (hls->use_localtime) {
-basename_size = strlen(vs->m3u8_name) +
strlen(pattern_localtime_fmt) + 1;
-} else {
-basename_size = strlen(vs->m3u8_name) + strlen(pattern) + 1;
-}
+p = strrchr(vs->m3u8_name, '.');
+if (p)
+*p = '\0';
-vs->basename = av_malloc(basename_size);
+vs->basename = av_asprintf("%s%s", vs->m3u8_name, pattern);
if (!vs->basename)
return AVERROR(ENOMEM);
-av_strlcpy(vs->basename, vs->m3u8_name, basename_size);
-
-p = strrchr(vs->basename, '.');
if (p)
-*p = '\0';
-if (hls->use_localtime) {
-av_strlcat(vs->basename, pattern_localtime_fmt, basename_size);
-} else {
-av_strlcat(vs->basename, pattern, basename_size);
-}
+*p = '.';
}
if (hls->segment_type == SEGMENT_TYPE_FMP4) {
--
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 1/6] avformat/hlsenc: Don't reset AVIOContext pointer manually a second time
ff_format_io_close() already does it for us.
Signed-off-by: Andreas Rheinhardt
---
libavformat/hlsenc.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/libavformat/hlsenc.c b/libavformat/hlsenc.c
index 7b289c060f..a796c124dd 100644
--- a/libavformat/hlsenc.c
+++ b/libavformat/hlsenc.c
@@ -2497,7 +2497,6 @@ static int hls_write_packet(AVFormatContext *s, AVPacket
*pkt)
if ((ret = hls_window(s, 0, vs)) < 0) {
av_log(s, AV_LOG_WARNING, "upload playlist failed, will retry
with a new http session.\n");
ff_format_io_close(s, &vs->out);
-vs->out = NULL;
if ((ret = hls_window(s, 0, vs)) < 0) {
av_freep(&old_filename);
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/6] avformat/hlsenc: Don't cast const away
Signed-off-by: Andreas Rheinhardt
---
libavformat/hlsenc.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/libavformat/hlsenc.c b/libavformat/hlsenc.c
index afb4d2a0c0..2a0d17baea 100644
--- a/libavformat/hlsenc.c
+++ b/libavformat/hlsenc.c
@@ -525,10 +525,10 @@ static int hls_delete_old_segments(AVFormatContext *s,
HLSContext *hls,
int ret = 0;
int segment_cnt = 0;
AVBPrint path;
-char *dirname = NULL;
+const char *dirname = NULL;
char *dirname_r = NULL;
char *dirname_repl = NULL;
-char *vtt_dirname = NULL;
+const char *vtt_dirname = NULL;
char *vtt_dirname_r = NULL;
const char *proto = NULL;
@@ -559,7 +559,7 @@ static int hls_delete_old_segments(AVFormatContext *s,
HLSContext *hls,
if (segment && !hls->use_localtime_mkdir) {
dirname_r = hls->segment_filename ? av_strdup(hls->segment_filename):
av_strdup(vs->avf->url);
-dirname = (char*)av_dirname(dirname_r);
+dirname = av_dirname(dirname_r);
}
/* if %v is present in the file's directory
@@ -598,7 +598,7 @@ static int hls_delete_old_segments(AVFormatContext *s,
HLSContext *hls,
if ((segment->sub_filename[0] != '\0')) {
vtt_dirname_r = av_strdup(vs->vtt_avf->url);
-vtt_dirname = (char*)av_dirname(vtt_dirname_r);
+vtt_dirname = av_dirname(vtt_dirname_r);
av_bprint_clear(&path);
av_bprintf(&path, "%s%c%s", vtt_dirname, SEPARATOR,
--
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/6] avformat/hlsenc: Simplify setting subtitle basename with av_asprintf
Signed-off-by: Andreas Rheinhardt
---
This patch is designed not to change the output at all. Yet I wonder if
instead of p = strrchr(vs->m3u8_name, '.') it should not better be p =
strrchr(av_basename(vs->m3u8_name), '.'). Otherwise in a path like
"./hlsstream/master" everything after '.' will be treated as extension
which does not seem to be intended. The same remark also applies to e.g.
the next patch.
libavformat/hlsenc.c | 20
1 file changed, 8 insertions(+), 12 deletions(-)
diff --git a/libavformat/hlsenc.c b/libavformat/hlsenc.c
index 2a0d17baea..5517cb4354 100644
--- a/libavformat/hlsenc.c
+++ b/libavformat/hlsenc.c
@@ -2743,9 +2743,8 @@ static int hls_init(AVFormatContext *s)
VariantStream *vs = NULL;
int basename_size = 0;
const char *pattern_localtime_fmt = get_default_pattern_localtime_fmt(s);
-const char *vtt_pattern = "%d.vtt";
+const char *vtt_pattern = hls->flags & HLS_SINGLE_FILE ? ".vtt" : "%d.vtt";
char *p = NULL;
-int vtt_basename_size = 0;
int http_base_proto = ff_is_http_proto(s->url);
int fmp4_init_filename_len = strlen(hls->fmp4_init_filename) + 1;
@@ -2954,28 +2953,25 @@ static int hls_init(AVFormatContext *s)
if (!vs->vtt_oformat)
return AVERROR_MUXER_NOT_FOUND;
-if (hls->flags & HLS_SINGLE_FILE)
-vtt_pattern = ".vtt";
-vtt_basename_size = strlen(vs->m3u8_name) + strlen(vtt_pattern) +
1;
+p = strrchr(vs->m3u8_name, '.');
+if (p)
+*p = '\0';
-vs->vtt_basename = av_malloc(vtt_basename_size);
+vs->vtt_basename = av_asprintf("%s%s", vs->m3u8_name, vtt_pattern);
if (!vs->vtt_basename)
return AVERROR(ENOMEM);
-av_strlcpy(vs->vtt_basename, vs->m3u8_name, vtt_basename_size);
-p = strrchr(vs->vtt_basename, '.');
-if (p)
-*p = '\0';
if (hls->subtitle_filename) {
ret = format_name(hls->subtitle_filename, &vs->vtt_m3u8_name,
i, vs->varname);
if (ret < 0)
return ret;
} else {
-vs->vtt_m3u8_name = av_asprintf("%s_vtt.m3u8",
vs->vtt_basename);
+vs->vtt_m3u8_name = av_asprintf("%s_vtt.m3u8", vs->m3u8_name);
if (!vs->vtt_m3u8_name)
return AVERROR(ENOMEM);
}
-av_strlcat(vs->vtt_basename, vtt_pattern, vtt_basename_size);
+if (p)
+*p = '.';
}
if (hls->baseurl) {
--
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 v4 03/11] libavutil/hwcontext_d3d11va: adding more texture information to the D3D11 hwcontext API
> -Original Message-
> From: ffmpeg-devel On Behalf Of
> Hendrik Leppkes
> Sent: Saturday, May 9, 2020 7:54 PM
> To: FFmpeg development discussions and patches de...@ffmpeg.org>
> Subject: Re: [FFmpeg-devel] [PATCH v4 03/11] libavutil/hwcontext_d3d11va:
> adding more texture information to the D3D11 hwcontext API
>
> On Sat, May 9, 2020 at 7:41 PM Soft Works wrote:
> >
> > > -Original Message-
> > > From: ffmpeg-devel On Behalf Of
> > > Hendrik Leppkes
> > > Sent: Saturday, May 9, 2020 9:08 AM
> > > To: FFmpeg development discussions and patches > > de...@ffmpeg.org>
> > > Subject: Re: [FFmpeg-devel] [PATCH v4 03/11]
> libavutil/hwcontext_d3d11va:
> > > adding more texture information to the D3D11 hwcontext API
> > >
> >
> > > > >
> > > > > I'm not really a fan of this. Only supporting array textures was
> > > > > an intentional design decision back when D3D11VA was defined,
> > > > > because it greatly simplified the entire design - and as far as
> > > > > I know the d3d11va decoder, for example, doesnt even support
> > > > > decoding into
> > > anything else.
> > > > >
> > > > > - Hendrik
> > > >
> > > > It's not like there would be a choice. The Intel MSDK uses an
> > > > allocator mechanism and when it asks for a non-array DX11 texture
> > > > it has to
> > > be given one.
> > > >
> > >
> > > Of course there is a choice. Only support the new stuff. Afterall we
> > > havent supported it at all for years now, so only supporting it on
> > > newer drivers isn't the end of the world.
> >
> > It _IS_ the end of the world when at the same time, the default will
> > be switched to DX11 because this will automatically create many cases
> > where things will fail which have been working previously.
> >
> > An automatic fallback is not a good alternative either because that
> > would break specific adapter selection by adapter number because the
> > numbering is different between D3D9 and DX11.
> >
> > Assuming that everybody would have the latest driver is not matching
> > the situation in the real world. See here for an example:
> > https://github.com/softworkz/ffmpeg_dx11/issues/1
> >
>
> According to your own documentation, even the proposed DX11 version will
> still fail on various systems (only bullet point 3 is solved from the list in
> issue
> 2, leaving 1 and 2) So either you have a fallback, or DX11 should probably
> just
> not be the default at all then.
From a perspective of a normal ffmpeg command line user, my position is
that DX11 should not be made the default because it will break command
lines that have been working before. (in a significant amount of cases)
Even more important, though: The behavior should be deterministic, which
means that ffmpeg should not make an automatic decision (consider the
device selection by adapter number).
Intel discrete graphic adapters are coming this year, so device selection
will become even more important than before as you will be able to have
even multiple Intel graphics adapters.
Regarding your question above ("only the 3rd bullet point is addressed"):
We implemented a comprehensive device detection which gives us detailed
Information about all hardware devices, their drivers, supported codecs and
capabilities.
This allows us to detect Intel adapters having drivers below MSDK version 1.21,
and for those we're using D3D9 only.
But for all other versions (MSDK 1.21 to 1.31), we _want_ to be able to use
DX11 because it allows using without a connected display and without an
active user session (e.g. Windows service).
So, the impact is two-fold:
- We would be in the position to choose D3D9, but we "want" to have it
working on all the other driver versions
- For a regular user, who cannot easily determine the MSDK version (or should
not be needed to bother doing so), the resulting ffmpeg behavior would
be failure in a lot of cases
softworkz
___
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 v4 03/11] libavutil/hwcontext_d3d11va: adding more texture information to the D3D11 hwcontext API
On Sat, May 9, 2020 at 7:48 PM Hendrik Leppkes wrote: > On Sat, May 9, 2020 at 7:18 PM Max Dmitrichenko > wrote: > > > > On Sat, May 9, 2020 at 3:18 PM Hendrik Leppkes > wrote: > > > > > On Sat, May 9, 2020 at 2:11 PM Max Dmitrichenko > > > wrote: > > > > > > > > Question about array-textures: are there any confirmation that with > any > > > > BindFlags combination it is should be possible to create such > texture? > > > > Most importantly D3D11_BIND_RENDER_TARGET. > > > > > > > > > > More interestingly, is there any evidence that this is in fact not > > > possible? > > > I see no mention of any limitations like that in the D3D11 > documentation. > > > > > > Where does this condition then come from? > > > > > > > > MSFT documentation is not share much details, > > Try following https://pastebin.com/iCPrwUem > > see #if condition for easy check > > > > Did you ever try reducing the number of bind flags? > Flagging it both for decoder and renderer usage at the same time seems > slightly overkill to me, afterall only one of those processes is going > to fill the texture, and you could (and maybe should) use a different > pool if you want renderer target textures, for eg. filtering? > > both flags: D3D11_BIND_DECODER ( output from the decoder API ) and D3D11_BIND_VIDEO_ENCODER (input from the video encoder API) work fine for ArraySize > 1 / array-textures where more complex cases , like with D3D11_BIND_RENDER_TARGET seems to be gap with one texture in AVHWFramesContext, unless we have several AVHWFramesContext, is this a case? regards Max ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH v4 03/11] libavutil/hwcontext_d3d11va: adding more texture information to the D3D11 hwcontext API
> -Original Message- > From: ffmpeg-devel On Behalf Of > Hendrik Leppkes > > > > > > > Of course there is a choice. Only support the new stuff. Afterall we > > havent supported it at all for years now, so only supporting it on > > newer drivers isn't the end of the world. > > > > To give an example for consistency: > > d3d11va decoding will only ever decode into array-textures. So when I use > d3d11va decoding, and then try to encode with qsvenc, it still fails on such > systems, right? > And not only that, it'll fail in mysterious ways. > > When I'm decoding with qsvdec and it produces a list of textures, and the API > user does not handle them, since its a new feature and a API change, it'll > break mysteriously again. Nothing will break when ffmpeg supports non-array textures, neither expected nor mysteriously. > Adding a confusing alternate way to store textures in the context seems less > then ideal, even more so since its not necessary for up-to-date drivers. Let It's not a confusing alternate way; non-array textures are just an alternate way that hasn't been implemented in the ffmpeg code so far, that's all. If you don't like the way how it's done, here's an alternate way that is probably a bit cleaner but also more verbose: https://github.com/softworkz/ffmpeg_dx11/commit/c09cc37ce7f513717493e060df740aa0e7374257 (if you wonder about the disabled locking: it's not required at all - neither for Intel, Nvidia or AMD D3D11VA decoders, we could discuss that separately if you wish) Best regards, softworkz ___ 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 v4 03/11] libavutil/hwcontext_d3d11va: adding more texture information to the D3D11 hwcontext API
On Sat, May 9, 2020 at 7:41 PM Soft Works wrote: > > > -Original Message- > > From: ffmpeg-devel On Behalf Of > > Hendrik Leppkes > > Sent: Saturday, May 9, 2020 9:08 AM > > To: FFmpeg development discussions and patches > de...@ffmpeg.org> > > Subject: Re: [FFmpeg-devel] [PATCH v4 03/11] libavutil/hwcontext_d3d11va: > > adding more texture information to the D3D11 hwcontext API > > > > > > > > > > > I'm not really a fan of this. Only supporting array textures was an > > > > intentional design decision back when D3D11VA was defined, because > > > > it greatly simplified the entire design - and as far as I know the > > > > d3d11va decoder, for example, doesnt even support decoding into > > anything else. > > > > > > > > - Hendrik > > > > > > It's not like there would be a choice. The Intel MSDK uses an > > > allocator mechanism and when it asks for a non-array DX11 texture it has > > > to > > be given one. > > > > > > > Of course there is a choice. Only support the new stuff. Afterall we havent > > supported it at all for years now, so only supporting it on newer drivers > > isn't > > the end of the world. > > It _IS_ the end of the world when at the same time, the default will be > switched to DX11 because this will automatically create many cases > where things will fail which have been working previously. > > An automatic fallback is not a good alternative either because that would > break specific adapter selection by adapter number because the numbering > is different between D3D9 and DX11. > > Assuming that everybody would have the latest driver is not matching the > situation in the real world. See here for an example: > https://github.com/softworkz/ffmpeg_dx11/issues/1 > According to your own documentation, even the proposed DX11 version will still fail on various systems (only bullet point 3 is solved from the list in issue 2, leaving 1 and 2) So either you have a fallback, or DX11 should probably just not be the default at all then. - Hendrik ___ 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 v4 03/11] libavutil/hwcontext_d3d11va: adding more texture information to the D3D11 hwcontext API
On Sat, May 9, 2020 at 7:18 PM Max Dmitrichenko wrote: > > On Sat, May 9, 2020 at 3:18 PM Hendrik Leppkes wrote: > > > On Sat, May 9, 2020 at 2:11 PM Max Dmitrichenko > > wrote: > > > > > > Question about array-textures: are there any confirmation that with any > > > BindFlags combination it is should be possible to create such texture? > > > Most importantly D3D11_BIND_RENDER_TARGET. > > > > > > > More interestingly, is there any evidence that this is in fact not > > possible? > > I see no mention of any limitations like that in the D3D11 documentation. > > > > Where does this condition then come from? > > > > > MSFT documentation is not share much details, > Try following https://pastebin.com/iCPrwUem > see #if condition for easy check > Did you ever try reducing the number of bind flags? Flagging it both for decoder and renderer usage at the same time seems slightly overkill to me, afterall only one of those processes is going to fill the texture, and you could (and maybe should) use a different pool if you want renderer target textures, for eg. filtering? - Hendrik ___ 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 v4 03/11] libavutil/hwcontext_d3d11va: adding more texture information to the D3D11 hwcontext API
> -Original Message- > From: ffmpeg-devel On Behalf Of > Hendrik Leppkes > Sent: Saturday, May 9, 2020 9:08 AM > To: FFmpeg development discussions and patches de...@ffmpeg.org> > Subject: Re: [FFmpeg-devel] [PATCH v4 03/11] libavutil/hwcontext_d3d11va: > adding more texture information to the D3D11 hwcontext API > > > > > > > I'm not really a fan of this. Only supporting array textures was an > > > intentional design decision back when D3D11VA was defined, because > > > it greatly simplified the entire design - and as far as I know the > > > d3d11va decoder, for example, doesnt even support decoding into > anything else. > > > > > > - Hendrik > > > > It's not like there would be a choice. The Intel MSDK uses an > > allocator mechanism and when it asks for a non-array DX11 texture it has to > be given one. > > > > Of course there is a choice. Only support the new stuff. Afterall we havent > supported it at all for years now, so only supporting it on newer drivers > isn't > the end of the world. It _IS_ the end of the world when at the same time, the default will be switched to DX11 because this will automatically create many cases where things will fail which have been working previously. An automatic fallback is not a good alternative either because that would break specific adapter selection by adapter number because the numbering is different between D3D9 and DX11. Assuming that everybody would have the latest driver is not matching the situation in the real world. See here for an example: https://github.com/softworkz/ffmpeg_dx11/issues/1 The (similar) implementation that I have done, is running on fine on thousands of installations for about a year now. With the currently proposed solution, we would be unable to ship the product. Best regards, softworkz ___ 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 v4 03/11] libavutil/hwcontext_d3d11va: adding more texture information to the D3D11 hwcontext API
On Sat, May 9, 2020 at 5:09 PM Mark Thompson wrote:
>
> On 08/05/2020 21:26, Hendrik Leppkes wrote:
> > On Fri, May 8, 2020 at 5:51 PM wrote:
> >>
> >> From: Artem Galin
> >>
> >> Added AVD3D11FrameDescriptors array to store array of single textures in
> >> case if there is no way
> >> to allocate array texture with BindFlags = D3D11_BIND_RENDER_TARGET.
> >>
> >> Signed-off-by: Artem Galin
> >> ---
> >> libavutil/hwcontext_d3d11va.c | 26 --
> >> libavutil/hwcontext_d3d11va.h | 9 +
> >> 2 files changed, 29 insertions(+), 6 deletions(-)
> >>
> >> ...
> >> diff --git a/libavutil/hwcontext_d3d11va.h b/libavutil/hwcontext_d3d11va.h
> >> index 9f91e9b1b6..295bdcd90d 100644
> >> --- a/libavutil/hwcontext_d3d11va.h
> >> +++ b/libavutil/hwcontext_d3d11va.h
> >> @@ -164,6 +164,15 @@ typedef struct AVD3D11VAFramesContext {
> >> * This field is ignored/invalid if a user-allocated texture is
> >> provided.
> >> */
> >> UINT MiscFlags;
> >> +
> >> +/**
> >> + * In case if texture structure member above is not NULL contains the
> >> same texture
> >> + * pointer for all elements and different indexes into the array
> >> texture.
> >> + * In case if texture structure member above is NULL, all elements
> >> contains
> >> + * pointers to separate non-array textures and 0 indexes.
> >> + * This field is ignored/invalid if a user-allocated texture is
> >> provided.
> >> + */
> >> +AVD3D11FrameDescriptor *texture_infos;
> >> } AVD3D11VAFramesContext;
> >>
> >
> >
> > I'm not really a fan of this. Only supporting array textures was an
> > intentional design decision back when D3D11VA was defined, because it
> > greatly simplified the entire design - and as far as I know the
> > d3d11va decoder, for example, doesnt even support decoding into
> > anything else.
>
> For an decoder, yes, because the set of things to render to can easily be
> constrained.
>
> For an encoder, you want to support more cases then just textures generated
> by a decoder, and ideally that would allow arbitrary textures with the right
> properties so that the encoder is not weirdly gimped (compare NVENC, which
> does accept any texture). The barrier to making that work is this horrible
> texture preregistration requirement where we need to be able to find all of
> the textures which might be used up front, not the single/array texture
> difference. While changing the API here is not fun, following the method
> used for the same problem with D3D9 surfaces seems like the simplest way to
> make it all work nicely.
>
If that is the goal, wouldn't it be ideal for an encoder to work just
with a device context, and not require a frame context?
- Hendrik
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH v3] avcodec/v4l2_m2m_dec: Remove redundant packet and fix double free
From: Andriy Gelman
v4l2_receive_frame() uses two packets s->buf_pkt and avpkt. If avpkt
cannot be enqueued, the packet is buffered in s->buf_pkt and enqueued in
the next call. Currently the ownership transfer between the two packets
is not properly handled. A double free occurs if
ff_v4l2_context_enqueue_packet() returns EAGAIN and v4l2_try_start
returns EINVAL.
In fact, having two AVPackets is not needed and everything can be
handled by s->buf_pkt.
This commit removes the local avpkt from v4l2_receive_frame(), meaning
that the ownership transfer doesn't need to be handled and the double
free is fixed.
Signed-off-by: Andriy Gelman
---
Sorry, forgot to squash the commit from v1 so v2 didn't apply. This is correct
version.
Supersedes:
https://patchwork.ffmpeg.org/project/ffmpeg/patch/20200505055454.28683-1-andriy.gel...@gmail.com/
libavcodec/v4l2_m2m_dec.c | 37 +++--
1 file changed, 15 insertions(+), 22 deletions(-)
diff --git a/libavcodec/v4l2_m2m_dec.c b/libavcodec/v4l2_m2m_dec.c
index 3e17e0fcac..b038efed9c 100644
--- a/libavcodec/v4l2_m2m_dec.c
+++ b/libavcodec/v4l2_m2m_dec.c
@@ -138,14 +138,10 @@ static int v4l2_receive_frame(AVCodecContext *avctx,
AVFrame *frame)
V4L2m2mContext *s = ((V4L2m2mPriv*)avctx->priv_data)->context;
V4L2Context *const capture = &s->capture;
V4L2Context *const output = &s->output;
-AVPacket avpkt = {0};
int ret;
-if (s->buf_pkt.size) {
-avpkt = s->buf_pkt;
-memset(&s->buf_pkt, 0, sizeof(AVPacket));
-} else {
-ret = ff_decode_get_packet(avctx, &avpkt);
+if (!s->buf_pkt.size) {
+ret = ff_decode_get_packet(avctx, &s->buf_pkt);
if (ret < 0 && ret != AVERROR_EOF)
return ret;
}
@@ -153,32 +149,29 @@ static int v4l2_receive_frame(AVCodecContext *avctx,
AVFrame *frame)
if (s->draining)
goto dequeue;
-ret = ff_v4l2_context_enqueue_packet(output, &avpkt);
-if (ret < 0) {
-if (ret != AVERROR(EAGAIN))
- return ret;
+ret = ff_v4l2_context_enqueue_packet(output, &s->buf_pkt);
+if (ret < 0 && ret != AVERROR(EAGAIN))
+goto fail;
-s->buf_pkt = avpkt;
-/* no input buffers available, continue dequeing */
-}
+/* if EAGAIN don't unref packet and try to enqueue in the next iteration */
+if (ret != AVERROR(EAGAIN))
+av_packet_unref(&s->buf_pkt);
-if (avpkt.size) {
+if (!s->draining) {
ret = v4l2_try_start(avctx);
if (ret) {
-av_packet_unref(&avpkt);
-
/* cant recover */
-if (ret == AVERROR(ENOMEM))
-return ret;
-
-return 0;
+if (ret != AVERROR(ENOMEM))
+ret = 0;
+goto fail;
}
}
dequeue:
-if (!s->buf_pkt.size)
-av_packet_unref(&avpkt);
return ff_v4l2_context_dequeue_frame(capture, frame, -1);
+fail:
+av_packet_unref(&s->buf_pkt);
+return ret;
}
static av_cold int v4l2_decode_init(AVCodecContext *avctx)
--
2.25.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH v4 03/11] libavutil/hwcontext_d3d11va: adding more texture information to the D3D11 hwcontext API
On Sat, May 9, 2020 at 3:18 PM Hendrik Leppkes wrote: > On Sat, May 9, 2020 at 2:11 PM Max Dmitrichenko > wrote: > > > > Question about array-textures: are there any confirmation that with any > > BindFlags combination it is should be possible to create such texture? > > Most importantly D3D11_BIND_RENDER_TARGET. > > > > More interestingly, is there any evidence that this is in fact not > possible? > I see no mention of any limitations like that in the D3D11 documentation. > > Where does this condition then come from? > > MSFT documentation is not share much details, Try following https://pastebin.com/iCPrwUem see #if condition for easy check regards Max ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
[FFmpeg-devel] [PATCH v2] avcodec/v4l2_m2m_dec: Remove redundant packet and fix double free
From: Andriy Gelman
v4l2_receive_frame() uses two packets s->buf_pkt and avpkt. If avpkt
cannot be enqueued, the packet is buffered in s->buf_pkt and enqueued in
the next call. Currently the ownership transfer between the two packets
is not properly handled. A double free occurs if
ff_v4l2_context_enqueue_packet() returns EAGAIN and v4l2_try_start
returns EINVAL.
In fact, having two AVPackets is not needed and everything can be
handled by s->buf_pkt.
This commit removes the local avpkt from v4l2_receive_frame(), meaning
that the ownership transfer doesn't need to be handled and the double
free is fixed.
Signed-off-by: Andriy Gelman
---
Supersedes
https://patchwork.ffmpeg.org/project/ffmpeg/patch/20200505055454.28683-1-andriy.gel...@gmail.com/
libavcodec/v4l2_m2m_dec.c | 36 +++-
1 file changed, 15 insertions(+), 21 deletions(-)
diff --git a/libavcodec/v4l2_m2m_dec.c b/libavcodec/v4l2_m2m_dec.c
index f1ad1aa2a2..b038efed9c 100644
--- a/libavcodec/v4l2_m2m_dec.c
+++ b/libavcodec/v4l2_m2m_dec.c
@@ -138,13 +138,10 @@ static int v4l2_receive_frame(AVCodecContext *avctx,
AVFrame *frame)
V4L2m2mContext *s = ((V4L2m2mPriv*)avctx->priv_data)->context;
V4L2Context *const capture = &s->capture;
V4L2Context *const output = &s->output;
-AVPacket avpkt = {0};
int ret;
-if (s->buf_pkt.size) {
-av_packet_move_ref(&avpkt, &s->buf_pkt);
-} else {
-ret = ff_decode_get_packet(avctx, &avpkt);
+if (!s->buf_pkt.size) {
+ret = ff_decode_get_packet(avctx, &s->buf_pkt);
if (ret < 0 && ret != AVERROR_EOF)
return ret;
}
@@ -152,32 +149,29 @@ static int v4l2_receive_frame(AVCodecContext *avctx,
AVFrame *frame)
if (s->draining)
goto dequeue;
-ret = ff_v4l2_context_enqueue_packet(output, &avpkt);
-if (ret < 0) {
-if (ret != AVERROR(EAGAIN))
- return ret;
+ret = ff_v4l2_context_enqueue_packet(output, &s->buf_pkt);
+if (ret < 0 && ret != AVERROR(EAGAIN))
+goto fail;
-s->buf_pkt = avpkt;
-/* no input buffers available, continue dequeing */
-}
+/* if EAGAIN don't unref packet and try to enqueue in the next iteration */
+if (ret != AVERROR(EAGAIN))
+av_packet_unref(&s->buf_pkt);
-if (avpkt.size) {
+if (!s->draining) {
ret = v4l2_try_start(avctx);
if (ret) {
-av_packet_unref(&avpkt);
-
/* cant recover */
-if (ret == AVERROR(ENOMEM))
-return ret;
-
-return 0;
+if (ret != AVERROR(ENOMEM))
+ret = 0;
+goto fail;
}
}
dequeue:
-if (!s->buf_pkt.size)
-av_packet_unref(&avpkt);
return ff_v4l2_context_dequeue_frame(capture, frame, -1);
+fail:
+av_packet_unref(&s->buf_pkt);
+return ret;
}
static av_cold int v4l2_decode_init(AVCodecContext *avctx)
--
2.25.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH v4 1/2] libavcodec/libaomenc.c: Support gray input
Sorry, Resolved bug is this: https://bugs.chromium.org/p/aomedia/issues/detail?id=2639 and we no longer need these lines: +rawimg->planes[AOM_PLANE_U] = frame->data[0]; +rawimg->planes[AOM_PLANE_V] = frame->data[0]; +rawimg->stride[AOM_PLANE_U] = frame->linesize[0]; +rawimg->stride[AOM_PLANE_V] = frame->linesize[0]; 2020年5月10日(日) 0:59 Ryo Hirafuji : > Hi. > > https://crbug.com/aomedia/2545 > > This bug is resolved and we no longer need these lines to avoid crash in > libaom. > > > -rawimg->planes[AOM_PLANE_U] = frame->data[1]; > > -rawimg->planes[AOM_PLANE_V] = frame->data[2]; > > -rawimg->stride[AOM_PLANE_U] = frame->linesize[1]; > > -rawimg->stride[AOM_PLANE_V] = frame->linesize[2]; > > I can create and send a new patch without these workaround lines, but of > course, it will crash if the ffmpeg will be built with older versions of > libaom. > How should I resolve this backward compatibility issue? or I don't have to > consider it? > > Please give me some advice. > > > 2020年4月16日(木) 2:58 James Zern : > >> On Wed, Apr 15, 2020 at 8:14 AM James Almer wrote: >> > >> > On 4/14/2020 9:26 PM, James Zern wrote: >> > > On Tue, Apr 14, 2020 at 3:57 AM Ryo Hirafuji < >> ryo.hiraf...@link-u.co.jp> wrote: >> > >> >> > >> Thanks for the review! >> > >> >> > >> This should bump the micro version number in libavcodec/version.h. >> > >> >> > >> >> > >> OK, I will bump up the version when the problem below is solved. >> > >> >> > > >> > > If we want to go for compatibility with different versions of the >> > > library we could move forward with the patch as is, though it would be >> > > simpler to just treat this as a bug fix in libaom. >> > >> > Once a new version of libaom is tagged (Hopefully soon, since it's been >> > almost two years since 1.0.0), we could set it as the minimum >> > requirement and forget about 1.0.0, since that version is by now >> > essentially unusable. >> > >> >> Thanks, that was my hope. I just wasn't sure how long we wanted to >> wait before changing the minimum. You're right though, the only tags >> are old and were more for bitstream compatibility rather than encoder >> functionality. A full release should be coming soon [1] and with more >> regular frequency after that. >> >> [1] https://crbug.com/aomedia/2545 >> ___ >> 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 05/10] avformat/nutenc: Create put_* functions by macro
On Sat, May 09, 2020 at 06:04:13AM +0200, Andreas Rheinhardt wrote: > Michael Niedermayer: > > On Mon, May 04, 2020 at 08:22:45PM +0200, Andreas Rheinhardt wrote: > >> It allows to add analogous functions using e.g. the bytestream API > >> instead of using an AVIOContext. > >> > >> Signed-off-by: Andreas Rheinhardt > >> --- > >> libavformat/nutenc.c | 49 > >> 1 file changed, 27 insertions(+), 22 deletions(-) > > > > It certainly is possible to use macros to make the put functions work > > with 2 unrelated APIs. > > But pretty it is not, why do we need 2 APIs ? > > > This is done in preparation for patch 6/10 [1] that separates the > several variable-length elements that precede the main content (or in > case of the syncpoint structure: that is the complete content). By > putting them in a separate buffer one can eliminate one level of dynamic > buffers. And given that these little buffers are naturally given as > buffers, using the bytestream API seems the easiest and nicest way. > > While one could of course achieve the same by wrapping these little > buffers in an AVIOContext via ffio_init_context(), I don't consider this > pretty. I was hoping that my mildly stupid question would lead to some prettier solution. as that failed, teh patch is ok thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB When you are offended at any man's fault, turn to yourself and study your own failings. Then you will forget your anger. -- Epictetus 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] [PATCH] POWER8 VSX vectorization libswscale/input.c Track ticket 5570
On 25.03.2020 10:55, Pestov Vyacheslav wrote: > On 25.03.2020 1:12, Carl Eugen Hoyos wrote: > >> Am Di., 24. März 2020 um 14:28 Uhr schrieb Pestov Vyacheslav >> : >>> yuy2ToY_c: 10157 >>> yuy2ToY_c_vsx: 2353 >>> >>> yuy2ToUV_c: 4907 >>> yuy2ToUV_c_vsx: 1357 >>> >>> rgb24ToY_c: 21172 >>> rgb24ToY_c_vsx: 9191 >>> >>> rgb24ToUV_c: 33568 >>> rgb24ToUV_c_vsx: 12746 >>> >>> bgr24ToY_c: 20983 >>> bgr24ToY_c_vsx: 9381 >>> >>> bgr24ToUV_c: 34513 >>> bgr24ToUV_c_vsx: 12708 >>> >>> monowhite2Y_c: 5247 >>> monowhite2Y_c_vsx: 2099 >>> >>> monoblack2Y_c: 5584 >>> monoblack2Y_c_vsx: 1993 >>> >>> uyvyToY_c: 10111 >>> uyvyToY_c_vsx: 1780 >>> >>> uyvyToUV_c: 4872 >>> uyvyToUV_c_vsx: 1284 >>> >>> nvXXtoUV_c: 5128 >>> nvXXtoUV_c_vsx: 1456 >>> >>> rgbaToA_c: 9930 >>> rgbaToA_c_vsx: 2599 >>> >>> bswap16Y_c: 10399 >>> bswap16Y_c_vsx: 2451 >>> >>> rgb16_32ToUV_half_c_template: 42350 >>> rgb16_32ToUV_half_c_template_vsx: 18583 >>> >>> bswap16UV_c: 11784 >>> bswap16UV_c_vsx: 2873 >>> >>> planar_rgb_to_y: 24602 >>> planar_rgb_to_y_vsx: 10792 >>> >>> planar_rgb_to_uv: 35601 >>> planar_rgb_to_uv_vsx: 14112 >>> >>> planar_rgb16_to_y: 25686 >>> planar_rgb16_to_y_vsx: 10293 >>> >>> planar_rgb16_to_uv: 36367 >>> planar_rgb16_to_uv_vsx: 13575 >>> >>> yvy2ToUV_c: 4879 >>> yvy2ToUV_c_vsx: 1239 >>> >>> read_ya16be_gray_c: 9591 >>> read_ya16be_gray_c_vsx: 4164 >>> >>> read_ya16be_alpha_c: 9390 >>> read_ya16be_alpha_c_vsx: 1874 >>> >>> read_ya16le_gray_c: 9884 >>> read_ya16le_gray_c_vsx: 4224 >>> >>> read_ya16le_alpha_c: 9403 >>> read_ya16le_alpha_c_vsx: 2026 >>> >>> planar_rgb_to_a: 10262 >>> planar_rgb_to_a_vsx: 9361 >>> >>> planar_rgb16_to_a: 9554 >>> planar_rgb16_to_a_vsx: 9393 >>> >>> read_ayuv64le_Y_c: 10457 >>> read_ayuv64le_Y_c_vsx: 7703 >>> >>> read_ayuv64le_A_c: 9404 >>> read_ayuv64le_A_c_vsx: 2797 >>> >>> read_ayuv64le_UV_c: 9464 >>> read_ayuv64le_UV_c_vsx: 3781 >>> >>> p010LEToY_c: 9546 >>> p010LEToY_c_vsx: 2422 >>> >>> p010LEToUV_c: 6390 >>> p010LEToUV_c_vsx: 2681 >>> >>> p010BEToY_c: 9836 >>> p010BEToY_c_vsx: 2572 >>> >>> p010BEToUV_c: 7022 >>> p010BEToUV_c_vsx: 2660 >>> >>> p016LEToUV_c: 5022 >>> p016LEToUV_c_vsx: 2447 >>> >>> p016BEToUV_c: 5293 >>> p016BEToUV_c_vsx: 2307 >> To make our lives a little easier, could you tell us what you tested >> and how we can reproduce your results? >> >> Also: Is your patch expected to be bit-exact? If yes, do you >> have a script that allows to compare C and vsx code? >> If not, how did you test your code? >> (Or does fate cover these conversions? I wouldn't expect so.) >> >> Thank you, 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". > Hi, yes I am using some scripts(see attached archive): > > 1) Put macros into tested functions in input_vsx.c and input.c (START_TIMER > and STOP_TIMET). > You can take files with macros from my dropbox > https://www.dropbox.com/sh/eoed5pjp9a9psx0/AACpsa6PKGAIl5pYF58sHeRda?dl=0 > > 2) I am generating some random input file with dd utility. For example: > > dd if=/dev/urandom of=/tmp/test.raw bs=1024 count=40900 > > 3) Run script script ffmpeg_bench.sh from directory where created test.raw > > cd /tmp > > bash ./ffmpeg_bench.sh > > 4) Run python3 script print_result.py. This script takes the ffmpeg_bench > results from files bench_cpu.txt and bench_vsx.txt, calculates the average > values and displays in a convenient form > > With best regards, Pestov Vyacheslav > > ___ > 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". Please, check my patch. I have been waiting for its commiting more than a year(Just over a year ago, I too sent out a patch in Devel list). I want to get my bounty from bountysource platform. ___ 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 v4 1/2] libavcodec/libaomenc.c: Support gray input
Hi. https://crbug.com/aomedia/2545 This bug is resolved and we no longer need these lines to avoid crash in libaom. > -rawimg->planes[AOM_PLANE_U] = frame->data[1]; > -rawimg->planes[AOM_PLANE_V] = frame->data[2]; > -rawimg->stride[AOM_PLANE_U] = frame->linesize[1]; > -rawimg->stride[AOM_PLANE_V] = frame->linesize[2]; I can create and send a new patch without these workaround lines, but of course, it will crash if the ffmpeg will be built with older versions of libaom. How should I resolve this backward compatibility issue? or I don't have to consider it? Please give me some advice. 2020年4月16日(木) 2:58 James Zern : > On Wed, Apr 15, 2020 at 8:14 AM James Almer wrote: > > > > On 4/14/2020 9:26 PM, James Zern wrote: > > > On Tue, Apr 14, 2020 at 3:57 AM Ryo Hirafuji < > ryo.hiraf...@link-u.co.jp> wrote: > > >> > > >> Thanks for the review! > > >> > > >> This should bump the micro version number in libavcodec/version.h. > > >> > > >> > > >> OK, I will bump up the version when the problem below is solved. > > >> > > > > > > If we want to go for compatibility with different versions of the > > > library we could move forward with the patch as is, though it would be > > > simpler to just treat this as a bug fix in libaom. > > > > Once a new version of libaom is tagged (Hopefully soon, since it's been > > almost two years since 1.0.0), we could set it as the minimum > > requirement and forget about 1.0.0, since that version is by now > > essentially unusable. > > > > Thanks, that was my hope. I just wasn't sure how long we wanted to > wait before changing the minimum. You're right though, the only tags > are old and were more for bitstream compatibility rather than encoder > functionality. A full release should be coming soon [1] and with more > regular frequency after that. > > [1] https://crbug.com/aomedia/2545 > ___ > 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 v4 03/11] libavutil/hwcontext_d3d11va: adding more texture information to the D3D11 hwcontext API
On 08/05/2020 21:26, Hendrik Leppkes wrote:
> On Fri, May 8, 2020 at 5:51 PM wrote:
>>
>> From: Artem Galin
>>
>> Added AVD3D11FrameDescriptors array to store array of single textures in
>> case if there is no way
>> to allocate array texture with BindFlags = D3D11_BIND_RENDER_TARGET.
>>
>> Signed-off-by: Artem Galin
>> ---
>> libavutil/hwcontext_d3d11va.c | 26 --
>> libavutil/hwcontext_d3d11va.h | 9 +
>> 2 files changed, 29 insertions(+), 6 deletions(-)
>>
>> ...
>> diff --git a/libavutil/hwcontext_d3d11va.h b/libavutil/hwcontext_d3d11va.h
>> index 9f91e9b1b6..295bdcd90d 100644
>> --- a/libavutil/hwcontext_d3d11va.h
>> +++ b/libavutil/hwcontext_d3d11va.h
>> @@ -164,6 +164,15 @@ typedef struct AVD3D11VAFramesContext {
>> * This field is ignored/invalid if a user-allocated texture is
>> provided.
>> */
>> UINT MiscFlags;
>> +
>> +/**
>> + * In case if texture structure member above is not NULL contains the
>> same texture
>> + * pointer for all elements and different indexes into the array
>> texture.
>> + * In case if texture structure member above is NULL, all elements
>> contains
>> + * pointers to separate non-array textures and 0 indexes.
>> + * This field is ignored/invalid if a user-allocated texture is
>> provided.
>> + */
>> +AVD3D11FrameDescriptor *texture_infos;
>> } AVD3D11VAFramesContext;
>>
>
>
> I'm not really a fan of this. Only supporting array textures was an
> intentional design decision back when D3D11VA was defined, because it
> greatly simplified the entire design - and as far as I know the
> d3d11va decoder, for example, doesnt even support decoding into
> anything else.
For an decoder, yes, because the set of things to render to can easily be
constrained.
For an encoder, you want to support more cases then just textures generated by
a decoder, and ideally that would allow arbitrary textures with the right
properties so that the encoder is not weirdly gimped (compare NVENC, which does
accept any texture). The barrier to making that work is this horrible texture
preregistration requirement where we need to be able to find all of the
textures which might be used up front, not the single/array texture difference.
While changing the API here is not fun, following the method used for the same
problem with D3D9 surfaces seems like the simplest way to make it all work
nicely.
Possibly I am not understanding something here, though - I don't see what this
has to do with the setting of D3D11_BIND_RENDER_TARGET (and in particular why
the code discards the array index if this flag is set).
- Mark
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH 10/10] avformat/nutenc: Don't allocate array with zero entries
On Sat, May 09, 2020 at 06:52:35AM +0200, Andreas Rheinhardt wrote: > Michael Niedermayer: > > On Mon, May 04, 2020 at 08:22:50PM +0200, Andreas Rheinhardt wrote: > >> Allocating an array with zero entries is both unnecessary as well as > >> potentially troublesome because the behaviour in this case is not really > >> well defined. > > > > What is not well defined ? > > > The behaviour of our memory-allocation functions in case one requests to > allocate zero bytes is not well-defined (does it return NULL or not?). > E.g. although the documentation of av_mallocz_array() (which applies to > av_calloc, too) treats the size and nmemb parameters symmetrically, the > actual implementation differed until commit > b7d9507bb8c4d1b8bf99158d6859a5b2ecd73298 (up until then, a size of zero > would have resulted in NULL being returned). In the discussion [1] > around this patch there were devs favouring returning NULL upon any > request to allocate zero bytes. The NUT muxer is btw one of the two main > reasons for failing fate-tests in case one returned NULL when an > allocation of zero bytes is requested. > > What happens on allocation of zero bytes is implementation-defined for > the analogous C functions; in our implementation the only function that > explicitly documents what happens when the size fed to it is zero is IMO The intended behavor of the allocation functions was to return NULL on failure only. That way a NULL test can be used for testing for failure without special cases. Also it avoids special cases with NULL pointers with functions which do not allow NULL even for size = 0. I think at minimum a succeeding *malloc(x) should work with *memcpy(x)/*memset(x)/... of the same API. if the later are undefined with NULL so the first should not produce NULL on success. > av_realloc() which does not abide by its documentation (it does not free > anything when size is zero, but rather reallocates the buffer to a size > of one). Thats an interresting bug thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB If the United States is serious about tackling the national security threats related to an insecure 5G network, it needs to rethink the extent to which it values corporate profits and government espionage over security.-Bruce Schneier 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] avdevice/v4l2enc: Allow writing non-rawvideos to v4l2
On 04/05/2020 15:19, Jan Ekström wrote:
> On Sun, Apr 26, 2020 at 11:26 PM David Manouchehri
> wrote:
>>
>> Resubmit of a previous patch, not sure why the diff didn't come through.
>> ___
>>
>> @@ -56,7 +55,13 @@ static av_cold int write_header(AVFormatContext *s1)
>>
>> par = s1->streams[0]->codecpar;
>>
>> -v4l2_pixfmt = ff_fmt_ff2v4l(par->format, AV_CODEC_ID_RAWVIDEO);
>> +if(s1->streams[0]->codecpar->codec_id == AV_CODEC_ID_RAWVIDEO) {
>> +v4l2_pixfmt = ff_fmt_ff2v4l(par->format, AV_CODEC_ID_RAWVIDEO);
>> +}
>> +else {
>> +v4l2_pixfmt = ff_fmt_ff2v4l(AV_PIX_FMT_NONE,
>> s1->streams[0]->codecpar->codec_id);
>> +}
>> +
>
> Hi,
>
> A small nit. Wouldn't the variable `par` be usable there that was just
> created right on top of this if/else structure ? A la `par->codec_id`
> instead of poking at s1->streams[0] again?
>
> Otherwise looks good to me, linked this today on IRC as someone needed
> to test a v4l2 device they were developing with MJPEG. Didn't work,
> but that could be due to our MJPEG encoder adding all the metadata
> headers etc into the bit stream.
Yep, applied with that change.
Thank you!
- Mark
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
Re: [FFmpeg-devel] [PATCH] avformat/oggenc: Avoid allocations and copying when writing page data
Andreas Rheinhardt:
> Andreas Rheinhardt:
>> When the Ogg muxer writes a page, it has to do three things: It needs to
>> write a page header, then it has to actually copy the page data and then
>> it has to calculate and write a CRC checksum of both header as well as
>> data at a certain position in the page header.
>>
>> To do this, the muxer used a dynamic buffer for both writing as well as
>> calculating the checksum via an AVIOContext's feature to automatically
>> calculate checksums on the data it writes. This entails an allocation of
>> an AVIOContext, of the opaque specific to dynamic buffers and of the
>> buffer itself (which may be reallocated multiple times) as well as
>> memcopying the data (first into the AVIOContext's small write buffer,
>> then into the dynamic buffer's big buffer).
>>
>> This commit changes this: The page header is no longer written into a
>> dynamic buffer any more; instead the (small) page header is written into
>> a small buffer on the stack. The CRC is then calculated directly via
>> av_crc() on both the page header as well as the page data. Then both the
>> page header and the page data are written.
>>
>> Finally, ogg_write_page() can now no longer fail, so it has been
>> modified to return nothing; this also fixed a bug in the only caller of
>> this function: It didn't check the return value.
>>
>> Signed-off-by: Andreas Rheinhardt
>> ---
>> libavformat/oggenc.c | 63
>> 1 file changed, 22 insertions(+), 41 deletions(-)
>>
>> diff --git a/libavformat/oggenc.c b/libavformat/oggenc.c
>> index fbd14fedf9..f81907117e 100644
>> --- a/libavformat/oggenc.c
>> +++ b/libavformat/oggenc.c
>> @@ -29,7 +29,6 @@
>> #include "libavcodec/bytestream.h"
>> #include "libavcodec/flac.h"
>> #include "avformat.h"
>> -#include "avio_internal.h"
>> #include "internal.h"
>> #include "vorbiscomment.h"
>>
>> @@ -99,50 +98,32 @@ static const AVClass flavor ## _muxer_class = {\
>> .version= LIBAVUTIL_VERSION_INT,\
>> };
>>
>> -static void ogg_update_checksum(AVFormatContext *s, AVIOContext *pb,
>> int64_t crc_offset)
>> -{
>> -int64_t pos = avio_tell(pb);
>> -uint32_t checksum = ffio_get_checksum(pb);
>> -avio_seek(pb, crc_offset, SEEK_SET);
>> -avio_wb32(pb, checksum);
>> -avio_seek(pb, pos, SEEK_SET);
>> -}
>> -
>> -static int ogg_write_page(AVFormatContext *s, OGGPage *page, int
>> extra_flags)
>> +static void ogg_write_page(AVFormatContext *s, OGGPage *page, int
>> extra_flags)
>> {
>> OGGStreamContext *oggstream = s->streams[page->stream_index]->priv_data;
>> -AVIOContext *pb;
>> -int64_t crc_offset;
>> -int ret, size;
>> -uint8_t *buf;
>> -
>> -ret = avio_open_dyn_buf(&pb);
>> -if (ret < 0)
>> -return ret;
>> -ffio_init_checksum(pb, ff_crc04C11DB7_update, 0);
>> -ffio_wfourcc(pb, "OggS");
>> -avio_w8(pb, 0);
>> -avio_w8(pb, page->flags | extra_flags);
>> -avio_wl64(pb, page->granule);
>> -avio_wl32(pb, oggstream->serial_num);
>> -avio_wl32(pb, oggstream->page_counter++);
>> -crc_offset = avio_tell(pb);
>> -avio_wl32(pb, 0); // crc
>> -avio_w8(pb, page->segments_count);
>> -avio_write(pb, page->segments, page->segments_count);
>> -avio_write(pb, page->data, page->size);
>> -
>> -ogg_update_checksum(s, pb, crc_offset);
>> -
>> -size = avio_close_dyn_buf(pb, &buf);
>> -if (size < 0)
>> -return size;
>> -
>> -avio_write(s->pb, buf, size);
>> +uint8_t buf[4 + 1 + 1 + 8 + 4 + 4 + 4 + 1 + 255], *ptr = buf, *crc_pos;
>> +const AVCRC *crc_table = av_crc_get_table(AV_CRC_32_IEEE);
>> +uint32_t crc;
>> +
>> +bytestream_put_le32(&ptr, MKTAG('O', 'g', 'g', 'S'));
>> +bytestream_put_byte(&ptr, 0);
>> +bytestream_put_byte(&ptr, page->flags | extra_flags);
>> +bytestream_put_le64(&ptr, page->granule);
>> +bytestream_put_le32(&ptr, oggstream->serial_num);
>> +bytestream_put_le32(&ptr, oggstream->page_counter++);
>> +crc_pos = ptr;
>> +bytestream_put_le32(&ptr, 0);
>> +bytestream_put_byte(&ptr, page->segments_count);
>> +bytestream_put_buffer(&ptr, page->segments, page->segments_count);
>> +
>> +crc = av_crc(crc_table, 0, buf, ptr - buf);
>> +crc = av_crc(crc_table, crc, page->data, page->size);
>> +bytestream_put_be32(&crc_pos, crc);
>> +
>> +avio_write(s->pb, buf, ptr - buf);
>> +avio_write(s->pb, page->data, page->size);
>> avio_write_marker(s->pb, AV_NOPTS_VALUE, AVIO_DATA_MARKER_FLUSH_POINT);
>> -av_free(buf);
>> oggstream->page_count--;
>> -return 0;
>> }
>>
>> static int ogg_key_granule(OGGStreamContext *oggstream, int64_t granule)
>>
> Will apply this tomorrow unless there are objections.
>
> - Andreas
>
Applied.
- 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] [PATCH] fate: add adpcm_ima_cunning tests
single: Single-track
track{0,1}: Dual-track
trunc-t1: Truncated track 1
trunc-t2-track{0,1}: Fully-truncated track 2
trunc-t2a-track{0,1}: Partially-truncated track 2
trunc-h2: Truncated track 2 header
Signed-off-by: Zane van Iperen
---
tests/fate/adpcm.mak | 27 +++
tests/ref/fate/adpcm-ima-cunning-single | 1 +
tests/ref/fate/adpcm-ima-cunning-track0 | 1 +
tests/ref/fate/adpcm-ima-cunning-track1 | 1 +
tests/ref/fate/adpcm-ima-cunning-trunc-h2 | 1 +
tests/ref/fate/adpcm-ima-cunning-trunc-t1 | 1 +
.../fate/adpcm-ima-cunning-trunc-t2-track0| 1 +
.../fate/adpcm-ima-cunning-trunc-t2-track1| 1 +
.../fate/adpcm-ima-cunning-trunc-t2a-track0 | 1 +
.../fate/adpcm-ima-cunning-trunc-t2a-track1 | 1 +
10 files changed, 36 insertions(+)
create mode 100644 tests/ref/fate/adpcm-ima-cunning-single
create mode 100644 tests/ref/fate/adpcm-ima-cunning-track0
create mode 100644 tests/ref/fate/adpcm-ima-cunning-track1
create mode 100644 tests/ref/fate/adpcm-ima-cunning-trunc-h2
create mode 100644 tests/ref/fate/adpcm-ima-cunning-trunc-t1
create mode 100644 tests/ref/fate/adpcm-ima-cunning-trunc-t2-track0
create mode 100644 tests/ref/fate/adpcm-ima-cunning-trunc-t2-track1
create mode 100644 tests/ref/fate/adpcm-ima-cunning-trunc-t2a-track0
create mode 100644 tests/ref/fate/adpcm-ima-cunning-trunc-t2a-track1
diff --git a/tests/fate/adpcm.mak b/tests/fate/adpcm.mak
index 3e6d4ecdd1..bc2804477f 100644
--- a/tests/fate/adpcm.mak
+++ b/tests/fate/adpcm.mak
@@ -112,5 +112,32 @@ fate-adpcm-ima-alp-mono: CMD = md5 -i
$(TARGET_SAMPLES)/alp/AD_P11.PCM -f s16le
FATE_ADPCM-$(call DEMDEC, ALP, ADPCM_IMA_ALP) += fate-adpcm-ima-alp-stereo
fate-adpcm-ima-alp-stereo: CMD = md5 -i $(TARGET_SAMPLES)/alp/theme-cut.tun -f
s16le
+FATE_ADPCM-$(call DEMDEC, PP_BNK, ADPCM_IMA_CUNNING) +=
fate-adpcm-ima-cunning-single
+fate-adpcm-ima-cunning-single: CMD = md5 -y -i
$(TARGET_SAMPLES)/pp_bnk/GD-cut.5c -f s16le
+
+FATE_ADPCM-$(call DEMDEC, PP_BNK, ADPCM_IMA_CUNNING) +=
fate-adpcm-ima-cunning-track0
+fate-adpcm-ima-cunning-track0: CMD = md5 -y -i
$(TARGET_SAMPLES)/pp_bnk/VIDEOMOD-cut.11c -map 0:a:0 -f s16le
+
+FATE_ADPCM-$(call DEMDEC, PP_BNK, ADPCM_IMA_CUNNING) +=
fate-adpcm-ima-cunning-track1
+fate-adpcm-ima-cunning-track1: CMD = md5 -y -i
$(TARGET_SAMPLES)/pp_bnk/VIDEOMOD-cut.11c -map 0:a:1 -f s16le
+
+FATE_ADPCM-$(call DEMDEC, PP_BNK, ADPCM_IMA_CUNNING) +=
fate-adpcm-ima-cunning-trunc-t1
+fate-adpcm-ima-cunning-trunc-t1: CMD = md5 -y -i
$(TARGET_SAMPLES)/pp_bnk/VIDEOMOD-trunc-t1.11c -map 0:a:0 -f s16le
+
+FATE_ADPCM-$(call DEMDEC, PP_BNK, ADPCM_IMA_CUNNING) +=
fate-adpcm-ima-cunning-trunc-t2-track0
+fate-adpcm-ima-cunning-trunc-t2-track0: CMD = md5 -y -i
$(TARGET_SAMPLES)/pp_bnk/VIDEOMOD-trunc-t2.11c -map 0:a:0 -f s16le
+
+FATE_ADPCM-$(call DEMDEC, PP_BNK, ADPCM_IMA_CUNNING) +=
fate-adpcm-ima-cunning-trunc-t2-track1
+fate-adpcm-ima-cunning-trunc-t2-track1: CMD = md5 -y -i
$(TARGET_SAMPLES)/pp_bnk/VIDEOMOD-trunc-t2.11c -map 0:a:1 -f s16le
+
+FATE_ADPCM-$(call DEMDEC, PP_BNK, ADPCM_IMA_CUNNING) +=
fate-adpcm-ima-cunning-trunc-t2a-track0
+fate-adpcm-ima-cunning-trunc-t2a-track0: CMD = md5 -y -i
$(TARGET_SAMPLES)/pp_bnk/VIDEOMOD-trunc-t2a.11c -map 0:a:0 -f s16le
+
+FATE_ADPCM-$(call DEMDEC, PP_BNK, ADPCM_IMA_CUNNING) +=
fate-adpcm-ima-cunning-trunc-t2a-track1
+fate-adpcm-ima-cunning-trunc-t2a-track1: CMD = md5 -y -i
$(TARGET_SAMPLES)/pp_bnk/VIDEOMOD-trunc-t2a.11c -map 0:a:1 -f s16le
+
+FATE_ADPCM-$(call DEMDEC, PP_BNK, ADPCM_IMA_CUNNING) +=
fate-adpcm-ima-cunning-trunc-h2
+fate-adpcm-ima-cunning-trunc-h2: CMD = md5 -y -i
$(TARGET_SAMPLES)/pp_bnk/VIDEOMOD-trunc-h2.11c -map 0:a:0 -f s16le
+
FATE_SAMPLES_AVCONV += $(FATE_ADPCM-yes)
fate-adpcm: $(FATE_ADPCM-yes)
diff --git a/tests/ref/fate/adpcm-ima-cunning-single
b/tests/ref/fate/adpcm-ima-cunning-single
new file mode 100644
index 00..49a8308093
--- /dev/null
+++ b/tests/ref/fate/adpcm-ima-cunning-single
@@ -0,0 +1 @@
+dd6ba6151c3e74d09be3c54005465aab
diff --git a/tests/ref/fate/adpcm-ima-cunning-track0
b/tests/ref/fate/adpcm-ima-cunning-track0
new file mode 100644
index 00..bd489cfb45
--- /dev/null
+++ b/tests/ref/fate/adpcm-ima-cunning-track0
@@ -0,0 +1 @@
+fb8db1eef33860c1adde4932e7a250ac
diff --git a/tests/ref/fate/adpcm-ima-cunning-track1
b/tests/ref/fate/adpcm-ima-cunning-track1
new file mode 100644
index 00..f79013c9de
--- /dev/null
+++ b/tests/ref/fate/adpcm-ima-cunning-track1
@@ -0,0 +1 @@
+4b2f9c416ae676526754c82f2a669c91
diff --git a/tests/ref/fate/adpcm-ima-cunning-trunc-h2
b/tests/ref/fate/adpcm-ima-cunning-trunc-h2
new file mode 100644
index 00..bd489cfb45
--- /dev/null
+++ b/tests/ref/fate/adpcm-ima-cunning-trunc-h2
@@ -0,0 +1 @@
+fb8db1eef33860c1adde4932e7a250ac
diff --git a/tests/ref/fate/adpcm-ima-cunning-trunc-t1
b/tests/ref/fate/adpcm-ima-cunning-trunc-t1
new file mode 1006
Re: [FFmpeg-devel] [PATCH v4 03/11] libavutil/hwcontext_d3d11va: adding more texture information to the D3D11 hwcontext API
On Sat, May 9, 2020 at 2:11 PM Max Dmitrichenko wrote: > > Question about array-textures: are there any confirmation that with any > BindFlags combination it is should be possible to create such texture? > Most importantly D3D11_BIND_RENDER_TARGET. > More interestingly, is there any evidence that this is in fact not possible? I see no mention of any limitations like that in the D3D11 documentation. Where does this condition then come from? - Hendrik ___ 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 v4 03/11] libavutil/hwcontext_d3d11va: adding more texture information to the D3D11 hwcontext API
On Sat, May 9, 2020 at 9:18 AM Hendrik Leppkes wrote:
> On Sat, May 9, 2020 at 9:07 AM Hendrik Leppkes
> wrote:
> >
> > On Sat, May 9, 2020 at 2:12 AM Soft Works wrote:
> > >
> > > > From: ffmpeg-devel On Behalf Of
> > > > Hendrik Leppkes
> > > > Sent: Friday, May 8, 2020 10:27 PM
> > > > To: FFmpeg development discussions and patches > > > de...@ffmpeg.org>
> > > > Subject: Re: [FFmpeg-devel] [PATCH v4 03/11]
> libavutil/hwcontext_d3d11va:
> > > > adding more texture information to the D3D11 hwcontext API
> > > >
> > > > On Fri, May 8, 2020 at 5:51 PM wrote:
> > > > >
> > > > > From: Artem Galin
> > > > >
> > > > > Added AVD3D11FrameDescriptors array to store array of single
> textures
> > > > > in case if there is no way to allocate array texture with
> BindFlags =
> > > > D3D11_BIND_RENDER_TARGET.
> > > > >
> > > > > Signed-off-by: Artem Galin
> > > > > ---
> > > > > libavutil/hwcontext_d3d11va.c | 26 --
> > > > > libavutil/hwcontext_d3d11va.h | 9 +
> > > > > 2 files changed, 29 insertions(+), 6 deletions(-)
> > > > >
> > > > > diff --git a/libavutil/hwcontext_d3d11va.c
> > > > > b/libavutil/hwcontext_d3d11va.c index c8ae58f908..cd80931dd3 100644
> > > > > --- a/libavutil/hwcontext_d3d11va.c
> > > > > +++ b/libavutil/hwcontext_d3d11va.c
> > > > > @@ -72,8 +72,8 @@ static av_cold void load_functions(void) }
> > > > >
> > > > > typedef struct D3D11VAFramesContext {
> > > > > -int nb_surfaces_used;
> > > > > -
> > > > > +size_t nb_surfaces;
> > > > > +size_t nb_surfaces_used;
> > > > > DXGI_FORMAT format;
> > > > >
> > > > > ID3D11Texture2D *staging_texture; @@ -112,6 +112,8 @@ static
> void
> > > > > d3d11va_frames_uninit(AVHWFramesContext *ctx)
> > > > > if (s->staging_texture)
> > > > > ID3D11Texture2D_Release(s->staging_texture);
> > > > > s->staging_texture = NULL;
> > > > > +
> > > > > +av_freep(&frames_hwctx->texture_infos);
> > > > > }
> > > > >
> > > > > static int d3d11va_frames_get_constraints(AVHWDeviceContext *ctx,
> @@
> > > > > -152,8 +154,10 @@ static void free_texture(void *opaque, uint8_t
> *data)
> > > > > av_free(data);
> > > > > }
> > > > >
> > > > > -static AVBufferRef *wrap_texture_buf(ID3D11Texture2D *tex, int
> index)
> > > > > +static AVBufferRef *wrap_texture_buf(AVHWFramesContext *ctx,
> > > > > +ID3D11Texture2D *tex, int index)
> > > > > {
> > > > > +D3D11VAFramesContext *s = ctx->internal->priv;
> > > > > +AVD3D11VAFramesContext *frames_hwctx = ctx->hwctx;
> > > > > AVBufferRef *buf;
> > > > > AVD3D11FrameDescriptor *desc = av_mallocz(sizeof(*desc));
> > > > > if (!desc) {
> > > > > @@ -161,6 +165,10 @@ static AVBufferRef
> > > > *wrap_texture_buf(ID3D11Texture2D *tex, int index)
> > > > > return NULL;
> > > > > }
> > > > >
> > > > > +frames_hwctx->texture_infos[s->nb_surfaces_used].texture =
> tex;
> > > > > +frames_hwctx->texture_infos[s->nb_surfaces_used].index =
> index;
> > > > > +s->nb_surfaces_used++;
> > > > > +
> > > > > desc->texture = tex;
> > > > > desc->index = index;
> > > > >
> > > > > @@ -199,7 +207,7 @@ static AVBufferRef
> > > > *d3d11va_alloc_single(AVHWFramesContext *ctx)
> > > > > return NULL;
> > > > > }
> > > > >
> > > > > -return wrap_texture_buf(tex, 0);
> > > > > +return wrap_texture_buf(ctx, tex, 0);
> > > > > }
> > > > >
> > > > > static AVBufferRef *d3d11va_pool_alloc(void *opaque, int size) @@
> > > > > -220,7 +228,7 @@ static AVBufferRef *d3d11va_pool_alloc(void
> *opaque,
> > > > int size)
> > > > > }
> > > > >
> > > > > ID3D11Texture2D_AddRef(hwctx->texture);
> > > > > -return wrap_texture_buf(hwctx->texture,
> s->nb_surfaces_used++);
> > > > > +return wrap_texture_buf(ctx, hwctx->texture,
> > > > > + s->nb_surfaces_used);
> > > > > }
> > > > >
> > > > > static int d3d11va_frames_init(AVHWFramesContext *ctx) @@ -267,7
> > > > > +275,7 @@ static int d3d11va_frames_init(AVHWFramesContext *ctx)
> > > > > av_log(ctx, AV_LOG_ERROR, "User-provided texture has
> > > > mismatching parameters\n");
> > > > > return AVERROR(EINVAL);
> > > > > }
> > > > > -} else if (texDesc.ArraySize > 0) {
> > > > > +} else if (!(texDesc.BindFlags & D3D11_BIND_RENDER_TARGET) &&
> > > > > + texDesc.ArraySize > 0) {
> > > > > hr = ID3D11Device_CreateTexture2D(device_hwctx->device,
> > > > &texDesc, NULL, &hwctx->texture);
> > > > > if (FAILED(hr)) {
> > > > > av_log(ctx, AV_LOG_ERROR, "Could not create the
> texture
> > > > > (%lx)\n", (long)hr); @@ -275,6 +283,12 @@ static int
> > > > d3d11va_frames_init(AVHWFramesContext *ctx)
> > > > > }
> > > > > }
> > > > >
> > > > > +hwctx->texture_infos =
> av_mallocz_array(ctx->initial_pool_size,
> > > > sizeof(*hwctx->texture_infos));
> > > > > +if (!hwctx->texture_infos)
> > > > > +return AVERROR(ENOMEM);
> > > >
[FFmpeg-devel] [PATCH 2/3] libavdevice: Update to new iterating API
Signed-off-by: Zhao, Gang
---
libavdevice/avdevice.c | 31 ---
1 file changed, 24 insertions(+), 7 deletions(-)
diff --git libavdevice/avdevice.c libavdevice/avdevice.c
index 3d03d89f04..8c1b296d71 100644
--- libavdevice/avdevice.c
+++ libavdevice/avdevice.c
@@ -83,16 +83,33 @@ static void *device_next(void *prev, int output,
{
const AVClass *pc;
AVClassCategory category = AV_CLASS_CATEGORY_NA;
+void *opaque = NULL;
+void *orig_prev = prev;
+int found_prev = 0;
+
do {
-if (output) {
-if (!(prev = av_oformat_next(prev)))
-break;
+if (output)
+prev = (void *)av_muxer_iterate(&opaque);
+else
+prev = (void *)av_demuxer_iterate(&opaque);
+
+if (!prev)
+break;
+
+/* if orig_prev is NULL, start from the first muxer/demuxer */
+orig_prev = orig_prev ? orig_prev : prev;
+
+if (!found_prev) {
+if (orig_prev == prev)
+found_prev = 1;
+continue;
+}
+
+if (output)
pc = ((AVOutputFormat *)prev)->priv_class;
-} else {
-if (!(prev = av_iformat_next(prev)))
-break;
+else
pc = ((AVInputFormat *)prev)->priv_class;
-}
+
if (!pc)
continue;
category = pc->category;
--
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] [PATCH v2 4/4] avcodec/encode: avcodec/frame_thread_encoder: Fixed a compile warning
Disable deprecation declarations compile warning when we really need
to call these deprecated functions.
Signed-off-by: Zhao, Gang
---
Changes from v1:
Removed unnecessary #if check
libavcodec/encode.c | 2 ++
libavcodec/frame_thread_encoder.c | 2 ++
2 files changed, 4 insertions(+)
diff --git libavcodec/encode.c libavcodec/encode.c
index 9ed2cf0f59..59f1254d61 100644
--- libavcodec/encode.c
+++ libavcodec/encode.c
@@ -368,11 +368,13 @@ static int do_encode(AVCodecContext *avctx, const AVFrame
*frame, int *got_packe
avctx->internal->buffer_pkt_valid = 0;
if (avctx->codec_type == AVMEDIA_TYPE_VIDEO) {
+FF_DISABLE_DEPRECATION_WARNINGS
ret = avcodec_encode_video2(avctx, avctx->internal->buffer_pkt,
frame, got_packet);
} else if (avctx->codec_type == AVMEDIA_TYPE_AUDIO) {
ret = avcodec_encode_audio2(avctx, avctx->internal->buffer_pkt,
frame, got_packet);
+FF_ENABLE_DEPRECATION_WARNINGS
} else {
ret = AVERROR(EINVAL);
}
diff --git libavcodec/frame_thread_encoder.c libavcodec/frame_thread_encoder.c
index 949bc69f81..87e3b470e5 100644
--- libavcodec/frame_thread_encoder.c
+++ libavcodec/frame_thread_encoder.c
@@ -86,7 +86,9 @@ static void * attribute_align_arg worker(void *v){
pthread_mutex_unlock(&c->task_fifo_mutex);
frame = task.indata;
+FF_DISABLE_DEPRECATION_WARNINGS
ret = avcodec_encode_video2(avctx, pkt, frame, &got_packet);
+FF_ENABLE_DEPRECATION_WARNINGS
pthread_mutex_lock(&c->buffer_mutex);
av_frame_unref(frame);
pthread_mutex_unlock(&c->buffer_mutex);
--
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] [PATCH 1/3] avformat: Correctly check the list before accessing
Signed-off-by: Zhao, Gang
---
libavformat/allformats.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git libavformat/allformats.c libavformat/allformats.c
index 3919c9e4c1..47cf885699 100644
--- libavformat/allformats.c
+++ libavformat/allformats.c
@@ -520,7 +520,7 @@ const AVOutputFormat *av_muxer_iterate(void **opaque)
if (i < size) {
f = muxer_list[i];
-} else if (indev_list) {
+} else if (outdev_list) {
f = outdev_list[i - size];
}
@@ -537,7 +537,7 @@ const AVInputFormat *av_demuxer_iterate(void **opaque)
if (i < size) {
f = demuxer_list[i];
-} else if (outdev_list) {
+} else if (indev_list) {
f = indev_list[i - size];
}
--
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] [PATCH 3/3] avformat/options: Update to new iterating API
Signed-off-by: Zhao, Gang
---
libavformat/options.c | 14 --
1 file changed, 8 insertions(+), 6 deletions(-)
diff --git libavformat/options.c libavformat/options.c
index e14510504f..cec6ee3621 100644
--- libavformat/options.c
+++ libavformat/options.c
@@ -55,26 +55,28 @@ static void *format_child_next(void *obj, void *prev)
static const AVClass *format_child_class_next(const AVClass *prev)
{
-AVInputFormat *ifmt = NULL;
-AVOutputFormat *ofmt = NULL;
+const AVInputFormat *ifmt;
+const AVOutputFormat *ofmt;
+void *demuxer_opaque = NULL;
+void *muxer_opaque = NULL;
if (!prev)
return &ff_avio_class;
-while ((ifmt = av_iformat_next(ifmt)))
+while ((ifmt = av_demuxer_iterate(&demuxer_opaque)))
if (ifmt->priv_class == prev)
break;
if (!ifmt)
-while ((ofmt = av_oformat_next(ofmt)))
+while ((ofmt = av_muxer_iterate(&muxer_opaque)))
if (ofmt->priv_class == prev)
break;
if (!ofmt)
-while (ifmt = av_iformat_next(ifmt))
+while (ifmt = av_demuxer_iterate(&demuxer_opaque))
if (ifmt->priv_class)
return ifmt->priv_class;
-while (ofmt = av_oformat_next(ofmt))
+while (ofmt = av_muxer_iterate(&muxer_opaque))
if (ofmt->priv_class)
return ofmt->priv_class;
--
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] avcodec/mediacodec_common: use MediaFormat to probe frame color characteristics
On Tue, Mar 31, 2020 at 10:03:08AM +0200, Matthieu Bouron wrote:
> ---
> libavcodec/mediacodecdec_common.c | 100 ++
> 1 file changed, 100 insertions(+)
>
> diff --git a/libavcodec/mediacodecdec_common.c
> b/libavcodec/mediacodecdec_common.c
> index f0752fa6261..404ed282275 100644
> --- a/libavcodec/mediacodecdec_common.c
> +++ b/libavcodec/mediacodecdec_common.c
> @@ -85,6 +85,85 @@
> #define OUTPUT_DEQUEUE_TIMEOUT_US 8000
> #define OUTPUT_DEQUEUE_BLOCK_TIMEOUT_US 100
>
> +enum {
> +COLOR_RANGE_FULL= 0x1,
> +COLOR_RANGE_LIMITED = 0x2,
> +};
> +
> +static enum AVColorRange mcdec_get_color_range(int color_range)
> +{
> +switch (color_range) {
> +case COLOR_RANGE_FULL:
> +return AVCOL_RANGE_JPEG;
> +case COLOR_RANGE_LIMITED:
> +return AVCOL_RANGE_MPEG;
> +default:
> +return AVCOL_RANGE_UNSPECIFIED;
> +}
> +}
> +
> +enum {
> +COLOR_STANDARD_BT709 = 0x1,
> +COLOR_STANDARD_BT601_PAL = 0x2,
> +COLOR_STANDARD_BT601_NTSC = 0x4,
> +COLOR_STANDARD_BT2020 = 0x6,
> +};
> +
> +static enum AVColorSpace mcdec_get_color_space(int color_standard)
> +{
> +switch (color_standard) {
> +case COLOR_STANDARD_BT709:
> +return AVCOL_SPC_BT709;
> +case COLOR_STANDARD_BT601_PAL:
> +return AVCOL_SPC_BT470BG;
> +case COLOR_STANDARD_BT601_NTSC:
> +return AVCOL_SPC_SMPTE170M;
> +case COLOR_STANDARD_BT2020:
> +return AVCOL_SPC_BT2020_NCL;
> +default:
> +return AVCOL_SPC_UNSPECIFIED;
> +}
> +}
> +
> +static enum AVColorPrimaries mcdec_get_color_pri(int color_standard)
> +{
> +switch (color_standard) {
> +case COLOR_STANDARD_BT709:
> +return AVCOL_PRI_BT709;
> +case COLOR_STANDARD_BT601_PAL:
> +return AVCOL_PRI_BT470BG;
> +case COLOR_STANDARD_BT601_NTSC:
> +return AVCOL_PRI_SMPTE170M;
> +case COLOR_STANDARD_BT2020:
> +return AVCOL_PRI_BT2020;
> +default:
> +return AVCOL_PRI_UNSPECIFIED;
> +}
> +}
> +
> +enum {
> +COLOR_TRANSFER_LINEAR= 0x1,
> +COLOR_TRANSFER_SDR_VIDEO = 0x3,
> +COLOR_TRANSFER_ST2084= 0x6,
> +COLOR_TRANSFER_HLG = 0x7,
> +};
> +
> +static enum AVColorTransferCharacteristic mcdec_get_color_trc(int
> color_transfer)
> +{
> +switch (color_transfer) {
> +case COLOR_TRANSFER_LINEAR:
> +return AVCOL_TRC_LINEAR;
> +case COLOR_TRANSFER_SDR_VIDEO:
> +return AVCOL_TRC_SMPTE170M;
> +case COLOR_TRANSFER_ST2084:
> +return AVCOL_TRC_SMPTEST2084;
> +case COLOR_TRANSFER_HLG:
> +return AVCOL_TRC_ARIB_STD_B67;
> +default:
> +return AVCOL_TRC_UNSPECIFIED;
> +}
> +}
> +
> enum {
> COLOR_FormatYUV420Planar = 0x13,
> COLOR_FormatYUV420SemiPlanar = 0x15,
> @@ -220,6 +299,10 @@ FF_DISABLE_DEPRECATION_WARNINGS
> FF_ENABLE_DEPRECATION_WARNINGS
> #endif
> frame->pkt_dts = AV_NOPTS_VALUE;
> +frame->color_range = avctx->color_range;
> +frame->color_primaries = avctx->color_primaries;
> +frame->color_trc = avctx->color_trc;
> +frame->colorspace = avctx->colorspace;
>
> buffer = av_mallocz(sizeof(AVMediaCodecBuffer));
> if (!buffer) {
> @@ -368,6 +451,9 @@ static int mediacodec_dec_parse_format(AVCodecContext
> *avctx, MediaCodecDecConte
> int ret = 0;
> int width = 0;
> int height = 0;
> +int color_range = 0;
> +int color_standard = 0;
> +int color_transfer = 0;
> char *format = NULL;
>
> if (!s->format) {
> @@ -426,6 +512,20 @@ static int mediacodec_dec_parse_format(AVCodecContext
> *avctx, MediaCodecDecConte
> ff_set_sar(avctx, sar);
> }
>
> +AMEDIAFORMAT_GET_INT32(color_range, "color-range", 0);
> +if (color_range)
> +avctx->color_range = mcdec_get_color_range(color_range);
> +
> +AMEDIAFORMAT_GET_INT32(color_standard, "color-standard", 0);
> +if (color_standard) {
> +avctx->colorspace = mcdec_get_color_space(color_standard);
> +avctx->color_primaries = mcdec_get_color_pri(color_standard);
> +}
> +
> +AMEDIAFORMAT_GET_INT32(color_transfer, "color-transfer", 0);
> +if (color_transfer)
> +avctx->color_trc = mcdec_get_color_trc(color_transfer);
> +
> av_log(avctx, AV_LOG_INFO,
> "Output crop parameters top=%d bottom=%d left=%d right=%d, "
> "resulting dimensions width=%d height=%d\n",
> --
> 2.26.0
>
Ping.
--
Matthieu 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 v4 03/11] libavutil/hwcontext_d3d11va: adding more texture information to the D3D11 hwcontext API
On Sat, May 9, 2020 at 9:07 AM Hendrik Leppkes wrote:
>
> On Sat, May 9, 2020 at 2:12 AM Soft Works wrote:
> >
> > > From: ffmpeg-devel On Behalf Of
> > > Hendrik Leppkes
> > > Sent: Friday, May 8, 2020 10:27 PM
> > > To: FFmpeg development discussions and patches > > de...@ffmpeg.org>
> > > Subject: Re: [FFmpeg-devel] [PATCH v4 03/11] libavutil/hwcontext_d3d11va:
> > > adding more texture information to the D3D11 hwcontext API
> > >
> > > On Fri, May 8, 2020 at 5:51 PM wrote:
> > > >
> > > > From: Artem Galin
> > > >
> > > > Added AVD3D11FrameDescriptors array to store array of single textures
> > > > in case if there is no way to allocate array texture with BindFlags =
> > > D3D11_BIND_RENDER_TARGET.
> > > >
> > > > Signed-off-by: Artem Galin
> > > > ---
> > > > libavutil/hwcontext_d3d11va.c | 26 --
> > > > libavutil/hwcontext_d3d11va.h | 9 +
> > > > 2 files changed, 29 insertions(+), 6 deletions(-)
> > > >
> > > > diff --git a/libavutil/hwcontext_d3d11va.c
> > > > b/libavutil/hwcontext_d3d11va.c index c8ae58f908..cd80931dd3 100644
> > > > --- a/libavutil/hwcontext_d3d11va.c
> > > > +++ b/libavutil/hwcontext_d3d11va.c
> > > > @@ -72,8 +72,8 @@ static av_cold void load_functions(void) }
> > > >
> > > > typedef struct D3D11VAFramesContext {
> > > > -int nb_surfaces_used;
> > > > -
> > > > +size_t nb_surfaces;
> > > > +size_t nb_surfaces_used;
> > > > DXGI_FORMAT format;
> > > >
> > > > ID3D11Texture2D *staging_texture; @@ -112,6 +112,8 @@ static void
> > > > d3d11va_frames_uninit(AVHWFramesContext *ctx)
> > > > if (s->staging_texture)
> > > > ID3D11Texture2D_Release(s->staging_texture);
> > > > s->staging_texture = NULL;
> > > > +
> > > > +av_freep(&frames_hwctx->texture_infos);
> > > > }
> > > >
> > > > static int d3d11va_frames_get_constraints(AVHWDeviceContext *ctx, @@
> > > > -152,8 +154,10 @@ static void free_texture(void *opaque, uint8_t *data)
> > > > av_free(data);
> > > > }
> > > >
> > > > -static AVBufferRef *wrap_texture_buf(ID3D11Texture2D *tex, int index)
> > > > +static AVBufferRef *wrap_texture_buf(AVHWFramesContext *ctx,
> > > > +ID3D11Texture2D *tex, int index)
> > > > {
> > > > +D3D11VAFramesContext *s = ctx->internal->priv;
> > > > +AVD3D11VAFramesContext *frames_hwctx = ctx->hwctx;
> > > > AVBufferRef *buf;
> > > > AVD3D11FrameDescriptor *desc = av_mallocz(sizeof(*desc));
> > > > if (!desc) {
> > > > @@ -161,6 +165,10 @@ static AVBufferRef
> > > *wrap_texture_buf(ID3D11Texture2D *tex, int index)
> > > > return NULL;
> > > > }
> > > >
> > > > +frames_hwctx->texture_infos[s->nb_surfaces_used].texture = tex;
> > > > +frames_hwctx->texture_infos[s->nb_surfaces_used].index = index;
> > > > +s->nb_surfaces_used++;
> > > > +
> > > > desc->texture = tex;
> > > > desc->index = index;
> > > >
> > > > @@ -199,7 +207,7 @@ static AVBufferRef
> > > *d3d11va_alloc_single(AVHWFramesContext *ctx)
> > > > return NULL;
> > > > }
> > > >
> > > > -return wrap_texture_buf(tex, 0);
> > > > +return wrap_texture_buf(ctx, tex, 0);
> > > > }
> > > >
> > > > static AVBufferRef *d3d11va_pool_alloc(void *opaque, int size) @@
> > > > -220,7 +228,7 @@ static AVBufferRef *d3d11va_pool_alloc(void *opaque,
> > > int size)
> > > > }
> > > >
> > > > ID3D11Texture2D_AddRef(hwctx->texture);
> > > > -return wrap_texture_buf(hwctx->texture, s->nb_surfaces_used++);
> > > > +return wrap_texture_buf(ctx, hwctx->texture,
> > > > + s->nb_surfaces_used);
> > > > }
> > > >
> > > > static int d3d11va_frames_init(AVHWFramesContext *ctx) @@ -267,7
> > > > +275,7 @@ static int d3d11va_frames_init(AVHWFramesContext *ctx)
> > > > av_log(ctx, AV_LOG_ERROR, "User-provided texture has
> > > mismatching parameters\n");
> > > > return AVERROR(EINVAL);
> > > > }
> > > > -} else if (texDesc.ArraySize > 0) {
> > > > +} else if (!(texDesc.BindFlags & D3D11_BIND_RENDER_TARGET) &&
> > > > + texDesc.ArraySize > 0) {
> > > > hr = ID3D11Device_CreateTexture2D(device_hwctx->device,
> > > &texDesc, NULL, &hwctx->texture);
> > > > if (FAILED(hr)) {
> > > > av_log(ctx, AV_LOG_ERROR, "Could not create the texture
> > > > (%lx)\n", (long)hr); @@ -275,6 +283,12 @@ static int
> > > d3d11va_frames_init(AVHWFramesContext *ctx)
> > > > }
> > > > }
> > > >
> > > > +hwctx->texture_infos = av_mallocz_array(ctx->initial_pool_size,
> > > sizeof(*hwctx->texture_infos));
> > > > +if (!hwctx->texture_infos)
> > > > +return AVERROR(ENOMEM);
> > > > +
> > > > +s->nb_surfaces = ctx->initial_pool_size;
> > > > +
> > > > ctx->internal->pool_internal =
> > > av_buffer_pool_init2(sizeof(AVD3D11FrameDescriptor),
> > > > ctx,
> > > > d3d11va_pool_alloc, NULL);
> > > > if (!ctx->internal->pool_int
Re: [FFmpeg-devel] [PATCH v4 03/11] libavutil/hwcontext_d3d11va: adding more texture information to the D3D11 hwcontext API
On Sat, May 9, 2020 at 2:12 AM Soft Works wrote:
>
> > From: ffmpeg-devel On Behalf Of
> > Hendrik Leppkes
> > Sent: Friday, May 8, 2020 10:27 PM
> > To: FFmpeg development discussions and patches > de...@ffmpeg.org>
> > Subject: Re: [FFmpeg-devel] [PATCH v4 03/11] libavutil/hwcontext_d3d11va:
> > adding more texture information to the D3D11 hwcontext API
> >
> > On Fri, May 8, 2020 at 5:51 PM wrote:
> > >
> > > From: Artem Galin
> > >
> > > Added AVD3D11FrameDescriptors array to store array of single textures
> > > in case if there is no way to allocate array texture with BindFlags =
> > D3D11_BIND_RENDER_TARGET.
> > >
> > > Signed-off-by: Artem Galin
> > > ---
> > > libavutil/hwcontext_d3d11va.c | 26 --
> > > libavutil/hwcontext_d3d11va.h | 9 +
> > > 2 files changed, 29 insertions(+), 6 deletions(-)
> > >
> > > diff --git a/libavutil/hwcontext_d3d11va.c
> > > b/libavutil/hwcontext_d3d11va.c index c8ae58f908..cd80931dd3 100644
> > > --- a/libavutil/hwcontext_d3d11va.c
> > > +++ b/libavutil/hwcontext_d3d11va.c
> > > @@ -72,8 +72,8 @@ static av_cold void load_functions(void) }
> > >
> > > typedef struct D3D11VAFramesContext {
> > > -int nb_surfaces_used;
> > > -
> > > +size_t nb_surfaces;
> > > +size_t nb_surfaces_used;
> > > DXGI_FORMAT format;
> > >
> > > ID3D11Texture2D *staging_texture; @@ -112,6 +112,8 @@ static void
> > > d3d11va_frames_uninit(AVHWFramesContext *ctx)
> > > if (s->staging_texture)
> > > ID3D11Texture2D_Release(s->staging_texture);
> > > s->staging_texture = NULL;
> > > +
> > > +av_freep(&frames_hwctx->texture_infos);
> > > }
> > >
> > > static int d3d11va_frames_get_constraints(AVHWDeviceContext *ctx, @@
> > > -152,8 +154,10 @@ static void free_texture(void *opaque, uint8_t *data)
> > > av_free(data);
> > > }
> > >
> > > -static AVBufferRef *wrap_texture_buf(ID3D11Texture2D *tex, int index)
> > > +static AVBufferRef *wrap_texture_buf(AVHWFramesContext *ctx,
> > > +ID3D11Texture2D *tex, int index)
> > > {
> > > +D3D11VAFramesContext *s = ctx->internal->priv;
> > > +AVD3D11VAFramesContext *frames_hwctx = ctx->hwctx;
> > > AVBufferRef *buf;
> > > AVD3D11FrameDescriptor *desc = av_mallocz(sizeof(*desc));
> > > if (!desc) {
> > > @@ -161,6 +165,10 @@ static AVBufferRef
> > *wrap_texture_buf(ID3D11Texture2D *tex, int index)
> > > return NULL;
> > > }
> > >
> > > +frames_hwctx->texture_infos[s->nb_surfaces_used].texture = tex;
> > > +frames_hwctx->texture_infos[s->nb_surfaces_used].index = index;
> > > +s->nb_surfaces_used++;
> > > +
> > > desc->texture = tex;
> > > desc->index = index;
> > >
> > > @@ -199,7 +207,7 @@ static AVBufferRef
> > *d3d11va_alloc_single(AVHWFramesContext *ctx)
> > > return NULL;
> > > }
> > >
> > > -return wrap_texture_buf(tex, 0);
> > > +return wrap_texture_buf(ctx, tex, 0);
> > > }
> > >
> > > static AVBufferRef *d3d11va_pool_alloc(void *opaque, int size) @@
> > > -220,7 +228,7 @@ static AVBufferRef *d3d11va_pool_alloc(void *opaque,
> > int size)
> > > }
> > >
> > > ID3D11Texture2D_AddRef(hwctx->texture);
> > > -return wrap_texture_buf(hwctx->texture, s->nb_surfaces_used++);
> > > +return wrap_texture_buf(ctx, hwctx->texture,
> > > + s->nb_surfaces_used);
> > > }
> > >
> > > static int d3d11va_frames_init(AVHWFramesContext *ctx) @@ -267,7
> > > +275,7 @@ static int d3d11va_frames_init(AVHWFramesContext *ctx)
> > > av_log(ctx, AV_LOG_ERROR, "User-provided texture has
> > mismatching parameters\n");
> > > return AVERROR(EINVAL);
> > > }
> > > -} else if (texDesc.ArraySize > 0) {
> > > +} else if (!(texDesc.BindFlags & D3D11_BIND_RENDER_TARGET) &&
> > > + texDesc.ArraySize > 0) {
> > > hr = ID3D11Device_CreateTexture2D(device_hwctx->device,
> > &texDesc, NULL, &hwctx->texture);
> > > if (FAILED(hr)) {
> > > av_log(ctx, AV_LOG_ERROR, "Could not create the texture
> > > (%lx)\n", (long)hr); @@ -275,6 +283,12 @@ static int
> > d3d11va_frames_init(AVHWFramesContext *ctx)
> > > }
> > > }
> > >
> > > +hwctx->texture_infos = av_mallocz_array(ctx->initial_pool_size,
> > sizeof(*hwctx->texture_infos));
> > > +if (!hwctx->texture_infos)
> > > +return AVERROR(ENOMEM);
> > > +
> > > +s->nb_surfaces = ctx->initial_pool_size;
> > > +
> > > ctx->internal->pool_internal =
> > av_buffer_pool_init2(sizeof(AVD3D11FrameDescriptor),
> > > ctx,
> > > d3d11va_pool_alloc, NULL);
> > > if (!ctx->internal->pool_internal) diff --git
> > > a/libavutil/hwcontext_d3d11va.h b/libavutil/hwcontext_d3d11va.h index
> > > 9f91e9b1b6..295bdcd90d 100644
> > > --- a/libavutil/hwcontext_d3d11va.h
> > > +++ b/libavutil/hwcontext_d3d11va.h
> > > @@ -164,6 +164,15 @@ typedef struct AVD3D11VAFramesContext {
> > > * This f
