Re: [FFmpeg-devel] [PATCH v1 06/10] return value check for init_get_bits in vp6.c

2021-08-11 Thread Hendrik Leppkes 
On Thu, Aug 12, 2021 at 6:53 AM maryam ebrahimzadeh  wrote:
>
> ---
>  libavcodec/vp6.c | 4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/libavcodec/vp6.c b/libavcodec/vp6.c
> index 73822a00f9..149daa59f3 100644
> --- a/libavcodec/vp6.c
> +++ b/libavcodec/vp6.c
> @@ -167,7 +167,9 @@ static int vp6_parse_header(VP56Context *s, const uint8_t 
> *buf, int buf_size)
>  }
>  if (s->use_huffman) {
>  s->parse_coeff = vp6_parse_coeff_huffman;
> -init_get_bits(>gb, buf, buf_size<<3);
> +ret = init_get_bits8(>gb, buf, (buf_size<<3)/8);
> +if (ret < 0)
> +return ret;

<< 3 and / 8 just negate each other.

- 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 v1 01/10] return value check for init_get_bits in wmv2dec.c

2021-08-11 Thread Hendrik Leppkes 
On Thu, Aug 12, 2021 at 6:48 AM maryam ebrahimzadeh  wrote:
>
> As the second argument for init_get_bits can be crafted, a return value check 
> for this function call is necessary  so replace init_get_bits with 
> init_get_bits8.
>
> ---
>  libavcodec/wmv2dec.c | 6 --
>  1 file changed, 4 insertions(+), 2 deletions(-)
>
> diff --git a/libavcodec/wmv2dec.c b/libavcodec/wmv2dec.c
> index c500e3e779..73da73c02c 100644
> --- a/libavcodec/wmv2dec.c
> +++ b/libavcodec/wmv2dec.c
> @@ -101,12 +101,14 @@ static int decode_ext_header(Wmv2Context *w)
>  GetBitContext gb;
>  int fps;
>  int code;
> +int ret;
>
>  if (s->avctx->extradata_size < 4)
>  return AVERROR_INVALIDDATA;
>
> -init_get_bits(, s->avctx->extradata, 32);
> -
> +ret = init_get_bits8(, s->avctx->extradata, 4);
> +if (ret < 0)
> +return ret;

This is a fixed size, the buffer size is checked right above, what
exactly would the error condition be here?

- 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 v2 1/1] return value check for init_get_bits in wmadec.c

2021-08-11 Thread maryam ebrahimzadeh 
sorry for my mistake.
previous version faild to make.
---
 libavcodec/sipr.c|  5 +++--
 libavcodec/truemotion2.c | 12 +---
 libavcodec/utvideodec.c  |  8 ++--
 libavcodec/vaapi_mpeg2.c |  5 -
 libavcodec/vble.c|  5 +++--
 libavcodec/vc1dec.c  |  8 ++--
 libavcodec/vorbisdec.c   |  8 ++--
 libavcodec/vp6.c |  4 +++-
 libavcodec/wmadec.c  |  1 -
 9 files changed, 40 insertions(+), 16 deletions(-)

diff --git a/libavcodec/sipr.c b/libavcodec/sipr.c
index a792b22c9f..362b475bea 100644
--- a/libavcodec/sipr.c
+++ b/libavcodec/sipr.c
@@ -547,8 +547,9 @@ static int sipr_decode_frame(AVCodecContext *avctx, void 
*data,
 return ret;
 samples = (float *)frame->data[0];
 
-init_get_bits(, buf, mode_par->bits_per_frame);
-
+ret = init_get_bits8(, buf, (mode_par->bits_per_frame)/8);
+if (ret < 0)
+return ret;
 for (i = 0; i < mode_par->frames_per_packet; i++) {
 decode_parameters(, , mode_par);
 
diff --git a/libavcodec/truemotion2.c b/libavcodec/truemotion2.c
index f29db593f9..f6fedc22d4 100644
--- a/libavcodec/truemotion2.c
+++ b/libavcodec/truemotion2.c
@@ -317,7 +317,9 @@ static int tm2_read_stream(TM2Context *ctx, const uint8_t 
*buf, int stream_id, i
 pos = bytestream2_tell();
 if (skip <= pos)
 return AVERROR_INVALIDDATA;
-init_get_bits(>gb, buf + pos, (skip - pos) * 8);
+ret = init_get_bits8(>gb, buf + pos, (skip - pos));
+if (ret < 0)
+return ret;
 if ((ret = tm2_read_deltas(ctx, stream_id)) < 0)
 return ret;
 bytestream2_skip(, ((get_bits_count(>gb) + 31) >> 5) << 2);
@@ -334,7 +336,9 @@ static int tm2_read_stream(TM2Context *ctx, const uint8_t 
*buf, int stream_id, i
 pos = bytestream2_tell();
 if (skip <= pos)
 return AVERROR_INVALIDDATA;
-init_get_bits(>gb, buf + pos, (skip - pos) * 8);
+ret = init_get_bits8(>gb, buf + pos, (skip - pos));
+if (ret < 0)
+return ret;
 if ((ret = tm2_build_huff_table(ctx, )) < 0)
 return ret;
 bytestream2_skip(, ((get_bits_count(>gb) + 31) >> 5) << 2);
@@ -359,7 +363,9 @@ static int tm2_read_stream(TM2Context *ctx, const uint8_t 
*buf, int stream_id, i
 ret = AVERROR_INVALIDDATA;
 goto end;
 }
-init_get_bits(>gb, buf + pos, (skip - pos) * 8);
+init_get_bits8(>gb, buf + pos, (skip - pos));
+if (ret < 0)
+return ret;
 for (i = 0; i < toks; i++) {
 if (get_bits_left(>gb) <= 0) {
 av_log(ctx->avctx, AV_LOG_ERROR, "Incorrect number of tokens: 
%i\n", toks);
diff --git a/libavcodec/utvideodec.c b/libavcodec/utvideodec.c
index b39d8a7948..144992ff0d 100644
--- a/libavcodec/utvideodec.c
+++ b/libavcodec/utvideodec.c
@@ -153,7 +153,9 @@ static int decode_plane10(UtvideoContext *c, int plane_no,
 c->bdsp.bswap_buf((uint32_t *) c->slice_bits,
   (uint32_t *)(src + slice_data_start + c->slices * 4),
   (slice_data_end - slice_data_start + 3) >> 2);
-init_get_bits(, c->slice_bits, slice_size * 8);
+ret = init_get_bits8(, c->slice_bits, slice_size);
+if (ret < 0)
+return ret;
 
 prev = 0x200;
 for (j = sstart; j < send; j++) {
@@ -314,7 +316,9 @@ static int decode_plane(UtvideoContext *c, int plane_no,
 c->bdsp.bswap_buf((uint32_t *) c->slice_bits,
   (uint32_t *)(src + slice_data_start + c->slices * 4),
   (slice_data_end - slice_data_start + 3) >> 2);
-init_get_bits(, c->slice_bits, slice_size * 8);
+ret = init_get_bits8(, c->slice_bits, slice_size);
+if (ret < 0)
+return ret;
 
 prev = 0x80;
 for (j = sstart; j < send; j++) {
diff --git a/libavcodec/vaapi_mpeg2.c b/libavcodec/vaapi_mpeg2.c
index 26e0cd827c..8e3903212a 100644
--- a/libavcodec/vaapi_mpeg2.c
+++ b/libavcodec/vaapi_mpeg2.c
@@ -136,9 +136,12 @@ static int vaapi_mpeg2_decode_slice(AVCodecContext *avctx, 
const uint8_t *buffer
 GetBitContext gb;
 uint32_t quantiser_scale_code, intra_slice_flag, macroblock_offset;
 int err;
+int ret;
 
 /* Determine macroblock_offset */
-init_get_bits(, buffer, 8 * size);
+ret = init_get_bits8(, buffer, size);
+if (ret < 0 )
+return ret;
 if (get_bits_long(, 32) >> 8 != 1) /* start code */
 return AVERROR_INVALIDDATA;
 quantiser_scale_code = get_bits(, 5);
diff --git a/libavcodec/vble.c b/libavcodec/vble.c
index f1400959e0..d3e1804c7b 100644
--- a/libavcodec/vble.c
+++ b/libavcodec/vble.c
@@ -146,8 +146,9 @@ static int vble_decode_frame(AVCodecContext *avctx, void 
*data, int *got_frame,
 if (version != 1)
 av_log(avctx, AV_LOG_WARNING, "Unsupported VBLE Version: %d\n", 
version);
 
-init_get_bits(, src + 4, (avpkt->size - 4) *

[FFmpeg-devel] [PATCH v1 10/10] return value check for init_get_bits in utvideodec.c

2021-08-11 Thread maryam ebrahimzadeh 
---
 libavcodec/utvideodec.c | 8 ++--
 1 file changed, 6 insertions(+), 2 deletions(-)

diff --git a/libavcodec/utvideodec.c b/libavcodec/utvideodec.c
index b39d8a7948..144992ff0d 100644
--- a/libavcodec/utvideodec.c
+++ b/libavcodec/utvideodec.c
@@ -153,7 +153,9 @@ static int decode_plane10(UtvideoContext *c, int plane_no,
 c->bdsp.bswap_buf((uint32_t *) c->slice_bits,
   (uint32_t *)(src + slice_data_start + c->slices * 4),
   (slice_data_end - slice_data_start + 3) >> 2);
-init_get_bits(, c->slice_bits, slice_size * 8);
+ret = init_get_bits8(, c->slice_bits, slice_size);
+if (ret < 0)
+return ret;
 
 prev = 0x200;
 for (j = sstart; j < send; j++) {
@@ -314,7 +316,9 @@ static int decode_plane(UtvideoContext *c, int plane_no,
 c->bdsp.bswap_buf((uint32_t *) c->slice_bits,
   (uint32_t *)(src + slice_data_start + c->slices * 4),
   (slice_data_end - slice_data_start + 3) >> 2);
-init_get_bits(, c->slice_bits, slice_size * 8);
+ret = init_get_bits8(, c->slice_bits, slice_size);
+if (ret < 0)
+return ret;
 
 prev = 0x80;
 for (j = sstart; j < send; j++) {
-- 
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 v1 09/10] return value check for init_get_bits in vaapi_mpeg2.c

2021-08-11 Thread maryam ebrahimzadeh 
---
 libavcodec/vaapi_mpeg2.c | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/libavcodec/vaapi_mpeg2.c b/libavcodec/vaapi_mpeg2.c
index 26e0cd827c..8e3903212a 100644
--- a/libavcodec/vaapi_mpeg2.c
+++ b/libavcodec/vaapi_mpeg2.c
@@ -136,9 +136,12 @@ static int vaapi_mpeg2_decode_slice(AVCodecContext *avctx, 
const uint8_t *buffer
 GetBitContext gb;
 uint32_t quantiser_scale_code, intra_slice_flag, macroblock_offset;
 int err;
+int ret;
 
 /* Determine macroblock_offset */
-init_get_bits(, buffer, 8 * size);
+ret = init_get_bits8(, buffer, size);
+if (ret < 0 )
+return ret;
 if (get_bits_long(, 32) >> 8 != 1) /* start code */
 return AVERROR_INVALIDDATA;
 quantiser_scale_code = get_bits(, 5);
-- 
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 v1 08/10] return value check for init_get_bits in vble.c

2021-08-11 Thread maryam ebrahimzadeh 
---
 libavcodec/vble.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/libavcodec/vble.c b/libavcodec/vble.c
index f1400959e0..d3e1804c7b 100644
--- a/libavcodec/vble.c
+++ b/libavcodec/vble.c
@@ -146,8 +146,9 @@ static int vble_decode_frame(AVCodecContext *avctx, void 
*data, int *got_frame,
 if (version != 1)
 av_log(avctx, AV_LOG_WARNING, "Unsupported VBLE Version: %d\n", 
version);
 
-init_get_bits(, src + 4, (avpkt->size - 4) * 8);
-
+ret = init_get_bits8(, src + 4, (avpkt->size - 4) );
+if (ret < 0)
+return ret;
 /* Unpack */
 if (vble_unpack(ctx, ) < 0) {
 av_log(avctx, AV_LOG_ERROR, "Invalid Code\n");
-- 
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 v1 07/10] return value check for init_get_bits in vc1dec.c

2021-08-11 Thread maryam ebrahimzadeh 
---
 libavcodec/vc1dec.c | 8 ++--
 1 file changed, 6 insertions(+), 2 deletions(-)

diff --git a/libavcodec/vc1dec.c b/libavcodec/vc1dec.c
index 1fb1950ade..07d60294f2 100644
--- a/libavcodec/vc1dec.c
+++ b/libavcodec/vc1dec.c
@@ -444,7 +444,9 @@ static av_cold int vc1_decode_init(AVCodecContext *avctx)
 // the last byte of the extradata is a version number, 1 for the
 // samples we can decode
 
-init_get_bits(, avctx->extradata, avctx->extradata_size*8);
+ret = init_get_bits8(, avctx->extradata, avctx->extradata_size);
+if (ret < 0)
+return ret;
 
 if ((ret = ff_vc1_decode_sequence_header(avctx, v, )) < 0)
   return ret;
@@ -771,7 +773,9 @@ static int vc1_decode_frame(AVCodecContext *avctx, void 
*data,
 }
 init_get_bits(>gb, buf2, buf_size2*8);
 } else
-init_get_bits(>gb, buf, buf_size*8);
+ret = init_get_bits8(>gb, buf, buf_size);
+if (ret < 0)
+return ret;
 
 if (v->res_sprite) {
 v->new_sprite  = !get_bits1(>gb);
-- 
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 v1 06/10] return value check for init_get_bits in vp6.c

2021-08-11 Thread maryam ebrahimzadeh 
---
 libavcodec/vp6.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/libavcodec/vp6.c b/libavcodec/vp6.c
index 73822a00f9..149daa59f3 100644
--- a/libavcodec/vp6.c
+++ b/libavcodec/vp6.c
@@ -167,7 +167,9 @@ static int vp6_parse_header(VP56Context *s, const uint8_t 
*buf, int buf_size)
 }
 if (s->use_huffman) {
 s->parse_coeff = vp6_parse_coeff_huffman;
-init_get_bits(>gb, buf, buf_size<<3);
+ret = init_get_bits8(>gb, buf, (buf_size<<3)/8);
+if (ret < 0)
+return ret;
 } else {
 ret = ff_vp56_init_range_decoder(>cc, buf, buf_size);
 if (ret < 0)
-- 
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 v1 05/10] return value check for init_get_bits in vorbisdec.c

2021-08-11 Thread maryam ebrahimzadeh 
---
 libavcodec/vorbisdec.c | 8 ++--
 1 file changed, 6 insertions(+), 2 deletions(-)

diff --git a/libavcodec/vorbisdec.c b/libavcodec/vorbisdec.c
index dac2b6841c..80358f6359 100644
--- a/libavcodec/vorbisdec.c
+++ b/libavcodec/vorbisdec.c
@@ -1052,7 +1052,9 @@ static av_cold int vorbis_decode_init(AVCodecContext 
*avctx)
 return ret;
 }
 
-init_get_bits(gb, header_start[0], header_len[0]*8);
+ret = init_get_bits8(gb, header_start[0], header_len[0]);
+if (ret < 0)
+return ret;
 hdr_type = get_bits(gb, 8);
 if (hdr_type != 1) {
 av_log(avctx, AV_LOG_ERROR, "First header is not the id header.\n");
@@ -1064,7 +1066,9 @@ static av_cold int vorbis_decode_init(AVCodecContext 
*avctx)
 return ret;
 }
 
-init_get_bits(gb, header_start[2], header_len[2]*8);
+ret = init_get_bits8(gb, header_start[2], header_len[2]);
+if (ret < 0)
+return ret;
 hdr_type = get_bits(gb, 8);
 if (hdr_type != 5) {
 av_log(avctx, AV_LOG_ERROR, "Third header is not the setup header.\n");
-- 
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 v1 04/10] return value check for init_get_bits in wmadec.c

2021-08-11 Thread maryam ebrahimzadeh 
---
 libavcodec/wmadec.c | 15 +++
 1 file changed, 11 insertions(+), 4 deletions(-)

diff --git a/libavcodec/wmadec.c b/libavcodec/wmadec.c
index d627bbe50e..6ac6221d11 100644
--- a/libavcodec/wmadec.c
+++ b/libavcodec/wmadec.c
@@ -822,6 +822,7 @@ static int wma_decode_superframe(AVCodecContext *avctx, 
void *data,
 uint8_t *q;
 float **samples;
 int samples_offset;
+int ret;
 
 ff_tlog(avctx, "***decode_superframe:\n");
 
@@ -838,7 +839,9 @@ static int wma_decode_superframe(AVCodecContext *avctx, 
void *data,
 if (avctx->block_align)
 buf_size = avctx->block_align;
 
-init_get_bits(>gb, buf, buf_size * 8);
+ret = init_get_bits8(>gb, buf, buf_size);
+if (ret < 0)
+return ret;
 
 if (s->use_bit_reservoir) {
 /* read super frame header */
@@ -904,8 +907,10 @@ static int wma_decode_superframe(AVCodecContext *avctx, 
void *data,
 memset(q, 0, AV_INPUT_BUFFER_PADDING_SIZE);
 
 /* XXX: bit_offset bits into last frame */
-init_get_bits(>gb, s->last_superframe,
-  s->last_superframe_len * 8 + bit_offset);
+ret = init_get_bits8(>gb, s->last_superframe,
+  (s->last_superframe_len * 8 + bit_offset)/8);
+if (ret < 0)
+return ret;
 /* skip unused bits */
 if (s->last_bitoffset > 0)
 skip_bits(>gb, s->last_bitoffset);
@@ -921,7 +926,9 @@ static int wma_decode_superframe(AVCodecContext *avctx, 
void *data,
 pos = bit_offset + 4 + 4 + s->byte_offset_bits + 3;
 if (pos >= MAX_CODED_SUPERFRAME_SIZE * 8 || pos > buf_size * 8)
 return AVERROR_INVALIDDATA;
-init_get_bits(>gb, buf + (pos >> 3), (buf_size - (pos >> 3)) * 8);
+int ret = init_get_bits8(>gb, buf + (pos >> 3), (buf_size - (pos >> 
3)));
+if (ret < 0)
+return ret;
 len = pos & 7;
 if (len > 0)
 skip_bits(>gb, len);
-- 
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 v1 03/10] return value check for init_get_bits in wmalosslessdec.c

2021-08-11 Thread maryam ebrahimzadeh 
---
 libavcodec/wmalosslessdec.c | 9 +++--
 1 file changed, 7 insertions(+), 2 deletions(-)

diff --git a/libavcodec/wmalosslessdec.c b/libavcodec/wmalosslessdec.c
index 74c91f4f7e..a2e83ca99c 100644
--- a/libavcodec/wmalosslessdec.c
+++ b/libavcodec/wmalosslessdec.c
@@ -1187,6 +1187,7 @@ static int decode_packet(AVCodecContext *avctx, void 
*data, int *got_frame_ptr,
 const uint8_t* buf = avpkt->data;
 int buf_size   = avpkt->size;
 int num_bits_prev_frame, packet_sequence_number, spliced_packet;
+int ret;
 
 s->frame->nb_samples = 0;
 
@@ -1205,7 +1206,9 @@ static int decode_packet(AVCodecContext *avctx, void 
*data, int *got_frame_ptr,
 s->buf_bit_size  = buf_size << 3;
 
 /* parse packet header */
-init_get_bits(gb, buf, s->buf_bit_size);
+ret = init_get_bits8(gb, buf, (s->buf_bit_size)/8);
+if (ret < 0)
+return ret;
 packet_sequence_number = get_bits(gb, 4);
 skip_bits(gb, 1);   // Skip seekable_frame_in_packet, currently unused
 spliced_packet = get_bits1(gb);
@@ -1256,7 +1259,9 @@ static int decode_packet(AVCodecContext *avctx, void 
*data, int *got_frame_ptr,
 int frame_size;
 
 s->buf_bit_size = (avpkt->size - s->next_packet_start) << 3;
-init_get_bits(gb, avpkt->data, s->buf_bit_size);
+init_get_bits8(gb, avpkt->data, (s->buf_bit_size)/8);
+if (ret < 0)
+return ret;
 skip_bits(gb, s->packet_offset);
 
 if (s->len_prefix && remaining_bits(s, gb) > s->log2_frame_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 v1 02/10] return value check for init_get_bits in wmaprodec.c

2021-08-11 Thread maryam ebrahimzadeh 
---
 libavcodec/wmaprodec.c | 9 +++--
 1 file changed, 7 insertions(+), 2 deletions(-)

diff --git a/libavcodec/wmaprodec.c b/libavcodec/wmaprodec.c
index e0d00d2d37..23df0be6ab 100644
--- a/libavcodec/wmaprodec.c
+++ b/libavcodec/wmaprodec.c
@@ -1615,6 +1615,7 @@ static int decode_packet(AVCodecContext *avctx, 
WMAProDecodeCtx *s,
 int buf_size   = avpkt->size;
 int num_bits_prev_frame;
 int packet_sequence_number;
+int ret;
 
 *got_frame_ptr = 0;
 
@@ -1666,7 +1667,9 @@ static int decode_packet(AVCodecContext *avctx, 
WMAProDecodeCtx *s,
 s->buf_bit_size = buf_size << 3;
 
 /** parse packet header */
-init_get_bits(gb, buf, s->buf_bit_size);
+ret = init_get_bits8(gb, buf, (s->buf_bit_size)/8);
+if (ret < 0)
+return ret;
 if (avctx->codec_id != AV_CODEC_ID_XMA2) {
 packet_sequence_number = get_bits(gb, 4);
 skip_bits(gb, 2);
@@ -1734,7 +1737,9 @@ static int decode_packet(AVCodecContext *avctx, 
WMAProDecodeCtx *s,
 }
 
 s->buf_bit_size = (avpkt->size - s->next_packet_start) << 3;
-init_get_bits(gb, avpkt->data, s->buf_bit_size);
+ret = init_get_bits8(gb, avpkt->data, (s->buf_bit_size)/8);
+if (ret < 0)
+return ret;
 skip_bits(gb, s->packet_offset);
 if (s->len_prefix && remaining_bits(s, gb) > s->log2_frame_size &&
 (frame_size = show_bits(gb, s->log2_frame_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 v1 01/10] return value check for init_get_bits in wmv2dec.c

2021-08-11 Thread maryam ebrahimzadeh 
As the second argument for init_get_bits can be crafted, a return value check 
for this function call is necessary  so replace init_get_bits with 
init_get_bits8.

---
 libavcodec/wmv2dec.c | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/libavcodec/wmv2dec.c b/libavcodec/wmv2dec.c
index c500e3e779..73da73c02c 100644
--- a/libavcodec/wmv2dec.c
+++ b/libavcodec/wmv2dec.c
@@ -101,12 +101,14 @@ static int decode_ext_header(Wmv2Context *w)
 GetBitContext gb;
 int fps;
 int code;
+int ret;
 
 if (s->avctx->extradata_size < 4)
 return AVERROR_INVALIDDATA;
 
-init_get_bits(, s->avctx->extradata, 32);
-
+ret = init_get_bits8(, s->avctx->extradata, 4);
+if (ret < 0)
+return ret;
 fps = get_bits(, 5);
 s->bit_rate = get_bits(, 11) * 1024;
 w->mspel_bit= get_bits1();
-- 
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] movenc: Ensure no separate moof written for empty track

2021-08-11 Thread Hu Weiwen 
track->mdat_buf can be not NULL while the track is still empty if the
last packet write failed.

Signed-off-by: Hu Weiwen 
---
 libavformat/movenc.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/libavformat/movenc.c b/libavformat/movenc.c
index bcc202300bb..a460cd9adae 100644
--- a/libavformat/movenc.c
+++ b/libavformat/movenc.c
@@ -5422,7 +5422,7 @@ static int mov_flush_fragment(AVFormatContext *s, int 
force)
 duration = track->start_dts + track->track_duration -
track->cluster[0].dts;
 if (mov->flags & FF_MOV_FLAG_SEPARATE_MOOF) {
-if (!track->mdat_buf)
+if (!track->entry)
 continue;
 mdat_size = avio_tell(track->mdat_buf);
 moof_tracks = i;
-- 
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".

[FFmpeg-devel] [PATCH] movenc: Get rid of frag_start

2021-08-11 Thread Hu Weiwen 
"frag_start" is redundant, and every occurance can be replaced with 
cluster[0].dts - start_dts

The proof of no behaviour changes: (All line number below is based on commit 
bff7d662d728)

"frag_start" is read at 4 place (with all possible call stacks):

mov_write_packet
  ...
  mov_flush_fragment
mov_write_moof_tag
  mov_write_moof_tag_internal
mov_write_traf_tag
  mov_write_tfxd_tag (#1)
  mov_write_tfdt_tag (#2)
  mov_add_tfra_entries (#3)
  mov_write_sidx_tags
mov_write_sidx_tag (#4)

mov_write_trailer
  mov_auto_flush_fragment
mov_flush_fragment
  ... (#1 #2 #3 #4)
  mov_write_sidx_tags
mov_write_sidx_tag (#4)
  shift_data
compute_sidx_size
  get_sidx_size
mov_write_sidx_tags
  mov_write_sidx_tag (#4)

All read happens in "mov_write_trailer" and "mov_write_moof_tag". So we need to 
prove no behaviour change in these two
functions.

Condition 1: for every track that have "trk->entry == 0", trk->frag_start == 
trk->track_duration.

Condition 2: for every track that have "trk->entry > 0", trk->frag_start == 
trk->cluster[0].dts - trk->start_dts.

Definition 1: "Before flush" means just before the invocation of 
"mov_flush_fragment", except for the auto-flush case in
"mov_write_single_packet", which means before L5934.

Lemma 1: If Condition 1 & 2 is true before flush, Condition 1 & 2 is still true 
after "mov_flush_fragment" returns.

Proof:
No update to the tracks that have "trk->entry == 0" before flushing, so we 
only consider tracks that have "trk->entry > 0":

Case 1: !moov_written and moov will be written in this iteration
trk->entry = 0  
  L5366
trk->frag_start == trk->cluster[0].dts - trk->start_dts 
  Lemma condition
trk->frag_start += trk->start_dts + trk->track_duration - 
trk->cluster[0].dts;L5363
So trk->entry == 0 && trk->frag_start == trk->track_duration
Case 2: !moov_written and moov will NOT be written in this iteration
nothing changed
Case 3: moov_written
trk->entry = 0  
  L5445
trk->frag_start == trk->cluster[0].dts - trk->start_dts 
  Lemma condition
trk->frag_start += trk->start_dts + trk->track_duration - 
trk->cluster[0].dts;L5444
So trk->entry == 0 && trk->frag_start == trk->track_duration

Note that trk->track_duration may be updated for the tracks that have 
"trk->entry > 0" (mov_write_moov_tag will
update track_duration of "tmcd" track, but it must have 1 entry). But in 
all case, trk->frag_start is also updated
to consider the new value.

Lemma 2: If Condition 1 & 2 is true before "ff_mov_write_packet" invocation, 
Condition 1 & 2 is still true after it returns.

Proof:
Only the track corresponding to the pkt is updated, and no update to 
relevant variables if trk->entry > 0 before invocation.
So we only need to prove "trk->frag_start == trk->cluster[0].dts - 
trk->start_dts" after trk->entry increase from 0 to 1.

Case 1: trk->start_dts == AV_NOPTS_VALUE
Case 1.1: trk->frag_discont && use_editlist
trk->cluster[0].dts = pkt->dtsat L5741
trk->frag_start = pkt->ptsat L5785
trk->start_dts = pkt->dts - pkt->pts  at L5786
So trk->frag_start == trk->cluster[0].dts - trk->start_dts
Case 1.2: trk->frag_discont && !use_editlist
trk->cluster[0].dts = pkt->dtsat L5741
trk->frag_start = pkt->dtsat L5790
trk->start_dts = 0at L5791
So trk->frag_start == trk->cluster[0].dts - trk->start_dts
Case 1.3: !trk->frag_discont
trk->cluster[0].dts = pkt->dtsat L5741
trk->frag_start = 0   init
trk->start_dts = pkt->dts at L5779
So trk->frag_start == trk->cluster[0].dts - trk->start_dts
Case 2: trk->start_dts != AV_NOPTS_VALUE
Case 2.1: trk->frag_discont
trk->cluster[0].dts = pkt->dtsat L5741
trk->frag_start = pkt->dts - trk->start_dts   at L5763
So trk->frag_start == trk->cluster[0].dts - trk->start_dts
Case 2.2: !trk->frag_discont
trk->cluster[0].dts = trk->start_dts + trk->track_duration  at L5749
trk->track_duration == trk->frag_start  Lemma 
condition
So trk->frag_start == trk->cluster[0].dts - trk->start_dts

Lemma 3: Condition 1 & 2 is true in all case before and after 
"ff_mov_write_packet" invocation, before flush and after
 "mov_flush_fragment" returns.

Proof: All updates to relevant variable happen either in 
"ff_mov_write_packet", or during flush. And Condition 1 & 2
   is true initially. So with

Re: [FFmpeg-devel] [PATCH v2] lavc/qsvenc: allows the SDK runtime to choose LowPower/non-LowPower modes

2021-08-11 Thread Soft Works 



> -Original Message-
> From: ffmpeg-devel  On Behalf Of
> Haihao Xiang
> Sent: Thursday, 12 August 2021 04:34
> To: ffmpeg-devel@ffmpeg.org
> Cc: Haihao Xiang 
> Subject: [FFmpeg-devel] [PATCH v2] lavc/qsvenc: allows the SDK
> runtime to choose LowPower/non-LowPower modes
> 
> The SDK supports LowPower and non-LowPower modes, but some features
> are
> available only under one of the two modes. Currently non-LowPower
> mode
> is always chosen in FFmpeg if the mode is not set to LowPower
> explicitly. User will experience some SDK errors if a LowPower
> related
> feature is specified but the mode is not set to LowPower. With this
> patch, the mode is set to unknown by default in FFmpeg, the SDK is
> able
> to choose a workable mode for the specified features.
> ---
> v2: update commit log and rebase the patch against the current master
> 
>  libavcodec/qsvenc.c | 6 --
>  libavcodec/qsvenc.h | 2 +-
>  2 files changed, 5 insertions(+), 3 deletions(-)
> 
> diff --git a/libavcodec/qsvenc.c b/libavcodec/qsvenc.c
> index e7e65ebfcf..50ec7065ca 100644
> --- a/libavcodec/qsvenc.c
> +++ b/libavcodec/qsvenc.c
> @@ -514,7 +514,7 @@ static int init_video_param(AVCodecContext
> *avctx, QSVEncContext *q)
>  }
>  }
> 
> -if (q->low_power) {
> +if (q->low_power == 1) {
>  #if QSV_HAVE_VDENC
>  q->param.mfx.LowPower = MFX_CODINGOPTION_ON;
>  #else
> @@ -523,7 +523,9 @@ static int init_video_param(AVCodecContext
> *avctx, QSVEncContext *q)
>  q->low_power = 0;
>  q->param.mfx.LowPower = MFX_CODINGOPTION_OFF;
>  #endif
> -} else
> +} else if (q->low_power == -1)
> +q->param.mfx.LowPower = MFX_CODINGOPTION_UNKNOWN;
> +else
>  q->param.mfx.LowPower = MFX_CODINGOPTION_OFF;
> 
>  q->param.mfx.CodecProfile   = q->profile;
> diff --git a/libavcodec/qsvenc.h b/libavcodec/qsvenc.h
> index ba20b6f906..31516b8e55 100644
> --- a/libavcodec/qsvenc.h
> +++ b/libavcodec/qsvenc.h
> @@ -96,7 +96,7 @@
>  { "adaptive_b", "Adaptive B-frame placement",
> OFFSET(qsv.adaptive_b), AV_OPT_TYPE_INT, { .i64 = -1 }, -1,
> 1, VE }, \
>  { "b_strategy", "Strategy to choose between I/P/B-frames",
> OFFSET(qsv.b_strategy),AV_OPT_TYPE_INT, { .i64 = -1 }, -1,
> 1, VE }, \
>  { "forced_idr", "Forcing I frames as IDR frames",
> OFFSET(qsv.forced_idr), AV_OPT_TYPE_BOOL,{ .i64 = 0  },  0,
> 1, VE }, \
> -{ "low_power", "enable low power mode(experimental: many limitations
> by mfx version, BRC modes, etc.)", OFFSET(qsv.low_power),
> AV_OPT_TYPE_BOOL, { .i64 = 0}, 0, 1, VE},\
> +{ "low_power", "enable low power mode(experimental: many limitations
> by mfx version, BRC modes, etc.)", OFFSET(qsv.low_power),
> AV_OPT_TYPE_BOOL, { .i64 = -1}, -1, 1, VE},\

I don't know what the "official" guideline is for AV_OPT_TYPE_BOOL,
but IMO it is confusing to have a tristate logic, especially when 
it is unclear what happens in each of the three cases.

I've seen that there are a few cases in all ffmpeg where it is
done like that, but in most cases it is unclear what happens 
with each of the three values and in many cases, there are 
only 2 effective values anyway.
And even inconsistent: In some cases, -1 and 1 are both taken 
for true, in other cases it is checked for x < 1 and sometimes
x >= 0.

IMO, that's a pattern that shouldn't be adopted. An INTEGER option
(still with -1, 0 and 1) with three named option values and an 
indication what the default is, would be a nicer way - and still
compatible.
(for all other options as well in a later patch). 

In general though, the patch makes sense to me!

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] libavformat/file.c: 'file_delete()' and 'file_move()' require 'CONFIG_FILE_PROTOCOL'

2021-08-11 Thread Andreas Rheinhardt 
Michael Witten:
> This quashes 2 warnings when the 'file' protocol is not enabled.
> ---
>  libavformat/file.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/libavformat/file.c b/libavformat/file.c
> index 8303436be0..9c23f680cd 100644
> --- a/libavformat/file.c
> +++ b/libavformat/file.c
> @@ -167,6 +167,8 @@ static int file_check(URLContext *h, int mask)
>  return ret;
>  }
>  
> +#if CONFIG_FILE_PROTOCOL
> +
>  static int file_delete(URLContext *h)
>  {
>  #if HAVE_UNISTD_H
> @@ -203,8 +205,6 @@ static int file_move(URLContext *h_src, URLContext *h_dst)
>  return 0;
>  }
>  
> -#if CONFIG_FILE_PROTOCOL
> -
>  static int file_open(URLContext *h, const char *filename, int flags)
>  {
>  FileContext *c = h->priv_data;
> 
Thanks, 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-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH 1/2] avformat/oggdec: Use av_realloc_array()

2021-08-11 Thread Andreas Rheinhardt 
Andreas Rheinhardt:
> Signed-off-by: Andreas Rheinhardt 
> ---
> This also removes the last user of av_size_mult from libavformat
> (indeed, from anything outside of mem.c), so this removes one entry
> from the list of dynamic symbols (if using a shared build).
> 
>  libavformat/oggdec.c | 5 ++---
>  1 file changed, 2 insertions(+), 3 deletions(-)
> 
> diff --git a/libavformat/oggdec.c b/libavformat/oggdec.c
> index bb289e0756..5afbae2147 100644
> --- a/libavformat/oggdec.c
> +++ b/libavformat/oggdec.c
> @@ -251,7 +251,6 @@ static int ogg_new_stream(AVFormatContext *s, uint32_t 
> serial)
>  int idx = ogg->nstreams;
>  AVStream *st;
>  struct ogg_stream *os;
> -size_t size;
>  
>  if (ogg->state) {
>  av_log(s, AV_LOG_ERROR, "New streams are not supposed to be added "
> @@ -260,8 +259,8 @@ static int ogg_new_stream(AVFormatContext *s, uint32_t 
> serial)
>  }
>  
>  /* Allocate and init a new Ogg Stream */
> -if (av_size_mult(ogg->nstreams + 1, sizeof(*ogg->streams), ) < 0 ||
> -!(os = av_realloc(ogg->streams, size)))
> +if (!(os = av_realloc_array(ogg->streams, ogg->nstreams + 1,
> +sizeof(*ogg->streams
>  return AVERROR(ENOMEM);
>  ogg->streams = os;
>  os   = ogg->streams + idx;
> 
Will apply this patchset later today unless there are objections.

- Andreas
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH] avcodec/h264_parse: add some missing checks to ff_h264_init_poc()

2021-08-11 Thread James Almer 

On 8/11/2021 11:33 PM, Andreas Rheinhardt wrote:

James Almer:

On 8/11/2021 11:26 PM, Andreas Rheinhardt wrote:

James Almer:

poc.delta_poc_bottom and poc.delta_poc[1] are only coded in the
bitstream if
pps->pic_order_present is true, so ensure they are not used
otherwise, to
prevent the potential use of stale values.

Signed-off-by: James Almer 
---
This complements ce4a31cd1ff0348d279af74d49556d0315171e94, and is a more
thorough fix for the issue described in it, affecting all users of
ff_h264_init_poc(), like the parser, and not just the decoder.

   libavcodec/h264_parse.c  | 7 ---
   libavcodec/h264_parse.h  | 2 +-
   libavcodec/h264_parser.c | 2 +-
   libavcodec/h264_slice.c  | 2 +-
   4 files changed, 7 insertions(+), 6 deletions(-)

diff --git a/libavcodec/h264_parse.c b/libavcodec/h264_parse.c
index 1c1d1c04b0..5d642c7201 100644
--- a/libavcodec/h264_parse.c
+++ b/libavcodec/h264_parse.c
@@ -275,9 +275,10 @@ fail:
   }
     int ff_h264_init_poc(int pic_field_poc[2], int *pic_poc,
- const SPS *sps, H264POCContext *pc,
+ const PPS *pps, H264POCContext *pc,
    int picture_structure, int nal_ref_idc)
   {
+    const SPS *sps = pps->sps;
   const int max_frame_num = 1 << sps->log2_max_frame_num;
   int64_t field_poc[2];
   @@ -300,7 +301,7 @@ int ff_h264_init_poc(int pic_field_poc[2], int
*pic_poc,
   pc->poc_msb = pc->prev_poc_msb;
   field_poc[0] =
   field_poc[1] = pc->poc_msb + pc->poc_lsb;
-    if (picture_structure == PICT_FRAME)
+    if (pps->pic_order_present && picture_structure == PICT_FRAME)
   field_poc[1] += pc->delta_poc_bottom;
   } else if (sps->poc_type == 1) {
   int abs_frame_num;
@@ -336,7 +337,7 @@ int ff_h264_init_poc(int pic_field_poc[2], int
*pic_poc,
   field_poc[0] = expectedpoc + pc->delta_poc[0];
   field_poc[1] = field_poc[0] +
sps->offset_for_top_to_bottom_field;
   -    if (picture_structure == PICT_FRAME)
+    if (pps->pic_order_present && picture_structure == PICT_FRAME)
   field_poc[1] += pc->delta_poc[1];


delta_pic_order_cnt_bottom and both delta_pic_order_cnt elements are
supposed to be inferred to zero when they are not present. If this were
done, the above additions wouldn't make a difference. I thought that
ce4a31cd1ff0348d279af74d49556d0315171e94 actually did exactly that,
which makes me not understand the current patch.


I explained it above. It complements ce4a31cd1f, being a more thorough
fix that also affects the parser (where much like the decoder before the
aforementioned commit, it's not inferring them to zero), by making this
function not depend on the caller ensuring the POC struct is clean of
stale values.


So this is supposed to help callers who do not use our slice parsing
code, but rather some other code that does not properly infer values for
elements that are absent?


Like the parser, yes. It's independent of the decoder, and reimplements 
slice header parsing.
I was going to send a patch to infer these values to 0 on it too like i 
did for the decoder, but i figured this was a better fix, adding the 
proper syntax checks from the spec.




- Andreas
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".



___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH] avfilter/vf_scale: Avoid unnecessary indirection

2021-08-11 Thread Andreas Rheinhardt 
Andreas Rheinhardt:
> Signed-off-by: Andreas Rheinhardt 
> ---
>  libavfilter/vf_scale.c | 42 +-
>  1 file changed, 21 insertions(+), 21 deletions(-)
> 
> diff --git a/libavfilter/vf_scale.c b/libavfilter/vf_scale.c
> index aa855b894a..160ad8b584 100644
> --- a/libavfilter/vf_scale.c
> +++ b/libavfilter/vf_scale.c
> @@ -530,31 +530,31 @@ static int config_props(AVFilterLink *outlink)
>  
>  for (i = 0; i < 3; i++) {
>  int in_v_chr_pos = scale->in_v_chr_pos, out_v_chr_pos = 
> scale->out_v_chr_pos;
> -struct SwsContext **s = swscs[i];
> -*s = sws_alloc_context();
> -if (!*s)
> +struct SwsContext *const s = sws_alloc_context();
> +if (!s)
>  return AVERROR(ENOMEM);
> -
> -av_opt_set_int(*s, "srcw", inlink0 ->w, 0);
> -av_opt_set_int(*s, "srch", inlink0 ->h >> !!i, 0);
> -av_opt_set_int(*s, "src_format", inlink0->format, 0);
> -av_opt_set_int(*s, "dstw", outlink->w, 0);
> -av_opt_set_int(*s, "dsth", outlink->h >> !!i, 0);
> -av_opt_set_int(*s, "dst_format", outfmt, 0);
> -av_opt_set_int(*s, "sws_flags", scale->flags, 0);
> -av_opt_set_int(*s, "param0", scale->param[0], 0);
> -av_opt_set_int(*s, "param1", scale->param[1], 0);
> +*swscs[i] = s;
> +
> +av_opt_set_int(s, "srcw", inlink0 ->w, 0);
> +av_opt_set_int(s, "srch", inlink0 ->h >> !!i, 0);
> +av_opt_set_int(s, "src_format", inlink0->format, 0);
> +av_opt_set_int(s, "dstw", outlink->w, 0);
> +av_opt_set_int(s, "dsth", outlink->h >> !!i, 0);
> +av_opt_set_int(s, "dst_format", outfmt, 0);
> +av_opt_set_int(s, "sws_flags", scale->flags, 0);
> +av_opt_set_int(s, "param0", scale->param[0], 0);
> +av_opt_set_int(s, "param1", scale->param[1], 0);
>  if (scale->in_range != AVCOL_RANGE_UNSPECIFIED)
> -av_opt_set_int(*s, "src_range",
> +av_opt_set_int(s, "src_range",
> scale->in_range == AVCOL_RANGE_JPEG, 0);
>  if (scale->out_range != AVCOL_RANGE_UNSPECIFIED)
> -av_opt_set_int(*s, "dst_range",
> +av_opt_set_int(s, "dst_range",
> scale->out_range == AVCOL_RANGE_JPEG, 0);
>  
>  if (scale->opts) {
>  AVDictionaryEntry *e = NULL;
>  while ((e = av_dict_get(scale->opts, "", e, 
> AV_DICT_IGNORE_SUFFIX))) {
> -if ((ret = av_opt_set(*s, e->key, e->value, 0)) < 0)
> +if ((ret = av_opt_set(s, e->key, e->value, 0)) < 0)
>  return ret;
>  }
>  }
> @@ -569,12 +569,12 @@ static int config_props(AVFilterLink *outlink)
>  out_v_chr_pos = (i == 0) ? 128 : (i == 1) ? 64 : 192;
>  }
>  
> -av_opt_set_int(*s, "src_h_chr_pos", scale->in_h_chr_pos, 0);
> -av_opt_set_int(*s, "src_v_chr_pos", in_v_chr_pos, 0);
> -av_opt_set_int(*s, "dst_h_chr_pos", scale->out_h_chr_pos, 0);
> -av_opt_set_int(*s, "dst_v_chr_pos", out_v_chr_pos, 0);
> +av_opt_set_int(s, "src_h_chr_pos", scale->in_h_chr_pos, 0);
> +av_opt_set_int(s, "src_v_chr_pos", in_v_chr_pos, 0);
> +av_opt_set_int(s, "dst_h_chr_pos", scale->out_h_chr_pos, 0);
> +av_opt_set_int(s, "dst_v_chr_pos", out_v_chr_pos, 0);
>  
> -if ((ret = sws_init_context(*s, NULL, NULL)) < 0)
> +if ((ret = sws_init_context(s, NULL, NULL)) < 0)
>  return ret;
>  if (!scale->interlaced)
>  break;
> 
Will apply later today unless there are objections.

- Andreas
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH] avutil/mem: Correct av_calloc() documentation

2021-08-11 Thread Andreas Rheinhardt 
Andreas Rheinhardt:
> Incorrect since 4959f18a8e11ad7d3529b1c4fc429f1b6b76ad7c.
> 
> Signed-off-by: Andreas Rheinhardt 
> ---
> Do we even need both av_mallocz_array and av_calloc given that
> they do exactly the same? I'd like to deprecate one, namely
> av_mallocz_array() (it has the longer name).
> 
>  libavutil/mem.h | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/libavutil/mem.h b/libavutil/mem.h
> index e9d343eaf0..c7f8867a13 100644
> --- a/libavutil/mem.h
> +++ b/libavutil/mem.h
> @@ -240,7 +240,7 @@ av_alloc_size(1, 2) void *av_malloc_array(size_t nmemb, 
> size_t size);
>  av_alloc_size(1, 2) void *av_mallocz_array(size_t nmemb, size_t size);
>  
>  /**
> - * Non-inlined equivalent of av_mallocz_array().
> + * Equivalent of av_mallocz_array().
>   *
>   * Created for symmetry with the calloc() C function.
>   */
> 
Will apply later today unless there are objections.
I'm still waiting for input regarding the deprecation of av_calloc or
av_mallocz_array.

- Andreas
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

[FFmpeg-devel] [PATCH v2] lavc/qsvenc: allows the SDK runtime to choose LowPower/non-LowPower modes

2021-08-11 Thread Haihao Xiang 
The SDK supports LowPower and non-LowPower modes, but some features are
available only under one of the two modes. Currently non-LowPower mode
is always chosen in FFmpeg if the mode is not set to LowPower
explicitly. User will experience some SDK errors if a LowPower related
feature is specified but the mode is not set to LowPower. With this
patch, the mode is set to unknown by default in FFmpeg, the SDK is able
to choose a workable mode for the specified features.
---
v2: update commit log and rebase the patch against the current master

 libavcodec/qsvenc.c | 6 --
 libavcodec/qsvenc.h | 2 +-
 2 files changed, 5 insertions(+), 3 deletions(-)

diff --git a/libavcodec/qsvenc.c b/libavcodec/qsvenc.c
index e7e65ebfcf..50ec7065ca 100644
--- a/libavcodec/qsvenc.c
+++ b/libavcodec/qsvenc.c
@@ -514,7 +514,7 @@ static int init_video_param(AVCodecContext *avctx, 
QSVEncContext *q)
 }
 }
 
-if (q->low_power) {
+if (q->low_power == 1) {
 #if QSV_HAVE_VDENC
 q->param.mfx.LowPower = MFX_CODINGOPTION_ON;
 #else
@@ -523,7 +523,9 @@ static int init_video_param(AVCodecContext *avctx, 
QSVEncContext *q)
 q->low_power = 0;
 q->param.mfx.LowPower = MFX_CODINGOPTION_OFF;
 #endif
-} else
+} else if (q->low_power == -1)
+q->param.mfx.LowPower = MFX_CODINGOPTION_UNKNOWN;
+else
 q->param.mfx.LowPower = MFX_CODINGOPTION_OFF;
 
 q->param.mfx.CodecProfile   = q->profile;
diff --git a/libavcodec/qsvenc.h b/libavcodec/qsvenc.h
index ba20b6f906..31516b8e55 100644
--- a/libavcodec/qsvenc.h
+++ b/libavcodec/qsvenc.h
@@ -96,7 +96,7 @@
 { "adaptive_b", "Adaptive B-frame placement", 
OFFSET(qsv.adaptive_b), AV_OPT_TYPE_INT, { .i64 = -1 }, -1,  1, VE 
}, \
 { "b_strategy", "Strategy to choose between I/P/B-frames", 
OFFSET(qsv.b_strategy),AV_OPT_TYPE_INT, { .i64 = -1 }, -1,  1, VE 
}, \
 { "forced_idr", "Forcing I frames as IDR frames", 
OFFSET(qsv.forced_idr), AV_OPT_TYPE_BOOL,{ .i64 = 0  },  0,  1, VE 
}, \
-{ "low_power", "enable low power mode(experimental: many limitations by mfx 
version, BRC modes, etc.)", OFFSET(qsv.low_power), AV_OPT_TYPE_BOOL, { .i64 = 
0}, 0, 1, VE},\
+{ "low_power", "enable low power mode(experimental: many limitations by mfx 
version, BRC modes, etc.)", OFFSET(qsv.low_power), AV_OPT_TYPE_BOOL, { .i64 = 
-1}, -1, 1, VE},\
 
 extern const AVCodecHWConfigInternal *const ff_qsv_enc_hw_configs[];
 
-- 
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/h264_parse: add some missing checks to ff_h264_init_poc()

2021-08-11 Thread Andreas Rheinhardt 
James Almer:
> On 8/11/2021 11:26 PM, Andreas Rheinhardt wrote:
>> James Almer:
>>> poc.delta_poc_bottom and poc.delta_poc[1] are only coded in the
>>> bitstream if
>>> pps->pic_order_present is true, so ensure they are not used
>>> otherwise, to
>>> prevent the potential use of stale values.
>>>
>>> Signed-off-by: James Almer 
>>> ---
>>> This complements ce4a31cd1ff0348d279af74d49556d0315171e94, and is a more
>>> thorough fix for the issue described in it, affecting all users of
>>> ff_h264_init_poc(), like the parser, and not just the decoder.
>>>
>>>   libavcodec/h264_parse.c  | 7 ---
>>>   libavcodec/h264_parse.h  | 2 +-
>>>   libavcodec/h264_parser.c | 2 +-
>>>   libavcodec/h264_slice.c  | 2 +-
>>>   4 files changed, 7 insertions(+), 6 deletions(-)
>>>
>>> diff --git a/libavcodec/h264_parse.c b/libavcodec/h264_parse.c
>>> index 1c1d1c04b0..5d642c7201 100644
>>> --- a/libavcodec/h264_parse.c
>>> +++ b/libavcodec/h264_parse.c
>>> @@ -275,9 +275,10 @@ fail:
>>>   }
>>>     int ff_h264_init_poc(int pic_field_poc[2], int *pic_poc,
>>> - const SPS *sps, H264POCContext *pc,
>>> + const PPS *pps, H264POCContext *pc,
>>>    int picture_structure, int nal_ref_idc)
>>>   {
>>> +    const SPS *sps = pps->sps;
>>>   const int max_frame_num = 1 << sps->log2_max_frame_num;
>>>   int64_t field_poc[2];
>>>   @@ -300,7 +301,7 @@ int ff_h264_init_poc(int pic_field_poc[2], int
>>> *pic_poc,
>>>   pc->poc_msb = pc->prev_poc_msb;
>>>   field_poc[0] =
>>>   field_poc[1] = pc->poc_msb + pc->poc_lsb;
>>> -    if (picture_structure == PICT_FRAME)
>>> +    if (pps->pic_order_present && picture_structure == PICT_FRAME)
>>>   field_poc[1] += pc->delta_poc_bottom;
>>>   } else if (sps->poc_type == 1) {
>>>   int abs_frame_num;
>>> @@ -336,7 +337,7 @@ int ff_h264_init_poc(int pic_field_poc[2], int
>>> *pic_poc,
>>>   field_poc[0] = expectedpoc + pc->delta_poc[0];
>>>   field_poc[1] = field_poc[0] +
>>> sps->offset_for_top_to_bottom_field;
>>>   -    if (picture_structure == PICT_FRAME)
>>> +    if (pps->pic_order_present && picture_structure == PICT_FRAME)
>>>   field_poc[1] += pc->delta_poc[1];
>>
>> delta_pic_order_cnt_bottom and both delta_pic_order_cnt elements are
>> supposed to be inferred to zero when they are not present. If this were
>> done, the above additions wouldn't make a difference. I thought that
>> ce4a31cd1ff0348d279af74d49556d0315171e94 actually did exactly that,
>> which makes me not understand the current patch.
> 
> I explained it above. It complements ce4a31cd1f, being a more thorough
> fix that also affects the parser (where much like the decoder before the
> aforementioned commit, it's not inferring them to zero), by making this
> function not depend on the caller ensuring the POC struct is clean of
> stale values.
> 
So this is supposed to help callers who do not use our slice parsing
code, but rather some other code that does not properly infer values for
elements that are absent?

- Andreas
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH] avcodec/h264_parse: add some missing checks to ff_h264_init_poc()

2021-08-11 Thread James Almer 

On 8/11/2021 11:26 PM, Andreas Rheinhardt wrote:

James Almer:

poc.delta_poc_bottom and poc.delta_poc[1] are only coded in the bitstream if
pps->pic_order_present is true, so ensure they are not used otherwise, to
prevent the potential use of stale values.

Signed-off-by: James Almer 
---
This complements ce4a31cd1ff0348d279af74d49556d0315171e94, and is a more
thorough fix for the issue described in it, affecting all users of
ff_h264_init_poc(), like the parser, and not just the decoder.

  libavcodec/h264_parse.c  | 7 ---
  libavcodec/h264_parse.h  | 2 +-
  libavcodec/h264_parser.c | 2 +-
  libavcodec/h264_slice.c  | 2 +-
  4 files changed, 7 insertions(+), 6 deletions(-)

diff --git a/libavcodec/h264_parse.c b/libavcodec/h264_parse.c
index 1c1d1c04b0..5d642c7201 100644
--- a/libavcodec/h264_parse.c
+++ b/libavcodec/h264_parse.c
@@ -275,9 +275,10 @@ fail:
  }
  
  int ff_h264_init_poc(int pic_field_poc[2], int *pic_poc,

- const SPS *sps, H264POCContext *pc,
+ const PPS *pps, H264POCContext *pc,
   int picture_structure, int nal_ref_idc)
  {
+const SPS *sps = pps->sps;
  const int max_frame_num = 1 << sps->log2_max_frame_num;
  int64_t field_poc[2];
  
@@ -300,7 +301,7 @@ int ff_h264_init_poc(int pic_field_poc[2], int *pic_poc,

  pc->poc_msb = pc->prev_poc_msb;
  field_poc[0] =
  field_poc[1] = pc->poc_msb + pc->poc_lsb;
-if (picture_structure == PICT_FRAME)
+if (pps->pic_order_present && picture_structure == PICT_FRAME)
  field_poc[1] += pc->delta_poc_bottom;
  } else if (sps->poc_type == 1) {
  int abs_frame_num;
@@ -336,7 +337,7 @@ int ff_h264_init_poc(int pic_field_poc[2], int *pic_poc,
  field_poc[0] = expectedpoc + pc->delta_poc[0];
  field_poc[1] = field_poc[0] + sps->offset_for_top_to_bottom_field;
  
-if (picture_structure == PICT_FRAME)

+if (pps->pic_order_present && picture_structure == PICT_FRAME)
  field_poc[1] += pc->delta_poc[1];


delta_pic_order_cnt_bottom and both delta_pic_order_cnt elements are
supposed to be inferred to zero when they are not present. If this were
done, the above additions wouldn't make a difference. I thought that
ce4a31cd1ff0348d279af74d49556d0315171e94 actually did exactly that,
which makes me not understand the current patch.


I explained it above. It complements ce4a31cd1f, being a more thorough 
fix that also affects the parser (where much like the decoder before the 
aforementioned commit, it's not inferring them to zero), by making this 
function not depend on the caller ensuring the POC struct is clean of 
stale values.





  } else {
  int poc = 2 * (pc->frame_num_offset + pc->frame_num);
diff --git a/libavcodec/h264_parse.h b/libavcodec/h264_parse.h
index 4d01620125..35c4810f34 100644
--- a/libavcodec/h264_parse.h
+++ b/libavcodec/h264_parse.h
@@ -78,7 +78,7 @@ int ff_h264_parse_ref_count(int *plist_count, int 
ref_count[2],
  int slice_type_nos, int picture_structure, void 
*logctx);
  
  int ff_h264_init_poc(int pic_field_poc[2], int *pic_poc,

- const SPS *sps, H264POCContext *poc,
+ const PPS *pps, H264POCContext *poc,
   int picture_structure, int nal_ref_idc);
  
  int ff_h264_decode_extradata(const uint8_t *data, int size, H264ParamSets *ps,

diff --git a/libavcodec/h264_parser.c b/libavcodec/h264_parser.c
index d3c56cc188..6e2e7cde67 100644
--- a/libavcodec/h264_parser.c
+++ b/libavcodec/h264_parser.c
@@ -440,7 +440,7 @@ static inline int parse_nal_units(AVCodecParserContext *s,
  /* Decode POC of this picture.
   * The prev_ values needed for decoding POC of the next picture 
are not set here. */
  field_poc[0] = field_poc[1] = INT_MAX;
-ret = ff_h264_init_poc(field_poc, >output_picture_number, sps,
+ret = ff_h264_init_poc(field_poc, >output_picture_number, 
p->ps.pps,
   >poc, p->picture_structure, nal.ref_idc);
  if (ret < 0)
  goto fail;
diff --git a/libavcodec/h264_slice.c b/libavcodec/h264_slice.c
index 0d7107d455..223cf21267 100644
--- a/libavcodec/h264_slice.c
+++ b/libavcodec/h264_slice.c
@@ -1742,7 +1742,7 @@ static int h264_field_start(H264Context *h, const 
H264SliceContext *sl,
  }
  
  ret = ff_h264_init_poc(h->cur_pic_ptr->field_poc, >cur_pic_ptr->poc,

- h->ps.sps, >poc, h->picture_structure, nal->ref_idc);
+   h->ps.pps, >poc, h->picture_structure, 
nal->ref_idc);
  if (ret < 0)
  return ret;
  



___
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/h264_parse: add some missing checks to ff_h264_init_poc()

2021-08-11 Thread Andreas Rheinhardt 
James Almer:
> poc.delta_poc_bottom and poc.delta_poc[1] are only coded in the bitstream if
> pps->pic_order_present is true, so ensure they are not used otherwise, to
> prevent the potential use of stale values.
> 
> Signed-off-by: James Almer 
> ---
> This complements ce4a31cd1ff0348d279af74d49556d0315171e94, and is a more
> thorough fix for the issue described in it, affecting all users of
> ff_h264_init_poc(), like the parser, and not just the decoder.
> 
>  libavcodec/h264_parse.c  | 7 ---
>  libavcodec/h264_parse.h  | 2 +-
>  libavcodec/h264_parser.c | 2 +-
>  libavcodec/h264_slice.c  | 2 +-
>  4 files changed, 7 insertions(+), 6 deletions(-)
> 
> diff --git a/libavcodec/h264_parse.c b/libavcodec/h264_parse.c
> index 1c1d1c04b0..5d642c7201 100644
> --- a/libavcodec/h264_parse.c
> +++ b/libavcodec/h264_parse.c
> @@ -275,9 +275,10 @@ fail:
>  }
>  
>  int ff_h264_init_poc(int pic_field_poc[2], int *pic_poc,
> - const SPS *sps, H264POCContext *pc,
> + const PPS *pps, H264POCContext *pc,
>   int picture_structure, int nal_ref_idc)
>  {
> +const SPS *sps = pps->sps;
>  const int max_frame_num = 1 << sps->log2_max_frame_num;
>  int64_t field_poc[2];
>  
> @@ -300,7 +301,7 @@ int ff_h264_init_poc(int pic_field_poc[2], int *pic_poc,
>  pc->poc_msb = pc->prev_poc_msb;
>  field_poc[0] =
>  field_poc[1] = pc->poc_msb + pc->poc_lsb;
> -if (picture_structure == PICT_FRAME)
> +if (pps->pic_order_present && picture_structure == PICT_FRAME)
>  field_poc[1] += pc->delta_poc_bottom;
>  } else if (sps->poc_type == 1) {
>  int abs_frame_num;
> @@ -336,7 +337,7 @@ int ff_h264_init_poc(int pic_field_poc[2], int *pic_poc,
>  field_poc[0] = expectedpoc + pc->delta_poc[0];
>  field_poc[1] = field_poc[0] + sps->offset_for_top_to_bottom_field;
>  
> -if (picture_structure == PICT_FRAME)
> +if (pps->pic_order_present && picture_structure == PICT_FRAME)
>  field_poc[1] += pc->delta_poc[1];

delta_pic_order_cnt_bottom and both delta_pic_order_cnt elements are
supposed to be inferred to zero when they are not present. If this were
done, the above additions wouldn't make a difference. I thought that
ce4a31cd1ff0348d279af74d49556d0315171e94 actually did exactly that,
which makes me not understand the current patch.

>  } else {
>  int poc = 2 * (pc->frame_num_offset + pc->frame_num);
> diff --git a/libavcodec/h264_parse.h b/libavcodec/h264_parse.h
> index 4d01620125..35c4810f34 100644
> --- a/libavcodec/h264_parse.h
> +++ b/libavcodec/h264_parse.h
> @@ -78,7 +78,7 @@ int ff_h264_parse_ref_count(int *plist_count, int 
> ref_count[2],
>  int slice_type_nos, int picture_structure, void 
> *logctx);
>  
>  int ff_h264_init_poc(int pic_field_poc[2], int *pic_poc,
> - const SPS *sps, H264POCContext *poc,
> + const PPS *pps, H264POCContext *poc,
>   int picture_structure, int nal_ref_idc);
>  
>  int ff_h264_decode_extradata(const uint8_t *data, int size, H264ParamSets 
> *ps,
> diff --git a/libavcodec/h264_parser.c b/libavcodec/h264_parser.c
> index d3c56cc188..6e2e7cde67 100644
> --- a/libavcodec/h264_parser.c
> +++ b/libavcodec/h264_parser.c
> @@ -440,7 +440,7 @@ static inline int parse_nal_units(AVCodecParserContext *s,
>  /* Decode POC of this picture.
>   * The prev_ values needed for decoding POC of the next picture 
> are not set here. */
>  field_poc[0] = field_poc[1] = INT_MAX;
> -ret = ff_h264_init_poc(field_poc, >output_picture_number, sps,
> +ret = ff_h264_init_poc(field_poc, >output_picture_number, 
> p->ps.pps,
>   >poc, p->picture_structure, nal.ref_idc);
>  if (ret < 0)
>  goto fail;
> diff --git a/libavcodec/h264_slice.c b/libavcodec/h264_slice.c
> index 0d7107d455..223cf21267 100644
> --- a/libavcodec/h264_slice.c
> +++ b/libavcodec/h264_slice.c
> @@ -1742,7 +1742,7 @@ static int h264_field_start(H264Context *h, const 
> H264SliceContext *sl,
>  }
>  
>  ret = ff_h264_init_poc(h->cur_pic_ptr->field_poc, >cur_pic_ptr->poc,
> - h->ps.sps, >poc, h->picture_structure, nal->ref_idc);
> +   h->ps.pps, >poc, h->picture_structure, 
> nal->ref_idc);
>  if (ret < 0)
>  return ret;
>  
> 

___
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 23/23] avfilter: Remove init_opaque callback

2021-08-11 Thread Andreas Rheinhardt 
The last init_opaque callback has been removed in commit
07ffdedf784e86b88074d8d3e08e55752869562a; the opaque argument has been
always NULL since 0acf7e268b2f873379cd854b4d5aaba6f9c1f0b5.

Signed-off-by: Andreas Rheinhardt 
---
 libavfilter/avfilter.c | 4 +---
 libavfilter/avfilter.h | 7 ---
 2 files changed, 1 insertion(+), 10 deletions(-)

diff --git a/libavfilter/avfilter.c b/libavfilter/avfilter.c
index 9ac247c251..385720df82 100644
--- a/libavfilter/avfilter.c
+++ b/libavfilter/avfilter.c
@@ -914,9 +914,7 @@ int avfilter_init_dict(AVFilterContext *ctx, AVDictionary 
**options)
 }
 }
 
-if (ctx->filter->init_opaque)
-ret = ctx->filter->init_opaque(ctx, NULL);
-else if (ctx->filter->init)
+if (ctx->filter->init)
 ret = ctx->filter->init(ctx);
 else if (ctx->filter->init_dict)
 ret = ctx->filter->init_dict(ctx, options);
diff --git a/libavfilter/avfilter.h b/libavfilter/avfilter.h
index 360f63bc45..5a225ffc44 100644
--- a/libavfilter/avfilter.h
+++ b/libavfilter/avfilter.h
@@ -300,13 +300,6 @@ typedef struct AVFilter {
  */
 int (*process_command)(AVFilterContext *, const char *cmd, const char 
*arg, char *res, int res_len, int flags);
 
-/**
- * Filter initialization function, alternative to the init()
- * callback. Args contains the user-supplied parameters, opaque is
- * used for providing binary data.
- */
-int (*init_opaque)(AVFilterContext *ctx, void *opaque);
-
 /**
  * Filter activation function.
  *
-- 
2.30.2

___
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 22/23] avfilter/vf_xmedian: Free inpads' names generically

2021-08-11 Thread Andreas Rheinhardt 
This affects only the xmedian filter, not tmedian.

Signed-off-by: Andreas Rheinhardt 
---
 libavfilter/vf_xmedian.c | 7 ++-
 1 file changed, 2 insertions(+), 5 deletions(-)

diff --git a/libavfilter/vf_xmedian.c b/libavfilter/vf_xmedian.c
index 168a5944db..c01f9ff202 100644
--- a/libavfilter/vf_xmedian.c
+++ b/libavfilter/vf_xmedian.c
@@ -121,10 +121,8 @@ static av_cold int init(AVFilterContext *ctx)
 if (!pad.name)
 return AVERROR(ENOMEM);
 
-if ((ret = ff_insert_inpad(ctx, i, )) < 0) {
-av_freep();
+if ((ret = ff_insert_inpad(ctx, i, )) < 0)
 return ret;
-}
 }
 
 return 0;
@@ -337,8 +335,6 @@ static av_cold void uninit(AVFilterContext *ctx)
 
 ff_framesync_uninit(>fs);
 
-for (int i = 0; i < ctx->nb_inputs && !s->tmedian; i++)
-av_freep(>input_pads[i].name);
 for (int i = 0; i < s->nb_frames && s->frames && s->tmedian; i++)
 av_frame_free(>frames[i]);
 av_freep(>frames);
@@ -404,6 +400,7 @@ const AVFilter ff_vf_xmedian = {
 .activate  = activate,
 .flags = AVFILTER_FLAG_DYNAMIC_INPUTS | 
AVFILTER_FLAG_SLICE_THREADS |
  AVFILTER_FLAG_SUPPORT_TIMELINE_INTERNAL,
+.flags_internal  = FF_FILTER_FLAG_FREE_INPADS,
 .process_command = process_command,
 };
 
-- 
2.30.2

___
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 21/23] avfilter/vf_stack: Free inpads' names generically

2021-08-11 Thread Andreas Rheinhardt 
Signed-off-by: Andreas Rheinhardt 
---
 libavfilter/vf_stack.c | 11 ---
 1 file changed, 4 insertions(+), 7 deletions(-)

diff --git a/libavfilter/vf_stack.c b/libavfilter/vf_stack.c
index 3368e25c9c..33cef09a91 100644
--- a/libavfilter/vf_stack.c
+++ b/libavfilter/vf_stack.c
@@ -123,10 +123,8 @@ static av_cold int init(AVFilterContext *ctx)
 if (!pad.name)
 return AVERROR(ENOMEM);
 
-if ((ret = ff_insert_inpad(ctx, i, )) < 0) {
-av_freep();
+if ((ret = ff_insert_inpad(ctx, i, )) < 0)
 return ret;
-}
 }
 
 return 0;
@@ -371,14 +369,10 @@ static int config_output(AVFilterLink *outlink)
 static av_cold void uninit(AVFilterContext *ctx)
 {
 StackContext *s = ctx->priv;
-int i;
 
 ff_framesync_uninit(>fs);
 av_freep(>frames);
 av_freep(>items);
-
-for (i = 0; i < ctx->nb_inputs; i++)
-av_freep(>input_pads[i].name);
 }
 
 static int activate(AVFilterContext *ctx)
@@ -420,6 +414,7 @@ const AVFilter ff_vf_hstack = {
 .uninit= uninit,
 .activate  = activate,
 .flags = AVFILTER_FLAG_DYNAMIC_INPUTS | 
AVFILTER_FLAG_SLICE_THREADS,
+.flags_internal = FF_FILTER_FLAG_FREE_INPADS,
 };
 
 #endif /* CONFIG_HSTACK_FILTER */
@@ -440,6 +435,7 @@ const AVFilter ff_vf_vstack = {
 .uninit= uninit,
 .activate  = activate,
 .flags = AVFILTER_FLAG_DYNAMIC_INPUTS | 
AVFILTER_FLAG_SLICE_THREADS,
+.flags_internal = FF_FILTER_FLAG_FREE_INPADS,
 };
 
 #endif /* CONFIG_VSTACK_FILTER */
@@ -467,6 +463,7 @@ const AVFilter ff_vf_xstack = {
 .uninit= uninit,
 .activate  = activate,
 .flags = AVFILTER_FLAG_DYNAMIC_INPUTS | 
AVFILTER_FLAG_SLICE_THREADS,
+.flags_internal = FF_FILTER_FLAG_FREE_INPADS,
 };
 
 #endif /* CONFIG_XSTACK_FILTER */
-- 
2.30.2

___
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 20/23] avfilter/vf_signature: Free inpads' names generically

2021-08-11 Thread Andreas Rheinhardt 
Signed-off-by: Andreas Rheinhardt 
---
 libavfilter/vf_signature.c | 7 ++-
 1 file changed, 2 insertions(+), 5 deletions(-)

diff --git a/libavfilter/vf_signature.c b/libavfilter/vf_signature.c
index a345ad6ebd..3f4b17b555 100644
--- a/libavfilter/vf_signature.c
+++ b/libavfilter/vf_signature.c
@@ -664,10 +664,8 @@ static av_cold int init(AVFilterContext *ctx)
 
 if (!pad.name)
 return AVERROR(ENOMEM);
-if ((ret = ff_insert_inpad(ctx, i, )) < 0) {
-av_freep();
+if ((ret = ff_insert_inpad(ctx, i, )) < 0)
 return ret;
-}
 
 sc = &(sic->streamcontexts[i]);
 
@@ -730,8 +728,6 @@ static av_cold void uninit(AVFilterContext *ctx)
 }
 av_freep(>streamcontexts);
 }
-for (unsigned i = 0; i < ctx->nb_inputs; i++)
-av_freep(>input_pads[i].name);
 }
 
 static int config_output(AVFilterLink *outlink)
@@ -769,4 +765,5 @@ const AVFilter ff_vf_signature = {
 .outputs   = signature_outputs,
 .inputs= NULL,
 .flags = AVFILTER_FLAG_DYNAMIC_INPUTS,
+.flags_internal = FF_FILTER_FLAG_FREE_INPADS,
 };
-- 
2.30.2

___
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 19/23] avfilter/vf_program_opencl: Free inpads' names generically

2021-08-11 Thread Andreas Rheinhardt 
Only ff_vf_program_opencl is affected by this: ff_vsrc_openclsrc
as a source filter doesn't have any inputs and the code where inpads
are inserted is unreachable for it.

Signed-off-by: Andreas Rheinhardt 
---
 libavfilter/vf_program_opencl.c | 9 ++---
 1 file changed, 2 insertions(+), 7 deletions(-)

diff --git a/libavfilter/vf_program_opencl.c b/libavfilter/vf_program_opencl.c
index 5f455e9afa..c4f4acb919 100644
--- a/libavfilter/vf_program_opencl.c
+++ b/libavfilter/vf_program_opencl.c
@@ -288,10 +288,8 @@ static av_cold int program_opencl_init(AVFilterContext 
*avctx)
 input.config_props = _opencl_filter_config_input;
 
 err = ff_insert_inpad(avctx, i, );
-if (err < 0) {
-av_freep();
+if (err < 0)
 return err;
-}
 }
 }
 
@@ -302,14 +300,11 @@ static av_cold void program_opencl_uninit(AVFilterContext 
*avctx)
 {
 ProgramOpenCLContext *ctx = avctx->priv;
 cl_int cle;
-int i;
 
 if (ctx->nb_inputs > 0) {
 ff_framesync_uninit(>fs);
 
 av_freep(>frames);
-for (i = 0; i < avctx->nb_inputs; i++)
-av_freep(>input_pads[i].name);
 }
 
 if (ctx->kernel) {
@@ -375,7 +370,7 @@ const AVFilter ff_vf_program_opencl = {
 .activate   = _opencl_activate,
 .inputs = NULL,
 .outputs= program_opencl_outputs,
-.flags_internal = FF_FILTER_FLAG_HWFRAME_AWARE,
+.flags_internal = FF_FILTER_FLAG_HWFRAME_AWARE | 
FF_FILTER_FLAG_FREE_INPADS,
 };
 
 #endif
-- 
2.30.2

___
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 18/23] avfilter/vf_mix: Free inpads' names generically

2021-08-11 Thread Andreas Rheinhardt 
Signed-off-by: Andreas Rheinhardt 
---
 libavfilter/vf_mix.c | 10 +++---
 1 file changed, 3 insertions(+), 7 deletions(-)

diff --git a/libavfilter/vf_mix.c b/libavfilter/vf_mix.c
index 0ca60d5522..9f1400e729 100644
--- a/libavfilter/vf_mix.c
+++ b/libavfilter/vf_mix.c
@@ -125,10 +125,8 @@ static av_cold int init(AVFilterContext *ctx)
 if (!pad.name)
 return AVERROR(ENOMEM);
 
-if ((ret = ff_insert_inpad(ctx, i, )) < 0) {
-av_freep();
+if ((ret = ff_insert_inpad(ctx, i, )) < 0)
 return ret;
-}
 }
 }
 
@@ -303,10 +301,7 @@ static av_cold void uninit(AVFilterContext *ctx)
 ff_framesync_uninit(>fs);
 av_freep(>weights);
 
-if (!s->tmix) {
-for (i = 0; i < ctx->nb_inputs; i++)
-av_freep(>input_pads[i].name);
-} else {
+if (s->tmix) {
 for (i = 0; i < s->nb_frames && s->frames; i++)
 av_frame_free(>frames[i]);
 }
@@ -370,6 +365,7 @@ const AVFilter ff_vf_mix = {
 .activate  = activate,
 .flags = AVFILTER_FLAG_DYNAMIC_INPUTS | 
AVFILTER_FLAG_SLICE_THREADS |
  AVFILTER_FLAG_SUPPORT_TIMELINE_INTERNAL,
+.flags_internal = FF_FILTER_FLAG_FREE_INPADS,
 .process_command = process_command,
 };
 
-- 
2.30.2

___
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 17/23] avfilter/vf_mergeplanes: Free inpads' names generically

2021-08-11 Thread Andreas Rheinhardt 
Signed-off-by: Andreas Rheinhardt 
---
 libavfilter/vf_mergeplanes.c | 9 ++---
 1 file changed, 2 insertions(+), 7 deletions(-)

diff --git a/libavfilter/vf_mergeplanes.c b/libavfilter/vf_mergeplanes.c
index 30888f62af..633421e37d 100644
--- a/libavfilter/vf_mergeplanes.c
+++ b/libavfilter/vf_mergeplanes.c
@@ -96,10 +96,8 @@ static av_cold int init(AVFilterContext *ctx)
 if (!pad.name)
 return AVERROR(ENOMEM);
 
-if ((ret = ff_insert_inpad(ctx, i, )) < 0){
-av_freep();
+if ((ret = ff_insert_inpad(ctx, i, )) < 0)
 return ret;
-}
 }
 
 return 0;
@@ -279,12 +277,8 @@ static int activate(AVFilterContext *ctx)
 static av_cold void uninit(AVFilterContext *ctx)
 {
 MergePlanesContext *s = ctx->priv;
-int i;
 
 ff_framesync_uninit(>fs);
-
-for (i = 0; i < ctx->nb_inputs; i++)
-av_freep(>input_pads[i].name);
 }
 
 static const AVFilterPad mergeplanes_outputs[] = {
@@ -308,4 +302,5 @@ const AVFilter ff_vf_mergeplanes = {
 .inputs= NULL,
 .outputs   = mergeplanes_outputs,
 .flags = AVFILTER_FLAG_DYNAMIC_INPUTS,
+.flags_internal = FF_FILTER_FLAG_FREE_INPADS,
 };
-- 
2.30.2

___
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 16/23] avfilter/vf_extractplanes: Free outpads' names generically

2021-08-11 Thread Andreas Rheinhardt 
Signed-off-by: Andreas Rheinhardt 
---
 libavfilter/vf_extractplanes.c | 16 +++-
 1 file changed, 3 insertions(+), 13 deletions(-)

diff --git a/libavfilter/vf_extractplanes.c b/libavfilter/vf_extractplanes.c
index cede3d669e..52602965ac 100644
--- a/libavfilter/vf_extractplanes.c
+++ b/libavfilter/vf_extractplanes.c
@@ -352,23 +352,13 @@ static av_cold int init(AVFilterContext *ctx)
 pad.type = AVMEDIA_TYPE_VIDEO;
 pad.config_props = config_output;
 
-if ((ret = ff_insert_outpad(ctx, ctx->nb_outputs, )) < 0) {
-av_freep();
+if ((ret = ff_insert_outpad(ctx, ctx->nb_outputs, )) < 0)
 return ret;
-}
 }
 
 return 0;
 }
 
-static av_cold void uninit(AVFilterContext *ctx)
-{
-int i;
-
-for (i = 0; i < ctx->nb_outputs; i++)
-av_freep(>output_pads[i].name);
-}
-
 static const AVFilterPad extractplanes_inputs[] = {
 {
 .name = "default",
@@ -385,11 +375,11 @@ const AVFilter ff_vf_extractplanes = {
 .priv_size = sizeof(ExtractPlanesContext),
 .priv_class= _class,
 .init  = init,
-.uninit= uninit,
 .query_formats = query_formats,
 .inputs= extractplanes_inputs,
 .outputs   = NULL,
 .flags = AVFILTER_FLAG_DYNAMIC_OUTPUTS,
+.flags_internal = FF_FILTER_FLAG_FREE_OUTPADS,
 };
 
 #if CONFIG_ALPHAEXTRACT_FILTER
@@ -409,10 +399,10 @@ const AVFilter ff_vf_alphaextract = {
   "grayscale image component."),
 .priv_size  = sizeof(ExtractPlanesContext),
 .init   = init_alphaextract,
-.uninit = uninit,
 .query_formats  = query_formats,
 .inputs = extractplanes_inputs,
 .outputs= NULL,
 .flags  = AVFILTER_FLAG_DYNAMIC_OUTPUTS,
+.flags_internal = FF_FILTER_FLAG_FREE_OUTPADS,
 };
 #endif  /* CONFIG_ALPHAEXTRACT_FILTER */
-- 
2.30.2

___
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 15/23] avfilter/src_movie: Free outpads' names generically

2021-08-11 Thread Andreas Rheinhardt 
Signed-off-by: Andreas Rheinhardt 
---
 libavfilter/src_movie.c | 7 +++
 1 file changed, 3 insertions(+), 4 deletions(-)

diff --git a/libavfilter/src_movie.c b/libavfilter/src_movie.c
index 7d97295dd0..947aa8c90f 100644
--- a/libavfilter/src_movie.c
+++ b/libavfilter/src_movie.c
@@ -306,10 +306,8 @@ static av_cold int movie_common_init(AVFilterContext *ctx)
 return AVERROR(ENOMEM);
 pad.config_props  = movie_config_output_props;
 pad.request_frame = movie_request_frame;
-if ((ret = ff_insert_outpad(ctx, i, )) < 0) {
-av_freep();
+if ((ret = ff_insert_outpad(ctx, i, )) < 0)
 return ret;
-}
 if ( movie->st[i].st->codecpar->codec_type == AVMEDIA_TYPE_AUDIO &&
 !movie->st[i].st->codecpar->channel_layout) {
 ret = guess_channel_layout(>st[i], i, ctx);
@@ -334,7 +332,6 @@ static av_cold void movie_uninit(AVFilterContext *ctx)
 int i;
 
 for (i = 0; i < ctx->nb_outputs; i++) {
-av_freep(>output_pads[i].name);
 if (movie->st[i].st)
 avcodec_free_context(>st[i].codec_ctx);
 }
@@ -649,6 +646,7 @@ const AVFilter ff_avsrc_movie = {
 .inputs= NULL,
 .outputs   = NULL,
 .flags = AVFILTER_FLAG_DYNAMIC_OUTPUTS,
+.flags_internal  = FF_FILTER_FLAG_FREE_OUTPADS,
 .process_command = process_command
 };
 
@@ -671,6 +669,7 @@ const AVFilter ff_avsrc_amovie = {
 .outputs= NULL,
 .priv_class = _class,
 .flags  = AVFILTER_FLAG_DYNAMIC_OUTPUTS,
+.flags_internal  = FF_FILTER_FLAG_FREE_OUTPADS,
 .process_command = process_command,
 };
 
-- 
2.30.2

___
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 14/23] avfilter/split: Free outpads' names generically

2021-08-11 Thread Andreas Rheinhardt 
Signed-off-by: Andreas Rheinhardt 
---
 libavfilter/split.c | 16 +++-
 1 file changed, 3 insertions(+), 13 deletions(-)

diff --git a/libavfilter/split.c b/libavfilter/split.c
index da5f681af8..b14f6798e9 100644
--- a/libavfilter/split.c
+++ b/libavfilter/split.c
@@ -56,23 +56,13 @@ static av_cold int split_init(AVFilterContext *ctx)
 if (!pad.name)
 return AVERROR(ENOMEM);
 
-if ((ret = ff_insert_outpad(ctx, i, )) < 0) {
-av_freep();
+if ((ret = ff_insert_outpad(ctx, i, )) < 0)
 return ret;
-}
 }
 
 return 0;
 }
 
-static av_cold void split_uninit(AVFilterContext *ctx)
-{
-int i;
-
-for (i = 0; i < ctx->nb_outputs; i++)
-av_freep(>output_pads[i].name);
-}
-
 static int filter_frame(AVFilterLink *inlink, AVFrame *frame)
 {
 AVFilterContext *ctx = inlink->dst;
@@ -125,10 +115,10 @@ const AVFilter ff_vf_split = {
 .priv_size   = sizeof(SplitContext),
 .priv_class  = _class,
 .init= split_init,
-.uninit  = split_uninit,
 .inputs  = avfilter_vf_split_inputs,
 .outputs = NULL,
 .flags   = AVFILTER_FLAG_DYNAMIC_OUTPUTS,
+.flags_internal = FF_FILTER_FLAG_FREE_OUTPADS,
 };
 
 static const AVFilterPad avfilter_af_asplit_inputs[] = {
@@ -146,8 +136,8 @@ const AVFilter ff_af_asplit = {
 .priv_size   = sizeof(SplitContext),
 .priv_class  = _class,
 .init= split_init,
-.uninit  = split_uninit,
 .inputs  = avfilter_af_asplit_inputs,
 .outputs = NULL,
 .flags   = AVFILTER_FLAG_DYNAMIC_OUTPUTS,
+.flags_internal = FF_FILTER_FLAG_FREE_OUTPADS,
 };
-- 
2.30.2

___
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 13/23] avfilter/f_streamselect: Free pads' names generically

2021-08-11 Thread Andreas Rheinhardt 
Signed-off-by: Andreas Rheinhardt 
---
 libavfilter/f_streamselect.c | 13 +++--
 1 file changed, 3 insertions(+), 10 deletions(-)

diff --git a/libavfilter/f_streamselect.c b/libavfilter/f_streamselect.c
index 22eb76d4d7..7762cdb3d1 100644
--- a/libavfilter/f_streamselect.c
+++ b/libavfilter/f_streamselect.c
@@ -172,11 +172,8 @@ static int parse_definition(AVFilterContext *ctx, int 
nb_pads, int is_input, int
 pad.config_props  = config_output;
 ret = ff_insert_outpad(ctx, i, );
 }
-
-if (ret < 0) {
-av_freep();
+if (ret < 0)
 return ret;
-}
 }
 
 return 0;
@@ -295,12 +292,6 @@ static av_cold void uninit(AVFilterContext *ctx)
 av_freep(>map);
 av_freep(>frames);
 ff_framesync_uninit(>fs);
-
-for (int i = 0; i < ctx->nb_inputs; i++)
-av_freep(>input_pads[i].name);
-
-for (int i = 0; i < ctx->nb_outputs; i++)
-av_freep(>output_pads[i].name);
 }
 
 static int query_formats(AVFilterContext *ctx)
@@ -338,6 +329,7 @@ const AVFilter ff_vf_streamselect = {
 .priv_size   = sizeof(StreamSelectContext),
 .priv_class  = _class,
 .flags   = AVFILTER_FLAG_DYNAMIC_INPUTS | 
AVFILTER_FLAG_DYNAMIC_OUTPUTS,
+.flags_internal  = FF_FILTER_FLAG_FREE_OUTPADS | 
FF_FILTER_FLAG_FREE_INPADS,
 };
 
 #define astreamselect_options streamselect_options
@@ -354,4 +346,5 @@ const AVFilter ff_af_astreamselect = {
 .priv_size   = sizeof(StreamSelectContext),
 .priv_class  = _class,
 .flags   = AVFILTER_FLAG_DYNAMIC_INPUTS | 
AVFILTER_FLAG_DYNAMIC_OUTPUTS,
+.flags_internal  = FF_FILTER_FLAG_FREE_OUTPADS | 
FF_FILTER_FLAG_FREE_INPADS,
 };
-- 
2.30.2

___
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 12/23] avfilter/f_select: Free outpads' names generically

2021-08-11 Thread Andreas Rheinhardt 
Signed-off-by: Andreas Rheinhardt 
---
 libavfilter/f_select.c | 10 +++---
 1 file changed, 3 insertions(+), 7 deletions(-)

diff --git a/libavfilter/f_select.c b/libavfilter/f_select.c
index f0468078e8..0538ee347d 100644
--- a/libavfilter/f_select.c
+++ b/libavfilter/f_select.c
@@ -192,10 +192,8 @@ static av_cold int init(AVFilterContext *ctx)
 return AVERROR(ENOMEM);
 pad.type = ctx->filter->inputs[0].type;
 pad.request_frame = request_frame;
-if ((ret = ff_insert_outpad(ctx, i, )) < 0) {
-av_freep();
+if ((ret = ff_insert_outpad(ctx, i, )) < 0)
 return ret;
-}
 }
 
 return 0;
@@ -432,14 +430,10 @@ static int request_frame(AVFilterLink *outlink)
 static av_cold void uninit(AVFilterContext *ctx)
 {
 SelectContext *select = ctx->priv;
-int i;
 
 av_expr_free(select->expr);
 select->expr = NULL;
 
-for (i = 0; i < ctx->nb_outputs; i++)
-av_freep(>output_pads[i].name);
-
 if (select->do_scene_detect) {
 av_frame_free(>prev_picref);
 }
@@ -485,6 +479,7 @@ const AVFilter ff_af_aselect = {
 .inputs  = avfilter_af_aselect_inputs,
 .priv_class  = _class,
 .flags   = AVFILTER_FLAG_DYNAMIC_OUTPUTS,
+.flags_internal = FF_FILTER_FLAG_FREE_OUTPADS,
 };
 #endif /* CONFIG_ASELECT_FILTER */
 
@@ -550,5 +545,6 @@ const AVFilter ff_vf_select = {
 .priv_class= _class,
 .inputs= avfilter_vf_select_inputs,
 .flags = AVFILTER_FLAG_DYNAMIC_OUTPUTS,
+.flags_internal = FF_FILTER_FLAG_FREE_OUTPADS,
 };
 #endif /* CONFIG_SELECT_FILTER */
-- 
2.30.2

___
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 04/23] avfilter/af_acrossover: Free outpads' names generically

2021-08-11 Thread Andreas Rheinhardt 
Signed-off-by: Andreas Rheinhardt 
---
 libavfilter/af_acrossover.c | 9 ++---
 1 file changed, 2 insertions(+), 7 deletions(-)

diff --git a/libavfilter/af_acrossover.c b/libavfilter/af_acrossover.c
index 3ba67b30e1..c99c7de1f7 100644
--- a/libavfilter/af_acrossover.c
+++ b/libavfilter/af_acrossover.c
@@ -191,10 +191,8 @@ static av_cold int init(AVFilterContext *ctx)
 return AVERROR(ENOMEM);
 pad.name = name;
 
-if ((ret = ff_insert_outpad(ctx, i, )) < 0) {
-av_freep();
+if ((ret = ff_insert_outpad(ctx, i, )) < 0)
 return ret;
-}
 }
 
 return ret;
@@ -550,13 +548,9 @@ fail:
 static av_cold void uninit(AVFilterContext *ctx)
 {
 AudioCrossoverContext *s = ctx->priv;
-int i;
 
 av_freep(>fdsp);
 av_frame_free(>xover);
-
-for (i = 0; i < ctx->nb_outputs; i++)
-av_freep(>output_pads[i].name);
 }
 
 static const AVFilterPad inputs[] = {
@@ -581,4 +575,5 @@ const AVFilter ff_af_acrossover = {
 .outputs= NULL,
 .flags  = AVFILTER_FLAG_DYNAMIC_OUTPUTS |
   AVFILTER_FLAG_SLICE_THREADS,
+.flags_internal = FF_FILTER_FLAG_FREE_OUTPADS,
 };
-- 
2.30.2

___
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 11/23] avfilter/f_interleave: Free inpads' names generically

2021-08-11 Thread Andreas Rheinhardt 
Signed-off-by: Andreas Rheinhardt 
---
 libavfilter/f_interleave.c | 14 +++---
 1 file changed, 3 insertions(+), 11 deletions(-)

diff --git a/libavfilter/f_interleave.c b/libavfilter/f_interleave.c
index 259952b591..b2c0305797 100644
--- a/libavfilter/f_interleave.c
+++ b/libavfilter/f_interleave.c
@@ -173,21 +173,13 @@ static av_cold int init(AVFilterContext *ctx)
 default:
 av_assert0(0);
 }
-if ((ret = ff_insert_inpad(ctx, i, )) < 0) {
-av_freep();
+if ((ret = ff_insert_inpad(ctx, i, )) < 0)
 return ret;
-}
 }
 
 return 0;
 }
 
-static av_cold void uninit(AVFilterContext *ctx)
-{
-for (int i = 0; i < ctx->nb_inputs; i++)
-av_freep(>input_pads[i].name);
-}
-
 static int config_output(AVFilterLink *outlink)
 {
 AVFilterContext *ctx = outlink->src;
@@ -243,11 +235,11 @@ const AVFilter ff_vf_interleave = {
 .description = NULL_IF_CONFIG_SMALL("Temporally interleave video inputs."),
 .priv_size   = sizeof(InterleaveContext),
 .init= init,
-.uninit  = uninit,
 .activate= activate,
 .outputs = interleave_outputs,
 .priv_class  = _class,
 .flags   = AVFILTER_FLAG_DYNAMIC_INPUTS,
+.flags_internal = FF_FILTER_FLAG_FREE_INPADS,
 };
 
 #endif
@@ -271,11 +263,11 @@ const AVFilter ff_af_ainterleave = {
 .description = NULL_IF_CONFIG_SMALL("Temporally interleave audio inputs."),
 .priv_size   = sizeof(InterleaveContext),
 .init= init,
-.uninit  = uninit,
 .activate= activate,
 .outputs = ainterleave_outputs,
 .priv_class  = _class,
 .flags   = AVFILTER_FLAG_DYNAMIC_INPUTS,
+.flags_internal = FF_FILTER_FLAG_FREE_INPADS,
 };
 
 #endif
-- 
2.30.2

___
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 10/23] avfilter/avf_concat: Free pads' names generically

2021-08-11 Thread Andreas Rheinhardt 
Signed-off-by: Andreas Rheinhardt 
---
 libavfilter/avf_concat.c | 14 +++---
 1 file changed, 3 insertions(+), 11 deletions(-)

diff --git a/libavfilter/avf_concat.c b/libavfilter/avf_concat.c
index 333a0b090c..0ff7cb20b0 100644
--- a/libavfilter/avf_concat.c
+++ b/libavfilter/avf_concat.c
@@ -317,10 +317,8 @@ static av_cold int init(AVFilterContext *ctx)
 .get_audio_buffer = get_audio_buffer,
 };
 pad.name = av_asprintf("in%d:%c%d", seg, "va"[type], str);
-if ((ret = ff_insert_inpad(ctx, ctx->nb_inputs, )) < 0) {
-av_freep();
+if ((ret = ff_insert_inpad(ctx, ctx->nb_inputs, )) < 0)
 return ret;
-}
 }
 }
 }
@@ -332,10 +330,8 @@ static av_cold int init(AVFilterContext *ctx)
 .config_props  = config_output,
 };
 pad.name = av_asprintf("out:%c%d", "va"[type], str);
-if ((ret = ff_insert_outpad(ctx, ctx->nb_outputs, )) < 0) {
-av_freep();
+if ((ret = ff_insert_outpad(ctx, ctx->nb_outputs, )) < 0)
 return ret;
-}
 }
 }
 
@@ -349,12 +345,7 @@ static av_cold int init(AVFilterContext *ctx)
 static av_cold void uninit(AVFilterContext *ctx)
 {
 ConcatContext *cat = ctx->priv;
-unsigned i;
 
-for (i = 0; i < ctx->nb_inputs; i++)
-av_freep(>input_pads[i].name);
-for (i = 0; i < ctx->nb_outputs; i++)
-av_freep(>output_pads[i].name);
 av_freep(>in);
 }
 
@@ -463,5 +454,6 @@ const AVFilter ff_avf_concat = {
 .outputs   = NULL,
 .priv_class= _class,
 .flags = AVFILTER_FLAG_DYNAMIC_INPUTS | 
AVFILTER_FLAG_DYNAMIC_OUTPUTS,
+.flags_internal = FF_FILTER_FLAG_FREE_INPADS | FF_FILTER_FLAG_FREE_OUTPADS,
 .process_command = process_command,
 };
-- 
2.30.2

___
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 09/23] avfilter/af_lv2: Free inpads' names generically

2021-08-11 Thread Andreas Rheinhardt 
Signed-off-by: Andreas Rheinhardt 
---
 libavfilter/af_lv2.c | 12 
 1 file changed, 4 insertions(+), 8 deletions(-)

diff --git a/libavfilter/af_lv2.c b/libavfilter/af_lv2.c
index 28b729691d..d97367ca99 100644
--- a/libavfilter/af_lv2.c
+++ b/libavfilter/af_lv2.c
@@ -393,7 +393,7 @@ static av_cold int init(AVFilterContext *ctx)
 const LilvPlugin *plugin;
 AVFilterPad pad = { NULL };
 LilvNode *uri;
-int i;
+int i, ret;
 
 s->world = lilv_world_new();
 if (!s->world)
@@ -464,10 +464,8 @@ static av_cold int init(AVFilterContext *ctx)
 return AVERROR(ENOMEM);
 
 pad.filter_frame = filter_frame;
-if (ff_insert_inpad(ctx, ctx->nb_inputs, ) < 0) {
-av_freep();
-return AVERROR(ENOMEM);
-}
+if ((ret = ff_insert_inpad(ctx, ctx->nb_inputs, )) < 0)
+return ret;
 }
 
 return 0;
@@ -572,9 +570,6 @@ static av_cold void uninit(AVFilterContext *ctx)
 av_freep(>maxes);
 av_freep(>controls);
 av_freep(>seq_out);
-
-if (ctx->nb_inputs)
-av_freep(>input_pads[0].name);
 }
 
 static const AVFilterPad lv2_outputs[] = {
@@ -598,4 +593,5 @@ const AVFilter ff_af_lv2 = {
 .inputs= 0,
 .outputs   = lv2_outputs,
 .flags = AVFILTER_FLAG_DYNAMIC_INPUTS,
+.flags_internal = FF_FILTER_FLAG_FREE_INPADS,
 };
-- 
2.30.2

___
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 08/23] avfilter/af_ladspa: Free inpads' names generically

2021-08-11 Thread Andreas Rheinhardt 
Signed-off-by: Andreas Rheinhardt 
---
 libavfilter/af_ladspa.c | 12 
 1 file changed, 4 insertions(+), 8 deletions(-)

diff --git a/libavfilter/af_ladspa.c b/libavfilter/af_ladspa.c
index 4060251670..cbb8282988 100644
--- a/libavfilter/af_ladspa.c
+++ b/libavfilter/af_ladspa.c
@@ -456,7 +456,7 @@ static av_cold int init(AVFilterContext *ctx)
 AVFilterPad pad = { NULL };
 char *p, *arg, *saveptr = NULL;
 unsigned long nb_ports;
-int i, j = 0;
+int i, j = 0, ret;
 
 if (!s->dl_name) {
 av_log(ctx, AV_LOG_ERROR, "No plugin name provided\n");
@@ -639,10 +639,8 @@ static av_cold int init(AVFilterContext *ctx)
 
 pad.filter_frame = filter_frame;
 pad.config_props = config_input;
-if (ff_insert_inpad(ctx, ctx->nb_inputs, ) < 0) {
-av_freep();
-return AVERROR(ENOMEM);
-}
+if ((ret = ff_insert_inpad(ctx, ctx->nb_inputs, )) < 0)
+return ret;
 }
 
 av_log(ctx, AV_LOG_DEBUG, "ports: %lu\n", nb_ports);
@@ -764,9 +762,6 @@ static av_cold void uninit(AVFilterContext *ctx)
 av_freep(>octlv);
 av_freep(>handles);
 av_freep(>ctl_needs_value);
-
-if (ctx->nb_inputs)
-av_freep(>input_pads[0].name);
 }
 
 static int process_command(AVFilterContext *ctx, const char *cmd, const char 
*args,
@@ -803,4 +798,5 @@ const AVFilter ff_af_ladspa = {
 .inputs= 0,
 .outputs   = ladspa_outputs,
 .flags = AVFILTER_FLAG_DYNAMIC_INPUTS,
+.flags_internal = FF_FILTER_FLAG_FREE_INPADS,
 };
-- 
2.30.2

___
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 07/23] avfilter/af_join: Free inpads' names generically

2021-08-11 Thread Andreas Rheinhardt 
Signed-off-by: Andreas Rheinhardt 
---
 libavfilter/af_join.c | 9 ++---
 1 file changed, 2 insertions(+), 7 deletions(-)

diff --git a/libavfilter/af_join.c b/libavfilter/af_join.c
index 6a4b449021..1fb216f622 100644
--- a/libavfilter/af_join.c
+++ b/libavfilter/af_join.c
@@ -194,10 +194,8 @@ static av_cold int join_init(AVFilterContext *ctx)
 if (!pad.name)
 return AVERROR(ENOMEM);
 
-if ((ret = ff_insert_inpad(ctx, i, )) < 0) {
-av_freep();
+if ((ret = ff_insert_inpad(ctx, i, )) < 0)
 return ret;
-}
 }
 
 return 0;
@@ -212,10 +210,6 @@ static av_cold void join_uninit(AVFilterContext *ctx)
 av_frame_free(>input_frames[i]);
 }
 
-for (i = 0; i < ctx->nb_inputs; i++) {
-av_freep(>input_pads[i].name);
-}
-
 av_freep(>channels);
 av_freep(>buffers);
 av_freep(>input_frames);
@@ -552,4 +546,5 @@ const AVFilter ff_af_join = {
 .inputs = NULL,
 .outputs= avfilter_af_join_outputs,
 .flags  = AVFILTER_FLAG_DYNAMIC_INPUTS,
+.flags_internal = FF_FILTER_FLAG_FREE_INPADS,
 };
-- 
2.30.2

___
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 06/23] avfilter/af_amix: Free inpads' names generically

2021-08-11 Thread Andreas Rheinhardt 
Signed-off-by: Andreas Rheinhardt 
---
 libavfilter/af_amix.c | 8 ++--
 1 file changed, 2 insertions(+), 6 deletions(-)

diff --git a/libavfilter/af_amix.c b/libavfilter/af_amix.c
index 2296b49243..d5af72bafe 100644
--- a/libavfilter/af_amix.c
+++ b/libavfilter/af_amix.c
@@ -553,10 +553,8 @@ static av_cold int init(AVFilterContext *ctx)
 if (!pad.name)
 return AVERROR(ENOMEM);
 
-if ((ret = ff_insert_inpad(ctx, i, )) < 0) {
-av_freep();
+if ((ret = ff_insert_inpad(ctx, i, )) < 0)
 return ret;
-}
 }
 
 s->fdsp = avpriv_float_dsp_alloc(0);
@@ -589,9 +587,6 @@ static av_cold void uninit(AVFilterContext *ctx)
 av_freep(>scale_norm);
 av_freep(>weights);
 av_freep(>fdsp);
-
-for (i = 0; i < ctx->nb_inputs; i++)
-av_freep(>input_pads[i].name);
 }
 
 static int query_formats(AVFilterContext *ctx)
@@ -650,4 +645,5 @@ const AVFilter ff_af_amix = {
 .outputs= avfilter_af_amix_outputs,
 .process_command = process_command,
 .flags  = AVFILTER_FLAG_DYNAMIC_INPUTS,
+.flags_internal = FF_FILTER_FLAG_FREE_INPADS,
 };
-- 
2.30.2

___
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 05/23] avfilter/af_amerge: Free inpads' names generically

2021-08-11 Thread Andreas Rheinhardt 
Signed-off-by: Andreas Rheinhardt 
---
 libavfilter/af_amerge.c | 7 ++-
 1 file changed, 2 insertions(+), 5 deletions(-)

diff --git a/libavfilter/af_amerge.c b/libavfilter/af_amerge.c
index 2e45b7c277..1b7c6dd2f4 100644
--- a/libavfilter/af_amerge.c
+++ b/libavfilter/af_amerge.c
@@ -60,8 +60,6 @@ static av_cold void uninit(AVFilterContext *ctx)
 AMergeContext *s = ctx->priv;
 
 av_freep(>in);
-for (unsigned i = 0; i < ctx->nb_inputs; i++)
-av_freep(>input_pads[i].name);
 }
 
 static int query_formats(AVFilterContext *ctx)
@@ -330,10 +328,8 @@ static av_cold int init(AVFilterContext *ctx)
 };
 if (!name)
 return AVERROR(ENOMEM);
-if ((ret = ff_insert_inpad(ctx, i, )) < 0) {
-av_freep();
+if ((ret = ff_insert_inpad(ctx, i, )) < 0)
 return ret;
-}
 }
 return 0;
 }
@@ -360,4 +356,5 @@ const AVFilter ff_af_amerge = {
 .outputs   = amerge_outputs,
 .priv_class= _class,
 .flags = AVFILTER_FLAG_DYNAMIC_INPUTS,
+.flags_internal = FF_FILTER_FLAG_FREE_INPADS,
 };
-- 
2.30.2

___
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 03/23] avfilter/avfilter: Allow to free pads generically

2021-08-11 Thread Andreas Rheinhardt 
This can be enabled/disabled on a per-filter basis by setting
the new internal flags FF_FILTER_FLAG_FREE_(IN|OUT)PADS.

Signed-off-by: Andreas Rheinhardt 
---
It would be possible to only free the names of non-static pads;
it could then be used with the headphone and afir filters.
But I don't think the additional complexity is worth it.

 libavfilter/avfilter.c | 19 +++
 libavfilter/internal.h | 10 ++
 2 files changed, 25 insertions(+), 4 deletions(-)

diff --git a/libavfilter/avfilter.c b/libavfilter/avfilter.c
index de7501c37b..9ac247c251 100644
--- a/libavfilter/avfilter.c
+++ b/libavfilter/avfilter.c
@@ -117,7 +117,7 @@ void ff_command_queue_pop(AVFilterContext *filter)
  */
 static int insert_pad(unsigned idx, unsigned *count, size_t padidx_off,
   AVFilterPad **pads, AVFilterLink ***links,
-  AVFilterPad *newpad)
+  AVFilterPad *newpad, int free_on_failure)
 {
 AVFilterLink **newlinks;
 AVFilterPad *newpads;
@@ -131,8 +131,11 @@ static int insert_pad(unsigned idx, unsigned *count, 
size_t padidx_off,
 *pads  = newpads;
 if (newlinks)
 *links = newlinks;
-if (!newpads || !newlinks)
+if (!newpads || !newlinks) {
+if (free_on_failure)
+av_freep(>name);
 return AVERROR(ENOMEM);
+}
 
 memmove(*pads  + idx + 1, *pads  + idx, sizeof(AVFilterPad)   * (*count - 
idx));
 memmove(*links + idx + 1, *links + idx, sizeof(AVFilterLink*) * (*count - 
idx));
@@ -150,13 +153,15 @@ static int insert_pad(unsigned idx, unsigned *count, 
size_t padidx_off,
 int ff_insert_inpad(AVFilterContext *f, unsigned index, AVFilterPad *p)
 {
 return insert_pad(index, >nb_inputs, offsetof(AVFilterLink, dstpad),
-  >input_pads, >inputs, p);
+  >input_pads, >inputs, p,
+  f->filter->flags_internal & FF_FILTER_FLAG_FREE_INPADS);
 }
 
 int ff_insert_outpad(AVFilterContext *f, unsigned index, AVFilterPad *p)
 {
 return insert_pad(index, >nb_outputs, offsetof(AVFilterLink, srcpad),
-  >output_pads, >outputs, p);
+  >output_pads, >outputs, p,
+  f->filter->flags_internal & FF_FILTER_FLAG_FREE_OUTPADS);
 }
 
 int avfilter_link(AVFilterContext *src, unsigned srcpad,
@@ -767,7 +772,13 @@ void avfilter_free(AVFilterContext *filter)
 av_buffer_unref(>hw_device_ctx);
 
 av_freep(>name);
+if (filter->filter->flags_internal & FF_FILTER_FLAG_FREE_INPADS)
+for (unsigned i = 0; i < filter->nb_inputs; i++)
+av_freep(>input_pads[i].name);
 av_freep(>input_pads);
+if (filter->filter->flags_internal & FF_FILTER_FLAG_FREE_OUTPADS)
+for (unsigned i = 0; i < filter->nb_outputs; i++)
+av_freep(>output_pads[i].name);
 av_freep(>output_pads);
 av_freep(>inputs);
 av_freep(>outputs);
diff --git a/libavfilter/internal.h b/libavfilter/internal.h
index 615b725cab..d9ff997e72 100644
--- a/libavfilter/internal.h
+++ b/libavfilter/internal.h
@@ -306,6 +306,16 @@ void ff_filter_graph_remove_filter(AVFilterGraph *graph, 
AVFilterContext *filter
  */
 #define FF_FILTER_FLAG_HWFRAME_AWARE (1 << 0)
 
+/**
+ * The names of all input pads are allocated and should be freed generically.
+ */
+ #define FF_FILTER_FLAG_FREE_INPADS  (1 << 1)
+
+/**
+ * The names of all output pads are allocated and should be freed generically.
+ */
+ #define FF_FILTER_FLAG_FREE_OUTPADS (1 << 2)
+
 /**
  * Run one round of processing on a filter graph.
  */
-- 
2.30.2

___
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 02/23] avfilter/internal: Uninline ff_insert_(in|out)pad()

2021-08-11 Thread Andreas Rheinhardt 
These functions are not hot at all and future commits will make them
bigger.

Signed-off-by: Andreas Rheinhardt 
---
I haven't found a caller that adds a pad somewhere else than the end
of the list, so the index parameter could be removed. Shall I do so
or is there a compelling reason to retain this functionality?

 libavfilter/avfilter.c | 32 +---
 libavfilter/internal.h | 32 ++--
 2 files changed, 31 insertions(+), 33 deletions(-)

diff --git a/libavfilter/avfilter.c b/libavfilter/avfilter.c
index f9d7226386..de7501c37b 100644
--- a/libavfilter/avfilter.c
+++ b/libavfilter/avfilter.c
@@ -101,9 +101,23 @@ void ff_command_queue_pop(AVFilterContext *filter)
 av_free(c);
 }
 
-int ff_insert_pad(unsigned idx, unsigned *count, size_t padidx_off,
-   AVFilterPad **pads, AVFilterLink ***links,
-   AVFilterPad *newpad)
+/**
+ * Insert a new pad.
+ *
+ * @param idx Insertion point. Pad is inserted at the end if this point
+ *is beyond the end of the list of pads.
+ * @param count Pointer to the number of pads in the list
+ * @param padidx_off Offset within an AVFilterLink structure to the element
+ *   to increment when inserting a new pad causes link
+ *   numbering to change
+ * @param pads Pointer to the pointer to the beginning of the list of pads
+ * @param links Pointer to the pointer to the beginning of the list of links
+ * @param newpad The new pad to add. A copy is made when adding.
+ * @return >= 0 in case of success, a negative AVERROR code on error
+ */
+static int insert_pad(unsigned idx, unsigned *count, size_t padidx_off,
+  AVFilterPad **pads, AVFilterLink ***links,
+  AVFilterPad *newpad)
 {
 AVFilterLink **newlinks;
 AVFilterPad *newpads;
@@ -133,6 +147,18 @@ int ff_insert_pad(unsigned idx, unsigned *count, size_t 
padidx_off,
 return 0;
 }
 
+int ff_insert_inpad(AVFilterContext *f, unsigned index, AVFilterPad *p)
+{
+return insert_pad(index, >nb_inputs, offsetof(AVFilterLink, dstpad),
+  >input_pads, >inputs, p);
+}
+
+int ff_insert_outpad(AVFilterContext *f, unsigned index, AVFilterPad *p)
+{
+return insert_pad(index, >nb_outputs, offsetof(AVFilterLink, srcpad),
+  >output_pads, >outputs, p);
+}
+
 int avfilter_link(AVFilterContext *src, unsigned srcpad,
   AVFilterContext *dst, unsigned dstpad)
 {
diff --git a/libavfilter/internal.h b/libavfilter/internal.h
index 6c908690b4..615b725cab 100644
--- a/libavfilter/internal.h
+++ b/libavfilter/internal.h
@@ -214,39 +214,11 @@ void ff_tlog_ref(void *ctx, AVFrame *ref, int end);
 
 void ff_tlog_link(void *ctx, AVFilterLink *link, int end);
 
-/**
- * Insert a new pad.
- *
- * @param idx Insertion point. Pad is inserted at the end if this point
- *is beyond the end of the list of pads.
- * @param count Pointer to the number of pads in the list
- * @param padidx_off Offset within an AVFilterLink structure to the element
- *   to increment when inserting a new pad causes link
- *   numbering to change
- * @param pads Pointer to the pointer to the beginning of the list of pads
- * @param links Pointer to the pointer to the beginning of the list of links
- * @param newpad The new pad to add. A copy is made when adding.
- * @return >= 0 in case of success, a negative AVERROR code on error
- */
-int ff_insert_pad(unsigned idx, unsigned *count, size_t padidx_off,
-   AVFilterPad **pads, AVFilterLink ***links,
-   AVFilterPad *newpad);
-
 /** Insert a new input pad for the filter. */
-static inline int ff_insert_inpad(AVFilterContext *f, unsigned index,
-   AVFilterPad *p)
-{
-return ff_insert_pad(index, >nb_inputs, offsetof(AVFilterLink, dstpad),
-  >input_pads, >inputs, p);
-}
+int ff_insert_inpad(AVFilterContext *f, unsigned index, AVFilterPad *p);
 
 /** Insert a new output pad for the filter. */
-static inline int ff_insert_outpad(AVFilterContext *f, unsigned index,
-AVFilterPad *p)
-{
-return ff_insert_pad(index, >nb_outputs, offsetof(AVFilterLink, srcpad),
-  >output_pads, >outputs, p);
-}
+int ff_insert_outpad(AVFilterContext *f, unsigned index, AVFilterPad *p);
 
 /**
  * Request an input frame from the filter at the other end of the link.
-- 
2.30.2

___
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/h264_parse: add some missing checks to ff_h264_init_poc()

2021-08-11 Thread James Almer 
poc.delta_poc_bottom and poc.delta_poc[1] are only coded in the bitstream if
pps->pic_order_present is true, so ensure they are not used otherwise, to
prevent the potential use of stale values.

Signed-off-by: James Almer 
---
This complements ce4a31cd1ff0348d279af74d49556d0315171e94, and is a more
thorough fix for the issue described in it, affecting all users of
ff_h264_init_poc(), like the parser, and not just the decoder.

 libavcodec/h264_parse.c  | 7 ---
 libavcodec/h264_parse.h  | 2 +-
 libavcodec/h264_parser.c | 2 +-
 libavcodec/h264_slice.c  | 2 +-
 4 files changed, 7 insertions(+), 6 deletions(-)

diff --git a/libavcodec/h264_parse.c b/libavcodec/h264_parse.c
index 1c1d1c04b0..5d642c7201 100644
--- a/libavcodec/h264_parse.c
+++ b/libavcodec/h264_parse.c
@@ -275,9 +275,10 @@ fail:
 }
 
 int ff_h264_init_poc(int pic_field_poc[2], int *pic_poc,
- const SPS *sps, H264POCContext *pc,
+ const PPS *pps, H264POCContext *pc,
  int picture_structure, int nal_ref_idc)
 {
+const SPS *sps = pps->sps;
 const int max_frame_num = 1 << sps->log2_max_frame_num;
 int64_t field_poc[2];
 
@@ -300,7 +301,7 @@ int ff_h264_init_poc(int pic_field_poc[2], int *pic_poc,
 pc->poc_msb = pc->prev_poc_msb;
 field_poc[0] =
 field_poc[1] = pc->poc_msb + pc->poc_lsb;
-if (picture_structure == PICT_FRAME)
+if (pps->pic_order_present && picture_structure == PICT_FRAME)
 field_poc[1] += pc->delta_poc_bottom;
 } else if (sps->poc_type == 1) {
 int abs_frame_num;
@@ -336,7 +337,7 @@ int ff_h264_init_poc(int pic_field_poc[2], int *pic_poc,
 field_poc[0] = expectedpoc + pc->delta_poc[0];
 field_poc[1] = field_poc[0] + sps->offset_for_top_to_bottom_field;
 
-if (picture_structure == PICT_FRAME)
+if (pps->pic_order_present && picture_structure == PICT_FRAME)
 field_poc[1] += pc->delta_poc[1];
 } else {
 int poc = 2 * (pc->frame_num_offset + pc->frame_num);
diff --git a/libavcodec/h264_parse.h b/libavcodec/h264_parse.h
index 4d01620125..35c4810f34 100644
--- a/libavcodec/h264_parse.h
+++ b/libavcodec/h264_parse.h
@@ -78,7 +78,7 @@ int ff_h264_parse_ref_count(int *plist_count, int 
ref_count[2],
 int slice_type_nos, int picture_structure, void 
*logctx);
 
 int ff_h264_init_poc(int pic_field_poc[2], int *pic_poc,
- const SPS *sps, H264POCContext *poc,
+ const PPS *pps, H264POCContext *poc,
  int picture_structure, int nal_ref_idc);
 
 int ff_h264_decode_extradata(const uint8_t *data, int size, H264ParamSets *ps,
diff --git a/libavcodec/h264_parser.c b/libavcodec/h264_parser.c
index d3c56cc188..6e2e7cde67 100644
--- a/libavcodec/h264_parser.c
+++ b/libavcodec/h264_parser.c
@@ -440,7 +440,7 @@ static inline int parse_nal_units(AVCodecParserContext *s,
 /* Decode POC of this picture.
  * The prev_ values needed for decoding POC of the next picture 
are not set here. */
 field_poc[0] = field_poc[1] = INT_MAX;
-ret = ff_h264_init_poc(field_poc, >output_picture_number, sps,
+ret = ff_h264_init_poc(field_poc, >output_picture_number, 
p->ps.pps,
  >poc, p->picture_structure, nal.ref_idc);
 if (ret < 0)
 goto fail;
diff --git a/libavcodec/h264_slice.c b/libavcodec/h264_slice.c
index 0d7107d455..223cf21267 100644
--- a/libavcodec/h264_slice.c
+++ b/libavcodec/h264_slice.c
@@ -1742,7 +1742,7 @@ static int h264_field_start(H264Context *h, const 
H264SliceContext *sl,
 }
 
 ret = ff_h264_init_poc(h->cur_pic_ptr->field_poc, >cur_pic_ptr->poc,
- h->ps.sps, >poc, h->picture_structure, nal->ref_idc);
+   h->ps.pps, >poc, h->picture_structure, 
nal->ref_idc);
 if (ret < 0)
 return ret;
 
-- 
2.32.0

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

[FFmpeg-devel] [PATCH 01/23] avfilter/vf_(guided|program_opencl): Add missing dynamic inputs flag

2021-08-11 Thread Andreas Rheinhardt 
The code for inserting inpads can't be reached by ff_vsrc_openclsrc
(unsurprising given that it is a source filter), so it didn't get
the flag.

Signed-off-by: Andreas Rheinhardt 
---
 libavfilter/vf_guided.c | 3 ++-
 libavfilter/vf_program_opencl.c | 1 +
 2 files changed, 3 insertions(+), 1 deletion(-)

diff --git a/libavfilter/vf_guided.c b/libavfilter/vf_guided.c
index 202a6a0586..e2bf08f5c3 100644
--- a/libavfilter/vf_guided.c
+++ b/libavfilter/vf_guided.c
@@ -500,6 +500,7 @@ const AVFilter ff_vf_guided = {
 .activate= activate,
 .inputs  = NULL,
 .outputs = guided_outputs,
-.flags   = AVFILTER_FLAG_SUPPORT_TIMELINE_GENERIC | 
AVFILTER_FLAG_SLICE_THREADS,
+.flags   = AVFILTER_FLAG_DYNAMIC_INPUTS | 
AVFILTER_FLAG_SLICE_THREADS |
+   AVFILTER_FLAG_SUPPORT_TIMELINE_GENERIC,
 .process_command = process_command,
 };
diff --git a/libavfilter/vf_program_opencl.c b/libavfilter/vf_program_opencl.c
index 4b38baeb3c..5f455e9afa 100644
--- a/libavfilter/vf_program_opencl.c
+++ b/libavfilter/vf_program_opencl.c
@@ -367,6 +367,7 @@ const AVFilter ff_vf_program_opencl = {
 .description= NULL_IF_CONFIG_SMALL("Filter video using an OpenCL 
program"),
 .priv_size  = sizeof(ProgramOpenCLContext),
 .priv_class = _opencl_class,
+.flags  = AVFILTER_FLAG_DYNAMIC_INPUTS,
 .preinit= _opencl_framesync_preinit,
 .init   = _opencl_init,
 .uninit = _opencl_uninit,
-- 
2.30.2

___
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/3] libavformat/protocols.c: avio_enum_protocols_{input, output}(): Add functions to the API

2021-08-11 Thread Michael Witten 
| Michael Witten:
|
|   > In the repo, there is only one function that enumerates protocols:
|   >
|   >   fftools/cmdutils.c: show_protocols()
|   >
|   > This commit simply has that function make calls directly to the
|   > desired functions, namely:
|   >
|   >   * avio_enum_protocols_for_input()
|   >   * avio_enum_protocols_for_output()
|   >
|   > [...]
|   > -while ((name = avio_enum_protocols(, 0)))
|   > +while ((name = avio_enum_protocols_for_input()))
|   >  printf("  %s\n", name);
|   >  printf("Output:\n");
|   > -while ((name = avio_enum_protocols(, 1)))
|   > +while ((name = avio_enum_protocols_for_output()))
|
| Andreas Rheinhardt:
|
|   > You did not reset opaque before the second call; instead you are relying
|   > on undocumented behaviour, namely that opaque is reset to NULL when no
|   > further protocol exists. (Instead the implementation could also make
|   > opaque point to the sentinel of the array of protocols.) In fact, the
|   > current code already relied on this, but with two functions it is worse,
|   > because in the second loop the opaque for the second function does not
|   > come from a call of avio_enum_protocols_for_output() at all.
|   >
|   > [...]
|   >
|   > I don't think it is worth adding two more public symbols for this.

* Indeed, I did not attempt to alter 'show_protocols()', other than to
  replace one API call with another, more direct API call.

* Perhaps it should simply be documented that 'opaque' is set to NULL.

* I would not be opposed to dropping this patch; it is just a potentiality.

Sincerely,
Michael WItten
___
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/3] avfilter/vf_(guided|program_opencl): Add missing dynamic inputs flag

2021-08-11 Thread Andreas Rheinhardt 
Andreas Rheinhardt:
> Signed-off-by: Andreas Rheinhardt 
> ---
>  libavfilter/vf_guided.c | 3 ++-
>  libavfilter/vf_program_opencl.c | 2 ++
>  2 files changed, 4 insertions(+), 1 deletion(-)
> 
> diff --git a/libavfilter/vf_guided.c b/libavfilter/vf_guided.c
> index 202a6a0586..e2bf08f5c3 100644
> --- a/libavfilter/vf_guided.c
> +++ b/libavfilter/vf_guided.c
> @@ -500,6 +500,7 @@ const AVFilter ff_vf_guided = {
>  .activate= activate,
>  .inputs  = NULL,
>  .outputs = guided_outputs,
> -.flags   = AVFILTER_FLAG_SUPPORT_TIMELINE_GENERIC | 
> AVFILTER_FLAG_SLICE_THREADS,
> +.flags   = AVFILTER_FLAG_DYNAMIC_INPUTS | 
> AVFILTER_FLAG_SLICE_THREADS |
> +   AVFILTER_FLAG_SUPPORT_TIMELINE_GENERIC,
>  .process_command = process_command,
>  };
> diff --git a/libavfilter/vf_program_opencl.c b/libavfilter/vf_program_opencl.c
> index 4b38baeb3c..3af1485d53 100644
> --- a/libavfilter/vf_program_opencl.c
> +++ b/libavfilter/vf_program_opencl.c
> @@ -367,6 +367,7 @@ const AVFilter ff_vf_program_opencl = {
>  .description= NULL_IF_CONFIG_SMALL("Filter video using an OpenCL 
> program"),
>  .priv_size  = sizeof(ProgramOpenCLContext),
>  .priv_class = _opencl_class,
> +.flags  = AVFILTER_FLAG_DYNAMIC_INPUTS,
>  .preinit= _opencl_framesync_preinit,
>  .init   = _opencl_init,
>  .uninit = _opencl_uninit,
> @@ -420,6 +421,7 @@ const AVFilter ff_vsrc_openclsrc = {
>  .description= NULL_IF_CONFIG_SMALL("Generate video using an OpenCL 
> program"),
>  .priv_size  = sizeof(ProgramOpenCLContext),
>  .priv_class = _class,
> +.flags  = AVFILTER_FLAG_DYNAMIC_INPUTS,

This part here is wrong, as the code where inpads are inserted can not
be reached by it (it is a source filter after all). Will send an updated
patch.

>  .init   = _opencl_init,
>  .uninit = _opencl_uninit,
>  .query_formats  = _opencl_filter_query_formats,
> 

- Andreas
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH 2.0/3] libavformat/protocols.c: avio_enum_protocols(): Add more const-correctness

2021-08-11 Thread Michael Witten 
| Michael Witten:
|
|   > -const char *avio_enum_protocols(void **opaque, int output)
|   > +const char *avio_enum_protocols(void **const opaque, const int output)
|
| Andreas Rheinhardt:
|
|   > This thing makes nothing more const-correct at all; C uses call be
|   > value, so we only deal with our own copy of opaque which we may modify
|   > as we please.
|   > The reason for the const-incorrectness lies in the fact that this
|   > function makes *opaque point to something const (namely an entry in a
|   > const list of pointers (each pointing to a const protocol, but that is
|   > irrelevant)), so that the user now has a pointer whose pointed to-type
|   > is not const-qualified, despite the actual target being const.
|   > See here:
|   > 
https://patchwork.ffmpeg.org/project/ffmpeg/patch/20190821090438.10260-2-andreas.rheinha...@gmail.com/
|   > for how to fix the const-correctness if one wants to keep the general
|   > design of the functions. See libavformat/allformats.c,
|   > libavcodec/allcodecs.c, libavfilter/allfilters.c for the other approach
|   > (that involves storing an index in the pointer).
|   >
|   > - Andreas

* The general design of the functions has not been altered by this series.

* The previous patch fixed the const incorrectness as warned by the compiler.
  This patch merely improves the const correctness in general.

* We don't want to modify those parameters as we please, and so we'd like
  to ask the compiler to remind us of that fact as necessary.

  It's const-correct in the sense that it expresses the following fact: Those
  variables are not going to be changed; if there is no intention to modify a
  variable, then it's good practice to mark that variable as const.

  Because this function is being edited, it's a good time to sprinkle
  the 'const' keyword around, as a matter of mental hygiene.

Sincerely,
Michael Witten
___
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/3] libavformat/protocols.c: avio_enum_protocols_{input, output}(): Add functions to the API

2021-08-11 Thread Andreas Rheinhardt 
Michael Witten:
> In the repo, there is only one function that enumerates protocols:
> 
>   fftools/cmdutils.c: show_protocols()
> 
> This commit simply has that function make calls directly to the
> desired functions, namely:
> 
>   * avio_enum_protocols_for_input()
>   * avio_enum_protocols_for_output()
> ---
>  fftools/cmdutils.c  |  4 ++--
>  libavformat/avio.h  | 22 ++
>  libavformat/protocols.c |  2 --
>  3 files changed, 24 insertions(+), 4 deletions(-)
> 
> diff --git a/fftools/cmdutils.c b/fftools/cmdutils.c
> index 64237a4796..87f9be64c3 100644
> --- a/fftools/cmdutils.c
> +++ b/fftools/cmdutils.c
> @@ -1681,10 +1681,10 @@ int show_protocols(void *optctx, const char *opt, 
> const char *arg)
>  
>  printf("Supported file protocols:\n"
> "Input:\n");
> -while ((name = avio_enum_protocols(, 0)))
> +while ((name = avio_enum_protocols_for_input()))
>  printf("  %s\n", name);
>  printf("Output:\n");
> -while ((name = avio_enum_protocols(, 1)))
> +while ((name = avio_enum_protocols_for_output()))

You did not reset opaque before the second call; instead you are relying
on undocumented behaviour, namely that opaque is reset to NULL when no
further protocol exists. (Instead the implementation could also make
opaque point to the sentinel of the array of protocols.) In fact, the
current code already relied on this, but with two functions it is worse,
because in the second loop the opaque for the second function does not
come from a call of avio_enum_protocols_for_output() at all.

>  printf("  %s\n", name);
>  return 0;
>  }
> diff --git a/libavformat/avio.h b/libavformat/avio.h
> index 3b92cf742a..455b872260 100644
> --- a/libavformat/avio.h
> +++ b/libavformat/avio.h
> @@ -788,6 +788,28 @@ int avio_close_dyn_buf(AVIOContext *s, uint8_t 
> **pbuffer);
>   */
>  const char *avio_enum_protocols(void **const opaque, const int output);
>  
> +/**
> + * Iterate through names of available output protocols.
> + *
> + * @param opaque A private pointer representing current protocol.
> + *It must be a pointer to NULL on first iteration and will
> + *be updated by successive calls to avio_enum_protocols_for_output.
> + *
> + * @return A static string containing the name of current protocol or NULL
> + */
> +const char *avio_enum_protocols_for_output(void **const opaque);
> +
> +/**
> + * Iterate through names of available input protocols.
> + *
> + * @param opaque A private pointer representing current protocol.
> + *It must be a pointer to NULL on first iteration and will
> + *be updated by successive calls to avio_enum_protocols_for_input.
> + *
> + * @return A static string containing the name of current protocol or NULL
> + */
> +const char *avio_enum_protocols_for_input(void **const opaque);

I don't think it is worth adding two more public symbols for this.

> +
>  /**
>   * Get AVClass by names of available protocols.
>   *
> diff --git a/libavformat/protocols.c b/libavformat/protocols.c
> index 4cb8ae0b63..ca04ed2eb5 100644
> --- a/libavformat/protocols.c
> +++ b/libavformat/protocols.c
> @@ -102,13 +102,11 @@ const AVClass *ff_urlcontext_child_class_iterate(void 
> **iter)
>  *opaque = NULL; \
>  return NULL;
>  
> -static inline
>  const char *avio_enum_protocols_for_output(void **const opaque)
>  {
>  AVIO_ENUM_PROTOCOLS(url_write);
>  }
>  
> -static inline
>  const char *avio_enum_protocols_for_input(void **const opaque)
>  {
>  AVIO_ENUM_PROTOCOLS(url_read);
> 

___
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 0/3] libavformat/protocols.c: avio_enum_protocols(): Cleanup

2021-08-11 Thread Michael Witten 
| Michael Witten:
| 
|   > However, {2} is presented as a bunch of tiny little transformations
|   > that are intended to aid comprehension; they can be squashed into
|   > one commit as the maintainer sees fit (indeed, as shown below, the
|   > squashed diff is already quite comprehensible):
| 
| Nicholas George:
| 
|   > This is my my opinion, but better squash related changes: what matters
|   > is the final code, how readable it is.
|   > 
|   > Regards,
|   > Nicolas George

In my discussion with Lynn, I realized that I was using:

  for(

instead of:

  for (

If a squash is desired, then it would be easy enough for the committer to
to alter the patch that is embedded in the cover-letter, and thereby get
both a squash and a fix the missing space.

Otherwise, if more changes are necessary, I can make this improvement in
a followup series.

Sincerely,
Michael Witten
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH 2.0/3] libavformat/protocols.c: avio_enum_protocols(): Add more const-correctness

2021-08-11 Thread Andreas Rheinhardt 
Michael Witten:
> This commit adds 'const' qualifiers to the parameters.
> 
> ---
>  libavformat/avio.h  | 2 +-
>  libavformat/protocols.c | 2 +-
>  2 files changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/libavformat/avio.h b/libavformat/avio.h
> index 0b35409787..3b92cf742a 100644
> --- a/libavformat/avio.h
> +++ b/libavformat/avio.h
> @@ -786,7 +786,7 @@ int avio_close_dyn_buf(AVIOContext *s, uint8_t **pbuffer);
>   *
>   * @return A static string containing the name of current protocol or NULL
>   */
> -const char *avio_enum_protocols(void **opaque, int output);
> +const char *avio_enum_protocols(void **const opaque, const int output);
>  
>  /**
>   * Get AVClass by names of available protocols.
> diff --git a/libavformat/protocols.c b/libavformat/protocols.c
> index e0b3405ab8..e671c5ab6a 100644
> --- a/libavformat/protocols.c
> +++ b/libavformat/protocols.c
> @@ -91,7 +91,7 @@ const AVClass *ff_urlcontext_child_class_iterate(void 
> **iter)
>  return ret;
>  }
>  
> -const char *avio_enum_protocols(void **opaque, int output)
> +const char *avio_enum_protocols(void **const opaque, const int output)
>  {
>  const URLProtocol *const *p = *opaque;
>  
> 
This thing makes nothing more const-correct at all; C uses call be
value, so we only deal with our own copy of opaque which we may modify
as we please.
The reason for the const-incorrectness lies in the fact that this
function makes *opaque point to something const (namely an entry in a
const list of pointers (each pointing to a const protocol, but that is
irrelevant)), so that the user now has a pointer whose pointed to-type
is not const-qualified, despite the actual target being const.
See here:
https://patchwork.ffmpeg.org/project/ffmpeg/patch/20190821090438.10260-2-andreas.rheinha...@gmail.com/
for how to fix the const-correctness if one wants to keep the general
design of the functions. See libavformat/allformats.c,
libavcodec/allcodecs.c, libavfilter/allfilters.c for the other approach
(that involves storing an index in the pointer).

- Andreas
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH 2.b/3] libavformat/protocols.c: avio_enum_protocols(): Convert the 'goto' loop to a 'for(; ; )' block

2021-08-11 Thread Michael Witten 
| Michael Witten:
| 
|   > -iterate:
|   > +for(;;) {
|   >  if (*p) {
|   >  if ((output && (*p)->url_write) || (!output && (*p)->url_read)) {
|   >  *opaque = (void *)p;
|   > @@ -105,7 +105,7 @@ iterate:
|   >  goto done;
|   >  }
|   >  ++p;
|   > -goto iterate;
|   > +}
| 
| Lynn:
| 
|   > while (1) please. Let's not add more for (;;) loops.

This is just an intermediate patch.

Future patches populate the slots or clauses of the 'for' statement,
and if these small patches are squashed together (or relegated by
a proper merge commit), then the 'for(;;)' will no longer be part
of the master history.

Sincerely,
Michael Witten


PS
Long ago, I read someone's view on the debate between the options:

  * while (1)
  * for (;;)

That person remarked that he reads "(;;)" as "ever", so that the
whole statement "for (;;)" reads as "forever"; in addition, it is
1 character shorter than "while (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] ffmpeg_hw: Don't ignore key parameters when initializing a hw device

2021-08-11 Thread Soft Works 



> -Original Message-
> From: ffmpeg-devel  On Behalf Of
> Haihao Xiang
> Sent: Wednesday, 11 August 2021 08:44
> To: ffmpeg-devel@ffmpeg.org
> Cc: Haihao Xiang 
> Subject: [FFmpeg-devel] [PATCH] ffmpeg_hw: Don't ignore key
> parameters when initializing a hw device
> 
> Currently user may use '-init_hw_device type=name' to initialize a hw
> device, however the key parameter is ignored when use '-
> init_hw_device
> type=name,key=value'. After applying this patch, user may set key
> parameter if needed.
> ---
>  fftools/ffmpeg_hw.c | 16 +++-
>  1 file changed, 15 insertions(+), 1 deletion(-)
> 

This makes sense as it allows to further simplify hw initialization
command lines.

As an example, you can write 

-init_hw_device qsv=qd,child_device=1

Instead of

-init_hw_device qsv=qd:hw_any,child_device=1

So besides the former being shorter, it also saves the user from 
needing to remember 'hw_any' (or hw, hw2, hw3, hw4 matching the 
child_device param on Windows).

LGTM.

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/mxfdec: store parition score instead of partition pointer in metadata

2021-08-11 Thread Marton Balint 
Partition struct may be reallocated, so let's store the score directly in order
to avoid use-after-free.

Also mxf->current_partition might be null when reading some local tags.

Signed-off-by: Marton Balint 
---
 libavformat/mxfdec.c | 31 +--
 1 file changed, 17 insertions(+), 14 deletions(-)

diff --git a/libavformat/mxfdec.c b/libavformat/mxfdec.c
index 34cbd2cd77..55f2e5c767 100644
--- a/libavformat/mxfdec.c
+++ b/libavformat/mxfdec.c
@@ -108,7 +108,7 @@ typedef struct MXFPartition {
 
 typedef struct MXFMetadataSet {
 UID uid;
-MXFPartition *partition;
+uint64_t partition_score;
 enum MXFMetadataSetType type;
 } MXFMetadataSet;
 
@@ -831,21 +831,25 @@ static int mxf_read_partition_pack(void *arg, AVIOContext 
*pb, int tag, int size
 return 0;
 }
 
-static int partition_score(MXFPartition *p)
+static uint64_t partition_score(MXFPartition *p)
 {
+uint64_t score;
+if (!p)
+return 0;
 if (p->type == Footer)
-return 5;
-if (p->complete)
-return 4;
-if (p->closed)
-return 3;
-return 1;
+score = 5;
+else if (p->complete)
+score = 4;
+else if (p->closed)
+score = 3;
+else
+score = 1;
+return (score << 60) | ((uint64_t)p->this_partition >> 4);
 }
 
 static int mxf_add_metadata_set(MXFContext *mxf, MXFMetadataSet **metadata_set)
 {
 MXFMetadataSet **tmp;
-MXFPartition *new_p = (*metadata_set)->partition;
 enum MXFMetadataSetType type = (*metadata_set)->type;
 
 // Index Table is special because it might be added manually without
@@ -854,10 +858,9 @@ static int mxf_add_metadata_set(MXFContext *mxf, 
MXFMetadataSet **metadata_set)
 if (type != IndexTableSegment) {
 for (int i = 0; i < mxf->metadata_sets_count; i++) {
 if (!memcmp((*metadata_set)->uid, mxf->metadata_sets[i]->uid, 16) 
&& type == mxf->metadata_sets[i]->type) {
-MXFPartition *old_p = mxf->metadata_sets[i]->partition;
-int old_s = partition_score(old_p);
-int new_s = partition_score(new_p);
-if (old_s > new_s || old_s == new_s && old_p->this_partition > 
new_p->this_partition) {
+uint64_t old_s = mxf->metadata_sets[i]->partition_score;
+uint64_t new_s = (*metadata_set)->partition_score;
+if (old_s > new_s) {
  mxf_free_metadataset(metadata_set, 1);
  return 0;
 }
@@ -2894,7 +2897,7 @@ static const MXFMetadataReadTableEntry 
mxf_metadata_read_table[] = {
 static int mxf_metadataset_init(MXFMetadataSet *ctx, enum MXFMetadataSetType 
type, MXFPartition *partition)
 {
 ctx->type = type;
-ctx->partition = partition;
+ctx->partition_score = partition_score(partition);
 switch (type){
 case MultipleDescriptor:
 case Descriptor:
-- 
2.31.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 2.b/3] libavformat/protocols.c: avio_enum_protocols(): Convert the 'goto' loop to a 'for(; ; )' block

2021-08-11 Thread Lynne 
11 Aug 2021, 21:00 by mfwit...@gmail.com:

> The indentation will be cleaned up in the next commit.
>
> ---
>  libavformat/protocols.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/libavformat/protocols.c b/libavformat/protocols.c
> index 032f07bf72..2aa302d08f 100644
> --- a/libavformat/protocols.c
> +++ b/libavformat/protocols.c
> @@ -95,7 +95,7 @@ const char *avio_enum_protocols(void **const opaque, const 
> int output)
>  {
>  typedef const URLProtocol *const *Iterator;
>  Iterator p = *opaque ? (Iterator)(*opaque) + 1 : url_protocols;
> -iterate:
> +for(;;) {
>  if (*p) {
>  if ((output && (*p)->url_write) || (!output && (*p)->url_read)) {
>  *opaque = (void *)p;
> @@ -105,7 +105,7 @@ iterate:
>  goto done;
>  }
>  ++p;
> -goto iterate;
> +}
>  
>  done:
>  *opaque = NULL;
>

while (1) please. Let's not add more for (;;) loops.
___
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/3] avfilter/avfilter: Fix leaks upon filter creation error

2021-08-11 Thread Andreas Rheinhardt 
Nicolas George:
> Andreas Rheinhardt (12021-08-11):
>> Both the name as well as the options need to be freed.
>> (Right now there is no option for the AVFilterContext itself that could
>> leak, but some filters have options (e.g. of type AV_OPT_TYPE_STRING)
>> that can leak.)
>>
>> Signed-off-by: Andreas Rheinhardt 
> 
> LGTM.
> 
I have now found an issue with this patch: If preinit fails (no current
preinit seems to be able to fail), then av_opt_free() will be called
before the AVClass has been set on the private context (presuming the
filter to have a private class).

Furthermore, there are more problems here: The documentation states that
uninit will be called on preinit failure. This is just not true.
Finally, nb_(in|out)puts is set before the structures necessary for this
have been allocated and if uninit is called (due to preinit success),
then freeing the pads names might crash; seems like none of the filters
that currently have a preinit are affected by this (only the xmedian
filter has dynamic inputs, but it has no static inputs, so it is safe).
I will therefore send an updated patch; I will also send a patch to free
the name of pads generically based upon a internal flag.

- Andreas
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH 0/3] libavformat/protocols.c: avio_enum_protocols(): Cleanup

2021-08-11 Thread Nicolas George 
Michael Witten (12021-08-11):
> However, {2} is presented as a bunch of tiny little transformations
> that are intended to aid comprehension; they can be squashed into
> one commit as the maintainer sees fit (indeed, as shown below, the
> squashed diff is already quite comprehensible):

This is my my opinion, but better squash related changes: what matters
is the final code, how readable it is.

Regards,

-- 
  Nicolas George


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 2.e/3] libavformat/protocols.c: avio_enum_protocols(): Create a macro for generating different loops

2021-08-11 Thread Michael Witten 
The function 'avio_enum_protocols()' iterates through the list of
protocols, looking for a protocol that has a certain non-zero
pointer-to-function; the exact pointer-to-function to use depends
on the the argument passed through the parameter 'output'.

* Before this commit, the parameter 'output' was being checked
  on every iteration, despite the fact that its value does not
  change.

* This commit explicitly separates out the different cases into
  their own loops (i.e., their own functions), so that 'output'
  need not be tested on each iteration.

* To aid maintenance, these separate functions are the expansion
  of a single macro that provides a generic implementation:

AVIO_ENUM_PROTOCOLS(METHOD)

  One of the benefits of using a macro is that it does not depend
  on a compiler being able to optimize the code. Before deciding
  to use a macro for this purpose, it was attempted to write a
  generic version in terms of pure C code that also would not
  rely on magical optimizations; this involved type conversions
  on pointer arithmetic around 'offsetof()', but it turns out that
  Standard C (not to be confused with Actual C) has no reliable way
  to recover the value of a pointer-to-function from an object,
  so that avenue was ultimately abandoned for the sake of pure
  pedantry.
---
 libavformat/protocols.c | 37 +++--
 1 file changed, 27 insertions(+), 10 deletions(-)

diff --git a/libavformat/protocols.c b/libavformat/protocols.c
index 9ce98968fa..4cb8ae0b63 100644
--- a/libavformat/protocols.c
+++ b/libavformat/protocols.c
@@ -91,18 +91,35 @@ const AVClass *ff_urlcontext_child_class_iterate(void 
**iter)
 return ret;
 }
 
-const char *avio_enum_protocols(void **const opaque, const int output)
+#define AVIO_ENUM_PROTOCOLS(METHOD) \
+typedef const URLProtocol *const *Iterator; \
+for(Iterator p = *opaque ? (Iterator)(*opaque) + 1 : url_protocols; *p; 
++p) { \
+if ((*p)->METHOD) { \
+*opaque = (void *)p; \
+return (*p)->name; \
+} \
+} \
+*opaque = NULL; \
+return NULL;
+
+static inline
+const char *avio_enum_protocols_for_output(void **const opaque)
 {
-typedef const URLProtocol *const *Iterator;
-for(Iterator p = *opaque ? (Iterator)(*opaque) + 1 : url_protocols; *p; 
++p) {
-if ((output && (*p)->url_write) || (!output && (*p)->url_read)) {
-*opaque = (void *)p;
-return (*p)->name;
-}
-}
+AVIO_ENUM_PROTOCOLS(url_write);
+}
 
-*opaque = NULL;
-return NULL;
+static inline
+const char *avio_enum_protocols_for_input(void **const opaque)
+{
+AVIO_ENUM_PROTOCOLS(url_read);
+}
+
+const char *avio_enum_protocols(void **const opaque, const int output)
+{
+if (output)
+return avio_enum_protocols_for_output(opaque);
+else
+return avio_enum_protocols_for_input(opaque);
 }
 
 const AVClass *avio_protocol_get_class(const char *name)
-- 
2.22.0

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

[FFmpeg-devel] [PATCH 3/3] libavformat/protocols.c: avio_enum_protocols_{input, output}(): Add functions to the API

2021-08-11 Thread Michael Witten 
In the repo, there is only one function that enumerates protocols:

  fftools/cmdutils.c: show_protocols()

This commit simply has that function make calls directly to the
desired functions, namely:

  * avio_enum_protocols_for_input()
  * avio_enum_protocols_for_output()
---
 fftools/cmdutils.c  |  4 ++--
 libavformat/avio.h  | 22 ++
 libavformat/protocols.c |  2 --
 3 files changed, 24 insertions(+), 4 deletions(-)

diff --git a/fftools/cmdutils.c b/fftools/cmdutils.c
index 64237a4796..87f9be64c3 100644
--- a/fftools/cmdutils.c
+++ b/fftools/cmdutils.c
@@ -1681,10 +1681,10 @@ int show_protocols(void *optctx, const char *opt, const 
char *arg)
 
 printf("Supported file protocols:\n"
"Input:\n");
-while ((name = avio_enum_protocols(, 0)))
+while ((name = avio_enum_protocols_for_input()))
 printf("  %s\n", name);
 printf("Output:\n");
-while ((name = avio_enum_protocols(, 1)))
+while ((name = avio_enum_protocols_for_output()))
 printf("  %s\n", name);
 return 0;
 }
diff --git a/libavformat/avio.h b/libavformat/avio.h
index 3b92cf742a..455b872260 100644
--- a/libavformat/avio.h
+++ b/libavformat/avio.h
@@ -788,6 +788,28 @@ int avio_close_dyn_buf(AVIOContext *s, uint8_t **pbuffer);
  */
 const char *avio_enum_protocols(void **const opaque, const int output);
 
+/**
+ * Iterate through names of available output protocols.
+ *
+ * @param opaque A private pointer representing current protocol.
+ *It must be a pointer to NULL on first iteration and will
+ *be updated by successive calls to avio_enum_protocols_for_output.
+ *
+ * @return A static string containing the name of current protocol or NULL
+ */
+const char *avio_enum_protocols_for_output(void **const opaque);
+
+/**
+ * Iterate through names of available input protocols.
+ *
+ * @param opaque A private pointer representing current protocol.
+ *It must be a pointer to NULL on first iteration and will
+ *be updated by successive calls to avio_enum_protocols_for_input.
+ *
+ * @return A static string containing the name of current protocol or NULL
+ */
+const char *avio_enum_protocols_for_input(void **const opaque);
+
 /**
  * Get AVClass by names of available protocols.
  *
diff --git a/libavformat/protocols.c b/libavformat/protocols.c
index 4cb8ae0b63..ca04ed2eb5 100644
--- a/libavformat/protocols.c
+++ b/libavformat/protocols.c
@@ -102,13 +102,11 @@ const AVClass *ff_urlcontext_child_class_iterate(void 
**iter)
 *opaque = NULL; \
 return NULL;
 
-static inline
 const char *avio_enum_protocols_for_output(void **const opaque)
 {
 AVIO_ENUM_PROTOCOLS(url_write);
 }
 
-static inline
 const char *avio_enum_protocols_for_input(void **const opaque)
 {
 AVIO_ENUM_PROTOCOLS(url_read);
-- 
2.22.0

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

[FFmpeg-devel] [PATCH 2.d/3] libavformat/protocols.c: avio_enum_protocols(): Move loop initialization

2021-08-11 Thread Michael Witten 
For the sake of completeness and scope correctness, the declaration
and initialization of 'p' has been moved into the 'for(;;)' statement.

---
 libavformat/protocols.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/libavformat/protocols.c b/libavformat/protocols.c
index e3cde9ce02..9ce98968fa 100644
--- a/libavformat/protocols.c
+++ b/libavformat/protocols.c
@@ -94,8 +94,7 @@ const AVClass *ff_urlcontext_child_class_iterate(void **iter)
 const char *avio_enum_protocols(void **const opaque, const int output)
 {
 typedef const URLProtocol *const *Iterator;
-Iterator p = *opaque ? (Iterator)(*opaque) + 1 : url_protocols;
-for(; *p; ++p) {
+for(Iterator p = *opaque ? (Iterator)(*opaque) + 1 : url_protocols; *p; 
++p) {
 if ((output && (*p)->url_write) || (!output && (*p)->url_read)) {
 *opaque = (void *)p;
 return (*p)->name;
-- 
2.22.0

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

[FFmpeg-devel] [PATCH 2.c/3] libavformat/protocols.c: avio_enum_protocols(): Move the loop variables

2021-08-11 Thread Michael Witten 
The loop variables can now be moved into their respective
slots of the 'for(;;)' statement; this removes the need
for the 'done' label.

---
 libavformat/protocols.c | 8 +---
 1 file changed, 1 insertion(+), 7 deletions(-)

diff --git a/libavformat/protocols.c b/libavformat/protocols.c
index 2aa302d08f..e3cde9ce02 100644
--- a/libavformat/protocols.c
+++ b/libavformat/protocols.c
@@ -95,19 +95,13 @@ const char *avio_enum_protocols(void **const opaque, const 
int output)
 {
 typedef const URLProtocol *const *Iterator;
 Iterator p = *opaque ? (Iterator)(*opaque) + 1 : url_protocols;
-for(;;) {
-if (*p) {
+for(; *p; ++p) {
 if ((output && (*p)->url_write) || (!output && (*p)->url_read)) {
 *opaque = (void *)p;
 return (*p)->name;
 }
-} else {
-goto done;
-}
-++p;
 }
 
-done:
 *opaque = NULL;
 return NULL;
 }
-- 
2.22.0

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

[FFmpeg-devel] [PATCH 2.b/3] libavformat/protocols.c: avio_enum_protocols(): Convert the 'goto' loop to a 'for(; ; )' block

2021-08-11 Thread Michael Witten 
The indentation will be cleaned up in the next commit.

---
 libavformat/protocols.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/libavformat/protocols.c b/libavformat/protocols.c
index 032f07bf72..2aa302d08f 100644
--- a/libavformat/protocols.c
+++ b/libavformat/protocols.c
@@ -95,7 +95,7 @@ const char *avio_enum_protocols(void **const opaque, const 
int output)
 {
 typedef const URLProtocol *const *Iterator;
 Iterator p = *opaque ? (Iterator)(*opaque) + 1 : url_protocols;
-iterate:
+for(;;) {
 if (*p) {
 if ((output && (*p)->url_write) || (!output && (*p)->url_read)) {
 *opaque = (void *)p;
@@ -105,7 +105,7 @@ iterate:
 goto done;
 }
 ++p;
-goto iterate;
+}
 
 done:
 *opaque = NULL;
-- 
2.22.0

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

[FFmpeg-devel] [PATCH 2.a/3] libavformat/protocols.c: avio_enum_protocols(): Move branch to bottom of function

2021-08-11 Thread Michael Witten 
A 'goto done;' statement is used to jump to the desired code.
---
 libavformat/protocols.c | 7 +--
 1 file changed, 5 insertions(+), 2 deletions(-)

diff --git a/libavformat/protocols.c b/libavformat/protocols.c
index 0deadbfbe7..032f07bf72 100644
--- a/libavformat/protocols.c
+++ b/libavformat/protocols.c
@@ -102,11 +102,14 @@ iterate:
 return (*p)->name;
 }
 } else {
-*opaque = NULL;
-return NULL;
+goto done;
 }
 ++p;
 goto iterate;
+
+done:
+*opaque = NULL;
+return NULL;
 }
 
 const AVClass *avio_protocol_get_class(const char *name)
-- 
2.22.0

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

[FFmpeg-devel] [PATCH 2.9/3] libavformat/protocols.c: avio_enum_protocols(): Reverse the conditional

2021-08-11 Thread Michael Witten 
The 'if(!*p)' has been turned into 'if (*p)'; of course,
this has necessitated the swapping of the branches.

---
 libavformat/protocols.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/libavformat/protocols.c b/libavformat/protocols.c
index 5828113428..0deadbfbe7 100644
--- a/libavformat/protocols.c
+++ b/libavformat/protocols.c
@@ -96,14 +96,14 @@ const char *avio_enum_protocols(void **const opaque, const 
int output)
 typedef const URLProtocol *const *Iterator;
 Iterator p = *opaque ? (Iterator)(*opaque) + 1 : url_protocols;
 iterate:
-if (!*p) {
-*opaque = NULL;
-return NULL;
-} else {
+if (*p) {
 if ((output && (*p)->url_write) || (!output && (*p)->url_read)) {
 *opaque = (void *)p;
 return (*p)->name;
 }
+} else {
+*opaque = NULL;
+return NULL;
 }
 ++p;
 goto iterate;
-- 
2.22.0

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

[FFmpeg-devel] [PATCH 2.8/3] libavformat/3otocols.c: avio_enum_protocols(): Make the 'else' logic explicit

2021-08-11 Thread Michael Witten 
---
 libavformat/protocols.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/libavformat/protocols.c b/libavformat/protocols.c
index 3f8433e317..5828113428 100644
--- a/libavformat/protocols.c
+++ b/libavformat/protocols.c
@@ -99,11 +99,12 @@ iterate:
 if (!*p) {
 *opaque = NULL;
 return NULL;
-}
+} else {
 if ((output && (*p)->url_write) || (!output && (*p)->url_read)) {
 *opaque = (void *)p;
 return (*p)->name;
 }
+}
 ++p;
 goto iterate;
 }
-- 
2.22.0

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

[FFmpeg-devel] [PATCH 2.7/3] libavformat/protocols.c: avio_enum_protocols(): Indent code

2021-08-11 Thread Michael Witten 
Nothing but white space changed:

  $ git diff --ignore-all-space "$THIS"^ "$THIS" && echo NOTHING
  NOTHING

This is just setting up for the next commit.
---
 libavformat/protocols.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/libavformat/protocols.c b/libavformat/protocols.c
index ec7c72b14f..3f8433e317 100644
--- a/libavformat/protocols.c
+++ b/libavformat/protocols.c
@@ -100,10 +100,10 @@ iterate:
 *opaque = NULL;
 return NULL;
 }
-if ((output && (*p)->url_write) || (!output && (*p)->url_read)) {
-*opaque = (void *)p;
-return (*p)->name;
-}
+if ((output && (*p)->url_write) || (!output && (*p)->url_read)) {
+*opaque = (void *)p;
+return (*p)->name;
+}
 ++p;
 goto iterate;
 }
-- 
2.22.0

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

[FFmpeg-devel] [PATCH 2.6/3] libavformat/protocols.c: avio_enum_protocols(): Move assignment to '*opaque'

2021-08-11 Thread Michael Witten 
The assignment is not necessary until returning.
---
 libavformat/protocols.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/libavformat/protocols.c b/libavformat/protocols.c
index bedaa9ef77..ec7c72b14f 100644
--- a/libavformat/protocols.c
+++ b/libavformat/protocols.c
@@ -96,12 +96,12 @@ const char *avio_enum_protocols(void **const opaque, const 
int output)
 typedef const URLProtocol *const *Iterator;
 Iterator p = *opaque ? (Iterator)(*opaque) + 1 : url_protocols;
 iterate:
-*opaque = (void *)p;
 if (!*p) {
 *opaque = NULL;
 return NULL;
 }
 if ((output && (*p)->url_write) || (!output && (*p)->url_read)) {
+*opaque = (void *)p;
 return (*p)->name;
 }
 ++p;
-- 
2.22.0

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

[FFmpeg-devel] [PATCH 2.5/3] libavformat/protocols.c: avio_enum_protocols(): Add block curly braces to 'if' statement

2021-08-11 Thread Michael Witten 
This is preparation for the next commit.
---
 libavformat/protocols.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/libavformat/protocols.c b/libavformat/protocols.c
index 5e4bf5cbae..bedaa9ef77 100644
--- a/libavformat/protocols.c
+++ b/libavformat/protocols.c
@@ -101,8 +101,9 @@ iterate:
 *opaque = NULL;
 return NULL;
 }
-if ((output && (*p)->url_write) || (!output && (*p)->url_read))
+if ((output && (*p)->url_write) || (!output && (*p)->url_read)) {
 return (*p)->name;
+}
 ++p;
 goto iterate;
 }
-- 
2.22.0

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

[FFmpeg-devel] [PATCH 2.4/3] libavformat/protocols.c: avio_enum_protocols(): Consolidate initialization of 'p'

2021-08-11 Thread Michael Witten 
Now that the label has been moved past the initial assignment of 'p',
it is possible to consolidate both the declaration and initialization.

A typedef is used to simplify the declaration of 'p', and to help the
reader understand what the purpose of 'p' is.

---
 libavformat/protocols.c | 6 ++
 1 file changed, 2 insertions(+), 4 deletions(-)

diff --git a/libavformat/protocols.c b/libavformat/protocols.c
index 7e90cb067d..5e4bf5cbae 100644
--- a/libavformat/protocols.c
+++ b/libavformat/protocols.c
@@ -93,10 +93,8 @@ const AVClass *ff_urlcontext_child_class_iterate(void **iter)
 
 const char *avio_enum_protocols(void **const opaque, const int output)
 {
-const URLProtocol *const *p;
-
-p = *opaque;
-p = p ? p + 1 : url_protocols;
+typedef const URLProtocol *const *Iterator;
+Iterator p = *opaque ? (Iterator)(*opaque) + 1 : url_protocols;
 iterate:
 *opaque = (void *)p;
 if (!*p) {
-- 
2.22.0

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

[FFmpeg-devel] [PATCH 2.3/3] libavformat/protocols.c: avio_enum_protocols(): Move 'iterate' label

2021-08-11 Thread Michael Witten 
Upon iteration ('goto iterate;'), it is known that 'p' is non-zero,
so there is no point in doing the check; it is known that 'p' must
be incremented. Therefore, the 'iterate' label may be moved past
the ternary operator, provided that '++p;' is added just before
the 'goto', so as to perform the required incrementing.
---
 libavformat/protocols.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/libavformat/protocols.c b/libavformat/protocols.c
index b0aae66dab..7e90cb067d 100644
--- a/libavformat/protocols.c
+++ b/libavformat/protocols.c
@@ -95,9 +95,9 @@ const char *avio_enum_protocols(void **const opaque, const 
int output)
 {
 const URLProtocol *const *p;
 
-iterate:
 p = *opaque;
 p = p ? p + 1 : url_protocols;
+iterate:
 *opaque = (void *)p;
 if (!*p) {
 *opaque = NULL;
@@ -105,6 +105,7 @@ iterate:
 }
 if ((output && (*p)->url_write) || (!output && (*p)->url_read))
 return (*p)->name;
+++p;
 goto iterate;
 }
 
-- 
2.22.0

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

[FFmpeg-devel] [PATCH 2.2/3] libavformat/protocols.c: avio_enum_protocols(): Convert recursion to iteration

2021-08-11 Thread Michael Witten 
In C, it's generally not good to write a recursive algorithm,
because it is not possible to rely on the compiler to elide
a tail call; therefore, this commit converts a tail call into
an iterative loop by means of an explicit 'goto' statement.
---
 libavformat/protocols.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/libavformat/protocols.c b/libavformat/protocols.c
index 1c5e3b2bdb..b0aae66dab 100644
--- a/libavformat/protocols.c
+++ b/libavformat/protocols.c
@@ -95,6 +95,7 @@ const char *avio_enum_protocols(void **const opaque, const 
int output)
 {
 const URLProtocol *const *p;
 
+iterate:
 p = *opaque;
 p = p ? p + 1 : url_protocols;
 *opaque = (void *)p;
@@ -104,7 +105,7 @@ const char *avio_enum_protocols(void **const opaque, const 
int output)
 }
 if ((output && (*p)->url_write) || (!output && (*p)->url_read))
 return (*p)->name;
-return avio_enum_protocols(opaque, output);
+goto iterate;
 }
 
 const AVClass *avio_protocol_get_class(const char *name)
-- 
2.22.0

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

[FFmpeg-devel] [PATCH 2.1/3] libavformat/protocols.c: avio_enum_protocols(): Split declaration and initialization

2021-08-11 Thread Michael Witten 
The main purpose of doing this is to allow for inserting a
a statement label; as I recall, a label cannot be placed
just before a declaration, even when that declaration has
an initializer (then again, I never tried, so maybe this
is not true...)

---
 libavformat/protocols.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/libavformat/protocols.c b/libavformat/protocols.c
index e671c5ab6a..1c5e3b2bdb 100644
--- a/libavformat/protocols.c
+++ b/libavformat/protocols.c
@@ -93,8 +93,9 @@ const AVClass *ff_urlcontext_child_class_iterate(void **iter)
 
 const char *avio_enum_protocols(void **const opaque, const int output)
 {
-const URLProtocol *const *p = *opaque;
+const URLProtocol *const *p;
 
+p = *opaque;
 p = p ? p + 1 : url_protocols;
 *opaque = (void *)p;
 if (!*p) {
-- 
2.22.0

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

[FFmpeg-devel] [PATCH 2.0/3] libavformat/protocols.c: avio_enum_protocols(): Add more const-correctness

2021-08-11 Thread Michael Witten 
This commit adds 'const' qualifiers to the parameters.

---
 libavformat/avio.h  | 2 +-
 libavformat/protocols.c | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/libavformat/avio.h b/libavformat/avio.h
index 0b35409787..3b92cf742a 100644
--- a/libavformat/avio.h
+++ b/libavformat/avio.h
@@ -786,7 +786,7 @@ int avio_close_dyn_buf(AVIOContext *s, uint8_t **pbuffer);
  *
  * @return A static string containing the name of current protocol or NULL
  */
-const char *avio_enum_protocols(void **opaque, int output);
+const char *avio_enum_protocols(void **const opaque, const int output);
 
 /**
  * Get AVClass by names of available protocols.
diff --git a/libavformat/protocols.c b/libavformat/protocols.c
index e0b3405ab8..e671c5ab6a 100644
--- a/libavformat/protocols.c
+++ b/libavformat/protocols.c
@@ -91,7 +91,7 @@ const AVClass *ff_urlcontext_child_class_iterate(void **iter)
 return ret;
 }
 
-const char *avio_enum_protocols(void **opaque, int output)
+const char *avio_enum_protocols(void **const opaque, const int output)
 {
 const URLProtocol *const *p = *opaque;
 
-- 
2.22.0

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

[FFmpeg-devel] [PATCH 1/3] libavformat/protocols.c: avio_enum_protocols(): Add const-correctness

2021-08-11 Thread Michael Witten 
This quashes a compile-time warning.

  * 'url_protocols' is an array of const pointers.

  * The explicit conversion to '(void *)' is okay,
because the destination is an "opaque" blob of
private data.
---
 libavformat/protocols.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/libavformat/protocols.c b/libavformat/protocols.c
index 7f08f151b6..e0b3405ab8 100644
--- a/libavformat/protocols.c
+++ b/libavformat/protocols.c
@@ -93,10 +93,10 @@ const AVClass *ff_urlcontext_child_class_iterate(void 
**iter)
 
 const char *avio_enum_protocols(void **opaque, int output)
 {
-const URLProtocol **p = *opaque;
+const URLProtocol *const *p = *opaque;
 
 p = p ? p + 1 : url_protocols;
-*opaque = p;
+*opaque = (void *)p;
 if (!*p) {
 *opaque = NULL;
 return NULL;
-- 
2.22.0

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

[FFmpeg-devel] [PATCH 0/3] libavformat/protocols.c: avio_enum_protocols(): Cleanup

2021-08-11 Thread Michael Witten 
This series improves the following function:

  libavformat/protocols.c: avio_enum_protocols()

There are really only 3 logical commits:

  [1] Add const-correctness (fixes a compile-time warning)
  {2} Refactoring   (cleanup)
  [3] Add functions to the API  (use them too)

However, {2} is presented as a bunch of tiny little transformations
that are intended to aid comprehension; they can be squashed into
one commit as the maintainer sees fit (indeed, as shown below, the
squashed diff is already quite comprehensible):

  {2} Refactoring
[2.0] Add more const-correctness
[2.1] Split declaration and initialization
[2.2] Convert recursion to iteration
[2.3] Move 'iterate' label
[2.4] Consolidate initialization of 'p'
[2.5] Add block curly braces to 'if' statement
[2.6] Move assignment to '*opaque'
[2.7] Indent code
[2.8] Make the 'else' logic explicit
[2.9] Reverse the conditional
[2.a] Move branch to bottom of function
[2.b] Convert the 'goto' loop to a 'for(;;)' block
[2.c] Move the loop variables
[2.d] Move loop initialization
[2.e] Create a macro for generating different loops

For your convenience, this email itself provides an example squashing
of those commits; to apply it, do something like the following:

  $ git am/path/to/patch-1.eml   # Patch [1]
  $ git am --scissors /path/to/this-email# This email's Patch {2}
  $ git am/path/to/patch-3.eml   # Patch [3]

Alternatively, you can have the best of both worlds by means of a merge:

  $ git am /path/to/patch-1.eml  # Patch [1]
  $ patch_1=$(git rev-parse HEAD)
  $ git am /path/to/patch-2.*.eml# Patches [2.*]
  $ git reset --hard "$patch_1"
  $ git merge --no-ff -m \
  'libavformat/protocols.c: avio_enum_protocols(): Refactor' \
  ORIG_HEAD
  $ git am /path/to/patch-3.eml  # Patch [3]

That will produce a very nice history:

  $ git log --oneline --graph

Here is the overall change for the entire series:

 fftools/cmdutils.c  |  4 ++--
 libavformat/avio.h  | 24 +++-
 libavformat/protocols.c | 36 +---
 3 files changed, 50 insertions(+), 14 deletions(-)

Sincerely,
Michael Witten

--8<8<8<8<8<8<8<8<8<8<8<8<8<--

Subject: libavformat/protocols.c: avio_enum_protocols(): Refactor
Date: Wed, 11 Aug 2021 19:00:09 -

This commit is the result of squashing a series of very tiny
transformations; it refactors 'avio_enum_protocols()' into
2 functions:

  * avio_enum_protocols_for_input()
  * avio_enum_protocols_for_output()

Those functions are in turn mostly implemented by this macro:

  * AVIO_ENUM_PROTOCOLS()

The goal of this refactoring was the following:

  * To make the code more immediately understandable.
  * To reduce the potential for redundant computation.

diff --git a/libavformat/avio.h b/libavformat/avio.h
index 0b35409787..3b92cf742a 100644
--- a/libavformat/avio.h
+++ b/libavformat/avio.h
@@ -786,7 +786,7 @@ int avio_close_dyn_buf(AVIOContext *s, uint8_t **pbuffer);
  *
  * @return A static string containing the name of current protocol or NULL
  */
-const char *avio_enum_protocols(void **opaque, int output);
+const char *avio_enum_protocols(void **const opaque, const int output);
 
 /**
  * Get AVClass by names of available protocols.
diff --git a/libavformat/protocols.c b/libavformat/protocols.c
index e0b3405ab8..4cb8ae0b63 100644
--- a/libavformat/protocols.c
+++ b/libavformat/protocols.c
@@ -91,19 +91,35 @@ const AVClass *ff_urlcontext_child_class_iterate(void 
**iter)
 return ret;
 }
 
-const char *avio_enum_protocols(void **opaque, int output)
+#define AVIO_ENUM_PROTOCOLS(METHOD) \
+typedef const URLProtocol *const *Iterator; \
+for(Iterator p = *opaque ? (Iterator)(*opaque) + 1 : url_protocols; *p; 
++p) { \
+if ((*p)->METHOD) { \
+*opaque = (void *)p; \
+return (*p)->name; \
+} \
+} \
+*opaque = NULL; \
+return NULL;
+
+static inline
+const char *avio_enum_protocols_for_output(void **const opaque)
 {
-const URLProtocol *const *p = *opaque;
+AVIO_ENUM_PROTOCOLS(url_write);
+}
 
-p = p ? p + 1 : url_protocols;
-*opaque = (void *)p;
-if (!*p) {
-*opaque = NULL;
-return NULL;
-}
-if ((output && (*p)->url_write) || (!output && (*p)->url_read))
-return (*p)->name;
-return avio_enum_protocols(opaque, output);
+static inline
+const char *avio_enum_protocols_for_input(void **const opaque)
+{
+AVIO_ENUM_PROTOCOLS(url_read);
+}
+
+const char *avio_enum_protocols(void **const opaque, const int output)
+{
+if (output)
+return avio_enum_protocols_for_output(opaque);
+else
+return avio_enum_protocols_for_input(opaque);
 }
 
 const AVClass *avio_protocol_get_class(const char *name)

Re: [FFmpeg-devel] [RFC] Suggestion for a Nicer Integration with GitHub

2021-08-11 Thread ffmpegandmahanstreamer 
August 11, 2021 9:44 AM, "Soft Works"  wrote:

>> -Original Message-
>> From: ffmpeg-devel  On Behalf Of
>> ffmpegandmahanstreamer@e.email
>> Sent: Wednesday, 11 August 2021 15:01
>> To: FFmpeg development discussions and patches > de...@ffmpeg.org>
>> Subject: Re: [FFmpeg-devel] [RFC] Suggestion for a Nicer Integration
>> with GitHub
>> 
>> August 10, 2021 10:37 AM, "Soft Works"  wrote:
> 
> [..]
> 
>> Just recently, I discovered a very interesting project:
>> https://gitgitgadget.github.io
>> 
>> This is all about the development of Git itself, which is done via
>> mailing list and they had the same problem, namely developers that
>> could never be convinced of using GitHub instead of the mailing
>> list. That’s how GitGitGadget came to life:
>> https://github.com/gitgitgadget/gitgitgadget/blob/main/DESIGN.md
>> 
>> Now my suggestion – obviously – is: Adapt the GitGitGadget
>> implementation and employ it for ffmpeg development.
>> 
>> This is a wonderful idea, if it works side in side by the mailing
>> list. I have actually been thinking about this at the back of my
>> head.
> 
> [..]
> 
>> However, with this idea, will people still submit more patches? One
>> of the benefits about github is that you don't need to create a new
>> account and do all that extra stuff.
> 
> On GitHub you _do_ need to create an account to submit pull requests
> (which are like patchsets and can contain multiple commits/patches).
But the changes of someone having a github account is higher than gitea, so to 
speak.
> 
>> If someone was going to sign up
>> for gitgitgaget already and is going the extra mile, they are the
>> same ones most likely to be willing to sumbit to the mailing list as
>> well.
> 
> It doesn't work like that. In fact giggitgadget just works in the
> background invisibly. The procedure is:
> 
> - [optional] a GitHub user might need to get accredited to be
> allowed to submit PRs(to reduce unnecessary noise)
> In case of GIT, it is sufficient when a new developer gets
> approved by any other already participating developer
> 
> - A developer submits a PR at github.com/ffmpeg/ffmpeg
> 
> - The automation performs some automatic validation checks whether
> the submission is acceptable
> 
> - The developer adds a comment containing "/submit"
> 
> - The ggg automation automatically sends the PR as patchset
> to the mailing list
> 
> - Comments in the mailing list are mapped back to the GitHub PR
> 
> - When a developer make changes to PR and "/submit"s again,
> a vN patchset is sent to the mailing list
> 
> What also works is the other direction: patchsets that are submitted
> to the mailing list are automatically mirrored as PR in the
> GitHub repo.
> 
Oh, ok i understand now.
This is a genius idea. I think it's a gamechanger. Thanks for bringing it to 
our attention.

> As said, the really good thing is: nobody would need to change
> the way he is working.
> 
> 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 mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH v2] avutils/hwcontext: When deriving a hwdevice, search for existing device in both directions

2021-08-11 Thread Soft Works 



> -Original Message-
> From: ffmpeg-devel  On Behalf Of
> Soft Works
> Sent: Tuesday, 10 August 2021 11:53
> To: ffmpeg-devel@ffmpeg.org
> Subject: [FFmpeg-devel] [PATCH v2] avutils/hwcontext: When deriving a
> hwdevice, search for existing device in both directions
> 

[..]

> Signed-off-by: softworkz 
> ---
> v2: allow storing multiple derived devices in a device ctx; add
> checks for oom
>  libavutil/hwcontext.c  | 38
> ++
>  libavutil/hwcontext.h  |  1 +
>  libavutil/hwcontext_internal.h |  6 ++
>  libavutil/hwcontext_qsv.c  | 10 -
>  4 files changed, 54 insertions(+), 1 deletion(-)
> 
> diff --git a/libavutil/hwcontext.c b/libavutil/hwcontext.c
> index d13d0f7c9b..7f4e541553 100644
> --- a/libavutil/hwcontext.c
> +++ b/libavutil/hwcontext.c

Now, that Haihao's patch has been merged,
(https://patchwork.ffmpeg.org/project/ffmpeg/list/?series=4532)

this patch is required to make all related derivation scenarios
work, and for some that are working, it will avoid duplicate 
instantiation of hw device contexts.

This version of the patch addresses the (valid) concerns
from @Hendrik by storing multiple derived device contexts
in cases where more than one device is derived from another
device.

It also adds the missing checks as pointed out by Haihao.

Would be great when someone could take a look at the code.


The combination of this and Haihao's patch is quite a milestone
(in the QSV area) as it will enable several scenarios that 
haven't been working before.

>From a quick lock, this will also close the following tickets:


openCL cannot be run simultaneously with h264_qsv
https://trac.ffmpeg.org/ticket/6077 

Intel QSV: "No device available for encoder" message is given
https://trac.ffmpeg.org/ticket/6492 

overlay_qsv fails to create qsvvpp
https://trac.ffmpeg.org/ticket/7808 

overlay_qsv cannot burn graphic subtitles on windows
https://trac.ffmpeg.org/ticket/8609 

overlay_qsv fails with "Inputs with different underlying QSV 
devices are forbidden"
https://trac.ffmpeg.org/ticket/8995


Kind 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] Mail quoting (was: 1/2] libavutil/log: Add capability to prefix loglines with current time or current date+time)

2021-08-11 Thread ffmpegandmahanstreamer 
E.email comes with this capability built in.

August 10, 2021 10:02 AM, "Michael Niedermayer"  wrote:

> On Tue, Aug 10, 2021 at 09:47:31AM +, Soft Works wrote:
> 
>> -Original Message-
>> From: ffmpeg-devel  On Behalf Of
>> Nicolas George
>> Sent: Tuesday, 10 August 2021 11:16
>> To: FFmpeg development discussions and patches > de...@ffmpeg.org>
>> Subject: [FFmpeg-devel] Mail quoting (was: 1/2] libavutil/log: Add capability
>> to prefix loglines with current time or current date+time)
>> 
>> Soft Works (12021-08-10):
>>> I meant the e-mail body of the previous conversation.
>> 
>> Well, it is my mail, I put what I want in it, and you do what you want with
>> yours.
>> 
>> But ask yourself: which one do you find easier to read: one where you have
>> to scroll half a dozen pages of old mail just to get to the new bits, or one
>> where you have enough quoted context to remember what the discussion is
>> about but not too much?
>> 
>> For me, the answer is the second, and since I prefer this for myself
>> 
>> Totally agree.
>> 
>> I have toe
>> courtesy to do the same for the mails I send, even if it takes a few more
>> keystrokes. A lot of people do not bother,
>> 
>> Yes, that made me wonder whether shortening would be against any rule or
>> guideline.
>> 
>> One of the most annoying things with that mailing-list-style development
>> is the requirement to scroll through every single message of concern
>> while trying to spot all lines that do not have a '> ' prefix. As some do not
>> even put a blank line before and after a comment, you cannot rely on that,
>> meaning that you have to look very carefully while scrolling.
> 
> if your MUA doesnt color the text to make it easy,
> maybe you should consider a different MUA
> for example mutt can color code text based on how many ">" are there at the 
> begin
> in fact mutt lets you write your own rules for how to color the mails
> I would assume any half decent MUA should be able to do something similar
> 
> Thanks
> 
> [...]
> 
> --
> Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
> 
> Awnsering whenever a program halts or runs forever is
> On a turing machine, in general impossible (turings halting problem).
> On any real computer, always possible as a real computer has a finite number
> of states N, and will either halt in less than N cycles or never halt.
> 
> ___
> 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] [RFC] Suggestion for a Nicer Integration with GitHub

2021-08-11 Thread ffmpegandmahanstreamer 
August 10, 2021 10:37 AM, "Soft Works"  wrote:

> Hi,
> 
> A while ago there was a discussion about moving forward and 
> migrating the ffmpeg development process from the mailing list to 
> another platform (like GitLab).
> That discussion had died without further results and an important 
> takeaway for me was that there are just too many that love this way 
> of interaction and operation and would argue till the end of time 
> against such changes. That’s not meant as a kind of criticism, just 
> an assessment. There a those and those people with different 
> preferences and no doubt that others, who are preferring a more 
> modern and integrated approach like GitHub provides, would be as 
> much rejective when told about having to switch to a mailing list 
> based process.

I do think that if it moves it should move to something self hosted. However 
people have strong opinions about code forges (Github sucks because of "x", 
while someone else says gitlab sucks because of "y", and then gitea sucks 
because of "z", and so on)

> 
> But without doubt, a lot more developers could be attracted to 
> participate in ffmpeg development when it would be accessible in a 
> way like many developers are used to work these days. The ffmpeg 
> mirror on GitHub has 354 PR’s (25k stars, 8k forks!) even though 
> that there’s a big and clear warning shown that PRs won’t be 
> accepted this way. I wonder how many PRs might get submitted once we 
> could actually accept PRs from there.
> 
Anyone who wanted to contribute would send a patch t
> My conclusion from the recent discussion was, that the only way to 
> make a change that could find a larger base of agreement would be a 
> solution that doesn’t make a change at all. What I mean by that is: 
> no moving of the repository, no migration to another platform, no 
> replacement of the mailing-list and leaving everything working 
> as-is. Instead, just add something on-top of it that will allow all 
> those “others” to better accommodate with ffmpeg development.
> I had the idea to build some synchronization between Patchwork and 
> GitHub in a way that it would mirror submitted patches as GitHub 
> pull requests, I didn’t have the time to get on it.
> 

> Just recently, I discovered a very interesting project: 
> https://gitgitgadget.github.io
> 
> This is all about the development of Git itself, which is done via 
> mailing list and they had the same problem, namely developers that 
> could never be convinced of using GitHub instead of the mailing 
> list. That’s how GitGitGadget came to life: 
> https://github.com/gitgitgadget/gitgitgadget/blob/main/DESIGN.md
> 
> Now my suggestion – obviously – is: Adapt the GitGitGadget 
> implementation and employ it for ffmpeg development.

This is a wonderful idea, if it works side in side by the mailing list. I have 
actually been thinking about this at the back of my head.

But FFMpeg, gstreamer, linux kernel, llvm, qemu, wine, etc... all require a 
level of technical skill thats higher than most open source projects (like 
webapps). So if someone can code at that level but cant submit a email patch 
then the patches you would be getting through web will most likely be "minor" 
patches that don't really need anything. Sometimes this isn't true however, for 
example on the page on github there are many patches where theres something non 
trival fixed but they dont have the time to submit patch to mailing list.

However, with this idea, will people still submit more patches? One of the 
benefits about github is that you don't need to create a new account and do all 
that extra stuff. If someone was going to sign up for gitgitgaget already and 
is going the extra mile, they are the same ones most likely to be willing to 
sumbit to the mailing list as well.

Nevertheless, I would be excited to see something like this. Hopefully it 
brings in more patches.
The best approach still in my opinion is what you mentioned earlier: have 
something that integrates directly with Github and Gitlab as those are the two 
largest code forges. 
> 
> Please let me know what you think about it.
> 
> 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 mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH v3 1/2] qsvdec: add support for HW_DEVICE_CTX method

2021-08-11 Thread James Almer 

On 8/11/2021 1:29 PM, Soft Works wrote:




-Original Message-
From: ffmpeg-devel  On Behalf Of
Haihao Xiang
Sent: Wednesday, 11 August 2021 08:02
To: ffmpeg-devel@ffmpeg.org
Cc: Haihao Xiang 
Subject: [FFmpeg-devel] [PATCH v3 1/2] qsvdec: add support for
HW_DEVICE_CTX method

This allows user set hw_device_ctx instead of hw_frames_ctx for QSV
decoders, hence we may remove the ad-hoc libmfx setup code from
FFmpeg.

"-hwaccel_output_format format" is applied to QSV decoders after
removing the ad-hoc libmfx code. In order to keep compatibility with
old
commandlines, the default format is set to AV_PIX_FMT_QSV, but this
behavior will be removed in the future. Please set "-
hwaccel_output_format qsv"
explicitly if AV_PIX_FMT_QSV is expected.

The normal device stuff works for QSV decoders now, user may use
"-init_hw_device args" to initialise device and "-hwaccel_device
devicename" to select a device for QSV decoders.

"-qsv_device device" which was added for workarounding device
selection
in the ad-hoc libmfx code still works

For example:

$> ffmpeg -init_hw_device qsv=qsv:hw_any,child_device=/dev/dri/card0
-hwaccel qsv -c:v h264_qsv -i input.h264  -f null -

/dev/dri/renderD128 is actually open for h264_qsv decoder in the
above
command without this patch. After applying this patch, /dev/dri/card0
is used.

$> ffmpeg -init_hw_device vaapi=va:/dev/dri/card0 -init_hw_device
qsv=hw@va -hwaccel_device hw -hwaccel qsv -c:v h264_qsv -i input.h264
-f null -

device hw of type qsv is not usable in the above command without this
patch. After applying this patch, this command works as expected.
---
v3:
  Don't deprecate -qsv_device option
  Use single-shot device initialization to implement qsv_device option
  Update the commit log

  fftools/Makefile |   1 -
  fftools/ffmpeg.h |   1 -
  fftools/ffmpeg_hw.c  |  12 +
  fftools/ffmpeg_opt.c |  28 +--
  fftools/ffmpeg_qsv.c | 109 -
--
  libavcodec/qsvdec.c  |  31 +++-
  6 files changed, 66 insertions(+), 116 deletions(-)
  delete mode 100644 fftools/ffmpeg_qsv.c

diff --git a/fftools/Makefile b/fftools/Makefile
index 5affaa3f56..5234932ab0 100644
--- a/fftools/Makefile
+++ b/fftools/Makefile
@@ -10,7 +10,6 @@ ALLAVPROGS   =
$(AVBASENAMES:%=%$(PROGSSUF)$(EXESUF))
  ALLAVPROGS_G = $(AVBASENAMES:%=%$(PROGSSUF)_g$(EXESUF))

  OBJS-ffmpeg+= fftools/ffmpeg_opt.o
fftools/ffmpeg_filter.o fftools/ffmpeg_hw.o
-OBJS-ffmpeg-$(CONFIG_LIBMFX)   += fftools/ffmpeg_qsv.o
  ifndef CONFIG_VIDEOTOOLBOX
  OBJS-ffmpeg-$(CONFIG_VDA)  += fftools/ffmpeg_videotoolbox.o
  endif
diff --git a/fftools/ffmpeg.h b/fftools/ffmpeg.h
index d9c0628657..d2dd7ca092 100644
--- a/fftools/ffmpeg.h
+++ b/fftools/ffmpeg.h
@@ -61,7 +61,6 @@ enum HWAccelID {
  HWACCEL_AUTO,
  HWACCEL_GENERIC,
  HWACCEL_VIDEOTOOLBOX,
-HWACCEL_QSV,
  };

  typedef struct HWAccel {
diff --git a/fftools/ffmpeg_hw.c b/fftools/ffmpeg_hw.c
index fc4a5d31d6..6923c4c5a1 100644
--- a/fftools/ffmpeg_hw.c
+++ b/fftools/ffmpeg_hw.c
@@ -339,6 +339,18 @@ int hw_device_setup_for_decode(InputStream *ist)
  } else if (ist->hwaccel_id == HWACCEL_GENERIC) {
  type = ist->hwaccel_device_type;
  dev = hw_device_get_by_type(type);
+
+// When "-qsv_device device" is used, an internal QSV
device named
+// as "__qsv_device" is created. Another QSV device is
created too
+// if "-init_hw_device qsv=name:device" is used. There
are 2 QSV devices
+// if both "-qsv_device device" and "-init_hw_device
qsv=name:device"
+// are used, hw_device_get_by_type(AV_HWDEVICE_TYPE_QSV)
returns NULL.
+// To keep back-compatibility with the removed ad-hoc
libmfx setup code,
+// call hw_device_get_by_name("__qsv_device") to select
the internal QSV
+// device.
+if (!dev && type == AV_HWDEVICE_TYPE_QSV)
+dev = hw_device_get_by_name("__qsv_device");
+
  if (!dev)
  err = hw_device_init_from_type(type, NULL, );
  } else {
diff --git a/fftools/ffmpeg_opt.c b/fftools/ffmpeg_opt.c
index 34cc6c4fd3..428934a3d8 100644
--- a/fftools/ffmpeg_opt.c
+++ b/fftools/ffmpeg_opt.c
@@ -137,9 +137,6 @@ static const char *const
opt_name_enc_time_bases[]= {"enc_time_base"
  const HWAccel hwaccels[] = {
  #if CONFIG_VIDEOTOOLBOX
  { "videotoolbox", videotoolbox_init, HWACCEL_VIDEOTOOLBOX,
AV_PIX_FMT_VIDEOTOOLBOX },
-#endif
-#if CONFIG_LIBMFX
-{ "qsv",   qsv_init,   HWACCEL_QSV,   AV_PIX_FMT_QSV },
  #endif
  { 0 },
  };
@@ -571,6 +568,23 @@ static int opt_vaapi_device(void *optctx, const
char *opt, const char *arg)
  }
  #endif

+#if CONFIG_QSV
+static int opt_qsv_device(void *optctx, const char *opt, const char
*arg)
+{
+const char *prefix = "qsv=__qsv_device:hw_any,child_device=";
+int err;
+char *tmp = av_asprintf("%s%s", prefix, arg);
+
+if

Re: [FFmpeg-devel] [PATCH v3 1/2] qsvdec: add support for HW_DEVICE_CTX method

2021-08-11 Thread Soft Works 



> -Original Message-
> From: ffmpeg-devel  On Behalf Of
> Haihao Xiang
> Sent: Wednesday, 11 August 2021 08:02
> To: ffmpeg-devel@ffmpeg.org
> Cc: Haihao Xiang 
> Subject: [FFmpeg-devel] [PATCH v3 1/2] qsvdec: add support for
> HW_DEVICE_CTX method
> 
> This allows user set hw_device_ctx instead of hw_frames_ctx for QSV
> decoders, hence we may remove the ad-hoc libmfx setup code from
> FFmpeg.
> 
> "-hwaccel_output_format format" is applied to QSV decoders after
> removing the ad-hoc libmfx code. In order to keep compatibility with
> old
> commandlines, the default format is set to AV_PIX_FMT_QSV, but this
> behavior will be removed in the future. Please set "-
> hwaccel_output_format qsv"
> explicitly if AV_PIX_FMT_QSV is expected.
> 
> The normal device stuff works for QSV decoders now, user may use
> "-init_hw_device args" to initialise device and "-hwaccel_device
> devicename" to select a device for QSV decoders.
> 
> "-qsv_device device" which was added for workarounding device
> selection
> in the ad-hoc libmfx code still works
> 
> For example:
> 
> $> ffmpeg -init_hw_device qsv=qsv:hw_any,child_device=/dev/dri/card0
> -hwaccel qsv -c:v h264_qsv -i input.h264  -f null -
> 
> /dev/dri/renderD128 is actually open for h264_qsv decoder in the
> above
> command without this patch. After applying this patch, /dev/dri/card0
> is used.
> 
> $> ffmpeg -init_hw_device vaapi=va:/dev/dri/card0 -init_hw_device
> qsv=hw@va -hwaccel_device hw -hwaccel qsv -c:v h264_qsv -i input.h264
> -f null -
> 
> device hw of type qsv is not usable in the above command without this
> patch. After applying this patch, this command works as expected.
> ---
> v3:
>  Don't deprecate -qsv_device option
>  Use single-shot device initialization to implement qsv_device option
>  Update the commit log
> 
>  fftools/Makefile |   1 -
>  fftools/ffmpeg.h |   1 -
>  fftools/ffmpeg_hw.c  |  12 +
>  fftools/ffmpeg_opt.c |  28 +--
>  fftools/ffmpeg_qsv.c | 109 -
> --
>  libavcodec/qsvdec.c  |  31 +++-
>  6 files changed, 66 insertions(+), 116 deletions(-)
>  delete mode 100644 fftools/ffmpeg_qsv.c
> 
> diff --git a/fftools/Makefile b/fftools/Makefile
> index 5affaa3f56..5234932ab0 100644
> --- a/fftools/Makefile
> +++ b/fftools/Makefile
> @@ -10,7 +10,6 @@ ALLAVPROGS   =
> $(AVBASENAMES:%=%$(PROGSSUF)$(EXESUF))
>  ALLAVPROGS_G = $(AVBASENAMES:%=%$(PROGSSUF)_g$(EXESUF))
> 
>  OBJS-ffmpeg+= fftools/ffmpeg_opt.o
> fftools/ffmpeg_filter.o fftools/ffmpeg_hw.o
> -OBJS-ffmpeg-$(CONFIG_LIBMFX)   += fftools/ffmpeg_qsv.o
>  ifndef CONFIG_VIDEOTOOLBOX
>  OBJS-ffmpeg-$(CONFIG_VDA)  += fftools/ffmpeg_videotoolbox.o
>  endif
> diff --git a/fftools/ffmpeg.h b/fftools/ffmpeg.h
> index d9c0628657..d2dd7ca092 100644
> --- a/fftools/ffmpeg.h
> +++ b/fftools/ffmpeg.h
> @@ -61,7 +61,6 @@ enum HWAccelID {
>  HWACCEL_AUTO,
>  HWACCEL_GENERIC,
>  HWACCEL_VIDEOTOOLBOX,
> -HWACCEL_QSV,
>  };
> 
>  typedef struct HWAccel {
> diff --git a/fftools/ffmpeg_hw.c b/fftools/ffmpeg_hw.c
> index fc4a5d31d6..6923c4c5a1 100644
> --- a/fftools/ffmpeg_hw.c
> +++ b/fftools/ffmpeg_hw.c
> @@ -339,6 +339,18 @@ int hw_device_setup_for_decode(InputStream *ist)
>  } else if (ist->hwaccel_id == HWACCEL_GENERIC) {
>  type = ist->hwaccel_device_type;
>  dev = hw_device_get_by_type(type);
> +
> +// When "-qsv_device device" is used, an internal QSV
> device named
> +// as "__qsv_device" is created. Another QSV device is
> created too
> +// if "-init_hw_device qsv=name:device" is used. There
> are 2 QSV devices
> +// if both "-qsv_device device" and "-init_hw_device
> qsv=name:device"
> +// are used, hw_device_get_by_type(AV_HWDEVICE_TYPE_QSV)
> returns NULL.
> +// To keep back-compatibility with the removed ad-hoc
> libmfx setup code,
> +// call hw_device_get_by_name("__qsv_device") to select
> the internal QSV
> +// device.
> +if (!dev && type == AV_HWDEVICE_TYPE_QSV)
> +dev = hw_device_get_by_name("__qsv_device");
> +
>  if (!dev)
>  err = hw_device_init_from_type(type, NULL, );
>  } else {
> diff --git a/fftools/ffmpeg_opt.c b/fftools/ffmpeg_opt.c
> index 34cc6c4fd3..428934a3d8 100644
> --- a/fftools/ffmpeg_opt.c
> +++ b/fftools/ffmpeg_opt.c
> @@ -137,9 +137,6 @@ static const char *const
> opt_name_enc_time_bases[]= {"enc_time_base"
>  const HWAccel hwaccels[] = {
>  #if CONFIG_VIDEOTOOLBOX
>  { "videotoolbox", videotoolbox_init, HWACCEL_VIDEOTOOLBOX,
> AV_PIX_FMT_VIDEOTOOLBOX },
> -#endif
> -#if CONFIG_LIBMFX
> -{ "qsv",   qsv_init,   HWACCEL_QSV,   AV_PIX_FMT_QSV },
>  #endif
>  { 0 },
>  };
> @@ -571,6 +568,23 @@ static int opt_vaapi_device(void *optctx, const
> char *opt, const char *arg)
>  }
>  #endif
> 
> +#if CONFIG_QSV
> +static int

Re: [FFmpeg-devel] [PATCH] lavc/qsvenc: allows the SDK runtime to choose LowPower/non-LowPower modes

2021-08-11 Thread James Almer 

On 8/11/2021 12:12 PM, Xiang, Haihao wrote:

On Sat, 2020-10-10 at 14:22 +0800, Haihao Xiang wrote:

The SDK supports LowPower and non-LowPower modes, but some features are
available only under one of the two modes. Currently non-LowPower mode
is always chosen in FFmpeg if the mode is not set explicitly, which will
result in some SDK errors if a feature is unavailable under non-LowPower
mode. With this patch, the mode is unknown in FFmpeg if the mode is not
set explicitly, the SDK is responsible for mode selection
---
This is the new version for "lavc/qsvenc: let the SDK to choose the
encoding mode by default" and the git commit log is updated only


Hi,

Is there any comment for this patch? Without this patch, user has to set the
mode to LowPower mode explicitly for some features. It is really inconvenient
because lots of user do not know these features are available only under
LowPower mode. If not objection, I may rebase this patch against the current
master.


Please do.



Thanks
Haihao



  libavcodec/qsvenc.c | 6 --
  libavcodec/qsvenc.h | 2 +-
  2 files changed, 5 insertions(+), 3 deletions(-)

diff --git a/libavcodec/qsvenc.c b/libavcodec/qsvenc.c
index 1ed8f5d973..cff96e59c9 100644
--- a/libavcodec/qsvenc.c
+++ b/libavcodec/qsvenc.c
@@ -510,7 +510,7 @@ static int init_video_param(AVCodecContext *avctx,
QSVEncContext *q)
  }
  }
  
-if (q->low_power) {

+if (q->low_power == 1) {
  #if QSV_HAVE_VDENC
  q->param.mfx.LowPower = MFX_CODINGOPTION_ON;
  #else
@@ -519,7 +519,9 @@ static int init_video_param(AVCodecContext *avctx,
QSVEncContext *q)
  q->low_power = 0;
  q->param.mfx.LowPower = MFX_CODINGOPTION_OFF;
  #endif
-} else
+} else if (q->low_power == -1)
+q->param.mfx.LowPower = MFX_CODINGOPTION_UNKNOWN;
+else
  q->param.mfx.LowPower = MFX_CODINGOPTION_OFF;
  
  q->param.mfx.CodecProfile   = q->profile;

diff --git a/libavcodec/qsvenc.h b/libavcodec/qsvenc.h
index 4f579d1db1..55cc1a 100644
--- a/libavcodec/qsvenc.h
+++ b/libavcodec/qsvenc.h
@@ -96,7 +96,7 @@
  { "adaptive_b", "Adaptive B-frame
placement", OFFSET(qsv.adaptive_b), AV_OPT_TYPE_INT, { .i64 =
-1 }, -1,  1, VE }, \
  { "b_strategy", "Strategy to choose between I/P/B-frames",
OFFSET(qsv.b_strategy),AV_OPT_TYPE_INT, { .i64 = -1 }, -1,  1, VE
}, \
  { "forced_idr", "Forcing I frames as IDR
frames", OFFSET(qsv.forced_idr), AV_OPT_TYPE_BOOL,{ .i64 =
0  },  0,  1, VE }, \
-{ "low_power", "enable low power mode(experimental: many limitations by mfx
version, BRC modes, etc.)", OFFSET(qsv.low_power), AV_OPT_TYPE_BOOL, { .i64 =
0}, 0, 1, VE},\
+{ "low_power", "enable low power mode(experimental: many limitations by mfx
version, BRC modes, etc.)", OFFSET(qsv.low_power), AV_OPT_TYPE_BOOL, { .i64 =
-1}, -1, 1, VE},\
  
  extern const AVCodecHWConfigInternal *ff_qsv_enc_hw_configs[];
  

___
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] lavc/qsvenc: allows the SDK runtime to choose LowPower/non-LowPower modes

2021-08-11 Thread Xiang, Haihao 
On Sat, 2020-10-10 at 14:22 +0800, Haihao Xiang wrote:
> The SDK supports LowPower and non-LowPower modes, but some features are
> available only under one of the two modes. Currently non-LowPower mode
> is always chosen in FFmpeg if the mode is not set explicitly, which will
> result in some SDK errors if a feature is unavailable under non-LowPower
> mode. With this patch, the mode is unknown in FFmpeg if the mode is not
> set explicitly, the SDK is responsible for mode selection
> ---
> This is the new version for "lavc/qsvenc: let the SDK to choose the
> encoding mode by default" and the git commit log is updated only

Hi,

Is there any comment for this patch? Without this patch, user has to set the
mode to LowPower mode explicitly for some features. It is really inconvenient
because lots of user do not know these features are available only under
LowPower mode. If not objection, I may rebase this patch against the current
master.

Thanks
Haihao

> 
>  libavcodec/qsvenc.c | 6 --
>  libavcodec/qsvenc.h | 2 +-
>  2 files changed, 5 insertions(+), 3 deletions(-)
> 
> diff --git a/libavcodec/qsvenc.c b/libavcodec/qsvenc.c
> index 1ed8f5d973..cff96e59c9 100644
> --- a/libavcodec/qsvenc.c
> +++ b/libavcodec/qsvenc.c
> @@ -510,7 +510,7 @@ static int init_video_param(AVCodecContext *avctx,
> QSVEncContext *q)
>  }
>  }
>  
> -if (q->low_power) {
> +if (q->low_power == 1) {
>  #if QSV_HAVE_VDENC
>  q->param.mfx.LowPower = MFX_CODINGOPTION_ON;
>  #else
> @@ -519,7 +519,9 @@ static int init_video_param(AVCodecContext *avctx,
> QSVEncContext *q)
>  q->low_power = 0;
>  q->param.mfx.LowPower = MFX_CODINGOPTION_OFF;
>  #endif
> -} else
> +} else if (q->low_power == -1)
> +q->param.mfx.LowPower = MFX_CODINGOPTION_UNKNOWN;
> +else
>  q->param.mfx.LowPower = MFX_CODINGOPTION_OFF;
>  
>  q->param.mfx.CodecProfile   = q->profile;
> diff --git a/libavcodec/qsvenc.h b/libavcodec/qsvenc.h
> index 4f579d1db1..55cc1a 100644
> --- a/libavcodec/qsvenc.h
> +++ b/libavcodec/qsvenc.h
> @@ -96,7 +96,7 @@
>  { "adaptive_b", "Adaptive B-frame
> placement", OFFSET(qsv.adaptive_b), AV_OPT_TYPE_INT, { .i64 =
> -1 }, -1,  1, VE }, \
>  { "b_strategy", "Strategy to choose between I/P/B-frames",
> OFFSET(qsv.b_strategy),AV_OPT_TYPE_INT, { .i64 = -1 }, -1,  1, VE
> }, \
>  { "forced_idr", "Forcing I frames as IDR
> frames", OFFSET(qsv.forced_idr), AV_OPT_TYPE_BOOL,{ .i64 =
> 0  },  0,  1, VE }, \
> -{ "low_power", "enable low power mode(experimental: many limitations by mfx
> version, BRC modes, etc.)", OFFSET(qsv.low_power), AV_OPT_TYPE_BOOL, { .i64 =
> 0}, 0, 1, VE},\
> +{ "low_power", "enable low power mode(experimental: many limitations by mfx
> version, BRC modes, etc.)", OFFSET(qsv.low_power), AV_OPT_TYPE_BOOL, { .i64 =
> -1}, -1, 1, VE},\
>  
>  extern const AVCodecHWConfigInternal *ff_qsv_enc_hw_configs[];
>  
___
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/wma: handle run_level_decode error

2021-08-11 Thread Andreas Rheinhardt 
Stéphane Cerveau:
> Consider data as invalid if ff_wma_run_level_decode
> gets out with an error.
> 
> It avoids an unpleasant sound distorsion.
> 
> See http://trac.ffmpeg.org/ticket/9358
> ---
>  libavcodec/wmadec.c | 5 +++--
>  1 file changed, 3 insertions(+), 2 deletions(-)
> 
> diff --git a/libavcodec/wmadec.c b/libavcodec/wmadec.c
> index d627bbe50e..74ea8cea77 100644
> --- a/libavcodec/wmadec.c
> +++ b/libavcodec/wmadec.c
> @@ -606,10 +606,11 @@ static int wma_decode_block(WMACodecContext *s)
>   * there is potentially less energy there */
>  tindex = (ch == 1 && s->ms_stereo);
>  memset(ptr, 0, s->block_len * sizeof(WMACoef));
> -ff_wma_run_level_decode(s->avctx, >gb, >coef_vlc[tindex],
> +if (ff_wma_run_level_decode(s->avctx, >gb, 
> >coef_vlc[tindex],
>  s->level_table[tindex], 
> s->run_table[tindex],
>  0, ptr, 0, nb_coefs[ch],
> -s->block_len, s->frame_len_bits, 
> coef_nb_bits);
> +s->block_len, s->frame_len_bits, 
> coef_nb_bits))
> +  return AVERROR_INVALIDDATA;
>  }
>  if (s->version == 1 && s->avctx->channels >= 2)
>  align_get_bits(>gb);
> 
Generally, one should forward error codes and not make up some on the
fly; in this case, the callee does not return proper error codes, so
this should be fixed, too (but not in the same commit and not
necessarily by you). Even more importantly, the callee emits an error
message, stating that an error will be ignored, which will no longer
true with this patch.

- Andreas
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

[FFmpeg-devel] [PATCH] avcodec/wma: handle run_level_decode error

2021-08-11 Thread Stéphane Cerveau 
Consider data as invalid if ff_wma_run_level_decode
gets out with an error.

It avoids an unpleasant sound distorsion.

See http://trac.ffmpeg.org/ticket/9358
---
 libavcodec/wmadec.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/libavcodec/wmadec.c b/libavcodec/wmadec.c
index d627bbe50e..74ea8cea77 100644
--- a/libavcodec/wmadec.c
+++ b/libavcodec/wmadec.c
@@ -606,10 +606,11 @@ static int wma_decode_block(WMACodecContext *s)
  * there is potentially less energy there */
 tindex = (ch == 1 && s->ms_stereo);
 memset(ptr, 0, s->block_len * sizeof(WMACoef));
-ff_wma_run_level_decode(s->avctx, >gb, >coef_vlc[tindex],
+if (ff_wma_run_level_decode(s->avctx, >gb, >coef_vlc[tindex],
 s->level_table[tindex], 
s->run_table[tindex],
 0, ptr, 0, nb_coefs[ch],
-s->block_len, s->frame_len_bits, 
coef_nb_bits);
+s->block_len, s->frame_len_bits, 
coef_nb_bits))
+  return AVERROR_INVALIDDATA;
 }
 if (s->version == 1 && s->avctx->channels >= 2)
 align_get_bits(>gb);
-- 
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] [RFC PATCH] avformat/mov: add AVFMT_SHOW_IDS flag

2021-08-11 Thread James Almer 

On 8/11/2021 11:04 AM, Gyan Doshi wrote:



On 2021-08-11 07:29 pm, Andreas Rheinhardt wrote:

Gyan Doshi:

The MOV muxer can store streamids as track ids but they aren't
visible when probing the result via lavf/dump or ffprobe due to
lack of this flag in the demuxer.

This current submission is just to get Patchwork FATE results.
Will be updated with changed refs, if any.

You are actually supposed to run FATE yourself.


Patchwork is going to test anyway. Might as well save CPU for better uses.


I don't think people will be amused with you using the mailing list to 
test your patches.
It's much faster and less noisy to just run make fate GEN=1 on your end, 
and send finished patches.




Regards,
Gyan
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".


___
ffmpeg-devel 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] [RFC PATCH] avformat/mov: add AVFMT_SHOW_IDS flag

2021-08-11 Thread Gyan Doshi 




On 2021-08-11 07:29 pm, Andreas Rheinhardt wrote:

Gyan Doshi:

The MOV muxer can store streamids as track ids but they aren't
visible when probing the result via lavf/dump or ffprobe due to
lack of this flag in the demuxer.

This current submission is just to get Patchwork FATE results.
Will be updated with changed refs, if any.

You are actually supposed to run FATE yourself.


Patchwork is going to test anyway. Might as well save CPU for better uses.

Regards,
Gyan
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

[FFmpeg-devel] [PATCH] avcodec/cbs_h264: infer all pic_order_cnt slice fields when not coded

2021-08-11 Thread James Almer 
Also change the syntax for some checks, to more closely follow the spec.

Signed-off-by: James Almer 
---
 libavcodec/cbs_h264_syntax_template.c | 24 +---
 1 file changed, 13 insertions(+), 11 deletions(-)

diff --git a/libavcodec/cbs_h264_syntax_template.c 
b/libavcodec/cbs_h264_syntax_template.c
index 0f8bba4a0d..5de7b5b76b 100644
--- a/libavcodec/cbs_h264_syntax_template.c
+++ b/libavcodec/cbs_h264_syntax_template.c
@@ -1106,19 +1106,21 @@ static int FUNC(slice_header)(CodedBitstreamContext 
*ctx, RWContext *rw,
 if (pps->bottom_field_pic_order_in_frame_present_flag &&
 !current->field_pic_flag)
 se(delta_pic_order_cnt_bottom, INT32_MIN + 1, INT32_MAX);
+else
+infer(delta_pic_order_cnt_bottom, 0);
+} else
+infer(delta_pic_order_cnt_bottom, 0);
 
-} else if (sps->pic_order_cnt_type == 1) {
-if (!sps->delta_pic_order_always_zero_flag) {
-se(delta_pic_order_cnt[0], INT32_MIN + 1, INT32_MAX);
-if (pps->bottom_field_pic_order_in_frame_present_flag &&
-!current->field_pic_flag)
-se(delta_pic_order_cnt[1], INT32_MIN + 1, INT32_MAX);
-else
-infer(delta_pic_order_cnt[1], 0);
-} else {
-infer(delta_pic_order_cnt[0], 0);
+if (sps->pic_order_cnt_type == 1 && 
!sps->delta_pic_order_always_zero_flag) {
+se(delta_pic_order_cnt[0], INT32_MIN + 1, INT32_MAX);
+if (pps->bottom_field_pic_order_in_frame_present_flag &&
+!current->field_pic_flag)
+se(delta_pic_order_cnt[1], INT32_MIN + 1, INT32_MAX);
+else
 infer(delta_pic_order_cnt[1], 0);
-}
+} else {
+infer(delta_pic_order_cnt[0], 0);
+infer(delta_pic_order_cnt[1], 0);
 }
 
 if (pps->redundant_pic_cnt_present_flag)
-- 
2.32.0

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [RFC PATCH] avformat/mov: add AVFMT_SHOW_IDS flag

2021-08-11 Thread Andreas Rheinhardt 
Gyan Doshi:
> The MOV muxer can store streamids as track ids but they aren't
> visible when probing the result via lavf/dump or ffprobe due to
> lack of this flag in the demuxer.
> 
> This current submission is just to get Patchwork FATE results.
> Will be updated with changed refs, if any.

You are actually supposed to run FATE yourself.

> ---
>  libavformat/mov.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/libavformat/mov.c b/libavformat/mov.c
> index 46bc7b5aa3..c556390525 100644
> --- a/libavformat/mov.c
> +++ b/libavformat/mov.c
> @@ -8216,5 +8216,5 @@ const AVInputFormat ff_mov_demuxer = {
>  .read_packet= mov_read_packet,
>  .read_close = mov_read_close,
>  .read_seek  = mov_read_seek,
> -.flags  = AVFMT_NO_BYTE_SEEK | AVFMT_SEEK_TO_PTS,
> +.flags  = AVFMT_NO_BYTE_SEEK | AVFMT_SEEK_TO_PTS | 
> AVFMT_SHOW_IDS,
>  };
> 

___
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] [RFC] Suggestion for a Nicer Integration with GitHub

2021-08-11 Thread Soft Works 
> -Original Message-
> From: ffmpeg-devel  On Behalf Of
> ffmpegandmahanstreamer@e.email
> Sent: Wednesday, 11 August 2021 15:01
> To: FFmpeg development discussions and patches  de...@ffmpeg.org>
> Subject: Re: [FFmpeg-devel] [RFC] Suggestion for a Nicer Integration
> with GitHub
> 
> August 10, 2021 10:37 AM, "Soft Works"  wrote:
> 

[..]

> > Just recently, I discovered a very interesting project:
> > https://gitgitgadget.github.io
> >
> > This is all about the development of Git itself, which is done via
> > mailing list and they had the same problem, namely developers that
> > could never be convinced of using GitHub instead of the mailing
> > list. That’s how GitGitGadget came to life:
> > https://github.com/gitgitgadget/gitgitgadget/blob/main/DESIGN.md
> >
> > Now my suggestion – obviously – is: Adapt the GitGitGadget
> > implementation and employ it for ffmpeg development.
> 
> This is a wonderful idea, if it works side in side by the mailing
> list. I have actually been thinking about this at the back of my
> head.

[..]

> However, with this idea, will people still submit more patches? One
> of the benefits about github is that you don't need to create a new
> account and do all that extra stuff.

On GitHub you _do_ need to create an account to submit pull requests
(which are like patchsets and can contain multiple commits/patches).

> If someone was going to sign up
> for gitgitgaget already and is going the extra mile, they are the
> same ones most likely to be willing to sumbit to the mailing list as
> well.

It doesn't work like that. In fact giggitgadget just works in the 
background invisibly. The procedure is:

- [optional] a GitHub user might need to get accredited to be 
  allowed to submit PRs(to reduce unnecessary noise)
  In case of GIT, it is sufficient when a new developer gets
  approved by any other already participating developer

- A developer submits a PR at github.com/ffmpeg/ffmpeg

- The automation performs some automatic validation checks whether
  the submission is acceptable

- The developer adds a comment containing "/submit"

- The ggg automation automatically sends the PR as patchset
  to the mailing list

- Comments in the mailing list are mapped back to the GitHub PR

- When a developer make changes to PR and "/submit"s again,
  a vN patchset is sent to the mailing list


What also works is the other direction: patchsets that are submitted
to the mailing list are automatically mirrored as PR in the 
GitHub repo.

As said, the really good thing is: nobody would need to change
the way he is working.

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 v2 1/5] libavfilter/x86/vf_gblur: add ff_postscale_slice_avx512()

2021-08-11 Thread James Almer 

On 8/11/2021 10:11 AM, Kieran Kunhya wrote:

On Wed, 11 Aug 2021 at 13:31, James Almer  wrote:


You can disable AVX512 at both runtime and compile time. I don't think
that because there's one CPU arch out there that sees a hit in
performance for one instruction set we should stop applying code other
CPUs will benefit from.



Gramner suggests using the ice lake avx-512 subset as the minimum baseline
which I think is a good idea.

Kieran


I'm fine with that, yes.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH v2 1/5] libavfilter/x86/vf_gblur: add ff_postscale_slice_avx512()

2021-08-11 Thread Kieran Kunhya 
On Wed, 11 Aug 2021 at 13:31, James Almer  wrote:

> You can disable AVX512 at both runtime and compile time. I don't think
> that because there's one CPU arch out there that sees a hit in
> performance for one instruction set we should stop applying code other
> CPUs will benefit from.
>

Gramner suggests using the ice lake avx-512 subset as the minimum baseline
which I think is a good idea.

Kieran
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH v2] libavcodec/qsvence: Use QSV encoder defaults as ffmpeg defaults

2021-08-11 Thread James Almer 

On 8/10/2021 11:55 PM, Xiang, Haihao wrote:

On Tue, 2021-08-10 at 08:53 +, Soft Works wrote:

Signed-off-by: softworkz 
---
  libavcodec/qsvenc.h | 4 ++--
  1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/libavcodec/qsvenc.h b/libavcodec/qsvenc.h
index fc8a14143e..58984f996f 100644
--- a/libavcodec/qsvenc.h
+++ b/libavcodec/qsvenc.h
@@ -76,8 +76,8 @@
  
  #define QSV_COMMON_OPTS \

  { "async_depth", "Maximum processing parallelism", OFFSET(qsv.async_depth),
AV_OPT_TYPE_INT, { .i64 = ASYNC_DEPTH_DEFAULT }, 1, INT_MAX, VE
},  \
-{ "avbr_accuracy","Accuracy of the AVBR
ratecontrol",OFFSET(qsv.avbr_accuracy),AV_OPT_TYPE_INT, { .i64 = 0 },
0, INT_MAX, VE }, \
-{ "avbr_convergence", "Convergence of the AVBR ratecontrol",
OFFSET(qsv.avbr_convergence), AV_OPT_TYPE_INT, { .i64 = 0 }, 0, INT_MAX, VE
}, \
+{ "avbr_accuracy","Accuracy of the AVBR ratecontrol (unit of tenth of
percent)",OFFSET(qsv.avbr_accuracy),AV_OPT_TYPE_INT, { .i64 = 1 }, 1,
UINT16_MAX, VE }, \
+{ "avbr_convergence", "Convergence of the AVBR ratecontrol (unit of 100
frames)", OFFSET(qsv.avbr_convergence), AV_OPT_TYPE_INT, { .i64 = 1 }, 1,
UINT16_MAX, VE }, \
  { "preset", NULL, OFFSET(qsv.preset), AV_OPT_TYPE_INT, { .i64 =
MFX_TARGETUSAGE_BALANCED }, MFX_TARGETUSAGE_BEST_QUALITY,
MFX_TARGETUSAGE_BEST_SPEED,   VE, "preset" }, \
  { "veryfast",NULL, 0, AV_OPT_TYPE_CONST, { .i64 =
MFX_TARGETUSAGE_BEST_SPEED  },   INT_MIN, INT_MAX, VE, "preset"
},\
  { "faster",  NULL, 0, AV_OPT_TYPE_CONST, { .i64 =
MFX_TARGETUSAGE_6  },INT_MIN, INT_MAX, VE, "preset"
},


lgtm. thx!


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 v2 1/5] libavfilter/x86/vf_gblur: add ff_postscale_slice_avx512()

2021-08-11 Thread James Almer 

On 8/11/2021 6:43 AM, Kieran Kunhya wrote:

On Wed, 11 Aug 2021 at 08:23, Paul B Mahol  wrote:


will apply if nobody complains.



Is this really a good idea considering the heavy downclocking of avx512 on
server SKUs?


You can disable AVX512 at both runtime and compile time. I don't think 
that because there's one CPU arch out there that sees a hit in 
performance for one instruction set we should stop applying code other 
CPUs will benefit from.

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH v2 1/5] libavfilter/x86/vf_gblur: add ff_postscale_slice_avx512()

2021-08-11 Thread Kieran Kunhya 
On Wed, 11 Aug 2021 at 08:23, Paul B Mahol  wrote:

> will apply if nobody complains.
>

Is this really a good idea considering the heavy downclocking of avx512 on
server SKUs?
___
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] [FFmpeg-cvslog] avformat/mxfdec: prefer footer and complete partitions for metadata

2021-08-11 Thread Marton Balint 




On Tue, 10 Aug 2021, Michael Niedermayer wrote:


On Sun, Aug 01, 2021 at 01:15:32AM +, Marton Balint wrote:

ffmpeg | branch: master | Marton Balint  | Sun Jun 27 22:59:49 
2021 +0200| [7b4bdcd68e1e0abfab21a8be81789531d649c1ff] | committer: Marton Balint

avformat/mxfdec: prefer footer and complete partitions for metadata

Also do not store inferior metadata with the same UID.

Signed-off-by: Marton Balint 


http://git.videolan.org/gitweb.cgi/ffmpeg.git/?a=commit;h=7b4bdcd68e1e0abfab21a8be81789531d649c1ff

---

 libavformat/mxfdec.c | 51 +++
 1 file changed, 47 insertions(+), 4 deletions(-)

[...]

@@ -842,10 +855,39 @@ static int mxf_read_partition_pack(void *arg, AVIOContext 
*pb, int tag, int size
 return 0;
 }

+static int partition_score(MXFPartition *p)
+{
+if (p->type == Footer)


This can fail both as null pointer dereference from mxf->current_partition
being NULL as well as a read after free from a realloc


Hmm, thanks, strange how I (and fate) missed this so obvious problem. Will 
send a fix.


Regards,
Marton




here are the 2 traces:
==15334==ERROR: AddressSanitizer: SEGV on unknown address 0x0008 (pc 
0x00cb211e bp 0x7ffde58f6780 sp 0x7ffde58f6760 T0)
==15334==The signal is caused by a READ memory access.
==15334==Hint: address points to the zero page.
   #0 0xcb211d in partition_score ffmpeg/libavformat/mxfdec.c:860:12
   #1 0xcb149e in mxf_add_metadata_set ffmpeg/libavformat/mxfdec.c:882:29
   #2 0xc7e98c in mxf_read_local_tags ffmpeg/libavformat/mxfdec.c:3004:19
   #3 0xc7e98c in mxf_parse_klv ffmpeg/libavformat/mxfdec.c:3031
   #4 0xc69296 in mxf_read_header ffmpeg/libavformat/mxfdec.c:3445:28
   #5 0xff3e67 in avformat_open_input ffmpeg/libavformat/utils.c:571:20
   #6 0x4c779c in LLVMFuzzerTestOneInput ffmpeg/tools/target_dem_fuzzer.c:187:11
   #7 0x271b34d in fuzzer::Fuzzer::ExecuteCallback(unsigned char const*, 
unsigned long) Fuzzer/build/../FuzzerLoop.cpp:495:13
   #8 0x270ff22 in fuzzer::RunOneTest(fuzzer::Fuzzer*, char const*, unsigned 
long) Fuzzer/build/../FuzzerDriver.cpp:273:6
   #9 0x2715121 in fuzzer::FuzzerDriver(int*, char***, int (*)(unsigned char 
const*, unsigned long)) Fuzzer/build/../FuzzerDriver.cpp:690:9
   #10 0x270fc00 in main Fuzzer/build/../FuzzerMain.cpp:20:10
   #11 0x7ff2d603ebf6 in __libc_start_main 
/build/glibc-S9d2JN/glibc-2.27/csu/../csu/libc-start.c:310
   #12 0x41fb79 in _start (ffmpeg/tools/target_io_dem_fuzzer+0x41fb79)

=
==15313==ERROR: AddressSanitizer: heap-use-after-free on address 0x612006d8 
at pc 0x00d6eca2 bp 0x7ffd92ec0950 sp 0x7ffd92ec0948
READ of size 4 at 0x612006d8 thread T0
   #0 0xd6eca1 in partition_score ffmpeg/libavformat/mxfdec.c:860:12
   #1 0xd6deee in mxf_add_metadata_set ffmpeg/libavformat/mxfdec.c:882:29
   #2 0xd3b3dc in mxf_read_local_tags ffmpeg/libavformat/mxfdec.c:3004:19
   #3 0xd3b3dc in mxf_parse_klv ffmpeg/libavformat/mxfdec.c:3031
   #4 0xd25ce6 in mxf_read_header ffmpeg/libavformat/mxfdec.c:3445:28
   #5 0x4f2707 in avformat_open_input ffmpeg/libavformat/utils.c:571:20
   #6 0x4c6c35 in LLVMFuzzerTestOneInput ffmpeg/tools/target_dem_fuzzer.c:187:11
   #7 0x271a86d in fuzzer::Fuzzer::ExecuteCallback(unsigned char const*, 
unsigned long) Fuzzer/build/../FuzzerLoop.cpp:495:13
   #8 0x270f442 in fuzzer::RunOneTest(fuzzer::Fuzzer*, char const*, unsigned 
long) Fuzzer/build/../FuzzerDriver.cpp:273:6
   #9 0x2714641 in fuzzer::FuzzerDriver(int*, char***, int (*)(unsigned char 
const*, unsigned long)) Fuzzer/build/../FuzzerDriver.cpp:690:9
   #10 0x270f120 in main Fuzzer/build/../FuzzerMain.cpp:20:10
   #11 0x7fbf99d16bf6 in __libc_start_main 
/build/glibc-S9d2JN/glibc-2.27/csu/../csu/libc-start.c:310
   #12 0x41fb79 in _start (ffmpeg/tools/target_dem_fuzzer+0x41fb79)

0x612006d8 is located 152 bytes inside of 288-byte region 
[0x61200640,0x61200760)
freed by thread T0 here:
   #0 0x497e19 in realloc 
/b/swarming/w/ir/cache/builder/src/third_party/llvm/compiler-rt/lib/asan/asan_malloc_linux.cc:164:3
   #1 0xd5e0f4 in mxf_read_partition_pack ffmpeg/libavformat/mxfdec.c:700:16
   #2 0xd3a842 in mxf_parse_klv ffmpeg/libavformat/mxfdec.c:3034:15
   #3 0xd25ce6 in mxf_read_header ffmpeg/libavformat/mxfdec.c:3445:28
   #4 0x4f2707 in avformat_open_input ffmpeg/libavformat/utils.c:571:20
   #5 0x4c6c35 in LLVMFuzzerTestOneInput ffmpeg/tools/target_dem_fuzzer.c:187:11
   #6 0x271a86d in fuzzer::Fuzzer::ExecuteCallback(unsigned char const*, 
unsigned long) Fuzzer/build/../FuzzerLoop.cpp:495:13
   #7 0x270f442 in fuzzer::RunOneTest(fuzzer::Fuzzer*, char const*, unsigned 
long) Fuzzer/build/../FuzzerDriver.cpp:273:6
   #8 0x2714641 in fuzzer::FuzzerDriver(int*, char***, int (*)(unsigned char 
const*, unsigned long)) Fuzzer/build/../FuzzerDriver.cpp:690:9
   #9 0x270f120 in main Fuzzer/build/../FuzzerMain.cpp:20:10
   #10 0x7fbf99d16bf6 in __libc_start_main

  1   2   >