[FFmpeg-devel] 4.4 Release Name

2021-04-02 Thread Michael Niedermayer
Hi all

We still need to choose the name for 4.4
previous unused suggestions where:
Von Neumann, Lorentz, Poincaré, Desitter, De Broglie, Gauss, Galois, Viterbi, 
Darwin

Feel free to reply with name suggestions
If theres a tie then i will randomly pick amongth the tied, i assume all 
previous
suggestions where suggested exactly once already.

I plan to make the release today or tomorrow unless major bugfixes are
still pending. I probably wont have time sunday / monday for making the 
release

Thanks

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

While the State exists there can be no freedom; when there is freedom there
will be no State. -- Vladimir Lenin


signature.asc
Description: PGP signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

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

Re: [FFmpeg-devel] [PATCH 1/7] avformat/utils: Check allocations for failure

2021-04-02 Thread Andreas Rheinhardt
Andreas Rheinhardt:
> There would be leaks in case of failure.
> 
> Signed-off-by: Andreas Rheinhardt 
> ---
> There is unfortunately more of this dynarray_add.
> 
>  libavformat/utils.c | 16 
>  1 file changed, 12 insertions(+), 4 deletions(-)
> 
> diff --git a/libavformat/utils.c b/libavformat/utils.c
> index 0834c80f4e..13b1bc7c78 100644
> --- a/libavformat/utils.c
> +++ b/libavformat/utils.c
> @@ -4625,7 +4625,7 @@ fail:
>  AVProgram *av_new_program(AVFormatContext *ac, int id)
>  {
>  AVProgram *program = NULL;
> -int i;
> +int i, ret;
>  
>  av_log(ac, AV_LOG_TRACE, "new_program: id=0x%04x\n", id);
>  
> @@ -4637,7 +4637,11 @@ AVProgram *av_new_program(AVFormatContext *ac, int id)
>  program = av_mallocz(sizeof(AVProgram));
>  if (!program)
>  return NULL;
> -dynarray_add(&ac->programs, &ac->nb_programs, program);
> +ret = av_dynarray_add_nofree(&ac->programs, &ac->nb_programs, 
> program);
> +if (ret < 0) {
> +av_free(program);
> +return NULL;
> +}
>  program->discard = AVDISCARD_NONE;
>  program->pmt_version = -1;
>  program->id = id;
> @@ -4657,7 +4661,7 @@ AVChapter *avpriv_new_chapter(AVFormatContext *s, 
> int64_t id, AVRational time_ba
>int64_t start, int64_t end, const char *title)
>  {
>  AVChapter *chapter = NULL;
> -int i;
> +int i, ret;
>  
>  if (end != AV_NOPTS_VALUE && start > end) {
>  av_log(s, AV_LOG_ERROR, "Chapter end time %"PRId64" before start 
> %"PRId64"\n", end, start);
> @@ -4677,7 +4681,11 @@ AVChapter *avpriv_new_chapter(AVFormatContext *s, 
> int64_t id, AVRational time_ba
>  chapter = av_mallocz(sizeof(AVChapter));
>  if (!chapter)
>  return NULL;
> -dynarray_add(&s->chapters, &s->nb_chapters, chapter);
> +ret = av_dynarray_add_nofree(&s->chapters, &s->nb_chapters, chapter);
> +if (ret < 0) {
> +av_free(chapter);
> +return NULL;
> +}
>  }
>  av_dict_set(&chapter->metadata, "title", title, 0);
>  chapter->id= id;
> 
Will apply the first two patches of this patchset.

- 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] 4.4 Release Name

2021-04-02 Thread RADSL


On 4/2/2021 2:59 AM, Michael Niedermayer wrote:

Hi all

We still need to choose the name for 4.4
previous unused suggestions where:
Von Neumann, Lorentz, Poincaré, Desitter, De Broglie, Gauss, Galois, Viterbi, 
Darwin

Feel free to reply with name suggestions
If theres a tie then i will randomly pick amongth the tied, i assume all 
previous
suggestions where suggested exactly once already.

I plan to make the release today or tomorrow unless major bugfixes are
still pending. I probably wont have time sunday / monday for making the
release

Thanks



version 4.4 Plandemic

Sincerly
___
ffmpeg-devel mailing list
ffmpeg-devel@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 32/39] avcodec/msmpeg4enc: Don't use code for static init that can fail

2021-04-02 Thread Andreas Rheinhardt
On Thu, Dec 10, 2020 at 12:19 PM Andreas Rheinhardt <
andreas.rheinha...@gmail.com> wrote:

> Signed-off-by: Andreas Rheinhardt 
> ---
>  libavcodec/mpegvideo_enc.c |  3 +--
>  libavcodec/msmpeg4.h   |  2 +-
>  libavcodec/msmpeg4enc.c| 23 ---
>  3 files changed, 10 insertions(+), 18 deletions(-)
>
> diff --git a/libavcodec/mpegvideo_enc.c b/libavcodec/mpegvideo_enc.c
> index 8fb415f42b..8f4876b0ca 100644
> --- a/libavcodec/mpegvideo_enc.c
> +++ b/libavcodec/mpegvideo_enc.c
> @@ -1008,8 +1008,7 @@ FF_ENABLE_DEPRECATION_WARNINGS
>  if (CONFIG_H263_ENCODER && s->out_format == FMT_H263)
>  ff_h263_encode_init(s);
>  if (CONFIG_MSMPEG4_ENCODER && s->msmpeg4_version)
> -if ((ret = ff_msmpeg4_encode_init(s)) < 0)
> -return ret;
> +ff_msmpeg4_encode_init(s);
>  if ((CONFIG_MPEG1VIDEO_ENCODER || CONFIG_MPEG2VIDEO_ENCODER)
>  && s->out_format == FMT_MPEG1)
>  ff_mpeg1_encode_init(s);
> diff --git a/libavcodec/msmpeg4.h b/libavcodec/msmpeg4.h
> index bcdb967401..e111088574 100644
> --- a/libavcodec/msmpeg4.h
> +++ b/libavcodec/msmpeg4.h
> @@ -50,7 +50,7 @@ void ff_msmpeg4_encode_motion(MpegEncContext * s, int
> mx, int my);
>  int ff_msmpeg4_coded_block_pred(MpegEncContext * s, int n,
>  uint8_t **coded_block_ptr);
>
> -int ff_msmpeg4_encode_init(MpegEncContext *s);
> +void ff_msmpeg4_encode_init(MpegEncContext *s);
>  void ff_msmpeg4_encode_picture_header(MpegEncContext *s, int
> picture_number);
>  void ff_msmpeg4_encode_ext_header(MpegEncContext *s);
>  void ff_msmpeg4_encode_mb(MpegEncContext *s, int16_t block[6][64],
> diff --git a/libavcodec/msmpeg4enc.c b/libavcodec/msmpeg4enc.c
> index 2c61735d9d..7a3858b966 100644
> --- a/libavcodec/msmpeg4enc.c
> +++ b/libavcodec/msmpeg4enc.c
> @@ -32,7 +32,6 @@
>
>  #include "libavutil/attributes.h"
>  #include "libavutil/avutil.h"
> -#include "libavutil/mem.h"
>  #include "mpegvideo.h"
>  #include "h263.h"
>  #include "internal.h"
> @@ -46,13 +45,11 @@
>  static uint8_t rl_length[NB_RL_TABLES][MAX_LEVEL+1][MAX_RUN+1][2];
>
>  /* build the table which associate a (x,y) motion vector to a vlc */
> -static av_cold int init_mv_table(MVTable *tab)
> +static av_cold void init_mv_table(MVTable *tab, uint16_t
> table_mv_index[4096])
>  {
>  int i, x, y;
>
> -tab->table_mv_index = av_malloc(sizeof(uint16_t) * 4096);
> -if (!tab->table_mv_index)
> -return AVERROR(ENOMEM);
> +tab->table_mv_index = table_mv_index;
>
>  /* mark all entries as not used */
>  for(i=0;i<4096;i++)
> @@ -63,8 +60,6 @@ static av_cold int init_mv_table(MVTable *tab)
>  y = tab->table_mvy[i];
>  tab->table_mv_index[(x << 6) | y] = i;
>  }
> -
> -return 0;
>  }
>
>  void ff_msmpeg4_code012(PutBitContext *pb, int n)
> @@ -118,10 +113,10 @@ static int get_size_of_code(MpegEncContext * s,
> RLTable *rl, int last, int run,
>  return size;
>  }
>
> -av_cold int ff_msmpeg4_encode_init(MpegEncContext *s)
> +av_cold void ff_msmpeg4_encode_init(MpegEncContext *s)
>  {
>  static int init_done=0;
> -int i, ret;
> +int i;
>
>  ff_msmpeg4_common_init(s);
>  if(s->msmpeg4_version>=4){
> @@ -130,12 +125,12 @@ av_cold int ff_msmpeg4_encode_init(MpegEncContext *s)
>  }
>
>  if (!init_done) {
> +static uint16_t mv_index_tables[2][4096];
>  /* init various encoding tables */
>  init_done = 1;
> -if ((ret = init_mv_table(&ff_mv_tables[0])) < 0)
> -return ret;
> -if ((ret = init_mv_table(&ff_mv_tables[1])) < 0)
> -return ret;
> +init_mv_table(&ff_mv_tables[0], mv_index_tables[0]);
> +init_mv_table(&ff_mv_tables[1], mv_index_tables[1]);
> +
>  for(i=0;i  ff_rl_init(&ff_rl_table[i], ff_static_rl_table_store[i]);
>
> @@ -152,8 +147,6 @@ av_cold int ff_msmpeg4_encode_init(MpegEncContext *s)
>  }
>  }
>  }
> -
> -return 0;
>  }
>
>  static void find_best_tables(MpegEncContext * s)
> --
> 2.25.1
>
>
Will apply.

- 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] 4.4 Release Name

2021-04-02 Thread Gyan Doshi



On 2021-04-02 15:29, Michael Niedermayer wrote:

Hi all

We still need to choose the name for 4.4
previous unused suggestions where:
Von Neumann, Lorentz, Poincaré, Desitter, De Broglie, Gauss, Galois, Viterbi, 
Darwin

Feel free to reply with name suggestions
If theres a tie then i will randomly pick amongth the tied, i assume all 
previous
suggestions where suggested exactly once already.


Rao

after one of the inventors of the DCT.

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

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

Re: [FFmpeg-devel] 4.4 Release Name

2021-04-02 Thread Kieran Kunhya
I would like to suggest:

https://en.m.wikipedia.org/wiki/Kizzmekia_Corbett

Sent from my mobile device

On Fri, 2 Apr 2021, 12:34 RADSL,  wrote:

>
> On 4/2/2021 2:59 AM, Michael Niedermayer wrote:
> > Hi all
> >
> > We still need to choose the name for 4.4
> > previous unused suggestions where:
> > Von Neumann, Lorentz, Poincaré, Desitter, De Broglie, Gauss, Galois,
> Viterbi, Darwin
> >
> > Feel free to reply with name suggestions
> > If theres a tie then i will randomly pick amongth the tied, i assume all
> previous
> > suggestions where suggested exactly once already.
> >
> > I plan to make the release today or tomorrow unless major bugfixes are
> > still pending. I probably wont have time sunday / monday for making the
> > release
> >
> > Thanks
> >
> >
> version 4.4 Plandemic
>
> Sincerly
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@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] 4.4 Release Name

2021-04-02 Thread Andreas Rheinhardt
Michael Niedermayer:
> Hi all
> 
> We still need to choose the name for 4.4
> previous unused suggestions where:
> Von Neumann, Lorentz, Poincaré, Desitter, De Broglie, Gauss, Galois, Viterbi, 
> Darwin
> 

Von Neumann sounds good to me.

- 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] 4.4 Release Name

2021-04-02 Thread Reto Kromer
RADSL wrote:

>On 4/2/2021 2:59 AM, Michael Niedermayer wrote:
>> We still need to choose the name for 4.4
>> previous unused suggestions where:
>> Von Neumann, Lorentz, Poincaré, Desitter, De Broglie, Gauss,
>> Galois, Viterbi, Darwin

Willem de Sitter? If so, then I would write it in two words.

>version 4.4 Plandemic

LOL +1

... and +1 for von Neumann.

Best regards, Reto

___
ffmpeg-devel mailing list
ffmpeg-devel@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] 4.4 Release Name

2021-04-02 Thread Steven Liu


> 2021年4月2日 下午5:59,Michael Niedermayer  写道:
> 
> Von Neumann

Von Neumann lgtm :D

Thanks

Steven Liu



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

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

[FFmpeg-devel] [PATCH 1/2] avcodec/bsf: Fix segfault when freeing half-allocated BSF

2021-04-02 Thread Andreas Rheinhardt
When allocating a BSF fails, it could happen that the BSF's close
function has been called despite a failure to allocate the private data.

Signed-off-by: Andreas Rheinhardt 
---
 libavcodec/bsf.c | 39 ---
 1 file changed, 20 insertions(+), 19 deletions(-)

diff --git a/libavcodec/bsf.c b/libavcodec/bsf.c
index d71bc32584..157984bd9a 100644
--- a/libavcodec/bsf.c
+++ b/libavcodec/bsf.c
@@ -45,14 +45,15 @@ void av_bsf_free(AVBSFContext **pctx)
 return;
 ctx = *pctx;
 
-if (ctx->filter->close)
-ctx->filter->close(ctx);
+if (ctx->internal) {
+if (ctx->filter->close)
+ctx->filter->close(ctx);
+av_packet_free(&ctx->internal->buffer_pkt);
+av_freep(&ctx->internal);
+}
 if (ctx->filter->priv_class && ctx->priv_data)
 av_opt_free(ctx->priv_data);
 
-if (ctx->internal)
-av_packet_free(&ctx->internal->buffer_pkt);
-av_freep(&ctx->internal);
 av_freep(&ctx->priv_data);
 
 avcodec_parameters_free(&ctx->par_in);
@@ -110,20 +111,6 @@ int av_bsf_alloc(const AVBitStreamFilter *filter, 
AVBSFContext **pctx)
 ret = AVERROR(ENOMEM);
 goto fail;
 }
-
-bsfi = av_mallocz(sizeof(*bsfi));
-if (!bsfi) {
-ret = AVERROR(ENOMEM);
-goto fail;
-}
-ctx->internal = bsfi;
-
-bsfi->buffer_pkt = av_packet_alloc();
-if (!bsfi->buffer_pkt) {
-ret = AVERROR(ENOMEM);
-goto fail;
-}
-
 /* allocate priv data and init private options */
 if (filter->priv_data_size) {
 ctx->priv_data = av_mallocz(filter->priv_data_size);
@@ -136,6 +123,20 @@ int av_bsf_alloc(const AVBitStreamFilter *filter, 
AVBSFContext **pctx)
 av_opt_set_defaults(ctx->priv_data);
 }
 }
+/* Allocate AVBSFInternal; must happen after priv_data has been allocated
+ * so that a filter->close needing priv_data is never called without. */
+bsfi = av_mallocz(sizeof(*bsfi));
+if (!bsfi) {
+ret = AVERROR(ENOMEM);
+goto fail;
+}
+ctx->internal = bsfi;
+
+bsfi->buffer_pkt = av_packet_alloc();
+if (!bsfi->buffer_pkt) {
+ret = AVERROR(ENOMEM);
+goto fail;
+}
 
 *pctx = ctx;
 return 0;
-- 
2.27.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] avcodec/bsf: Simplify getting codec name

2021-04-02 Thread Andreas Rheinhardt
All codec ids on BSF whitelists have a codec descriptor, so one can just
use avcodec_get_name() without worrying about the case of what happens
when no codec descriptor is found.

Signed-off-by: Andreas Rheinhardt 
---
 libavcodec/bsf.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/libavcodec/bsf.c b/libavcodec/bsf.c
index 157984bd9a..543fe87b30 100644
--- a/libavcodec/bsf.c
+++ b/libavcodec/bsf.c
@@ -160,9 +160,9 @@ int av_bsf_init(AVBSFContext *ctx)
"bitstream filter '%s'. Supported codecs are: ",
desc ? desc->name : "unknown", ctx->par_in->codec_id, 
ctx->filter->name);
 for (i = 0; ctx->filter->codec_ids[i] != AV_CODEC_ID_NONE; i++) {
-desc = avcodec_descriptor_get(ctx->filter->codec_ids[i]);
+enum AVCodecID codec_id = ctx->filter->codec_ids[i];
 av_log(ctx, AV_LOG_ERROR, "%s (%d) ",
-   desc ? desc->name : "unknown", 
ctx->filter->codec_ids[i]);
+   avcodec_get_name(codec_id), codec_id);
 }
 av_log(ctx, AV_LOG_ERROR, "\n");
 return AVERROR(EINVAL);
-- 
2.27.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] 4.4 Release Name

2021-04-02 Thread Lynne
Apr 2, 2021, 12:34 by ad...@radsl.net:

>
> On 4/2/2021 2:59 AM, Michael Niedermayer wrote:
>
>> Hi all
>>
>> We still need to choose the name for 4.4
>> previous unused suggestions where:
>> Von Neumann, Lorentz, Poincaré, Desitter, De Broglie, Gauss, Galois, 
>> Viterbi, Darwin
>>
>> Feel free to reply with name suggestions
>> If theres a tie then i will randomly pick amongth the tied, i assume all 
>> previous
>> suggestions where suggested exactly once already.
>>
>> I plan to make the release today or tomorrow unless major bugfixes are
>> still pending. I probably wont have time sunday / monday for making the
>> release
>>
>> Thanks
>>
> version 4.4 Plandemic
>

Plandemic +1
Rao +1
Von Neumann -1, it's the least inspired name possible.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

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

[FFmpeg-devel] [PATCH 3/7] lavc/pngdec: remove unnecessary context variables

2021-04-02 Thread Anton Khirnov
Do not store the image buffer pointer/linesize in the context, just
access them directly from the frame.
Stop assuming that linesize is the same for the current and last frame.
---
 libavcodec/pngdec.c | 36 +---
 1 file changed, 17 insertions(+), 19 deletions(-)

diff --git a/libavcodec/pngdec.c b/libavcodec/pngdec.c
index 095e4e86c2..ff705ef48a 100644
--- a/libavcodec/pngdec.c
+++ b/libavcodec/pngdec.c
@@ -77,8 +77,6 @@ typedef struct PNGDecContext {
 int has_trns;
 uint8_t transparent_color_be[6];
 
-uint8_t *image_buf;
-int image_linesize;
 uint32_t palette[256];
 uint8_t *crow_buf;
 uint8_t *last_row;
@@ -330,27 +328,27 @@ static int percent_missing(PNGDecContext *s)
 }
 
 /* process exactly one decompressed row */
-static void png_handle_row(PNGDecContext *s)
+static void png_handle_row(PNGDecContext *s, uint8_t *dst, ptrdiff_t 
dst_stride)
 {
 uint8_t *ptr, *last_row;
 int got_line;
 
 if (!s->interlace_type) {
-ptr = s->image_buf + s->image_linesize * (s->y + s->y_offset) + 
s->x_offset * s->bpp;
+ptr = dst + dst_stride * (s->y + s->y_offset) + s->x_offset * s->bpp;
 if (s->y == 0)
 last_row = s->last_row;
 else
-last_row = ptr - s->image_linesize;
+last_row = ptr - dst_stride;
 
 ff_png_filter_row(&s->dsp, ptr, s->crow_buf[0], s->crow_buf + 1,
   last_row, s->row_size, s->bpp);
 /* loco lags by 1 row so that it doesn't interfere with top prediction 
*/
 if (s->filter_type == PNG_FILTER_TYPE_LOCO && s->y > 0) {
 if (s->bit_depth == 16) {
-deloco_rgb16((uint16_t *)(ptr - s->image_linesize), 
s->row_size / 2,
+deloco_rgb16((uint16_t *)(ptr - dst_stride), s->row_size / 2,
  s->color_type == PNG_COLOR_TYPE_RGB_ALPHA);
 } else {
-deloco_rgb8(ptr - s->image_linesize, s->row_size,
+deloco_rgb8(ptr - dst_stride, s->row_size,
 s->color_type == PNG_COLOR_TYPE_RGB_ALPHA);
 }
 }
@@ -370,7 +368,7 @@ static void png_handle_row(PNGDecContext *s)
 } else {
 got_line = 0;
 for (;;) {
-ptr = s->image_buf + s->image_linesize * (s->y + s->y_offset) + 
s->x_offset * s->bpp;
+ptr = dst + dst_stride * (s->y + s->y_offset) + s->x_offset * 
s->bpp;
 if ((ff_png_pass_ymask[s->pass] << (s->y & 7)) & 0x80) {
 /* if we already read one row, it is time to stop to
  * wait for the next one */
@@ -411,7 +409,8 @@ the_end:;
 }
 }
 
-static int png_decode_idat(PNGDecContext *s, int length)
+static int png_decode_idat(PNGDecContext *s, int length,
+   uint8_t *dst, ptrdiff_t dst_stride)
 {
 int ret;
 s->zstream.avail_in = FFMIN(length, bytestream2_get_bytes_left(&s->gb));
@@ -427,7 +426,7 @@ static int png_decode_idat(PNGDecContext *s, int length)
 }
 if (s->zstream.avail_out == 0) {
 if (!(s->pic_state & PNG_ALLIMAGE)) {
-png_handle_row(s);
+png_handle_row(s, dst, dst_stride);
 }
 s->zstream.avail_out = s->crow_size;
 s->zstream.next_out  = s->crow_buf;
@@ -732,8 +731,7 @@ static int decode_idat_chunk(AVCodecContext *avctx, 
PNGDecContext *s,
 }
 ff_dlog(avctx, "row_size=%d crow_size =%d\n",
 s->row_size, s->crow_size);
-s->image_buf  = p->data[0];
-s->image_linesize = p->linesize[0];
+
 /* copy the palette if needed */
 if (avctx->pix_fmt == AV_PIX_FMT_PAL8)
 memcpy(p->data[1], s->palette, 256 * sizeof(uint32_t));
@@ -764,7 +762,7 @@ static int decode_idat_chunk(AVCodecContext *avctx, 
PNGDecContext *s,
 if (s->has_trns && s->color_type != PNG_COLOR_TYPE_PALETTE)
 s->bpp -= byte_depth;
 
-ret = png_decode_idat(s, length);
+ret = png_decode_idat(s, length, p->data[0], p->linesize[0]);
 
 if (s->has_trns && s->color_type != PNG_COLOR_TYPE_PALETTE)
 s->bpp += byte_depth;
@@ -913,7 +911,7 @@ static void handle_small_bpp(PNGDecContext *s, AVFrame *p)
 pd[8*i + 1]= (pd[i]>>6) & 1;
 pd[8*i + 0]=  pd[i]>>7;
 }
-pd += s->image_linesize;
+pd += p->linesize[0];
 }
 } else if (s->bits_per_pixel == 2) {
 int i, j;
@@ -941,7 +939,7 @@ static void handle_small_bpp(PNGDecContext *s, AVFrame *p)
 pd[4*i + 0]= ( pd[i]>>6 )*0x55;
 }
 }
-pd += s->image_linesize;
+pd += p->linesize[0];
 }
 } else if (s->bits_per_pixel == 4) {
 int i, j;
@@ -961,7 +959,7 @@ static void handle_small_bpp(PNGDecContext *s, AVFrame *p)
 pd[2*i + 0] = (pd[i] >> 4) * 0x11;
 }
 

[FFmpeg-devel] [PATCH 1/7] tests/fate: add a test for APNG_DISPOSE_OP_BACKGROUND

2021-04-02 Thread Anton Khirnov
---
 tests/fate/apng.mak| 3 +++
 tests/ref/fate/apng-dispose-background | 8 
 2 files changed, 11 insertions(+)
 create mode 100644 tests/ref/fate/apng-dispose-background

diff --git a/tests/fate/apng.mak b/tests/fate/apng.mak
index 0a5f542f19..901fc0a10e 100644
--- a/tests/fate/apng.mak
+++ b/tests/fate/apng.mak
@@ -7,6 +7,9 @@ fate-apng-osample: CMD = framecrc -i 
$(TARGET_SAMPLES)/apng/o_sample.png
 FATE_APNG += fate-apng-dispose-previous
 fate-apng-dispose-previous: CMD = framecrc -i 
$(TARGET_SAMPLES)/apng/apng_out_of_order_frames.png
 
+FATE_APNG += fate-apng-dispose-background
+fate-apng-dispose-background: CMD = framecrc -i $(TARGET_SAMPLES)/apng/015.png
+
 FATE_APNG-$(call DEMDEC, APNG, APNG) += $(FATE_APNG)
 
 FATE_SAMPLES_FFMPEG += $(FATE_APNG-yes)
diff --git a/tests/ref/fate/apng-dispose-background 
b/tests/ref/fate/apng-dispose-background
new file mode 100644
index 00..41e6d0fe2a
--- /dev/null
+++ b/tests/ref/fate/apng-dispose-background
@@ -0,0 +1,8 @@
+#tb 0: 1/10
+#media_type 0: video
+#codec_id 0: rawvideo
+#dimensions 0: 128x64
+#sar 0: 0/1
+0,  0,  0,1,32768, 0x2d11c3b1
+0,  1,  1,1,32768, 0x2d11c3b1
+0,  2,  2,1,32768, 0x6d15d2c1
-- 
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 2/7] lavc/pngdec: perform APNG blending in-place

2021-04-02 Thread Anton Khirnov
Saves an allocation+free and two frame copies per each frame.
---
 libavcodec/pngdec.c | 51 +
 1 file changed, 28 insertions(+), 23 deletions(-)

diff --git a/libavcodec/pngdec.c b/libavcodec/pngdec.c
index 63c22063d9..095e4e86c2 100644
--- a/libavcodec/pngdec.c
+++ b/libavcodec/pngdec.c
@@ -1068,8 +1068,12 @@ static void handle_p_frame_png(PNGDecContext *s, AVFrame 
*p)
 static int handle_p_frame_apng(AVCodecContext *avctx, PNGDecContext *s,
AVFrame *p)
 {
+uint8_t   *dst= p->data[0];
+ptrdiff_t  dst_stride = p->linesize[0];
+const uint8_t *src= s->last_picture.f->data[0];
+ptrdiff_t  src_stride = s->last_picture.f->linesize[0];
+
 size_t x, y;
-uint8_t *buffer;
 
 if (s->blend_op == APNG_BLEND_OP_OVER &&
 avctx->pix_fmt != AV_PIX_FMT_RGBA &&
@@ -1089,26 +1093,32 @@ static int handle_p_frame_apng(AVCodecContext *avctx, 
PNGDecContext *s,
 if (ret < 0)
 return ret;
 
+src= s->last_picture.f->data[0];
+src_stride = s->last_picture.f->linesize[0];
+
 for (y = s->last_y_offset; y < s->last_y_offset + s->last_h; y++) {
-memset(s->last_picture.f->data[0] + s->image_linesize * y +
+memset(s->last_picture.f->data[0] + src_stride * y +
s->bpp * s->last_x_offset, 0, s->bpp * s->last_w);
 }
 }
 
-buffer = av_memdup(s->last_picture.f->data[0], s->image_linesize * 
s->height);
-if (!buffer)
-return AVERROR(ENOMEM);
+// copy unchanged rectangles from the last frame
+for (y = 0; y < s->y_offset; y++)
+memcpy(dst + y * dst_stride, src + y * src_stride, p->width * s->bpp);
+for (y = s->y_offset; y < s->y_offset + s->cur_h; y++) {
+memcpy(dst + y * dst_stride, src + y * src_stride, s->x_offset * 
s->bpp);
+memcpy(dst + y * dst_stride + (s->x_offset + s->cur_w) * s->bpp,
+   src + y * src_stride + (s->x_offset + s->cur_w) * s->bpp,
+   (p->width - s->cur_w - s->x_offset) * s->bpp);
+}
+for (y = s->y_offset + s->cur_h; y < p->height; y++)
+memcpy(dst + y * dst_stride, src + y * src_stride, p->width * s->bpp);
 
-// Perform blending
-if (s->blend_op == APNG_BLEND_OP_SOURCE) {
-for (y = s->y_offset; y < s->y_offset + s->cur_h; ++y) {
-size_t row_start = s->image_linesize * y + s->bpp * s->x_offset;
-memcpy(buffer + row_start, p->data[0] + row_start, s->bpp * 
s->cur_w);
-}
-} else { // APNG_BLEND_OP_OVER
+if (s->blend_op == APNG_BLEND_OP_OVER) {
+// Perform blending
 for (y = s->y_offset; y < s->y_offset + s->cur_h; ++y) {
-uint8_t *foreground = p->data[0] + s->image_linesize * y + s->bpp 
* s->x_offset;
-uint8_t *background = buffer + s->image_linesize * y + s->bpp * 
s->x_offset;
+uint8_t   *foreground = dst + dst_stride * y + s->bpp * 
s->x_offset;
+const uint8_t *background = src + src_stride * y + s->bpp * 
s->x_offset;
 for (x = s->x_offset; x < s->x_offset + s->cur_w; ++x, foreground 
+= s->bpp, background += s->bpp) {
 size_t b;
 uint8_t foreground_alpha, background_alpha, output_alpha;
@@ -1135,18 +1145,17 @@ static int handle_p_frame_apng(AVCodecContext *avctx, 
PNGDecContext *s,
 break;
 }
 
-if (foreground_alpha == 0)
+if (foreground_alpha == 255)
 continue;
 
-if (foreground_alpha == 255) {
-memcpy(background, foreground, s->bpp);
+if (foreground_alpha == 0) {
+memcpy(foreground, background, s->bpp);
 continue;
 }
 
 if (avctx->pix_fmt == AV_PIX_FMT_PAL8) {
 // TODO: Alpha blending with PAL8 will likely need the 
entire image converted over to RGBA first
 avpriv_request_sample(avctx, "Alpha blending palette 
samples");
-background[0] = foreground[0];
 continue;
 }
 
@@ -1164,15 +1173,11 @@ static int handle_p_frame_apng(AVCodecContext *avctx, 
PNGDecContext *s,
 }
 }
 output[b] = output_alpha;
-memcpy(background, output, s->bpp);
+memcpy(foreground, output, s->bpp);
 }
 }
 }
 
-// Copy blended buffer into the frame and free
-memcpy(p->data[0], buffer, s->image_linesize * s->height);
-av_free(buffer);
-
 return 0;
 }
 
-- 
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 4/7] lavc/pngdec: restructure exporting frame meta/side data

2021-04-02 Thread Anton Khirnov
This data cannot be stored in PNGDecContext.picture, because the
corresponding chunks may be read after the call to
ff_thread_finish_setup(), at which point modifying shared context data
is a race.

Store intermediate state in the context and then write it directly to
the output frame.

Fixes exporting frame metadata after 5663301560
Fixes #8972

Found-by: Andreas Rheinhardt 
---
 libavcodec/pngdec.c | 162 
 1 file changed, 119 insertions(+), 43 deletions(-)

diff --git a/libavcodec/pngdec.c b/libavcodec/pngdec.c
index ff705ef48a..f3295688c6 100644
--- a/libavcodec/pngdec.c
+++ b/libavcodec/pngdec.c
@@ -57,6 +57,18 @@ typedef struct PNGDecContext {
 ThreadFrame last_picture;
 ThreadFrame picture;
 
+AVDictionary *frame_metadata;
+
+uint8_t  iccp_name[82];
+uint8_t *iccp_data;
+size_t   iccp_data_len;
+
+int stereo_mode;
+
+int have_chrm;
+uint32_t white_point[2];
+uint32_t display_primaries[3][2];
+
 enum PNGHeaderState hdr_state;
 enum PNGImageState pic_state;
 int width, height;
@@ -508,8 +520,7 @@ static uint8_t *iso88591_to_utf8(const uint8_t *in, size_t 
size_in)
 return out;
 }
 
-static int decode_text_chunk(PNGDecContext *s, uint32_t length, int compressed,
- AVDictionary **dict)
+static int decode_text_chunk(PNGDecContext *s, uint32_t length, int compressed)
 {
 int ret, method;
 const uint8_t *data= s->gb.buffer;
@@ -551,7 +562,7 @@ static int decode_text_chunk(PNGDecContext *s, uint32_t 
length, int compressed,
 return AVERROR(ENOMEM);
 }
 
-av_dict_set(dict, kw_utf8, txt_utf8,
+av_dict_set(&s->frame_metadata, kw_utf8, txt_utf8,
 AV_DICT_DONT_STRDUP_KEY | AV_DICT_DONT_STRDUP_VAL);
 return 0;
 }
@@ -849,21 +860,21 @@ static int decode_trns_chunk(AVCodecContext *avctx, 
PNGDecContext *s,
 static int decode_iccp_chunk(PNGDecContext *s, int length, AVFrame *f)
 {
 int ret, cnt = 0;
-uint8_t *data, profile_name[82];
 AVBPrint bp;
-AVFrameSideData *sd;
 
-while ((profile_name[cnt++] = bytestream2_get_byte(&s->gb)) && cnt < 81);
+while ((s->iccp_name[cnt++] = bytestream2_get_byte(&s->gb)) && cnt < 81);
 if (cnt > 80) {
 av_log(s->avctx, AV_LOG_ERROR, "iCCP with invalid name!\n");
-return AVERROR_INVALIDDATA;
+ret = AVERROR_INVALIDDATA;
+goto fail;
 }
 
 length = FFMAX(length - cnt, 0);
 
 if (bytestream2_get_byte(&s->gb) != 0) {
 av_log(s->avctx, AV_LOG_ERROR, "iCCP with invalid compression!\n");
-return AVERROR_INVALIDDATA;
+ret =  AVERROR_INVALIDDATA;
+goto fail;
 }
 
 length = FFMAX(length - 1, 0);
@@ -871,24 +882,19 @@ static int decode_iccp_chunk(PNGDecContext *s, int 
length, AVFrame *f)
 if ((ret = decode_zbuf(&bp, s->gb.buffer, s->gb.buffer + length)) < 0)
 return ret;
 
-ret = av_bprint_finalize(&bp, (char **)&data);
+av_freep(&s->iccp_data);
+ret = av_bprint_finalize(&bp, (char **)&s->iccp_data);
 if (ret < 0)
 return ret;
-
-sd = av_frame_new_side_data(f, AV_FRAME_DATA_ICC_PROFILE, bp.len);
-if (!sd) {
-av_free(data);
-return AVERROR(ENOMEM);
-}
-
-av_dict_set(&sd->metadata, "name", profile_name, 0);
-memcpy(sd->data, data, bp.len);
-av_free(data);
+s->iccp_data_len = bp.len;
 
 /* ICC compressed data and CRC */
 bytestream2_skip(&s->gb, length + 4);
 
 return 0;
+fail:
+s->iccp_name[0] = 0;
+return ret;
 }
 
 static void handle_small_bpp(PNGDecContext *s, AVFrame *p)
@@ -1183,7 +1189,6 @@ static int decode_frame_common(AVCodecContext *avctx, 
PNGDecContext *s,
AVFrame *p, const AVPacket *avpkt)
 {
 const AVCRC *crc_tab = av_crc_get_table(AV_CRC_32_IEEE_LE);
-AVDictionary **metadatap = NULL;
 uint32_t tag, length;
 int decode_next_dat = 0;
 int i, ret;
@@ -1251,7 +1256,6 @@ static int decode_frame_common(AVCodecContext *avctx, 
PNGDecContext *s,
 }
 }
 
-metadatap = &p->metadata;
 switch (tag) {
 case MKTAG('I', 'H', 'D', 'R'):
 if ((ret = decode_ihdr_chunk(avctx, s, length)) < 0)
@@ -1293,26 +1297,20 @@ static int decode_frame_common(AVCodecContext *avctx, 
PNGDecContext *s,
 goto skip_tag;
 break;
 case MKTAG('t', 'E', 'X', 't'):
-if (decode_text_chunk(s, length, 0, metadatap) < 0)
+if (decode_text_chunk(s, length, 0) < 0)
 av_log(avctx, AV_LOG_WARNING, "Broken tEXt chunk\n");
 bytestream2_skip(&s->gb, length + 4);
 break;
 case MKTAG('z', 'T', 'X', 't'):
-if (decode_text_chunk(s, length, 1, metadatap) < 0)
+if (decode_text_chunk(s, length, 1) < 0)
 av_log(avctx, AV_LOG_WARNING, "Broken zTXt chunk\n");
 bytestream2_skip(&s->gb, length + 4

[FFmpeg-devel] [PATCH 5/7] tests/fate: add tests for PNG side/meta data

2021-04-02 Thread Anton Khirnov
---
 tests/fate/image.mak  |  8 ++
 tests/ref/fate/png-frame-metadata |  4 +++
 tests/ref/fate/png-side-data  | 46 +++
 3 files changed, 58 insertions(+)
 create mode 100644 tests/ref/fate/png-frame-metadata
 create mode 100644 tests/ref/fate/png-side-data

diff --git a/tests/fate/image.mak b/tests/fate/image.mak
index eca8d5ab2c..226e190262 100644
--- a/tests/fate/image.mak
+++ b/tests/fate/image.mak
@@ -358,6 +358,14 @@ $(foreach CLSP,$(PNG_COLORSPACES),$(eval $(call 
FATE_IMGSUITE_PNG,$(CLSP
 FATE_PNG += fate-png-int-rgb24
 fate-png-int-rgb24: CMD = framecrc -i 
$(TARGET_SAMPLES)/png1/lena-int_rgb24.png -sws_flags +accurate_rnd+bitexact
 
+FATE_PNG += fate-png-frame-metadata
+fate-png-frame-metadata: CMD = run ffprobe$(PROGSSUF)$(EXESUF) -show_entries 
frame_tags \
+-i $(TARGET_SAMPLES)/filter/pixelart0.png
+
+FATE_PNG += fate-png-side-data
+fate-png-side-data: CMD = run ffprobe$(PROGSSUF)$(EXESUF) -show_frames \
+-i $(TARGET_SAMPLES)/png1/lena-int_rgb24.png
+
 FATE_PNG-$(call DEMDEC, IMAGE2, PNG) += $(FATE_PNG)
 FATE_IMAGE += $(FATE_PNG-yes)
 fate-png: $(FATE_PNG-yes)
diff --git a/tests/ref/fate/png-frame-metadata 
b/tests/ref/fate/png-frame-metadata
new file mode 100644
index 00..7c6d1916eb
--- /dev/null
+++ b/tests/ref/fate/png-frame-metadata
@@ -0,0 +1,4 @@
+[FRAME]
+TAG:gamma=45455/10
+TAG:Software=GLDPNG ver 3.4
+[/FRAME]
diff --git a/tests/ref/fate/png-side-data b/tests/ref/fate/png-side-data
new file mode 100644
index 00..c3d1030f96
--- /dev/null
+++ b/tests/ref/fate/png-side-data
@@ -0,0 +1,46 @@
+[FRAME]
+media_type=video
+stream_index=0
+key_frame=1
+pkt_pts=0
+pkt_pts_time=0.00
+pkt_dts=0
+pkt_dts_time=0.00
+best_effort_timestamp=0
+best_effort_timestamp_time=0.00
+pkt_duration=1
+pkt_duration_time=0.04
+pkt_pos=0
+pkt_size=40194
+width=128
+height=128
+pix_fmt=rgb24
+sample_aspect_ratio=1:1
+pict_type=I
+coded_picture_number=0
+display_picture_number=0
+interlaced_frame=1
+top_field_first=0
+repeat_pict=0
+color_range=pc
+color_space=unknown
+color_primaries=unknown
+color_transfer=unknown
+chroma_location=unspecified
+[SIDE_DATA]
+side_data_type=ICC profile
+name=Photoshop ICC profile
+size=3144
+[/SIDE_DATA]
+[SIDE_DATA]
+side_data_type=Mastering display metadata
+red_x=63999/10
+red_y=33001/10
+green_x=3/10
+green_y=6/10
+blue_x=15000/10
+blue_y=5999/10
+white_point_x=31269/10
+white_point_y=32899/10
+[/SIDE_DATA]
+[/FRAME]
-- 
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 7/7] lavc/pngdec: use a separate bytestream reader for each chunk

2021-04-02 Thread Anton Khirnov
This makes sure that reading a truncated chunk will never overflow into
the following chunk. It also allows to remove many repeated lines
skipping over the trailing crc checksum.
---
 libavcodec/pngdec.c | 166 +++-
 1 file changed, 72 insertions(+), 94 deletions(-)

diff --git a/libavcodec/pngdec.c b/libavcodec/pngdec.c
index 0ff81d740c..562c5ffea4 100644
--- a/libavcodec/pngdec.c
+++ b/libavcodec/pngdec.c
@@ -421,13 +421,12 @@ the_end:;
 }
 }
 
-static int png_decode_idat(PNGDecContext *s, int length,
+static int png_decode_idat(PNGDecContext *s, GetByteContext *gb,
uint8_t *dst, ptrdiff_t dst_stride)
 {
 int ret;
-s->zstream.avail_in = FFMIN(length, bytestream2_get_bytes_left(&s->gb));
-s->zstream.next_in  = s->gb.buffer;
-bytestream2_skip(&s->gb, length);
+s->zstream.avail_in = bytestream2_get_bytes_left(gb);
+s->zstream.next_in  = gb->buffer;
 
 /* decode one line if possible */
 while (s->zstream.avail_in > 0) {
@@ -520,11 +519,11 @@ static uint8_t *iso88591_to_utf8(const uint8_t *in, 
size_t size_in)
 return out;
 }
 
-static int decode_text_chunk(PNGDecContext *s, uint32_t length, int compressed)
+static int decode_text_chunk(PNGDecContext *s, GetByteContext *gb, int 
compressed)
 {
 int ret, method;
-const uint8_t *data= s->gb.buffer;
-const uint8_t *data_end= data + length;
+const uint8_t *data= gb->buffer;
+const uint8_t *data_end= gb->buffer_end;
 const uint8_t *keyword = data;
 const uint8_t *keyword_end = memchr(keyword, 0, data_end - keyword);
 uint8_t *kw_utf8 = NULL, *text, *txt_utf8 = NULL;
@@ -568,9 +567,9 @@ static int decode_text_chunk(PNGDecContext *s, uint32_t 
length, int compressed)
 }
 
 static int decode_ihdr_chunk(AVCodecContext *avctx, PNGDecContext *s,
- uint32_t length)
+ GetByteContext *gb)
 {
-if (length != 13)
+if (bytestream2_get_bytes_left(gb) != 13)
 return AVERROR_INVALIDDATA;
 
 if (s->pic_state & PNG_IDAT) {
@@ -583,28 +582,27 @@ static int decode_ihdr_chunk(AVCodecContext *avctx, 
PNGDecContext *s,
 return AVERROR_INVALIDDATA;
 }
 
-s->width  = s->cur_w = bytestream2_get_be32(&s->gb);
-s->height = s->cur_h = bytestream2_get_be32(&s->gb);
+s->width  = s->cur_w = bytestream2_get_be32(gb);
+s->height = s->cur_h = bytestream2_get_be32(gb);
 if (av_image_check_size(s->width, s->height, 0, avctx)) {
 s->cur_w = s->cur_h = s->width = s->height = 0;
 av_log(avctx, AV_LOG_ERROR, "Invalid image size\n");
 return AVERROR_INVALIDDATA;
 }
-s->bit_depth= bytestream2_get_byte(&s->gb);
+s->bit_depth= bytestream2_get_byte(gb);
 if (s->bit_depth != 1 && s->bit_depth != 2 && s->bit_depth != 4 &&
 s->bit_depth != 8 && s->bit_depth != 16) {
 av_log(avctx, AV_LOG_ERROR, "Invalid bit depth\n");
 goto error;
 }
-s->color_type   = bytestream2_get_byte(&s->gb);
-s->compression_type = bytestream2_get_byte(&s->gb);
+s->color_type   = bytestream2_get_byte(gb);
+s->compression_type = bytestream2_get_byte(gb);
 if (s->compression_type) {
 av_log(avctx, AV_LOG_ERROR, "Invalid compression method %d\n", 
s->compression_type);
 goto error;
 }
-s->filter_type  = bytestream2_get_byte(&s->gb);
-s->interlace_type   = bytestream2_get_byte(&s->gb);
-bytestream2_skip(&s->gb, 4); /* crc */
+s->filter_type  = bytestream2_get_byte(gb);
+s->interlace_type   = bytestream2_get_byte(gb);
 s->hdr_state |= PNG_IHDR;
 if (avctx->debug & FF_DEBUG_PICT_INFO)
 av_log(avctx, AV_LOG_DEBUG, "width=%d height=%d depth=%d color_type=%d 
"
@@ -619,24 +617,24 @@ error:
 return AVERROR_INVALIDDATA;
 }
 
-static int decode_phys_chunk(AVCodecContext *avctx, PNGDecContext *s)
+static int decode_phys_chunk(AVCodecContext *avctx, PNGDecContext *s,
+ GetByteContext *gb)
 {
 if (s->pic_state & PNG_IDAT) {
 av_log(avctx, AV_LOG_ERROR, "pHYs after IDAT\n");
 return AVERROR_INVALIDDATA;
 }
-avctx->sample_aspect_ratio.num = bytestream2_get_be32(&s->gb);
-avctx->sample_aspect_ratio.den = bytestream2_get_be32(&s->gb);
+avctx->sample_aspect_ratio.num = bytestream2_get_be32(gb);
+avctx->sample_aspect_ratio.den = bytestream2_get_be32(gb);
 if (avctx->sample_aspect_ratio.num < 0 || avctx->sample_aspect_ratio.den < 
0)
 avctx->sample_aspect_ratio = (AVRational){ 0, 1 };
-bytestream2_skip(&s->gb, 1); /* unit specifier */
-bytestream2_skip(&s->gb, 4); /* crc */
+bytestream2_skip(gb, 1); /* unit specifier */
 
 return 0;
 }
 
 static int decode_idat_chunk(AVCodecContext *avctx, PNGDecContext *s,
- uint32_t length, AVFrame *p)
+ GetByteContext *gb, AVFram

[FFmpeg-devel] [PATCH 6/7] lavc/pngdec: improve chunk length check

2021-04-02 Thread Anton Khirnov
The length does not cover the chunk type or CRC.
---
 libavcodec/pngdec.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/libavcodec/pngdec.c b/libavcodec/pngdec.c
index f3295688c6..0ff81d740c 100644
--- a/libavcodec/pngdec.c
+++ b/libavcodec/pngdec.c
@@ -1217,7 +1217,7 @@ static int decode_frame_common(AVCodecContext *avctx, 
PNGDecContext *s,
 }
 
 length = bytestream2_get_be32(&s->gb);
-if (length > 0x7fff || length > 
bytestream2_get_bytes_left(&s->gb)) {
+if (length > 0x7fff || length + 8 > 
bytestream2_get_bytes_left(&s->gb)) {
 av_log(avctx, AV_LOG_ERROR, "chunk too big\n");
 ret = AVERROR_INVALIDDATA;
 goto fail;
-- 
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 2/7] lavc/pngdec: perform APNG blending in-place

2021-04-02 Thread James Almer

On 4/2/2021 11:40 AM, Anton Khirnov wrote:

Saves an allocation+free and two frame copies per each frame.
---
  libavcodec/pngdec.c | 51 +
  1 file changed, 28 insertions(+), 23 deletions(-)

diff --git a/libavcodec/pngdec.c b/libavcodec/pngdec.c
index 63c22063d9..095e4e86c2 100644
--- a/libavcodec/pngdec.c
+++ b/libavcodec/pngdec.c
@@ -1068,8 +1068,12 @@ static void handle_p_frame_png(PNGDecContext *s, AVFrame 
*p)
  static int handle_p_frame_apng(AVCodecContext *avctx, PNGDecContext *s,
 AVFrame *p)
  {
+uint8_t   *dst= p->data[0];
+ptrdiff_t  dst_stride = p->linesize[0];
+const uint8_t *src= s->last_picture.f->data[0];
+ptrdiff_t  src_stride = s->last_picture.f->linesize[0];
+
  size_t x, y;
-uint8_t *buffer;
  
  if (s->blend_op == APNG_BLEND_OP_OVER &&

  avctx->pix_fmt != AV_PIX_FMT_RGBA &&
@@ -1089,26 +1093,32 @@ static int handle_p_frame_apng(AVCodecContext *avctx, 
PNGDecContext *s,
  if (ret < 0)
  return ret;
  
+src= s->last_picture.f->data[0];

+src_stride = s->last_picture.f->linesize[0];


Is calling av_frame_make_writable(s->last_picture.f) valid at all? 
Shouldn't the frame's buffer be freed with ff_thread_release_buffer()? 
Especially if a non threading safe get_buffer2() callback was used.


Considering you can't call ff_thread_get_buffer() at this point to get a 
new writable buffer to av_frame_copy() to, since this is long after 
ff_thread_finish_setup() was called, not sure what else could be done.



+
  for (y = s->last_y_offset; y < s->last_y_offset + s->last_h; y++) {
-memset(s->last_picture.f->data[0] + s->image_linesize * y +
+memset(s->last_picture.f->data[0] + src_stride * y +
 s->bpp * s->last_x_offset, 0, s->bpp * s->last_w);
  }
  }
  
-buffer = av_memdup(s->last_picture.f->data[0], s->image_linesize * s->height);

-if (!buffer)
-return AVERROR(ENOMEM);
+// copy unchanged rectangles from the last frame
+for (y = 0; y < s->y_offset; y++)
+memcpy(dst + y * dst_stride, src + y * src_stride, p->width * s->bpp);
+for (y = s->y_offset; y < s->y_offset + s->cur_h; y++) {
+memcpy(dst + y * dst_stride, src + y * src_stride, s->x_offset * 
s->bpp);
+memcpy(dst + y * dst_stride + (s->x_offset + s->cur_w) * s->bpp,
+   src + y * src_stride + (s->x_offset + s->cur_w) * s->bpp,
+   (p->width - s->cur_w - s->x_offset) * s->bpp);
+}
+for (y = s->y_offset + s->cur_h; y < p->height; y++)
+memcpy(dst + y * dst_stride, src + y * src_stride, p->width * s->bpp);
  
-// Perform blending

-if (s->blend_op == APNG_BLEND_OP_SOURCE) {
-for (y = s->y_offset; y < s->y_offset + s->cur_h; ++y) {
-size_t row_start = s->image_linesize * y + s->bpp * s->x_offset;
-memcpy(buffer + row_start, p->data[0] + row_start, s->bpp * 
s->cur_w);
-}
-} else { // APNG_BLEND_OP_OVER
+if (s->blend_op == APNG_BLEND_OP_OVER) {
+// Perform blending
  for (y = s->y_offset; y < s->y_offset + s->cur_h; ++y) {
-uint8_t *foreground = p->data[0] + s->image_linesize * y + s->bpp * 
s->x_offset;
-uint8_t *background = buffer + s->image_linesize * y + s->bpp * 
s->x_offset;
+uint8_t   *foreground = dst + dst_stride * y + s->bpp * 
s->x_offset;
+const uint8_t *background = src + src_stride * y + s->bpp * 
s->x_offset;
  for (x = s->x_offset; x < s->x_offset + s->cur_w; ++x, foreground += 
s->bpp, background += s->bpp) {
  size_t b;
  uint8_t foreground_alpha, background_alpha, output_alpha;
@@ -1135,18 +1145,17 @@ static int handle_p_frame_apng(AVCodecContext *avctx, 
PNGDecContext *s,
  break;
  }
  
-if (foreground_alpha == 0)

+if (foreground_alpha == 255)
  continue;
  
-if (foreground_alpha == 255) {

-memcpy(background, foreground, s->bpp);
+if (foreground_alpha == 0) {
+memcpy(foreground, background, s->bpp);
  continue;
  }
  
  if (avctx->pix_fmt == AV_PIX_FMT_PAL8) {

  // TODO: Alpha blending with PAL8 will likely need the 
entire image converted over to RGBA first
  avpriv_request_sample(avctx, "Alpha blending palette 
samples");
-background[0] = foreground[0];
  continue;
  }
  
@@ -1164,15 +1173,11 @@ static int handle_p_frame_apng(AVCodecContext *avctx, PNGDecContext *s,

  }
  }
  output[b] = output_alpha;
-memcpy(background, output, s->bpp);
+   

Re: [FFmpeg-devel] 4.4 Release Name

2021-04-02 Thread Paul B Mahol
Name for new version should be: Mr. Miser.



On Fri, Apr 2, 2021 at 3:49 PM Lynne  wrote:

> Apr 2, 2021, 12:34 by ad...@radsl.net:
>
> >
> > On 4/2/2021 2:59 AM, Michael Niedermayer wrote:
> >
> >> Hi all
> >>
> >> We still need to choose the name for 4.4
> >> previous unused suggestions where:
> >> Von Neumann, Lorentz, Poincaré, Desitter, De Broglie, Gauss, Galois,
> Viterbi, Darwin
> >>
> >> Feel free to reply with name suggestions
> >> If theres a tie then i will randomly pick amongth the tied, i assume
> all previous
> >> suggestions where suggested exactly once already.
> >>
> >> I plan to make the release today or tomorrow unless major bugfixes are
> >> still pending. I probably wont have time sunday / monday for making the
> >> release
> >>
> >> Thanks
> >>
> > version 4.4 Plandemic
> >
>
> Plandemic +1
> Rao +1
> Von Neumann -1, it's the least inspired name possible.
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
> To unsubscribe, visit link above, or email
> ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

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

[FFmpeg-devel] [PATCH 1/2] avcodec/h264_metadata_bsf: Don't add AUD to extradata

2021-04-02 Thread Andreas Rheinhardt
This is a regression since switching to the generic CBS BSF code.

Signed-off-by: Andreas Rheinhardt 
---
Will apply this patchset soon.

 libavcodec/h264_metadata_bsf.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/libavcodec/h264_metadata_bsf.c b/libavcodec/h264_metadata_bsf.c
index 6e58c0be1d..06d23e3142 100644
--- a/libavcodec/h264_metadata_bsf.c
+++ b/libavcodec/h264_metadata_bsf.c
@@ -466,7 +466,7 @@ static int h264_metadata_update_fragment(AVBSFContext *bsf, 
AVPacket *pkt,
 if (ctx->aud == BSF_ELEMENT_REMOVE)
 ff_cbs_delete_unit(au, 0);
 } else {
-if (ctx->aud == BSF_ELEMENT_INSERT) {
+if (pkt && ctx->aud == BSF_ELEMENT_INSERT) {
 err = h264_metadata_insert_aud(bsf, au);
 if (err < 0)
 return err;
-- 
2.27.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] avcodec/av1_metadata_bsf: Check for the existence of units

2021-04-02 Thread Andreas Rheinhardt
Fixes a crash with ISOBMFF extradata containing no OBUs.

Signed-off-by: Andreas Rheinhardt 
---
 libavcodec/av1_metadata_bsf.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/libavcodec/av1_metadata_bsf.c b/libavcodec/av1_metadata_bsf.c
index 8cafe461d1..328db5c0da 100644
--- a/libavcodec/av1_metadata_bsf.c
+++ b/libavcodec/av1_metadata_bsf.c
@@ -120,7 +120,7 @@ static int av1_metadata_update_fragment(AVBSFContext *bsf, 
AVPacket *pkt,
 }
 
 // If a Temporal Delimiter is present, it must be the first OBU.
-if (frag->units[0].type == AV1_OBU_TEMPORAL_DELIMITER) {
+if (frag->nb_units && frag->units[0].type == AV1_OBU_TEMPORAL_DELIMITER) {
 if (ctx->td == BSF_ELEMENT_REMOVE)
 ff_cbs_delete_unit(frag, 0);
 } else if (pkt && ctx->td == BSF_ELEMENT_INSERT) {
-- 
2.27.0

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

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

Re: [FFmpeg-devel] [PATCH 3/3] avcodec/cfhd: More strictly check tag order and multiplicity

2021-04-02 Thread Paul B Mahol
I do not have time or motivation to deal with this and similar issues.

But applying band-aid solutions are not step forward.

On Fri, Apr 2, 2021 at 12:53 AM Michael Niedermayer 
wrote:

> On Fri, Apr 02, 2021 at 12:49:26AM +0200, Michael Niedermayer wrote:
> > On Fri, Apr 02, 2021 at 12:25:53AM +0200, Michael Niedermayer wrote:
> > > On Thu, Apr 01, 2021 at 09:22:23PM +0200, Paul B Mahol wrote:
> > > > Try this attached patch. I have not looked at all samples, as some
> allocate
> > > > too much memory for my system.
> > >
> > > > But this patch points where real bugs are, unlike yours patch which
> hides
> > > > real bugs even more.
> > >
> > > I would appreciate if cfhd wouldnt have so many real bugs.
> > > Your approach seems to be to fix what the fuzzer finds. What my patch
> was
> > > moving toward is to make the code more secure and robust not to fix
> individual
> > > bugs. My patch was never intended to be the end of such improvment,
> but with
> > > the first stage being rejected iam of course not putting time in the
> next ...
> > >
> > > but thats not so importrant now, whats important is the bugs here
> > > and your patch eliminates all of the current group but one. Thats good!
> > > Heres what remains:
> > > ffmpeg -threads 1 -i dec_fuzzer-30739.nut -f null -
> >
> > correction, the fuzzer found an alternative sample for 29754 which still
> crashes
> > this seems to also use less memory than the other remaining sample
> > will send the sample privatly
> >
> > [cfhd @ 0x16d92180] Invalid lowpass height
> > ==24087==at 0x123322D: VALGRIND_PRINTF_BACKTRACE (valgrind.h:6303)
> > ==24087==by 0x1233DEB: av_log_default_callback (log.c:397)
> > ==24087==by 0x1234092: av_vlog (log.c:432)
> > ==24087==by 0x1233EF1: av_log (log.c:411)
> > ==24087==by 0x82FCFB: cfhd_decode (cfhd.c:721)
> > ==24087==by 0x860064: decode_simple_internal (decode.c:327)
> > ==24087==by 0x860C9B: decode_simple_receive_frame (decode.c:526)
> > ==24087==by 0x860D95: decode_receive_frame_internal (decode.c:546)
> > ==24087==by 0x861019: avcodec_send_packet (decode.c:608)
> > ==24087==by 0x2525A7: decode (ffmpeg.c:2285)
> > ==24087==by 0x252DC7: decode_video (ffmpeg.c:2425)
> > ==24087==by 0x253EF3: process_input_packet (ffmpeg.c:2672)
> > ==24087==by 0x25BB79: process_input (ffmpeg.c:4606)
> > ==24087==by 0x25C06D: transcode_step (ffmpeg.c:4746)
> > ==24087==by 0x25C1D5: transcode (ffmpeg.c:4800)
> > ==24087==by 0x25CB3F: main (ffmpeg.c:5005)
> > Error while decoding stream #0:0: Invalid argument
> > ==24087==at 0x123322D: VALGRIND_PRINTF_BACKTRACE (valgrind.h:6303)
> > ==24087==by 0x1233DEB: av_log_default_callback (log.c:397)
> > ==24087==by 0x1234092: av_vlog (log.c:432)
> > ==24087==by 0x1233EF1: av_log (log.c:411)
> > ==24087==by 0x254285: process_input_packet (ffmpeg.c:2718)
> > ==24087==by 0x25BB79: process_input (ffmpeg.c:4606)
> > ==24087==by 0x25C06D: transcode_step (ffmpeg.c:4746)
> > ==24087==by 0x25C1D5: transcode (ffmpeg.c:4800)
> > ==24087==by 0x25CB3F: main (ffmpeg.c:5005)
> > [cfhd @ 0x16d92180] Invalid lowpass height
> > ==24087==at 0x123322D: VALGRIND_PRINTF_BACKTRACE (valgrind.h:6303)
> > ==24087==by 0x1233DEB: av_log_default_callback (log.c:397)
> > ==24087==by 0x1234092: av_vlog (log.c:432)
> > ==24087==by 0x1233EF1: av_log (log.c:411)
> > ==24087==by 0x82FCFB: cfhd_decode (cfhd.c:721)
> > ==24087==by 0x860064: decode_simple_internal (decode.c:327)
> > ==24087==by 0x860C9B: decode_simple_receive_frame (decode.c:526)
> > ==24087==by 0x860D95: decode_receive_frame_internal (decode.c:546)
> > ==24087==by 0x861019: avcodec_send_packet (decode.c:608)
> > ==24087==by 0x2525A7: decode (ffmpeg.c:2285)
> > ==24087==by 0x252DC7: decode_video (ffmpeg.c:2425)
> > ==24087==by 0x253EF3: process_input_packet (ffmpeg.c:2672)
> > ==24087==by 0x25BB79: process_input (ffmpeg.c:4606)
> > ==24087==by 0x25C06D: transcode_step (ffmpeg.c:4746)
> > ==24087==by 0x25C1D5: transcode (ffmpeg.c:4800)
> > ==24087==by 0x25CB3F: main (ffmpeg.c:5005)
> > Error while decoding stream #0:0: Invalid argument
> > ==24087==at 0x123322D: VALGRIND_PRINTF_BACKTRACE (valgrind.h:6303)
> > ==24087==by 0x1233DEB: av_log_default_callback (log.c:397)
> > ==24087==by 0x1234092: av_vlog (log.c:432)
> > ==24087==by 0x1233EF1: av_log (log.c:411)
> > ==24087==by 0x254285: process_input_packet (ffmpeg.c:2718)
> > ==24087==by 0x25BB79: process_input (ffmpeg.c:4606)
> > ==24087==by 0x25C06D: transcode_step (ffmpeg.c:4746)
> > ==24087==by 0x25C1D5: transcode (ffmpeg.c:4800)
> > ==24087==by 0x25CB3F: main (ffmpeg.c:5005)
> > [cfhd @ 0x16d92180] Sample format of 1039 is not implemented. Update
> your FFmpeg version to the newest one from Git. If the problem still
> occurs, it means that your file has a feature which has not been
> implemented.
> > Error while decoding s

Re: [FFmpeg-devel] [PATCH 1/2] avcodec/h264_metadata_bsf: Don't add AUD to extradata

2021-04-02 Thread James Almer

On 4/2/2021 12:38 PM, Andreas Rheinhardt wrote:

This is a regression since switching to the generic CBS BSF code.

Signed-off-by: Andreas Rheinhardt 
---
Will apply this patchset soon.

  libavcodec/h264_metadata_bsf.c | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/libavcodec/h264_metadata_bsf.c b/libavcodec/h264_metadata_bsf.c
index 6e58c0be1d..06d23e3142 100644
--- a/libavcodec/h264_metadata_bsf.c
+++ b/libavcodec/h264_metadata_bsf.c
@@ -466,7 +466,7 @@ static int h264_metadata_update_fragment(AVBSFContext *bsf, 
AVPacket *pkt,
  if (ctx->aud == BSF_ELEMENT_REMOVE)
  ff_cbs_delete_unit(au, 0);
  } else {
-if (ctx->aud == BSF_ELEMENT_INSERT) {
+if (pkt && ctx->aud == BSF_ELEMENT_INSERT) {
  err = h264_metadata_insert_aud(bsf, au);
  if (err < 0)
  return err;


LGTM. And please backport it, too.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

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

Re: [FFmpeg-devel] [PATCH 2/2] avcodec/av1_metadata_bsf: Check for the existence of units

2021-04-02 Thread James Almer

On 4/2/2021 12:39 PM, Andreas Rheinhardt wrote:

Fixes a crash with ISOBMFF extradata containing no OBUs.

Signed-off-by: Andreas Rheinhardt 
---
  libavcodec/av1_metadata_bsf.c | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/libavcodec/av1_metadata_bsf.c b/libavcodec/av1_metadata_bsf.c
index 8cafe461d1..328db5c0da 100644
--- a/libavcodec/av1_metadata_bsf.c
+++ b/libavcodec/av1_metadata_bsf.c
@@ -120,7 +120,7 @@ static int av1_metadata_update_fragment(AVBSFContext *bsf, 
AVPacket *pkt,
  }
  
  // If a Temporal Delimiter is present, it must be the first OBU.

-if (frag->units[0].type == AV1_OBU_TEMPORAL_DELIMITER) {
+if (frag->nb_units && frag->units[0].type == AV1_OBU_TEMPORAL_DELIMITER) {
  if (ctx->td == BSF_ELEMENT_REMOVE)
  ff_cbs_delete_unit(frag, 0);
  } else if (pkt && ctx->td == BSF_ELEMENT_INSERT) {


Should be ok. And backport it, too.
___
ffmpeg-devel mailing list
ffmpeg-devel@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 190/217] avcodec/binkaudio: Fix memleak upon init failure

2021-04-02 Thread Andreas Rheinhardt
On Wed, Dec 2, 2020 at 5:24 AM Andreas Rheinhardt <
andreas.rheinha...@gmail.com> wrote:

> Signed-off-by: Andreas Rheinhardt 
> ---
>  libavcodec/binkaudio.c | 2 ++
>  1 file changed, 2 insertions(+)
>
> diff --git a/libavcodec/binkaudio.c b/libavcodec/binkaudio.c
> index 7b5965ede1..f25aea0d64 100644
> --- a/libavcodec/binkaudio.c
> +++ b/libavcodec/binkaudio.c
> @@ -344,6 +344,7 @@ AVCodec ff_binkaudio_rdft_decoder = {
>  .close  = decode_end,
>  .receive_frame  = binkaudio_receive_frame,
>  .capabilities   = AV_CODEC_CAP_DELAY | AV_CODEC_CAP_DR1,
> +.caps_internal  = FF_CODEC_CAP_INIT_CLEANUP,
>  };
>
>  AVCodec ff_binkaudio_dct_decoder = {
> @@ -356,4 +357,5 @@ AVCodec ff_binkaudio_dct_decoder = {
>  .close  = decode_end,
>  .receive_frame  = binkaudio_receive_frame,
>  .capabilities   = AV_CODEC_CAP_DELAY | AV_CODEC_CAP_DR1,
> +.caps_internal  = FF_CODEC_CAP_INIT_CLEANUP,
>  };
> --
> 2.25.1
>
>

Will apply.

- 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 191/217] avcodec/binkaudio: Check return value of functions that can fail

2021-04-02 Thread Andreas Rheinhardt
On Wed, Dec 2, 2020 at 5:24 AM Andreas Rheinhardt <
andreas.rheinha...@gmail.com> wrote:

> Signed-off-by: Andreas Rheinhardt 
> ---
>  libavcodec/binkaudio.c | 8 +---
>  1 file changed, 5 insertions(+), 3 deletions(-)
>
> diff --git a/libavcodec/binkaudio.c b/libavcodec/binkaudio.c
> index f25aea0d64..2ee6f95f78 100644
> --- a/libavcodec/binkaudio.c
> +++ b/libavcodec/binkaudio.c
> @@ -69,7 +69,7 @@ static av_cold int decode_init(AVCodecContext *avctx)
>  BinkAudioContext *s = avctx->priv_data;
>  int sample_rate = avctx->sample_rate;
>  int sample_rate_half;
> -int i;
> +int i, ret;
>  int frame_len_bits;
>
>  /* determine frame length */
> @@ -131,11 +131,13 @@ static av_cold int decode_init(AVCodecContext *avctx)
>  s->first = 1;
>
>  if (CONFIG_BINKAUDIO_RDFT_DECODER && avctx->codec->id ==
> AV_CODEC_ID_BINKAUDIO_RDFT)
> -ff_rdft_init(&s->trans.rdft, frame_len_bits, DFT_C2R);
> +ret = ff_rdft_init(&s->trans.rdft, frame_len_bits, DFT_C2R);
>  else if (CONFIG_BINKAUDIO_DCT_DECODER)
> -ff_dct_init(&s->trans.dct, frame_len_bits, DCT_III);
> +ret = ff_dct_init(&s->trans.dct, frame_len_bits, DCT_III);
>  else
>  av_assert0(0);
> +if (ret < 0)
> +return ret;
>
>  s->pkt = av_packet_alloc();
>  if (!s->pkt)
> --
> 2.25.1
>
>

Will apply.

- 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 68/72] avcodec/proresenc_anatoliy: Fix memleak upon init error

2021-04-02 Thread Andreas Rheinhardt
On Fri, Nov 27, 2020 at 6:47 PM Andreas Rheinhardt <
andreas.rheinha...@gmail.com> wrote:

> A buffer may leak in case of YUVA444P10 with dimensions that are not
> both divisible by 16.
>
> Signed-off-by: Andreas Rheinhardt 
> ---
>  libavcodec/proresenc_anatoliy.c | 2 ++
>  1 file changed, 2 insertions(+)
>
> diff --git a/libavcodec/proresenc_anatoliy.c
> b/libavcodec/proresenc_anatoliy.c
> index 8bc13fd576..85e8cb3aaa 100644
> --- a/libavcodec/proresenc_anatoliy.c
> +++ b/libavcodec/proresenc_anatoliy.c
> @@ -956,6 +956,7 @@ AVCodec ff_prores_aw_encoder = {
>  .capabilities   = AV_CODEC_CAP_FRAME_THREADS,
>  .priv_class = &proresaw_enc_class,
>  .profiles   = NULL_IF_CONFIG_SMALL(ff_prores_profiles),
> +.caps_internal  = FF_CODEC_CAP_INIT_CLEANUP,
>  };
>
>  AVCodec ff_prores_encoder = {
> @@ -971,4 +972,5 @@ AVCodec ff_prores_encoder = {
>  .capabilities   = AV_CODEC_CAP_FRAME_THREADS,
>  .priv_class = &prores_enc_class,
>  .profiles   = NULL_IF_CONFIG_SMALL(ff_prores_profiles),
> +.caps_internal  = FF_CODEC_CAP_INIT_CLEANUP,
>  };
> --
> 2.25.1
>
>

Will apply.

- 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 112/134] avcodec/flacenc: Fix memleak upon init error

2021-04-02 Thread Andreas Rheinhardt
On Mon, Nov 30, 2020 at 1:56 AM Andreas Rheinhardt <
andreas.rheinha...@gmail.com> wrote:

> An AVMD5 struct would leak if an error happened after its allocation.
>
> Signed-off-by: Andreas Rheinhardt 
> ---
>  libavcodec/flacenc.c | 1 +
>  1 file changed, 1 insertion(+)
>
> diff --git a/libavcodec/flacenc.c b/libavcodec/flacenc.c
> index 8e7dbc52b4..a2aa4bdf17 100644
> --- a/libavcodec/flacenc.c
> +++ b/libavcodec/flacenc.c
> @@ -1513,4 +1513,5 @@ AVCodec ff_flac_encoder = {
>   AV_SAMPLE_FMT_S32,
>   AV_SAMPLE_FMT_NONE },
>  .priv_class = &flac_encoder_class,
> +.caps_internal  = FF_CODEC_CAP_INIT_CLEANUP,
>  };
> --
> 2.25.1
>
>
Will apply.

- 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 204/217] avcodec/ass_split: Don't presume strlen to be >= 2

2021-04-02 Thread Andreas Rheinhardt
On Wed, Dec 2, 2020 at 5:24 AM Andreas Rheinhardt <
andreas.rheinha...@gmail.com> wrote:

> Fixes potential heap-buffer-overflow.
>
> Signed-off-by: Andreas Rheinhardt 
> ---
>  libavcodec/ass_split.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/libavcodec/ass_split.c b/libavcodec/ass_split.c
> index c2c388d9f0..189272bbd9 100644
> --- a/libavcodec/ass_split.c
> +++ b/libavcodec/ass_split.c
> @@ -376,7 +376,7 @@ ASSSplitContext *ff_ass_split(const char *buf)
>  ASSSplitContext *ctx = av_mallocz(sizeof(*ctx));
>  if (!ctx)
>  return NULL;
> -if (buf && !memcmp(buf, "\xef\xbb\xbf", 3)) // Skip UTF-8 BOM header
> +if (buf && !strncmp(buf, "\xef\xbb\xbf", 3)) // Skip UTF-8 BOM header
>  buf += 3;
>  ctx->current_section = -1;
>  if (ass_split(ctx, buf) < 0) {
> --
> 2.25.1
>
>
Will apply.

- 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 221/223] avutil/cpu: Fix race condition in av_cpu_count()

2021-04-02 Thread Andreas Rheinhardt
On Thu, Dec 3, 2020 at 1:36 AM Andreas Rheinhardt <
andreas.rheinha...@gmail.com> wrote:

> av_cpu_count() intends to emit a debug message containing the number of
> logical cores when called the first time. The check currently works with
> a static volatile int; yet this does not help at all in case of
> concurrent accesses by multiple threads. So replace this with an
> atomic_int.
>
> Signed-off-by: Andreas Rheinhardt 
> ---
> To test my patches I have modified avcodec_open2() to always open the
> desired AVCodecContext simultaneously from two different threads [1].
> With this one easily runs into this issue when one uses a decoder with
> FF_CODEC_CAP_INIT_THREADSAFE that supports threading.
>
> [1]: https://pastebin.com/a1uEuQ81
>
>  libavutil/cpu.c | 6 ++
>  1 file changed, 2 insertions(+), 4 deletions(-)
>
> diff --git a/libavutil/cpu.c b/libavutil/cpu.c
> index 52f6b9a3bf..7b8a9045ab 100644
> --- a/libavutil/cpu.c
> +++ b/libavutil/cpu.c
> @@ -274,7 +274,7 @@ int av_parse_cpu_caps(unsigned *flags, const char *s)
>
>  int av_cpu_count(void)
>  {
> -static volatile int printed;
> +static atomic_int printed = 0;
>
>  int nb_cpus = 1;
>  #if HAVE_WINRT
> @@ -306,10 +306,8 @@ int av_cpu_count(void)
>  nb_cpus = sysinfo.dwNumberOfProcessors;
>  #endif
>
> -if (!printed) {
> +if (!atomic_exchange_explicit(&printed, 1, memory_order_relaxed))
>  av_log(NULL, AV_LOG_DEBUG, "detected %d logical cores\n",
> nb_cpus);
> -printed = 1;
> -}
>
>  return nb_cpus;
>  }
> --
> 2.25.1
>
>
Will apply.

- 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] [RFC] CFHD

2021-04-02 Thread Michael Niedermayer
Hi all

CFHD currently has even with all fixes (ignoring ones with objections) applied 
a null pointer
read and out of array write issue remaining.

My patch which makes the header parsing more restrictive has an objection
against it. and the only other developer who recently worked on it
stated that he has no "time or motivation to deal with this and similar issues"

Assuming no fix without objections is found. What do people prefer ?
Delay the 4.4 release ?
Apply all non objected fixes and mark CFHD as experimental ?
Something else ?

Also if anyone wants to work on this, tell me & paul (so someone can send you
the crashing testcases)

I wouldnt mind working on this but my approach of makeing the header
parser more restrictive and do it in a way that is easy to backport,
is unpopular and is in fact possibly just the first step in fixing this
if the objection didnt exist. 

So comments and input from other developers is definitly welcome here!

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.


signature.asc
Description: PGP signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

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

[FFmpeg-devel] [PATCH] avformat/url: fix ff_make_absolute_url with Windows file paths

2021-04-02 Thread Marton Balint
Ugly, but a lot less broken than it was.

Fixes ticket #9166.

Signed-off-by: Marton Balint 
---
 libavformat/url.c | 25 -
 1 file changed, 24 insertions(+), 1 deletion(-)

diff --git a/libavformat/url.c b/libavformat/url.c
index 77d610d95f..90fd41e810 100644
--- a/libavformat/url.c
+++ b/libavformat/url.c
@@ -149,6 +149,18 @@ int ff_url_decompose(URLComponents *uc, const char *url, 
const char *end)
 return 0;
 }
 
+static int is_fq_dos_path(const char *path)
+{
+if ((path[0] >= 'a' && path[0] <= 'z' || path[0] >= 'A' && path[0] <= 'Z') 
&&
+ path[1] == ':' &&
+(path[2] == '/' || path[2] == '\\'))
+return 1;
+if ((path[0] == '/' || path[0] == '\\') &&
+(path[1] == '/' || path[1] == '\\'))
+return 1;
+return 0;
+}
+
 static int append_path(char *root, char *out_end, char **rout,
const char *in, const char *in_end)
 {
@@ -185,6 +197,7 @@ int ff_make_absolute_url(char *buf, int size, const char 
*base,
 char *out, *out_end, *path;
 const char *keep, *base_path_end;
 int use_base_path, simplify_path = 0, ret;
+const char *base_separators = "/";
 
 /* This is tricky.
For HTTP, http://server/site/page + ../media/file
@@ -211,6 +224,16 @@ int ff_make_absolute_url(char *buf, int size, const char 
*base,
 
 if (!base)
 base = "";
+if (HAVE_DOS_PATHS) {
+if ((ret = ff_url_decompose(&ub, base, NULL)) < 0)
+goto error;
+if (is_fq_dos_path(base) || av_strstart(base, "file:", NULL) || 
ub.path == ub.url) {
+if (is_fq_dos_path(rel))
+base = "";
+else
+base_separators = "/\\";
+}
+}
 if ((ret = ff_url_decompose(&ub, base, NULL)) < 0 ||
 (ret = ff_url_decompose(&uc, rel,  NULL)) < 0)
 goto error;
@@ -249,7 +272,7 @@ int ff_make_absolute_url(char *buf, int size, const char 
*base,
 if (use_base_path) {
 base_path_end = ub.url_component_end_path;
 if (URL_COMPONENT_HAVE(uc, path))
-while (base_path_end > ub.path && base_path_end[-1] != '/')
+while (base_path_end > ub.path && !strchr(base_separators, 
base_path_end[-1]))
 base_path_end--;
 }
 if (keep > ub.path)
-- 
2.26.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] avformat/vividas: Fix crash when seeking without audio stream

2021-04-02 Thread Andreas Rheinhardt
The current code tries the access the codecpar of a nonexistent
audio stream when seeking. Stop that. Fixes ticket #9121.

Signed-off-by: Andreas Rheinhardt 
---
Will apply this soon.

 libavformat/vividas.c | 19 ---
 1 file changed, 12 insertions(+), 7 deletions(-)

diff --git a/libavformat/vividas.c b/libavformat/vividas.c
index 603d01a2dc..d35a646bde 100644
--- a/libavformat/vividas.c
+++ b/libavformat/vividas.c
@@ -757,18 +757,23 @@ static int viv_read_seek(AVFormatContext *s, int 
stream_index, int64_t timestamp
 
 for (int i = 0; i < viv->n_sb_blocks; i++) {
 if (frame >= viv->sb_blocks[i].packet_offset && frame < 
viv->sb_blocks[i].packet_offset + viv->sb_blocks[i].n_packets) {
-// flush audio packet queue
-viv->current_audio_subpacket = 0;
-viv->n_audio_subpackets = 0;
 viv->current_sb = i;
 // seek to ith sb block
 avio_seek(s->pb, viv->sb_offset + viv->sb_blocks[i].byte_offset, 
SEEK_SET);
 // load the block
 load_sb_block(s, viv, 0);
-// most problematic part: guess audio offset
-viv->audio_sample = av_rescale_q(viv->sb_blocks[i].packet_offset, 
av_make_q(s->streams[1]->codecpar->sample_rate, 1), 
av_inv_q(s->streams[0]->time_base));
-// hand-tuned 1.s a/v offset
-viv->audio_sample += s->streams[1]->codecpar->sample_rate;
+if (viv->num_audio) {
+const AVCodecParameters *par = s->streams[1]->codecpar;
+// flush audio packet queue
+viv->current_audio_subpacket = 0;
+viv->n_audio_subpackets  = 0;
+// most problematic part: guess audio offset
+viv->audio_sample = 
av_rescale_q(viv->sb_blocks[i].packet_offset,
+ av_make_q(par->sample_rate, 
1),
+ 
av_inv_q(s->streams[0]->time_base));
+// hand-tuned 1.s a/v offset
+viv->audio_sample += par->sample_rate;
+}
 viv->current_sb_entry = 0;
 return 1;
 }
-- 
2.27.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] CFHD

2021-04-02 Thread Paul B Mahol
On Fri, Apr 2, 2021 at 8:28 PM Michael Niedermayer 
wrote:

> Hi all
>
> CFHD currently has even with all fixes (ignoring ones with objections)
> applied a null pointer
> read and out of array write issue remaining.
>
> My patch which makes the header parsing more restrictive has an objection
> against it. and the only other developer who recently worked on it
> stated that he has no "time or motivation to deal with this and similar
> issues"
>
> Assuming no fix without objections is found. What do people prefer ?
> Delay the 4.4 release ?
> Apply all non objected fixes and mark CFHD as experimental ?
> Something else ?
>

Start fixing professionally security issues.
Am not going to do someone else job.


> Also if anyone wants to work on this, tell me & paul (so someone can send
> you
> the crashing testcases)
>
> I wouldnt mind working on this but my approach of makeing the header
> parser more restrictive and do it in a way that is easy to backport,
> is unpopular and is in fact possibly just the first step in fixing this
> if the objection didnt exist.
>
> So comments and input from other developers is definitly welcome here!
>
> 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] CFHD

2021-04-02 Thread Paul B Mahol
On Fri, Apr 2, 2021 at 10:14 PM Paul B Mahol  wrote:

>
>
> On Fri, Apr 2, 2021 at 8:28 PM Michael Niedermayer 
> wrote:
>
>> Hi all
>>
>> CFHD currently has even with all fixes (ignoring ones with objections)
>> applied a null pointer
>> read and out of array write issue remaining.
>>
>> My patch which makes the header parsing more restrictive has an objection
>> against it. and the only other developer who recently worked on it
>> stated that he has no "time or motivation to deal with this and similar
>> issues"
>>
>> Assuming no fix without objections is found. What do people prefer ?
>> Delay the 4.4 release ?
>> Apply all non objected fixes and mark CFHD as experimental ?
>> Something else ?
>>
>
> Start fixing professionally security issues.
> Am not going to do someone else job.
>


Also due to ignorance of giving needed equipment to other developer(s)
I'm not really motivated to continue maintain any code.

Why should person maintain code for no compensations, even symbolic ones.

I'm really sad in all this situation, where some long time prolific and
important contributors are simply being ignored.



>
>
>> Also if anyone wants to work on this, tell me & paul (so someone can send
>> you
>> the crashing testcases)
>>
>> I wouldnt mind working on this but my approach of makeing the header
>> parser more restrictive and do it in a way that is easy to backport,
>> is unpopular and is in fact possibly just the first step in fixing this
>> if the objection didnt exist.
>>
>> So comments and input from other developers is definitly welcome here!
>>
>> 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] CFHD

2021-04-02 Thread Michael Niedermayer
On Fri, Apr 02, 2021 at 10:22:27PM +0200, Paul B Mahol wrote:
> On Fri, Apr 2, 2021 at 10:14 PM Paul B Mahol  wrote:
> 
> >
> >
> > On Fri, Apr 2, 2021 at 8:28 PM Michael Niedermayer 
> > wrote:
> >
> >> Hi all
> >>
> >> CFHD currently has even with all fixes (ignoring ones with objections)
> >> applied a null pointer
> >> read and out of array write issue remaining.
> >>
> >> My patch which makes the header parsing more restrictive has an objection
> >> against it. and the only other developer who recently worked on it
> >> stated that he has no "time or motivation to deal with this and similar
> >> issues"
> >>
> >> Assuming no fix without objections is found. What do people prefer ?
> >> Delay the 4.4 release ?
> >> Apply all non objected fixes and mark CFHD as experimental ?
> >> Something else ?
> >>
> >
> > Start fixing professionally security issues.

> > Am not going to do someone else job.

Then you also should not object to someone else doing it in a way you
maybe dislike


> >
> 
> 
> Also due to ignorance of giving needed equipment to other developer(s)

what hardware do you need for FFmpeg ? you did not ask for any

If its about someone elses request, i think theres a misunderstanding
there.

Thanks


> I'm not really motivated to continue maintain any code.
> 
> Why should person maintain code for no compensations, even symbolic ones.
> 
> I'm really sad in all this situation, where some long time prolific and
> important contributors are simply being ignored.


[...]
-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

The worst form of inequality is to try to make unequal things equal.
-- Aristotle


signature.asc
Description: PGP signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

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

Re: [FFmpeg-devel] Hardware purchase request

2021-04-02 Thread Michael Niedermayer
On Mon, Mar 29, 2021 at 11:03:16PM +0300, Jan Ekström wrote:
> On Tue, Mar 23, 2021 at 12:47 AM Lynne  wrote:
> >
> > As discussed during the last developer meeting, I am in need of new 
> > hardware to
> > work on Vulkan filtering, hwcontext, AV1 VAAPI decoding, new assembly and
> > general development on FFmpeg and projects involving the FFmpeg libraries.
> >
> > I was requested to post what I'd like on the mailing list for discussion, 
> > as well
> > as to talk about their purchase, since I currently lack the spare funds to 
> > buy
> > everything and then be refunded, which is the standard way we have handled
> > hardware and expenses in the past.
> >
> 
> Hi, and first of all - thank you for posting this.
> 
> Just to start with my position:
> 1. I have no control over whether someone receives money or not, I am
> just part of the community.
> 2. IMHO we should be utilizing the money for things we find useful for
> the project, the most recent of which were the two M1 Mac Minis.
> Hardware required for development clearly fits that bill. So as such I
> am not opposed to
> 
> > As we have literally hundreds of thousands of dollars in our SPI fund
> > (121 716.03 USD as of the end of 2019), I have spared no expense in
> > my selection.
> 
> Personally, while I know that thinking about the big picture in money
> is not our hobby nor a thing that we like to keep in our minds, but I
> think we should not make such statements unless one has an
> understanding of the growth rate of that fund. I do not have such
> understanding, and I would not like to start making the calculations
> in my head to get an understanding of the yearly fluctuations of the
> fund, and thus I would not have utilized such wording.
> 
> Depending on such knowledge, it could be seen whether utilizing
> roughly 1:20 of that amount on a single entry can be seen as either
> something that can be handled within the yearly growth, or not. And if
> not, whether we have a reason to be OK with it (the single entry being
> of such importance that it cannot be ignored, other sources of income
> for the project, etc)
> 
> Let's just say that I'm happy to not be an accountant for anyone else
> than myself, having to look at whether something is sustainable or
> not.
> 
> > The price listed on each component is the lowest I could
> > find from all the stores I searched.
> >
> > PCPartPicker Part List: https://pcpartpicker.com/list/HJwhLP 
> > 
> >
> > CPU: AMD Ryzen 9 5950X 3.4 GHz 16-Core Processor  (€949.00 @ Topchat.com)
> > CPU Cooler: Fractal Design Celsius+ S36 Dynamic X2 PWM 87.6 CFM Liquid CPU 
> > Cooler  (€145.66 @ Amazon)
> > Motherboard: Asus ROG Crosshair VIII Dark Hero ATX AM4 Motherboard  
> > (€574.98 @ Amazon)
> > Memory: 2x G.Skill Trident Z RGB 32 GB (2 x 16 GB) F4-4000C16D-32GTZR 
> > DDR4-4000 CL16 Memory  (€470.95 @ Amazon)
> > Storage: 2x Samsung 980 Pro 1 TB M.2-2280 NVME Solid State Drive  (€216.38 
> > @ Amazon)
> > Video Card: XFX Radeon RX 6900 XT 16 GB Speedster MERC 319 Ultra Video Card 
> > (€1925.89 @ Amazon)
> > Case: Fractal Design Define 7 Compact ATX Mid Tower Case  (€132.78 @ Amazon)
> > Power Supply: Fractal Design Ion+ 860 W 80+ Platinum Certified Fully 
> > Modular ATX Power Supply  (€185.50 @ Amazon)
> > Case Fan: 3x Noctua A14 PWM 82.5 CFM 140 mm Fan  (€21.90 @ Amazon)
> > Monitor: LG 27GN950-B 27.0" 3840x2160 144 Hz Monitor  (€742.49 @ Amazon)
> >
> > Total: €6096.66
> 
> A lot of these components sound quite alright, and reasonable for a
> development workstation. Then there are various things which
> unfortunately make it hit my uncomfortability level, mostly due to not
> knowing how the context of the fund.
> 
> The most recent purchase I recall was for two pieces of shared
> hardware going for about 1500eur (1,299 gbp) which together would be
> around 3000eur. Personally, without knowing the state or growth rate
> of the fund I would be much more comfortable with something along
> those lines.

Lynne, do you need all the parts of this list for FFmpeg development ?
In the sense that a lower priced choice for a component or none would
materially impact FFmpeg development ?
I think theres a unfortunate misunderstanding that while we do have more
money we know what to do with ATM. That doesnt mean we should attempt to
use up as much as possible.
IIRC there was a large one time donation that made it that big so it wont
replenish that rapidly also people donating likely want us to use their
donations as optimally as possible.

IMO some of this list is quite reasonable like a 1TB NVME, then iam not
sure why you need a 2nd one. That can be needed of course but its not clear
from just the list. But really i dont want to "critique" the list, it just
overall feels like there was a misunderstanding and iam happy to approve
a machiene in the 2-3k range or also higher if its explained why its needed
for FFmpeg

and sorry for my late reply

Thanks


[...]
-- 
Michael Gnu

Re: [FFmpeg-devel] 4.4 Release Name

2021-04-02 Thread Zane van Iperen



On 2/4/21 8:34 pm, RADSL wrote:


On 4/2/2021 2:59 AM, Michael Niedermayer wrote:

Hi all

We still need to choose the name for 4.4
previous unused suggestions where:
Von Neumann, Lorentz, Poincaré, Desitter, De Broglie, Gauss, Galois, Viterbi, 
Darwin

Feel free to reply with name suggestions
If theres a tie then i will randomly pick amongth the tied, i assume all 
previous
suggestions where suggested exactly once already.

I plan to make the release today or tomorrow unless major bugfixes are
still pending. I probably wont have time sunday / monday for making the
release

Thanks



version 4.4 Plandemic


Absolutely +1 Plandemic


___
ffmpeg-devel mailing list
ffmpeg-devel@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/3] avcodec/adpcm_swf: remove memory allocation during trellis encoding

2021-04-02 Thread Zane van Iperen



On 1/4/21 9:34 pm, Zane van Iperen wrote:

The block size is hardcoded, so the buffer size is always known.
Statically allocate the buffer on the stack.

Signed-off-by: Zane van Iperen 
---
  libavcodec/adpcmenc.c | 7 ---
  1 file changed, 4 insertions(+), 3 deletions(-)



Ping on parts 2 and 3.

My concern with part 3 is the re-initialisation of fields from extradata. I'm 
not sure
if it should be done on only init, or on both init and flush.
___
ffmpeg-devel mailing list
ffmpeg-devel@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/mpegtsenc: Preserve disposition in the absence of language

2021-04-02 Thread Andreas Rheinhardt
Implements ticket #9113.

Signed-off-by: Andreas Rheinhardt 
---
 libavformat/mpegtsenc.c | 18 +-
 1 file changed, 9 insertions(+), 9 deletions(-)

diff --git a/libavformat/mpegtsenc.c b/libavformat/mpegtsenc.c
index 35c835c484..dbd3bb148a 100644
--- a/libavformat/mpegtsenc.c
+++ b/libavformat/mpegtsenc.c
@@ -459,6 +459,8 @@ static int mpegts_write_pmt(AVFormatContext *s, 
MpegTSService *service)
 AVStream *st = s->streams[i];
 MpegTSWriteStream *ts_st = st->priv_data;
 AVDictionaryEntry *lang = av_dict_get(st->metadata, "language", NULL, 
0);
+const char default_language[] = "und";
+const char *language = lang && strlen(lang->value) >= 3 ? lang->value 
: default_language;
 enum AVCodecID codec_id = st->codecpar->codec_id;
 
 if (s->nb_programs) {
@@ -598,16 +600,19 @@ static int mpegts_write_pmt(AVFormatContext *s, 
MpegTSService *service)
 }
 }
 
-if (lang) {
-char *p;
-char *next = lang->value;
+if (language != default_language ||
+st->disposition & (AV_DISPOSITION_CLEAN_EFFECTS|
+   AV_DISPOSITION_HEARING_IMPAIRED |
+   AV_DISPOSITION_VISUAL_IMPAIRED)) {
+const char *p;
+const char *next = language;
 uint8_t *len_ptr;
 
 *q++ = ISO_639_LANGUAGE_DESCRIPTOR;
 len_ptr  = q++;
 *len_ptr = 0;
 
-for (p = lang->value; next && *len_ptr < 255 / 4 * 4; p = next 
+ 1) {
+for (p = next; next && *len_ptr < 255 / 4 * 4; p = next + 1) {
 if (q - data > SECTION_LENGTH - 4) {
 err = 1;
 break;
@@ -637,10 +642,6 @@ static int mpegts_write_pmt(AVFormatContext *s, 
MpegTSService *service)
 }
 break;
 case AVMEDIA_TYPE_SUBTITLE:
-{
-   const char default_language[] = "und";
-   const char *language = lang && strlen(lang->value) >= 3 ? 
lang->value : default_language;
-
if (codec_id == AV_CODEC_ID_DVB_SUBTITLE) {
uint8_t *len_ptr;
int extradata_copied = 0;
@@ -715,7 +716,6 @@ static int mpegts_write_pmt(AVFormatContext *s, 
MpegTSService *service)
 
*len_ptr = q - len_ptr - 1;
 }
-}
 break;
 case AVMEDIA_TYPE_VIDEO:
 if (stream_type == STREAM_TYPE_VIDEO_DIRAC) {
-- 
2.27.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] 4.4 Release Name

2021-04-02 Thread Linjie Fu
On Sat, Apr 3, 2021 at 09:10 Zane van Iperen  wrote:

>
>
> On 2/4/21 8:34 pm, RADSL wrote:
> >
> > On 4/2/2021 2:59 AM, Michael Niedermayer wrote:
> >> Hi all
> >>
> >> We still need to choose the name for 4.4
> >> previous unused suggestions where:
> >> Von Neumann, Lorentz, Poincaré, Desitter, De Broglie, Gauss, Galois,
> Viterbi, Darwin
> >>
> >> Feel free to reply with name suggestions
> >> If theres a tie then i will randomly pick amongth the tied, i assume
> all previous
> >> suggestions where suggested exactly once already.
> >>
> >> I plan to make the release today or tomorrow unless major bugfixes are
> >> still pending. I probably wont have time sunday / monday for making the
> >> release
> >>
> >> Thanks
> >>
> >>
> > version 4.4 Plandemic
>
> Absolutely +1 Plandemic


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

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

Re: [FFmpeg-devel] [PATCH] avformat/mpegtsenc: Preserve disposition in the absence of language

2021-04-02 Thread stephen douglas
 ISO 639 language descriptors used by DVB are the 3 charecter variants hence 
const char *language = lang && strlen(lang->value) >= 3 ? lang->value : 
default_language;should beconst char *language = lang && strlen(lang->value) > 
3 ? lang->value : default_language;
   On Saturday, 3 April 2021, 06:53:20 BST, Andreas Rheinhardt 
 wrote:  
 
 Implements ticket #9113.

Signed-off-by: Andreas Rheinhardt 
---
 libavformat/mpegtsenc.c | 18 +-
 1 file changed, 9 insertions(+), 9 deletions(-)

diff --git a/libavformat/mpegtsenc.c b/libavformat/mpegtsenc.c
index 35c835c484..dbd3bb148a 100644
--- a/libavformat/mpegtsenc.c
+++ b/libavformat/mpegtsenc.c
@@ -459,6 +459,8 @@ static int mpegts_write_pmt(AVFormatContext *s, 
MpegTSService *service)
        AVStream *st = s->streams[i];
        MpegTSWriteStream *ts_st = st->priv_data;
        AVDictionaryEntry *lang = av_dict_get(st->metadata, "language", NULL, 
0);
+        const char default_language[] = "und";
+        const char *language = lang && strlen(lang->value) >= 3 ? lang->value 
: default_language;
        enum AVCodecID codec_id = st->codecpar->codec_id;
 
        if (s->nb_programs) {
@@ -598,16 +600,19 @@ static int mpegts_write_pmt(AVFormatContext *s, 
MpegTSService *service)
                }
            }
 
-            if (lang) {
-                char *p;
-                char *next = lang->value;
+            if (language != default_language ||
+                st->disposition & (AV_DISPOSITION_CLEAN_EFFECTS    |
+                                  AV_DISPOSITION_HEARING_IMPAIRED |
+                                  AV_DISPOSITION_VISUAL_IMPAIRED)) {
+                const char *p;
+                const char *next = language;
                uint8_t *len_ptr;
 
                *q++    = ISO_639_LANGUAGE_DESCRIPTOR;
                len_ptr  = q++;
                *len_ptr = 0;
 
-                for (p = lang->value; next && *len_ptr < 255 / 4 * 4; p = next 
+ 1) {
+                for (p = next; next && *len_ptr < 255 / 4 * 4; p = next + 1) {
                    if (q - data > SECTION_LENGTH - 4) {
                        err = 1;
                        break;
@@ -637,10 +642,6 @@ static int mpegts_write_pmt(AVFormatContext *s, 
MpegTSService *service)
            }
            break;
        case AVMEDIA_TYPE_SUBTITLE:
-        {
-          const char default_language[] = "und";
-          const char *language = lang && strlen(lang->value) >= 3 ? 
lang->value : default_language;
-
            if (codec_id == AV_CODEC_ID_DVB_SUBTITLE) {
                uint8_t *len_ptr;
                int extradata_copied = 0;
@@ -715,7 +716,6 @@ static int mpegts_write_pmt(AVFormatContext *s, 
MpegTSService *service)
 
                *len_ptr = q - len_ptr - 1;
            }
-        }
        break;
        case AVMEDIA_TYPE_VIDEO:
            if (stream_type == STREAM_TYPE_VIDEO_DIRAC) {
-- 
2.27.0

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

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".  
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

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