date:20220314

Re: [FFmpeg-devel] [PATCH v7 2/3] libavformat: Add DFPWM raw format

2022-03-14 Thread Tomas Härdin

+static const AVOption dfpwm_options[] = {
+{ "sample_rate", "", offsetof(DFPWMAudioDemuxerContext,
sample_rate), AV_OPT_TYPE_INT, {.i64 = 48000}, 0, INT_MAX,
AV_OPT_FLAG_DECODING_PARAM },
+{ "channels","", offsetof(DFPWMAudioDemuxerContext, channels),
AV_OPT_TYPE_INT, {.i64 = 1}, 0, INT_MAX, AV_OPT_FLAG_DECODING_PARAM },
+{ NULL },
+};

I think you can set the input sample rate and channel count via the
FFmpeg CLI's -ar and -ac options and have them be carried in and out of
here

/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 v7 2/3] libavformat: Add DFPWM raw format

2022-03-14 Thread Paul B Mahol

On Mon, Mar 14, 2022 at 10:47 AM Tomas Härdin  wrote:

> +static const AVOption dfpwm_options[] = {
> +{ "sample_rate", "", offsetof(DFPWMAudioDemuxerContext,
> sample_rate), AV_OPT_TYPE_INT, {.i64 = 48000}, 0, INT_MAX,
> AV_OPT_FLAG_DECODING_PARAM },
> +{ "channels","", offsetof(DFPWMAudioDemuxerContext, channels),
> AV_OPT_TYPE_INT, {.i64 = 1}, 0, INT_MAX, AV_OPT_FLAG_DECODING_PARAM },
> +{ NULL },
> +};
>
> I think you can set the input sample rate and channel count via the
> FFmpeg CLI's -ar and -ac options and have them be carried in and out of
> here
>

I highly doubt that.


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

Re: [FFmpeg-devel] [PATCH v6 1/2] libavcodec: Added DFPWM1a codec

2022-03-14 Thread Tomas Härdin

mån 2022-03-07 klockan 22:04 -0500 skrev Jack Bruienne:
> On 3/7/22 06:03, Tomas Härdin wrote:
> 
> > tor 2022-03-03 klockan 10:44 -0500 skrev Jack Bruienne:
> > >   From the wiki page (https://wiki.vexatos.com/dfpwm):
> > > > DFPWM (Dynamic Filter Pulse Width Modulation) is an audio codec
> > > > created by Ben “GreaseMonkey” Russell in 2012, originally to be
> > > > used
> > > > as a voice codec for asiekierka's pixmess, a C remake of
> > > > 64pixels.
> > > > It is a 1-bit-per-sample codec which uses a dynamic-strength
> > > > one-
> > > > pole
> > > > low-pass filter as a predictor. Due to the fact that a raw
> > > > DPFWM
> > > > decoding
> > > > creates a high-pitched whine, it is often followed by some
> > > > post-
> > > > processing
> > > > filters to make the stream more listenable.
> > This sounds similar to something I wrote for the Atari 2600 a
> > number of
> > years ago (https://www.pouet.net/prod.php?which=59283  )
> > 
> > I found an encoder online for DFPWM, and it seems to suffer from
> > the
> > same "beeping" that my debeeping hack fixes (suppressing 0xAA and
> > 0x55
> > bytes). Perhaps a similar hack could be useful in dfpwmenc.c
> 
> I'm curious how this works. Do you just cut out those bytes from the
> encoder output, or is it modified in some way? Wouldn't removing the
> data entirely eventually cause much of the audio to be lost?

The source code is included in the release. Look at audioquant.cpp.
I've attached it for convenience. The codec is based on a state machine
where each state is a 5-bit PCM value that can go to either of two
states, also 5-bit PCM values. Hence 1 bit per sample. I also have a
low-pass filter in the decoder.

I penalize state machines which result in 0x55 and 0xAA being overly
represented. This is done via computing a histogram of the output bytes
and scaling the RMS error according to how many of those bytes are in
the (tentative) output.

Another approach could be to detect and blank excessive runs of 0x55
and 0xAA bytes.


> >  From experience it's usually better to be strict when it comes to
> > stuff
> > like this. The ComputerCraft people should work out a standard for
> > this, preferably a container. We've had a similar problem in FreeDV
> > where which codec was being used was implicit most of the time,
> > which
> > has been resolved with the .c2 format.
> 
> I think the best standardized container for DFPWM will be WAV.

I agree, and I see this was already pushed.

/Tomas
#define _CRT_SECURE_NO_WARNINGS
#include 
#include 
#include 
#include 
#include 
#include 

using namespace std;

typedef short sample_t;
typedef int64_t err_t;

static vector samples;
static int rate;

#define DESIRED_RMS2//can be tweaked slightly for better utilization of dynamic range depending on material
#define BPS1
#define DELTA 10//try table values +- this every pass
//higher values = more exhaustive search
#define PRESHAPE
//#define POSTSHAPE
//#define VERBOSE

static void normalize(sample_t *data, int n) {
float rms = 0;
int x;

for (x = 0; x < n; x++)
rms += data[x]*data[x];

rms = sqrtf(rms / n);
fprintf(stderr, "RMS amplitude prior to normalization: %f\n", rms);

for (x = 0; x < n; x++) {
int value = data[x] * DESIRED_RMS / rms;
if (value < -32768) value = -32768;
if (value > 32767)  value = 32767;
data[x] = value;
}
}

static void quantize(const sample_t *input, sample_t *output, int n) {
int x, y, last_error = 0;
int counts[31][31];
memset(counts, 0, sizeof(counts));

for (x = 0; x < n; x++) {
#ifdef PRESHAPE
//shape using feedback. not sure how correct this is,
//but quiet parts appear to receive less noise
output[x] = ((input[x] + 3 * last_error / 4) / 2048) + 15;
#else
output[x] = (input[x] / 2048) + 15;
#endif

if (output[x] < 0)
output[x] = 0;
if (output[x] >= 31)
output[x] = 30;

last_error = (output[x] - 15) * 2048 - input[x];

if (x > 0)
counts[output[x-1]][output[x]]++;
}

for (y = 0; y < 31; y++) {
for (x = 0; x < 31; x++)
fprintf(stderr, "%3i ", counts[y][x]);
fprintf(stderr, "\n");
}
}

//table is k*31 entries, where k=2^N
static err_t table_adpcm_work(sample_t *data, int n, int *table, int k, int do_output, unsigned char *bits) {
int x, last = 15, last_error = 0;
err_t ret = 0;
int hist[256] = {0};
float factor;
int byte = 0;

for (x = 0; x < n; x++) {
int y;
int best, best_error, best_value;

for (y = 0; y < k; y++) {
int value = table[y + last*k];
int error;

#ifdef POSTSHAPE
//again, may not be entirely correct,
//but the output sounds roughly right
error = value - data[x] - last_error / 2;
#else
error = value - data[x];
#endif
error *= erro

Re: [FFmpeg-devel] [PATCH v7 2/3] libavformat: Add DFPWM raw format

2022-03-14 Thread Tomas Härdin

mån 2022-03-14 klockan 10:56 +0100 skrev Paul B Mahol:
> On Mon, Mar 14, 2022 at 10:47 AM Tomas Härdin 
> wrote:
> 
> > +static const AVOption dfpwm_options[] = {
> > +    { "sample_rate", "", offsetof(DFPWMAudioDemuxerContext,
> > sample_rate), AV_OPT_TYPE_INT, {.i64 = 48000}, 0, INT_MAX,
> > AV_OPT_FLAG_DECODING_PARAM },
> > +    { "channels",    "", offsetof(DFPWMAudioDemuxerContext,
> > channels),
> > AV_OPT_TYPE_INT, {.i64 = 1}, 0, INT_MAX, AV_OPT_FLAG_DECODING_PARAM
> > },
> > +    { NULL },
> > +};
> > 
> > I think you can set the input sample rate and channel count via the
> > FFmpeg CLI's -ar and -ac options and have them be carried in and
> > out of
> > here
> > 
> 
> I highly doubt that.

You can for other raw formats:

  ffplay -f s16le -ar 8k -ac 1 /dev/urandom

/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 v4 1/4] lavc/vaapi_encode_h265: Add GPB frame support for hevc_vaapi

2022-03-14 Thread Wang, Fei W




> -Original Message-
> From: ffmpeg-devel  On Behalf Of Xiang,
> Haihao
> Sent: Monday, March 14, 2022 10:15 AM
> To: ffmpeg-devel@ffmpeg.org
> Subject: Re: [FFmpeg-devel] [PATCH v4 1/4] lavc/vaapi_encode_h265: Add GPB
> frame support for hevc_vaapi
> 
> On Sun, 2022-03-13 at 20:45 +, Mark Thompson wrote:
> > On 11/03/2022 09:00, Fei Wang wrote:
> > > From: Linjie Fu 
> > >
> > > Use GPB frames to replace regular P/B frames if backend driver does
> > > not support it.
> > >
> > > - GPB:
> > >  Generalized P and B picture. Regular P/B frames replaced by B
> > >  frames with previous-predict only, L0 == L1. Normal B frames
> > >  still have 2 different ref_lists and allow bi-prediction
> > >
> > > Signed-off-by: Linjie Fu 
> > > Signed-off-by: Fei Wang 
> > > ---
> > > update:
> > > 1. Add b to gpb.
> > > 2. Optimise debug message.
> > >
> > >   libavcodec/vaapi_encode.c  | 74 +++--
> -
> > >   libavcodec/vaapi_encode.h  |  2 +
> > >   libavcodec/vaapi_encode_h265.c | 24 ++-
> > >   3 files changed, 93 insertions(+), 7 deletions(-)
> > >
> > > diff --git a/libavcodec/vaapi_encode.c b/libavcodec/vaapi_encode.c
> > > index 3bf379b1a0..bdba9726b2 100644
> > > --- a/libavcodec/vaapi_encode.c
> > > +++ b/libavcodec/vaapi_encode.c
> > > @@ -848,9 +848,13 @@ static void
> > > vaapi_encode_set_b_pictures(AVCodecContext
> > > *avctx,
> > >   pic->b_depth = current_depth;
> > >
> > >   vaapi_encode_add_ref(avctx, pic, start, 1, 1, 0);
> > > -vaapi_encode_add_ref(avctx, pic, end,   1, 1, 0);
> > >   vaapi_encode_add_ref(avctx, pic, prev,  0, 0, 1);
> > >
> > > +if (!ctx->b_to_gpb)
> > > +vaapi_encode_add_ref(avctx, pic, end, 1, 1, 0);
> > > +else
> > > +vaapi_encode_add_ref(avctx, pic, end, 0, 1, 0);
> >
> > This is doing something extremely dubious.  If b-to-gpb is set, then
> > don't use the future reference?
> 
> According to
> https://github.com/intel/media-
> driver/blob/master/media_driver/agnostic/common/codec/hal/codechal_vdenc
> _hevc.cpp#L3072-L3087
> , L0 and L1 should be the same for vdenc hevc on some platforms, so user can't
> use past and future reference together, which is why you experienced the 
> failure
> after applying version 2
> 
> Thanks
> Haihao
> 
> 
> > That means these pictures will only have the past reference, and the
> > coding efficiency will often be much worse.
> >
> > E.g. if you have the default structure (max_b_frames = 2, max_b_depth
> > = 1) then in a sequence of four pictures you get:
> >
> > 1 referring to something previous
> > 4 referring to 1
> > 2 referring to 1 and 4
> > 3 referring to 1 and 4
> >
> > and this change means you lose the 2 -> 4 and 3 -> 4 references.
> > Therefore, a change in the picture between 1 and 2 will end up coded
> > three times in 2, 3 and 4 rather than just being coded in 4 and then 
> > referred to
> by the others.

If driver doesn't support B frames with two different reference lists, use gpb 
instead
of regular B is a best way. In V3, I turned B frames to P, but this will break 
gop structure.
If user set I/P/B frames, while the output only contains I/P frames will be 
much confuse.

> >
> > > +
> > >   for (ref = end->refs[1]; ref; ref = ref->refs[1])
> > >   vaapi_encode_add_ref(avctx, pic, ref, 0, 1, 0);
> > >   }
> > > @@ -871,8 +875,11 @@ static void
> > > vaapi_encode_set_b_pictures(AVCodecContext
> > > *avctx,
> > >
> > >   vaapi_encode_add_ref(avctx, pic, pic,   0, 1, 0);
> > >   vaapi_encode_add_ref(avctx, pic, start, 1, 1, 0);
> > > -vaapi_encode_add_ref(avctx, pic, end,   1, 1, 0);
> > >   vaapi_encode_add_ref(avctx, pic, prev,  0, 0, 1);
> > > +if (!ctx->b_to_gpb)
> > > +vaapi_encode_add_ref(avctx, pic, end, 1, 1, 0);
> > > +else
> > > +vaapi_encode_add_ref(avctx, pic, end, 0, 1, 0);
> > >
> > >   for (ref = end->refs[1]; ref; ref = ref->refs[1])
> > >   vaapi_encode_add_ref(avctx, pic, ref, 0, 1, 0); @@
> > > -1845,6 +1852,51 @@ static av_cold int
> > > vaapi_encode_init_gop_structure(AVCodecContext *avctx)
> > >   ref_l1 = attr.value >> 16 & 0x;
> > >   }
> > >
> > > +ctx->p_to_gpb = 0;
> > > +ctx->b_to_gpb = 0;
> > > +
> > > +#if VA_CHECK_VERSION(1, 9, 0)
> > > +if (!(ctx->codec->flags & FLAG_INTRA_ONLY ||
> > > +avctx->gop_size <= 1)) {
> > > +attr = (VAConfigAttrib) { VAConfigAttribPredictionDirection };
> > > +vas = vaGetConfigAttributes(ctx->hwctx->display,
> > > +ctx->va_profile,
> > > +ctx->va_entrypoint,
> > > +&attr, 1);
> > > +if (vas != VA_STATUS_SUCCESS) {
> > > +av_log(avctx, AV_LOG_WARNING, "Failed to query
> > > +prediction
> > > direction "
>

[FFmpeg-devel] [PATCH 1/2] avcodec: add null encoders

2022-03-14 Thread Paul B Mahol

Signed-off-by: Paul B Mahol 
---
 libavcodec/Makefile |  2 ++
 libavcodec/allcodecs.c  |  2 ++
 libavcodec/codec_desc.c | 14 ++
 libavcodec/codec_id.h   |  2 ++
 libavcodec/nullenc.c| 61 +
 5 files changed, 81 insertions(+)
 create mode 100644 libavcodec/nullenc.c

diff --git a/libavcodec/Makefile b/libavcodec/Makefile
index cd929da8e6..8554b5ee7d 100644
--- a/libavcodec/Makefile
+++ b/libavcodec/Makefile
@@ -542,6 +542,8 @@ OBJS-$(CONFIG_MXPEG_DECODER)   += mxpegdec.o
 OBJS-$(CONFIG_NELLYMOSER_DECODER)  += nellymoserdec.o nellymoser.o
 OBJS-$(CONFIG_NELLYMOSER_ENCODER)  += nellymoserenc.o nellymoser.o
 OBJS-$(CONFIG_NOTCHLC_DECODER) += notchlc.o
+OBJS-$(CONFIG_NULL_AUDIO_ENCODER)  += nullenc.o
+OBJS-$(CONFIG_NULL_VIDEO_ENCODER)  += nullenc.o
 OBJS-$(CONFIG_NUV_DECODER) += nuv.o rtjpeg.o
 OBJS-$(CONFIG_ON2AVC_DECODER)  += on2avc.o on2avcdata.o
 OBJS-$(CONFIG_OPUS_DECODER)+= opusdec.o opus.o opus_celt.o 
opus_rc.o \
diff --git a/libavcodec/allcodecs.c b/libavcodec/allcodecs.c
index 628d27fd75..a30920bfe2 100644
--- a/libavcodec/allcodecs.c
+++ b/libavcodec/allcodecs.c
@@ -487,6 +487,8 @@ extern const AVCodec ff_mpc8_decoder;
 extern const AVCodec ff_msnsiren_decoder;
 extern const AVCodec ff_nellymoser_encoder;
 extern const AVCodec ff_nellymoser_decoder;
+extern const AVCodec ff_null_audio_encoder;
+extern const AVCodec ff_null_video_encoder;
 extern const AVCodec ff_on2avc_decoder;
 extern const AVCodec ff_opus_encoder;
 extern const AVCodec ff_opus_decoder;
diff --git a/libavcodec/codec_desc.c b/libavcodec/codec_desc.c
index 81f3b3c640..7d6bfd352c 100644
--- a/libavcodec/codec_desc.c
+++ b/libavcodec/codec_desc.c
@@ -3516,6 +3516,20 @@ static const AVCodecDescriptor codec_descriptors[] = {
 .long_name = NULL_IF_CONFIG_SMALL("AVFrame to AVPacket passthrough"),
 .props = AV_CODEC_PROP_LOSSLESS,
 },
+{
+.id= AV_CODEC_ID_AUDIO_NULL,
+.type  = AVMEDIA_TYPE_AUDIO,
+.name  = "null_audio",
+.long_name = NULL_IF_CONFIG_SMALL("Audio NULL"),
+.props = AV_CODEC_PROP_LOSSY,
+},
+{
+.id= AV_CODEC_ID_VIDEO_NULL,
+.type  = AVMEDIA_TYPE_VIDEO,
+.name  = "null_video",
+.long_name = NULL_IF_CONFIG_SMALL("Video NULL"),
+.props = AV_CODEC_PROP_LOSSY,
+},
 };
 
 static int descriptor_compare(const void *key, const void *member)
diff --git a/libavcodec/codec_id.h b/libavcodec/codec_id.h
index 3ffb9bd22e..4822dc7685 100644
--- a/libavcodec/codec_id.h
+++ b/libavcodec/codec_id.h
@@ -571,6 +571,8 @@ enum AVCodecID {
 * stream (only used by libavformat) */
 AV_CODEC_ID_FFMETADATA = 0x21000,   ///< Dummy codec for streams 
containing only metadata information.
 AV_CODEC_ID_WRAPPED_AVFRAME = 0x21001, ///< Passthrough codec, AVFrames 
wrapped in AVPacket
+AV_CODEC_ID_AUDIO_NULL = 0x21002, ///< Null audio codec
+AV_CODEC_ID_VIDEO_NULL = 0x21003, ///< Null video codec
 };
 
 /**
diff --git a/libavcodec/nullenc.c b/libavcodec/nullenc.c
new file mode 100644
index 00..8d3553ed33
--- /dev/null
+++ b/libavcodec/nullenc.c
@@ -0,0 +1,61 @@
+/*
+ * Copyright (c) 2022 The FFmpeg Project
+ *
+ * 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/internal.h"
+#include "libavutil/frame.h"
+#include "libavutil/buffer.h"
+
+#include "avcodec.h"
+#include "internal.h"
+#include "encode.h"
+
+static int null_encoder(AVCodecContext *avctx, AVPacket *pkt,
+const AVFrame *frame, int *got_packet)
+{
+int ret;
+
+pkt->pts = frame->pts;
+if (avctx->codec_type == AVMEDIA_TYPE_AUDIO)
+pkt->duration = ff_samples_to_time_base(avctx, frame->nb_samples);
+pkt->flags |= AV_PKT_FLAG_KEY;
+if ((ret = ff_alloc_packet(avctx, pkt, 1)) < 0)
+return ret;
+*got_packet = 1;
+return 0;
+}
+
+const AVCodec ff_null_video_encoder = {
+.name   = "null_video",
+.long_name  = NULL_IF_CONFIG_SMALL("Video NULL encoder"),
+.type   = AVMEDIA_TYPE_VIDEO,
+.id = AV_CODEC_ID_VIDEO_NULL,
+.encode2= null

[FFmpeg-devel] [PATCH 2/2] avformat/nullenc: use null encoders instead

2022-03-14 Thread Paul B Mahol

Signed-off-by: Paul B Mahol 
---
 libavformat/nullenc.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/libavformat/nullenc.c b/libavformat/nullenc.c
index d4769d5920..a83ed72039 100644
--- a/libavformat/nullenc.c
+++ b/libavformat/nullenc.c
@@ -30,8 +30,8 @@ static int null_write_packet(struct AVFormatContext *s, 
AVPacket *pkt)
 const AVOutputFormat ff_null_muxer = {
 .name  = "null",
 .long_name = NULL_IF_CONFIG_SMALL("raw null video"),
-.audio_codec   = AV_NE(AV_CODEC_ID_PCM_S16BE, AV_CODEC_ID_PCM_S16LE),
-.video_codec   = AV_CODEC_ID_WRAPPED_AVFRAME,
+.audio_codec   = AV_CODEC_ID_AUDIO_NULL,
+.video_codec   = AV_CODEC_ID_VIDEO_NULL,
 .write_packet  = null_write_packet,
 .flags = AVFMT_VARIABLE_FPS | AVFMT_NOFILE | 
AVFMT_NOTIMESTAMPS,
 .interleave_packet = ff_interleave_packet_passthrough,
-- 
2.33.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: add null encoders

2022-03-14 Thread James Almer





On 3/14/2022 8:56 AM, Paul B Mahol wrote:

Signed-off-by: Paul B Mahol 
---
  libavcodec/Makefile |  2 ++
  libavcodec/allcodecs.c  |  2 ++
  libavcodec/codec_desc.c | 14 ++
  libavcodec/codec_id.h   |  2 ++
  libavcodec/nullenc.c| 61 +
  5 files changed, 81 insertions(+)
  create mode 100644 libavcodec/nullenc.c

diff --git a/libavcodec/Makefile b/libavcodec/Makefile
index cd929da8e6..8554b5ee7d 100644
--- a/libavcodec/Makefile
+++ b/libavcodec/Makefile
@@ -542,6 +542,8 @@ OBJS-$(CONFIG_MXPEG_DECODER)   += mxpegdec.o
  OBJS-$(CONFIG_NELLYMOSER_DECODER)  += nellymoserdec.o nellymoser.o
  OBJS-$(CONFIG_NELLYMOSER_ENCODER)  += nellymoserenc.o nellymoser.o
  OBJS-$(CONFIG_NOTCHLC_DECODER) += notchlc.o
+OBJS-$(CONFIG_NULL_AUDIO_ENCODER)  += nullenc.o
+OBJS-$(CONFIG_NULL_VIDEO_ENCODER)  += nullenc.o
  OBJS-$(CONFIG_NUV_DECODER) += nuv.o rtjpeg.o
  OBJS-$(CONFIG_ON2AVC_DECODER)  += on2avc.o on2avcdata.o
  OBJS-$(CONFIG_OPUS_DECODER)+= opusdec.o opus.o opus_celt.o 
opus_rc.o \
diff --git a/libavcodec/allcodecs.c b/libavcodec/allcodecs.c
index 628d27fd75..a30920bfe2 100644
--- a/libavcodec/allcodecs.c
+++ b/libavcodec/allcodecs.c
@@ -487,6 +487,8 @@ extern const AVCodec ff_mpc8_decoder;
  extern const AVCodec ff_msnsiren_decoder;
  extern const AVCodec ff_nellymoser_encoder;
  extern const AVCodec ff_nellymoser_decoder;
+extern const AVCodec ff_null_audio_encoder;
+extern const AVCodec ff_null_video_encoder;
  extern const AVCodec ff_on2avc_decoder;
  extern const AVCodec ff_opus_encoder;
  extern const AVCodec ff_opus_decoder;
diff --git a/libavcodec/codec_desc.c b/libavcodec/codec_desc.c
index 81f3b3c640..7d6bfd352c 100644
--- a/libavcodec/codec_desc.c
+++ b/libavcodec/codec_desc.c
@@ -3516,6 +3516,20 @@ static const AVCodecDescriptor codec_descriptors[] = {
  .long_name = NULL_IF_CONFIG_SMALL("AVFrame to AVPacket passthrough"),
  .props = AV_CODEC_PROP_LOSSLESS,
  },
+{
+.id= AV_CODEC_ID_AUDIO_NULL,
+.type  = AVMEDIA_TYPE_AUDIO,
+.name  = "null_audio",
+.long_name = NULL_IF_CONFIG_SMALL("Audio NULL"),
+.props = AV_CODEC_PROP_LOSSY,
+},
+{
+.id= AV_CODEC_ID_VIDEO_NULL,
+.type  = AVMEDIA_TYPE_VIDEO,
+.name  = "null_video",
+.long_name = NULL_IF_CONFIG_SMALL("Video NULL"),
+.props = AV_CODEC_PROP_LOSSY,


Also AV_CODEC_PROP_INTRA_ONLY on both.


+},
  };
  
  static int descriptor_compare(const void *key, const void *member)

diff --git a/libavcodec/codec_id.h b/libavcodec/codec_id.h
index 3ffb9bd22e..4822dc7685 100644
--- a/libavcodec/codec_id.h
+++ b/libavcodec/codec_id.h
@@ -571,6 +571,8 @@ enum AVCodecID {
  * stream (only used by libavformat) */
  AV_CODEC_ID_FFMETADATA = 0x21000,   ///< Dummy codec for streams 
containing only metadata information.
  AV_CODEC_ID_WRAPPED_AVFRAME = 0x21001, ///< Passthrough codec, AVFrames 
wrapped in AVPacket
+AV_CODEC_ID_AUDIO_NULL = 0x21002, ///< Null audio codec
+AV_CODEC_ID_VIDEO_NULL = 0x21003, ///< Null video codec
  };
  
  /**

diff --git a/libavcodec/nullenc.c b/libavcodec/nullenc.c
new file mode 100644
index 00..8d3553ed33
--- /dev/null
+++ b/libavcodec/nullenc.c
@@ -0,0 +1,61 @@
+/*
+ * Copyright (c) 2022 The FFmpeg Project
+ *
+ * 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/internal.h"
+#include "libavutil/frame.h"
+#include "libavutil/buffer.h"
+
+#include "avcodec.h"
+#include "internal.h"
+#include "encode.h"
+
+static int null_encoder(AVCodecContext *avctx, AVPacket *pkt,
+const AVFrame *frame, int *got_packet)
+{
+int ret;
+
+pkt->pts = frame->pts;
+if (avctx->codec_type == AVMEDIA_TYPE_AUDIO)
+pkt->duration = ff_samples_to_time_base(avctx, frame->nb_samples);
+pkt->flags |= AV_PKT_FLAG_KEY;
+if ((ret = ff_alloc_packet(avctx, pkt, 1)) < 0)


To avoid bogus statistics, could you instead allocate a blank packet of 
size av_samples_get_buffer_size()?

Also, use ff_get_encode_buffer() and set the DR1 codec cap.


+return ret;
+*go

Re: [FFmpeg-devel] [PATCH 1/2] avcodec: add null encoders

2022-03-14 Thread Paul B Mahol

On Mon, Mar 14, 2022 at 1:12 PM James Almer  wrote:

>
>
> On 3/14/2022 8:56 AM, Paul B Mahol wrote:
> > Signed-off-by: Paul B Mahol 
> > ---
> >   libavcodec/Makefile |  2 ++
> >   libavcodec/allcodecs.c  |  2 ++
> >   libavcodec/codec_desc.c | 14 ++
> >   libavcodec/codec_id.h   |  2 ++
> >   libavcodec/nullenc.c| 61 +
> >   5 files changed, 81 insertions(+)
> >   create mode 100644 libavcodec/nullenc.c
> >
> > diff --git a/libavcodec/Makefile b/libavcodec/Makefile
> > index cd929da8e6..8554b5ee7d 100644
> > --- a/libavcodec/Makefile
> > +++ b/libavcodec/Makefile
> > @@ -542,6 +542,8 @@ OBJS-$(CONFIG_MXPEG_DECODER)   += mxpegdec.o
> >   OBJS-$(CONFIG_NELLYMOSER_DECODER)  += nellymoserdec.o nellymoser.o
> >   OBJS-$(CONFIG_NELLYMOSER_ENCODER)  += nellymoserenc.o nellymoser.o
> >   OBJS-$(CONFIG_NOTCHLC_DECODER) += notchlc.o
> > +OBJS-$(CONFIG_NULL_AUDIO_ENCODER)  += nullenc.o
> > +OBJS-$(CONFIG_NULL_VIDEO_ENCODER)  += nullenc.o
> >   OBJS-$(CONFIG_NUV_DECODER) += nuv.o rtjpeg.o
> >   OBJS-$(CONFIG_ON2AVC_DECODER)  += on2avc.o on2avcdata.o
> >   OBJS-$(CONFIG_OPUS_DECODER)+= opusdec.o opus.o opus_celt.o
> opus_rc.o \
> > diff --git a/libavcodec/allcodecs.c b/libavcodec/allcodecs.c
> > index 628d27fd75..a30920bfe2 100644
> > --- a/libavcodec/allcodecs.c
> > +++ b/libavcodec/allcodecs.c
> > @@ -487,6 +487,8 @@ extern const AVCodec ff_mpc8_decoder;
> >   extern const AVCodec ff_msnsiren_decoder;
> >   extern const AVCodec ff_nellymoser_encoder;
> >   extern const AVCodec ff_nellymoser_decoder;
> > +extern const AVCodec ff_null_audio_encoder;
> > +extern const AVCodec ff_null_video_encoder;
> >   extern const AVCodec ff_on2avc_decoder;
> >   extern const AVCodec ff_opus_encoder;
> >   extern const AVCodec ff_opus_decoder;
> > diff --git a/libavcodec/codec_desc.c b/libavcodec/codec_desc.c
> > index 81f3b3c640..7d6bfd352c 100644
> > --- a/libavcodec/codec_desc.c
> > +++ b/libavcodec/codec_desc.c
> > @@ -3516,6 +3516,20 @@ static const AVCodecDescriptor
> codec_descriptors[] = {
> >   .long_name = NULL_IF_CONFIG_SMALL("AVFrame to AVPacket
> passthrough"),
> >   .props = AV_CODEC_PROP_LOSSLESS,
> >   },
> > +{
> > +.id= AV_CODEC_ID_AUDIO_NULL,
> > +.type  = AVMEDIA_TYPE_AUDIO,
> > +.name  = "null_audio",
> > +.long_name = NULL_IF_CONFIG_SMALL("Audio NULL"),
> > +.props = AV_CODEC_PROP_LOSSY,
> > +},
> > +{
> > +.id= AV_CODEC_ID_VIDEO_NULL,
> > +.type  = AVMEDIA_TYPE_VIDEO,
> > +.name  = "null_video",
> > +.long_name = NULL_IF_CONFIG_SMALL("Video NULL"),
> > +.props = AV_CODEC_PROP_LOSSY,
>
> Also AV_CODEC_PROP_INTRA_ONLY on both.
>
> > +},
> >   };
> >
> >   static int descriptor_compare(const void *key, const void *member)
> > diff --git a/libavcodec/codec_id.h b/libavcodec/codec_id.h
> > index 3ffb9bd22e..4822dc7685 100644
> > --- a/libavcodec/codec_id.h
> > +++ b/libavcodec/codec_id.h
> > @@ -571,6 +571,8 @@ enum AVCodecID {
> >   * stream (only used by libavformat) */
> >   AV_CODEC_ID_FFMETADATA = 0x21000,   ///< Dummy codec for streams
> containing only metadata information.
> >   AV_CODEC_ID_WRAPPED_AVFRAME = 0x21001, ///< Passthrough codec,
> AVFrames wrapped in AVPacket
> > +AV_CODEC_ID_AUDIO_NULL = 0x21002, ///< Null audio codec
> > +AV_CODEC_ID_VIDEO_NULL = 0x21003, ///< Null video codec
> >   };
> >
> >   /**
> > diff --git a/libavcodec/nullenc.c b/libavcodec/nullenc.c
> > new file mode 100644
> > index 00..8d3553ed33
> > --- /dev/null
> > +++ b/libavcodec/nullenc.c
> > @@ -0,0 +1,61 @@
> > +/*
> > + * Copyright (c) 2022 The FFmpeg Project
> > + *
> > + * 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/internal.h"
> > +#include "libavutil/frame.h"
> > +#include "libavutil/buffer.h"
> > +
> > +#include "avcodec.h"
> > +#include "internal.h"
> > +#include "encode.h"
> > +
> > +static int null_encoder(AVCodecContext *avctx, AVPacket *pkt,
> > +const A

Re: [FFmpeg-devel] [PATCH 1/2] avcodec: add null encoders

2022-03-14 Thread James Almer





On 3/14/2022 9:17 AM, Paul B Mahol wrote:

On Mon, Mar 14, 2022 at 1:12 PM James Almer  wrote:




On 3/14/2022 8:56 AM, Paul B Mahol wrote:

Signed-off-by: Paul B Mahol 
---
   libavcodec/Makefile |  2 ++
   libavcodec/allcodecs.c  |  2 ++
   libavcodec/codec_desc.c | 14 ++
   libavcodec/codec_id.h   |  2 ++
   libavcodec/nullenc.c| 61 +
   5 files changed, 81 insertions(+)
   create mode 100644 libavcodec/nullenc.c

diff --git a/libavcodec/Makefile b/libavcodec/Makefile
index cd929da8e6..8554b5ee7d 100644
--- a/libavcodec/Makefile
+++ b/libavcodec/Makefile
@@ -542,6 +542,8 @@ OBJS-$(CONFIG_MXPEG_DECODER)   += mxpegdec.o
   OBJS-$(CONFIG_NELLYMOSER_DECODER)  += nellymoserdec.o nellymoser.o
   OBJS-$(CONFIG_NELLYMOSER_ENCODER)  += nellymoserenc.o nellymoser.o
   OBJS-$(CONFIG_NOTCHLC_DECODER) += notchlc.o
+OBJS-$(CONFIG_NULL_AUDIO_ENCODER)  += nullenc.o
+OBJS-$(CONFIG_NULL_VIDEO_ENCODER)  += nullenc.o
   OBJS-$(CONFIG_NUV_DECODER) += nuv.o rtjpeg.o
   OBJS-$(CONFIG_ON2AVC_DECODER)  += on2avc.o on2avcdata.o
   OBJS-$(CONFIG_OPUS_DECODER)+= opusdec.o opus.o opus_celt.o

opus_rc.o \

diff --git a/libavcodec/allcodecs.c b/libavcodec/allcodecs.c
index 628d27fd75..a30920bfe2 100644
--- a/libavcodec/allcodecs.c
+++ b/libavcodec/allcodecs.c
@@ -487,6 +487,8 @@ extern const AVCodec ff_mpc8_decoder;
   extern const AVCodec ff_msnsiren_decoder;
   extern const AVCodec ff_nellymoser_encoder;
   extern const AVCodec ff_nellymoser_decoder;
+extern const AVCodec ff_null_audio_encoder;
+extern const AVCodec ff_null_video_encoder;
   extern const AVCodec ff_on2avc_decoder;
   extern const AVCodec ff_opus_encoder;
   extern const AVCodec ff_opus_decoder;
diff --git a/libavcodec/codec_desc.c b/libavcodec/codec_desc.c
index 81f3b3c640..7d6bfd352c 100644
--- a/libavcodec/codec_desc.c
+++ b/libavcodec/codec_desc.c
@@ -3516,6 +3516,20 @@ static const AVCodecDescriptor

codec_descriptors[] = {

   .long_name = NULL_IF_CONFIG_SMALL("AVFrame to AVPacket

passthrough"),

   .props = AV_CODEC_PROP_LOSSLESS,
   },
+{
+.id= AV_CODEC_ID_AUDIO_NULL,
+.type  = AVMEDIA_TYPE_AUDIO,
+.name  = "null_audio",
+.long_name = NULL_IF_CONFIG_SMALL("Audio NULL"),
+.props = AV_CODEC_PROP_LOSSY,
+},
+{
+.id= AV_CODEC_ID_VIDEO_NULL,
+.type  = AVMEDIA_TYPE_VIDEO,
+.name  = "null_video",
+.long_name = NULL_IF_CONFIG_SMALL("Video NULL"),
+.props = AV_CODEC_PROP_LOSSY,


Also AV_CODEC_PROP_INTRA_ONLY on both.


+},
   };

   static int descriptor_compare(const void *key, const void *member)
diff --git a/libavcodec/codec_id.h b/libavcodec/codec_id.h
index 3ffb9bd22e..4822dc7685 100644
--- a/libavcodec/codec_id.h
+++ b/libavcodec/codec_id.h
@@ -571,6 +571,8 @@ enum AVCodecID {
   * stream (only used by libavformat) */
   AV_CODEC_ID_FFMETADATA = 0x21000,   ///< Dummy codec for streams

containing only metadata information.

   AV_CODEC_ID_WRAPPED_AVFRAME = 0x21001, ///< Passthrough codec,

AVFrames wrapped in AVPacket

+AV_CODEC_ID_AUDIO_NULL = 0x21002, ///< Null audio codec
+AV_CODEC_ID_VIDEO_NULL = 0x21003, ///< Null video codec
   };

   /**
diff --git a/libavcodec/nullenc.c b/libavcodec/nullenc.c
new file mode 100644
index 00..8d3553ed33
--- /dev/null
+++ b/libavcodec/nullenc.c
@@ -0,0 +1,61 @@
+/*
+ * Copyright (c) 2022 The FFmpeg Project
+ *
+ * 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/internal.h"
+#include "libavutil/frame.h"
+#include "libavutil/buffer.h"
+
+#include "avcodec.h"
+#include "internal.h"
+#include "encode.h"
+
+static int null_encoder(AVCodecContext *avctx, AVPacket *pkt,
+const AVFrame *frame, int *got_packet)
+{
+int ret;
+
+pkt->pts = frame->pts;
+if (avctx->codec_type == AVMEDIA_TYPE_AUDIO)
+pkt->duration = ff_samples_to_time_base(avctx,

frame->nb_samples);

+pkt->flags |= AV_PKT_FLAG_KEY;
+if ((ret = ff_alloc_packet(avctx, pkt, 1)) < 0)


To avoid bogus statistics, could you instead allocate a blank packe

Re: [FFmpeg-devel] [PATCH 1/2] avcodec: add null encoders

2022-03-14 Thread Paul B Mahol

On Mon, Mar 14, 2022 at 1:17 PM James Almer  wrote:

>
>
> On 3/14/2022 9:17 AM, Paul B Mahol wrote:
> > On Mon, Mar 14, 2022 at 1:12 PM James Almer  wrote:
> >
> >>
> >>
> >> On 3/14/2022 8:56 AM, Paul B Mahol wrote:
> >>> Signed-off-by: Paul B Mahol 
> >>> ---
> >>>libavcodec/Makefile |  2 ++
> >>>libavcodec/allcodecs.c  |  2 ++
> >>>libavcodec/codec_desc.c | 14 ++
> >>>libavcodec/codec_id.h   |  2 ++
> >>>libavcodec/nullenc.c| 61
> +
> >>>5 files changed, 81 insertions(+)
> >>>create mode 100644 libavcodec/nullenc.c
> >>>
> >>> diff --git a/libavcodec/Makefile b/libavcodec/Makefile
> >>> index cd929da8e6..8554b5ee7d 100644
> >>> --- a/libavcodec/Makefile
> >>> +++ b/libavcodec/Makefile
> >>> @@ -542,6 +542,8 @@ OBJS-$(CONFIG_MXPEG_DECODER)   +=
> mxpegdec.o
> >>>OBJS-$(CONFIG_NELLYMOSER_DECODER)  += nellymoserdec.o
> nellymoser.o
> >>>OBJS-$(CONFIG_NELLYMOSER_ENCODER)  += nellymoserenc.o
> nellymoser.o
> >>>OBJS-$(CONFIG_NOTCHLC_DECODER) += notchlc.o
> >>> +OBJS-$(CONFIG_NULL_AUDIO_ENCODER)  += nullenc.o
> >>> +OBJS-$(CONFIG_NULL_VIDEO_ENCODER)  += nullenc.o
> >>>OBJS-$(CONFIG_NUV_DECODER) += nuv.o rtjpeg.o
> >>>OBJS-$(CONFIG_ON2AVC_DECODER)  += on2avc.o on2avcdata.o
> >>>OBJS-$(CONFIG_OPUS_DECODER)+= opusdec.o opus.o
> opus_celt.o
> >> opus_rc.o \
> >>> diff --git a/libavcodec/allcodecs.c b/libavcodec/allcodecs.c
> >>> index 628d27fd75..a30920bfe2 100644
> >>> --- a/libavcodec/allcodecs.c
> >>> +++ b/libavcodec/allcodecs.c
> >>> @@ -487,6 +487,8 @@ extern const AVCodec ff_mpc8_decoder;
> >>>extern const AVCodec ff_msnsiren_decoder;
> >>>extern const AVCodec ff_nellymoser_encoder;
> >>>extern const AVCodec ff_nellymoser_decoder;
> >>> +extern const AVCodec ff_null_audio_encoder;
> >>> +extern const AVCodec ff_null_video_encoder;
> >>>extern const AVCodec ff_on2avc_decoder;
> >>>extern const AVCodec ff_opus_encoder;
> >>>extern const AVCodec ff_opus_decoder;
> >>> diff --git a/libavcodec/codec_desc.c b/libavcodec/codec_desc.c
> >>> index 81f3b3c640..7d6bfd352c 100644
> >>> --- a/libavcodec/codec_desc.c
> >>> +++ b/libavcodec/codec_desc.c
> >>> @@ -3516,6 +3516,20 @@ static const AVCodecDescriptor
> >> codec_descriptors[] = {
> >>>.long_name = NULL_IF_CONFIG_SMALL("AVFrame to AVPacket
> >> passthrough"),
> >>>.props = AV_CODEC_PROP_LOSSLESS,
> >>>},
> >>> +{
> >>> +.id= AV_CODEC_ID_AUDIO_NULL,
> >>> +.type  = AVMEDIA_TYPE_AUDIO,
> >>> +.name  = "null_audio",
> >>> +.long_name = NULL_IF_CONFIG_SMALL("Audio NULL"),
> >>> +.props = AV_CODEC_PROP_LOSSY,
> >>> +},
> >>> +{
> >>> +.id= AV_CODEC_ID_VIDEO_NULL,
> >>> +.type  = AVMEDIA_TYPE_VIDEO,
> >>> +.name  = "null_video",
> >>> +.long_name = NULL_IF_CONFIG_SMALL("Video NULL"),
> >>> +.props = AV_CODEC_PROP_LOSSY,
> >>
> >> Also AV_CODEC_PROP_INTRA_ONLY on both.
> >>
> >>> +},
> >>>};
> >>>
> >>>static int descriptor_compare(const void *key, const void *member)
> >>> diff --git a/libavcodec/codec_id.h b/libavcodec/codec_id.h
> >>> index 3ffb9bd22e..4822dc7685 100644
> >>> --- a/libavcodec/codec_id.h
> >>> +++ b/libavcodec/codec_id.h
> >>> @@ -571,6 +571,8 @@ enum AVCodecID {
> >>>* stream (only used by libavformat)
> */
> >>>AV_CODEC_ID_FFMETADATA = 0x21000,   ///< Dummy codec for streams
> >> containing only metadata information.
> >>>AV_CODEC_ID_WRAPPED_AVFRAME = 0x21001, ///< Passthrough codec,
> >> AVFrames wrapped in AVPacket
> >>> +AV_CODEC_ID_AUDIO_NULL = 0x21002, ///< Null audio codec
> >>> +AV_CODEC_ID_VIDEO_NULL = 0x21003, ///< Null video codec
> >>>};
> >>>
> >>>/**
> >>> diff --git a/libavcodec/nullenc.c b/libavcodec/nullenc.c
> >>> new file mode 100644
> >>> index 00..8d3553ed33
> >>> --- /dev/null
> >>> +++ b/libavcodec/nullenc.c
> >>> @@ -0,0 +1,61 @@
> >>> +/*
> >>> + * Copyright (c) 2022 The FFmpeg Project
> >>> + *
> >>> + * 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

[FFmpeg-devel] [PATCH] Allow to modify max qp configuration parameter in libvpx without reseting the encoder

2022-03-14 Thread Danil Chapovalov

---
 libavcodec/libvpxenc.c | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/libavcodec/libvpxenc.c b/libavcodec/libvpxenc.c
index 8f94ba15dc..45baeed435 100644
--- a/libavcodec/libvpxenc.c
+++ b/libavcodec/libvpxenc.c
@@ -1658,6 +1658,13 @@ static int vpx_encode(AVCodecContext *avctx, AVPacket 
*pkt,
 flags |= strtoul(en->value, NULL, 10);
 }
 
+en = av_dict_get(frame->metadata, "max-quantizer", NULL, 0);
+if (en) {
+struct vpx_codec_enc_cfg cfg = *enccfg;
+cfg.rc_max_quantizer = strtoul(en->value, NULL, 10);
+vpx_codec_enc_config_set(&ctx->encoder, &cfg);
+}
+
 memset(&layer_id, 0, sizeof(layer_id));
 
 en = av_dict_get(frame->metadata, "temporal_id", NULL, 0);
-- 
2.35.1.723.g4982287a31-goog

___
ffmpeg-devel mailing list
ffmpeg-devel@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] ffmpeg: print proper statistics for video output when using wrapped avframe encoder

2022-03-14 Thread James Almer

pkt->size contains the size of an AVFrame struct plus some padding, which is 
meaningless.
Use instead the size of a raw video frame, as if it was the rawvideo encoder.

Signed-off-by: James Almer 
---
 fftools/ffmpeg.c | 11 +--
 1 file changed, 9 insertions(+), 2 deletions(-)

diff --git a/fftools/ffmpeg.c b/fftools/ffmpeg.c
index 9a3fdc636d..a878554627 100644
--- a/fftools/ffmpeg.c
+++ b/fftools/ffmpeg.c
@@ -722,6 +722,7 @@ static void write_packet(OutputFile *of, AVPacket *pkt, 
OutputStream *ost, int u
 {
 AVFormatContext *s = of->ctx;
 AVStream *st = ost->st;
+int data_size = pkt->size;
 int ret;
 
 /*
@@ -796,6 +797,12 @@ static void write_packet(OutputFile *of, AVPacket *pkt, 
OutputStream *ost, int u
 pkt->duration = av_rescale_q(1, av_inv_q(ost->frame_rate),
  ost->mux_timebase);
 }
+
+if (st->codecpar->codec_id == AV_CODEC_ID_WRAPPED_AVFRAME) {
+ret = av_image_get_buffer_size(st->codecpar->format, 
st->codecpar->width, st->codecpar->height, 1);
+if (ret >= 0)
+data_size = ret;
+}
 }
 
 av_packet_rescale_ts(pkt, ost->mux_timebase, ost->st->time_base);
@@ -838,7 +845,7 @@ static void write_packet(OutputFile *of, AVPacket *pkt, 
OutputStream *ost, int u
 }
 ost->last_mux_dts = pkt->dts;
 
-ost->data_size += pkt->size;
+ost->data_size += data_size;
 ost->packets_written++;
 
 pkt->stream_index = ost->index;
@@ -849,7 +856,7 @@ static void write_packet(OutputFile *of, AVPacket *pkt, 
OutputStream *ost, int u
 av_get_media_type_string(ost->enc_ctx->codec_type),
 av_ts2str(pkt->pts), av_ts2timestr(pkt->pts, 
&ost->st->time_base),
 av_ts2str(pkt->dts), av_ts2timestr(pkt->dts, 
&ost->st->time_base),
-pkt->size
+data_size
   );
 }
 
-- 
2.35.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 3/4] avformat/mxfdec: Check for avio_read() failure in mxf_read_strong_ref_array()

2022-03-14 Thread Michael Niedermayer

On Sun, Mar 13, 2022 at 04:52:25PM +0100, Marton Balint wrote:
> 
> 
> On Sun, 13 Mar 2022, Michael Niedermayer wrote:
> 
> > Signed-off-by: Michael Niedermayer 
> > ---
> > libavformat/mxfdec.c | 8 +++-
> > 1 file changed, 7 insertions(+), 1 deletion(-)
> > 
> > diff --git a/libavformat/mxfdec.c b/libavformat/mxfdec.c
> > index d7cdd22c8a..828fc0f9f1 100644
> > --- a/libavformat/mxfdec.c
> > +++ b/libavformat/mxfdec.c
> > @@ -932,6 +932,7 @@ static int mxf_read_cryptographic_context(void *arg, 
> > AVIOContext *pb, int tag, i
> > 
> > static int mxf_read_strong_ref_array(AVIOContext *pb, UID **refs, int 
> > *count)
> > {
> > +int64_t ret;
> > unsigned c = avio_rb32(pb);
> > 
> > //avio_read() used int
> > @@ -946,7 +947,12 @@ static int mxf_read_strong_ref_array(AVIOContext *pb, 
> > UID **refs, int *count)
> > return AVERROR(ENOMEM);
> > }
> > avio_skip(pb, 4); /* useless size of objects, always 16 according to 
> > specs */
> > -avio_read(pb, (uint8_t *)*refs, *count * sizeof(UID));
> > +ret = avio_read(pb, (uint8_t *)*refs, *count * sizeof(UID));
> > +if (ret != *count * sizeof(UID)) {
> > +*count = ret < 0 ? 0   : ret / sizeof(UID);
> 

> I suggest you hard fail if the read count is not the expected, do not
> silently ignore corrupt file.
> 
> Regards,
> Marton
> 
> > +return   ret < 0 ? ret : AVERROR_INVALIDDATA;

Does it not hard fail here ?

thx

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

Take away the freedom of one citizen and you will be jailed, take away
the freedom of all citizens and you will be congratulated by your peers
in Parliament.


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 4/4] avformat/mxfdec: Do not clear array in mxf_read_strong_ref_array() before writing

2022-03-14 Thread Michael Niedermayer

On Sun, Mar 13, 2022 at 04:53:29PM +0100, Marton Balint wrote:
> 
> 
> On Sun, 13 Mar 2022, Michael Niedermayer wrote:
> 
> > Signed-off-by: Michael Niedermayer 
> > ---
> > libavformat/mxfdec.c | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> > 
> > diff --git a/libavformat/mxfdec.c b/libavformat/mxfdec.c
> > index 828fc0f9f1..f088712494 100644
> > --- a/libavformat/mxfdec.c
> > +++ b/libavformat/mxfdec.c
> > @@ -941,7 +941,7 @@ static int mxf_read_strong_ref_array(AVIOContext *pb, 
> > UID **refs, int *count)
> > *count = c;
> > 
> > av_free(*refs);
> > -*refs = av_calloc(*count, sizeof(UID));
> > +*refs = av_malloc(*count * sizeof(UID));
> 
> I suggest av_malloc_array(), even if it can't overflow because of earlier
> checks.

agree, will change that

thx

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

"You are 36 times more likely to die in a bathtub than at the hands of a
terrorist. Also, you are 2.5 times more likely to become a president and
2 times more likely to become an astronaut, than to die in a terrorist
attack." -- Thoughty2



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/vp9_superframe_split_bsf: Check in size

2022-03-14 Thread Michael Niedermayer

On Sun, Mar 13, 2022 at 04:03:42PM -0300, James Almer wrote:
> 
> 
> On 3/12/2022 8:52 PM, Michael Niedermayer wrote:
> > Fixes: Out of array read
> > Fixes: 
> > 45137/clusterfuzz-testcase-minimized-ffmpeg_BSF_VP9_SUPERFRAME_SPLIT_fuzzer-4984270639202304
> > 
> > Found-by: continuous fuzzing process 
> > https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
> > Signed-off-by: Michael Niedermayer 
> > ---
> >   libavcodec/vp9_superframe_split_bsf.c | 5 +
> >   1 file changed, 5 insertions(+)
> > 
> > diff --git a/libavcodec/vp9_superframe_split_bsf.c 
> > b/libavcodec/vp9_superframe_split_bsf.c
> > index ed0444561a..6af555c078 100644
> > --- a/libavcodec/vp9_superframe_split_bsf.c
> > +++ b/libavcodec/vp9_superframe_split_bsf.c
> > @@ -51,6 +51,11 @@ static int vp9_superframe_split_filter(AVBSFContext 
> > *ctx, AVPacket *out)
> >   return ret;
> >   in = s->buffer_pkt;
> > +if (in->size == 0) {
> 
> !in->size

I favor checking "== 0" when its about the value 0 and !X when its about
something being not set / not allocated.
but i can change it if you prefer

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

The smallest minority on earth is the individual. Those who deny 
individual rights cannot claim to be defenders of minorities. - Ayn Rand


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/vp9_superframe_split_bsf: Check in size

2022-03-14 Thread James Almer





On 3/14/2022 11:04 AM, Michael Niedermayer wrote:

On Sun, Mar 13, 2022 at 04:03:42PM -0300, James Almer wrote:



On 3/12/2022 8:52 PM, Michael Niedermayer wrote:

Fixes: Out of array read
Fixes: 
45137/clusterfuzz-testcase-minimized-ffmpeg_BSF_VP9_SUPERFRAME_SPLIT_fuzzer-4984270639202304

Found-by: continuous fuzzing process 
https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer 
---
   libavcodec/vp9_superframe_split_bsf.c | 5 +
   1 file changed, 5 insertions(+)

diff --git a/libavcodec/vp9_superframe_split_bsf.c 
b/libavcodec/vp9_superframe_split_bsf.c
index ed0444561a..6af555c078 100644
--- a/libavcodec/vp9_superframe_split_bsf.c
+++ b/libavcodec/vp9_superframe_split_bsf.c
@@ -51,6 +51,11 @@ static int vp9_superframe_split_filter(AVBSFContext *ctx, 
AVPacket *out)
   return ret;
   in = s->buffer_pkt;
+if (in->size == 0) {


!in->size


I favor checking "== 0" when its about the value 0 and !X when its about
something being not set / not allocated.
but i can change it if you prefer

thx


I suggested it for the sake of consistence. Most AVPacket.size checks 
use !X to check for 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/4] avcodec/vp9_superframe_split_bsf: Check in size

2022-03-14 Thread Michael Niedermayer

On Mon, Mar 14, 2022 at 11:07:38AM -0300, James Almer wrote:
> 
> 
> On 3/14/2022 11:04 AM, Michael Niedermayer wrote:
> > On Sun, Mar 13, 2022 at 04:03:42PM -0300, James Almer wrote:
> > > 
> > > 
> > > On 3/12/2022 8:52 PM, Michael Niedermayer wrote:
> > > > Fixes: Out of array read
> > > > Fixes: 
> > > > 45137/clusterfuzz-testcase-minimized-ffmpeg_BSF_VP9_SUPERFRAME_SPLIT_fuzzer-4984270639202304
> > > > 
> > > > Found-by: continuous fuzzing process 
> > > > https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
> > > > Signed-off-by: Michael Niedermayer 
> > > > ---
> > > >libavcodec/vp9_superframe_split_bsf.c | 5 +
> > > >1 file changed, 5 insertions(+)
> > > > 
> > > > diff --git a/libavcodec/vp9_superframe_split_bsf.c 
> > > > b/libavcodec/vp9_superframe_split_bsf.c
> > > > index ed0444561a..6af555c078 100644
> > > > --- a/libavcodec/vp9_superframe_split_bsf.c
> > > > +++ b/libavcodec/vp9_superframe_split_bsf.c
> > > > @@ -51,6 +51,11 @@ static int vp9_superframe_split_filter(AVBSFContext 
> > > > *ctx, AVPacket *out)
> > > >return ret;
> > > >in = s->buffer_pkt;
> > > > +if (in->size == 0) {
> > > 
> > > !in->size
> > 
> > I favor checking "== 0" when its about the value 0 and !X when its about
> > something being not set / not allocated.
> > but i can change it if you prefer
> > 
> > thx
> 
> I suggested it for the sake of consistence. Most AVPacket.size checks use !X
> to check for 0.

changed
thx

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

[FFmpeg-devel] [PATCH] ffmpeg: add packet duration to AVPacket logging

2022-03-14 Thread Jan Ekström

From: Jaakko Perttilä 

Especially useful when debugging subtitle output, but also shows
if values are set or not for demux and encoding.

Co-authored-by: Jan Ekström 

Signed-off-by: Jan Ekström 
---
 fftools/ffmpeg.c | 27 ++-
 1 file changed, 18 insertions(+), 9 deletions(-)

diff --git a/fftools/ffmpeg.c b/fftools/ffmpeg.c
index 9a3fdc636d..98e175068e 100644
--- a/fftools/ffmpeg.c
+++ b/fftools/ffmpeg.c
@@ -845,10 +845,11 @@ static void write_packet(OutputFile *of, AVPacket *pkt, 
OutputStream *ost, int u
 
 if (debug_ts) {
 av_log(NULL, AV_LOG_INFO, "muxer <- type:%s "
-"pkt_pts:%s pkt_pts_time:%s pkt_dts:%s pkt_dts_time:%s 
size:%d\n",
+"pkt_pts:%s pkt_pts_time:%s pkt_dts:%s pkt_dts_time:%s 
duration:%s duration_time:%s size:%d\n",
 av_get_media_type_string(ost->enc_ctx->codec_type),
 av_ts2str(pkt->pts), av_ts2timestr(pkt->pts, 
&ost->st->time_base),
 av_ts2str(pkt->dts), av_ts2timestr(pkt->dts, 
&ost->st->time_base),
+av_ts2str(pkt->duration), av_ts2timestr(pkt->duration, 
&ost->st->time_base),
 pkt->size
   );
 }
@@ -1036,9 +1037,11 @@ static void do_audio_out(OutputFile *of, OutputStream 
*ost,
 
 if (debug_ts) {
 av_log(NULL, AV_LOG_INFO, "encoder -> type:audio "
-   "pkt_pts:%s pkt_pts_time:%s pkt_dts:%s pkt_dts_time:%s\n",
+   "pkt_pts:%s pkt_pts_time:%s pkt_dts:%s pkt_dts_time:%s "
+   "duration:%s duration_time:%s\n",
av_ts2str(pkt->pts), av_ts2timestr(pkt->pts, 
&enc->time_base),
-   av_ts2str(pkt->dts), av_ts2timestr(pkt->dts, 
&enc->time_base));
+   av_ts2str(pkt->dts), av_ts2timestr(pkt->dts, 
&enc->time_base),
+   av_ts2str(pkt->duration), av_ts2timestr(pkt->duration, 
&enc->time_base));
 }
 
 output_packet(of, pkt, ost, 0);
@@ -1360,9 +1363,11 @@ static void do_video_out(OutputFile *of,
 
 if (debug_ts) {
 av_log(NULL, AV_LOG_INFO, "encoder -> type:video "
-   "pkt_pts:%s pkt_pts_time:%s pkt_dts:%s 
pkt_dts_time:%s\n",
+   "pkt_pts:%s pkt_pts_time:%s pkt_dts:%s pkt_dts_time:%s "
+   "duration:%s duration_time:%s\n",
av_ts2str(pkt->pts), av_ts2timestr(pkt->pts, 
&enc->time_base),
-   av_ts2str(pkt->dts), av_ts2timestr(pkt->dts, 
&enc->time_base));
+   av_ts2str(pkt->dts), av_ts2timestr(pkt->dts, 
&enc->time_base),
+   av_ts2str(pkt->duration), av_ts2timestr(pkt->duration, 
&enc->time_base));
 }
 
 if (pkt->pts == AV_NOPTS_VALUE && !(enc->codec->capabilities & 
AV_CODEC_CAP_DELAY))
@@ -1372,9 +1377,11 @@ static void do_video_out(OutputFile *of,
 
 if (debug_ts) {
 av_log(NULL, AV_LOG_INFO, "encoder -> type:video "
-"pkt_pts:%s pkt_pts_time:%s pkt_dts:%s pkt_dts_time:%s\n",
+"pkt_pts:%s pkt_pts_time:%s pkt_dts:%s pkt_dts_time:%s "
+"duration:%s duration_time:%s\n",
 av_ts2str(pkt->pts), av_ts2timestr(pkt->pts, 
&ost->mux_timebase),
-av_ts2str(pkt->dts), av_ts2timestr(pkt->dts, 
&ost->mux_timebase));
+av_ts2str(pkt->dts), av_ts2timestr(pkt->dts, 
&ost->mux_timebase),
+av_ts2str(pkt->duration), av_ts2timestr(pkt->duration, 
&ost->mux_timebase));
 }
 
 frame_size = pkt->size;
@@ -4304,12 +4311,13 @@ static int process_input(int file_index)
 
 if (debug_ts) {
 av_log(NULL, AV_LOG_INFO, "demuxer -> ist_index:%d type:%s "
-   "next_dts:%s next_dts_time:%s next_pts:%s next_pts_time:%s 
pkt_pts:%s pkt_pts_time:%s pkt_dts:%s pkt_dts_time:%s off:%s off_time:%s\n",
+   "next_dts:%s next_dts_time:%s next_pts:%s next_pts_time:%s 
pkt_pts:%s pkt_pts_time:%s pkt_dts:%s pkt_dts_time:%s duration:%s 
duration_time:%s off:%s off_time:%s\n",
ifile->ist_index + pkt->stream_index, 
av_get_media_type_string(ist->dec_ctx->codec_type),
av_ts2str(ist->next_dts), av_ts2timestr(ist->next_dts, 
&AV_TIME_BASE_Q),
av_ts2str(ist->next_pts), av_ts2timestr(ist->next_pts, 
&AV_TIME_BASE_Q),
av_ts2str(pkt->pts), av_ts2timestr(pkt->pts, 
&ist->st->time_base),
av_ts2str(pkt->dts), av_ts2timestr(pkt->dts, 
&ist->st->time_base),
+   av_ts2str(pkt->duration), av_ts2timestr(pkt->duration, 
&ist->st->time_base),
av_ts2str(input_files[ist->file_index]->ts_offset),
av_ts2timestr(input_files[ist->file_index]->ts_offset, 
&AV_TIME_BASE_Q));
 }
@@ -4460,10 +4468,11 @@ static int process_input(int file_index)
 ifile->last_ts = av_rescale_q(pkt->dts, ist->st->time_base, 
AV_TIME_

Re: [FFmpeg-devel] [PATCH 00/13] [RFC] Reduce unnecessary recompilation

2022-03-14 Thread Michael Niedermayer

On Fri, Mar 11, 2022 at 02:17:42PM +0200, Martin Storsjö wrote:
> On Wed, 23 Feb 2022, Martin Storsjö wrote:
> 
> > When updating the ffmpeg source, one quite often ends up in a situation
> > where practically all of the codebase (or all of a library) gets rebuilt,
> > due to updates to headers that are included in most files.
> > 
> > In some cases, full rebuilds are warranted of course, but they could also
> > be avoided in many cases - e.g. such as if the minor/micro version of
> > a library has been bumped, or if a new component (codec, demuxer, filter
> > etc) has been enabled (or removed if reconfiguring with an older source
> > version). Very few source files are affected by exactly what the full
> > library version is, or by the full list of enabled components.
> > 
> > To avoid such rebuilds, I've got a proof of concept patchset that
> > splits headers, so that most source files avoid including the bits that
> > change often and that shouldn't affect how they are built.
> > 
> > - The version.h headers are split into a separate version_major.h which
> >  contains only the major library version, and accompanying FF_API_*
> >  defines. The main library headers only include version_major.h, and
> >  files that need the exact version (e.g. LIB_VERSION* or
> >  LIB_IDENT) can include version.h explicitly. This is a minor
> >  break of the public API though, as definitions that used to be available
> >  no longer are.
> > 
> >  This works mostly fine for most libraries, but there's little point in
> >  splitting libavutil/version.h, because LIBAVUTIL_VERSION_INT is used
> >  in every source file that defines an AVClass.
> > 
> >  By splitting version.h, and update to the minor/micro version numbers
> >  of all libraries except avutil now would require recompiling 30
> >  files instead of 1653 before.
> > 
> >  (This change also should lower the barrier to and reduce the risk of
> >  forgetting to bump the version numbers, which one otherwise often
> >  postpones while working on a patch, as it forces rebuilds.)
> > 
> > - config.h is split into a separate config_components.h that includes the
> >  list of enabled/disabled components (corresponding to $ALL_COMPONENTS
> >  in configure). One could consider splitting up config.h even more, but
> >  that probably gives less benefit compared to the amount of churn.
> > 
> >  Surprisingly, a nontrivial number of source files do depend on the
> >  state of specific encoders/decoders/components, so quite a few files
> >  do end up requiring including config_components.h. (Also this change
> >  can possibly break compilation of source files that require external
> >  dependencies that I haven't tested.)
> > 
> >  In practice, this reduces the number of rebuilt source files from
> >  1979 to 193, if there's a change to the list of enabled components
> >  but not to the rest of config.h.
> > 
> > What do you think - is it worth the slight churn to avoid pointless
> > rebuilds?
> 
> Ping - I never got any feedback on the general concept of this patchset; is
> either of the refactorings worthwhile?

I think its a good idea. Faster rebuilds & tests are always desirable

thx


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

Freedom in capitalist society always remains about the same as it was in
ancient Greek republics: Freedom for slave owners. -- Vladimir Lenin


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

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

Re: [FFmpeg-devel] [PATCH] ffmpeg: add packet duration to AVPacket logging

2022-03-14 Thread Paul B Mahol

LGTM, could also be refactored/deduplicated.
___
ffmpeg-devel mailing list
ffmpeg-devel@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] Allow to modify max qp configuration parameter in libvpx without reseting the encoder

2022-03-14 Thread Jan Ekström

On Mon, Mar 14, 2022 at 3:05 PM Danil Chapovalov
 wrote:
>
> ---

Probably something a la

avcodec/libvpxenc: enable dynamic quantizer reconfiguration

?

>  libavcodec/libvpxenc.c | 7 +++
>  1 file changed, 7 insertions(+)
>
> diff --git a/libavcodec/libvpxenc.c b/libavcodec/libvpxenc.c
> index 8f94ba15dc..45baeed435 100644
> --- a/libavcodec/libvpxenc.c
> +++ b/libavcodec/libvpxenc.c
> @@ -1658,6 +1658,13 @@ static int vpx_encode(AVCodecContext *avctx, AVPacket 
> *pkt,
>  flags |= strtoul(en->value, NULL, 10);
>  }
>
> +en = av_dict_get(frame->metadata, "max-quantizer", NULL, 0);
> +if (en) {
> +struct vpx_codec_enc_cfg cfg = *enccfg;
> +cfg.rc_max_quantizer = strtoul(en->value, NULL, 10);
> +vpx_codec_enc_config_set(&ctx->encoder, &cfg);
> +}
> +

There is side data already defined for quantizers, AVVideoEncParams /
AV_FRAME_DATA_VIDEO_ENC_PARAMS .

In other words, this should be handled in a similar manner to ROI, not
as an ad-hoc metadata key in the AVFrame.

Cheers,
Jan
___
ffmpeg-devel mailing list
ffmpeg-devel@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/2] avformat/movenc: initialize pts/dts of timecode packet

2022-03-14 Thread lance . lmwang

From: Limin Wang 

Fix below error message when timecode packet is written.
"Application provided duration: -9223372036854775808 / timestamp: 
-9223372036854775808 is out of range for mov/mp4 format"

try to reproduce by:
ffmpeg -y -f lavfi -i color -metadata "timecode=00:00:00:00" -t 1 test.mov

Note although error message is printed, the timecode packet will be written 
anyway. So
the patch 2/2 will try to change the log level to warning.

Fixes ticket #9488

Signed-off-by: Limin Wang 
---
 libavformat/movenc.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/libavformat/movenc.c b/libavformat/movenc.c
index ee1629d..436ceb8 100644
--- a/libavformat/movenc.c
+++ b/libavformat/movenc.c
@@ -6356,6 +6356,7 @@ static int mov_create_timecode_track(AVFormatContext *s, 
int index, int src_inde
 pkt->data = data;
 pkt->stream_index = index;
 pkt->flags = AV_PKT_FLAG_KEY;
+pkt->pts = pkt->dts = av_rescale_q(tc.start, av_inv_q(rate), 
(AVRational){1,mov->movie_timescale});
 pkt->size = 4;
 AV_WB32(pkt->data, tc.start);
 ret = ff_mov_write_packet(s, pkt);
-- 
1.8.3.1

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

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

[FFmpeg-devel] [PATCH v2 2/2] avformat/movenc: use warning log level and small adjustment for the log

2022-03-14 Thread lance . lmwang

From: Limin Wang 

Signed-off-by: Limin Wang 
---
 libavformat/movenc.c | 5 ++---
 1 file changed, 2 insertions(+), 3 deletions(-)

diff --git a/libavformat/movenc.c b/libavformat/movenc.c
index 436ceb8..d0072f5 100644
--- a/libavformat/movenc.c
+++ b/libavformat/movenc.c
@@ -5638,9 +5638,8 @@ static int check_pkt(AVFormatContext *s, AVPacket *pkt)
 
 duration = pkt->dts - ref;
 if (pkt->dts < ref || duration >= INT_MAX) {
-av_log(s, AV_LOG_ERROR, "Application provided duration: %"PRId64" / 
timestamp: %"PRId64" is out of range for mov/mp4 format\n",
-duration, pkt->dts
-);
+av_log(s, AV_LOG_WARNING, "Packet duration: %"PRId64" / dts: %"PRId64" 
is out of range\n",
+   duration, pkt->dts);
 
 pkt->dts = ref + 1;
 pkt->pts = AV_NOPTS_VALUE;
-- 
1.8.3.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 v2] avcodec: Add dv marker bsf

2022-03-14 Thread Dave Rice




> On Mar 12, 2022, at 1:09 PM, Michael Niedermayer  
> wrote:
> 
> On Sat, Mar 12, 2022 at 10:11:52AM -0500, Dave Rice wrote:
>> 
>> 
>>> On Mar 10, 2022, at 4:41 AM, Tobias Rapp  wrote:
>>> 
>>> On 09/03/2022 19:18, Michael Niedermayer wrote:
 Signed-off-by: Michael Niedermayer 
 ---
 doc/bitstream_filters.texi   |  30 
 libavcodec/Makefile  |   1 +
 libavcodec/bitstream_filters.c   |   1 +
 libavcodec/dv_error_marker_bsf.c | 127 +++
 4 files changed, 159 insertions(+)
 create mode 100644 libavcodec/dv_error_marker_bsf.c
 diff --git a/doc/bitstream_filters.texi b/doc/bitstream_filters.texi
 index a0092878c8..8c5d84dceb 100644
 --- a/doc/bitstream_filters.texi
 +++ b/doc/bitstream_filters.texi
 @@ -132,6 +132,36 @@ the header stored in extradata to the key packets:
 ffmpeg -i INPUT -map 0 -flags:v +global_header -c:v libx264 -bsf:v 
 dump_extra out.ts
 @end example
 +@section dv_error_marker
 +
 +Blocks in DV which are marked as damaged are replaced by blocks of the 
 specified color.
 +
 +@table @option
 +@item color
 +The color to replace damaged blocks by
 +@item sta
 +A 16 bit mask which specifies which of the 16 possible error status 
 values are
 +to be replaced by colored blocks. 0xFFFE is the default which replaces 
 all non 0
 +error status values.
 +@table @samp
 +@item ok
 +No error, no concealment
 +@item err
 +Error, No concealment
 +@item res
 +Reserved
 +@item notok
 +Error or concealment
 +@item notres
 +Not reserved
 +@item Aa, Ba, Ca, Ab, Bb, Cb, A, B, C, a, b, erri, erru
 +The specific error status code
 +@end table
 +see page 44-46 or section 5.5 of
 +@url{http://web.archive.org/web/20060927044735/http://www.smpte.org/smpte_store/standards/pdf/s314m.pdf}
 +
 +@end table
 +
 @section eac3_core
 [...]
>>> The filter options look nice to me now. Have not actually tested the 
>>> bitstream filter on DV files, though.
>> 
>> I tested this and this works well for me. Here's a few samples that 
>> demonstrate the filter:
>> 
>> ./ffmpeg -i 
>> https://samples.ffmpeg.org/archive/audio/pcm_s16le/dv+dvvideo+pcm_s16le++dropout.dv
>>   -bsf dv_error_marker=sta=b -f rawvideo -c:v copy - | ffplay -
>> ./ffmpeg -i 
>> https://archive.org/download/DvAnalyzerSampleDvVideoErrorConcealment/DV_Analyzer_Sample_Video_Error_Concealment_original.dv
>>  -bsf dv_error_marker=sta=b -f rawvideo -c:v copy - | ffplay -
> 
> I tested a bit more and it failed with dvcprohd, i have fixed it and will in a
> moment post a version that seems to work with both
> please retest

I retested the new version on variety of DV25 and DV50 content. Looks good to 
me.

> PS: i used some artificially damaged files from fate/dv/
> 
> thx
> 
> [...]
> -- 
> Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
> 
> Good people do not need laws to tell them to act responsibly, while bad
> people will find a way around the laws. -- Plato
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@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 3/4] avformat/mxfdec: Check for avio_read() failure in mxf_read_strong_ref_array()

2022-03-14 Thread Marton Balint





On Mon, 14 Mar 2022, Michael Niedermayer wrote:


On Sun, Mar 13, 2022 at 04:52:25PM +0100, Marton Balint wrote:



On Sun, 13 Mar 2022, Michael Niedermayer wrote:


Signed-off-by: Michael Niedermayer 
---
libavformat/mxfdec.c | 8 +++-
1 file changed, 7 insertions(+), 1 deletion(-)

diff --git a/libavformat/mxfdec.c b/libavformat/mxfdec.c
index d7cdd22c8a..828fc0f9f1 100644
--- a/libavformat/mxfdec.c
+++ b/libavformat/mxfdec.c
@@ -932,6 +932,7 @@ static int mxf_read_cryptographic_context(void *arg, 
AVIOContext *pb, int tag, i

static int mxf_read_strong_ref_array(AVIOContext *pb, UID **refs, int *count)
{
+int64_t ret;
unsigned c = avio_rb32(pb);

//avio_read() used int
@@ -946,7 +947,12 @@ static int mxf_read_strong_ref_array(AVIOContext *pb, UID 
**refs, int *count)
return AVERROR(ENOMEM);
}
avio_skip(pb, 4); /* useless size of objects, always 16 according to specs 
*/
-avio_read(pb, (uint8_t *)*refs, *count * sizeof(UID));
+ret = avio_read(pb, (uint8_t *)*refs, *count * sizeof(UID));
+if (ret != *count * sizeof(UID)) {
+*count = ret < 0 ? 0   : ret / sizeof(UID);





I suggest you hard fail if the read count is not the expected, do not
silently ignore corrupt file.

Regards,
Marton


+return   ret < 0 ? ret : AVERROR_INVALIDDATA;


Does it not hard fail here ?


Yeah, it does, sorry. This extra count calculation confused me... I'd just 
probably set it to 0 in case of a partial read, same as in case of an 
error, but fine either way I guess.


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

[FFmpeg-devel] [PATCH 1/2] avformat/mxfenc: allow more bits for variable part in uuid generation

2022-03-14 Thread Marton Balint

Also make sure we do not change the product UID.

Signed-off-by: Marton Balint 
---
 libavformat/mxfenc.c| 9 +
 tests/ref/fate/copy-trac4914| 2 +-
 tests/ref/fate/mxf-d10-user-comments| 6 +++---
 tests/ref/fate/mxf-opatom-user-comments | 2 +-
 tests/ref/fate/mxf-reel_name| 2 +-
 tests/ref/fate/mxf-user-comments| 2 +-
 tests/ref/fate/time_base| 2 +-
 tests/ref/lavf/mxf  | 6 +++---
 tests/ref/lavf/mxf_d10  | 2 +-
 tests/ref/lavf/mxf_dv25 | 2 +-
 tests/ref/lavf/mxf_dvcpro50 | 2 +-
 tests/ref/lavf/mxf_opatom   | 2 +-
 tests/ref/lavf/mxf_opatom_audio | 2 +-
 13 files changed, 21 insertions(+), 20 deletions(-)

diff --git a/libavformat/mxfenc.c b/libavformat/mxfenc.c
index 1e87dc6111..ba8e7babfb 100644
--- a/libavformat/mxfenc.c
+++ b/libavformat/mxfenc.c
@@ -227,7 +227,8 @@ static const UID mxf_d10_container_uls[] = {
 { 
0x06,0x0E,0x2B,0x34,0x04,0x01,0x01,0x01,0x0D,0x01,0x03,0x01,0x02,0x01,0x06,0x01 
}, // D-10 525/50 NTSC 30mb/s
 };
 
-static const uint8_t uuid_base[]= { 
0xAD,0xAB,0x44,0x24,0x2f,0x25,0x4d,0xc7,0x92,0xff,0x29,0xbd };
+static const uint8_t product_uid[]  = { 
0xAD,0xAB,0x44,0x24,0x2f,0x25,0x4d,0xc7,0x92,0xff,0x29,0xbd,0x00,0x0c,0x00,0x02};
+static const uint8_t uuid_base[]= { 
0xAD,0xAB,0x44,0x24,0x2f,0x25,0x4d,0xc7,0x92,0xff };
 static const uint8_t umid_ul[]  = { 
0x06,0x0A,0x2B,0x34,0x01,0x01,0x01,0x05,0x01,0x01,0x0D,0x00,0x13 };
 
 /**
@@ -424,9 +425,9 @@ typedef struct MXFContext {
 
 static void mxf_write_uuid(AVIOContext *pb, enum MXFMetadataSetType type, int 
value)
 {
-avio_write(pb, uuid_base, 12);
+avio_write(pb, uuid_base, 10);
 avio_wb16(pb, type);
-avio_wb16(pb, value);
+avio_wb32(pb, value);
 }
 
 static void mxf_write_umid(AVFormatContext *s, int type)
@@ -797,7 +798,7 @@ static void mxf_write_identification(AVFormatContext *s)
 
 // write product uid
 mxf_write_local_tag(s, 16, 0x3C05);
-mxf_write_uuid(pb, Identification, 2);
+avio_write(pb, product_uid, 16);
 
 // modification date
 mxf_write_local_tag(s, 8, 0x3C06);
diff --git a/tests/ref/fate/copy-trac4914 b/tests/ref/fate/copy-trac4914
index 743dc8c055..0ed039bf37 100644
--- a/tests/ref/fate/copy-trac4914
+++ b/tests/ref/fate/copy-trac4914
@@ -1,4 +1,4 @@
-f5150fb82c1bb5a90906fce93dcc3f76 *tests/data/fate/copy-trac4914.mxf
+a0f68fa1d9ed5d3030d8244ea0b0299a *tests/data/fate/copy-trac4914.mxf
 561721 tests/data/fate/copy-trac4914.mxf
 #tb 0: 1001/3
 #media_type 0: video
diff --git a/tests/ref/fate/mxf-d10-user-comments 
b/tests/ref/fate/mxf-d10-user-comments
index 64a2dec463..1b59beec7c 100644
--- a/tests/ref/fate/mxf-d10-user-comments
+++ b/tests/ref/fate/mxf-d10-user-comments
@@ -1,4 +1,4 @@
-6dc13ae283257e898e069e5041ac8435 *tests/data/fate/mxf-d10-user-comments.mxf_d10
+8c831b8e01aa4c86e98ab87930d06f3e *tests/data/fate/mxf-d10-user-comments.mxf_d10
 3782189 tests/data/fate/mxf-d10-user-comments.mxf_d10
 #extradata 0:   34, 0x716b05c4
 #tb 0: 1/25
@@ -13,8 +13,8 @@
 0,  3,  4,1,   15, 0x9bbe6feb, F=0x0
 [FORMAT]
 TAG:operational_pattern_ul=060e2b34.04010101.0d010201.01010900
-TAG:uid=adab4424-2f25-4dc7-92ff-29bd000c
-TAG:generation_uid=adab4424-2f25-4dc7-92ff-29bd000c0001
+TAG:uid=adab4424-2f25-4dc7-92ff-000c
+TAG:generation_uid=adab4424-2f25-4dc7-92ff-000c0001
 TAG:company_name=FATE-company
 TAG:product_name=FATE-test
 TAG:product_version_num=0.0.0.0.0
diff --git a/tests/ref/fate/mxf-opatom-user-comments 
b/tests/ref/fate/mxf-opatom-user-comments
index ec4fdff425..14a1cee1f2 100644
--- a/tests/ref/fate/mxf-opatom-user-comments
+++ b/tests/ref/fate/mxf-opatom-user-comments
@@ -1 +1 @@
-8475bebf3448a972ae89ba59309fd7d6
+d40b64e492133c74faa07e605eb65b2f
diff --git a/tests/ref/fate/mxf-reel_name b/tests/ref/fate/mxf-reel_name
index d50f0f6990..f3bafcc118 100644
--- a/tests/ref/fate/mxf-reel_name
+++ b/tests/ref/fate/mxf-reel_name
@@ -1 +1 @@
-ce49a0361d3f79106e1952d387eace51
+75e0ac14d5632d709bd805f1cacb1fbb
diff --git a/tests/ref/fate/mxf-user-comments b/tests/ref/fate/mxf-user-comments
index 5fcdc5806a..b4c78744b0 100644
--- a/tests/ref/fate/mxf-user-comments
+++ b/tests/ref/fate/mxf-user-comments
@@ -1 +1 @@
-956f653cd75e1a319569caec9df81b4f
+620ae205fefbb6dba74418f357a62c36
diff --git a/tests/ref/fate/time_base b/tests/ref/fate/time_base
index 28815d0828..fd6cac53fc 100644
--- a/tests/ref/fate/time_base
+++ b/tests/ref/fate/time_base
@@ -1 +1 @@
-78ac0348027b75d73acb8bea14e67a59
+d408aba82d62a90ed7f46a1999b014f1
diff --git a/tests/ref/lavf/mxf b/tests/ref/lavf/mxf
index 21bf2be513..3f0c74818a 100644
--- a/tests/ref/lavf/mxf
+++ b/tests/ref/lavf/mxf
@@ -1,9 +1,9 @@
-8938d5c4a396ff1b24d10d4f917ae1c9 *tests/data/lavf/lavf.mxf
+9ec1ad83b3400de11ca2f70b3b2d4c4d *tests/data/lavf/lavf.mxf
 526393 tests/data/lavf/lavf.mxf
 tes

[FFmpeg-devel] [PATCH 2/2] avformat/mxfenc: do not write index tables with the same InstanceUID

2022-03-14 Thread Marton Balint

Only index tables repeating previous index tables should use the same
InstaceUID. Use the index start position when generating the InstanceUID to fix
this.

Signed-off-by: Marton Balint 
---
 libavformat/mxfenc.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/libavformat/mxfenc.c b/libavformat/mxfenc.c
index ba8e7babfb..5b972eadaa 100644
--- a/libavformat/mxfenc.c
+++ b/libavformat/mxfenc.c
@@ -1757,7 +1757,7 @@ static void mxf_write_index_table_segment(AVFormatContext 
*s)
 
 // instance id
 mxf_write_local_tag(s, 16, 0x3C0A);
-mxf_write_uuid(pb, IndexTableSegment, 0);
+mxf_write_uuid(pb, IndexTableSegment, mxf->last_indexed_edit_unit);
 
 // index edit rate
 mxf_write_local_tag(s, 8, 0x3F0B);
-- 
2.31.1

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

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

Re: [FFmpeg-devel] [PATCH v2] avcodec: Add dv marker bsf

2022-03-14 Thread Michael Niedermayer

On Mon, Mar 14, 2022 at 12:04:46PM -0400, Dave Rice wrote:
> 
> 
> > On Mar 12, 2022, at 1:09 PM, Michael Niedermayer  
> > wrote:
> > 
> > On Sat, Mar 12, 2022 at 10:11:52AM -0500, Dave Rice wrote:
> >> 
> >> 
> >>> On Mar 10, 2022, at 4:41 AM, Tobias Rapp  wrote:
> >>> 
> >>> On 09/03/2022 19:18, Michael Niedermayer wrote:
>  Signed-off-by: Michael Niedermayer 
>  ---
>  doc/bitstream_filters.texi   |  30 
>  libavcodec/Makefile  |   1 +
>  libavcodec/bitstream_filters.c   |   1 +
>  libavcodec/dv_error_marker_bsf.c | 127 +++
>  4 files changed, 159 insertions(+)
>  create mode 100644 libavcodec/dv_error_marker_bsf.c
>  diff --git a/doc/bitstream_filters.texi b/doc/bitstream_filters.texi
>  index a0092878c8..8c5d84dceb 100644
>  --- a/doc/bitstream_filters.texi
>  +++ b/doc/bitstream_filters.texi
>  @@ -132,6 +132,36 @@ the header stored in extradata to the key packets:
>  ffmpeg -i INPUT -map 0 -flags:v +global_header -c:v libx264 -bsf:v 
>  dump_extra out.ts
>  @end example
>  +@section dv_error_marker
>  +
>  +Blocks in DV which are marked as damaged are replaced by blocks of the 
>  specified color.
>  +
>  +@table @option
>  +@item color
>  +The color to replace damaged blocks by
>  +@item sta
>  +A 16 bit mask which specifies which of the 16 possible error status 
>  values are
>  +to be replaced by colored blocks. 0xFFFE is the default which replaces 
>  all non 0
>  +error status values.
>  +@table @samp
>  +@item ok
>  +No error, no concealment
>  +@item err
>  +Error, No concealment
>  +@item res
>  +Reserved
>  +@item notok
>  +Error or concealment
>  +@item notres
>  +Not reserved
>  +@item Aa, Ba, Ca, Ab, Bb, Cb, A, B, C, a, b, erri, erru
>  +The specific error status code
>  +@end table
>  +see page 44-46 or section 5.5 of
>  +@url{http://web.archive.org/web/20060927044735/http://www.smpte.org/smpte_store/standards/pdf/s314m.pdf}
>  +
>  +@end table
>  +
>  @section eac3_core
>  [...]
> >>> The filter options look nice to me now. Have not actually tested the 
> >>> bitstream filter on DV files, though.
> >> 
> >> I tested this and this works well for me. Here's a few samples that 
> >> demonstrate the filter:
> >> 
> >> ./ffmpeg -i 
> >> https://samples.ffmpeg.org/archive/audio/pcm_s16le/dv+dvvideo+pcm_s16le++dropout.dv
> >>   -bsf dv_error_marker=sta=b -f rawvideo -c:v copy - | ffplay -
> >> ./ffmpeg -i 
> >> https://archive.org/download/DvAnalyzerSampleDvVideoErrorConcealment/DV_Analyzer_Sample_Video_Error_Concealment_original.dv
> >>  -bsf dv_error_marker=sta=b -f rawvideo -c:v copy - | ffplay -
> > 
> > I tested a bit more and it failed with dvcprohd, i have fixed it and will 
> > in a
> > moment post a version that seems to work with both
> > please retest
> 
> I retested the new version on variety of DV25 and DV50 content. Looks good to 
> me.

will apply

thx

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

"Nothing to hide" only works if the folks in power share the values of
you and everyone you know entirely and always will -- Tom Scott



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/3] tools/target_dec_fuzzer: Adjust threshold for DFA

2022-03-14 Thread Michael Niedermayer

On Fri, Mar 11, 2022 at 09:20:24PM +0100, Michael Niedermayer wrote:
> Fixes: Timeout
> Fixes: 
> 45351/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_DFA_fuzzer-5768895011618816
> 
> Found-by: continuous fuzzing process 
> https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
> Signed-off-by: Michael Niedermayer 
> ---
>  tools/target_dec_fuzzer.c | 1 +
>  1 file changed, 1 insertion(+)

will apply

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

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


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

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

[FFmpeg-devel] [PATCH] avfilter/vf_subtitles: pass storage size to libass

2022-03-14 Thread Oneric

Due to a quirk of the ASS format some tags depend on the exact storage
resolution of the video, so tell libass via ass_set_storage_size.

---
ass_set_storage_size exists since libass 0.10.2;
ffmpeg since 5.0 already requires 0.11.0.

This resolution dependences of ASS was already recognised when the
original_size parameter was added, but it actually goes farther than
just the aspect ratio. Conveniently this parameter still has all the
required information to retain rendering after resizing :)

Sample files to show the difference can be found eg here
https://code.videolan.org/videolan/vlc/uploads/b54e0761d0d3f4f79b2947ffb83a3b59/vlc-issue_libass-storage-size.tar.xz

./ffmpeg -i test_1080p.mkv -filter:v ass=./test_1080p.ass tmp_1080.mkv
./ffmpeg -i anamorphic_s720x576_d1024x576.mkv -filter:v 
ass=./anamorphic_s720x576_d1024x576.ass tmp_anam.mkv

---
 libavfilter/vf_subtitles.c | 7 ++-
 1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/libavfilter/vf_subtitles.c b/libavfilter/vf_subtitles.c
index 3fc4eeb63d..af6352b315 100644
--- a/libavfilter/vf_subtitles.c
+++ b/libavfilter/vf_subtitles.c
@@ -146,9 +146,14 @@ static int config_input(AVFilterLink *inlink)
 ff_draw_init(&ass->draw, inlink->format, ass->alpha ? 
FF_DRAW_PROCESS_ALPHA : 0);
 
 ass_set_frame_size  (ass->renderer, inlink->w, inlink->h);
-if (ass->original_w && ass->original_h)
+if (ass->original_w && ass->original_h) {
 ass_set_pixel_aspect(ass->renderer, (double)inlink->w / inlink->h /
  ((double)ass->original_w / ass->original_h));
+ass_set_storage_size(ass->renderer, ass->original_w, ass->original_h);
+} else {
+ass_set_storage_size(ass->renderer, inlink->w, inlink->h);
+}
+
 if (ass->shaping != -1)
 ass_set_shaper(ass->renderer, ass->shaping);
 
-- 
2.30.2

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

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

Re: [FFmpeg-devel] [PATCH 2/4] avformat/mxfdec: Check count in mxf_read_strong_ref_array()

2022-03-14 Thread Tomas Härdin

sön 2022-03-13 klockan 00:52 +0100 skrev Michael Niedermayer:
> Signed-off-by: Michael Niedermayer 
> ---
>  libavformat/mxfdec.c | 8 +++-
>  1 file changed, 7 insertions(+), 1 deletion(-)
> 
> diff --git a/libavformat/mxfdec.c b/libavformat/mxfdec.c
> index b85c10bf19..d7cdd22c8a 100644
> --- a/libavformat/mxfdec.c
> +++ b/libavformat/mxfdec.c
> @@ -932,7 +932,13 @@ static int mxf_read_cryptographic_context(void
> *arg, AVIOContext *pb, int tag, i
>  
>  static int mxf_read_strong_ref_array(AVIOContext *pb, UID **refs,
> int *count)
>  {
> -    *count = avio_rb32(pb);
> +    unsigned c = avio_rb32(pb);

not uint32_t?

> +
> +    //avio_read() used int
> +    if (c > INT_MAX / sizeof(UID))
> +    return AVERROR_PATCHWELCOME;
> +    *count = c;
> +

This should already be caught by av_calloc(), no?

/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 3/4] avformat/mxfdec: Check for avio_read() failure in mxf_read_strong_ref_array()

2022-03-14 Thread Tomas Härdin

sön 2022-03-13 klockan 00:52 +0100 skrev Michael Niedermayer:
> Signed-off-by: Michael Niedermayer 
> ---
>  libavformat/mxfdec.c | 8 +++-
>  1 file changed, 7 insertions(+), 1 deletion(-)
> 
> diff --git a/libavformat/mxfdec.c b/libavformat/mxfdec.c
> index d7cdd22c8a..828fc0f9f1 100644
> --- a/libavformat/mxfdec.c
> +++ b/libavformat/mxfdec.c
> @@ -932,6 +932,7 @@ static int mxf_read_cryptographic_context(void
> *arg, AVIOContext *pb, int tag, i
>  
>  static int mxf_read_strong_ref_array(AVIOContext *pb, UID **refs,
> int *count)
>  {
> +    int64_t ret;
>  unsigned c = avio_rb32(pb);
>  
>  //avio_read() used int
> @@ -946,7 +947,12 @@ static int mxf_read_strong_ref_array(AVIOContext
> *pb, UID **refs, int *count)
>  return AVERROR(ENOMEM);
>  }
>  avio_skip(pb, 4); /* useless size of objects, always 16
> according to specs */
> -    avio_read(pb, (uint8_t *)*refs, *count * sizeof(UID));
> +    ret = avio_read(pb, (uint8_t *)*refs, *count * sizeof(UID));
> +    if (ret != *count * sizeof(UID)) {
> +    *count = ret < 0 ? 0   : ret / sizeof(UID);
> +    return   ret < 0 ? ret : AVERROR_INVALIDDATA;

Looks ok

/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] avfilter/vf_subtitles: pass storage size to libass

2022-03-14 Thread Soft Works




> -Original Message-
> From: ffmpeg-devel  On Behalf Of Oneric
> Sent: Monday, March 14, 2022 8:07 PM
> To: ffmpeg-devel@ffmpeg.org
> Cc: Oneric 
> Subject: [FFmpeg-devel] [PATCH] avfilter/vf_subtitles: pass storage size
> to libass
> 
> Due to a quirk of the ASS format some tags depend on the exact storage
> resolution of the video, so tell libass via ass_set_storage_size.
> 
> ---
> ass_set_storage_size exists since libass 0.10.2;
> ffmpeg since 5.0 already requires 0.11.0.
> 
> This resolution dependences of ASS was already recognised when the
> original_size parameter was added, but it actually goes farther than
> just the aspect ratio. Conveniently this parameter still has all the
> required information to retain rendering after resizing :)
> 
> Sample files to show the difference can be found eg here
> https://code.videolan.org/videolan/vlc/uploads/b54e0761d0d3f4f79b2947ffb83
> a3b59/vlc-issue_libass-storage-size.tar.xz
> 
> ./ffmpeg -i test_1080p.mkv -filter:v ass=./test_1080p.ass tmp_1080.mkv
> ./ffmpeg -i anamorphic_s720x576_d1024x576.mkv -filter:v
> ass=./anamorphic_s720x576_d1024x576.ass tmp_anam.mkv
> 
> ---
>  libavfilter/vf_subtitles.c | 7 ++-
>  1 file changed, 6 insertions(+), 1 deletion(-)
> 
> diff --git a/libavfilter/vf_subtitles.c b/libavfilter/vf_subtitles.c
> index 3fc4eeb63d..af6352b315 100644
> --- a/libavfilter/vf_subtitles.c
> +++ b/libavfilter/vf_subtitles.c
> @@ -146,9 +146,14 @@ static int config_input(AVFilterLink *inlink)
>  ff_draw_init(&ass->draw, inlink->format, ass->alpha ?
> FF_DRAW_PROCESS_ALPHA : 0);
> 
>  ass_set_frame_size  (ass->renderer, inlink->w, inlink->h);
> -if (ass->original_w && ass->original_h)
> +if (ass->original_w && ass->original_h) {
>  ass_set_pixel_aspect(ass->renderer, (double)inlink->w / inlink->h
> /
>   ((double)ass->original_w / ass-
> >original_h));
> +ass_set_storage_size(ass->renderer, ass->original_w, ass-
> >original_h);
> +} else {
> +ass_set_storage_size(ass->renderer, inlink->w, inlink->h);
> +}
> +
>  if (ass->shaping != -1)
>  ass_set_shaper(ass->renderer, ass->shaping);
> 

Hi,

thanks for the patch!

I've been at the same point some time ago where I wondered why ffmpeg is
not setting this, but then I had found that it is overridden by the call 
to ass_set_pixel_aspect().

ass_set_pixel_aspect() is setting settings.par and if I'm not mistaken,
an existing par setting leads to the storage size setting to be ignored:

https://github.com/libass/libass/blob/5f0e8450f834894b2745238e3d32ff4878710ec8/libass/ass_render.c#L2891-L2903

But perhaps I'm missing something..

softworkz

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

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

Re: [FFmpeg-devel] [PATCH 1/2] avformat/mxfenc: allow more bits for variable part in uuid generation

2022-03-14 Thread Tomas Härdin

mån 2022-03-14 klockan 19:49 +0100 skrev Marton Balint:
> Also make sure we do not change the product UID.
> 
> Signed-off-by: Marton Balint 
> ---
>  libavformat/mxfenc.c    | 9 +
>  tests/ref/fate/copy-trac4914    | 2 +-
>  tests/ref/fate/mxf-d10-user-comments    | 6 +++---
>  tests/ref/fate/mxf-opatom-user-comments | 2 +-
>  tests/ref/fate/mxf-reel_name    | 2 +-
>  tests/ref/fate/mxf-user-comments    | 2 +-
>  tests/ref/fate/time_base    | 2 +-
>  tests/ref/lavf/mxf  | 6 +++---
>  tests/ref/lavf/mxf_d10  | 2 +-
>  tests/ref/lavf/mxf_dv25 | 2 +-
>  tests/ref/lavf/mxf_dvcpro50 | 2 +-
>  tests/ref/lavf/mxf_opatom   | 2 +-
>  tests/ref/lavf/mxf_opatom_audio | 2 +-
>  13 files changed, 21 insertions(+), 20 deletions(-)
> 
> diff --git a/libavformat/mxfenc.c b/libavformat/mxfenc.c
> index 1e87dc6111..ba8e7babfb 100644
> --- a/libavformat/mxfenc.c
> +++ b/libavformat/mxfenc.c
> @@ -227,7 +227,8 @@ static const UID mxf_d10_container_uls[] = {
>  {
> 0x06,0x0E,0x2B,0x34,0x04,0x01,0x01,0x01,0x0D,0x01,0x03,0x01,0x02,0x01
> ,0x06,0x01 }, // D-10 525/50 NTSC 30mb/s
>  };
>  
> -static const uint8_t uuid_base[]    = {
> 0xAD,0xAB,0x44,0x24,0x2f,0x25,0x4d,0xc7,0x92,0xff,0x29,0xbd };
> +static const uint8_t product_uid[]  = {
> 0xAD,0xAB,0x44,0x24,0x2f,0x25,0x4d,0xc7,0x92,0xff,0x29,0xbd,0x00,0x0c
> ,0x00,0x02};

Maybe use Identification instead of 0x0C.

> +static const uint8_t uuid_base[]    = {
> 0xAD,0xAB,0x44,0x24,0x2f,0x25,0x4d,0xc7,0x92,0xff };
>  static const uint8_t umid_ul[]  = {
> 0x06,0x0A,0x2B,0x34,0x01,0x01,0x01,0x05,0x01,0x01,0x0D,0x00,0x13 };
>  
>  /**
> @@ -424,9 +425,9 @@ typedef struct MXFContext {
>  
>  static void mxf_write_uuid(AVIOContext *pb, enum MXFMetadataSetType
> type, int value)
>  {
> -    avio_write(pb, uuid_base, 12);
> +    avio_write(pb, uuid_base, 10);
>  avio_wb16(pb, type);
> -    avio_wb16(pb, value);
> +    avio_wb32(pb, value);
>  }
>  
>  static void mxf_write_umid(AVFormatContext *s, int type)
> @@ -797,7 +798,7 @@ static void
> mxf_write_identification(AVFormatContext *s)
>  
>  // write product uid
>  mxf_write_local_tag(s, 16, 0x3C05);
> -    mxf_write_uuid(pb, Identification, 2);
> +    avio_write(pb, product_uid, 16);

For those wondering, the purpose of this not using mxf_write_uuid() is
likely to keep ProductUID the same after this patch. This is of course
good if a bit ugly since the calls with 0 and 1 are still there. Oh
well.

/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 2/2] avformat/mxfenc: do not write index tables with the same InstanceUID

2022-03-14 Thread Tomas Härdin

mån 2022-03-14 klockan 19:49 +0100 skrev Marton Balint:
> Only index tables repeating previous index tables should use the same
> InstaceUID. Use the index start position when generating the
> InstanceUID to fix
> this.
> 
> Signed-off-by: Marton Balint 
> ---
>  libavformat/mxfenc.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/libavformat/mxfenc.c b/libavformat/mxfenc.c
> index ba8e7babfb..5b972eadaa 100644
> --- a/libavformat/mxfenc.c
> +++ b/libavformat/mxfenc.c
> @@ -1757,7 +1757,7 @@ static void
> mxf_write_index_table_segment(AVFormatContext *s)
>  
>  // instance id
>  mxf_write_local_tag(s, 16, 0x3C0A);
> -    mxf_write_uuid(pb, IndexTableSegment, 0);
> +    mxf_write_uuid(pb, IndexTableSegment, mxf-
> >last_indexed_edit_unit);

Two things: yes, it is good that this fixes the same InstanceUID being
reused. But more importantly, we should not be writing files with over
65536 partitions!

This has been bugging me for quite some time. Honestly I don't know why
the decision was taken initially to write indices every 10 seconds. In
any use-case where seeks are moderately expensive working with files
produced by mxfenc is a nightmare. Prime example being HTTP.

If we do still need to keep writing partitions this way, can we repeat
the IndexTableSegments in the footer so the entire file doesn't have to
be scanned?

/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] avfilter/vf_subtitles: pass storage size to libass

2022-03-14 Thread Oneric

On Mon, Mar 14, 2022 at 19:35:36 +, Soft Works wrote:
> 
> I've been at the same point some time ago where I wondered why ffmpeg is
> not setting this, but then I had found that it is overridden by the call 
> to ass_set_pixel_aspect().
>
> ass_set_pixel_aspect() is setting settings.par and if I'm not mistaken,
> an existing par setting leads to the storage size setting to be ignored:

It’s not overridden. Only the explicit PAR is currently preferd over the 
implicit derivation from storage and frame size. However as I stated in 
the patch description and the comment:
  “some tags depend on the exact storage resolution of the video”
  “it actually goes farther than just the aspect ratio”

I.e. there's more info in the storage size than just the PAR.
You can also easily test the files I linked to empirically
validate that there is in fact a difference.

> But perhaps I'm missing something..
>
> softworkz
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

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

Re: [FFmpeg-devel] [PATCH 2/2] avformat/mxfenc: do not write index tables with the same InstanceUID

2022-03-14 Thread Marton Balint




On Mon, 14 Mar 2022, Tomas Härdin wrote:


mån 2022-03-14 klockan 19:49 +0100 skrev Marton Balint:

Only index tables repeating previous index tables should use the same
InstaceUID. Use the index start position when generating the
InstanceUID to fix
this.

Signed-off-by: Marton Balint 
---
 libavformat/mxfenc.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/libavformat/mxfenc.c b/libavformat/mxfenc.c
index ba8e7babfb..5b972eadaa 100644
--- a/libavformat/mxfenc.c
+++ b/libavformat/mxfenc.c
@@ -1757,7 +1757,7 @@ static void
mxf_write_index_table_segment(AVFormatContext *s)
 
 // instance id
 mxf_write_local_tag(s, 16, 0x3C0A);
-    mxf_write_uuid(pb, IndexTableSegment, 0);
+    mxf_write_uuid(pb, IndexTableSegment, mxf-
>last_indexed_edit_unit);


Two things: yes, it is good that this fixes the same InstanceUID being
reused. But more importantly, we should not be writing files with over
65536 partitions!


last_indexed_edit_unit is frame based not partition based, so it can 
overflow 65536 realtively easily, that is why I submitted patch 1.




This has been bugging me for quite some time. Honestly I don't know why
the decision was taken initially to write indices every 10 seconds. In
any use-case where seeks are moderately expensive working with files
produced by mxfenc is a nightmare. Prime example being HTTP.


The 10 second body partition limit is coming from some specification 
(XDCAM HD?), so this is kind of intentional.




If we do still need to keep writing partitions this way, can we repeat
the IndexTableSegments in the footer so the entire file doesn't have to
be scanned?


Yeah, that is what smart tools like bmxtools are doing.

Regards,
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] avfilter/vf_subtitles: pass storage size to libass

2022-03-14 Thread Soft Works



> -Original Message-
> From: ffmpeg-devel  On Behalf Of Oneric
> Sent: Monday, March 14, 2022 8:50 PM
> To: FFmpeg development discussions and patches 
> Subject: Re: [FFmpeg-devel] [PATCH] avfilter/vf_subtitles: pass storage
> size to libass
> 
> On Mon, Mar 14, 2022 at 19:35:36 +, Soft Works wrote:
> >
> > I've been at the same point some time ago where I wondered why ffmpeg is
> > not setting this, but then I had found that it is overridden by the call
> > to ass_set_pixel_aspect().
> >
> > ass_set_pixel_aspect() is setting settings.par and if I'm not mistaken,
> > an existing par setting leads to the storage size setting to be ignored:
> 
> It’s not overridden. Only the explicit PAR is currently preferd over the
> implicit derivation from storage and frame size. However as I stated in
> the patch description and the comment:
>   “some tags depend on the exact storage resolution of the video”
>   “it actually goes farther than just the aspect ratio”
> 

I found only one other place where storage_h is used (for determining 
blur size) but I didn't find any other usage in the libass source code.
That's what I'm wondering about.

Thanks,
sw


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

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

Re: [FFmpeg-devel] [PATCH 1/2] avformat/mxfenc: allow more bits for variable part in uuid generation

2022-03-14 Thread Marton Balint




On Mon, 14 Mar 2022, Tomas Härdin wrote:


mån 2022-03-14 klockan 19:49 +0100 skrev Marton Balint:

Also make sure we do not change the product UID.

Signed-off-by: Marton Balint 
---
 libavformat/mxfenc.c    | 9 +
 tests/ref/fate/copy-trac4914    | 2 +-
 tests/ref/fate/mxf-d10-user-comments    | 6 +++---
 tests/ref/fate/mxf-opatom-user-comments | 2 +-
 tests/ref/fate/mxf-reel_name    | 2 +-
 tests/ref/fate/mxf-user-comments    | 2 +-
 tests/ref/fate/time_base    | 2 +-
 tests/ref/lavf/mxf  | 6 +++---
 tests/ref/lavf/mxf_d10  | 2 +-
 tests/ref/lavf/mxf_dv25 | 2 +-
 tests/ref/lavf/mxf_dvcpro50 | 2 +-
 tests/ref/lavf/mxf_opatom   | 2 +-
 tests/ref/lavf/mxf_opatom_audio | 2 +-
 13 files changed, 21 insertions(+), 20 deletions(-)

diff --git a/libavformat/mxfenc.c b/libavformat/mxfenc.c
index 1e87dc6111..ba8e7babfb 100644
--- a/libavformat/mxfenc.c
+++ b/libavformat/mxfenc.c
@@ -227,7 +227,8 @@ static const UID mxf_d10_container_uls[] = {
 {
0x06,0x0E,0x2B,0x34,0x04,0x01,0x01,0x01,0x0D,0x01,0x03,0x01,0x02,0x01
,0x06,0x01 }, // D-10 525/50 NTSC 30mb/s
 };
 
-static const uint8_t uuid_base[]    = {
0xAD,0xAB,0x44,0x24,0x2f,0x25,0x4d,0xc7,0x92,0xff,0x29,0xbd };
+static const uint8_t product_uid[]  = {
0xAD,0xAB,0x44,0x24,0x2f,0x25,0x4d,0xc7,0x92,0xff,0x29,0xbd,0x00,0x0c
,0x00,0x02};


Maybe use Identification instead of 0x0C.


Actually I'd rather keep it 0x0C, Identification value might change (if 
MXFMetadataSetType enum is reordered in mxf.h), and we don't want 
ProductUID to change even then...


Thanks,
Marton




+static const uint8_t uuid_base[]    = {
0xAD,0xAB,0x44,0x24,0x2f,0x25,0x4d,0xc7,0x92,0xff };
 static const uint8_t umid_ul[]  = {
0x06,0x0A,0x2B,0x34,0x01,0x01,0x01,0x05,0x01,0x01,0x0D,0x00,0x13 };
 
 /**
@@ -424,9 +425,9 @@ typedef struct MXFContext {
 
 static void mxf_write_uuid(AVIOContext *pb, enum MXFMetadataSetType
type, int value)
 {
-    avio_write(pb, uuid_base, 12);
+    avio_write(pb, uuid_base, 10);
 avio_wb16(pb, type);
-    avio_wb16(pb, value);
+    avio_wb32(pb, value);
 }
 
 static void mxf_write_umid(AVFormatContext *s, int type)
@@ -797,7 +798,7 @@ static void
mxf_write_identification(AVFormatContext *s)
 
 // write product uid
 mxf_write_local_tag(s, 16, 0x3C05);
-    mxf_write_uuid(pb, Identification, 2);
+    avio_write(pb, product_uid, 16);


For those wondering, the purpose of this not using mxf_write_uuid() is
likely to keep ProductUID the same after this patch. This is of course
good if a bit ugly since the calls with 0 and 1 are still there. Oh
well.

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

Re: [FFmpeg-devel] [PATCH] avfilter/vf_subtitles: pass storage size to libass

2022-03-14 Thread Oneric

On Mon, Mar 14, 2022 at 19:57:05 +, Soft Works wrote:
> > > ass_set_pixel_aspect() is setting settings.par and if I'm not mistaken,
> > > an existing par setting leads to the storage size setting to be ignored:
> > 
> > It’s not overridden. Only the explicit PAR is currently preferd over the
> > implicit derivation from storage and frame size. However as I stated in
> > the patch description and the comment:
> >   “some tags depend on the exact storage resolution of the video”
> >   “it actually goes farther than just the aspect ratio”
> > 
> 
> I found only one other place where storage_h is used (for determining 
> blur size) but I didn't find any other usage in the libass source code.
> That's what I'm wondering about.

Well, blur is one of the things that depend on it. If you follow the usage 
of the blur scale, you'll see it also plays a role in the projection 
matrix for 3D-transforms (what the provided samples use) and if 
ScaledBorderAndShadow is not set to "yes", it also affects some other 
scaling values.

This unfortunate dependence is a result of how SSA and then ASS 
histoically developed and required to maintain compaitibility with 
existing subtitles.
___
ffmpeg-devel mailing list
ffmpeg-devel@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: add chromashift tests

2022-03-14 Thread Paul B Mahol

Signed-off-by: Paul B Mahol 
---
 tests/fate/filter-video.mak |  4 
 tests/ref/fate/filter-chromashift-smear | 10 ++
 tests/ref/fate/filter-chromashift-wrap  | 10 ++
 3 files changed, 24 insertions(+)
 create mode 100644 tests/ref/fate/filter-chromashift-smear
 create mode 100644 tests/ref/fate/filter-chromashift-wrap

diff --git a/tests/fate/filter-video.mak b/tests/fate/filter-video.mak
index cd33361880..d53922 100644
--- a/tests/fate/filter-video.mak
+++ b/tests/fate/filter-video.mak
@@ -451,6 +451,10 @@ fate-filter-concat: CMD = framecrc -filter_complex_script 
$(TARGET_PATH)/tests/d
 fate-filter-concat-vfr: tests/data/filtergraphs/concat-vfr
 fate-filter-concat-vfr: CMD = framecrc -filter_complex_script 
$(TARGET_PATH)/tests/data/filtergraphs/concat-vfr
 
+FATE_FILTER-$(call ALLYES, TESTSRC2_FILTER CHROMASHIFT_FILTER) += 
fate-filter-chromashift-smear fate-filter-chromashift-wrap
+fate-filter-chromashift-smear: CMD = framecrc -lavfi 
testsrc2=r=5:d=1,chromashift=cbh=-1:cbv=1:crh=2:crv=-2:edge=smear -pix_fmt 
yuv420p
+fate-filter-chromashift-wrap:  CMD = framecrc -lavfi 
testsrc2=r=5:d=1,chromashift=cbh=-1:cbv=1:crh=2:crv=-2:edge=wrap  -pix_fmt 
yuv420p
+
 FATE_FILTER-$(call ALLYES, TESTSRC2_FILTER FPS_FILTER DECIMATE_FILTER) += 
fate-filter-decimate
 fate-filter-decimate: CMD = framecrc -lavfi 
testsrc2=r=24:d=10,fps=60,decimate=5,decimate=4,decimate=3 -pix_fmt yuv420p
 
diff --git a/tests/ref/fate/filter-chromashift-smear 
b/tests/ref/fate/filter-chromashift-smear
new file mode 100644
index 00..e5651c0f94
--- /dev/null
+++ b/tests/ref/fate/filter-chromashift-smear
@@ -0,0 +1,10 @@
+#tb 0: 1/5
+#media_type 0: video
+#codec_id 0: rawvideo
+#dimensions 0: 320x240
+#sar 0: 1/1
+0,  0,  0,1,   115200, 0x91a39b4c
+0,  1,  1,1,   115200, 0xe2ff7f63
+0,  2,  2,1,   115200, 0x242f7a20
+0,  3,  3,1,   115200, 0x4f7c95a9
+0,  4,  4,1,   115200, 0xee6e9daa
diff --git a/tests/ref/fate/filter-chromashift-wrap 
b/tests/ref/fate/filter-chromashift-wrap
new file mode 100644
index 00..3ce663ac1c
--- /dev/null
+++ b/tests/ref/fate/filter-chromashift-wrap
@@ -0,0 +1,10 @@
+#tb 0: 1/5
+#media_type 0: video
+#codec_id 0: rawvideo
+#dimensions 0: 320x240
+#sar 0: 1/1
+0,  0,  0,1,   115200, 0x2b9db3ed
+0,  1,  1,1,   115200, 0xebb7987c
+0,  2,  2,1,   115200, 0xee1a9331
+0,  3,  3,1,   115200, 0xf4f5aeb2
+0,  4,  4,1,   115200, 0x7b66b6b3
-- 
2.33.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] avformat/mxfenc: allow more bits for variable part in uuid generation

2022-03-14 Thread Tomas Härdin

mån 2022-03-14 klockan 20:57 +0100 skrev Marton Balint:
> 
> 
> On Mon, 14 Mar 2022, Tomas Härdin wrote:
> 
> > mån 2022-03-14 klockan 19:49 +0100 skrev Marton Balint:
> > > Also make sure we do not change the product UID.
> > > 
> > > Signed-off-by: Marton Balint 
> > > ---
> > >  libavformat/mxfenc.c    | 9 +
> > >  tests/ref/fate/copy-trac4914    | 2 +-
> > >  tests/ref/fate/mxf-d10-user-comments    | 6 +++---
> > >  tests/ref/fate/mxf-opatom-user-comments | 2 +-
> > >  tests/ref/fate/mxf-reel_name    | 2 +-
> > >  tests/ref/fate/mxf-user-comments    | 2 +-
> > >  tests/ref/fate/time_base    | 2 +-
> > >  tests/ref/lavf/mxf  | 6 +++---
> > >  tests/ref/lavf/mxf_d10  | 2 +-
> > >  tests/ref/lavf/mxf_dv25 | 2 +-
> > >  tests/ref/lavf/mxf_dvcpro50 | 2 +-
> > >  tests/ref/lavf/mxf_opatom   | 2 +-
> > >  tests/ref/lavf/mxf_opatom_audio | 2 +-
> > >  13 files changed, 21 insertions(+), 20 deletions(-)
> > > 
> > > diff --git a/libavformat/mxfenc.c b/libavformat/mxfenc.c
> > > index 1e87dc6111..ba8e7babfb 100644
> > > --- a/libavformat/mxfenc.c
> > > +++ b/libavformat/mxfenc.c
> > > @@ -227,7 +227,8 @@ static const UID mxf_d10_container_uls[] = {
> > >  {
> > > 0x06,0x0E,0x2B,0x34,0x04,0x01,0x01,0x01,0x0D,0x01,0x03,0x01,0x02,
> > > 0x01
> > > ,0x06,0x01 }, // D-10 525/50 NTSC 30mb/s
> > >  };
> > >  
> > > -static const uint8_t uuid_base[]    = {
> > > 0xAD,0xAB,0x44,0x24,0x2f,0x25,0x4d,0xc7,0x92,0xff,0x29,0xbd };
> > > +static const uint8_t product_uid[]  = {
> > > 0xAD,0xAB,0x44,0x24,0x2f,0x25,0x4d,0xc7,0x92,0xff,0x29,0xbd,0x00,
> > > 0x0c
> > > ,0x00,0x02};
> > 
> > Maybe use Identification instead of 0x0C.
> 
> Actually I'd rather keep it 0x0C, Identification value might change
> (if 
> MXFMetadataSetType enum is reordered in mxf.h), and we don't want 
> ProductUID to change even then...

Good point

/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] avfilter/vf_subtitles: pass storage size to libass

2022-03-14 Thread Soft Works



> -Original Message-
> From: ffmpeg-devel  On Behalf Of Oneric
> Sent: Monday, March 14, 2022 9:08 PM
> To: FFmpeg development discussions and patches 
> Subject: Re: [FFmpeg-devel] [PATCH] avfilter/vf_subtitles: pass storage
> size to libass
> 
> On Mon, Mar 14, 2022 at 19:57:05 +, Soft Works wrote:
> > > > ass_set_pixel_aspect() is setting settings.par and if I'm not
> mistaken,
> > > > an existing par setting leads to the storage size setting to be
> ignored:
> > >
> > > It’s not overridden. Only the explicit PAR is currently preferd over
> the
> > > implicit derivation from storage and frame size. However as I stated
> in
> > > the patch description and the comment:
> > >   “some tags depend on the exact storage resolution of the video”
> > >   “it actually goes farther than just the aspect ratio”
> > >
> >
> > I found only one other place where storage_h is used (for determining
> > blur size) but I didn't find any other usage in the libass source code.
> > That's what I'm wondering about.
> 
> Well, blur is one of the things that depend on it. If you follow the usage
> of the blur scale, you'll see it also plays a role in the projection
> matrix for 3D-transforms (what the provided samples use) and if
> ScaledBorderAndShadow is not set to "yes", it also affects some other
> scaling values.
> 
> This unfortunate dependence is a result of how SSA and then ASS
> histoically developed and required to maintain compaitibility with
> existing subtitles.

Ah, alright, the blur setting goes deeper. Thanks for the explanation.

LGTM, then!

___
ffmpeg-devel mailing list
ffmpeg-devel@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] avformat/mxfenc: do not write index tables with the same InstanceUID

2022-03-14 Thread Tomas Härdin

mån 2022-03-14 klockan 20:54 +0100 skrev Marton Balint:
> 
> 
> On Mon, 14 Mar 2022, Tomas Härdin wrote:
> 
> > mån 2022-03-14 klockan 19:49 +0100 skrev Marton Balint:
> > > Only index tables repeating previous index tables should use the
> > > same
> > > InstaceUID. Use the index start position when generating the
> > > InstanceUID to fix
> > > this.
> > > 
> > > Signed-off-by: Marton Balint 
> > > ---
> > >  libavformat/mxfenc.c | 2 +-
> > >  1 file changed, 1 insertion(+), 1 deletion(-)
> > > 
> > > diff --git a/libavformat/mxfenc.c b/libavformat/mxfenc.c
> > > index ba8e7babfb..5b972eadaa 100644
> > > --- a/libavformat/mxfenc.c
> > > +++ b/libavformat/mxfenc.c
> > > @@ -1757,7 +1757,7 @@ static void
> > > mxf_write_index_table_segment(AVFormatContext *s)
> > >  
> > >  // instance id
> > >  mxf_write_local_tag(s, 16, 0x3C0A);
> > > -    mxf_write_uuid(pb, IndexTableSegment, 0);
> > > +    mxf_write_uuid(pb, IndexTableSegment, mxf-
> > > > last_indexed_edit_unit);
> > 
> > Two things: yes, it is good that this fixes the same InstanceUID
> > being
> > reused. But more importantly, we should not be writing files with
> > over
> > 65536 partitions!
> 
> last_indexed_edit_unit is frame based not partition based, so it can 
> overflow 65536 realtively easily, that is why I submitted patch 1.

Right. But we could use the partition number instead.

> 
> > 
> > This has been bugging me for quite some time. Honestly I don't know
> > why
> > the decision was taken initially to write indices every 10 seconds.
> > In
> > any use-case where seeks are moderately expensive working with
> > files
> > produced by mxfenc is a nightmare. Prime example being HTTP.
> 
> The 10 second body partition limit is coming from some specification 
> (XDCAM HD?), so this is kind of intentional.
> 
> > 
> > If we do still need to keep writing partitions this way, can we
> > repeat
> > the IndexTableSegments in the footer so the entire file doesn't
> > have to
> > be scanned?
> 
> Yeah, that is what smart tools like bmxtools are doing.

If XDCAM requires this amount of partitions then yeah, probably write
the index tables twice. That way a smart reader should be able to
figure out that it doesn't need to read more than the header, RIP and
footer.

/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 2/2] avformat/mxfenc: do not write index tables with the same InstanceUID

2022-03-14 Thread Marton Balint

On Mon, 14 Mar 2022, Tomas Härdin wrote:

mån 2022-03-14 klockan 20:54 +0100 skrev Marton Balint:

On Mon, 14 Mar 2022, Tomas Härdin wrote:

> mån 2022-03-14 klockan 19:49 +0100 skrev Marton Balint:
> > Only index tables repeating previous index tables should use the
> > same
> > InstaceUID. Use the index start position when generating the
> > InstanceUID to fix
> > this.
> > 
> > Signed-off-by: Marton Balint 

> > ---
> >  libavformat/mxfenc.c | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> > 
> > diff --git a/libavformat/mxfenc.c b/libavformat/mxfenc.c

> > index ba8e7babfb..5b972eadaa 100644
> > --- a/libavformat/mxfenc.c
> > +++ b/libavformat/mxfenc.c
> > @@ -1757,7 +1757,7 @@ static void
> > mxf_write_index_table_segment(AVFormatContext *s)
> >  
> >  // instance id
> >  mxf_write_local_tag(s, 16, 0x3C0A);
> > -    mxf_write_uuid(pb, IndexTableSegment, 0);
> > +    mxf_write_uuid(pb, IndexTableSegment, mxf-
> > > last_indexed_edit_unit);
> 
> Two things: yes, it is good that this fixes the same InstanceUID

> being
> reused. But more importantly, we should not be writing files with
> over
> 65536 partitions!

last_indexed_edit_unit is frame based not partition based, so it can 
overflow 65536 realtively easily, that is why I submitted patch 1.

Right. But we could use the partition number instead.

Well, we could use mxf->body_partitions_count but it is not trivial to see 
that it will work for all cases. For simple indexes, we rewrite the index 
table in the footer when writing the mxf header, opatom may follow another 
layout, so it just felt less error-prone to use actually the start offset 
of the index.

> 
> This has been bugging me for quite some time. Honestly I don't know

> why
> the decision was taken initially to write indices every 10 seconds.
> In
> any use-case where seeks are moderately expensive working with
> files
> produced by mxfenc is a nightmare. Prime example being HTTP.

The 10 second body partition limit is coming from some specification 
(XDCAM HD?), so this is kind of intentional.

> 
> If we do still need to keep writing partitions this way, can we

> repeat
> the IndexTableSegments in the footer so the entire file doesn't
> have to
> be scanned?

Yeah, that is what smart tools like bmxtools are doing.

If XDCAM requires this amount of partitions then yeah, probably write
the index tables twice. That way a smart reader should be able to
figure out that it doesn't need to read more than the header, RIP and
footer.

Sure, but this can be another patch.

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

[FFmpeg-devel] [PATCH 1/4] avfilter/x86/vf_blend: use unaligned movs for output

2022-03-14 Thread Marton Balint

Fixes crashes with:

ffmpeg -f lavfi -i allyuv=d=1 -vf tblend=difference128,pad=5000:ih:1 -f null x

Signed-off-by: Marton Balint 
---
 libavfilter/x86/vf_blend.asm | 22 +++---
 1 file changed, 11 insertions(+), 11 deletions(-)

diff --git a/libavfilter/x86/vf_blend.asm b/libavfilter/x86/vf_blend.asm
index 766e5b7bc1..277b100e4d 100644
--- a/libavfilter/x86/vf_blend.asm
+++ b/libavfilter/x86/vf_blend.asm
@@ -75,7 +75,7 @@ BLEND_INIT %1, 2, %3
 movum0, [topq + xq]
 movum1, [bottomq + xq]
 p%2 m0, m1
-mova   [dstq + xq], m0
+movu   [dstq + xq], m0
 add xq, mmsize
 jl .loop
 BLEND_END
@@ -108,7 +108,7 @@ BLEND_INIT %1, 6, %4
 
 packus%3%2   m0, m1
 
-mova  [dstq + xq], m0
+movu  [dstq + xq], m0
 addxq, mmsize
 jl .loop
 BLEND_END
@@ -148,7 +148,7 @@ BLEND_INIT multiply, 6
 MULTIPLYm1, m3, m5
 
 packuswb   m0, m1
-mova  [dstq + xq], m0
+movu  [dstq + xq], m0
 addxq, mmsize
 jl .loop
 BLEND_END
@@ -175,7 +175,7 @@ BLEND_INIT screen, 7
 SCREEN  m1, m3, m5, m6
 
 packuswb   m0, m1
-mova  [dstq + xq], m0
+movu  [dstq + xq], m0
 addxq, mmsize
 jl .loop
 BLEND_END
@@ -196,7 +196,7 @@ BLEND_INIT %1, 3, %3
 pxor   m1, m2
 pavg%2 m0, m1
 pxor   m0, m2
-mova  [dstq + xq], m0
+movu  [dstq + xq], m0
 addxq, mmsize
 jl .loop
 BLEND_END
@@ -230,7 +230,7 @@ BLEND_INIT %1, 6, %4
 
 packus%3%2 m0, m1
 
-mova  [dstq + xq], m0
+movu  [dstq + xq], m0
 addxq, mmsize
 jl .loop
 BLEND_END
@@ -251,7 +251,7 @@ BLEND_INIT hardmix, 5
 pxorm0, m3
 pcmpgtb m1, m0
 pxorm1, m2
-mova   [dstq + xq], m1
+movu   [dstq + xq], m1
 add xq, mmsize
 jl .loop
 BLEND_END
@@ -304,7 +304,7 @@ BLEND_INIT %1, 4, %3
 movam2, m3
 psubus%2m2, m1
 paddus%2m2, m0
-mova   [dstq + xq], m2
+movu   [dstq + xq], m2
 add xq, mmsize
 jl .loop
 BLEND_END
@@ -333,7 +333,7 @@ BLEND_INIT %1, 5, %4
 ABS2m0, m3, m1, m4
 %endif
 packus%3%2  m0, m3
-mova   [dstq + xq], m0
+movu   [dstq + xq], m0
 add xq, mmsize
 jl .loop
 BLEND_END
@@ -369,7 +369,7 @@ BLEND_INIT %1, 8, %4
 ABS2m3, m7, m1, m6
 %endif
 packus%3%2  m3, m7
-mova   [dstq + xq], m3
+movu   [dstq + xq], m3
 add xq, mmsize
 jl .loop
 BLEND_END
@@ -406,7 +406,7 @@ BLEND_INIT %1, 8, %4
 psub%3  m0, m4, m3
 psub%3  m1, m4, m7
 packus%3%2  m0, m1
-mova   [dstq + xq], m0
+movu   [dstq + xq], m0
 add xq, mmsize
 jl .loop
 BLEND_END
-- 
2.31.1

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

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

[FFmpeg-devel] [PATCH 2/4] avfilter/vf_zscale: fix number of threads

2022-03-14 Thread Marton Balint

Make sure it is between [1, MAX_THERADS] and also take into account the outlink
size in order not to request zero height output from zscale.

Signed-off-by: Marton Balint 
---
 libavfilter/vf_zscale.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/libavfilter/vf_zscale.c b/libavfilter/vf_zscale.c
index bb457423b3..bab87b0c94 100644
--- a/libavfilter/vf_zscale.c
+++ b/libavfilter/vf_zscale.c
@@ -799,7 +799,7 @@ static int filter_frame(AVFilterLink *link, AVFrame *in)
 link->dst->inputs[0]->w  = in->width;
 link->dst->inputs[0]->h  = in->height;
 
-s->nb_threads = FFMIN(ff_filter_get_nb_threads(ctx), link->h / 8);
+s->nb_threads = av_clip(FFMIN(ff_filter_get_nb_threads(ctx), 
FFMIN(link->h, outlink->h) / 8), 1, MAX_THREADS);
 s->in_colorspace = in->colorspace;
 s->in_trc = in->color_trc;
 s->in_primaries = in->color_primaries;
-- 
2.31.1

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

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

[FFmpeg-devel] [PATCH 3/4] avfilter/vf_zscale: properly check return value of slice threads

2022-03-14 Thread Marton Balint

Signed-off-by: Marton Balint 
---
 libavfilter/vf_zscale.c | 11 +++
 1 file changed, 7 insertions(+), 4 deletions(-)

diff --git a/libavfilter/vf_zscale.c b/libavfilter/vf_zscale.c
index bab87b0c94..ceefc95224 100644
--- a/libavfilter/vf_zscale.c
+++ b/libavfilter/vf_zscale.c
@@ -117,6 +117,7 @@ typedef struct ZScaleContext {
 
 void *tmp[MAX_THREADS]; //separate for each thread;
 int nb_threads;
+int jobs_ret[MAX_THREADS];
 
 zimg_image_format src_format, dst_format;
 zimg_image_format alpha_src_format, alpha_dst_format;
@@ -858,12 +859,14 @@ static int filter_frame(AVFilterLink *link, AVFrame *in)
 td.desc = desc;
 td.odesc = odesc;
 
-ret = ff_filter_execute(ctx, filter_slice, &td, NULL, s->nb_threads);
-if (ret < 0 || !s->graph[0]) {
+memset(s->jobs_ret, 0, s->nb_threads * sizeof(*s->jobs_ret));
+ret = ff_filter_execute(ctx, filter_slice, &td, s->jobs_ret, 
s->nb_threads);
+for (int i = 0; ret >= 0 && i < s->nb_threads; i++)
+if (s->jobs_ret[i] < 0)
+ret = s->jobs_ret[i];
+if (ret < 0) {
 av_frame_free(&in);
 av_frame_free(&out);
-if (ret >= 0)
-ret = AVERROR(EINVAL);
 return ret;
 }
 
-- 
2.31.1

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

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

[FFmpeg-devel] [PATCH 4/4] avfilter/vf_zscale: realign output buffer if needed

2022-03-14 Thread Marton Balint

Output buffer alignment might be different to ZIMG_ALIGNMENT or it may not be
aligned at all if a downstream filter (e.g. vf_pad) intentionally misaligns it.

Or maybe we should unconditionally always allocate output with
av_frame_get_buffer() instead of ff_get_video_buffer()?

Signed-off-by: Marton Balint 
---
 libavfilter/vf_zscale.c | 11 +++
 1 file changed, 7 insertions(+), 4 deletions(-)

diff --git a/libavfilter/vf_zscale.c b/libavfilter/vf_zscale.c
index ceefc95224..2061e38bcc 100644
--- a/libavfilter/vf_zscale.c
+++ b/libavfilter/vf_zscale.c
@@ -632,7 +632,7 @@ static int graphs_build(AVFrame *in, AVFrame *out, const 
AVPixFmtDescriptor *des
 return 0;
 }
 
-static int realign_frame(const AVPixFmtDescriptor *desc, AVFrame **frame)
+static int realign_frame(const AVPixFmtDescriptor *desc, AVFrame **frame, int 
needs_copy)
 {
 AVFrame *aligned = NULL;
 int ret = 0, plane, planes;
@@ -654,10 +654,10 @@ static int realign_frame(const AVPixFmtDescriptor *desc, 
AVFrame **frame)
 if ((ret = av_frame_get_buffer(aligned, ZIMG_ALIGNMENT)) < 0)
 goto fail;
 
-if ((ret = av_frame_copy(aligned, *frame)) < 0)
+if (needs_copy && (ret = av_frame_copy(aligned, *frame)) < 0)
 goto fail;
 
-if ((ret = av_frame_copy_props(aligned, *frame)) < 0)
+if (needs_copy && (ret = av_frame_copy_props(aligned, *frame)) < 0)
 goto fail;
 
 av_frame_free(frame);
@@ -786,9 +786,12 @@ static int filter_frame(AVFilterLink *link, AVFrame *in)
 goto fail;
 }
 
+if ((ret = realign_frame(odesc, &out, 0)) < 0)
+goto fail;
+
 av_frame_copy_props(out, in);
 
-if ((ret = realign_frame(desc, &in)) < 0)
+if ((ret = realign_frame(desc, &in, 1)) < 0)
 goto fail;
 
 snprintf(buf, sizeof(buf)-1, "%d", outlink->w);
-- 
2.31.1

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

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

Re: [FFmpeg-devel] [PATCH 2/4] avfilter/vf_zscale: fix number of threads

2022-03-14 Thread Paul B Mahol

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

Re: [FFmpeg-devel] [PATCH 3/4] avfilter/vf_zscale: properly check return value of slice threads

2022-03-14 Thread Paul B Mahol

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

Re: [FFmpeg-devel] [PATCH 4/4] avfilter/vf_zscale: realign output buffer if needed

2022-03-14 Thread Paul B Mahol

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] fate: add epx tests

2022-03-14 Thread Paul B Mahol

Signed-off-by: Paul B Mahol 
---
 tests/fate/filter-video.mak | 6 ++
 tests/ref/fate/filter-ep2x  | 7 +++
 tests/ref/fate/filter-ep3x  | 7 +++
 3 files changed, 20 insertions(+)
 create mode 100644 tests/ref/fate/filter-ep2x
 create mode 100644 tests/ref/fate/filter-ep3x

diff --git a/tests/fate/filter-video.mak b/tests/fate/filter-video.mak
index d53922..27a794dab4 100644
--- a/tests/fate/filter-video.mak
+++ b/tests/fate/filter-video.mak
@@ -424,6 +424,12 @@ FATE_FILTER_SAMPLES-$(call ALLYES, MATROSKA_DEMUXER 
OVERLAY_FILTER H264_DECODER
 fate-filter-overlay-dvdsub-2397: tests/data/filtergraphs/overlay-dvdsub-2397
 fate-filter-overlay-dvdsub-2397: CMD = framecrc -auto_conversion_filters 
-flags bitexact -i $(TARGET_SAMPLES)/filter/242_4.mkv -filter_complex_script 
$(TARGET_PATH)/tests/data/filtergraphs/overlay-dvdsub-2397 -c:a copy
 
+FATE_FILTER_EPX-$(call ALLYES, IMAGE2_DEMUXER PNG_DECODER EPX_FILTER) = 
fate-filter-ep2x fate-filter-ep3x
+FATE_FILTER_SAMPLES-yes += $(FATE_FILTER_EPX-yes)
+fate-filter-ep2x: CMD = framecrc -i $(TARGET_SAMPLES)/filter/pixelart%d.png 
-vf scale,format=rgb32,epx=2,scale,format=bgra
+fate-filter-ep3x: CMD = framecrc -i $(TARGET_SAMPLES)/filter/pixelart%d.png 
-vf scale,format=rgb32,epx=3,scale,format=bgra
+fate-filter-epx: $(FATE_FILTER_EPX-yes)
+
 FATE_FILTER_HQX-$(call ALLYES, IMAGE2_DEMUXER PNG_DECODER HQX_FILTER) = 
fate-filter-hq2x fate-filter-hq3x fate-filter-hq4x
 FATE_FILTER_SAMPLES-yes += $(FATE_FILTER_HQX-yes)
 fate-filter-hq2x: CMD = framecrc -i $(TARGET_SAMPLES)/filter/pixelart%d.png 
-vf scale,format=rgb32,hqx=2,scale,format=bgra
diff --git a/tests/ref/fate/filter-ep2x b/tests/ref/fate/filter-ep2x
new file mode 100644
index 00..d720510d99
--- /dev/null
+++ b/tests/ref/fate/filter-ep2x
@@ -0,0 +1,7 @@
+#tb 0: 1/25
+#media_type 0: video
+#codec_id 0: rawvideo
+#dimensions 0: 382x574
+#sar 0: 1/1
+0,  0,  0,1,   877072, 0xfd71968d
+0,  1,  1,1,   877072, 0x231d2ba7
diff --git a/tests/ref/fate/filter-ep3x b/tests/ref/fate/filter-ep3x
new file mode 100644
index 00..16f714ed46
--- /dev/null
+++ b/tests/ref/fate/filter-ep3x
@@ -0,0 +1,7 @@
+#tb 0: 1/25
+#media_type 0: video
+#codec_id 0: rawvideo
+#dimensions 0: 573x861
+#sar 0: 1/1
+0,  0,  0,1,  1973412, 0x99d19757
+0,  1,  1,1,  1973412, 0x8d5288f2
-- 
2.33.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] lavc/aarch64: add some neon pix_abs functions

2022-03-14 Thread Martin Storsjö


On Mon, 7 Mar 2022, Swinney, Jonathan wrote:


- ff_pix_abs16_neon
- ff_pix_abs16_xy2_neon

In direct micro benchmarks of these ff functions verses their C implementations,
these functions performed as follows on AWS Graviton 2:

ff_pix_abs16_neon:
c:  benchmark ran 10 iterations in 0.955383 seconds
ff: benchmark ran 10 iterations in 0.097669 seconds

ff_pix_abs16_xy2_neon:
c:  benchmark ran 10 iterations in 1.916759 seconds
ff: benchmark ran 10 iterations in 0.370729 seconds


I see that there's no checkasm tests for these functions - would you mind 
adding one? (There's something kind of like a checkasm test in 
libavcodec/tests/motion.c, but that one doesn't seem to be updated for 
contempory SIMD instruction sets.)


Adding a checkasm test is important as it tests for a bunch of aspects 
that otherwise can seem to work by accident (like missing zeroing/sign 
extension of the upper half of registers, clobbering callee saved 
registers, etc). For functions of this size, it's not hard to verify such 
aspects of course, but I pretty much want to have checkasm coverage for 
all newly added assembly. (Plus that checkasm gives built-in benchmarking 
support for the functions.)



diff --git a/libavcodec/aarch64/me_cmp_init_aarch64.c 
b/libavcodec/aarch64/me_cmp_init_aarch64.c
new file mode 100644
index 00..fb827daaf5
--- /dev/null
+++ b/libavcodec/aarch64/me_cmp_init_aarch64.c
@@ -0,0 +1,39 @@
+/*
+ * 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/aarch64/cpu.h"
+#include "libavcodec/mpegvideo.h"
+
+int ff_pix_abs16_neon(MpegEncContext *s, uint8_t *blk1, uint8_t *blk2,
+   ptrdiff_t stride, int h);
+int ff_pix_abs16_xy2_neon(MpegEncContext *s, uint8_t *blk1, uint8_t *blk2,
+   ptrdiff_t stride, int h);


The second line seems misindented for both functions


diff --git a/libavcodec/aarch64/me_cmp_neon.S b/libavcodec/aarch64/me_cmp_neon.S
new file mode 100644
index 00..85b0e4bd9e
--- /dev/null
+++ b/libavcodec/aarch64/me_cmp_neon.S
@@ -0,0 +1,219 @@
+/*
+ * Copyright (c) 2022 Jonathan Swinney 
+ *
+ * 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/aarch64/asm.S"
+function ff_pix_abs16_neon, export=1


Nit: Empty line between the include and the function


+// x0   unused
+// x1   uint8_t *pix1
+// x2   uint8_t *pix2
+// x3   ptrdiff_t stride
+// w4   int h
+// x5   uint8_t *pix3
+cmp w4, #4  // if h < 4, jump to completion 
section


Please indent the assembly according to the existing code; 8 spaces before 
the instruction column, 24 chars before the first operand.



+b.lt2f
+moviv18.4S, #0  // clear result accumulator


Nit: I prefer lower case for the element specifier (.4s)


+1:
+moviv16.8H, #0  // clear uabal accumulator
+ld1 {v0.16B}, [x1], x3  // load pix1
+ld1 {v4.16B}, [x2], x3  // load pix2
+ld1 {v1.16B}, [x1], x3  // load pix1
+ld1 {v5.16B}, [x2], x3  // load pix2
+uabal   v16.8H, v0.8B, v4.8B// absolute difference accumulate
+uabal2  v16.8H, v0.16B, v4.16B
+ld1 {v2.16B}, [x1], x3  // load pix1
+ld1 {v6.16B}, [x2], x3  // load pix2
+uabal   v16.8H, v1.8B, v5.8B// absolute difference accumu

Re: [FFmpeg-devel] [PATCH] lavc/aarch64: add some neon pix_abs functions

2022-03-14 Thread Martin Storsjö


On Mon, 7 Mar 2022, Pop, Sebastian wrote:


Here are a few suggestions:


+add d18, d17, d18   // add to the end result register
[...]
+mov w0, v18.S[0]// copy result to general purpose 
register


I think you can use 32-bit register s18 instead of d18.
The mov with indexed vector is more expensive than fmov.


Oh, I hadn't considered that. In a tight loop, I can indeed measure a 
quite significant difference between those.



adds18, s18, s17
fmov  w0, s18


+subsw4, w4, #1  // decrement h and set flags for 
branch below
[...]
+b.ne2b  // branch based on subs 
instruction above


Please avoid the flags register to branch.
Instead you could do:

sub   w4, w4, #1
cbnz w4, 2b


If there are other instructions between the sub and the b.ne, does this 
make any difference? (In most cases one can move the decrement into a 
suitable gap early in the loop anyway.) I.e. if the flags register already 
is set since long ago, naively I'd expect that b.ne would be faster (or at 
least not slower) than cbnz.


Some benchmarking on Cortex A53, A72 and A73 seems to agree with my 
expectations too. (It'd be good if we'd have the patch at hand hooked up 
in checkasm, so that we could measure and compare exactly the function at 
hand.)


// 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] aarch64: Only emit the PAC/BTI note section when targeting ELF

2022-03-14 Thread Martin Storsjö


On Wed, 9 Mar 2022, Martin Storsjö wrote:


This avoids build errors if such features are enabled while targeting
another binary format. (Using such features on other platforms
might require some other form of signaling/setup though, but
the ELF specific .note section isn't applicable at least.)

Signed-off-by: Martin Storsjö 
---
libavutil/aarch64/asm.S | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/libavutil/aarch64/asm.S b/libavutil/aarch64/asm.S
index b817eaab22..a7782415d7 100644
--- a/libavutil/aarch64/asm.S
+++ b/libavutil/aarch64/asm.S
@@ -141,7 +141,7 @@
#endif


-#if (GNU_PROPERTY_AARCH64_BTI != 0 || GNU_PROPERTY_AARCH64_PAC != 0)
+#if (GNU_PROPERTY_AARCH64_BTI != 0 || GNU_PROPERTY_AARCH64_PAC != 0) && 
defined(__ELF__)
.pushsection .note.gnu.property, "a"
.balign 8
.long 4
--
2.32.0 (Apple Git-132)


Pushed.

// 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 v4 1/4] lavc/vaapi_encode_h265: Add GPB frame support for hevc_vaapi

2022-03-14 Thread Mark Thompson


On 14/03/2022 02:15, Xiang, Haihao wrote:

On Sun, 2022-03-13 at 20:45 +, Mark Thompson wrote:

On 11/03/2022 09:00, Fei Wang wrote:

From: Linjie Fu 

Use GPB frames to replace regular P/B frames if backend driver does not
support it.

- GPB:
  Generalized P and B picture. Regular P/B frames replaced by B
  frames with previous-predict only, L0 == L1. Normal B frames
  still have 2 different ref_lists and allow bi-prediction

Signed-off-by: Linjie Fu 
Signed-off-by: Fei Wang 
---
update:
1. Add b to gpb.
2. Optimise debug message.

   libavcodec/vaapi_encode.c  | 74 +++---
   libavcodec/vaapi_encode.h  |  2 +
   libavcodec/vaapi_encode_h265.c | 24 ++-
   3 files changed, 93 insertions(+), 7 deletions(-)

diff --git a/libavcodec/vaapi_encode.c b/libavcodec/vaapi_encode.c
index 3bf379b1a0..bdba9726b2 100644
--- a/libavcodec/vaapi_encode.c
+++ b/libavcodec/vaapi_encode.c
@@ -848,9 +848,13 @@ static void vaapi_encode_set_b_pictures(AVCodecContext
*avctx,
   pic->b_depth = current_depth;
   
   vaapi_encode_add_ref(avctx, pic, start, 1, 1, 0);

-vaapi_encode_add_ref(avctx, pic, end,   1, 1, 0);
   vaapi_encode_add_ref(avctx, pic, prev,  0, 0, 1);
   
+if (!ctx->b_to_gpb)

+vaapi_encode_add_ref(avctx, pic, end, 1, 1, 0);
+else
+vaapi_encode_add_ref(avctx, pic, end, 0, 1, 0);


This is doing something extremely dubious.  If b-to-gpb is set, then don't use
the future reference?


According to
https://github.com/intel/media-driver/blob/master/media_driver/agnostic/common/codec/hal/codechal_vdenc_hevc.cpp#L3072-L3087
, L0 and L1 should be the same for vdenc hevc on some platforms,


Right, so this is actually a different constraint which isn't indicated so far. 
 It's not just the BI_NOT_EMPTY constraint that P slices cannot be used, it's 
also that in B slices RefPicList1 has to be identical to RefPicList0.  Perhaps 
this should be added to libva?


 so user can't
use past and future reference together,


Where is this coming from?  I don't see how past vs. future references are 
relevant at all (since the driver can't see that anyway), only the matching 
content of the lists.

Maybe in this case the right behaviour would be to concatenate what would 
normally be in the two lists and then put that in both of them (assuming it 
supports the necessary reference counts, but this particular hardware appears 
to allow 3/3 so it would).


which is why you experienced the failure
after applying version 2


Yep - and is also why the P-frame only case works, since that puts the same 
single entry in both lists.

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

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

Re: [FFmpeg-devel] [PATCH v4 1/4] lavc/vaapi_encode_h265: Add GPB frame support for hevc_vaapi

2022-03-14 Thread Mark Thompson

On 14/03/2022 11:07, Wang, Fei W wrote:

-Original Message-
From: ffmpeg-devel  On Behalf Of Xiang,
Haihao
Sent: Monday, March 14, 2022 10:15 AM
To: ffmpeg-devel@ffmpeg.org
Subject: Re: [FFmpeg-devel] [PATCH v4 1/4] lavc/vaapi_encode_h265: Add GPB
frame support for hevc_vaapi

On Sun, 2022-03-13 at 20:45 +, Mark Thompson wrote:

On 11/03/2022 09:00, Fei Wang wrote:

From: Linjie Fu 

Use GPB frames to replace regular P/B frames if backend driver does
not support it.

- GPB:
  Generalized P and B picture. Regular P/B frames replaced by B
  frames with previous-predict only, L0 == L1. Normal B frames
  still have 2 different ref_lists and allow bi-prediction

Signed-off-by: Linjie Fu 
Signed-off-by: Fei Wang 
---
update:
1. Add b to gpb.
2. Optimise debug message.

   libavcodec/vaapi_encode.c  | 74 +++--

-

   libavcodec/vaapi_encode.h  |  2 +
   libavcodec/vaapi_encode_h265.c | 24 ++-
   3 files changed, 93 insertions(+), 7 deletions(-)

diff --git a/libavcodec/vaapi_encode.c b/libavcodec/vaapi_encode.c
index 3bf379b1a0..bdba9726b2 100644
--- a/libavcodec/vaapi_encode.c
+++ b/libavcodec/vaapi_encode.c
@@ -848,9 +848,13 @@ static void
vaapi_encode_set_b_pictures(AVCodecContext
*avctx,
   pic->b_depth = current_depth;

   vaapi_encode_add_ref(avctx, pic, start, 1, 1, 0);
-vaapi_encode_add_ref(avctx, pic, end,   1, 1, 0);
   vaapi_encode_add_ref(avctx, pic, prev,  0, 0, 1);

+if (!ctx->b_to_gpb)
+vaapi_encode_add_ref(avctx, pic, end, 1, 1, 0);
+else
+vaapi_encode_add_ref(avctx, pic, end, 0, 1, 0);

This is doing something extremely dubious.  If b-to-gpb is set, then
don't use the future reference?

According to
https://github.com/intel/media-
driver/blob/master/media_driver/agnostic/common/codec/hal/codechal_vdenc
_hevc.cpp#L3072-L3087
, L0 and L1 should be the same for vdenc hevc on some platforms, so user can't
use past and future reference together, which is why you experienced the failure
after applying version 2

Thanks
Haihao

That means these pictures will only have the past reference, and the
coding efficiency will often be much worse.

E.g. if you have the default structure (max_b_frames = 2, max_b_depth
= 1) then in a sequence of four pictures you get:

1 referring to something previous
4 referring to 1
2 referring to 1 and 4
3 referring to 1 and 4

and this change means you lose the 2 -> 4 and 3 -> 4 references.
Therefore, a change in the picture between 1 and 2 will end up coded
three times in 2, 3 and 4 rather than just being coded in 4 and then referred to

by the others.

If driver doesn't support B frames with two different reference lists, use gpb 
instead
of regular B is a best way. In V3, I turned B frames to P, but this will break 
gop structure.
If user set I/P/B frames, while the output only contains I/P frames will be 
much confuse.

If the driver requires that RefPicList0 and RefPicList1 in B slices are the 
same then isn't the obvious solution to concatenate the expected lists and put 
the result in both actual lists (assuming it fits)?

That continues to support B frames in the obvious way (and transparently to the 
user).  The hardware will have to do a bit more motion search, but the fake P 
slices already require that anyway so I assume it is sensibly optimised.

+
   for (ref = end->refs[1]; ref; ref = ref->refs[1])
   vaapi_encode_add_ref(avctx, pic, ref, 0, 1, 0);
   }
@@ -871,8 +875,11 @@ static void
vaapi_encode_set_b_pictures(AVCodecContext
*avctx,

   vaapi_encode_add_ref(avctx, pic, pic,   0, 1, 0);
   vaapi_encode_add_ref(avctx, pic, start, 1, 1, 0);
-vaapi_encode_add_ref(avctx, pic, end,   1, 1, 0);
   vaapi_encode_add_ref(avctx, pic, prev,  0, 0, 1);
+if (!ctx->b_to_gpb)
+vaapi_encode_add_ref(avctx, pic, end, 1, 1, 0);
+else
+vaapi_encode_add_ref(avctx, pic, end, 0, 1, 0);

   for (ref = end->refs[1]; ref; ref = ref->refs[1])
   vaapi_encode_add_ref(avctx, pic, ref, 0, 1, 0); @@
-1845,6 +1852,51 @@ static av_cold int
vaapi_encode_init_gop_structure(AVCodecContext *avctx)
   ref_l1 = attr.value >> 16 & 0x;
   }

+ctx->p_to_gpb = 0;
+ctx->b_to_gpb = 0;
+
+#if VA_CHECK_VERSION(1, 9, 0)
+if (!(ctx->codec->flags & FLAG_INTRA_ONLY ||
+avctx->gop_size <= 1)) {
+attr = (VAConfigAttrib) { VAConfigAttribPredictionDirection };
+vas = vaGetConfigAttributes(ctx->hwctx->display,
+ctx->va_profile,
+ctx->va_entrypoint,
+&attr, 1);
+if (vas != VA_STATUS_SUCCESS) {
+av_log(avctx, AV_LOG_WARNING, "Failed to query
+prediction
direction "
+   "attribute: %d (%s).\n", vas, vaErrorStr(vas));
+

Re: [FFmpeg-devel] [PATCH v3] avcodec/pngenc: support writing iCCP chunks

2022-03-14 Thread Andreas Rheinhardt

Niklas Haas:
> From: Niklas Haas 
> 
> encode_zbuf is mostly a mirror image of decode_zbuf. Other than that,
> the code is pretty straightforward. Special care needs to be taken to
> avoid writing more than 79 characters of the profile description (the
> maximum supported).
> 
> To write the (dynamically sized) deflate-encoded data, we allocate extra
> space in the packet and use that directly as a scratch buffer. Modify
> png_write_chunk slightly to allow pre-writing the chunk contents like
> this. This implementation does unfortunately require initializing the
> deflate instance twice, but deflateBound() is not redundant with
> deflate() so we're not throwing away any significant work.
> 
> Also add a FATE transcode test to ensure that the ICC profile gets
> encoded correctly.
> ---
> 
> Changes in v3:
> - rewrite to write the chunk in-place (inside the packet buffer)
> 
> Actually, I implemented an AVBPrint-less version that I think I'm
> happier with overall. The extent of the "crimes" needed to support
> writing chunks in-place was a single `if` in png_write_chunk and
> hard-coding an 8 byte start offset.
> 
> I like this the most, since it doesn't require dynamic allocation _at
> all_. It also ends up producing a 1 byte smaller test file for some
> reason (not as a result of any obvious bug, but simply because zlib
> compresses the last few bytes of the stream in a slightly different way,
> probably as a result of some internal heuristics related to the buffer
> size - the decoded ICC profile checksum is the same).
> 
> ---
>  libavcodec/pngenc.c| 93 +-
>  tests/fate/image.mak   |  3 ++
>  tests/ref/fate/png-icc |  8 
>  3 files changed, 102 insertions(+), 2 deletions(-)
>  create mode 100644 tests/ref/fate/png-icc
> 
> diff --git a/libavcodec/pngenc.c b/libavcodec/pngenc.c
> index 3ebcc1e571..e9bbe33adf 100644
> --- a/libavcodec/pngenc.c
> +++ b/libavcodec/pngenc.c
> @@ -235,7 +235,8 @@ static void png_write_chunk(uint8_t **f, uint32_t tag,
>  bytestream_put_be32(f, av_bswap32(tag));
>  if (length > 0) {
>  crc = av_crc(crc_table, crc, buf, length);
> -memcpy(*f, buf, length);
> +if (*f != buf)
> +memcpy(*f, buf, length);
>  *f += length;
>  }
>  bytestream_put_be32(f, ~crc);
> @@ -343,10 +344,88 @@ static int png_get_gama(enum 
> AVColorTransferCharacteristic trc, uint8_t *buf)
>  return 1;
>  }
>  
> +static size_t zbuf_bound(const uint8_t *data, size_t size)
> +{
> +z_stream zstream;
> +size_t bound;
> +
> +zstream.zalloc = ff_png_zalloc,
> +zstream.zfree  = ff_png_zfree,

Don't surprise people with comma operators.

> +zstream.opaque = NULL;
> +if (deflateInit(&zstream, Z_DEFAULT_COMPRESSION) != Z_OK)

Use the z_stream from the context here and in encode_zbuf() (together
with deflateReset). That saves code, memory and runtime and honours the
user's wishes about compression level. (It will save way more than what
any AVBPrint-small-string-optimization will ever do.)

> +return 0;
> +
> +zstream.next_in = data;
> +zstream.avail_in = size;
> +bound = deflateBound(&zstream, size);

deflateBound uses uLong for the size which is typically a typedef for
unsigned long. In particular, on 64bit Windows size_t is 64bit and uLong
is 32bit. Furthermore, you need to ensure that the chunk length fits
into 32bits (png_write_chunk() even uses an int instead of an uint32_t
for the length). So some length check is necessary here.
(Notice that my zconf.h contains "typedef unsigned long  uLong; /* 32
bits or more */", so you may presume uLong to be more encompassing than
uint32_t.)

> +deflateEnd(&zstream);
> +return bound;
> +}
> +
> +static int encode_zbuf(uint8_t **buf, const uint8_t *buf_end,
> +   const uint8_t *data, size_t size)
> +{
> +z_stream zstream;
> +int ret;
> +
> +zstream.zalloc = ff_png_zalloc,
> +zstream.zfree  = ff_png_zfree,
> +zstream.opaque = NULL;
> +if (deflateInit(&zstream, Z_DEFAULT_COMPRESSION) != Z_OK)
> +return AVERROR_EXTERNAL;
> +zstream.next_in  = data;
> +zstream.avail_in = size;
> +zstream.next_out  = *buf;
> +zstream.avail_out = buf_end - *buf;
> +ret = deflate(&zstream, Z_FINISH);
> +deflateEnd(&zstream);
> +if (ret != Z_STREAM_END)
> +return AVERROR_EXTERNAL;
> +
> +*buf = zstream.next_out;
> +return 0;
> +}
> +
> +static int png_write_iccp(uint8_t **bytestream, const uint8_t *end,
> +  const AVFrameSideData *side_data)
> +{
> +const AVDictionaryEntry *entry;
> +const char *name;
> +uint8_t *start, *buf;
> +int ret;
> +
> +if (!side_data || !side_data->size)
> +return 0;
> +
> +/* write the chunk contents first */
> +start = *bytestream + 8; /* make room for iCCP tag + length */
> +buf = start;
> +
> +/* profile description */
> +entry = av_dict_get(side

60 matches

Mail list logo