Re: [FFmpeg-devel] [PATCH 13/17] avcodec/mlpenc: Fix channel layouts

2022-09-21 Thread Paul B Mahol
On 9/18/22, Andreas Rheinhardt  wrote:
> The encoder actually creates files with side channels, not back
> channels. See thd_layout in mlp_parse.h.
>
> Signed-off-by: Andreas Rheinhardt 
> ---
>  libavcodec/mlpenc.c | 10 +-
>  1 file changed, 5 insertions(+), 5 deletions(-)
>

lgtm

> diff --git a/libavcodec/mlpenc.c b/libavcodec/mlpenc.c
> index b66f3a3067..463332593f 100644
> --- a/libavcodec/mlpenc.c
> +++ b/libavcodec/mlpenc.c
> @@ -628,14 +628,14 @@ static av_cold int mlp_encode_init(AVCodecContext
> *avctx)
>  ctx->channel_arrangement = 1;
>  ctx->thd_substream_info  = 0x14;
>  } else if (!av_channel_layout_compare(&avctx->ch_layout,
> -
> &(AVChannelLayout)AV_CHANNEL_LAYOUT_5POINT0_BACK)) {
> +
> &(AVChannelLayout)AV_CHANNEL_LAYOUT_5POINT0)) {
>  ctx->ch_modifier_thd0= 1;
>  ctx->ch_modifier_thd1= 1;
>  ctx->ch_modifier_thd2= 1;
>  ctx->channel_arrangement = 11;
>  ctx->thd_substream_info  = 0x104;
>  } else if (!av_channel_layout_compare(&avctx->ch_layout,
> -
> &(AVChannelLayout)AV_CHANNEL_LAYOUT_5POINT1_BACK)) {
> +
> &(AVChannelLayout)AV_CHANNEL_LAYOUT_5POINT1)) {
>  ctx->ch_modifier_thd0= 2;
>  ctx->ch_modifier_thd1= 1;
>  ctx->ch_modifier_thd2= 2;
> @@ -2277,13 +2277,13 @@ const FFCodec ff_truehd_encoder = {
>  .p.sample_fmts  = (const enum AVSampleFormat[])
> {AV_SAMPLE_FMT_S16, AV_SAMPLE_FMT_S32, AV_SAMPLE_FMT_NONE},
>  .p.supported_samplerates = (const int[]) {44100, 48000, 88200, 96000,
> 176400, 192000, 0},
>  #if FF_API_OLD_CHANNEL_LAYOUT
> -.p.channel_layouts  = (const uint64_t[]) {AV_CH_LAYOUT_MONO,
> AV_CH_LAYOUT_STEREO, AV_CH_LAYOUT_5POINT0_BACK, AV_CH_LAYOUT_5POINT1_BACK,
> 0},
> +.p.channel_layouts  = (const uint64_t[]) { AV_CH_LAYOUT_MONO,
> AV_CH_LAYOUT_STEREO, AV_CH_LAYOUT_5POINT0, AV_CH_LAYOUT_5POINT1, 0 },
>  #endif
>  .p.ch_layouts   = (const AVChannelLayout[]) {
>AV_CHANNEL_LAYOUT_MONO,
>AV_CHANNEL_LAYOUT_STEREO,
> -  AV_CHANNEL_LAYOUT_5POINT0_BACK,
> -  AV_CHANNEL_LAYOUT_5POINT1_BACK,
> +  AV_CHANNEL_LAYOUT_5POINT0,
> +  AV_CHANNEL_LAYOUT_5POINT1,
>{ 0 }
>},
>  .caps_internal  = FF_CODEC_CAP_INIT_CLEANUP,
> --
> 2.34.1
>
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
> To unsubscribe, visit link above, or email
> ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
>
___
ffmpeg-devel mailing list
ffmpeg-devel@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 15/17] avcodec/mlpenc: Remove dead channel layout checks

2022-09-21 Thread Paul B Mahol
On 9/18/22, Andreas Rheinhardt  wrote:
> ff_encode_preinit() has already checked that the channel layout
> is equivalent to one of the layouts in AVCodec.ch_layouts.
>
> Signed-off-by: Andreas Rheinhardt 
> ---
>  libavcodec/mlpenc.c | 11 +--
>  1 file changed, 5 insertions(+), 6 deletions(-)
>


lgtm

> diff --git a/libavcodec/mlpenc.c b/libavcodec/mlpenc.c
> index d2e2f7..878c5aedc1 100644
> --- a/libavcodec/mlpenc.c
> +++ b/libavcodec/mlpenc.c
> @@ -27,6 +27,7 @@
>  #include "encode.h"
>  #include "put_bits.h"
>  #include "audio_frame_queue.h"
> +#include "libavutil/avassert.h"
>  #include "libavutil/channel_layout.h"
>  #include "libavutil/crc.h"
>  #include "libavutil/avstring.h"
> @@ -602,12 +603,11 @@ static av_cold int mlp_encode_init(AVCodecContext
> *avctx)
>  };
>  int i;
>
> -for (i = 0; i < FF_ARRAY_ELEMS(layout_arrangement); i++)
> +for (i = 0;; i++) {
> +av_assert1(i < FF_ARRAY_ELEMS(layout_arrangement) ||
> +   !"Impossible channel layout");
>  if (channels_present == layout_arrangement[i])
>  break;
> -if (i == FF_ARRAY_ELEMS(layout_arrangement)) {
> -av_log(avctx, AV_LOG_ERROR, "Unsupported channel
> arrangement\n");
> -return AVERROR(EINVAL);
>  }
>  ctx->channel_arrangement = i;
>  ctx->flags = FLAGS_DVDA;
> @@ -640,8 +640,7 @@ static av_cold int mlp_encode_init(AVCodecContext
> *avctx)
>  ctx->channel_arrangement = 15;
>  ctx->thd_substream_info  = 0x104;
>  } else {
> -av_log(avctx, AV_LOG_ERROR, "Unsupported channel
> arrangement\n");
> -return AVERROR(EINVAL);
> +av_assert1(!"AVCodec.ch_layouts needs to be updated");
>  }
>  ctx->flags = 0;
>  ctx->channel_occupancy = 0;
> --
> 2.34.1
>
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
> To unsubscribe, visit link above, or email
> ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
>
___
ffmpeg-devel mailing list
ffmpeg-devel@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 14/17] avcodec/mlpenc: Simplify channel layout comparisons

2022-09-21 Thread Paul B Mahol
On 9/18/22, Andreas Rheinhardt  wrote:
> These encoders have AVCodec.ch_layouts set, so ff_encode_preinit()
> has already checked that the used channel layout is equivalent
> to one of these native layouts. Therefore one can simply
> compare the channel masks (with the added complication
> that one has to use av_channel_layout_subset() to get it,
> because the channel layout is not guaranteed to have
> AV_CHANNEL_ORDER_NATIVE).
>
> Signed-off-by: Andreas Rheinhardt 
> ---
>  libavcodec/mlpenc.c | 30 ++
>  1 file changed, 14 insertions(+), 16 deletions(-)
>


probably ok

> diff --git a/libavcodec/mlpenc.c b/libavcodec/mlpenc.c
> index 463332593f..d2e2f7 100644
> --- a/libavcodec/mlpenc.c
> +++ b/libavcodec/mlpenc.c
> @@ -480,6 +480,7 @@ static av_cold int mlp_encode_init(AVCodecContext
> *avctx)
>  static AVOnce init_static_once = AV_ONCE_INIT;
>  MLPEncodeContext *ctx = avctx->priv_data;
>  RestartHeader *const rh = &ctx->restart_header;
> +uint64_t channels_present;
>  unsigned int sum = 0;
>  size_t size;
>  int ret;
> @@ -589,19 +590,20 @@ static av_cold int mlp_encode_init(AVCodecContext
> *avctx)
>
>  ctx->num_substreams = 1; // TODO: change this after adding
> multi-channel support for TrueHD
>
> +channels_present = av_channel_layout_subset(&avctx->ch_layout,
> ~(uint64_t)0);
>  if (ctx->avctx->codec_id == AV_CODEC_ID_MLP) {
> -static const AVChannelLayout layout_arrangement[] = {
> -AV_CHANNEL_LAYOUT_MONO, AV_CHANNEL_LAYOUT_STEREO,
> -AV_CHANNEL_LAYOUT_2_1,  AV_CHANNEL_LAYOUT_QUAD,
> -AV_CHANNEL_LAYOUT_2POINT1,  { 0 }, { 0 },
> -AV_CHANNEL_LAYOUT_SURROUND, AV_CHANNEL_LAYOUT_4POINT0,
> -AV_CHANNEL_LAYOUT_5POINT0_BACK, AV_CHANNEL_LAYOUT_3POINT1,
> -AV_CHANNEL_LAYOUT_4POINT1,
> AV_CHANNEL_LAYOUT_5POINT1_BACK,
> +static const uint64_t layout_arrangement[] = {
> +AV_CH_LAYOUT_MONO, AV_CH_LAYOUT_STEREO,
> +AV_CH_LAYOUT_2_1,  AV_CH_LAYOUT_QUAD,
> +AV_CH_LAYOUT_2POINT1,  0, 0,
> +AV_CH_LAYOUT_SURROUND, AV_CH_LAYOUT_4POINT0,
> +AV_CH_LAYOUT_5POINT0_BACK, AV_CH_LAYOUT_3POINT1,
> +AV_CH_LAYOUT_4POINT1,  AV_CH_LAYOUT_5POINT1_BACK,
>  };
>  int i;
>
>  for (i = 0; i < FF_ARRAY_ELEMS(layout_arrangement); i++)
> -if (!av_channel_layout_compare(&avctx->ch_layout,
> &layout_arrangement[i]))
> +if (channels_present == layout_arrangement[i])
>  break;
>  if (i == FF_ARRAY_ELEMS(layout_arrangement)) {
>  av_log(avctx, AV_LOG_ERROR, "Unsupported channel
> arrangement\n");
> @@ -613,29 +615,25 @@ static av_cold int mlp_encode_init(AVCodecContext
> *avctx)
>  ctx->summary_info  =
> ff_mlp_ch_info[ctx->channel_arrangement].summary_info ;
>  } else {
>  /* TrueHD */
> -if (!av_channel_layout_compare(&avctx->ch_layout,
> -
> &(AVChannelLayout)AV_CHANNEL_LAYOUT_MONO)) {
> +if (channels_present == AV_CH_LAYOUT_MONO) {
>  ctx->ch_modifier_thd0= 3;
>  ctx->ch_modifier_thd1= 3;
>  ctx->ch_modifier_thd2= 3;
>  ctx->channel_arrangement = 2;
>  ctx->thd_substream_info  = 0x14;
> -} else if (!av_channel_layout_compare(&avctx->ch_layout,
> -
> &(AVChannelLayout)AV_CHANNEL_LAYOUT_STEREO)) {
> +} else if (channels_present == AV_CH_LAYOUT_STEREO) {
>  ctx->ch_modifier_thd0= 1;
>  ctx->ch_modifier_thd1= 1;
>  ctx->ch_modifier_thd2= 1;
>  ctx->channel_arrangement = 1;
>  ctx->thd_substream_info  = 0x14;
> -} else if (!av_channel_layout_compare(&avctx->ch_layout,
> -
> &(AVChannelLayout)AV_CHANNEL_LAYOUT_5POINT0)) {
> +} else if (channels_present == AV_CH_LAYOUT_5POINT0) {
>  ctx->ch_modifier_thd0= 1;
>  ctx->ch_modifier_thd1= 1;
>  ctx->ch_modifier_thd2= 1;
>  ctx->channel_arrangement = 11;
>  ctx->thd_substream_info  = 0x104;
> -} else if (!av_channel_layout_compare(&avctx->ch_layout,
> -
> &(AVChannelLayout)AV_CHANNEL_LAYOUT_5POINT1)) {
> +} else if (channels_present == AV_CH_LAYOUT_5POINT1) {
>  ctx->ch_modifier_thd0= 2;
>  ctx->ch_modifier_thd1= 1;
>  ctx->ch_modifier_thd2= 2;
> --
> 2.34.1
>
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
> To unsubscribe, visit link above, or email
> ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
>
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link

[FFmpeg-devel] [PATCH] A-pac demuxer and decoder

2022-09-21 Thread Paul B Mahol
Patches attached.
From 751526c456d09bd22a6316196219d79876ae74f1 Mon Sep 17 00:00:00 2001
From: Paul B Mahol 
Date: Mon, 19 Sep 2022 22:14:05 +0200
Subject: [PATCH 1/2] avcodec: add APAC decoder

Signed-off-by: Paul B Mahol 
---
 libavcodec/Makefile |   1 +
 libavcodec/allcodecs.c  |   1 +
 libavcodec/apac.c   | 269 
 libavcodec/codec_desc.c |   7 ++
 libavcodec/codec_id.h   |   1 +
 5 files changed, 279 insertions(+)
 create mode 100644 libavcodec/apac.c

diff --git a/libavcodec/Makefile b/libavcodec/Makefile
index c836252664..b9aa6efaac 100644
--- a/libavcodec/Makefile
+++ b/libavcodec/Makefile
@@ -214,6 +214,7 @@ OBJS-$(CONFIG_AMRWB_DECODER)   += amrwbdec.o celp_filters.o   \
 OBJS-$(CONFIG_AMV_ENCODER) += mjpegenc.o mjpegenc_common.o
 OBJS-$(CONFIG_ANM_DECODER) += anm.o
 OBJS-$(CONFIG_ANSI_DECODER)+= ansi.o cga_data.o
+OBJS-$(CONFIG_APAC_DECODER)+= apac.o
 OBJS-$(CONFIG_APE_DECODER) += apedec.o
 OBJS-$(CONFIG_APTX_DECODER)+= aptxdec.o aptx.o
 OBJS-$(CONFIG_APTX_ENCODER)+= aptxenc.o aptx.o
diff --git a/libavcodec/allcodecs.c b/libavcodec/allcodecs.c
index 447225e26b..fc88e25fda 100644
--- a/libavcodec/allcodecs.c
+++ b/libavcodec/allcodecs.c
@@ -432,6 +432,7 @@ extern const FFCodec ff_alac_decoder;
 extern const FFCodec ff_als_decoder;
 extern const FFCodec ff_amrnb_decoder;
 extern const FFCodec ff_amrwb_decoder;
+extern const FFCodec ff_apac_decoder;
 extern const FFCodec ff_ape_decoder;
 extern const FFCodec ff_aptx_encoder;
 extern const FFCodec ff_aptx_decoder;
diff --git a/libavcodec/apac.c b/libavcodec/apac.c
new file mode 100644
index 00..2dc9aacd44
--- /dev/null
+++ b/libavcodec/apac.c
@@ -0,0 +1,269 @@
+/*
+ * APAC audio decoder
+ *
+ * This file is part of FFmpeg.
+ *
+ * FFmpeg is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public
+ * License as published by the Free Software Foundation; either
+ * version 2.1 of the License, or (at your option) any later version.
+ *
+ * FFmpeg is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+ * Lesser General Public License for more details.
+ *
+ * You should have received a copy of the GNU Lesser General Public
+ * License along with FFmpeg; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA
+ */
+
+#include "libavutil/audio_fifo.h"
+#include "libavutil/internal.h"
+#include "libavutil/intreadwrite.h"
+#include "avcodec.h"
+#include "codec_internal.h"
+#include "decode.h"
+#include "get_bits.h"
+
+typedef struct ChContext {
+int have_code;
+int last_sample;
+int last_delta;
+int bit_length;
+int block_length;
+uint8_t block[32 * 2];
+AVAudioFifo *samples;
+} ChContext;
+
+typedef struct APACContext {
+GetBitContext gb;
+int skip;
+
+int cur_ch;
+ChContext ch[2];
+
+uint8_t *bitstream;
+int64_t max_framesize;
+int bitstream_size;
+int bitstream_index;
+} APACContext;
+
+static av_cold int apac_close(AVCodecContext *avctx)
+{
+APACContext *s = avctx->priv_data;
+
+av_freep(&s->bitstream);
+s->bitstream_size = 0;
+
+for (int ch = 0; ch < avctx->ch_layout.nb_channels; ch++) {
+ChContext *c = &s->ch[ch];
+
+av_audio_fifo_free(c->samples);
+}
+
+return 0;
+}
+
+static av_cold int apac_init(AVCodecContext *avctx)
+{
+APACContext *s = avctx->priv_data;
+
+if (avctx->bits_per_coded_sample > 8)
+avctx->sample_fmt = AV_SAMPLE_FMT_S16P;
+else
+avctx->sample_fmt = AV_SAMPLE_FMT_U8P;
+
+if (avctx->ch_layout.nb_channels < 1 ||
+avctx->ch_layout.nb_channels > 2)
+return AVERROR_INVALIDDATA;
+
+for (int ch = 0; ch < avctx->ch_layout.nb_channels; ch++) {
+ChContext *c = &s->ch[ch];
+
+c->bit_length = avctx->bits_per_coded_sample;
+c->block_length = 8;
+c->have_code = 0;
+c->samples = av_audio_fifo_alloc(avctx->sample_fmt, 1, 1024);
+if (!c->samples)
+return AVERROR(ENOMEM);
+}
+
+s->max_framesize = 1024;
+s->bitstream = av_realloc_f(s->bitstream, s->max_framesize + AV_INPUT_BUFFER_PADDING_SIZE, sizeof(*s->bitstream));
+if (!s->bitstream)
+return AVERROR(ENOMEM);
+
+return 0;
+}
+
+static int get_code(ChContext *c, GetBitContext *gb)
+{
+if (get_bits1(gb)) {
+int code = get_bits(gb, 2);
+
+switch (code) {
+case 0:
+c->bit_length--;
+break;
+case 1:
+c->bit_length++;
+break;
+case 2:
+c->bit_length = get_bits(gb, 5);
+break;
+case 3:
+c->block_length = get_bits(gb, 4);
+return 1;
+}

Re: [FFmpeg-devel] [PATCH v2] avcodec/jpeg2000: Add support for High-Throughput JPEG 2000 (HTJ2K) decoding.

2022-09-21 Thread Caleb Etemesi
>> Please separate struct renaming into a separate patch

Will do in the next patch

>> Corresponds to µ_start, right?

Not sure what  µ_start here relates to, but this is the zero bit plane
information in *B.10.5*
of the jpeg2000 spec (ITU Rec. T.800 (06/2019))

>> Could also be called Lcup and Lref. But fine I suppose.

Will change in the next patch

>> No time to review this atm, hopefully later though

No problem.


>> Why are these tables in here when they're only used by jpeg2000htdec.c?

I wasn't aware of any table placing conventions and my personal preference
is usually to place them
inside header files.

On Tue, Sep 20, 2022 at 4:49 PM Tomas Härdin  wrote:

> tor 2022-09-08 klockan 23:49 +0300 skrev etemesica...@gmail.com:
> >
> > --- a/libavcodec/j2kenc.c
> > +++ b/libavcodec/j2kenc.c
> > @@ -106,7 +106,7 @@ static const int dwt_norms[2][4][10] = { //
> > [dwt_type][band][rlevel] (multiplied
> >  typedef struct {
> > Jpeg2000Component *comp;
> > double *layer_rates;
> > -} Jpeg2000Tile;
> > +} Jpeg2000EncTile;
> >
> >  typedef struct {
> >  AVClass *class;
> > @@ -131,7 +131,7 @@ typedef struct {
> >  Jpeg2000CodingStyle codsty;
> >  Jpeg2000QuantStyle  qntsty;
> >
> > -Jpeg2000Tile *tile;
> > +Jpeg2000EncTile *tile;
>
> Please separate struct renaming into a separate patch
>
> >  typedef struct Jpeg2000Cblk {
> >  uint8_t npasses;
> >  uint8_t ninclpasses; // number coding of passes included in
> > codestream
> > @@ -181,6 +181,7 @@ typedef struct Jpeg2000Cblk {
> >  uint16_t *lengthinc;
> >  uint8_t nb_lengthinc;
> >  uint8_t lblock;
> > +uint8_t zbp; // Zero bit planes
>
> Corresponds to µ_start, right?
>
> >  uint8_t *data;
> >  size_t data_allocated;
> >  int nb_terminations;
> > @@ -189,6 +190,7 @@ typedef struct Jpeg2000Cblk {
> >  Jpeg2000Pass *passes;
> >  Jpeg2000Layer *layers;
> >  int coord[2][2]; // border coordinates {{x0, x1}, {y0, y1}}
> > +int pass_lengths[2];
>
> Could also be called Lcup and Lref. But fine I suppose.
>
> >  } Jpeg2000Cblk; // code block
> >
> >  typedef struct Jpeg2000Prec {
> > @@ -227,6 +229,103 @@ typedef struct Jpeg2000Component {
> >  uint8_t roi_shift; // ROI scaling value for the component
> >  } Jpeg2000Component;
> >
> > +#define JP2_SIG_TYPE0x6A502020
> > +#define JP2_SIG_VALUE   0x0D0A870A
> > +#define JP2_CODESTREAM  0x6A703263
> > +#define JP2_HEADER  0x6A703268
> > +
> > +#define HAD_COC 0x01
> > +#define HAD_QCC 0x02
> > +
> > +#define MAX_POCS 32
>
> Similarly with code movements. I can see this move adds is_htj2k to
> Jpeg2000DecoderContext. Please separate such things. Makes reviewing
> functional changes much easier.
>
> > -static inline void tile_codeblocks(const Jpeg2000DecoderContext *s,
> > Jpeg2000Tile *tile)
> > +static inline void tile_codeblocks(const Jpeg2000DecoderContext *s,
> > Jpeg2000DecTile *tile)
> >  {
> >  Jpeg2000T1Context t1;
> >
> >  int compno, reslevelno, bandno;
> > +int subbandno;
> >
> >  /* Loop on tile components */
> >  for (compno = 0; compno < s->ncomponents; compno++) {
> > -Jpeg2000Component *comp = tile->comp + compno;
> > -Jpeg2000CodingStyle *codsty = tile->codsty + compno;
> > +Jpeg2000Component *comp= tile->comp + compno;
> > +Jpeg2000CodingStyle *codsty= tile->codsty + compno;
> > +Jpeg2000QuantStyle *quantsty   = tile->qntsty + compno;
>
> Cosmetic and functional changes don't mix
>
> >  int coded = 0;
> > +subbandno = 0;
> >
> >  t1.stride = (1 >
> > @@ -1959,7 +1881,7 @@ static inline void tile_codeblocks(const
> > Jpeg2000DecoderContext *s, Jpeg2000Tile
> >  for (reslevelno = 0; reslevelno < codsty->nreslevels2decode;
> > reslevelno++) {
> >  Jpeg2000ResLevel *rlevel = comp->reslevel + reslevelno;
> >  /* Loop on bands */
> > -for (bandno = 0; bandno < rlevel->nbands; bandno++) {
> > +for (bandno = 0; bandno < rlevel->nbands;
> > bandno++,subbandno++) {
> >  int nb_precincts, precno;
> >  Jpeg2000Band *band = rlevel->band + bandno;
> >  int cblkno = 0, bandpos;
> > @@ -1979,12 +1901,21 @@ static inline void tile_codeblocks(const
> > Jpeg2000DecoderContext *s, Jpeg2000Tile
> >  for (cblkno = 0;
> >   cblkno < prec->nb_codeblocks_width * prec-
> > >nb_codeblocks_height;
> >   cblkno++) {
> > -int x, y;
> > +int x, y, ret, magp;
> >  Jpeg2000Cblk *cblk = prec->cblk + cblkno;
> > -int ret = decode_cblk(s, codsty, &t1, cblk,
> > -cblk->coord[0][1] - cblk-
> > >coord[0][0],
> > -cblk->coord[1][1] - cblk-
> > >coord[1][0],
> > - 

Re: [FFmpeg-devel] [PATCH v3] libavcodec/cbs_av1: Add size check before parse obu

2022-09-21 Thread Xiang, Haihao


> cbs_av1_write_unit() check pbc size after parsing obu frame, and return

It is cbs_av1_write_obu(), not cbs_av1_write_unit(), right ? 

Thanks
Haihao


> AVERROR(ENOSPC) if pbc is small. pbc will be reallocated and this obu
> frame will be parsed again, but this may cause error because
> CodedBitstreamAV1Context has already been updated, for example
> ref_order_hint is updated and will not match the same obu frame. Now size
> check is added before parsing obu frame to avoid this error.
> 
> Signed-off-by: Wenbin Chen 
> ---
>  libavcodec/cbs_av1.c | 3 +++
>  1 file changed, 3 insertions(+)
> 
> diff --git a/libavcodec/cbs_av1.c b/libavcodec/cbs_av1.c
> index 154d9156cf..9c51a8c7c8 100644
> --- a/libavcodec/cbs_av1.c
> +++ b/libavcodec/cbs_av1.c
> @@ -1075,6 +1075,9 @@ static int cbs_av1_write_obu(CodedBitstreamContext *ctx,
>  put_bits32(pbc, 0);
>  }
>  
> +if (8 * (unit->data_size + obu->obu_size) > put_bits_left(pbc))
> +return AVERROR(ENOSPC);
> +
>  td = NULL;
>  start_pos = put_bits_count(pbc);
>  
___
ffmpeg-devel mailing list
ffmpeg-devel@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] sws: add jobs option, distinct from threads

2022-09-21 Thread Michael Niedermayer
On Tue, Sep 20, 2022 at 12:50:16PM -0500, rcombs wrote:
> This allows for more efficient use of asymmetric-multiprocessing systems.
> ---
>  libswscale/options.c  | 2 ++
>  libswscale/swscale_internal.h | 1 +
>  libswscale/utils.c| 9 ++---
>  libswscale/version.h  | 2 +-
>  4 files changed, 10 insertions(+), 4 deletions(-)

This chnages the output from
./ffmpeg -i ~/tickets/1984/00186002.avi -vframes 100 -qscale 1 -an -bitexact 
file-1984-ref.avi
(i suspect its all yuv410p indeo videos not just this one)

I presume thats unintended
also the jobs number ideally, especially with bitexact should not change
the output

but maybe iam missing something

thx


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

Whats the most studid thing your enemy could do ? Blow himself up
Whats the most studid thing you could do ? Give up your rights and
freedom because your enemy blew himself up.



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 2/7] sws: add jobs option, distinct from threads

2022-09-21 Thread Michael Niedermayer
On Wed, Sep 21, 2022 at 10:37:04AM +0200, Michael Niedermayer wrote:
> On Tue, Sep 20, 2022 at 12:50:16PM -0500, rcombs wrote:
> > This allows for more efficient use of asymmetric-multiprocessing systems.
> > ---
> >  libswscale/options.c  | 2 ++
> >  libswscale/swscale_internal.h | 1 +
> >  libswscale/utils.c| 9 ++---
> >  libswscale/version.h  | 2 +-
> >  4 files changed, 10 insertions(+), 4 deletions(-)
> 
> This chnages the output from
> ./ffmpeg -i ~/tickets/1984/00186002.avi -vframes 100 -qscale 1 -an -bitexact 
> file-1984-ref.avi
> (i suspect its all yuv410p indeo videos not just this one)
> 
> I presume thats unintended
> also the jobs number ideally, especially with bitexact should not change
> the output
> 
> but maybe iam missing something

"same" issue appears with some dxtory, snow and 10bit h264 inputs

[...]

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

No human being will ever know the Truth, for even if they happen to say it
by chance, they would not even known they had done so. -- Xenophanes


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 2/2] avfilter/avfilter: Make ff_command_queue_pop() static

2022-09-21 Thread Nicolas George
Andreas Rheinhardt (12022-09-21):
> Only used here.
> 
> Signed-off-by: Andreas Rheinhardt 
> ---
>  libavfilter/avfilter.c | 6 +++---
>  libavfilter/internal.h | 2 --
>  2 files changed, 3 insertions(+), 5 deletions(-)

Both patches look ok.

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".


Re: [FFmpeg-devel] [PATCH 1/4] avcodec/snow: Move ff_snow_inner_add_yblock() to snow_dwt.c

2022-09-21 Thread Michael Niedermayer
On Mon, Sep 19, 2022 at 11:27:49PM +0200, Andreas Rheinhardt wrote:
> Only used there and by x86 snow asm code as fallback.
> 
> Signed-off-by: Andreas Rheinhardt 
> ---
>  libavcodec/snow.c | 33 -
>  libavcodec/snow.h |  3 ---
>  libavcodec/snow_dwt.c | 32 
>  libavcodec/snow_dwt.h |  3 +++
>  4 files changed, 35 insertions(+), 36 deletions(-)
> 
> diff --git a/libavcodec/snow.c b/libavcodec/snow.c
> index aa15fccc42..85ad6d10a1 100644
> --- a/libavcodec/snow.c
> +++ b/libavcodec/snow.c
> @@ -29,39 +29,6 @@
>  #include "snowdata.h"
>  
>  
> -void ff_snow_inner_add_yblock(const uint8_t *obmc, const int obmc_stride, 
> uint8_t * * block, int b_w, int b_h,
> -  int src_x, int src_y, int src_stride, 
> slice_buffer * sb, int add, uint8_t * dst8){
> -int y, x;
> -IDWTELEM * dst;
> -for(y=0; y -//FIXME ugly misuse of obmc_stride
> -const uint8_t *obmc1= obmc + y*obmc_stride;
> -const uint8_t *obmc2= obmc1+ (obmc_stride>>1);
> -const uint8_t *obmc3= obmc1+ obmc_stride*(obmc_stride>>1);
> -const uint8_t *obmc4= obmc3+ (obmc_stride>>1);
> -dst = slice_buffer_get_line(sb, src_y + y);
> -for(x=0; x -int v=   obmc1[x] * block[3][x + y*src_stride]
> -+obmc2[x] * block[2][x + y*src_stride]
> -+obmc3[x] * block[1][x + y*src_stride]
> -+obmc4[x] * block[0][x + y*src_stride];
> -
> -v <<= 8 - LOG2_OBMC_MAX;
> -if(FRAC_BITS != 8){
> -v >>= 8 - FRAC_BITS;
> -}
> -if(add){
> -v += dst[x + src_x];
> -v = (v + (1<<(FRAC_BITS-1))) >> FRAC_BITS;
> -if(v&(~255)) v= ~(v>>31);
> -dst8[x + y*src_stride] = v;
> -}else{
> -dst[x + src_x] -= v;
> -}
> -}
> -}
> -}
> -
>  int ff_snow_get_buffer(SnowContext *s, AVFrame *frame)
>  {
>  int ret, i;
> diff --git a/libavcodec/snow.h b/libavcodec/snow.h
> index ed0f9abb42..1c976b9ba7 100644
> --- a/libavcodec/snow.h
> +++ b/libavcodec/snow.h
> @@ -45,11 +45,8 @@
>  #define QSHIFT 5
>  #define QROOT (1<  #define LOSSLESS_QLOG -128
> -#define FRAC_BITS 4
>  #define MAX_REF_FRAMES 8
>  
> -#define LOG2_OBMC_MAX 8
> -#define OBMC_MAX (1<<(LOG2_OBMC_MAX))
>  typedef struct BlockNode{
>  int16_t mx; ///< Motion vector component X, see mv_scale
>  int16_t my; ///< Motion vector component Y, see mv_scale
> diff --git a/libavcodec/snow_dwt.c b/libavcodec/snow_dwt.c
> index 18b315ef66..9401d119d0 100644
> --- a/libavcodec/snow_dwt.c
> +++ b/libavcodec/snow_dwt.c
> @@ -25,6 +25,38 @@
>  #include "me_cmp.h"
>  #include "snow_dwt.h"
>  
> +void ff_snow_inner_add_yblock(const uint8_t *obmc, const int obmc_stride,
> +  uint8_t **block, int b_w, int b_h,
> +  int src_x, int src_y, int src_stride,
> +  slice_buffer * sb, int add, uint8_t * dst8)
> +{
> +for (int y = 0; y < b_h; y++) {
> +//FIXME ugly misuse of obmc_stride
> +const uint8_t *obmc1 = obmc  + y * obmc_stride;
> +const uint8_t *obmc2 = obmc1 + (obmc_stride >> 1);
> +const uint8_t *obmc3 = obmc1 + obmc_stride * (obmc_stride >> 1);
> +const uint8_t *obmc4 = obmc3 + (obmc_stride >> 1);
> +IDWTELEM *dst = slice_buffer_get_line(sb, src_y + y);
> +for (int x = 0; x < b_w; x++) {
> +int v = obmc1[x] * block[3][x + y*src_stride]
> +  + obmc2[x] * block[2][x + y*src_stride]
> +  + obmc3[x] * block[1][x + y*src_stride]
> +  + obmc4[x] * block[0][x + y*src_stride];
> +
> +v <<= 8 - LOG2_OBMC_MAX;
> +if (FRAC_BITS != 8)
> +v >>= 8 - FRAC_BITS;
> +if (add) {
> +v += dst[x + src_x];
> +v = (v + (1 << (FRAC_BITS - 1))) >> FRAC_BITS;
> +if (v & (~255)) v= ~(v>>31);
> +dst8[x + y*src_stride] = v;
> +} else
> +dst[x + src_x] -= v;
> +}
> +}
> +}
> +

putting this in snow_dwt may be convenient but it is not part of the dwt so
this feels semantically wrong

thx

[...]

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

There will always be a question for which you do not know the correct answer.


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

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


Re: [FFmpeg-devel] [PATCH v3] libavcodec/cbs_av1: Add size check before parse obu

2022-09-21 Thread Chen, Wenbin
> > cbs_av1_write_unit() check pbc size after parsing obu frame, and return
> 
> It is cbs_av1_write_obu(), not cbs_av1_write_unit(), right ?
> 
> Thanks
> Haihao
> 

Sorry, it is typo. cbs_av1_write_obu is assigned to write_unit function pointer.
I will fix it and resubmit patch.

Thanks
Wenbin

> 
> > AVERROR(ENOSPC) if pbc is small. pbc will be reallocated and this obu
> > frame will be parsed again, but this may cause error because
> > CodedBitstreamAV1Context has already been updated, for example
> > ref_order_hint is updated and will not match the same obu frame. Now
> size
> > check is added before parsing obu frame to avoid this error.
> >
> > Signed-off-by: Wenbin Chen 
> > ---
> >  libavcodec/cbs_av1.c | 3 +++
> >  1 file changed, 3 insertions(+)
> >
> > diff --git a/libavcodec/cbs_av1.c b/libavcodec/cbs_av1.c
> > index 154d9156cf..9c51a8c7c8 100644
> > --- a/libavcodec/cbs_av1.c
> > +++ b/libavcodec/cbs_av1.c
> > @@ -1075,6 +1075,9 @@ static int
> cbs_av1_write_obu(CodedBitstreamContext *ctx,
> >  put_bits32(pbc, 0);
> >  }
> >
> > +if (8 * (unit->data_size + obu->obu_size) > put_bits_left(pbc))
> > +return AVERROR(ENOSPC);
> > +
> >  td = NULL;
> >  start_pos = put_bits_count(pbc);
> >
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@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 02/13] avformat/mxfdec: Check run_in to fit in int and be valid

2022-09-21 Thread Michael Niedermayer
On Tue, Sep 20, 2022 at 01:20:00PM +0200, Tomas Härdin wrote:
> tis 2022-09-20 klockan 13:07 +0200 skrev Tomas Härdin:
> > sön 2022-09-18 klockan 19:13 +0200 skrev Michael Niedermayer:
> > > Fixes: signed integer overflow: 9223372036854775807 - -2146905566
> > > cannot be represented in type 'long'
> > > Fixes: 50993/clusterfuzz-testcase-minimized-ffmpeg_dem_MXF_fuzzer-
> > > 6570996594769920
> > > 
> > > Found-by: continuous fuzzing process 
> > > https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
> > > Signed-off-by: Michael Niedermayer 
> > > ---
> > >  libavformat/mxfdec.c | 6 +-
> > >  1 file changed, 5 insertions(+), 1 deletion(-)
> > > 
> > > diff --git a/libavformat/mxfdec.c b/libavformat/mxfdec.c
> > > index e63e803aa56..da81fea3bc1 100644
> > > --- a/libavformat/mxfdec.c
> > > +++ b/libavformat/mxfdec.c
> > > @@ -3681,6 +3681,7 @@ static int mxf_read_header(AVFormatContext
> > > *s)
> > >  KLVPacket klv;
> > >  int64_t essence_offset = 0;
> > >  int ret;
> > > +    int64_t run_in;
> > >  
> > >  mxf->last_forward_tell = INT64_MAX;
> > >  
> > > @@ -3690,7 +3691,10 @@ static int mxf_read_header(AVFormatContext
> > > *s)
> > >  }
> > >  avio_seek(s->pb, -14, SEEK_CUR);
> > >  mxf->fc = s;
> > > -    mxf->run_in = avio_tell(s->pb);
> > > +    run_in = avio_tell(s->pb);
> > > +    if (run_in < 0 || run_in != (int)run_in)
> > 
> > run_in > INT_MAX is more clear
> > 
> > It strikes me that run_in is also used in lots of places in the
> > demuxer
> > without checking for overflow
> 
> I went and checked S377m and the run-in sequence "shall be less than
> 65536 bytes long". Both the 2004 and 2009 version of the spec agree on
> this. So we should reject run_in >= 65536, and mxf_probe() should be
> similarly adjusted.

ok, will do

thx for checking

i will change the patch by:
@@ -3717,7 +3717,7 @@ static int mxf_read_header(AVFormatContext *s)
 avio_seek(s->pb, -14, SEEK_CUR);
 mxf->fc = s;
 run_in = avio_tell(s->pb);
-if (run_in < 0 || run_in != (int)run_in)
+if (run_in < 0 || run_in > 65535)
 return AVERROR_INVALIDDATA;
 mxf->run_in = run_in;
 
@@ -4125,7 +4125,7 @@ static int mxf_read_close(AVFormatContext *s)
 
 static int mxf_probe(const AVProbeData *p) {
 const uint8_t *bufp = p->buf;
-const uint8_t *end = p->buf + p->buf_size;
+const uint8_t *end = p->buf + FFMIN(p->buf_size, 65536 + 
sizeof(mxf_header_partition_pack_key));
 
 if (p->buf_size < sizeof(mxf_header_partition_pack_key))
 return 0;

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

I know you won't believe me, but the highest form of Human Excellence is
to question oneself and others. -- Socrates


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

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


[FFmpeg-devel] [PATCH v4] libavcodec/cbs_av1: Add size check before parse obu

2022-09-21 Thread Wenbin Chen
cbs_av1_write_obu() check pbc size after parsing obu frame, and return
AVERROR(ENOSPC) if pbc is small. pbc will be reallocated and this obu
frame will be parsed again, but this may cause error because
CodedBitstreamAV1Context has already been updated, for example
ref_order_hint is updated and will not match the same obu frame. Now size
check is added before parsing obu frame to avoid this error.

Signed-off-by: Wenbin Chen 
---
 libavcodec/cbs_av1.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/libavcodec/cbs_av1.c b/libavcodec/cbs_av1.c
index 154d9156cf..9c51a8c7c8 100644
--- a/libavcodec/cbs_av1.c
+++ b/libavcodec/cbs_av1.c
@@ -1075,6 +1075,9 @@ static int cbs_av1_write_obu(CodedBitstreamContext *ctx,
 put_bits32(pbc, 0);
 }
 
+if (8 * (unit->data_size + obu->obu_size) > put_bits_left(pbc))
+return AVERROR(ENOSPC);
+
 td = NULL;
 start_pos = put_bits_count(pbc);
 
-- 
2.32.0

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

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


Re: [FFmpeg-devel] [PATCH 1/2] avcodec/mjpegdec: Check for unsupported bayer case

2022-09-21 Thread Michael Niedermayer
On Sun, Sep 18, 2022 at 11:57:03PM +0200, Michael Niedermayer wrote:
> Fixes: out of array access
> Fixes: 
> 51462/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_TIFF_fuzzer-662559341582745
> 
> Found-by: continuous fuzzing process 
> https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
> Signed-off-by: Michael Niedermayer 
> ---
>  libavcodec/mjpegdec.c | 2 ++
>  1 file changed, 2 insertions(+)

will apply this

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

When you are offended at any man's fault, turn to yourself and study your
own failings. Then you will forget your anger. -- Epictetus


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

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


Re: [FFmpeg-devel] [PATCH 0/3] Provide neon implementations

2022-09-21 Thread Martin Storsjö

On Tue, 20 Sep 2022, Hubert Mazur wrote:


This fixes issues addressed in previous patchset:
- move sub instruction in vsad8_intra,
- remove unnecessary mov instructions,
- remove single lane extraction in loop and place it at the end.

Removing mov instructions from pix_median_abs functions significantly
increased peformance for both.


I'm quite sure that it wasn't the removed mov instructions that improved 
performance (those instructions should be essentially free, they're just 
misleading), but the fact that you got rid of the extra single-element 
handling within the loop.


Anyway, the patches seem fine to me now, so I'll push them. Thanks!

// Martin

___
ffmpeg-devel mailing list
ffmpeg-devel@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] avcodec/jpeg2000: Add support for High-Throughput JPEG 2000 (HTJ2K) decoding.

2022-09-21 Thread Tomas Härdin
ons 2022-09-21 klockan 11:13 +0300 skrev Caleb Etemesi:
> > > Please separate struct renaming into a separate patch
> 
> Will do in the next patch
> 
> > > Corresponds to µ_start, right?
> 
> Not sure what  µ_start here relates to, but this is the zero bit
> plane
> information in *B.10.5*
> of the jpeg2000 spec (ITU Rec. T.800 (06/2019))
> 
> > > Could also be called Lcup and Lref. But fine I suppose.
> 
> Will change in the next patch
> 
> > > No time to review this atm, hopefully later though
> 
> No problem.
> 
> 
> > > Why are these tables in here when they're only used by
> > > jpeg2000htdec.c?
> 
> I wasn't aware of any table placing conventions and my personal
> preference
> is usually to place them
> inside header files.

You could have them in a separate file to make the code a bit easier to
read, but keeping them in a file that's included by both decoders is
kinda wrong. The compiler won't put them into the regular j2k decoder's
.o file since it doesn't use them, but still.

Tested this locally on some 4k sample files and it achieved 19 fps with
-lowres 2 on an Intel(R) Core(TM) i5-3317U CPU @ 1.70GHz (4 cores). I'm
getting access to a better machine to test this on as well.

I will probably spend some time getting this to work with the improved
threading patchset I've posted on here, once the new mem.* stuff is in.
Hopefully that brings realtime 4k htj2k decoding to threadripper and
similar CPUs, with low seek latency thanks to slice threading. That
would bring ffmpeg's decoder "ahead" of libopenjpeg, since opj only
does threading on slice (maybe precinct) level not codeblock level

/Tomas

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

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


Re: [FFmpeg-devel] [PATCH v1 3/3] swscale/la: Add output_lasx.c file.

2022-09-21 Thread Andreas Rheinhardt
Shiyou Yin:
> 
> 
>> 2022年9月11日 10:06,Shiyou Yin  写道:
>>
>>
>>
>>> 2022年9月9日 21:11,Andreas Rheinhardt >> > 写道:
>>>
>>> Shiyou Yin:


> 2022年9月6日 16:12,Shiyou Yin  > 写道:
>
>>
>> 2022年8月29日 20:30,Andreas Rheinhardt >  
>> > >> 写道:
>>
>> Hao Chen:
>>> ffmpeg -i ~/media/1_h264_1080p_30fps_3Mbps.mp4 -f rawvideo -s 640x480 
>>> -pix_fmt
>>> rgb24 -y /dev/null -an
>>> before: 150fps
>>> after: 183fps
>>>
>>> Signed-off-by: Hao Chen >> >
>>> ---
>>> libswscale/loongarch/Makefile | 3 +-
>>> libswscale/loongarch/output_lasx.c | 1982 +
>>> libswscale/loongarch/swscale_init_loongarch.c | 3 +
>>> libswscale/loongarch/swscale_loongarch.h | 6 +
>>> 4 files changed, 1993 insertions(+), 1 deletion(-)
>>> create mode 100644 libswscale/loongarch/output_lasx.c
>>>

>>> +static void
>>> +yuv2rgb_2_template_lasx(SwsContext *c, const int16_t *buf[2],
>>> + const int16_t *ubuf[2], const int16_t *vbuf[2],
>>> + const int16_t *abuf[2], uint8_t *dest, int dstW,
>>> + int yalpha, int uvalpha, int y,
>>> + enum AVPixelFormat target, int hasAlpha)
>>> +{
>>> + const int16_t *buf0 = buf[0], *buf1 = buf[1],
>>> + *ubuf0 = ubuf[0], *ubuf1 = ubuf[1],
>>> + *vbuf0 = vbuf[0], *vbuf1 = vbuf[1];
>>> + int yalpha1 = 4096 - yalpha;
>>> + int uvalpha1 = 4096 - uvalpha;
>>> + int i, count = 0;
>>> + int len = dstW - 15;
>>> + int len_count = (dstW + 1) >> 1;
>>> + const void *r, *g, *b;
>>> + int head = YUVRGB_TABLE_HEADROOM;
>>> + __m256i v_yalpha1 = __lasx_xvreplgr2vr_w(yalpha1);
>>> + __m256i v_uvalpha1 = __lasx_xvreplgr2vr_w(uvalpha1);
>>> + __m256i v_yalpha = __lasx_xvreplgr2vr_w(yalpha);
>>> + __m256i v_uvalpha = __lasx_xvreplgr2vr_w(uvalpha);
>>> + __m256i headroom = __lasx_xvreplgr2vr_w(head);
>>> +
>>> + for (i = 0; i < len; i += 16) {
>>> + int Y1, Y2, U, V;
>>> + int i_dex = i << 1;
>>> + int c_dex = count << 1;
>>> + __m256i y0_h, y0_l, y0, u0, v0;
>>> + __m256i y1_h, y1_l, y1, u1, v1;
>>> + __m256i y_l, y_h, u, v;
>>> +
>>> + DUP4_ARG2(__lasx_xvldx, buf0, i_dex, ubuf0, c_dex, vbuf0, c_dex,
>>> + buf1, i_dex, y0, u0, v0, y1);
>>> + DUP2_ARG2(__lasx_xvldx, ubuf1, c_dex, vbuf1, c_dex, u1, v1);
>>> + DUP2_ARG2(__lasx_xvsllwil_w_h, y0, 0, y1, 0, y0_l, y1_l);
>>> + DUP2_ARG1(__lasx_xvexth_w_h, y0, y1, y0_h, y1_h);
>>> + DUP4_ARG1(__lasx_vext2xv_w_h, u0, u1, v0, v1, u0, u1, v0, v1);
>>> + y0_l = __lasx_xvmul_w(y0_l, v_yalpha1);
>>> + y0_h = __lasx_xvmul_w(y0_h, v_yalpha1);
>>> + u0 = __lasx_xvmul_w(u0, v_uvalpha1);
>>> + v0 = __lasx_xvmul_w(v0, v_uvalpha1);
>>> + y_l = __lasx_xvmadd_w(y0_l, v_yalpha, y1_l);
>>> + y_h = __lasx_xvmadd_w(y0_h, v_yalpha, y1_h);
>>> + u = __lasx_xvmadd_w(u0, v_uvalpha, u1);
>>> + v = __lasx_xvmadd_w(v0, v_uvalpha, v1);
>>> + y_l = __lasx_xvsrai_w(y_l, 19);
>>> + y_h = __lasx_xvsrai_w(y_h, 19);
>>> + u = __lasx_xvsrai_w(u, 19);
>>> + v = __lasx_xvsrai_w(v, 19);
>>> + u = __lasx_xvadd_w(u, headroom);
>>> + v = __lasx_xvadd_w(v, headroom);
>>> + WRITE_YUV2RGB(y_l, y_l, u, v, 0, 1, 0, 0);
>>> + WRITE_YUV2RGB(y_l, y_l, u, v, 2, 3, 1, 1);
>>> + WRITE_YUV2RGB(y_h, y_h, u, v, 0, 1, 2, 2);
>>> + WRITE_YUV2RGB(y_h, y_h, u, v, 2, 3, 3, 3);
>>> + WRITE_YUV2RGB(y_l, y_l, u, v, 4, 5, 4, 4);
>>> + WRITE_YUV2RGB(y_l, y_l, u, v, 6, 7, 5, 5);
>>> + WRITE_YUV2RGB(y_h, y_h, u, v, 4, 5, 6, 6);
>>> + WRITE_YUV2RGB(y_h, y_h, u, v, 6, 7, 7, 7);
>>> + }
>>> + if (dstW - i >= 8) {
>>> + int Y1, Y2, U, V;
>>> + int i_dex = i << 1;
>>> + __m256i y0_l, y0, u0, v0;
>>> + __m256i y1_l, y1, u1, v1;
>>> + __m256i y_l, u, v;
>>> +
>>> + y0 = __lasx_xvldx(buf0, i_dex);
>>
>> 1. Not long ago, I tried to constify the src pointer of several asm
>> functions and noticed that they produced new warnings for loongarch
>> (according to patchwork:
>> https://patchwork.ffmpeg.org/project/ffmpeg/patch/db6pr0101mb2214178d3e6b8dca5b86f8198f...@db6pr0101mb2214.eurprd01.prod.exchangelabs.com/
>>  
>> ),
>> even though I was sure that the code is const-correct. After finding
>> (via https://github.com/opencv/opencv/pull/21833 
>> ) a toolchain
>> (https://gitee.com/wenux/cross-compiler-la-on-x86 
>> ) that can build the
>> lasx and lsx code (upstream GCC seems to be lack

Re: [FFmpeg-devel] [PATCH 1/4] avcodec/snow: Move ff_snow_inner_add_yblock() to snow_dwt.c

2022-09-21 Thread Andreas Rheinhardt
Michael Niedermayer:
> On Mon, Sep 19, 2022 at 11:27:49PM +0200, Andreas Rheinhardt wrote:
>> Only used there and by x86 snow asm code as fallback.
>>
>> Signed-off-by: Andreas Rheinhardt 
>> ---
>>  libavcodec/snow.c | 33 -
>>  libavcodec/snow.h |  3 ---
>>  libavcodec/snow_dwt.c | 32 
>>  libavcodec/snow_dwt.h |  3 +++
>>  4 files changed, 35 insertions(+), 36 deletions(-)
>>
>> diff --git a/libavcodec/snow.c b/libavcodec/snow.c
>> index aa15fccc42..85ad6d10a1 100644
>> --- a/libavcodec/snow.c
>> +++ b/libavcodec/snow.c
>> @@ -29,39 +29,6 @@
>>  #include "snowdata.h"
>>  
>>  
>> -void ff_snow_inner_add_yblock(const uint8_t *obmc, const int obmc_stride, 
>> uint8_t * * block, int b_w, int b_h,
>> -  int src_x, int src_y, int src_stride, 
>> slice_buffer * sb, int add, uint8_t * dst8){
>> -int y, x;
>> -IDWTELEM * dst;
>> -for(y=0; y> -//FIXME ugly misuse of obmc_stride
>> -const uint8_t *obmc1= obmc + y*obmc_stride;
>> -const uint8_t *obmc2= obmc1+ (obmc_stride>>1);
>> -const uint8_t *obmc3= obmc1+ obmc_stride*(obmc_stride>>1);
>> -const uint8_t *obmc4= obmc3+ (obmc_stride>>1);
>> -dst = slice_buffer_get_line(sb, src_y + y);
>> -for(x=0; x> -int v=   obmc1[x] * block[3][x + y*src_stride]
>> -+obmc2[x] * block[2][x + y*src_stride]
>> -+obmc3[x] * block[1][x + y*src_stride]
>> -+obmc4[x] * block[0][x + y*src_stride];
>> -
>> -v <<= 8 - LOG2_OBMC_MAX;
>> -if(FRAC_BITS != 8){
>> -v >>= 8 - FRAC_BITS;
>> -}
>> -if(add){
>> -v += dst[x + src_x];
>> -v = (v + (1<<(FRAC_BITS-1))) >> FRAC_BITS;
>> -if(v&(~255)) v= ~(v>>31);
>> -dst8[x + y*src_stride] = v;
>> -}else{
>> -dst[x + src_x] -= v;
>> -}
>> -}
>> -}
>> -}
>> -
>>  int ff_snow_get_buffer(SnowContext *s, AVFrame *frame)
>>  {
>>  int ret, i;
>> diff --git a/libavcodec/snow.h b/libavcodec/snow.h
>> index ed0f9abb42..1c976b9ba7 100644
>> --- a/libavcodec/snow.h
>> +++ b/libavcodec/snow.h
>> @@ -45,11 +45,8 @@
>>  #define QSHIFT 5
>>  #define QROOT (1<>  #define LOSSLESS_QLOG -128
>> -#define FRAC_BITS 4
>>  #define MAX_REF_FRAMES 8
>>  
>> -#define LOG2_OBMC_MAX 8
>> -#define OBMC_MAX (1<<(LOG2_OBMC_MAX))
>>  typedef struct BlockNode{
>>  int16_t mx; ///< Motion vector component X, see mv_scale
>>  int16_t my; ///< Motion vector component Y, see mv_scale
>> diff --git a/libavcodec/snow_dwt.c b/libavcodec/snow_dwt.c
>> index 18b315ef66..9401d119d0 100644
>> --- a/libavcodec/snow_dwt.c
>> +++ b/libavcodec/snow_dwt.c
>> @@ -25,6 +25,38 @@
>>  #include "me_cmp.h"
>>  #include "snow_dwt.h"
>>  
>> +void ff_snow_inner_add_yblock(const uint8_t *obmc, const int obmc_stride,
>> +  uint8_t **block, int b_w, int b_h,
>> +  int src_x, int src_y, int src_stride,
>> +  slice_buffer * sb, int add, uint8_t * dst8)
>> +{
>> +for (int y = 0; y < b_h; y++) {
>> +//FIXME ugly misuse of obmc_stride
>> +const uint8_t *obmc1 = obmc  + y * obmc_stride;
>> +const uint8_t *obmc2 = obmc1 + (obmc_stride >> 1);
>> +const uint8_t *obmc3 = obmc1 + obmc_stride * (obmc_stride >> 1);
>> +const uint8_t *obmc4 = obmc3 + (obmc_stride >> 1);
>> +IDWTELEM *dst = slice_buffer_get_line(sb, src_y + y);
>> +for (int x = 0; x < b_w; x++) {
>> +int v = obmc1[x] * block[3][x + y*src_stride]
>> +  + obmc2[x] * block[2][x + y*src_stride]
>> +  + obmc3[x] * block[1][x + y*src_stride]
>> +  + obmc4[x] * block[0][x + y*src_stride];
>> +
>> +v <<= 8 - LOG2_OBMC_MAX;
>> +if (FRAC_BITS != 8)
>> +v >>= 8 - FRAC_BITS;
>> +if (add) {
>> +v += dst[x + src_x];
>> +v = (v + (1 << (FRAC_BITS - 1))) >> FRAC_BITS;
>> +if (v & (~255)) v= ~(v>>31);
>> +dst8[x + y*src_stride] = v;
>> +} else
>> +dst[x + src_x] -= v;
>> +}
>> +}
>> +}
>> +
> 
> putting this in snow_dwt may be convenient but it is not part of the dwt so
> this feels semantically wrong
> 

If it is not part of the dwt, then why does SnowDWTContext have an
inner_add_yblock function pointer whose C version is
ff_snow_inner_add_yblock?

- 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] libavformat\matroskadec.c: crop support for matroska demuxer.

2022-09-21 Thread OvchinnikovDmitrii
In webm specification, it supports cropping information. 
(https://www.webmproject.org/docs/container/)
In ffmpeg, the implementation of webm is a subset of matroska. In 
matroskadec.c, those cropping related four fields are forced to 0.

for the sample file with crop (crop_bottom =8, crop_top=crop_left=crop_right=0.)
ffmpeg.exe -i  test_with_container_crop.webm -pix_fmt yuv420p -y output.yuv

original ffmpeg code - the output.yuv resolution is 1920x1088
changed code - the output.yuv resolution is 1920x1080"
---
 libavcodec/avcodec.h  |  8 
 libavcodec/codec_par.c|  8 
 libavcodec/codec_par.h|  8 
 libavcodec/decode.c   |  9 +
 libavformat/matroskadec.c | 17 +
 5 files changed, 46 insertions(+), 4 deletions(-)

diff --git a/libavcodec/avcodec.h b/libavcodec/avcodec.h
index 7db5d1b1c5..4420cfa0c9 100644
--- a/libavcodec/avcodec.h
+++ b/libavcodec/avcodec.h
@@ -585,6 +585,14 @@ typedef struct AVCodecContext {
  */
 int coded_width, coded_height;
 
+/**
+ * The dimensions of the crop, usually from container.
+ */
+int crop_top;
+int crop_left;
+int crop_bottom;
+int crop_right;
+
 /**
  * the number of pictures in a group of pictures, or 0 for intra_only
  * - encoding: Set by user.
diff --git a/libavcodec/codec_par.c b/libavcodec/codec_par.c
index abda649aa8..f74964a817 100644
--- a/libavcodec/codec_par.c
+++ b/libavcodec/codec_par.c
@@ -118,6 +118,10 @@ int avcodec_parameters_from_context(AVCodecParameters *par,
 par->format  = codec->pix_fmt;
 par->width   = codec->width;
 par->height  = codec->height;
+par->crop_top   = codec->crop_top;
+par->crop_left  = codec->crop_left;
+par->crop_bottom= codec->crop_bottom;
+par->crop_right = codec->crop_right;
 par->field_order = codec->field_order;
 par->color_range = codec->color_range;
 par->color_primaries = codec->color_primaries;
@@ -199,6 +203,10 @@ int avcodec_parameters_to_context(AVCodecContext *codec,
 codec->pix_fmt= par->format;
 codec->width  = par->width;
 codec->height = par->height;
+codec->crop_top   = par->crop_top;
+codec->crop_left  = par->crop_left;
+codec->crop_bottom= par->crop_bottom;
+codec->crop_right = par->crop_right;
 codec->field_order= par->field_order;
 codec->color_range= par->color_range;
 codec->color_primaries= par->color_primaries;
diff --git a/libavcodec/codec_par.h b/libavcodec/codec_par.h
index 7660791a12..6671f1810b 100644
--- a/libavcodec/codec_par.h
+++ b/libavcodec/codec_par.h
@@ -127,6 +127,14 @@ typedef struct AVCodecParameters {
 int width;
 int height;
 
+/**
+ * The dimensions of the crop, usually from container.
+ */
+int crop_top;
+int crop_left;
+int crop_bottom;
+int crop_right;
+
 /**
  * Video only. The aspect ratio (width / height) which a single pixel
  * should have when displayed.
diff --git a/libavcodec/decode.c b/libavcodec/decode.c
index 2961705c9d..905eb8401e 100644
--- a/libavcodec/decode.c
+++ b/libavcodec/decode.c
@@ -324,6 +324,15 @@ static inline int decode_simple_internal(AVCodecContext 
*avctx, AVFrame *frame,
 emms_c();
 actual_got_frame = got_frame;
 
+if (avctx->codec->type == AVMEDIA_TYPE_VIDEO) {
+if (avctx->crop_top != 0 || avctx->crop_left != 0 || avctx->crop_right 
!= 0 || avctx->crop_bottom != 0){
+frame->crop_top = avctx->crop_top;
+frame->crop_left= avctx->crop_left;
+frame->crop_right   = avctx->crop_right;
+frame->crop_bottom  = avctx->crop_bottom;
+}
+}
+
 if (avctx->codec->type == AVMEDIA_TYPE_VIDEO) {
 if (frame->flags & AV_FRAME_FLAG_DISCARD)
 got_frame = 0;
diff --git a/libavformat/matroskadec.c b/libavformat/matroskadec.c
index 16a3e93611..6e05b36e58 100644
--- a/libavformat/matroskadec.c
+++ b/libavformat/matroskadec.c
@@ -209,6 +209,10 @@ typedef struct MatroskaTrackVideo {
 uint64_t pixel_width;
 uint64_t pixel_height;
 EbmlBin  color_space;
+uint64_t pixel_cropt;
+uint64_t pixel_cropl;
+uint64_t pixel_cropb;
+uint64_t pixel_cropr;
 uint64_t display_unit;
 uint64_t interlaced;
 uint64_t field_order;
@@ -516,10 +520,10 @@ static EbmlSyntax matroska_track_video[] = {
 { MATROSKA_ID_VIDEOALPHAMODE,  EBML_UINT,  0, 0, 
offsetof(MatroskaTrackVideo, alpha_mode), { .u = 0 } },
 { MATROSKA_ID_VIDEOCOLOR,  EBML_NEST,  0, 
sizeof(MatroskaTrackVideoColor), offsetof(MatroskaTrackVideo, color), { .n = 
matroska_track_video_color } },
 { MATROSKA_ID_VIDEOPROJECTION, EBML_NEST,  0, 0, 
of

Re: [FFmpeg-devel] [PATCH] lavc/videotoolboxenc: Fix crash by uninitialized value

2022-09-21 Thread Thilo Borgmann

Am 15.09.22 um 20:42 schrieb Thilo Borgmann:

If create_cv_pixel_buffer() fails, pixel_buffer_info might get into CFRelease() 
containing an arbitrary value.
---
  libavcodec/videotoolboxenc.c | 4 +---
  1 file changed, 1 insertion(+), 3 deletions(-)

diff --git a/libavcodec/videotoolboxenc.c b/libavcodec/videotoolboxenc.c
index bb3065d1d5..dc9e321d3d 100644
--- a/libavcodec/videotoolboxenc.c
+++ b/libavcodec/videotoolboxenc.c
@@ -1440,7 +1440,7 @@ static int vtenc_create_encoder(AVCodecContext   *avctx,
  static int vtenc_configure_encoder(AVCodecContext *avctx)
  {
  CFMutableDictionaryRef enc_info;
-CFMutableDictionaryRef pixel_buffer_info;
+CFMutableDictionaryRef pixel_buffer_info = NULL;
  CMVideoCodecType   codec_type;
  VTEncContext   *vtctx = avctx->priv_data;
  CFStringRefprofile_level = NULL;
@@ -1517,8 +1517,6 @@ static int vtenc_configure_encoder(AVCodecContext *avctx)
  status = create_cv_pixel_buffer_info(avctx, &pixel_buffer_info);
  if (status)
  goto init_cleanup;
-} else {
-pixel_buffer_info = NULL;
  }
  
  vtctx->dts_delta = vtctx->has_b_frames ? -1 : 0;


LGTM's by ePirat on IRC. Pushed.

Thanks,
Thilo
___
ffmpeg-devel mailing list
ffmpeg-devel@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/cafenc: derive Opus frame size from the relevant stream parameters

2022-09-21 Thread James Almer
Use the stream duration as last resort, as an off-by-one result of the
"st->duration / (caf->packets - 1)" calculation can break playback on some
devices.

Fixes ticket #9930.

Signed-off-by: James Almer 
---
 libavformat/cafenc.c | 12 +---
 1 file changed, 9 insertions(+), 3 deletions(-)

diff --git a/libavformat/cafenc.c b/libavformat/cafenc.c
index fedb430b17..c203747b15 100644
--- a/libavformat/cafenc.c
+++ b/libavformat/cafenc.c
@@ -53,7 +53,11 @@ static uint32_t codec_flags(enum AVCodecID codec_id) {
 }
 }
 
-static uint32_t samples_per_packet(enum AVCodecID codec_id, int channels, int 
block_align) {
+static uint32_t samples_per_packet(AVCodecParameters *par) {
+enum AVCodecID codec_id = par->codec_id;
+int channels = par->ch_layout.nb_channels, block_align = par->block_align;
+int frame_size = par->frame_size, sample_rate = par->sample_rate;
+
 switch (codec_id) {
 case AV_CODEC_ID_PCM_S8:
 case AV_CODEC_ID_PCM_S16LE:
@@ -83,6 +87,8 @@ static uint32_t samples_per_packet(enum AVCodecID codec_id, 
int channels, int bl
 return 320;
 case AV_CODEC_ID_MP1:
 return 384;
+case AV_CODEC_ID_OPUS:
+return frame_size * 48000 / sample_rate;
 case AV_CODEC_ID_MP2:
 case AV_CODEC_ID_MP3:
 return 1152;
@@ -139,7 +145,7 @@ static int caf_write_header(AVFormatContext *s)
 }
 
 if (par->codec_id != AV_CODEC_ID_MP3 || frame_size != 576)
-frame_size = samples_per_packet(par->codec_id, 
par->ch_layout.nb_channels, par->block_align);
+frame_size = samples_per_packet(par);
 
 ffio_wfourcc(pb, "caff"); //< mFileType
 avio_wb16(pb, 1); //< mFileVersion
@@ -248,7 +254,7 @@ static int caf_write_trailer(AVFormatContext *s)
 avio_seek(pb, caf->data, SEEK_SET);
 avio_wb64(pb, file_size - caf->data - 8);
 if (!par->block_align) {
-int packet_size = samples_per_packet(par->codec_id, 
par->ch_layout.nb_channels, par->block_align);
+int packet_size = samples_per_packet(par);
 if (!packet_size) {
 packet_size = st->duration / (caf->packets - 1);
 avio_seek(pb, FRAME_SIZE_OFFSET, SEEK_SET);
-- 
2.37.3

___
ffmpeg-devel mailing list
ffmpeg-devel@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 02/13] avformat/mxfdec: Check run_in to fit in int and be valid

2022-09-21 Thread Tomas Härdin
ons 2022-09-21 klockan 11:35 +0200 skrev Michael Niedermayer:
> On Tue, Sep 20, 2022 at 01:20:00PM +0200, Tomas Härdin wrote:
> > tis 2022-09-20 klockan 13:07 +0200 skrev Tomas Härdin:
> > > sön 2022-09-18 klockan 19:13 +0200 skrev Michael Niedermayer:
> > > > Fixes: signed integer overflow: 9223372036854775807 - -
> > > > 2146905566
> > > > cannot be represented in type 'long'
> > > > Fixes: 50993/clusterfuzz-testcase-minimized-
> > > > ffmpeg_dem_MXF_fuzzer-
> > > > 6570996594769920
> > > > 
> > > > Found-by: continuous fuzzing process 
> > > > https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
> > > > Signed-off-by: Michael Niedermayer 
> > > > ---
> > > >  libavformat/mxfdec.c | 6 +-
> > > >  1 file changed, 5 insertions(+), 1 deletion(-)
> > > > 
> > > > diff --git a/libavformat/mxfdec.c b/libavformat/mxfdec.c
> > > > index e63e803aa56..da81fea3bc1 100644
> > > > --- a/libavformat/mxfdec.c
> > > > +++ b/libavformat/mxfdec.c
> > > > @@ -3681,6 +3681,7 @@ static int
> > > > mxf_read_header(AVFormatContext
> > > > *s)
> > > >  KLVPacket klv;
> > > >  int64_t essence_offset = 0;
> > > >  int ret;
> > > > +    int64_t run_in;
> > > >  
> > > >  mxf->last_forward_tell = INT64_MAX;
> > > >  
> > > > @@ -3690,7 +3691,10 @@ static int
> > > > mxf_read_header(AVFormatContext
> > > > *s)
> > > >  }
> > > >  avio_seek(s->pb, -14, SEEK_CUR);
> > > >  mxf->fc = s;
> > > > -    mxf->run_in = avio_tell(s->pb);
> > > > +    run_in = avio_tell(s->pb);
> > > > +    if (run_in < 0 || run_in != (int)run_in)
> > > 
> > > run_in > INT_MAX is more clear
> > > 
> > > It strikes me that run_in is also used in lots of places in the
> > > demuxer
> > > without checking for overflow
> > 
> > I went and checked S377m and the run-in sequence "shall be less
> > than
> > 65536 bytes long". Both the 2004 and 2009 version of the spec agree
> > on
> > this. So we should reject run_in >= 65536, and mxf_probe() should
> > be
> > similarly adjusted.
> 
> ok, will do
> 
> thx for checking
> 
> i will change the patch by:
> @@ -3717,7 +3717,7 @@ static int mxf_read_header(AVFormatContext *s)
>  avio_seek(s->pb, -14, SEEK_CUR);
>  mxf->fc = s;
>  run_in = avio_tell(s->pb);
> -    if (run_in < 0 || run_in != (int)run_in)
> +    if (run_in < 0 || run_in > 65535)

Let's avoid magic numbers:
#define RUN_IN_MAX 65535  // S377m-2004 section 5.5 and S377-1-2009
section 6.5

>  return AVERROR_INVALIDDATA;
>  mxf->run_in = run_in;
>  
> @@ -4125,7 +4125,7 @@ static int mxf_read_close(AVFormatContext *s)
>  
>  static int mxf_probe(const AVProbeData *p) {
>  const uint8_t *bufp = p->buf;
> -    const uint8_t *end = p->buf + p->buf_size;
> +    const uint8_t *end = p->buf + FFMIN(p->buf_size, 65536 +
> sizeof(mxf_header_partition_pack_key));

Seems correct. I tested this by prefixing fate-suite/mxf/Meridian-
Apple_ProResProxy-HDR10.mxf with 65535 NUL bytes which worked fine, and
65536 NUL bytes which does not probe as MXF as expected

/Tomas

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

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


Re: [FFmpeg-devel] [PATCH 02/13] avformat/mxfdec: Check run_in to fit in int and be valid

2022-09-21 Thread Tomas Härdin
ons 2022-09-21 klockan 11:35 +0200 skrev Michael Niedermayer:
> On Tue, Sep 20, 2022 at 01:20:00PM +0200, Tomas Härdin wrote:
> > tis 2022-09-20 klockan 13:07 +0200 skrev Tomas Härdin:
> > > sön 2022-09-18 klockan 19:13 +0200 skrev Michael Niedermayer:
> > > > Fixes: signed integer overflow: 9223372036854775807 - -
> > > > 2146905566
> > > > cannot be represented in type 'long'
> > > > Fixes: 50993/clusterfuzz-testcase-minimized-
> > > > ffmpeg_dem_MXF_fuzzer-
> > > > 6570996594769920
> > > > 
> > > > Found-by: continuous fuzzing process 
> > > > https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
> > > > Signed-off-by: Michael Niedermayer 
> > > > ---
> > > >  libavformat/mxfdec.c | 6 +-
> > > >  1 file changed, 5 insertions(+), 1 deletion(-)
> > > > 
> > > > diff --git a/libavformat/mxfdec.c b/libavformat/mxfdec.c
> > > > index e63e803aa56..da81fea3bc1 100644
> > > > --- a/libavformat/mxfdec.c
> > > > +++ b/libavformat/mxfdec.c
> > > > @@ -3681,6 +3681,7 @@ static int
> > > > mxf_read_header(AVFormatContext
> > > > *s)
> > > >  KLVPacket klv;
> > > >  int64_t essence_offset = 0;
> > > >  int ret;
> > > > +    int64_t run_in;
> > > >  
> > > >  mxf->last_forward_tell = INT64_MAX;
> > > >  
> > > > @@ -3690,7 +3691,10 @@ static int
> > > > mxf_read_header(AVFormatContext
> > > > *s)
> > > >  }
> > > >  avio_seek(s->pb, -14, SEEK_CUR);
> > > >  mxf->fc = s;
> > > > -    mxf->run_in = avio_tell(s->pb);
> > > > +    run_in = avio_tell(s->pb);
> > > > +    if (run_in < 0 || run_in != (int)run_in)
> > > 
> > > run_in > INT_MAX is more clear
> > > 
> > > It strikes me that run_in is also used in lots of places in the
> > > demuxer
> > > without checking for overflow
> > 
> > I went and checked S377m and the run-in sequence "shall be less
> > than
> > 65536 bytes long". Both the 2004 and 2009 version of the spec agree
> > on
> > this. So we should reject run_in >= 65536, and mxf_probe() should
> > be
> > similarly adjusted.
> 
> ok, will do
> 
> thx for checking
> 
> i will change the patch by:
> @@ -3717,7 +3717,7 @@ static int mxf_read_header(AVFormatContext *s)
>  avio_seek(s->pb, -14, SEEK_CUR);

Oh and also the call to mxf_read_sync() could be supplied with a
maximum number of bytes to read, allowing the code to bail out faster

/Tomas

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

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


Re: [FFmpeg-devel] [PATCH 09/17] avcodec/libcodec2: Remove dead channel count check

2022-09-21 Thread Tomas Härdin
sön 2022-09-18 klockan 22:27 +0200 skrev Andreas Rheinhardt:
> This encoder has AVCodec.ch_layouts set, so that this is checked
> generically.
> 
> Signed-off-by: Andreas Rheinhardt 
> ---
>  libavcodec/libcodec2.c | 1 -
>  1 file changed, 1 deletion(-)
> 
> diff --git a/libavcodec/libcodec2.c b/libavcodec/libcodec2.c
> index be9677ddeb..581ef04ce2 100644
> --- a/libavcodec/libcodec2.c
> +++ b/libavcodec/libcodec2.c
> @@ -105,7 +105,6 @@ static av_cold int
> libcodec2_init_encoder(AVCodecContext *avctx)
>  
>  //will need to be smarter once we get wideband support
>  if (avctx->sample_rate != 8000 ||
> -    avctx->ch_layout.nb_channels != 1 ||
>  avctx->sample_fmt != AV_SAMPLE_FMT_S16) {
>  av_log(avctx, AV_LOG_ERROR, "only 8 kHz 16-bit mono
> allowed\n");
>  return AVERROR(EINVAL);

Should be fine

___
ffmpeg-devel mailing list
ffmpeg-devel@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] avcodec/jpeg2000: Add support for High-Throughput JPEG 2000 (HTJ2K) decoding.

2022-09-21 Thread Tomas Härdin
ons 2022-09-21 klockan 12:30 +0200 skrev Tomas Härdin:
> Tested this locally on some 4k sample files and it achieved 19 fps
> with
> -lowres 2 on an Intel(R) Core(TM) i5-3317U CPU @ 1.70GHz (4 cores).
> I'm
> getting access to a better machine to test this on as well.

Ran some tests on a c5n.4xlarge instance, Intel(R) Xeon(R) Platinum
8124M CPU @ 3.00GHz, 16 vCPUs. Test sequence is 273 4k htj2k frames
from Disney encoded with OpenJPH version 0.7.3, 20-21 megs each. Tested
like so:

./ffmpeg -i ~/samples/htj2k-unwrapped/00%03d.j2c -f null -

Achieved fps with a filled disk cache:
-lowres  this patch  libopenjpegdec
09.1 7.0
140  27
2105 92
3128 157
4129 164

This is with the default frame-based threading. Not too bad. I suspect
the slower performance compared to opj with -lowres >= 3 is due to the
way parsing works. This is what's holding up my codeblock-threading
patchset's performance as well.

I have in mind to compare this with a regular j2k sample on the same
machine, but it's taking its sweet time transferring..

/Tomas

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

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


[FFmpeg-devel] [PATCH 22 bis/26] lavc/fmtconvert: RISC-V V int32_to_float_fmul_scalar

2022-09-21 Thread remi
From: Rémi Denis-Courmont 

---
 libavcodec/fmtconvert.c|  2 ++
 libavcodec/fmtconvert.h|  1 +
 libavcodec/riscv/Makefile  |  2 ++
 libavcodec/riscv/fmtconvert_init.c | 39 +
 libavcodec/riscv/fmtconvert_rvv.S  | 40 ++
 5 files changed, 84 insertions(+)
 create mode 100644 libavcodec/riscv/fmtconvert_init.c
 create mode 100644 libavcodec/riscv/fmtconvert_rvv.S

diff --git a/libavcodec/fmtconvert.c b/libavcodec/fmtconvert.c
index cedfd61138..d889e61aca 100644
--- a/libavcodec/fmtconvert.c
+++ b/libavcodec/fmtconvert.c
@@ -52,6 +52,8 @@ av_cold void ff_fmt_convert_init(FmtConvertContext *c)
 ff_fmt_convert_init_arm(c);
 #elif ARCH_PPC
 ff_fmt_convert_init_ppc(c);
+#elif ARCH_RISCV
+ff_fmt_convert_init_riscv(c);
 #elif ARCH_X86
 ff_fmt_convert_init_x86(c);
 #endif
diff --git a/libavcodec/fmtconvert.h b/libavcodec/fmtconvert.h
index da244e05a5..1cb4628a64 100644
--- a/libavcodec/fmtconvert.h
+++ b/libavcodec/fmtconvert.h
@@ -61,6 +61,7 @@ void ff_fmt_convert_init(FmtConvertContext *c);
 void ff_fmt_convert_init_aarch64(FmtConvertContext *c);
 void ff_fmt_convert_init_arm(FmtConvertContext *c);
 void ff_fmt_convert_init_ppc(FmtConvertContext *c);
+void ff_fmt_convert_init_riscv(FmtConvertContext *c);
 void ff_fmt_convert_init_x86(FmtConvertContext *c);
 void ff_fmt_convert_init_mips(FmtConvertContext *c);
 
diff --git a/libavcodec/riscv/Makefile b/libavcodec/riscv/Makefile
index 99541b075e..682174e875 100644
--- a/libavcodec/riscv/Makefile
+++ b/libavcodec/riscv/Makefile
@@ -1,5 +1,7 @@
 OBJS-$(CONFIG_AUDIODSP) += riscv/audiodsp_init.o \
riscv/audiodsp_rvf.o
 RVV-OBJS-$(CONFIG_AUDIODSP) += riscv/audiodsp_rvv.o
+OBJS-$(CONFIG_FMTCONVERT) += riscv/fmtconvert_init.o
+RVV-OBJS-$(CONFIG_FMTCONVERT) += riscv/fmtconvert_rvv.o
 OBJS-$(CONFIG_PIXBLOCKDSP) += riscv/pixblockdsp_init.o \
   riscv/pixblockdsp_rvi.o
diff --git a/libavcodec/riscv/fmtconvert_init.c 
b/libavcodec/riscv/fmtconvert_init.c
new file mode 100644
index 00..fd2f58d060
--- /dev/null
+++ b/libavcodec/riscv/fmtconvert_init.c
@@ -0,0 +1,39 @@
+/*
+ * Copyright © 2022 Rémi Denis-Courmont.
+ *
+ * This file is part of FFmpeg.
+ *
+ * FFmpeg is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public
+ * License as published by the Free Software Foundation; either
+ * version 2.1 of the License, or (at your option) any later version.
+ *
+ * FFmpeg is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+ * Lesser General Public License for more details.
+ *
+ * You should have received a copy of the GNU Lesser General Public
+ * License along with FFmpeg; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA
+ */
+
+#include 
+
+#include "config.h"
+#include "libavutil/attributes.h"
+#include "libavutil/cpu.h"
+#include "libavcodec/fmtconvert.h"
+
+void ff_int32_to_float_fmul_scalar_rvv(float *dst, const int32_t *src,
+   float mul, int len);
+
+av_cold void ff_fmt_convert_init_riscv(FmtConvertContext *c)
+{
+#ifdef HAVE_RVV
+int flags = av_get_cpu_flags();
+
+if (flags & AV_CPU_FLAG_RV_ZVE32F)
+c->int32_to_float_fmul_scalar = ff_int32_to_float_fmul_scalar_rvv;
+#endif
+}
diff --git a/libavcodec/riscv/fmtconvert_rvv.S 
b/libavcodec/riscv/fmtconvert_rvv.S
new file mode 100644
index 00..c19b77e38a
--- /dev/null
+++ b/libavcodec/riscv/fmtconvert_rvv.S
@@ -0,0 +1,40 @@
+/*
+ * Copyright © 2022 Rémi Denis-Courmont.
+ *
+ * This file is part of FFmpeg.
+ *
+ * FFmpeg is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public
+ * License as published by the Free Software Foundation; either
+ * version 2.1 of the License, or (at your option) any later version.
+ *
+ * FFmpeg is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+ * Lesser General Public License for more details.
+ *
+ * You should have received a copy of the GNU Lesser General Public
+ * License along with FFmpeg; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA
+ */
+
+#include "config.h"
+#include "../libavutil/riscv/asm.S"
+
+func ff_int32_to_float_fmul_scalar_rvv, zve32f
+NOHWF   fmv.w.x fa0, a2
+NOHWF   mv  a2, a3
+1:
+vsetvli t0, a2, e32, m1, ta, ma
+vle32.v v24, (a1)
+sllit1, t0, 2
+vfcvt.f.x.v v24, v24
+sub a2, a2, t0
+vfmul.vfv24, v24, fa0
+add a1, a1, t1
+vse32.v   

Re: [FFmpeg-devel] [PATCH] libavformat\matroskadec.c: crop support for matroska demuxer.

2022-09-21 Thread Andreas Rheinhardt
OvchinnikovDmitrii:
> In webm specification, it supports cropping information. 
> (https://www.webmproject.org/docs/container/)

So does Matroska; actually, the only reason WebM supports this type of
cropping is because it is part of the subset of Matroska that WebM kept.

> In ffmpeg, the implementation of webm is a subset of matroska. In 
> matroskadec.c, those cropping related four fields are forced to 0.
> 
> for the sample file with crop (crop_bottom =8, 
> crop_top=crop_left=crop_right=0.)
> ffmpeg.exe -i  test_with_container_crop.webm -pix_fmt yuv420p -y output.yuv
> 
> original ffmpeg code - the output.yuv resolution is 1920x1088
> changed code - the output.yuv resolution is 1920x1080"
> ---
>  libavcodec/avcodec.h  |  8 
>  libavcodec/codec_par.c|  8 
>  libavcodec/codec_par.h|  8 
>  libavcodec/decode.c   |  9 +
>  libavformat/matroskadec.c | 17 +
>  5 files changed, 46 insertions(+), 4 deletions(-)
> 
> diff --git a/libavcodec/avcodec.h b/libavcodec/avcodec.h
> index 7db5d1b1c5..4420cfa0c9 100644
> --- a/libavcodec/avcodec.h
> +++ b/libavcodec/avcodec.h
> @@ -585,6 +585,14 @@ typedef struct AVCodecContext {
>   */
>  int coded_width, coded_height;
>  
> +/**
> + * The dimensions of the crop, usually from container.
> + */
> +int crop_top;
> +int crop_left;
> +int crop_bottom;
> +int crop_right;
> +
>  /**
>   * the number of pictures in a group of pictures, or 0 for intra_only
>   * - encoding: Set by user.
> diff --git a/libavcodec/codec_par.c b/libavcodec/codec_par.c
> index abda649aa8..f74964a817 100644
> --- a/libavcodec/codec_par.c
> +++ b/libavcodec/codec_par.c
> @@ -118,6 +118,10 @@ int avcodec_parameters_from_context(AVCodecParameters 
> *par,
>  par->format  = codec->pix_fmt;
>  par->width   = codec->width;
>  par->height  = codec->height;
> +par->crop_top   = codec->crop_top;
> +par->crop_left  = codec->crop_left;
> +par->crop_bottom= codec->crop_bottom;
> +par->crop_right = codec->crop_right;
>  par->field_order = codec->field_order;
>  par->color_range = codec->color_range;
>  par->color_primaries = codec->color_primaries;
> @@ -199,6 +203,10 @@ int avcodec_parameters_to_context(AVCodecContext *codec,
>  codec->pix_fmt= par->format;
>  codec->width  = par->width;
>  codec->height = par->height;
> +codec->crop_top   = par->crop_top;
> +codec->crop_left  = par->crop_left;
> +codec->crop_bottom= par->crop_bottom;
> +codec->crop_right = par->crop_right;
>  codec->field_order= par->field_order;
>  codec->color_range= par->color_range;
>  codec->color_primaries= par->color_primaries;
> diff --git a/libavcodec/codec_par.h b/libavcodec/codec_par.h
> index 7660791a12..6671f1810b 100644
> --- a/libavcodec/codec_par.h
> +++ b/libavcodec/codec_par.h
> @@ -127,6 +127,14 @@ typedef struct AVCodecParameters {
>  int width;
>  int height;
>  
> +/**
> + * The dimensions of the crop, usually from container.
> + */
> +int crop_top;
> +int crop_left;
> +int crop_bottom;
> +int crop_right;
> +
>  /**
>   * Video only. The aspect ratio (width / height) which a single pixel
>   * should have when displayed.
> diff --git a/libavcodec/decode.c b/libavcodec/decode.c
> index 2961705c9d..905eb8401e 100644
> --- a/libavcodec/decode.c
> +++ b/libavcodec/decode.c
> @@ -324,6 +324,15 @@ static inline int decode_simple_internal(AVCodecContext 
> *avctx, AVFrame *frame,
>  emms_c();
>  actual_got_frame = got_frame;
>  
> +if (avctx->codec->type == AVMEDIA_TYPE_VIDEO) {
> +if (avctx->crop_top != 0 || avctx->crop_left != 0 || 
> avctx->crop_right != 0 || avctx->crop_bottom != 0){
> +frame->crop_top = avctx->crop_top;
> +frame->crop_left= avctx->crop_left;
> +frame->crop_right   = avctx->crop_right;
> +frame->crop_bottom  = avctx->crop_bottom;
> +}
> +}
> +
>  if (avctx->codec->type == AVMEDIA_TYPE_VIDEO) {
>  if (frame->flags & AV_FRAME_FLAG_DISCARD)
>  got_frame = 0;
> diff --git a/libavformat/matroskadec.c b/libavformat/matroskadec.c
> index 16a3e93611..6e05b36e58 100644
> --- a/libavformat/matroskadec.c
> +++ b/libavformat/matroskadec.c
> @@ -209,6 +209,10 @@ typedef struct MatroskaTrackVideo {
>  uint64_t pixel_width;
>  uint64_t pixel_height;
>  EbmlBin  color_space;
> +uint64_t pixel_cropt;
> +uint64_t pixel_cropl;
> +uint64_t pixel_cropb;
> +uint64_t pixel_cropr;
>  uint64_t display_unit;
>  uint64_t interlaced;
>  uint64_t field_order;

Re: [FFmpeg-devel] [PATCH 1/3] avcodec/cavsdsp: Remove unused function parameter

2022-09-21 Thread Rémi Denis-Courmont
FWIW, set LGTM

-- 
Реми Дёни-Курмон
http://www.remlab.net/
___
ffmpeg-devel mailing list
ffmpeg-devel@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] avcodec/cavsdsp: Remove unused function parameter

2022-09-21 Thread Andreas Rheinhardt
Andreas Rheinhardt:
> Signed-off-by: Andreas Rheinhardt 
> ---
>  libavcodec/cavs.c| 2 +-
>  libavcodec/cavsdsp.c | 7 +++
>  libavcodec/cavsdsp.h | 6 +++---
>  libavcodec/x86/cavsdsp.c | 7 +++
>  4 files changed, 10 insertions(+), 12 deletions(-)
> 
> diff --git a/libavcodec/cavs.c b/libavcodec/cavs.c
> index 87bbe26f98..cba0a06e89 100644
> --- a/libavcodec/cavs.c
> +++ b/libavcodec/cavs.c
> @@ -797,7 +797,7 @@ av_cold int ff_cavs_init(AVCodecContext *avctx)
>  ff_h264chroma_init(&h->h264chroma, 8);
>  ff_idctdsp_init(&h->idsp, avctx);
>  ff_videodsp_init(&h->vdsp, 8);
> -ff_cavsdsp_init(&h->cdsp, avctx);
> +ff_cavsdsp_init(&h->cdsp);
>  ff_init_scantable_permutation(h->idsp.idct_permutation,
>h->cdsp.idct_perm);
>  ff_init_scantable(h->idsp.idct_permutation, &h->scantable, 
> ff_zigzag_direct);
> diff --git a/libavcodec/cavsdsp.c b/libavcodec/cavsdsp.c
> index b096de452c..af46eaf8d2 100644
> --- a/libavcodec/cavsdsp.c
> +++ b/libavcodec/cavsdsp.c
> @@ -22,8 +22,6 @@
>   * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 
> USA
>   */
>  
> -#include 
> -
>  #include "idctdsp.h"
>  #include "mathops.h"
>  #include "cavsdsp.h"
> @@ -548,7 +546,8 @@ CAVS_MC(avg_, 16)
>  #define put_cavs_qpel16_mc00_c ff_put_pixels16x16_c
>  #define avg_cavs_qpel16_mc00_c ff_avg_pixels16x16_c
>  
> -av_cold void ff_cavsdsp_init(CAVSDSPContext* c, AVCodecContext *avctx) {
> +av_cold void ff_cavsdsp_init(CAVSDSPContext* c)
> +{
>  #define dspfunc(PFX, IDX, NUM) \
>  c->PFX ## _pixels_tab[IDX][ 0] = PFX ## NUM ## _mc00_c; \
>  c->PFX ## _pixels_tab[IDX][ 1] = PFX ## NUM ## _mc10_c; \
> @@ -578,6 +577,6 @@ av_cold void ff_cavsdsp_init(CAVSDSPContext* c, 
> AVCodecContext *avctx) {
>  c->idct_perm = FF_IDCT_PERM_NONE;
>  
>  #if ARCH_X86
> -ff_cavsdsp_init_x86(c, avctx);
> +ff_cavsdsp_init_x86(c);
>  #endif
>  }
> diff --git a/libavcodec/cavsdsp.h b/libavcodec/cavsdsp.h
> index 9ccaa0addd..2cd9298963 100644
> --- a/libavcodec/cavsdsp.h
> +++ b/libavcodec/cavsdsp.h
> @@ -22,9 +22,9 @@
>  #ifndef AVCODEC_CAVSDSP_H
>  #define AVCODEC_CAVSDSP_H
>  
> +#include 
>  #include 
>  
> -#include "avcodec.h"
>  #include "qpeldsp.h"
>  
>  typedef struct CAVSDSPContext {
> @@ -38,7 +38,7 @@ typedef struct CAVSDSPContext {
>  int idct_perm;
>  } CAVSDSPContext;
>  
> -void ff_cavsdsp_init(CAVSDSPContext* c, AVCodecContext *avctx);
> -void ff_cavsdsp_init_x86(CAVSDSPContext* c, AVCodecContext *avctx);
> +void ff_cavsdsp_init(CAVSDSPContext* c);
> +void ff_cavsdsp_init_x86(CAVSDSPContext* c);
>  
>  #endif /* AVCODEC_CAVSDSP_H */
> diff --git a/libavcodec/x86/cavsdsp.c b/libavcodec/x86/cavsdsp.c
> index 7ceb51a23c..4ad977a034 100644
> --- a/libavcodec/x86/cavsdsp.c
> +++ b/libavcodec/x86/cavsdsp.c
> @@ -345,8 +345,7 @@ static void avg_cavs_qpel16_mc00_sse2(uint8_t *dst, const 
> uint8_t *src,
>  }
>  #endif
>  
> -static av_cold void cavsdsp_init_mmx(CAVSDSPContext *c,
> - AVCodecContext *avctx)
> +static av_cold void cavsdsp_init_mmx(CAVSDSPContext *c)
>  {
>  #if HAVE_MMX_EXTERNAL
>  c->put_cavs_qpel_pixels_tab[1][0] = put_cavs_qpel8_mc00_mmx;
> @@ -369,12 +368,12 @@ CAVS_MC(avg_,  8, mmxext)
>  CAVS_MC(avg_, 16, mmxext)
>  #endif /* HAVE_MMXEXT_INLINE */
>  
> -av_cold void ff_cavsdsp_init_x86(CAVSDSPContext *c, AVCodecContext *avctx)
> +av_cold void ff_cavsdsp_init_x86(CAVSDSPContext *c)
>  {
>  av_unused int cpu_flags = av_get_cpu_flags();
>  
>  if (X86_MMX(cpu_flags))
> -cavsdsp_init_mmx(c, avctx);
> +cavsdsp_init_mmx(c);
>  
>  #if HAVE_MMXEXT_INLINE
>  if (INLINE_MMXEXT(cpu_flags)) {

Ok'ed by Rémi Denis-Courmont on IRC. I will therefore apply this tonight
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".


[FFmpeg-devel] [PATCH] fate/subtitles: Ignore line endings in sub-pgs-remux test

2022-09-21 Thread Andreas Rheinhardt
Should fix ticket #9934.

Signed-off-by: Andreas Rheinhardt 
---
 tests/fate/subtitles.mak | 1 +
 1 file changed, 1 insertion(+)

diff --git a/tests/fate/subtitles.mak b/tests/fate/subtitles.mak
index e6684a814b..6c8ddf0d96 100644
--- a/tests/fate/subtitles.mak
+++ b/tests/fate/subtitles.mak
@@ -54,6 +54,7 @@ fate-sub-mpsub-frames: CMD = fmtstdout ass -i 
$(TARGET_SAMPLES)/sub/MPSub_capabi
 # timestamps of the remuxed file have been fixed up.
 FATE_SUBTITLES-$(call REMUX, SUP) += fate-sub-pgs-remux
 fate-sub-pgs-remux: CMD = transcode sup $(TARGET_SAMPLES)/sub/pgs_sub.sup sup 
"-copyts -c:s copy" "-copyts -c:s copy"
+fate-sub-pgs-remux: CMP = diff
 
 FATE_SUBTITLES_ASS-$(call DEMDEC, PJS, PJS) += fate-sub-pjs
 fate-sub-pjs: CMD = fmtstdout ass -i 
$(TARGET_SAMPLES)/sub/PJS_capability_tester.pjs
-- 
2.34.1

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

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


Re: [FFmpeg-devel] [PATCH 02/13] avformat/mxfdec: Check run_in to fit in int and be valid

2022-09-21 Thread Michael Niedermayer
On Wed, Sep 21, 2022 at 03:23:21PM +0200, Tomas Härdin wrote:
> ons 2022-09-21 klockan 11:35 +0200 skrev Michael Niedermayer:
> > On Tue, Sep 20, 2022 at 01:20:00PM +0200, Tomas Härdin wrote:
> > > tis 2022-09-20 klockan 13:07 +0200 skrev Tomas Härdin:
> > > > sön 2022-09-18 klockan 19:13 +0200 skrev Michael Niedermayer:
> > > > > Fixes: signed integer overflow: 9223372036854775807 - -
> > > > > 2146905566
> > > > > cannot be represented in type 'long'
> > > > > Fixes: 50993/clusterfuzz-testcase-minimized-
> > > > > ffmpeg_dem_MXF_fuzzer-
> > > > > 6570996594769920
> > > > > 
> > > > > Found-by: continuous fuzzing process 
> > > > > https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
> > > > > Signed-off-by: Michael Niedermayer 
> > > > > ---
> > > > >  libavformat/mxfdec.c | 6 +-
> > > > >  1 file changed, 5 insertions(+), 1 deletion(-)
> > > > > 
> > > > > diff --git a/libavformat/mxfdec.c b/libavformat/mxfdec.c
> > > > > index e63e803aa56..da81fea3bc1 100644
> > > > > --- a/libavformat/mxfdec.c
> > > > > +++ b/libavformat/mxfdec.c
> > > > > @@ -3681,6 +3681,7 @@ static int
> > > > > mxf_read_header(AVFormatContext
> > > > > *s)
> > > > >  KLVPacket klv;
> > > > >  int64_t essence_offset = 0;
> > > > >  int ret;
> > > > > +    int64_t run_in;
> > > > >  
> > > > >  mxf->last_forward_tell = INT64_MAX;
> > > > >  
> > > > > @@ -3690,7 +3691,10 @@ static int
> > > > > mxf_read_header(AVFormatContext
> > > > > *s)
> > > > >  }
> > > > >  avio_seek(s->pb, -14, SEEK_CUR);
> > > > >  mxf->fc = s;
> > > > > -    mxf->run_in = avio_tell(s->pb);
> > > > > +    run_in = avio_tell(s->pb);
> > > > > +    if (run_in < 0 || run_in != (int)run_in)
> > > > 
> > > > run_in > INT_MAX is more clear
> > > > 
> > > > It strikes me that run_in is also used in lots of places in the
> > > > demuxer
> > > > without checking for overflow
> > > 
> > > I went and checked S377m and the run-in sequence "shall be less
> > > than
> > > 65536 bytes long". Both the 2004 and 2009 version of the spec agree
> > > on
> > > this. So we should reject run_in >= 65536, and mxf_probe() should
> > > be
> > > similarly adjusted.
> > 
> > ok, will do
> > 
> > thx for checking
> > 
> > i will change the patch by:
> > @@ -3717,7 +3717,7 @@ static int mxf_read_header(AVFormatContext *s)
> >  avio_seek(s->pb, -14, SEEK_CUR);
> >  mxf->fc = s;
> >  run_in = avio_tell(s->pb);
> > -    if (run_in < 0 || run_in != (int)run_in)
> > +    if (run_in < 0 || run_in > 65535)
> 
> Let's avoid magic numbers:
> #define RUN_IN_MAX 65535  // S377m-2004 section 5.5 and S377-1-2009
> section 6.5

sure, will use this

thx

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

it is not once nor twice but times without number that the same ideas make
their appearance in the world. -- Aristotle


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

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


Re: [FFmpeg-devel] [PATCH 02/13] avformat/mxfdec: Check run_in to fit in int and be valid

2022-09-21 Thread Michael Niedermayer
On Wed, Sep 21, 2022 at 03:25:33PM +0200, Tomas Härdin wrote:
> ons 2022-09-21 klockan 11:35 +0200 skrev Michael Niedermayer:
> > On Tue, Sep 20, 2022 at 01:20:00PM +0200, Tomas Härdin wrote:
> > > tis 2022-09-20 klockan 13:07 +0200 skrev Tomas Härdin:
> > > > sön 2022-09-18 klockan 19:13 +0200 skrev Michael Niedermayer:
> > > > > Fixes: signed integer overflow: 9223372036854775807 - -
> > > > > 2146905566
> > > > > cannot be represented in type 'long'
> > > > > Fixes: 50993/clusterfuzz-testcase-minimized-
> > > > > ffmpeg_dem_MXF_fuzzer-
> > > > > 6570996594769920
> > > > > 
> > > > > Found-by: continuous fuzzing process 
> > > > > https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
> > > > > Signed-off-by: Michael Niedermayer 
> > > > > ---
> > > > >  libavformat/mxfdec.c | 6 +-
> > > > >  1 file changed, 5 insertions(+), 1 deletion(-)
> > > > > 
> > > > > diff --git a/libavformat/mxfdec.c b/libavformat/mxfdec.c
> > > > > index e63e803aa56..da81fea3bc1 100644
> > > > > --- a/libavformat/mxfdec.c
> > > > > +++ b/libavformat/mxfdec.c
> > > > > @@ -3681,6 +3681,7 @@ static int
> > > > > mxf_read_header(AVFormatContext
> > > > > *s)
> > > > >  KLVPacket klv;
> > > > >  int64_t essence_offset = 0;
> > > > >  int ret;
> > > > > +    int64_t run_in;
> > > > >  
> > > > >  mxf->last_forward_tell = INT64_MAX;
> > > > >  
> > > > > @@ -3690,7 +3691,10 @@ static int
> > > > > mxf_read_header(AVFormatContext
> > > > > *s)
> > > > >  }
> > > > >  avio_seek(s->pb, -14, SEEK_CUR);
> > > > >  mxf->fc = s;
> > > > > -    mxf->run_in = avio_tell(s->pb);
> > > > > +    run_in = avio_tell(s->pb);
> > > > > +    if (run_in < 0 || run_in != (int)run_in)
> > > > 
> > > > run_in > INT_MAX is more clear
> > > > 
> > > > It strikes me that run_in is also used in lots of places in the
> > > > demuxer
> > > > without checking for overflow
> > > 
> > > I went and checked S377m and the run-in sequence "shall be less
> > > than
> > > 65536 bytes long". Both the 2004 and 2009 version of the spec agree
> > > on
> > > this. So we should reject run_in >= 65536, and mxf_probe() should
> > > be
> > > similarly adjusted.
> > 
> > ok, will do
> > 
> > thx for checking
> > 
> > i will change the patch by:
> > @@ -3717,7 +3717,7 @@ static int mxf_read_header(AVFormatContext *s)
> >  avio_seek(s->pb, -14, SEEK_CUR);
> 
> Oh and also the call to mxf_read_sync() could be supplied with a
> maximum number of bytes to read, allowing the code to bail out faster

I agree, but that should be seperate from the initial bugfix

thx

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

If a bugfix only changes things apparently unrelated to the bug with no
further explanation, that is a good sign that the bugfix is wrong.


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/4] avcodec/snow: Move ff_snow_inner_add_yblock() to snow_dwt.c

2022-09-21 Thread Michael Niedermayer
On Wed, Sep 21, 2022 at 01:00:07PM +0200, Andreas Rheinhardt wrote:
> Michael Niedermayer:
> > On Mon, Sep 19, 2022 at 11:27:49PM +0200, Andreas Rheinhardt wrote:
> >> Only used there and by x86 snow asm code as fallback.
> >>
> >> Signed-off-by: Andreas Rheinhardt 
> >> ---
> >>  libavcodec/snow.c | 33 -
> >>  libavcodec/snow.h |  3 ---
> >>  libavcodec/snow_dwt.c | 32 
> >>  libavcodec/snow_dwt.h |  3 +++
> >>  4 files changed, 35 insertions(+), 36 deletions(-)
> >>
> >> diff --git a/libavcodec/snow.c b/libavcodec/snow.c
> >> index aa15fccc42..85ad6d10a1 100644
> >> --- a/libavcodec/snow.c
> >> +++ b/libavcodec/snow.c
> >> @@ -29,39 +29,6 @@
> >>  #include "snowdata.h"
> >>  
> >>  
> >> -void ff_snow_inner_add_yblock(const uint8_t *obmc, const int obmc_stride, 
> >> uint8_t * * block, int b_w, int b_h,
> >> -  int src_x, int src_y, int src_stride, 
> >> slice_buffer * sb, int add, uint8_t * dst8){
> >> -int y, x;
> >> -IDWTELEM * dst;
> >> -for(y=0; y >> -//FIXME ugly misuse of obmc_stride
> >> -const uint8_t *obmc1= obmc + y*obmc_stride;
> >> -const uint8_t *obmc2= obmc1+ (obmc_stride>>1);
> >> -const uint8_t *obmc3= obmc1+ obmc_stride*(obmc_stride>>1);
> >> -const uint8_t *obmc4= obmc3+ (obmc_stride>>1);
> >> -dst = slice_buffer_get_line(sb, src_y + y);
> >> -for(x=0; x >> -int v=   obmc1[x] * block[3][x + y*src_stride]
> >> -+obmc2[x] * block[2][x + y*src_stride]
> >> -+obmc3[x] * block[1][x + y*src_stride]
> >> -+obmc4[x] * block[0][x + y*src_stride];
> >> -
> >> -v <<= 8 - LOG2_OBMC_MAX;
> >> -if(FRAC_BITS != 8){
> >> -v >>= 8 - FRAC_BITS;
> >> -}
> >> -if(add){
> >> -v += dst[x + src_x];
> >> -v = (v + (1<<(FRAC_BITS-1))) >> FRAC_BITS;
> >> -if(v&(~255)) v= ~(v>>31);
> >> -dst8[x + y*src_stride] = v;
> >> -}else{
> >> -dst[x + src_x] -= v;
> >> -}
> >> -}
> >> -}
> >> -}
> >> -
> >>  int ff_snow_get_buffer(SnowContext *s, AVFrame *frame)
> >>  {
> >>  int ret, i;
> >> diff --git a/libavcodec/snow.h b/libavcodec/snow.h
> >> index ed0f9abb42..1c976b9ba7 100644
> >> --- a/libavcodec/snow.h
> >> +++ b/libavcodec/snow.h
> >> @@ -45,11 +45,8 @@
> >>  #define QSHIFT 5
> >>  #define QROOT (1< >>  #define LOSSLESS_QLOG -128
> >> -#define FRAC_BITS 4
> >>  #define MAX_REF_FRAMES 8
> >>  
> >> -#define LOG2_OBMC_MAX 8
> >> -#define OBMC_MAX (1<<(LOG2_OBMC_MAX))
> >>  typedef struct BlockNode{
> >>  int16_t mx; ///< Motion vector component X, see 
> >> mv_scale
> >>  int16_t my; ///< Motion vector component Y, see 
> >> mv_scale
> >> diff --git a/libavcodec/snow_dwt.c b/libavcodec/snow_dwt.c
> >> index 18b315ef66..9401d119d0 100644
> >> --- a/libavcodec/snow_dwt.c
> >> +++ b/libavcodec/snow_dwt.c
> >> @@ -25,6 +25,38 @@
> >>  #include "me_cmp.h"
> >>  #include "snow_dwt.h"
> >>  
> >> +void ff_snow_inner_add_yblock(const uint8_t *obmc, const int obmc_stride,
> >> +  uint8_t **block, int b_w, int b_h,
> >> +  int src_x, int src_y, int src_stride,
> >> +  slice_buffer * sb, int add, uint8_t * dst8)
> >> +{
> >> +for (int y = 0; y < b_h; y++) {
> >> +//FIXME ugly misuse of obmc_stride
> >> +const uint8_t *obmc1 = obmc  + y * obmc_stride;
> >> +const uint8_t *obmc2 = obmc1 + (obmc_stride >> 1);
> >> +const uint8_t *obmc3 = obmc1 + obmc_stride * (obmc_stride >> 1);
> >> +const uint8_t *obmc4 = obmc3 + (obmc_stride >> 1);
> >> +IDWTELEM *dst = slice_buffer_get_line(sb, src_y + y);
> >> +for (int x = 0; x < b_w; x++) {
> >> +int v = obmc1[x] * block[3][x + y*src_stride]
> >> +  + obmc2[x] * block[2][x + y*src_stride]
> >> +  + obmc3[x] * block[1][x + y*src_stride]
> >> +  + obmc4[x] * block[0][x + y*src_stride];
> >> +
> >> +v <<= 8 - LOG2_OBMC_MAX;
> >> +if (FRAC_BITS != 8)
> >> +v >>= 8 - FRAC_BITS;
> >> +if (add) {
> >> +v += dst[x + src_x];
> >> +v = (v + (1 << (FRAC_BITS - 1))) >> FRAC_BITS;
> >> +if (v & (~255)) v= ~(v>>31);
> >> +dst8[x + y*src_stride] = v;
> >> +} else
> >> +dst[x + src_x] -= v;
> >> +}
> >> +}
> >> +}
> >> +
> > 
> > putting this in snow_dwt may be convenient but it is not part of the dwt so
> > this feels semantically wrong
> > 
> 
> If it is not part of the dwt, then why does SnowDWTContext have an
> inner_add_yblock function pointer whose C version is
> ff_snow_inner_add_yblock?

Re: [FFmpeg-devel] [PATCH 2/7] sws: add jobs option, distinct from threads

2022-09-21 Thread James Almer

On 9/20/2022 2:50 PM, rcombs wrote:

This allows for more efficient use of asymmetric-multiprocessing systems.
---
  libswscale/options.c  | 2 ++
  libswscale/swscale_internal.h | 1 +
  libswscale/utils.c| 9 ++---
  libswscale/version.h  | 2 +-
  4 files changed, 10 insertions(+), 4 deletions(-)

diff --git a/libswscale/options.c b/libswscale/options.c
index 4d41b835b1..5765daa100 100644
--- a/libswscale/options.c
+++ b/libswscale/options.c
@@ -81,6 +81,8 @@ static const AVOption swscale_options[] = {
  
  { "threads", "number of threads", OFFSET(nb_threads),   AV_OPT_TYPE_INT, {.i64 = 1 }, 0, INT_MAX, VE, "threads" },

  { "auto",NULL,0,  
AV_OPT_TYPE_CONST, {.i64 = 0 },.flags = VE, "threads" },
+{ "jobs","number of jobs",OFFSET(nb_jobs),  
AV_OPT_TYPE_INT, {.i64 = 0 }, 0, INT_MAX, VE, "jobs" },


Default should probably be 1.


+{ "auto",NULL,0,  
AV_OPT_TYPE_CONST, {.i64 = 0 },.flags = VE, "jobs" },
  
  { NULL }

  };
diff --git a/libswscale/swscale_internal.h b/libswscale/swscale_internal.h
index abeebbb002..602082e12c 100644
--- a/libswscale/swscale_internal.h
+++ b/libswscale/swscale_internal.h
@@ -339,6 +339,7 @@ typedef struct SwsContext {
  int vChrDrop; ///< Binary logarithm of extra vertical 
subsampling factor in source image chroma planes specified by user.
  int sliceDir; ///< Direction that slices are fed to the 
scaler (1 = top-to-bottom, -1 = bottom-to-top).
  int nb_threads;   ///< Number of threads used for scaling
+int nb_jobs;  ///< Number of slice jobs used for scaling
  double param[2];  ///< Input parameters for scaling 
algorithms that need them.
  
  AVFrame *frame_src;

diff --git a/libswscale/utils.c b/libswscale/utils.c
index 45baa22b23..c9ff9db957 100644
--- a/libswscale/utils.c
+++ b/libswscale/utils.c
@@ -1277,18 +1277,21 @@ static int context_init_threaded(SwsContext *c,
  ff_sws_slice_worker, NULL, c->nb_threads);
  if (ret == AVERROR(ENOSYS)) {
  c->nb_threads = 1;
+c->nb_jobs = 1;
  return 0;
  } else if (ret < 0)
  return ret;
  
  c->nb_threads = ret;

+if (c->nb_jobs < 1)


Can c->nb_jobs even be -1? The AVOption range above is 0..INT_MAX


+c->nb_jobs = av_cpu_job_count();
  
-c->slice_ctx = av_calloc(c->nb_threads, sizeof(*c->slice_ctx));

-c->slice_err = av_calloc(c->nb_threads, sizeof(*c->slice_err));
+c->slice_ctx = av_calloc(c->nb_jobs, sizeof(*c->slice_ctx));
+c->slice_err = av_calloc(c->nb_jobs, sizeof(*c->slice_err));
  if (!c->slice_ctx || !c->slice_err)
  return AVERROR(ENOMEM);
  
-for (int i = 0; i < c->nb_threads; i++) {

+for (int i = 0; i < c->nb_jobs; i++) {
  c->slice_ctx[i] = sws_alloc_context();
  if (!c->slice_ctx[i])
  return AVERROR(ENOMEM);
diff --git a/libswscale/version.h b/libswscale/version.h
index 9bb3b171a7..4529a2d7d4 100644
--- a/libswscale/version.h
+++ b/libswscale/version.h
@@ -29,7 +29,7 @@
  #include "version_major.h"
  
  #define LIBSWSCALE_VERSION_MINOR   8

-#define LIBSWSCALE_VERSION_MICRO 112
+#define LIBSWSCALE_VERSION_MICRO 113
  
  #define LIBSWSCALE_VERSION_INT  AV_VERSION_INT(LIBSWSCALE_VERSION_MAJOR, \

 LIBSWSCALE_VERSION_MINOR, \

___
ffmpeg-devel mailing list
ffmpeg-devel@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 02/13] avformat/mxfdec: Check run_in to fit in int and be valid

2022-09-21 Thread Marton Balint



On Wed, 21 Sep 2022, Tomas Härdin wrote:


ons 2022-09-21 klockan 11:35 +0200 skrev Michael Niedermayer:

On Tue, Sep 20, 2022 at 01:20:00PM +0200, Tomas Härdin wrote:
> tis 2022-09-20 klockan 13:07 +0200 skrev Tomas Härdin:
> > sön 2022-09-18 klockan 19:13 +0200 skrev Michael Niedermayer:
> > > Fixes: signed integer overflow: 9223372036854775807 - -
> > > 2146905566
> > > cannot be represented in type 'long'
> > > Fixes: 50993/clusterfuzz-testcase-minimized-
> > > ffmpeg_dem_MXF_fuzzer-
> > > 6570996594769920
> > > 
> > > Found-by: continuous fuzzing process 
> > > https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg

> > > Signed-off-by: Michael Niedermayer 
> > > ---
> > >  libavformat/mxfdec.c | 6 +-
> > >  1 file changed, 5 insertions(+), 1 deletion(-)
> > > 
> > > diff --git a/libavformat/mxfdec.c b/libavformat/mxfdec.c

> > > index e63e803aa56..da81fea3bc1 100644
> > > --- a/libavformat/mxfdec.c
> > > +++ b/libavformat/mxfdec.c
> > > @@ -3681,6 +3681,7 @@ static int
> > > mxf_read_header(AVFormatContext
> > > *s)
> > >  KLVPacket klv;
> > >  int64_t essence_offset = 0;
> > >  int ret;
> > > +    int64_t run_in;
> > >  
> > >  mxf->last_forward_tell = INT64_MAX;
> > >  
> > > @@ -3690,7 +3691,10 @@ static int
> > > mxf_read_header(AVFormatContext
> > > *s)
> > >  }
> > >  avio_seek(s->pb, -14, SEEK_CUR);
> > >  mxf->fc = s;
> > > -    mxf->run_in = avio_tell(s->pb);
> > > +    run_in = avio_tell(s->pb);
> > > +    if (run_in < 0 || run_in != (int)run_in)
> > 
> > run_in > INT_MAX is more clear
> > 
> > It strikes me that run_in is also used in lots of places in the

> > demuxer
> > without checking for overflow
> 
> I went and checked S377m and the run-in sequence "shall be less

> than
> 65536 bytes long". Both the 2004 and 2009 version of the spec agree
> on
> this. So we should reject run_in >= 65536, and mxf_probe() should
> be
> similarly adjusted.

ok, will do

thx for checking

i will change the patch by:
@@ -3717,7 +3717,7 @@ static int mxf_read_header(AVFormatContext *s)
 avio_seek(s->pb, -14, SEEK_CUR);


Oh and also the call to mxf_read_sync() could be supplied with a
maximum number of bytes to read, allowing the code to bail out faster


Yeah, I wanted to suggest this as well. And please allow 65536-byte 
run-in, even if that is not strictly allowed by the current standard, 
because the MXF book has no problem with that:


(run-in is) "...a sequence of up to 65536 bytes at the front of the file 
that precedes the first partition pack..."


Thanks,
Marton
___
ffmpeg-devel mailing list
ffmpeg-devel@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/movenc: Write auxi box for animated AVIF with alpha

2022-09-21 Thread James Zern
On Tue, Sep 20, 2022 at 2:17 PM Vignesh Venkatasubramanian
 wrote:
>
> According to the HEIF specification (ISO/IEC 23008-12) Section
> 7.5.3.1, tracks with handler_type 'auxv' must contain a 'auxi' box
> in its SampleEntry to notify the nature of the auxiliary track to the
> decoder.
>
> The content is the same as the 'auxC' box. So parameterize and re-use
> the existing function.
>
> Signed-off-by: Vignesh Venkatasubramanian 
> ---
>  libavformat/movenc.c | 27 +++
>  1 file changed, 15 insertions(+), 12 deletions(-)
>

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

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


[FFmpeg-devel] [PATCH] lavc: export flag for MPEG audio dual channel

2022-09-21 Thread Scott Theisen
From: ulmus-scott 

The flag identifies two independant mono channels recorded as stereo.

This change has been kicking around in the MythTV modifications since 2006.
See 
https://github.com/MythTV/mythtv/commit/435540c9e8ac245ceca968791c67431f37c8d617
I have changed the names and comment.  For the current MythTV modification see
https://github.com/ulmus-scott/FFmpeg/commit/645fa6f9a61d23bac0665851d211bbeb3686deb0
---
 libavcodec/audiotoolboxdec.c|  2 +-
 libavcodec/avcodec.h| 11 +++
 libavcodec/mpegaudio_parser.c   |  2 +-
 libavcodec/mpegaudiodecheader.c |  4 +++-
 libavcodec/mpegaudiodecheader.h |  2 +-
 5 files changed, 17 insertions(+), 4 deletions(-)

diff --git a/libavcodec/audiotoolboxdec.c b/libavcodec/audiotoolboxdec.c
index 82babe3d31..9d11844142 100644
--- a/libavcodec/audiotoolboxdec.c
+++ b/libavcodec/audiotoolboxdec.c
@@ -346,7 +346,7 @@ static av_cold int ffat_create_decoder(AVCodecContext 
*avctx,
 int bit_rate;
 if (ff_mpa_decode_header(AV_RB32(pkt->data), &avctx->sample_rate,
  &in_format.mChannelsPerFrame, 
&avctx->frame_size,
- &bit_rate, &codec_id) < 0)
+ &bit_rate, &codec_id, 
&avctx->mpeg_audio_mode_dual_channel) < 0)
 return AVERROR_INVALIDDATA;
 avctx->bit_rate = bit_rate;
 in_format.mSampleRate = avctx->sample_rate;
diff --git a/libavcodec/avcodec.h b/libavcodec/avcodec.h
index 7db5d1b1c5..bcf3a845a8 100644
--- a/libavcodec/avcodec.h
+++ b/libavcodec/avcodec.h
@@ -2076,6 +2076,17 @@ typedef struct AVCodecContext {
  * The decoder can then override during decoding as needed.
  */
 AVChannelLayout ch_layout;
+
+/**
+ * Audio only.  This flag is set when MPEG audio mode dual channel has 
been detected.
+ * This signals that the audio is two independent mono channels.
+ *
+ * 0 normally, 1 if dual channel flag is set.
+ *
+ * - encoding: currently unused (functionally equivalent to stereo, patch 
welcome)
+ * - decoding: set by lavc
+ */
+int mpeg_audio_mode_dual_channel;
 } AVCodecContext;
 
 /**
diff --git a/libavcodec/mpegaudio_parser.c b/libavcodec/mpegaudio_parser.c
index d54366f10a..d957cf467f 100644
--- a/libavcodec/mpegaudio_parser.c
+++ b/libavcodec/mpegaudio_parser.c
@@ -70,7 +70,7 @@ static int mpegaudio_parse(AVCodecParserContext *s1,
 
 state= (state<<8) + buf[i++];
 
-ret = ff_mpa_decode_header(state, &sr, &channels, &frame_size, 
&bit_rate, &codec_id);
+ret = ff_mpa_decode_header(state, &sr, &channels, &frame_size, 
&bit_rate, &codec_id, &avctx->mpeg_audio_mode_dual_channel);
 if (ret < 4) {
 if (i > 4)
 s->header_count = -2;
diff --git a/libavcodec/mpegaudiodecheader.c b/libavcodec/mpegaudiodecheader.c
index ef63befbf4..6c9a641906 100644
--- a/libavcodec/mpegaudiodecheader.c
+++ b/libavcodec/mpegaudiodecheader.c
@@ -117,7 +117,7 @@ int avpriv_mpegaudio_decode_header(MPADecodeHeader *s, 
uint32_t header)
 return 0;
 }
 
-int ff_mpa_decode_header(uint32_t head, int *sample_rate, int *channels, int 
*frame_size, int *bit_rate, enum AVCodecID *codec_id)
+int ff_mpa_decode_header(uint32_t head, int *sample_rate, int *channels, int 
*frame_size, int *bit_rate, enum AVCodecID *codec_id, int *dual_mono)
 {
 MPADecodeHeader s1, *s = &s1;
 
@@ -148,5 +148,7 @@ int ff_mpa_decode_header(uint32_t head, int *sample_rate, 
int *channels, int *fr
 *sample_rate = s->sample_rate;
 *channels = s->nb_channels;
 *bit_rate = s->bit_rate;
+*dual_mono = (s->mode == MPA_DUAL) ? 1 : 0;
+
 return s->frame_size;
 }
diff --git a/libavcodec/mpegaudiodecheader.h b/libavcodec/mpegaudiodecheader.h
index ed5d1f3b33..e599d287f7 100644
--- a/libavcodec/mpegaudiodecheader.h
+++ b/libavcodec/mpegaudiodecheader.h
@@ -56,7 +56,7 @@ int avpriv_mpegaudio_decode_header(MPADecodeHeader *s, 
uint32_t header);
 /* useful helper to get MPEG audio stream info. Return -1 if error in
header, otherwise the coded frame size in bytes */
 int ff_mpa_decode_header(uint32_t head, int *sample_rate,
- int *channels, int *frame_size, int *bitrate, enum 
AVCodecID *codec_id);
+ int *channels, int *frame_size, int *bitrate, enum 
AVCodecID *codec_id, int *dual_mono);
 
 /* fast header check for resync */
 static inline int ff_mpa_check_header(uint32_t header){
-- 
2.34.1

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

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


Re: [FFmpeg-devel] [PATCH] lavc: export flag for MPEG audio dual channel

2022-09-21 Thread Rémi Denis-Courmont
Le keskiviikkona 21. syyskuuta 2022, 22.26.11 EEST Scott Theisen a écrit :
> diff --git a/libavcodec/avcodec.h b/libavcodec/avcodec.h
> index 7db5d1b1c5..bcf3a845a8 100644
> --- a/libavcodec/avcodec.h
> +++ b/libavcodec/avcodec.h
> @@ -2076,6 +2076,17 @@ typedef struct AVCodecContext {
>   * The decoder can then override during decoding as needed.
> */
>  AVChannelLayout ch_layout;
> +
> +/**
> + * Audio only.  This flag is set when MPEG audio mode dual channel has
> been detected. + * This signals that the audio is two independent mono
> channels. + *
> + * 0 normally, 1 if dual channel flag is set.
> + *
> + * - encoding: currently unused (functionally equivalent to stereo,
> patch welcome) + * - decoding: set by lavc
> + */
> +int mpeg_audio_mode_dual_channel;
>  } AVCodecContext;

I agree that the dual mono flag should be exposed to the application somehow, 
but isn't this a slient ABI break?

-- 
Rémi Denis-Courmont
http://www.remlab.net/



___
ffmpeg-devel mailing list
ffmpeg-devel@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: export flag for MPEG audio dual channel

2022-09-21 Thread James Almer

On 9/21/2022 4:44 PM, Rémi Denis-Courmont wrote:

Le keskiviikkona 21. syyskuuta 2022, 22.26.11 EEST Scott Theisen a écrit :

diff --git a/libavcodec/avcodec.h b/libavcodec/avcodec.h
index 7db5d1b1c5..bcf3a845a8 100644
--- a/libavcodec/avcodec.h
+++ b/libavcodec/avcodec.h
@@ -2076,6 +2076,17 @@ typedef struct AVCodecContext {
   * The decoder can then override during decoding as needed.
*/
  AVChannelLayout ch_layout;
+
+/**
+ * Audio only.  This flag is set when MPEG audio mode dual channel has
been detected. + * This signals that the audio is two independent mono
channels. + *
+ * 0 normally, 1 if dual channel flag is set.
+ *
+ * - encoding: currently unused (functionally equivalent to stereo,
patch welcome) + * - decoding: set by lavc
+ */
+int mpeg_audio_mode_dual_channel;
  } AVCodecContext;


I agree that the dual mono flag should be exposed to the application somehow,
but isn't this a slient ABI break?


It's not a break, but it's overkill for what's essentially a flag.

The proper way to do this would be to signal such a layout as an actual 
channel layout, using a custom order one where both channels are set as 
Front Center. But i don't know if until the old channel layout API 
fields are gone we should have decoders setting something only new API 
users will understand. Old API field users would look at channels and 
see a 2, and channel_layout and see it's empty, but then old and new API 
values would technically conflict, so I'd like to hear some opinions.


An alternative could be signaling this using an AVFormatContext.metadata 
entry called "dualmono", and ensuring the channel layout is 2 channels 
of UNSPEC order.

___
ffmpeg-devel mailing list
ffmpeg-devel@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: export flag for MPEG audio dual channel

2022-09-21 Thread Andreas Rheinhardt
Rémi Denis-Courmont:
> Le keskiviikkona 21. syyskuuta 2022, 22.26.11 EEST Scott Theisen a écrit :
>> diff --git a/libavcodec/avcodec.h b/libavcodec/avcodec.h
>> index 7db5d1b1c5..bcf3a845a8 100644
>> --- a/libavcodec/avcodec.h
>> +++ b/libavcodec/avcodec.h
>> @@ -2076,6 +2076,17 @@ typedef struct AVCodecContext {
>>   * The decoder can then override during decoding as needed.
>> */
>>  AVChannelLayout ch_layout;
>> +
>> +/**
>> + * Audio only.  This flag is set when MPEG audio mode dual channel has
>> been detected. + * This signals that the audio is two independent mono
>> channels. + *
>> + * 0 normally, 1 if dual channel flag is set.
>> + *
>> + * - encoding: currently unused (functionally equivalent to stereo,
>> patch welcome) + * - decoding: set by lavc
>> + */
>> +int mpeg_audio_mode_dual_channel;
>>  } AVCodecContext;
> 
> I agree that the dual mono flag should be exposed to the application somehow, 
> but isn't this a slient ABI break?
> 

Now. sizeof(AVCodecContext) is not part of the public ABI (we have a
custom allocator for it: avcodec_alloc_context3()).

- 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] avutil/channel_layout: mention how the API user should treat channel orders it does not understand

2022-09-21 Thread James Almer
In case new orders are added in the future, existing library users can still
use the layout simply by ignoring everything but the channel count in it, so
make this explicit.

Signed-off-by: James Almer 
---
 libavutil/channel_layout.h | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/libavutil/channel_layout.h b/libavutil/channel_layout.h
index 4dd6614de9..9e685fab72 100644
--- a/libavutil/channel_layout.h
+++ b/libavutil/channel_layout.h
@@ -290,6 +290,9 @@ typedef struct AVChannelCustom {
 typedef struct AVChannelLayout {
 /**
  * Channel order used in this layout.
+ * Any value not defined in the AVChannelOrder enum in a layout that
+ * av_channel_layout_check() doesn't reject must be treated as if it was
+ * AV_CHANNEL_ORDER_UNSPEC.
  * This is a mandatory field.
  */
 enum AVChannelOrder order;
-- 
2.37.3

___
ffmpeg-devel mailing list
ffmpeg-devel@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] Media 100i decoder

2022-09-21 Thread Paul B Mahol
Patch attached.
From 05c426fe110d788830ab322433ed12319a921b05 Mon Sep 17 00:00:00 2001
From: Paul B Mahol 
Date: Wed, 21 Sep 2022 18:22:33 +0200
Subject: [PATCH] avcodec: add Media 100i decoder

Signed-off-by: Paul B Mahol 
---
 libavcodec/Makefile |   1 +
 libavcodec/allcodecs.c  |   1 +
 libavcodec/codec_desc.c |   7 ++
 libavcodec/codec_id.h   |   1 +
 libavcodec/media100.c   | 216 
 libavformat/isom_tags.c |   4 +
 6 files changed, 230 insertions(+)
 create mode 100644 libavcodec/media100.c

diff --git a/libavcodec/Makefile b/libavcodec/Makefile
index b9aa6efaac..45702551b3 100644
--- a/libavcodec/Makefile
+++ b/libavcodec/Makefile
@@ -468,6 +468,7 @@ OBJS-$(CONFIG_MACE6_DECODER)   += mace.o
 OBJS-$(CONFIG_MAGICYUV_DECODER)+= magicyuv.o
 OBJS-$(CONFIG_MAGICYUV_ENCODER)+= magicyuvenc.o
 OBJS-$(CONFIG_MDEC_DECODER)+= mdec.o mpeg12.o mpeg12data.o
+OBJS-$(CONFIG_MEDIA100_DECODER)+= media100.o
 OBJS-$(CONFIG_METASOUND_DECODER)   += metasound.o metasound_data.o \
   twinvq.o
 OBJS-$(CONFIG_MICRODVD_DECODER)+= microdvddec.o ass.o
diff --git a/libavcodec/allcodecs.c b/libavcodec/allcodecs.c
index fc88e25fda..1966f61770 100644
--- a/libavcodec/allcodecs.c
+++ b/libavcodec/allcodecs.c
@@ -194,6 +194,7 @@ extern const FFCodec ff_m101_decoder;
 extern const FFCodec ff_magicyuv_encoder;
 extern const FFCodec ff_magicyuv_decoder;
 extern const FFCodec ff_mdec_decoder;
+extern const FFCodec ff_media100_decoder;
 extern const FFCodec ff_mimic_decoder;
 extern const FFCodec ff_mjpeg_encoder;
 extern const FFCodec ff_mjpeg_decoder;
diff --git a/libavcodec/codec_desc.c b/libavcodec/codec_desc.c
index e8e1529401..a58b3f9780 100644
--- a/libavcodec/codec_desc.c
+++ b/libavcodec/codec_desc.c
@@ -1909,6 +1909,13 @@ static const AVCodecDescriptor codec_descriptors[] = {
 .long_name = NULL_IF_CONFIG_SMALL("WBMP (Wireless Application Protocol Bitmap) image"),
 .props = AV_CODEC_PROP_INTRA_ONLY | AV_CODEC_PROP_LOSSLESS,
 },
+{
+.id= AV_CODEC_ID_MEDIA100,
+.type  = AVMEDIA_TYPE_VIDEO,
+.name  = "media100",
+.long_name = NULL_IF_CONFIG_SMALL("Media 100i"),
+.props = AV_CODEC_PROP_INTRA_ONLY | AV_CODEC_PROP_LOSSY,
+},
 
 /* various PCM "codecs" */
 {
diff --git a/libavcodec/codec_id.h b/libavcodec/codec_id.h
index 9c01ea9750..dc79c95b46 100644
--- a/libavcodec/codec_id.h
+++ b/libavcodec/codec_id.h
@@ -318,6 +318,7 @@ enum AVCodecID {
 AV_CODEC_ID_PHM,
 AV_CODEC_ID_RADIANCE_HDR,
 AV_CODEC_ID_WBMP,
+AV_CODEC_ID_MEDIA100,
 
 /* various PCM "codecs" */
 AV_CODEC_ID_FIRST_AUDIO = 0x1, ///< A dummy id pointing at the start of audio codecs
diff --git a/libavcodec/media100.c b/libavcodec/media100.c
new file mode 100644
index 00..2c7bb3cf93
--- /dev/null
+++ b/libavcodec/media100.c
@@ -0,0 +1,216 @@
+/*
+ * Media 100 decoder
+ * Copyright (c) 2022 Paul B Mahol
+ *
+ * This file is part of FFmpeg.
+ *
+ * FFmpeg is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public
+ * License as published by the Free Software Foundation; either
+ * version 2.1 of the License, or (at your option) any later version.
+ *
+ * FFmpeg is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+ * Lesser General Public License for more details.
+ *
+ * You should have received a copy of the GNU Lesser General Public
+ * License along with FFmpeg; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA
+ */
+
+/**
+ * @file
+ * Media 100 decoder.
+ */
+
+#include 
+
+#include "libavutil/intreadwrite.h"
+#include "avcodec.h"
+#include "bytestream.h"
+#include "codec_internal.h"
+
+typedef struct Media100Context {
+AVCodecContext *avctx;   // wrapper context for mjpegb
+} Media100Context;
+
+static av_cold int media100_decode_init(AVCodecContext *avctx)
+{
+Media100Context *ctx = avctx->priv_data;
+const AVCodec *codec;
+int ret;
+
+codec = avcodec_find_decoder(AV_CODEC_ID_MJPEGB);
+if (!codec)
+return AVERROR_BUG;
+ctx->avctx = avcodec_alloc_context3(codec);
+if (!ctx->avctx)
+return AVERROR(ENOMEM);
+ctx->avctx->thread_count = 1;
+ctx->avctx->flags  = avctx->flags;
+ctx->avctx->flags2 = avctx->flags2;
+ctx->avctx->width  = ctx->avctx->coded_width  = avctx->width;
+ctx->avctx->height = ctx->avctx->coded_height = avctx->height;
+
+ret = avcodec_open2(ctx->avctx, codec, NULL);
+if (ret < 0)
+return ret;
+
+return 0;
+}
+
+static int media100_decode_frame(AVCodecContext *avctx,
+ AVFrame *frame, int *got_frame,
+ 

Re: [FFmpeg-devel] [PATCH] Media 100i decoder

2022-09-21 Thread Andreas Rheinhardt
Paul B Mahol:
> Subject: [PATCH] avcodec: add Media 100i decoder
> 
> Signed-off-by: Paul B Mahol 
> ---
>  libavcodec/Makefile |   1 +
>  libavcodec/allcodecs.c  |   1 +
>  libavcodec/codec_desc.c |   7 ++
>  libavcodec/codec_id.h   |   1 +
>  libavcodec/media100.c   | 216 
>  libavformat/isom_tags.c |   4 +
>  6 files changed, 230 insertions(+)
>  create mode 100644 libavcodec/media100.c
> 
> diff --git a/libavcodec/Makefile b/libavcodec/Makefile
> index b9aa6efaac..45702551b3 100644
> --- a/libavcodec/Makefile
> +++ b/libavcodec/Makefile
> @@ -468,6 +468,7 @@ OBJS-$(CONFIG_MACE6_DECODER)   += mace.o
>  OBJS-$(CONFIG_MAGICYUV_DECODER)+= magicyuv.o
>  OBJS-$(CONFIG_MAGICYUV_ENCODER)+= magicyuvenc.o
>  OBJS-$(CONFIG_MDEC_DECODER)+= mdec.o mpeg12.o mpeg12data.o
> +OBJS-$(CONFIG_MEDIA100_DECODER)+= media100.o
>  OBJS-$(CONFIG_METASOUND_DECODER)   += metasound.o metasound_data.o \
>twinvq.o
>  OBJS-$(CONFIG_MICRODVD_DECODER)+= microdvddec.o ass.o
> diff --git a/libavcodec/allcodecs.c b/libavcodec/allcodecs.c
> index fc88e25fda..1966f61770 100644
> --- a/libavcodec/allcodecs.c
> +++ b/libavcodec/allcodecs.c
> @@ -194,6 +194,7 @@ extern const FFCodec ff_m101_decoder;
>  extern const FFCodec ff_magicyuv_encoder;
>  extern const FFCodec ff_magicyuv_decoder;
>  extern const FFCodec ff_mdec_decoder;
> +extern const FFCodec ff_media100_decoder;
>  extern const FFCodec ff_mimic_decoder;
>  extern const FFCodec ff_mjpeg_encoder;
>  extern const FFCodec ff_mjpeg_decoder;
> diff --git a/libavcodec/codec_desc.c b/libavcodec/codec_desc.c
> index e8e1529401..a58b3f9780 100644
> --- a/libavcodec/codec_desc.c
> +++ b/libavcodec/codec_desc.c
> @@ -1909,6 +1909,13 @@ static const AVCodecDescriptor codec_descriptors[] = {
>  .long_name = NULL_IF_CONFIG_SMALL("WBMP (Wireless Application 
> Protocol Bitmap) image"),
>  .props = AV_CODEC_PROP_INTRA_ONLY | AV_CODEC_PROP_LOSSLESS,
>  },
> +{
> +.id= AV_CODEC_ID_MEDIA100,
> +.type  = AVMEDIA_TYPE_VIDEO,
> +.name  = "media100",
> +.long_name = NULL_IF_CONFIG_SMALL("Media 100i"),
> +.props = AV_CODEC_PROP_INTRA_ONLY | AV_CODEC_PROP_LOSSY,
> +},
>  
>  /* various PCM "codecs" */
>  {
> diff --git a/libavcodec/codec_id.h b/libavcodec/codec_id.h
> index 9c01ea9750..dc79c95b46 100644
> --- a/libavcodec/codec_id.h
> +++ b/libavcodec/codec_id.h
> @@ -318,6 +318,7 @@ enum AVCodecID {
>  AV_CODEC_ID_PHM,
>  AV_CODEC_ID_RADIANCE_HDR,
>  AV_CODEC_ID_WBMP,
> +AV_CODEC_ID_MEDIA100,
>  
>  /* various PCM "codecs" */
>  AV_CODEC_ID_FIRST_AUDIO = 0x1, ///< A dummy id pointing at the 
> start of audio codecs
> diff --git a/libavcodec/media100.c b/libavcodec/media100.c
> new file mode 100644
> index 00..2c7bb3cf93
> --- /dev/null
> +++ b/libavcodec/media100.c
> @@ -0,0 +1,216 @@
> +/*
> + * Media 100 decoder
> + * Copyright (c) 2022 Paul B Mahol
> + *
> + * This file is part of FFmpeg.
> + *
> + * FFmpeg is free software; you can redistribute it and/or
> + * modify it under the terms of the GNU Lesser General Public
> + * License as published by the Free Software Foundation; either
> + * version 2.1 of the License, or (at your option) any later version.
> + *
> + * FFmpeg is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
> + * Lesser General Public License for more details.
> + *
> + * You should have received a copy of the GNU Lesser General Public
> + * License along with FFmpeg; if not, write to the Free Software
> + * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 
> USA
> + */
> +
> +/**
> + * @file
> + * Media 100 decoder.
> + */
> +
> +#include 

I think you don't even need stdint.h, let alone inttypes.h.

> +
> +#include "libavutil/intreadwrite.h"
> +#include "avcodec.h"
> +#include "bytestream.h"
> +#include "codec_internal.h"
> +
> +typedef struct Media100Context {
> +AVCodecContext *avctx;   // wrapper context for mjpegb
> +} Media100Context;
> +
> +static av_cold int media100_decode_init(AVCodecContext *avctx)
> +{
> +Media100Context *ctx = avctx->priv_data;
> +const AVCodec *codec;
> +int ret;
> +
> +codec = avcodec_find_decoder(AV_CODEC_ID_MJPEGB);
> +if (!codec)
> +return AVERROR_BUG;

This bug can be triggered, because you did not add a configure
dependency on the mjpegb decoder.
Btw: If you used ff_mjpegb_decoder directly, the linker would now about
this dependency and so this decoder could be fuzzed. (Right now we
magically add these dependencies for the fuzzer; see lines 188-191 in
target_dec_fuzzer.c.)

> +ctx->avctx = avcodec_alloc_context3(codec);
> +if (!ctx->avctx)
> +return AVERROR(ENOME

Re: [FFmpeg-devel] [PATCH] lavc: export flag for MPEG audio dual channel

2022-09-21 Thread Scott Theisen

On 9/21/22 15:51, James Almer wrote:

On 9/21/2022 4:44 PM, Rémi Denis-Courmont wrote:
Le keskiviikkona 21. syyskuuta 2022, 22.26.11 EEST Scott Theisen a 
écrit :

diff --git a/libavcodec/avcodec.h b/libavcodec/avcodec.h
index 7db5d1b1c5..bcf3a845a8 100644
--- a/libavcodec/avcodec.h
+++ b/libavcodec/avcodec.h
@@ -2076,6 +2076,17 @@ typedef struct AVCodecContext {
   * The decoder can then override during decoding 
as needed.

*/
  AVChannelLayout ch_layout;
+
+    /**
+ * Audio only.  This flag is set when MPEG audio mode dual 
channel has
been detected. + * This signals that the audio is two 
independent mono

channels. + *
+ * 0 normally, 1 if dual channel flag is set.
+ *
+ * - encoding: currently unused (functionally equivalent to 
stereo,

patch welcome) + * - decoding: set by lavc
+ */
+    int mpeg_audio_mode_dual_channel;
  } AVCodecContext;


I agree that the dual mono flag should be exposed to the application 
somehow,

but isn't this a slient ABI break?


It's not a break, but it's overkill for what's essentially a flag.


This is how MythTV customized FFmpeg (in 2006) for this and this way was 
probably the easiest.  It /is/ a flag, so maybe adding an int as a 
bitset instead of as a bool so other flags could be added if necessary?




The proper way to do this would be to signal such a layout as an 
actual channel layout, using a custom order one where both channels 
are set as Front Center. But i don't know if until the old channel 
layout API fields are gone we should have decoders setting something 
only new API users will understand. Old API field users would look at 
channels and see a 2, and channel_layout and see it's empty, but then 
old and new API values would technically conflict, so I'd like to hear 
some opinions.


I'm not very familiar with either channel layout API, but the audio is 
encoded identically to stereo other than the flag, so could we add 
another entry, e.g. AV_CHANNEL_ORDER_MONO, to the `enum AVChannelOrder` 
to signify that each channel is independent, but is otherwise identical 
to AV_CHANNEL_ORDER_NATIVE?




An alternative could be signaling this using an 
AVFormatContext.metadata entry called "dualmono", and ensuring the 
channel layout is 2 channels of UNSPEC order.




AVFormatContext sounds like the wrong place, since there could, in 
theory, be multiple audio streams utilizing or not dual mono audio, 
which could also be switching back and forth between using dual mono and 
not.


Regards,

Scott
___
ffmpeg-devel mailing list
ffmpeg-devel@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] avutil/dict: Add av_dict_iterate

2022-09-21 Thread Marvin Scholz
This is a more explicit iteration API rather than using the "magic"
av_dict_get(d, "", t, AV_DICT_IGNORE_SUFFIX) which is not really
trivial to grasp what it does when casually reading through code.
---
 libavutil/dict.c| 19 +++
 libavutil/dict.h| 27 +++
 libavutil/version.h |  2 +-
 3 files changed, 47 insertions(+), 1 deletion(-)

diff --git a/libavutil/dict.c b/libavutil/dict.c
index 14ad780a79..2f690a5b8e 100644
--- a/libavutil/dict.c
+++ b/libavutil/dict.c
@@ -20,6 +20,7 @@
 
 #include 
 
+#include "avassert.h"
 #include "avstring.h"
 #include "dict.h"
 #include "dict_internal.h"
@@ -38,6 +39,24 @@ int av_dict_count(const AVDictionary *m)
 return m ? m->count : 0;
 }
 
+AVDictionaryEntry *av_dict_iterate(const AVDictionary *m,
+   const AVDictionaryEntry *prev)
+{
+int i = 0;
+
+if (!m)
+return NULL;
+
+if (prev)
+i = prev - m->elems + 1;
+
+av_assert2(i >= 0);
+if (i >= m->count)
+return NULL;
+
+return &m->elems[i];
+}
+
 AVDictionaryEntry *av_dict_get(const AVDictionary *m, const char *key,
const AVDictionaryEntry *prev, int flags)
 {
diff --git a/libavutil/dict.h b/libavutil/dict.h
index 0d1afc6c64..b42b3f07fd 100644
--- a/libavutil/dict.h
+++ b/libavutil/dict.h
@@ -32,6 +32,8 @@
 
 #include 
 
+#include "attributes.h"
+
 /**
  * @addtogroup lavu_dict AVDictionary
  * @ingroup lavu_data
@@ -101,6 +103,31 @@ typedef struct AVDictionary AVDictionary;
 AVDictionaryEntry *av_dict_get(const AVDictionary *m, const char *key,
const AVDictionaryEntry *prev, int flags);
 
+/**
+ * Iterate over a dictionary
+ *
+ * Iterates through all entries in the dictionary.
+ * 
+ * @warning The returned AVDictionaryEntry key/value must not be changed.
+ *
+ * @param m The dictionary to iterate over
+ * @param prev  Pointer to the previous AVDictionaryEntry, NULL initially
+ * 
+ * @retval AVDictionaryEntry* The next element in the dictionary
+ * @retval NULL   No more elements in the dictionary
+ *
+ * Typical usage:
+ * @code
+ * AVDictionaryEntry *e = NULL;
+ * while (e = av_dict_iterate(m, e)) {
+ * // ...
+ * }
+ * @endcode
+ */
+av_warn_unused_result
+AVDictionaryEntry *av_dict_iterate(const AVDictionary *m,
+   const AVDictionaryEntry *prev);
+
 /**
  * Get number of entries in dictionary.
  *
diff --git a/libavutil/version.h b/libavutil/version.h
index 0585fa7b80..6fd07ed2a4 100644
--- a/libavutil/version.h
+++ b/libavutil/version.h
@@ -80,7 +80,7 @@
 
 #define LIBAVUTIL_VERSION_MAJOR  57
 #define LIBAVUTIL_VERSION_MINOR  36
-#define LIBAVUTIL_VERSION_MICRO 102
+#define LIBAVUTIL_VERSION_MICRO 103
 
 #define LIBAVUTIL_VERSION_INT   AV_VERSION_INT(LIBAVUTIL_VERSION_MAJOR, \
LIBAVUTIL_VERSION_MINOR, \
-- 
2.37.0 (Apple Git-136)

___
ffmpeg-devel mailing list
ffmpeg-devel@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] avutil/dict: Use av_dict_iterate in av_dict_get

2022-09-21 Thread Marvin Scholz
---
 libavutil/dict.c | 16 ++--
 1 file changed, 6 insertions(+), 10 deletions(-)

diff --git a/libavutil/dict.c b/libavutil/dict.c
index 2f690a5b8e..1a348d6710 100644
--- a/libavutil/dict.c
+++ b/libavutil/dict.c
@@ -60,18 +60,14 @@ AVDictionaryEntry *av_dict_iterate(const AVDictionary *m,
 AVDictionaryEntry *av_dict_get(const AVDictionary *m, const char *key,
const AVDictionaryEntry *prev, int flags)
 {
-unsigned int i, j;
+AVDictionaryEntry *entry = (AVDictionaryEntry *)prev;
+unsigned int j;
 
-if (!m || !key)
+if (!key)
 return NULL;
 
-if (prev)
-i = prev - m->elems + 1;
-else
-i = 0;
-
-for (; i < m->count; i++) {
-const char *s = m->elems[i].key;
+while (entry = av_dict_iterate(m, entry)) {
+const char *s = entry->key;
 if (flags & AV_DICT_MATCH_CASE)
 for (j = 0; s[j] == key[j] && key[j]; j++)
 ;
@@ -82,7 +78,7 @@ AVDictionaryEntry *av_dict_get(const AVDictionary *m, const 
char *key,
 continue;
 if (s[j] && !(flags & AV_DICT_IGNORE_SUFFIX))
 continue;
-return &m->elems[i];
+return entry;
 }
 return NULL;
 }
-- 
2.37.0 (Apple Git-136)

___
ffmpeg-devel mailing list
ffmpeg-devel@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/7] avcodec: Fix Doxygen trailing brief comments

2022-09-21 Thread Marvin Scholz
The //< comment is not any magic comment supported by Doxygen,
instead use //!< to mark them as brief doc for the members.
---
 libavcodec/avcodec.h   | 8 
 libavcodec/codec_par.h | 8 
 2 files changed, 8 insertions(+), 8 deletions(-)

diff --git a/libavcodec/avcodec.h b/libavcodec/avcodec.h
index 7db5d1b1c5..665a5eadaf 100644
--- a/libavcodec/avcodec.h
+++ b/libavcodec/avcodec.h
@@ -2804,10 +2804,10 @@ int avcodec_get_hw_frames_parameters(AVCodecContext 
*avctx,
  */
 
 enum AVPictureStructure {
-AV_PICTURE_STRUCTURE_UNKNOWN,  //< unknown
-AV_PICTURE_STRUCTURE_TOP_FIELD,//< coded as top field
-AV_PICTURE_STRUCTURE_BOTTOM_FIELD, //< coded as bottom field
-AV_PICTURE_STRUCTURE_FRAME,//< coded as frame
+AV_PICTURE_STRUCTURE_UNKNOWN,  //!< unknown
+AV_PICTURE_STRUCTURE_TOP_FIELD,//!< coded as top field
+AV_PICTURE_STRUCTURE_BOTTOM_FIELD, //!< coded as bottom field
+AV_PICTURE_STRUCTURE_FRAME,//!< coded as frame
 };
 
 typedef struct AVCodecParserContext {
diff --git a/libavcodec/codec_par.h b/libavcodec/codec_par.h
index 7660791a12..8caad71b5e 100644
--- a/libavcodec/codec_par.h
+++ b/libavcodec/codec_par.h
@@ -37,10 +37,10 @@
 enum AVFieldOrder {
 AV_FIELD_UNKNOWN,
 AV_FIELD_PROGRESSIVE,
-AV_FIELD_TT,  //< Top coded_first, top displayed first
-AV_FIELD_BB,  //< Bottom coded first, bottom displayed first
-AV_FIELD_TB,  //< Top coded first, bottom displayed first
-AV_FIELD_BT,  //< Bottom coded first, top displayed first
+AV_FIELD_TT,  //!< Top coded_first, top displayed first
+AV_FIELD_BB,  //!< Bottom coded first, bottom displayed first
+AV_FIELD_TB,  //!< Top coded first, bottom displayed first
+AV_FIELD_BT,  //!< Bottom coded first, top displayed first
 };
 
 /**
-- 
2.37.0 (Apple Git-136)

___
ffmpeg-devel mailing list
ffmpeg-devel@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 2/7] avdevice/avdevice: Fix mismatching argument name

2022-09-21 Thread Marvin Scholz
---
 libavdevice/avdevice.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/libavdevice/avdevice.h b/libavdevice/avdevice.h
index 0b32e59fed..185593053f 100644
--- a/libavdevice/avdevice.h
+++ b/libavdevice/avdevice.h
@@ -494,7 +494,7 @@ int avdevice_list_devices(struct AVFormatContext *s, 
AVDeviceInfoList **device_l
 /**
  * Convenient function to free result of avdevice_list_devices().
  *
- * @param devices device list to be freed.
+ * @param device_list device list to be freed.
  */
 void avdevice_free_list_devices(AVDeviceInfoList **device_list);
 
-- 
2.37.0 (Apple Git-136)

___
ffmpeg-devel mailing list
ffmpeg-devel@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 3/7] avformat/avformat: Fix mismatching argument names

2022-09-21 Thread Marvin Scholz
---
 libavformat/avformat.h | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/libavformat/avformat.h b/libavformat/avformat.h
index 9d46875cce..c695cfc6de 100644
--- a/libavformat/avformat.h
+++ b/libavformat/avformat.h
@@ -2003,7 +2003,7 @@ AVProgram *av_new_program(AVFormatContext *s, int id);
  * avformat_free_context() can be used to free the context and
  * everything allocated by the framework within it.
  *
- * @param *ctx is set to the created format context, or to NULL in
+ * @param ctx pointee is set to the created format context, or to NULL in
  * case of failure
  * @param oformat format to use for allocating the context, if NULL
  * format_name and filename are used instead
@@ -2656,7 +2656,7 @@ const AVIndexEntry *avformat_index_get_entry(AVStream 
*st, int idx);
  * Get the AVIndexEntry corresponding to the given timestamp.
  *
  * @param st  Stream containing the requested AVIndexEntry.
- * @param timestamp   Timestamp to retrieve the index entry for.
+ * @param wanted_timestamp   Timestamp to retrieve the index entry for.
  * @param flags   If AVSEEK_FLAG_BACKWARD then the returned entry will 
correspond
  *to the timestamp which is <= the requested one, if 
backward
  *is 0, then it will be >=
-- 
2.37.0 (Apple Git-136)

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

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


[FFmpeg-devel] [PATCH v2 4/7] avutil: Fix mismatching argument names

2022-09-21 Thread Marvin Scholz
---
 libavutil/hwcontext.h   | 2 +-
 libavutil/mathematics.h | 6 --
 libavutil/mem.h | 3 ++-
 libavutil/rational.h| 3 ++-
 4 files changed, 9 insertions(+), 5 deletions(-)

diff --git a/libavutil/hwcontext.h b/libavutil/hwcontext.h
index c18b7e1e8b..efca17585e 100644
--- a/libavutil/hwcontext.h
+++ b/libavutil/hwcontext.h
@@ -249,7 +249,7 @@ const char *av_hwdevice_get_type_name(enum AVHWDeviceType 
type);
 /**
  * Iterate over supported device types.
  *
- * @param type AV_HWDEVICE_TYPE_NONE initially, then the previous type
+ * @param prev AV_HWDEVICE_TYPE_NONE initially, then the previous type
  * returned by this function in subsequent iterations.
  * @return The next usable device type from enum AVHWDeviceType, or
  * AV_HWDEVICE_TYPE_NONE if there are no more.
diff --git a/libavutil/mathematics.h b/libavutil/mathematics.h
index 64d4137a60..e4aff1e973 100644
--- a/libavutil/mathematics.h
+++ b/libavutil/mathematics.h
@@ -111,7 +111,8 @@ enum AVRounding {
 /**
  * Compute the greatest common divisor of two integer operands.
  *
- * @param a,b Operands
+ * @param a Operand
+ * @param b Operand
  * @return GCD of a and b up to sign; if a >= 0 and b >= 0, return value is >= 
0;
  * if a == 0 and b == 0, returns 0.
  */
@@ -186,7 +187,8 @@ int av_compare_ts(int64_t ts_a, AVRational tb_a, int64_t 
ts_b, AVRational tb_b);
  * av_compare_mod(0x11, 0x02, 0x20) > 0 // since 0x11 % 0x20 (0x11) > 0x02 % 
0x20 (0x02)
  * @endcode
  *
- * @param a,b Operands
+ * @param a Operand
+ * @param b Operand
  * @param mod Divisor; must be a power of 2
  * @return
  * - a negative value if `a % mod < b % mod`
diff --git a/libavutil/mem.h b/libavutil/mem.h
index d91174196c..c9c4fcf1ff 100644
--- a/libavutil/mem.h
+++ b/libavutil/mem.h
@@ -667,7 +667,8 @@ void *av_dynarray2_add(void **tab_ptr, int *nb_ptr, size_t 
elem_size,
 /**
  * Multiply two `size_t` values checking for overflow.
  *
- * @param[in]  a,b Operands of multiplication
+ * @param[in]  a   Operand of multiplication
+ * @param[in]  b   Operand of multiplication
  * @param[out] r   Pointer to the result of the operation
  * @return 0 on success, AVERROR(EINVAL) on overflow
  */
diff --git a/libavutil/rational.h b/libavutil/rational.h
index cbb08a0baf..8cbfc8e066 100644
--- a/libavutil/rational.h
+++ b/libavutil/rational.h
@@ -179,7 +179,8 @@ AVRational av_d2q(double d, int max) av_const;
  * Find which of the two rationals is closer to another rational.
  *
  * @param q Rational to be compared against
- * @param q1,q2 Rationals to be tested
+ * @param q1Rational to be tested
+ * @param q2Rational to be tested
  * @return One of the following values:
  * - 1 if `q1` is nearer to `q` than `q2`
  * - -1 if `q2` is nearer to `q` than `q1`
-- 
2.37.0 (Apple Git-136)

___
ffmpeg-devel mailing list
ffmpeg-devel@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 5/7] swresample/swresample: Fix mismatching argument names

2022-09-21 Thread Marvin Scholz
---
 libswresample/swresample.h | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/libswresample/swresample.h b/libswresample/swresample.h
index 980be65783..4c26468c63 100644
--- a/libswresample/swresample.h
+++ b/libswresample/swresample.h
@@ -354,8 +354,8 @@ int swr_convert(struct SwrContext *s, uint8_t **out, int 
out_count,
  *  in this case the output timestamps will match output sample 
numbers.
  *  See ffmpeg-resampler(1) for the two modes of compensation.
  *
- * @param s[in] initialized Swr context
- * @param pts[in]   timestamp for the next input sample, INT64_MIN if unknown
+ * @param[in] s initialized Swr context
+ * @param[in] pts   timestamp for the next input sample, INT64_MIN if unknown
  * @see swr_set_compensation(), swr_drop_output(), and swr_inject_silence() are
  *  function used internally for timestamp compensation.
  * @return the output timestamp for the next output sample
@@ -636,8 +636,8 @@ int swr_convert_frame(SwrContext *swr,
  * @see swr_close();
  *
  * @param swr audio resample context
- * @param output  output AVFrame
- * @param input   input AVFrame
+ * @param out output AVFrame
+ * @param in  input AVFrame
  * @return0 on success, AVERROR on failure.
  */
 int swr_config_frame(SwrContext *swr, const AVFrame *out, const AVFrame *in);
-- 
2.37.0 (Apple Git-136)

___
ffmpeg-devel mailing list
ffmpeg-devel@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 6/7] avformat/avformat: Improve doxy style

2022-09-21 Thread Marvin Scholz
Mostly re-indenting and adding some missing references.
---
 libavformat/avformat.h | 180 +++--
 1 file changed, 103 insertions(+), 77 deletions(-)

diff --git a/libavformat/avformat.h b/libavformat/avformat.h
index c695cfc6de..1d97d56ac5 100644
--- a/libavformat/avformat.h
+++ b/libavformat/avformat.h
@@ -1898,8 +1898,8 @@ const AVOutputFormat *av_muxer_iterate(void **opaque);
 /**
  * Iterate over all registered demuxers.
  *
- * @param opaque a pointer where libavformat will store the iteration state. 
Must
- *   point to NULL to start the iteration.
+ * @param opaque a pointer where libavformat will store the iteration state.
+ *   Must point to NULL to start the iteration.
  *
  * @return the next registered demuxer or NULL when the iteration is
  * finished
@@ -1957,12 +1957,13 @@ AVStream *avformat_new_stream(AVFormatContext *s, const 
AVCodec *c);
 /**
  * Wrap an existing array as stream side data.
  *
- * @param st stream
+ * @param st   stream
  * @param type side information type
  * @param data the side data array. It must be allocated with the av_malloc()
  * family of functions. The ownership of the data is transferred to
  * st.
  * @param size side information size
+ *
  * @return zero on success, a negative AVERROR code on failure. On failure,
  * the stream is unchanged and the data remains owned by the caller.
  */
@@ -1973,8 +1974,9 @@ int av_stream_add_side_data(AVStream *st, enum 
AVPacketSideDataType type,
  * Allocate new information from stream.
  *
  * @param stream stream
- * @param type desired side information type
- * @param size side information size
+ * @param type   desired side information type
+ * @param size   side information size
+ *
  * @return pointer to fresh allocated data or NULL otherwise
  */
 uint8_t *av_stream_new_side_data(AVStream *stream,
@@ -1983,9 +1985,10 @@ uint8_t *av_stream_new_side_data(AVStream *stream,
  * Get side information from stream.
  *
  * @param stream stream
- * @param type desired side information type
- * @param size If supplied, *size will be set to the size of the side data
- * or to zero if the desired side data is not present.
+ * @param type   desired side information type
+ * @param size   If supplied, *size will be set to the size of the side data
+ *   or to zero if the desired side data is not present.
+ *
  * @return pointer to data if present or NULL otherwise
  */
 uint8_t *av_stream_get_side_data(const AVStream *stream,
@@ -2003,16 +2006,17 @@ AVProgram *av_new_program(AVFormatContext *s, int id);
  * avformat_free_context() can be used to free the context and
  * everything allocated by the framework within it.
  *
- * @param ctx pointee is set to the created format context, or to NULL in
- * case of failure
- * @param oformat format to use for allocating the context, if NULL
- * format_name and filename are used instead
- * @param format_name the name of output format to use for allocating the
- * context, if NULL filename is used instead
- * @param filename the name of the filename to use for allocating the
- * context, may be NULL
- * @return >= 0 in case of success, a negative AVERROR code in case of
- * failure
+ * @param ctx   pointee is set to the created format context,
+ *  or to NULL in case of failure
+ * @param oformat   format to use for allocating the context, if NULL
+ *  format_name and filename are used instead
+ * @param format_name   the name of output format to use for allocating the
+ *  context, if NULL filename is used instead
+ * @param filename  the name of the filename to use for allocating the
+ *  context, may be NULL
+ *
+ * @return  >= 0 in case of success, a negative AVERROR code in case of
+ *  failure
  */
 int avformat_alloc_output_context2(AVFormatContext **ctx, const AVOutputFormat 
*oformat,
const char *format_name, const char 
*filename);
@@ -2067,15 +2071,16 @@ const AVInputFormat *av_probe_input_format3(const 
AVProbeData *pd,
  * attempt is made. When the maximum probe size is reached, the input format
  * with the highest score is returned.
  *
- * @param pb the bytestream to probe
- * @param fmt the input format is put here
- * @param url the url of the stream
- * @param logctx the log context
- * @param offset the offset within the bytestream to probe from
+ * @param pb the bytestream to probe
+ * @param fmtthe input format is put here
+ * @param urlthe url of the stream
+ * @param logctx the log context
+ * @param offset the offset within the bytestream to probe from
  * @param max_probe_size the maximum probe buffer size (zero for default)
+ *
  * @return the score in case of success, a negative value corresponding to an
  * the maximal score is AVPROBE_SCORE

[FFmpeg-devel] [PATCH v2 7/7] avcodec/avcodec: Escape Doxygen reference

2022-09-21 Thread Marvin Scholz
The # is interpreted as explicit reference request by Doxygen
which is not desired here.

Additionally use a typewriter font to make the inline code
easier to distinguish.
---
 libavcodec/avcodec.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/libavcodec/avcodec.h b/libavcodec/avcodec.h
index 665a5eadaf..f0904520b1 100644
--- a/libavcodec/avcodec.h
+++ b/libavcodec/avcodec.h
@@ -1518,7 +1518,7 @@ typedef struct AVCodecContext {
  *   libavcodec will behave as if this field was always set to 1.
  *   Callers that want to be forward compatible with future libavcodec
  *   versions should wrap access to this field in
- * #if LIBAVCODEC_VERSION_MAJOR < 60
+ * \#if LIBAVCODEC_VERSION_MAJOR < 60
  */
 attribute_deprecated
 int thread_safe_callbacks;
-- 
2.37.0 (Apple Git-136)

___
ffmpeg-devel mailing list
ffmpeg-devel@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] avcodec/jpeg2000: Add support for High-Throughput JPEG 2000 (HTJ2K) decoding.

2022-09-21 Thread Caleb Etemesi
There is one with way better performance on its way, especially with images
with magnitude refinement passes.

here @https://github.com/etemesi254/FFmpeg/tree/my-profile

And the associated runtime profile from running

`perf record -g -F 999 ./ffmpeg_g  -i ~/jpeg2000/meridian.ht.j2c  -v 32
 -bench
mark -f null  -`

Online version  - https://share.firefox.dev/3C0rI9e

Image - https://etemesi254.github.io/assets/imgs/gsoc/meridian.ht.j2c [ 4K
image]

Ffmpeg results from the benchmark

`
bench: utime=0.371s stime=0.036s rtime=0.408s
bench: maxrss=165900kB
`
The machine is an AMD Ryzen 6000U with 6 cores 128kb L1.

Perf reports it takes 826 ms,  because the decoder does two decodes per
image,(I think one for the demuxer then the decoder, probably a bug).
anf most of the time is spent on idwt

OpenJPH decodes the same image in ~90ms.

So I do think there is room for improvement.

On Wed, 21 Sept 2022, 17:08 Tomas Härdin,  wrote:

> ons 2022-09-21 klockan 12:30 +0200 skrev Tomas Härdin:
> > Tested this locally on some 4k sample files and it achieved 19 fps
> > with
> > -lowres 2 on an Intel(R) Core(TM) i5-3317U CPU @ 1.70GHz (4 cores).
> > I'm
> > getting access to a better machine to test this on as well.
>
> Ran some tests on a c5n.4xlarge instance, Intel(R) Xeon(R) Platinum
> 8124M CPU @ 3.00GHz, 16 vCPUs. Test sequence is 273 4k htj2k frames
> from Disney encoded with OpenJPH version 0.7.3, 20-21 megs each. Tested
> like so:
>
> ./ffmpeg -i ~/samples/htj2k-unwrapped/00%03d.j2c -f null -
>
> Achieved fps with a filled disk cache:
> -lowres  this patch  libopenjpegdec
> 09.1 7.0
> 140  27
> 2105 92
> 3128 157
> 4129 164
>
> This is with the default frame-based threading. Not too bad. I suspect
> the slower performance compared to opj with -lowres >= 3 is due to the
> way parsing works. This is what's holding up my codeblock-threading
> patchset's performance as well.
>
> I have in mind to compare this with a regular j2k sample on the same
> machine, but it's taking its sweet time transferring..
>
> /Tomas
>
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
> To unsubscribe, visit link above, or email
> ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
>
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

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