Re: [FFmpeg-devel] [PATCH 01/35] fftools/ffmpeg_mux: add private muxer context

[Anton Khirnov]

Quoting Michael Niedermayer (2022-07-14 00:12:59)
> On Wed, Jul 13, 2022 at 12:58:54PM +0200, Anton Khirnov wrote:
> > Quoting Michael Niedermayer (2022-07-08 18:58:11)
> > > On Fri, Jun 17, 2022 at 12:27:18PM +0200, Anton Khirnov wrote:
> > > > The current version of this set can also be found in my tree
> > > > git://git.khirnov.net/libav
> > > > branch ffmpeg_mt/mux
> > > 
> > > There are really many files changing, its hard to say for sure that all 
> > > are the
> > > same issue, but basically it all seems more or less frames in some streams
> > > including cases where there are hugely more or 0
> > > 
> > > Here are some examples:
> > > 
> > > 
> > > ffmpeg -i matrixbench_mpeg2.mpg -vcodec rawvideo -pix_fmt rgb555 
> > > -allow_raw_vfw 1 -vframes 1 -bitexact file-rgb555.mkv
> > > 
> > > the new file is much bigger (due to the audio track)
> > > 
> > > -rw-r- 1 michael michael 2765813 Jul  8 16:57 file-rgb555.mkv
> > > -rw-r- 1 michael michael  834643 Jul  8 17:02 file-rgb555-ref.mkv
> > 
> > Where can I find this file?
> 
> the 2 file-rgb555.mkv files are the outputs from ffmpeg from the 
> matrixbench_mpeg2
> file and teh command line above. From before and after the change IIRC
> 
> matrixbench_mpeg2.mpg should be here:
> https://samples.ffmpeg.org/benchmark/testsuite1/

The output is ~815kB in the current branch, same as before. So I assume
the problem got fixed by the changes I did for one of the other samples.

Thanks for testing and let me know if you find any other issues.

-- 
Anton Khirnov
___
ffmpeg-devel mailing list
ffmpeg-devel@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 3/4] lavc/hevc_refs: exclude current frame from long term refs

[Xiang, Haihao]

On Tue, 2022-06-14 at 09:23 +0800, Fei Wang wrote:
> From: Xu Guangxin 
> 
> suppose
> a. You have 3 frames, 0, 1, 4096.
> b. The ltMask is 0xfff and use_msb is 0.
> c. The 0, 1 are lt refs for 4096.
> d. you are decoding frame 4096, and get the 0 frame.
> Since 4096 & ltMask is 0 too, even you want get 0, find_ref_idx may give you
> 4096.
> add_candidate_ref will report an error for this
> 
> Tested-by: Fei Wang 
> Signed-off-by: Xu Guangxin 
> ---
>  libavcodec/hevc_refs.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/libavcodec/hevc_refs.c b/libavcodec/hevc_refs.c
> index 89053fd1a2..b3d5f96043 100644
> --- a/libavcodec/hevc_refs.c
> +++ b/libavcodec/hevc_refs.c
> @@ -386,7 +386,7 @@ static HEVCFrame *find_ref_idx(HEVCContext *s, int poc,
> uint8_t use_msb)
>  for (i = 0; i < FF_ARRAY_ELEMS(s->DPB); i++) {
>  HEVCFrame *ref = >DPB[i];
>  if (ref->frame->buf[0] && ref->sequence == s->seq_decode) {
> -if ((ref->poc & mask) == poc)
> +if ((ref->poc & mask) == poc && (use_msb || ref->poc != s->poc))
>  return ref;
>  }
>  }

LGTM

-Haihao

___
ffmpeg-devel mailing list
ffmpeg-devel@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/flvenc: fix timestamp of key frame index

[Zhao Zhili]

From: Zhao Zhili 

Firstly, the timestamps generated from framerate are inaccurate for
variable framerate mode.

Secondly, the timestamps always start from zero, while pts/dts can
start from nonzero. FLV demuxer rejects such index with message:
"Found invalid index entries, clearing the index".
---
 libavformat/flvenc.c  | 5 +
 tests/ref/fate/flv-add_keyframe_index | 2 +-
 2 files changed, 2 insertions(+), 5 deletions(-)

diff --git a/libavformat/flvenc.c b/libavformat/flvenc.c
index 770ca319ed..1c4ffb985a 100644
--- a/libavformat/flvenc.c
+++ b/libavformat/flvenc.c
@@ -104,7 +104,6 @@ typedef struct FLVContext {
 int64_t lastkeyframelocation_offset;
 int64_t lastkeyframelocation;
 
-int acurframeindex;
 int64_t keyframes_info_offset;
 
 int64_t filepositions_count;
@@ -391,7 +390,6 @@ static void write_metadata(AVFormatContext *s, unsigned int 
ts)
 }
 
 if (flv->flags & FLV_ADD_KEYFRAME_INDEX) {
-flv->acurframeindex = 0;
 flv->keyframe_index_size = 0;
 
 put_amf_string(pb, "hasVideo");
@@ -993,8 +991,7 @@ static int flv_write_packet(AVFormatContext *s, AVPacket 
*pkt)
 switch (par->codec_type) {
 case AVMEDIA_TYPE_VIDEO:
 flv->videosize += (avio_tell(pb) - cur_offset);
-flv->lasttimestamp = flv->acurframeindex / flv->framerate;
-flv->acurframeindex++;
+flv->lasttimestamp = pkt->dts / 1000.0;
 if (pkt->flags & AV_PKT_FLAG_KEY) {
 double ts = flv->lasttimestamp;
 int64_t pos = cur_offset;
diff --git a/tests/ref/fate/flv-add_keyframe_index 
b/tests/ref/fate/flv-add_keyframe_index
index 39c4bed85a..6549170a68 100644
--- a/tests/ref/fate/flv-add_keyframe_index
+++ b/tests/ref/fate/flv-add_keyframe_index
@@ -1,4 +1,4 @@
-5f38d76da3ed4a5be06ca604c53666f2 *tests/data/fate/flv-add_keyframe_index.flv
+9f3d6de74f3329651a4c515c20cea00f *tests/data/fate/flv-add_keyframe_index.flv
 630192 tests/data/fate/flv-add_keyframe_index.flv
 #tb 0: 1/1000
 #media_type 0: video
-- 
2.35.3

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

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

[FFmpeg-devel] [PATCH 2/2] avformat/flvdec: make key frame timestamps more accurate

[Zhao Zhili]

From: Zhao Zhili 

There is an implicit cast from double to int64_t in time unit of
second.
---
 libavformat/flvdec.c | 16 ++--
 1 file changed, 10 insertions(+), 6 deletions(-)

diff --git a/libavformat/flvdec.c b/libavformat/flvdec.c
index c5d3c63bd0..a78d720295 100644
--- a/libavformat/flvdec.c
+++ b/libavformat/flvdec.c
@@ -146,9 +146,9 @@ static void add_keyframes_index(AVFormatContext *s)
 if (ffstream(stream)->nb_index_entries == 0) {
 for (i = 0; i < flv->keyframe_count; i++) {
 av_log(s, AV_LOG_TRACE, "keyframe filepositions = %"PRId64" times 
= %"PRId64"\n",
-   flv->keyframe_filepositions[i], flv->keyframe_times[i] * 
1000);
+   flv->keyframe_filepositions[i], flv->keyframe_times[i]);
 av_add_index_entry(stream, flv->keyframe_filepositions[i],
-flv->keyframe_times[i] * 1000, 0, 0, AVINDEX_KEYFRAME);
+flv->keyframe_times[i], 0, 0, AVINDEX_KEYFRAME);
 }
 } else
 av_log(s, AV_LOG_WARNING, "Skipping duplicate index\n");
@@ -461,9 +461,13 @@ static int parse_keyframes_index(AVFormatContext *s, 
AVIOContext *ioc, int64_t m
 d = av_int2double(avio_rb64(ioc));
 if (isnan(d) || d < INT64_MIN || d > INT64_MAX)
 goto invalid;
-if (current_array ==  && (d <= INT64_MIN / 1000 || d >= 
INT64_MAX / 1000))
-goto invalid;
-current_array[0][i] = d;
+if (current_array == ) {
+if (d <= INT64_MIN / 1000 || d >= INT64_MAX / 1000)
+goto invalid;
+current_array[0][i] = d * 1000;
+} else {
+current_array[0][i] = d;
+}
 }
 if (times && filepositions) {
 // All done, exiting at a position allowing amf_parse_object
@@ -476,7 +480,7 @@ static int parse_keyframes_index(AVFormatContext *s, 
AVIOContext *ioc, int64_t m
 if (timeslen == fileposlen && fileposlen>1 && max_pos <= filepositions[0]) 
{
 for (i = 0; i < FFMIN(2,fileposlen); i++) {
 flv->validate_index[i].pos = filepositions[i];
-flv->validate_index[i].dts = times[i] * 1000;
+flv->validate_index[i].dts = times[i];
 flv->validate_count= i + 1;
 }
 flv->keyframe_times = times;
-- 
2.35.3

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

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

Re: [FFmpeg-devel] [PATCH] libavcodec/qsvenc: Use parameter from AVCodecContext to reset qsv codec

[Chen, Wenbin]

> Using parameter from AVCodecContext to reset qsv codec is more suitable
> for MFXVideoENCODE_Reset()'s usage. Per-frame metadata is more suitable
> for the usage of mfxEncodeCtrl being passed to
> MFXVideoENCODE_EncodeFrameAsync(). Now change it to use the value
> from AVCodecContext.
> 
> Signed-off-by: Wenbin Chen 
> ---
>  doc/encoders.texi   |  5 ++---
>  libavcodec/qsvenc.c | 26 --
>  2 files changed, 10 insertions(+), 21 deletions(-)
> 
> diff --git a/doc/encoders.texi b/doc/encoders.texi
> index 02a91ffe96..bf5fafd3fe 100644
> --- a/doc/encoders.texi
> +++ b/doc/encoders.texi
> @@ -3337,10 +3337,9 @@ For encoders set this flag to ON to reduce power
> consumption and GPU usage.
>  Following options can be used durning qsv encoding.
> 
>  @table @option
> -@item @var{qsv_config_qp}
> +@item @var{global_quality}
>  Supported in h264_qsv and hevc_qsv.
> -This option can be set in per-frame metadata. QP parameter can be
> dynamically
> -changed when encoding in CQP mode.
> +Change this value to reset qsv codec's qp configuration.
>  @end table
> 
>  @subsection H264 options
> diff --git a/libavcodec/qsvenc.c b/libavcodec/qsvenc.c
> index 2382c2f5f7..82cb5a4865 100644
> --- a/libavcodec/qsvenc.c
> +++ b/libavcodec/qsvenc.c
> @@ -1625,34 +1625,24 @@ static int update_qp(AVCodecContext *avctx,
> QSVEncContext *q,
>   const AVFrame *frame)

"const AVFrame *frame" is not used. It can be removed.

>  {
>  int updated = 0, qp = 0, new_qp;
> -char *tail;
> -AVDictionaryEntry *entry = NULL;
> 
>  if (avctx->codec_id != AV_CODEC_ID_H264 && avctx->codec_id !=
> AV_CODEC_ID_HEVC)
>  return 0;
> 
> -entry = av_dict_get(frame->metadata, "qsv_config_qp", NULL, 0);
> -if (entry && q->param.mfx.RateControlMethod ==
> MFX_RATECONTROL_CQP) {
> -qp = strtol(entry->value, , 10);
> -if (*tail) {
> -av_log(avctx, AV_LOG_WARNING, "Invalid qsv_config_qp string.
> Ignore this metadata\n");
> -return 0;
> -}
> -if (qp < 0 || qp > 51) {
> -av_log(avctx, AV_LOG_WARNING, "Invalid qp, clip to 0 ~ 51\n");
> -qp = av_clip(qp, 0, 51);
> -}
> -av_log(avctx, AV_LOG_DEBUG, "Configure qp: %d\n",qp);
> -UPDATE_PARAM(q->param.mfx.QPP, qp);
> +if (q->param.mfx.RateControlMethod == MFX_RATECONTROL_CQP) {
> +qp = avctx->global_quality / FF_QP2LAMBDA;
> +new_qp = av_clip(qp, 0, 51);
> +UPDATE_PARAM(q->param.mfx.QPP, new_qp);
>  new_qp = av_clip(qp * fabs(avctx->i_quant_factor) +
>  avctx->i_quant_offset, 0, 51);
>  UPDATE_PARAM(q->param.mfx.QPI, new_qp);
>  new_qp = av_clip(qp * fabs(avctx->b_quant_factor) +
>  avctx->b_quant_offset, 0, 51);
>  UPDATE_PARAM(q->param.mfx.QPB, new_qp);

"q->param" is passed to both "in" and "out" parameters in 
MFXVideoENCODE_Query() call,
so the value in q->param may be changed. There is a potential issue that codec 
will reset on
every frame.

I will fix these in my patch v2.

> -av_log(avctx, AV_LOG_DEBUG,
> -"using fixed qp = %d/%d/%d for idr/p/b frames\n",
> -q->param.mfx.QPI, q->param.mfx.QPP, q->param.mfx.QPB);
> +if (updated)
> +av_log(avctx, AV_LOG_DEBUG,
> +   "using fixed qp = %d/%d/%d for idr/p/b frames\n",
> +   q->param.mfx.QPI, q->param.mfx.QPP, q->param.mfx.QPB);
>  }
>  return updated;
>  }
> --
> 2.32.0
> 
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> 
> To unsubscribe, visit link above, or email
> ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
___
ffmpeg-devel mailing list
ffmpeg-devel@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 2/4] lavc/hevcdec: do not let missing ref frames invovled in dpb process

[Xiang, Haihao]

On Tue, 2022-06-14 at 09:23 +0800, Fei Wang wrote:
> From: Xu Guangxin 
> 
> We will generate a new frame for a missed reference. The frame can only
> be used for reference. We assign an invalid decode sequence to it, so
> it will not be involved in any dpb process.
> 
> Tested-by: Fei Wang 
> Signed-off-by: Xu Guangxin 
> ---
>  libavcodec/hevc_refs.c | 14 +-
>  libavcodec/hevcdec.c   |  4 ++--
>  libavcodec/hevcdec.h   |  3 +++
>  3 files changed, 18 insertions(+), 3 deletions(-)
> 
> diff --git a/libavcodec/hevc_refs.c b/libavcodec/hevc_refs.c
> index 3f8fe1ef18..89053fd1a2 100644
> --- a/libavcodec/hevc_refs.c
> +++ b/libavcodec/hevc_refs.c
> @@ -172,6 +172,16 @@ int ff_hevc_set_new_ref(HEVCContext *s, AVFrame **frame,
> int poc)
>  return 0;
>  }
>  
> +static void unref_missing_refs(HEVCContext *s)
> +{
> +for (int i = 0; i < FF_ARRAY_ELEMS(s->DPB); i++) {
> + HEVCFrame *frame = >DPB[i];
> + if (frame->sequence == HEVC_DECODE_SEQUENCE_INVALID) {
> + ff_hevc_unref_frame(s, frame, ~0);
> + }
> +}
> +}
> +
>  int ff_hevc_output_frame(HEVCContext *s, AVFrame *out, int flush)
>  {
>  if (IS_IRAP(s) && s->no_rasl_output_flag == 1) {
> @@ -418,7 +428,7 @@ static HEVCFrame *generate_missing_ref(HEVCContext *s, int
> poc)
>  }
>  
>  frame->poc  = poc;
> -frame->sequence = s->seq_decode;
> +frame->sequence = HEVC_DECODE_SEQUENCE_INVALID;
>  frame->flags= 0;
>  
>  if (s->threads_type == FF_THREAD_FRAME)
> @@ -462,6 +472,8 @@ int ff_hevc_frame_rps(HEVCContext *s)
>  return 0;
>  }
>  
> +unref_missing_refs(s);
> +
>  /* clear the reference flags on all frames except the current one */
>  for (i = 0; i < FF_ARRAY_ELEMS(s->DPB); i++) {
>  HEVCFrame *frame = >DPB[i];
> diff --git a/libavcodec/hevcdec.c b/libavcodec/hevcdec.c
> index f782ea6394..99785aa5d1 100644
> --- a/libavcodec/hevcdec.c
> +++ b/libavcodec/hevcdec.c
> @@ -569,7 +569,7 @@ static int hls_slice_header(HEVCContext *s)
>  }
>  
>  if ((IS_IDR(s) || IS_BLA(s)) && sh->first_slice_in_pic_flag) {
> -s->seq_decode = (s->seq_decode + 1) & 0xff;
> +s->seq_decode = (s->seq_decode + 1) & HEVC_DECODE_SEQUENCE_MASK;
>  s->max_ra = INT_MAX;
>  if (IS_IDR(s))
>  ff_hevc_clear_refs(s);
> @@ -614,7 +614,7 @@ static int hls_slice_header(HEVCContext *s)
>  return pix_fmt;
>  s->avctx->pix_fmt = pix_fmt;
>  
> -s->seq_decode = (s->seq_decode + 1) & 0xff;
> +s->seq_decode = (s->seq_decode + 1) & HEVC_DECODE_SEQUENCE_MASK;

I see 0xff is used in other places, could you replace it with
HEVC_DECODE_SEQUENCE_MASK too ?

Thanks
Haihao


>  s->max_ra = INT_MAX;
>  }
>  
> diff --git a/libavcodec/hevcdec.h b/libavcodec/hevcdec.h
> index de861b88b3..9c8bcefb48 100644
> --- a/libavcodec/hevcdec.h
> +++ b/libavcodec/hevcdec.h
> @@ -390,6 +390,9 @@ typedef struct DBParams {
>  #define HEVC_FRAME_FLAG_LONG_REF  (1 << 2)
>  #define HEVC_FRAME_FLAG_BUMPING   (1 << 3)
>  
> +#define HEVC_DECODE_SEQUENCE_MASK 0xff
> +#define HEVC_DECODE_SEQUENCE_INVALID (HEVC_DECODE_SEQUENCE_MASK + 1)
> +
>  typedef struct HEVCFrame {
>  AVFrame *frame;
>  AVFrame *frame_grain;
___
ffmpeg-devel mailing list
ffmpeg-devel@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 01/35] fftools/ffmpeg_mux: add private muxer context

[Michael Niedermayer]

On Wed, Jul 13, 2022 at 12:58:54PM +0200, Anton Khirnov wrote:
> Quoting Michael Niedermayer (2022-07-08 18:58:11)
> > On Fri, Jun 17, 2022 at 12:27:18PM +0200, Anton Khirnov wrote:
> > > The current version of this set can also be found in my tree
> > > git://git.khirnov.net/libav
> > > branch ffmpeg_mt/mux
> > 
> > There are really many files changing, its hard to say for sure that all are 
> > the
> > same issue, but basically it all seems more or less frames in some streams
> > including cases where there are hugely more or 0
> > 
> > Here are some examples:
> > 
> > 
> > ffmpeg -i matrixbench_mpeg2.mpg -vcodec rawvideo -pix_fmt rgb555 
> > -allow_raw_vfw 1 -vframes 1 -bitexact file-rgb555.mkv
> > 
> > the new file is much bigger (due to the audio track)
> > 
> > -rw-r- 1 michael michael 2765813 Jul  8 16:57 file-rgb555.mkv
> > -rw-r- 1 michael michael  834643 Jul  8 17:02 file-rgb555-ref.mkv
> 
> Where can I find this file?

the 2 file-rgb555.mkv files are the outputs from ffmpeg from the 
matrixbench_mpeg2
file and teh command line above. From before and after the change IIRC

matrixbench_mpeg2.mpg should be here:
https://samples.ffmpeg.org/benchmark/testsuite1/

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

[FFmpeg-devel] [PATCH v2] libavcodec: Set hidden visibility on global symbols accessed from AArch64 assembly

[Martin Storsjö]

The AArch64 assembly accesses those symbols directly, without
indirection via e.g. the GOT on ELF. In order for this not to
require text relocations, those symbols need to be resolved fully
at link time, i.e. those symbols can't be interposable.

Normally, so far, this is achieved when linking shared libraries
in two ways; we have a version script (libavcodec/libavcodec.v) which
marks all symbols that don't start with av* as local. Additionally,
we try to add -Wl,-Bsymbolic to the linker options if supported,
making sure that such symbol references are resolved fully at link
time, instead of making them interposable.

When the libavcodec static library is linked into another shared
library, there's no guarantee that it uses similar options (even though
that would be favourable), which would end up requiring text relocations
in the AArch64 assembly.

Explicitly mark the symbols that are accessed from AArch64 assembly
as hidden, so that they are resolved fully at link time even without
the version script and -Wl,-Bsymbolic.

Signed-off-by: Martin Storsjö 
---
Moved the attribute to libavutil/internal.h, renamed to a different
namespace (not av_ prefixed), moved the attribute on ff_vp9_subpel_filters
to the header, as suggested.
---
 libavcodec/aacsbrdata.h | 2 +-
 libavcodec/fft.h| 2 +-
 libavcodec/vp9dsp.h | 2 +-
 libavutil/internal.h| 6 ++
 4 files changed, 9 insertions(+), 3 deletions(-)

diff --git a/libavcodec/aacsbrdata.h b/libavcodec/aacsbrdata.h
index 7a11594c9b..b3899b3e5f 100644
--- a/libavcodec/aacsbrdata.h
+++ b/libavcodec/aacsbrdata.h
@@ -268,7 +268,7 @@ static const int8_t sbr_offset[6][16] = {
 };
 
 /* First eight entries repeated at end to simplify SIMD implementations. */
-const DECLARE_ALIGNED(16, INTFLOAT, AAC_RENAME(ff_sbr_noise_table))[][2] = {
+const attribute_visibility_hidden DECLARE_ALIGNED(16, INTFLOAT, 
AAC_RENAME(ff_sbr_noise_table))[][2] = {
 {Q31(-0.99948153278296f), Q31(-0.59483417516607f)}, {Q31( 0.97113454393991f), 
Q31(-0.67528515225647f)},
 {Q31( 0.14130051758487f), Q31(-0.95090983575689f)}, {Q31(-0.47005496701697f), 
Q31(-0.37340549728647f)},
 {Q31( 0.80705063769351f), Q31( 0.29653668284408f)}, {Q31(-0.38981478896926f), 
Q31( 0.89572605717087f)},
diff --git a/libavcodec/fft.h b/libavcodec/fft.h
index 706c9d07f5..b4066fe0d5 100644
--- a/libavcodec/fft.h
+++ b/libavcodec/fft.h
@@ -114,7 +114,7 @@ void ff_init_ff_cos_tabs(int index);
 #endif
 
 #define COSTABLE(size) \
-COSTABLE_CONST DECLARE_ALIGNED(32, FFTSample, 
FFT_NAME(ff_cos_##size))[size/2]
+COSTABLE_CONST attribute_visibility_hidden DECLARE_ALIGNED(32, FFTSample, 
FFT_NAME(ff_cos_##size))[size/2]
 
 extern COSTABLE(16);
 extern COSTABLE(32);
diff --git a/libavcodec/vp9dsp.h b/libavcodec/vp9dsp.h
index 700dd72de8..13117fe9bc 100644
--- a/libavcodec/vp9dsp.h
+++ b/libavcodec/vp9dsp.h
@@ -120,7 +120,7 @@ typedef struct VP9DSPContext {
 vp9_scaled_mc_func smc[5][N_FILTERS][2];
 } VP9DSPContext;
 
-extern const int16_t ff_vp9_subpel_filters[3][16][8];
+extern const int16_t attribute_visibility_hidden 
ff_vp9_subpel_filters[3][16][8];
 
 void ff_vp9dsp_init(VP9DSPContext *dsp, int bpp, int bitexact);
 
diff --git a/libavutil/internal.h b/libavutil/internal.h
index b44cbaaa7b..36afc4687f 100644
--- a/libavutil/internal.h
+++ b/libavutil/internal.h
@@ -61,6 +61,12 @@
 #endif
 #endif
 
+#if (AV_GCC_VERSION_AT_LEAST(4,0) || defined(__clang__)) && (defined(__ELF__) 
|| defined(__MACH__))
+#define attribute_visibility_hidden __attribute__((visibility("hidden")))
+#else
+#define attribute_visibility_hidden
+#endif
+
 #if defined(_WIN32) && CONFIG_SHARED && !defined(BUILDING_avutil)
 #define av_export_avutil __declspec(dllimport)
 #else
-- 
2.25.1

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

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

[FFmpeg-devel] [PATCH 5/5] aarch64: me_cmp: Don't do uaddlv once per iteration

[Martin Storsjö]

The max height is 16; the max difference per pixel is 255, and
a .8h element can easily contain 16*255, thus keep accumulating
in two .8h vectors, and just do the final accumulation at the
end.

This requires a minor register renumbering in ff_pix_abs16_xy2_neon.

Before:   Cortex A53A72A73   Graviton 3
pix_abs_0_0_neon:   97.7   47.0   37.5   22.7
pix_abs_0_1_neon:  154.0   59.0   52.0   25.0
pix_abs_0_3_neon:  179.7   96.7   87.5   41.2
After:
pix_abs_0_0_neon:   96.0   39.2   31.2   22.0
pix_abs_0_1_neon:  150.7   59.7   46.2   23.7
pix_abs_0_3_neon:  175.7   83.7   81.7   38.2

---
I remember suggesting this before, and having it dismissed for
some reason I don't remember - maybe that the element size wasn't
big enough to hold the intermediate results? At least as far as I
can see, it can hold the results just fine, and this passes all
tests.
---
 libavcodec/aarch64/me_cmp_neon.S | 102 +++
 1 file changed, 49 insertions(+), 53 deletions(-)

diff --git a/libavcodec/aarch64/me_cmp_neon.S b/libavcodec/aarch64/me_cmp_neon.S
index 89546869fb..cda7ce0408 100644
--- a/libavcodec/aarch64/me_cmp_neon.S
+++ b/libavcodec/aarch64/me_cmp_neon.S
@@ -27,15 +27,16 @@ function ff_pix_abs16_neon, export=1
 // x3   ptrdiff_t stride
 // w4   int h
 cmp w4, #4  // if h < 4, jump to 
completion section
-moviv18.4S, #0  // clear result accumulator
+moviv16.8h, #0  // clear result accumulator
+moviv17.8h, #0  // clear result accumulator
 b.lt2f
 1:
 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
-uabdl   v16.8h, v0.8b, v4.8b// absolute difference 
accumulate
-uabdl2  v17.8h, v0.16b, v4.16b
+uabal   v16.8h, v0.8b, v4.8b// absolute difference 
accumulate
+uabal2  v17.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 
accumulate
@@ -48,27 +49,26 @@ function ff_pix_abs16_neon, export=1
 uabal   v16.8h, v3.8b, v7.8b
 uabal2  v17.8h, v3.16b, v7.16b
 cmp w4, #4  // if h >= 4, loop
-add v16.8h, v16.8h, v17.8h
-uaddlv  s16, v16.8h // add up everything in 
v16 accumulator
-add d18, d16, d18   // add to the end result 
register
 
 b.ge1b
 cbnzw4, 2f  // if iterations remain, 
jump to completion section
 
-fmovw0, s18 // copy result to general 
purpose register
+add v16.8h, v16.8h, v17.8h
+uaddlv  s16, v16.8h // add up everything in 
v16 accumulator
+fmovw0, s16 // copy result to general 
purpose register
 ret
 
 2:
 ld1 {v0.16b}, [x1], x3  // load pix1
 ld1 {v4.16b}, [x2], x3  // load pix2
-uabdl   v16.8h, v0.8b, v4.8b// absolute difference 
accumulate
-uabal2  v16.8h, v0.16b, v4.16b
 subsw4, w4, #1  // h -= 1
-addvh16, v16.8h // add up v16
-add d18, d16, d18   // add to result
+uabal   v16.8h, v0.8b, v4.8b// absolute difference 
accumulate
+uabal2  v17.8h, v0.16b, v4.16b
 b.ne2b
 
-fmovw0, s18 // copy result to general 
purpose register
+add v16.8h, v16.8h, v17.8h
+uaddlv  s16, v16.8h // add up everything in 
v16 accumulator
+fmovw0, s16 // copy result to general 
purpose register
 ret
 endfunc
 
@@ -80,7 +80,8 @@ function ff_pix_abs16_xy2_neon, export=1
 // w4   int h
 
 add x5, x2, x3  // use x5 to hold uint8_t 
*pix3
-moviv0.2d, #0   // initialize the result 
register
+moviv21.8h, #0  // initialize the result 
register
+moviv22.8h, #0  // initialize the result 
register
 
 // Load initial pix2 values for either the unrolled version or 
completion version.
 ldurq4, [x2, #1]// load pix2+1
@@ 

[FFmpeg-devel] [PATCH 4/5] aarch64: me_cmp: Switch from uabd to uabal in ff_pix_abs16_xy2_neon

[Martin Storsjö]

Using absolute-difference-accumulate does use twice the amount of
absolute-difference instructions, but avoids the need for the
uaddl and add instructions, reducing the total number of instructions
by 3.

These can be interleaved in the rest of the calculation, to avoid
tight dependencies at the end. Unfortunately, this is marginally
slower on Cortex A53, but faster on A72 and A73.

Before:   Cortex A53A72A73   Graviton 3
pix_abs_0_3_neon:  175.7  109.2   92.0   41.2
After:
pix_abs_0_3_neon:  179.7   96.7   87.5   41.2
---
 libavcodec/aarch64/me_cmp_neon.S | 32 +++-
 1 file changed, 11 insertions(+), 21 deletions(-)

diff --git a/libavcodec/aarch64/me_cmp_neon.S b/libavcodec/aarch64/me_cmp_neon.S
index 0ae23d8922..89546869fb 100644
--- a/libavcodec/aarch64/me_cmp_neon.S
+++ b/libavcodec/aarch64/me_cmp_neon.S
@@ -124,6 +124,9 @@ function ff_pix_abs16_xy2_neon, export=1
 add v26.8h, v30.8h, v2.8h   // add up 0..7, using pix2 
+ pix2+1 values from pix3 above
 add v27.8h, v31.8h, v3.8h   // add up 8..15, using 
pix2 + pix2+1 values from pix3 above
 
+uabdl   v24.8h, v1.8b,  v23.8b  // absolute difference 
0..7, i=0
+uabdl2  v23.8h, v1.16b, v23.16b // absolute difference 
8..15, i=0
+
 ld1 {v21.16b}, [x5], x3 // load pix3
 ld1 {v20.16b}, [x1], x3 // load pix1
 
@@ -137,6 +140,9 @@ function ff_pix_abs16_xy2_neon, export=1
 rshrn   v28.8b, v28.8h, #2  // shift right 2 0..7 
(rounding shift right)
 rshrn2  v28.16b, v29.8h, #2 // shift right 2 8..15
 
+uabal   v24.8h, v16.8b,  v26.8b // absolute difference 
0..7, i=1
+uabal2  v23.8h, v16.16b, v26.16b// absolute difference 
8..15, i=1
+
 uaddl   v2.8h, v21.8b, v22.8b   // pix3 + pix3+1 0..7
 uaddl2  v3.8h, v21.16b, v22.16b // pix3 + pix3+1 8..15
 add v30.8h, v4.8h, v2.8h// add up 0..7, using pix2 
+ pix2+1 values from pix3 above
@@ -144,33 +150,17 @@ function ff_pix_abs16_xy2_neon, export=1
 rshrn   v30.8b, v30.8h, #2  // shift right 2 0..7 
(rounding shift right)
 rshrn2  v30.16b, v31.8h, #2 // shift right 2 8..15
 
-// Averages are now stored in these registers:
-// v23, v16, v28, v30
-// pix1 values in these registers:
-// v1, v16, v17, v20
-// available:
-// v4, v5, v7, v18, v19, v24, v25, v27, v29, v31
+uabal   v24.8h, v17.8b,  v28.8b // absolute difference 
0..7, i=2
+uabal2  v23.8h, v17.16b, v28.16b// absolute difference 
8..15, i=2
 
 sub w4, w4, #4  // h -= 4
 
-// Using absolute-difference instructions instead of 
absolute-difference-accumulate allows
-// us to keep the results in 16b vectors instead of widening values 
with twice the instructions.
-// This approach also has fewer data dependencies, allowing better 
instruction level parallelism.
-uabdv4.16b, v1.16b, v23.16b // absolute difference 
0..15, i=0
-uabdv5.16b, v16.16b, v26.16b// absolute difference 
0..15, i=1
-uabdv6.16b, v17.16b, v28.16b// absolute difference 
0..15, i=2
-uabdv7.16b, v20.16b, v30.16b// absolute difference 
0..15, i=3
+uabal   v24.8h, v20.8b,  v30.8b // absolute difference 
0..7, i=3
+uabal2  v23.8h, v20.16b, v30.16b// absolute difference 
8..15, i=3
 
 cmp w4, #4  // loop if h >= 4
 
-// Now add up all the values in each vector, v4-v7 with widening adds
-uaddl   v19.8h, v4.8b, v5.8b
-uaddl2  v18.8h, v4.16b, v5.16b
-uaddl   v4.8h, v6.8b, v7.8b
-uaddl2  v5.8h, v6.16b, v7.16b
-add v4.8h, v4.8h, v5.8h
-add v4.8h, v4.8h, v18.8h
-add v4.8h, v4.8h, v19.8h
+add v4.8h, v23.8h, v24.8h
 uaddlv  s4, v4.8h   // finish adding up 
accumulated values
 add d0, d0, d4  // add the value to the 
top level accumulator
 
-- 
2.25.1

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

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

[FFmpeg-devel] [PATCH 3/5] aarch64: me_cmp: Interleave some of the loads in ff_pix_abs16_xy2_neon

[Martin Storsjö]

Before:   Cortex A53A72A73   Graviton 3
pix_abs_0_3_neon:  183.7  112.7   97.5   41.2
After:
pix_abs_0_3_neon:  175.7  109.2   92.0   41.2
---
 libavcodec/aarch64/me_cmp_neon.S | 22 ++
 1 file changed, 14 insertions(+), 8 deletions(-)

diff --git a/libavcodec/aarch64/me_cmp_neon.S b/libavcodec/aarch64/me_cmp_neon.S
index 31db3793d9..0ae23d8922 100644
--- a/libavcodec/aarch64/me_cmp_neon.S
+++ b/libavcodec/aarch64/me_cmp_neon.S
@@ -101,26 +101,32 @@ function ff_pix_abs16_xy2_neon, export=1
 ld1 {v6.16b}, [x5], x3  // load pix3
 ld1 {v16.16b}, [x1], x3 // load pix1
 
-ldurq19, [x5, #1]   // load pix3+1
-ld1 {v18.16b}, [x5], x3 // load pix3
-ld1 {v17.16b}, [x1], x3 // load pix1
-
-ldurq22, [x5, #1]   // load pix3+1
-ld1 {v21.16b}, [x5], x3 // load pix3
-ld1 {v20.16b}, [x1], x3 // load pix1
-
 // These blocks compute the average: avg(pix2[n], pix2[n+1], pix3[n], 
pix3[n+1])
 uaddl   v30.8h, v4.8b, v5.8b// pix3 + pix3+1 0..7
 uaddl2  v31.8h, v4.16b, v5.16b  // pix3 + pix3+1 8..15
+
+ldurq19, [x5, #1]   // load pix3+1
+
 add v23.8h, v2.8h, v30.8h   // add up 0..7, using pix2 
+ pix2+1 values from previous iteration
 add v24.8h, v3.8h, v31.8h   // add up 8..15, using 
pix2 + pix2+1 values from previous iteration
+
+ld1 {v18.16b}, [x5], x3 // load pix3
+ld1 {v17.16b}, [x1], x3 // load pix1
+
 rshrn   v23.8b, v23.8h, #2  // shift right 2 0..7 
(rounding shift right)
 rshrn2  v23.16b, v24.8h, #2 // shift right 2 8..15
 
 uaddl   v2.8h, v6.8b, v7.8b // pix3 + pix3+1 0..7
 uaddl2  v3.8h, v6.16b, v7.16b   // pix3 + pix3+1 8..15
+
+ldurq22, [x5, #1]   // load pix3+1
+
 add v26.8h, v30.8h, v2.8h   // add up 0..7, using pix2 
+ pix2+1 values from pix3 above
 add v27.8h, v31.8h, v3.8h   // add up 8..15, using 
pix2 + pix2+1 values from pix3 above
+
+ld1 {v21.16b}, [x5], x3 // load pix3
+ld1 {v20.16b}, [x1], x3 // load pix1
+
 rshrn   v26.8b, v26.8h, #2  // shift right 2 0..7 
(rounding shift right)
 rshrn2  v26.16b, v27.8h, #2 // shift right 2 8..15
 
-- 
2.25.1

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

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

[FFmpeg-devel] [PATCH 2/5] checkasm: motion: Make the benchmarks more stable

[Martin Storsjö]

Don't use the last random offset, but a static one.
---
 tests/checkasm/motion.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/tests/checkasm/motion.c b/tests/checkasm/motion.c
index 79e4358941..87b20d1c10 100644
--- a/tests/checkasm/motion.c
+++ b/tests/checkasm/motion.c
@@ -81,7 +81,8 @@ static void test_motion(const char *name, me_cmp_func 
test_func)
 break;
 }
 }
-// benchmark with the final value of ptr
+// Test with a fixed offset, for benchmark stability
+ptr = img2 + 3 * WIDTH + 3;
 bench_new(NULL, img1, ptr, WIDTH, 8);
 }
 }
-- 
2.25.1

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

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

[FFmpeg-devel] [PATCH 1/5] libavcodec: aarch64: Don't clobber v8 in the h%4 case in ff_pix_abs16_xy2_neon

[Martin Storsjö]

Checkasm doesn't currently test this codepath.
---
 libavcodec/aarch64/me_cmp_neon.S | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/libavcodec/aarch64/me_cmp_neon.S b/libavcodec/aarch64/me_cmp_neon.S
index e49d049fc2..31db3793d9 100644
--- a/libavcodec/aarch64/me_cmp_neon.S
+++ b/libavcodec/aarch64/me_cmp_neon.S
@@ -189,11 +189,11 @@ function ff_pix_abs16_xy2_neon, export=1
 urshr   v16.8h, v16.8h, #2  // shift right by 2 0..7 
(rounding shift right)
 urshr   v17.8h, v17.8h, #2  // shift right by 2 8..15
 
-uxtl2   v8.8h, v1.16b   // 8->16 bits pix1 8..15
+uxtl2   v7.8h, v1.16b   // 8->16 bits pix1 8..15
 uxtlv1.8h, v1.8b// 8->16 bits pix1 0..7
 
 uabdv6.8h, v1.8h, v16.8h// absolute difference 0..7
-uabav6.8h, v8.8h, v17.8h// absolute difference 
accumulate 8..15
+uabav6.8h, v7.8h, v17.8h// absolute difference 
accumulate 8..15
 mov v2.16b, v18.16b // pix3 -> pix2
 mov v3.16b, v19.16b // pix3+1 -> pix2+1
 uaddlv  s6, v6.8h   // add up accumulator in v6
-- 
2.25.1

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

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

[FFmpeg-devel] [PATCH 2/2] RFC: checkasm: motion: Test different h parameters

[Martin Storsjö]

Previously, the checkasm test always passed h=8, so no other cases
were tested.

Out of the me_cmp functions, in practice, some functions are hardcoded
to always assume a 8x8 block (ignoring the h parameter), while others
do use the parameter. For those with hardcoded height, both the
reference C function and the assembly implementations ignore the
parameter similarly.

The documentation for the functions indicate that heights between
w/2 and 2*w, within the range of 4 to 16, should be supported. This
patch just tests random heights in that range, without knowing what
width the current function actually uses.
---
I'm not sure if it's good to have checkasm exercise cases that
don't occur in practice or not. In particular, the aarch64
functions have a separate implementation for non-multiple-of-4
height, which probably doesn't ever get called in practice, while
other SIMD implementations lack that.

Alternatively, we'd improve the documentation for the expectations
for these functions and make the test match that, and remove the
unused non-multiple-of-4 case in the aarch64 assembly.
---
 tests/checkasm/motion.c | 10 ++
 1 file changed, 6 insertions(+), 4 deletions(-)

diff --git a/tests/checkasm/motion.c b/tests/checkasm/motion.c
index 0112822174..79e4358941 100644
--- a/tests/checkasm/motion.c
+++ b/tests/checkasm/motion.c
@@ -45,7 +45,7 @@ static void test_motion(const char *name, me_cmp_func 
test_func)
 /* motion estimation can look up to 17 bytes ahead */
 static const int look_ahead = 17;
 
-int i, x, y, d1, d2;
+int i, x, y, h, d1, d2;
 uint8_t *ptr;
 
 LOCAL_ALIGNED_16(uint8_t, img1, [WIDTH * HEIGHT]);
@@ -68,14 +68,16 @@ static void test_motion(const char *name, me_cmp_func 
test_func)
 for (i = 0; i < ITERATIONS; i++) {
 x = rnd() % (WIDTH - look_ahead);
 y = rnd() % (HEIGHT - look_ahead);
+// Pick a random h between 4 and 16; pick an even value.
+h = 4 + ((rnd() % (16 + 1 - 4)) & ~1);
 
 ptr = img2 + y * WIDTH + x;
-d2 = call_ref(NULL, img1, ptr, WIDTH, 8);
-d1 = call_new(NULL, img1, ptr, WIDTH, 8);
+d2 = call_ref(NULL, img1, ptr, WIDTH, h);
+d1 = call_new(NULL, img1, ptr, WIDTH, h);
 
 if (d1 != d2) {
 fail();
-printf("func: %s, x=%d y=%d, error: asm=%d c=%d\n", name, x, 
y, d1, d2);
+printf("func: %s, x=%d y=%d h=%d, error: asm=%d c=%d\n", name, 
x, y, h, d1, d2);
 break;
 }
 }
-- 
2.25.1

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

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

[FFmpeg-devel] [PATCH 1/2] x86: Don't hardcode the height to 8 in sad8_xy2_mmx

[Martin Storsjö]

The height is hardcoded in some of the me_cmp functions, but not
in all of them. But in the case of all other functions, it's hardcoded
in the same place in SIMD functions as in the C reference functions,
while this one function differs from the behaviour of the C code.

(Before 542765ce3eccbca587d54262a512cbdb1407230d, there were a
couple other sad8_*_mmx functions with similar hardcoded height.)
---
 libavcodec/x86/me_cmp_init.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/libavcodec/x86/me_cmp_init.c b/libavcodec/x86/me_cmp_init.c
index 61e9396b8f..dcc2621276 100644
--- a/libavcodec/x86/me_cmp_init.c
+++ b/libavcodec/x86/me_cmp_init.c
@@ -202,13 +202,12 @@ static inline int sum_mmx(void)
 static int sad8_xy2_ ## suf(MpegEncContext *v, uint8_t *blk2,   \
 uint8_t *blk1, ptrdiff_t stride, int h) \
 {   \
-av_assert2(h == 8); \
 __asm__ volatile (  \
 "pxor %%mm7, %%mm7 \n\t"\
 "pxor %%mm6, %%mm6 \n\t"\
 ::);\
 \
-sad8_4_ ## suf(blk1, blk2, stride, 8);  \
+sad8_4_ ## suf(blk1, blk2, stride, h);  \
 \
 return sum_ ## suf();   \
 }   \
-- 
2.25.1

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

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

Re: [FFmpeg-devel] [PATCH] lavc/aarch64: Add pix_abs16_x2 neon implementation

[Martin Storsjö]

On Tue, 12 Jul 2022, Hubert Mazur wrote:


Provide neon implementation for pix_abs16_x2 function.

Performance tests of implementation are below.
- pix_abs_0_1_c: 283.5
- pix_abs_0_1_neon: 39.0

Benchmarks and tests run with checkasm tool on AWS Graviton 3.

Signed-off-by: Hubert Mazur 
---
libavcodec/aarch64/me_cmp_init_aarch64.c |  3 +
libavcodec/aarch64/me_cmp_neon.S | 75 
2 files changed, 78 insertions(+)


Thanks, I think this looks good enough to me, thus 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".

[FFmpeg-devel] [PATCH] avcodec/aacdec: don't force HE-AACv2 profile if no PS info is present

[James Almer]

Should fix ticket #3361

Signed-off-by: James Almer 
---
This also needs an update to some fate ref samples i'll upload before pushing
(fate-aac-al_sbr_ps_04_ur and fate-aac-al_sbr_ps_06_ur which are now decoded
properly as he_aac mono, so the .s16 files need to be replaced).

 libavcodec/aacdec_template.c  | 15 ++-
 libavcodec/aacsbr_template.c  |  1 +
 tests/fate/gapless.mak| 14 +++---
 .../audiomatch-afconvert-16000-stereo-he2-adts|  2 +-
 4 files changed, 15 insertions(+), 17 deletions(-)

diff --git a/libavcodec/aacdec_template.c b/libavcodec/aacdec_template.c
index 10fba3d3b2..15c20c07d6 100644
--- a/libavcodec/aacdec_template.c
+++ b/libavcodec/aacdec_template.c
@@ -967,8 +967,7 @@ static int decode_ga_specific_config(AACContext *ac, 
AVCodecContext *avctx,
 
 if (count_channels(layout_map, tags) > 1) {
 m4ac->ps = 0;
-} else if (m4ac->sbr == 1 && m4ac->ps == -1)
-m4ac->ps = 1;
+}
 
 if (ac && (ret = output_configure(ac, layout_map, tags, OC_GLOBAL_HDR, 0)))
 return ret;
@@ -2572,18 +2571,16 @@ static int decode_extension_payload(AACContext *ac, 
GetBitContext *gb, int cnt,
 av_log(ac->avctx, AV_LOG_ERROR, "Implicit SBR was found with a 
first occurrence after the first frame.\n");
 skip_bits_long(gb, 8 * cnt - 4);
 return res;
-} else if (ac->oc[1].m4ac.ps == -1 && ac->oc[1].status < OC_LOCKED &&
-   ac->avctx->ch_layout.nb_channels == 1) {
-ac->oc[1].m4ac.sbr = 1;
-ac->oc[1].m4ac.ps = 1;
-ac->avctx->profile = FF_PROFILE_AAC_HE_V2;
-output_configure(ac, ac->oc[1].layout_map, 
ac->oc[1].layout_map_tags,
- ac->oc[1].status, 1);
 } else {
 ac->oc[1].m4ac.sbr = 1;
 ac->avctx->profile = FF_PROFILE_AAC_HE;
 }
 res = AAC_RENAME(ff_decode_sbr_extension)(ac, >sbr, gb, crc_flag, 
cnt, elem_type);
+if (ac->oc[1].m4ac.ps == 1 && ac->oc[1].status < OC_LOCKED &&
+ac->avctx->ch_layout.nb_channels == 1) {
+output_configure(ac, ac->oc[1].layout_map, 
ac->oc[1].layout_map_tags,
+ ac->oc[1].status, 1);
+}
 break;
 case EXT_DYNAMIC_RANGE:
 res = decode_dynamic_range(>che_drc, gb);
diff --git a/libavcodec/aacsbr_template.c b/libavcodec/aacsbr_template.c
index b72c94b76d..f9925b40e5 100644
--- a/libavcodec/aacsbr_template.c
+++ b/libavcodec/aacsbr_template.c
@@ -954,6 +954,7 @@ static void read_sbr_extension(AACContext *ac, 
SpectralBandReplication *sbr,
 *num_bits_left = 0;
 } else {
 *num_bits_left -= ff_ps_read_data(ac->avctx, gb, >ps.common, 
*num_bits_left);
+ac->oc[1].m4ac.ps = 1;
 ac->avctx->profile = FF_PROFILE_AAC_HE_V2;
 }
 break;
diff --git a/tests/fate/gapless.mak b/tests/fate/gapless.mak
index 68a396e187..7dd8ceb142 100644
--- a/tests/fate/gapless.mak
+++ b/tests/fate/gapless.mak
@@ -47,27 +47,27 @@ fate-audiomatch-square-aac: CMD = audio_match 
$(TARGET_SAMPLES)/audiomatch/squar
 
 fate-audiomatch-afconvert-16000-mono-lc-adts: CMD = audio_match 
$(TARGET_SAMPLES)/audiomatch/tones_afconvert_16000_mono_aac_lc.adts  
$(SAMPLES)/audiomatch/tones_16000_mono.wav
 fate-audiomatch-afconvert-16000-mono-lc-m4a:  CMD = audio_match 
$(TARGET_SAMPLES)/audiomatch/tones_afconvert_16000_mono_aac_lc.m4a   
$(SAMPLES)/audiomatch/tones_16000_mono.wav
-fate-audiomatch-afconvert-16000-mono-he-adts: CMD = audio_match 
$(TARGET_SAMPLES)/audiomatch/tones_afconvert_16000_mono_aac_he.adts  
$(SAMPLES)/audiomatch/tones_16000_mono.wav "-ac 1 -ar 16000"
-fate-audiomatch-afconvert-16000-mono-he-m4a:  CMD = audio_match 
$(TARGET_SAMPLES)/audiomatch/tones_afconvert_16000_mono_aac_he.m4a   
$(SAMPLES)/audiomatch/tones_16000_mono.wav "-ac 1 -ar 16000"
+fate-audiomatch-afconvert-16000-mono-he-adts: CMD = audio_match 
$(TARGET_SAMPLES)/audiomatch/tones_afconvert_16000_mono_aac_he.adts  
$(SAMPLES)/audiomatch/tones_16000_mono.wav "-ar 16000"
+fate-audiomatch-afconvert-16000-mono-he-m4a:  CMD = audio_match 
$(TARGET_SAMPLES)/audiomatch/tones_afconvert_16000_mono_aac_he.m4a   
$(SAMPLES)/audiomatch/tones_16000_mono.wav "-ar 16000"
 fate-audiomatch-afconvert-16000-stereo-lc-adts: CMD = audio_match 
$(TARGET_SAMPLES)/audiomatch/tones_afconvert_16000_stereo_aac_lc.adts  
$(SAMPLES)/audiomatch/tones_16000_stereo.wav
 fate-audiomatch-afconvert-16000-stereo-lc-m4a:  CMD = audio_match 
$(TARGET_SAMPLES)/audiomatch/tones_afconvert_16000_stereo_aac_lc.m4a   
$(SAMPLES)/audiomatch/tones_16000_stereo.wav
 fate-audiomatch-afconvert-16000-stereo-he-adts: CMD = audio_match 
$(TARGET_SAMPLES)/audiomatch/tones_afconvert_16000_stereo_aac_he.adts  
$(SAMPLES)/audiomatch/tones_16000_stereo.wav "-ar 16000"
 fate-audiomatch-afconvert-16000-stereo-he-m4a:  CMD = audio_match 

Re: [FFmpeg-devel] Performances improvement in "image_copy_plane"

[James Almer]

On 7/13/2022 12:54 PM, Marco Vianini wrote:

Sorry, my mail client was using html format.
I hope now the mail will be sent correctly.


You can get a very big improvement of performances in the special (but very likely) case of: 
"(dst_linesize == bytewidth && src_linesize == bytewidth)"

In this case in fact We can "Coalesce rows", that is using ONLY ONE MEMCPY, 
instead of a smaller memcpy for every row (that is looping for height times).

Code:
"
static void image_copy_plane(uint8_t       *dst, ptrdiff_t dst_linesize,
                              const uint8_t *src, ptrdiff_t src_linesize,
                              ptrdiff_t bytewidth, int height)
{
     if (!dst || !src)
         return;
     av_assert0(abs(src_linesize) >= bytewidth);
     av_assert0(abs(dst_linesize) >= bytewidth);
 
     /// MY PATCH START

     /// Coalesce rows.
     if (dst_linesize == bytewidth && src_linesize == bytewidth) {
       bytewidth *= height;
       height = 1;
       src_linesize = dst_linesize = 0;
     }
     /// MY PATCH STOP

     for (;height > 0; height--) {
         memcpy(dst, src, bytewidth);
         dst += dst_linesize;
         src += src_linesize;
     }
}
"


I did following tests on Windows 10 64bit.
I compiled code in Release.
I copied my pc camera frames 1000 times (resolution 1920x1080):

With Coalesce:
copy_cnt=100  size=1920x1080 tot_time_copy(us)=36574 (average=365.74)
copy_cnt=200  size=1920x1080 tot_time_copy(us)=78207 (average=391.035)
copy_cnt=300  size=1920x1080 tot_time_copy(us)=122170(average=407.233)
copy_cnt=400  size=1920x1080 tot_time_copy(us)=163678(average=409.195)
copy_cnt=500  size=1920x1080 tot_time_copy(us)=201872(average=403.744)
copy_cnt=600  size=1920x1080 tot_time_copy(us)=246174(average=410.29)
copy_cnt=700  size=1920x1080 tot_time_copy(us)=287043(average=410.061)
copy_cnt=800  size=1920x1080 tot_time_copy(us)=326462(average=408.077)
copy_cnt=900  size=1920x1080 tot_time_copy(us)=356882(average=396.536)
copy_cnt=1000 size=1920x1080 tot_time_copy(us)=394566(average=394.566)

Without Coalesce:
copy_cnt=100  size=1920x1080 tot_time_copy(us)=44303 (average=443.03)
copy_cnt=200  size=1920x1080 tot_time_copy(us)=100501(average=502.505)
copy_cnt=300  size=1920x1080 tot_time_copy(us)=150097(average=500.323)
copy_cnt=400  size=1920x1080 tot_time_copy(us)=201010(average=502.525)
copy_cnt=500  size=1920x1080 tot_time_copy(us)=256818(average=513.636)
copy_cnt=600  size=1920x1080 tot_time_copy(us)=303273(average=505.455)
copy_cnt=700  size=1920x1080 tot_time_copy(us)=359152(average=513.074)
copy_cnt=800  size=1920x1080 tot_time_copy(us)=414413(average=518.016)
copy_cnt=900  size=1920x1080 tot_time_copy(us)=465315(average=517.017)
copy_cnt=1000 size=1920x1080 tot_time_copy(us)=520381(average=520.381)


I think the results are very good.
What do you think about?


It looks like a good speed up, but we need a patch created with git 
format-patch that can be applied to the source tree to properly review 
this. Can you send that?

___
ffmpeg-devel mailing list
ffmpeg-devel@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/xstack: Add support for fixed size grid

[Vignesh Venkatasubramanian]

On Wed, Jul 13, 2022 at 9:08 AM Paul B Mahol  wrote:
>
>
> It is merged already.

Oops, sorry about that. Thanks for merging!

-- 
Vignesh
___
ffmpeg-devel mailing list
ffmpeg-devel@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/mov: Rework the AVIF parser to handle multiple items

[Vignesh Venkatasubramanian]

On Mon, Jul 11, 2022 at 3:25 PM James Zern
 wrote:
>
> On Thu, Jun 30, 2022 at 2:04 PM Vignesh Venkatasubramanian
>  wrote:
> >
> > Stores the item ids of all the items found in the file and
> > processes the primary item at the end of the meta box. This patch
> > does not change any behavior. It sets up the code for parsing
> > alpha channel (and possibly images with 'grid') in follow up
> > patches.
> >
> > Signed-off-by: Vignesh Venkatasubramanian 
> > ---
> >  libavformat/isom.h |   4 ++
> >  libavformat/mov.c  | 148 -
> >  2 files changed, 97 insertions(+), 55 deletions(-)
> >
> > [...]
>
> @@ -4692,9 +4755,25 @@ static int mov_read_meta(MOVContext *c,
> AVIOContext *pb, MOVAtom atom)
>  tag = avio_rl32(pb);
>  atom.size -= 4;
>  if (tag == MKTAG('h','d','l','r')) {
> +int ret;
>  avio_seek(pb, -8, SEEK_CUR);
>  atom.size += 8;
> -return mov_read_default(c, pb, atom);
> +ret = mov_read_default(c, pb, atom);
> +if (ret < 0)
>
> In some other cases these two lines are combined, if ((ret = ...
>

Done.

> +return ret;
> +if (c->is_still_picture_avif) {
> +int ret;
> +// Add a stream for the YUV planes (primary item).
> +ret = avif_add_stream(c, c->primary_item_id);
> +if (ret)
>
> This could be updated too and use '< 0' to match other code.
>

Done.

> +return ret;
> +// For still AVIF images, the meta box contains all the
> +// necessary information that would generally be
> provided by the
> +// moov box. So simply mark that we have found the moov box 
> so
> +// that parsing can continue.
> +c->found_moov = 1;
> +}
> +return ret;
>  }
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
> To unsubscribe, visit link above, or email
> ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".



-- 
Vignesh
___
ffmpeg-devel mailing list
ffmpeg-devel@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/mov: Rework the AVIF parser to handle multiple items

[Vignesh Venkatasubramanian]

Stores the item ids of all the items found in the file and
processes the primary item at the end of the meta box. This patch
does not change any behavior. It sets up the code for parsing
alpha channel (and possibly images with 'grid') in follow up
patches.

Signed-off-by: Vignesh Venkatasubramanian 
---
 libavformat/isom.h |   4 ++
 libavformat/mov.c  | 146 -
 2 files changed, 95 insertions(+), 55 deletions(-)

diff --git a/libavformat/isom.h b/libavformat/isom.h
index f05c2d9c28..d8b262e915 100644
--- a/libavformat/isom.h
+++ b/libavformat/isom.h
@@ -318,6 +318,10 @@ typedef struct MOVContext {
 uint32_t max_stts_delta;
 int is_still_picture_avif;
 int primary_item_id;
+int *avif_item_ids;
+int avif_item_ids_size;
+int *avif_extent_lengths;
+int64_t *avif_extent_offsets;
 } MOVContext;
 
 int ff_mp4_read_descr_len(AVIOContext *pb);
diff --git a/libavformat/mov.c b/libavformat/mov.c
index 88669faa70..cd87088f3e 100644
--- a/libavformat/mov.c
+++ b/libavformat/mov.c
@@ -4683,6 +4683,69 @@ static int mov_read_custom(MOVContext *c, AVIOContext 
*pb, MOVAtom atom)
 return ret;
 }
 
+static int avif_add_stream(MOVContext *c, int item_id)
+{
+MOVStreamContext *sc;
+AVStream *st;
+int item_index = -1;
+for (int i = 0; i < c->avif_item_ids_size; i++)
+if (c->avif_item_ids[i] == item_id) {
+item_index = i;
+break;
+}
+if (item_index < 0)
+return AVERROR_INVALIDDATA;
+st = avformat_new_stream(c->fc, NULL);
+if (!st)
+return AVERROR(ENOMEM);
+st->id = c->fc->nb_streams;
+sc = av_mallocz(sizeof(MOVStreamContext));
+if (!sc)
+return AVERROR(ENOMEM);
+
+st->priv_data = sc;
+st->codecpar->codec_type = AVMEDIA_TYPE_VIDEO;
+st->codecpar->codec_id = AV_CODEC_ID_AV1;
+sc->ffindex = st->index;
+c->trak_index = st->index;
+st->avg_frame_rate.num = st->avg_frame_rate.den = 1;
+st->time_base.num = st->time_base.den = 1;
+st->nb_frames = 1;
+sc->time_scale = 1;
+sc = st->priv_data;
+sc->pb = c->fc->pb;
+sc->pb_is_copied = 1;
+
+// Populate the necessary fields used by mov_build_index.
+sc->stsc_count = 1;
+sc->stsc_data = av_malloc_array(1, sizeof(*sc->stsc_data));
+if (!sc->stsc_data)
+return AVERROR(ENOMEM);
+sc->stsc_data[0].first = 1;
+sc->stsc_data[0].count = 1;
+sc->stsc_data[0].id = 1;
+sc->chunk_count = 1;
+sc->chunk_offsets = av_malloc_array(1, sizeof(*sc->chunk_offsets));
+if (!sc->chunk_offsets)
+return AVERROR(ENOMEM);
+sc->sample_count = 1;
+sc->sample_sizes = av_malloc_array(1, sizeof(*sc->sample_sizes));
+if (!sc->sample_sizes)
+return AVERROR(ENOMEM);
+sc->stts_count = 1;
+sc->stts_data = av_malloc_array(1, sizeof(*sc->stts_data));
+if (!sc->stts_data)
+return AVERROR(ENOMEM);
+sc->stts_data[0].count = 1;
+// Not used for still images. But needed by mov_build_index.
+sc->stts_data[0].duration = 0;
+sc->sample_sizes[0] = c->avif_extent_lengths[item_index];
+sc->chunk_offsets[0] = c->avif_extent_offsets[item_index];
+
+mov_build_index(c, st);
+return 0;
+}
+
 static int mov_read_meta(MOVContext *c, AVIOContext *pb, MOVAtom atom)
 {
 while (atom.size > 8) {
@@ -4692,9 +4755,23 @@ static int mov_read_meta(MOVContext *c, AVIOContext *pb, 
MOVAtom atom)
 tag = avio_rl32(pb);
 atom.size -= 4;
 if (tag == MKTAG('h','d','l','r')) {
+int ret;
 avio_seek(pb, -8, SEEK_CUR);
 atom.size += 8;
-return mov_read_default(c, pb, atom);
+if ((ret = mov_read_default(c, pb, atom)) < 0)
+return ret;
+if (c->is_still_picture_avif) {
+int ret;
+// Add a stream for the YUV planes (primary item).
+if ((ret = avif_add_stream(c, c->primary_item_id)) < 0)
+return ret;
+// For still AVIF images, the meta box contains all the
+// necessary information that would generally be provided by 
the
+// moov box. So simply mark that we have found the moov box so
+// that parsing can continue.
+c->found_moov = 1;
+}
+return ret;
 }
 }
 return 0;
@@ -7483,8 +7560,6 @@ static int mov_read_iloc(MOVContext *c, AVIOContext *pb, 
MOVAtom atom)
 int item_count, extent_count;
 uint64_t base_offset, extent_offset, extent_length;
 uint8_t value;
-AVStream *st;
-MOVStreamContext *sc;
 
 if (!c->is_still_picture_avif) {
 // * For non-avif, we simply ignore the iloc box.
@@ -7498,27 +7573,6 @@ static int mov_read_iloc(MOVContext *c, AVIOContext *pb, 
MOVAtom atom)
 return 0;
 }
 
-st = avformat_new_stream(c->fc, NULL);
-if (!st)
-return AVERROR(ENOMEM);
-

Re: [FFmpeg-devel] [PATCH] avfilter/xstack: Add support for fixed size grid

[Paul B Mahol]

It is merged already.
___
ffmpeg-devel mailing list
ffmpeg-devel@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/xstack: Add support for fixed size grid

[Vignesh Venkatasubramanian]

On Wed, Jun 29, 2022 at 10:15 AM Vignesh Venkatasubramanian
 wrote:
>
> On Wed, Jun 29, 2022 at 12:24 AM Paul B Mahol  wrote:
> >
> >
> >
> > On Wed, Jun 29, 2022 at 9:21 AM Paul B Mahol  wrote:
> >>
> >>
> >>
> >> On Tue, Jun 28, 2022 at 9:01 PM Vignesh Venkatasubramanian 
> >>  wrote:
> >>>
> >>> Add a short hand parameter for making a fixed size grid. The existing
> >>> xstack layout parameter syntax gets tedious if all one wants is a
> >>> matrix like grid of the input streams. Add a grid option to the xstack
> >>> filter that simplifies this use case by simply specifying the number of
> >>> rows and columns instead of specific x/y co-ordinate for each stream.
> >>
> >>
> >> Use SIZE AVOption for grid size option.
> >> As already done in tile filter.
>
> Ah, i did not know about this option. Updated.
>
> >
> >
> > Also there is no need to always force same size of frames in grid, can 
> > either force same width or same height.
> >
>
> I have relaxed the condition to "images within the same row must have
> same height (similar to hstack) and all rows must have the same width
> (similar to vstack)".
>
> > By default it can use grid option, (just set grid default to 2x1, and 
> > remove default layout setup thing)
>
> Done.
>
> >>
> >>
> >>
> >>
> >>>
> >>>
> >>> Also updating the filter documentation to explain the new option.
> >>>
> >>> Signed-off-by: Vignesh Venkatasubramanian 
> >>> ---
> >>>  doc/filters.texi   | 19 +--
> >>>  libavfilter/vf_stack.c | 73 --
> >>>  2 files changed, 81 insertions(+), 11 deletions(-)
> >>>
> >>> diff --git a/doc/filters.texi b/doc/filters.texi
> >>> index e525e87b3c..9d800a0fd6 100644
> >>> --- a/doc/filters.texi
> >>> +++ b/doc/filters.texi
> >>> @@ -24381,8 +24381,23 @@ the output video frame will be filled. 
> >>> Similarly, videos can overlap each
> >>>  other if their position doesn't leave enough space for the full frame of
> >>>  adjoining videos.
> >>>
> >>> -For 2 inputs, a default layout of @code{0_0|w0_0} is set. In all other 
> >>> cases,
> >>> -a layout must be set by the user.
> >>> +For 2 inputs, a default layout of @code{0_0|w0_0} is set. In all other 
> >>> cases, a
> >>> +layout or a grid must be set by the user. Either grid or layout option 
> >>> can be
> >>> +specified at a time. Specifying both will result in an error.
> >>> +
> >>> +@item grid
> >>> +Specify a fixed size grid of inputs.
> >>> +This option is used to create a fixed size grid of the input streams.  
> >>> The
> >>> +option is of the form x (e.g. 2x4). There must be  *
> >>> + input streams and they will be arranged as a grid with  
> >>> rows and
> >>> + columns. When using this option, all the input streams must 
> >>> have the
> >>> +same width and height.
> >>> +
> >>> +Either grid or layout option can be specified at a time. Specifying both 
> >>> will
> >>> +result in an error.
> >>> +
> >>> +If grid is set, then inputs option is ignored and is implicitly set to
> >>> +*.
> >>>
> >>>  @item shortest
> >>>  If set to 1, force the output to terminate when the shortest input
> >>> diff --git a/libavfilter/vf_stack.c b/libavfilter/vf_stack.c
> >>> index aa32a1bf5e..b38a193355 100644
> >>> --- a/libavfilter/vf_stack.c
> >>> +++ b/libavfilter/vf_stack.c
> >>> @@ -48,6 +48,9 @@ typedef struct StackContext {
> >>>  int is_vertical;
> >>>  int is_horizontal;
> >>>  int nb_planes;
> >>> +char *grid;
> >>> +int nb_grid_rows;
> >>> +int nb_grid_columns;
> >>>  uint8_t fillcolor[4];
> >>>  char *fillcolor_str;
> >>>  int fillcolor_enable;
> >>> @@ -85,14 +88,6 @@ static av_cold int init(AVFilterContext *ctx)
> >>>  if (!strcmp(ctx->filter->name, "hstack"))
> >>>  s->is_horizontal = 1;
> >>>
> >>> -s->frames = av_calloc(s->nb_inputs, sizeof(*s->frames));
> >>> -if (!s->frames)
> >>> -return AVERROR(ENOMEM);
> >>> -
> >>> -s->items = av_calloc(s->nb_inputs, sizeof(*s->items));
> >>> -if (!s->items)
> >>> -return AVERROR(ENOMEM);
> >>> -
> >>>  if (!strcmp(ctx->filter->name, "xstack")) {
> >>>  if (strcmp(s->fillcolor_str, "none") &&
> >>>  av_parse_color(s->fillcolor, s->fillcolor_str, -1, ctx) >= 
> >>> 0) {
> >>> @@ -100,7 +95,21 @@ static av_cold int init(AVFilterContext *ctx)
> >>>  } else {
> >>>  s->fillcolor_enable = 0;
> >>>  }
> >>> -if (!s->layout) {
> >>> +if (s->grid && s->layout) {
> >>> +av_log(ctx, AV_LOG_ERROR, "Both layout and grid were 
> >>> specified. Only one is allowed.\n");
> >>> +return AVERROR(EINVAL);
> >>> +}
> >>> +if (s->grid) {
> >>> +if (sscanf(s->grid, "%dx%d", >nb_grid_rows, 
> >>> >nb_grid_columns) != 2) {
> >>> +av_log(ctx, AV_LOG_ERROR, "grid string is not of the 
> >>> form rowsxcolumns.\n");
> >>> +return AVERROR(EINVAL);
> >>> +}
> >>> +s->nb_inputs 

Re: [FFmpeg-devel] Request: make framepool visible externally

[Marco Vianini]

On Wednesday, July 13, 2022 at 02:02:18 PM GMT+2, James Almer 
 wrote: 





On 7/13/2022 5:03 AM, Marco Vianini wrote:
>  Actually I was speaking about framepool, and not bufferpool.
> framepool is intended to get an "AVFrame *" from a pool, by 
> "ff_frame_pool_get".
> At the moment it is available only internally to "libavfilter".
> It permits an important improvement on performances, by using a pool. So it 
> should be very nice if I could use it in my own code.
> To be possible framepool.h should become a public header.
> Thank You

Please, do not top post in this list.

I know you want AVFrames. What i mean is that you should use the 
existing buffer pool API to achieve that. Write your own function that 
returns a freshly allocated AVFrame that fills the buf[] and data[] 
fields with buffers returned by av_buffer_pool_get() instead of 
av_buffer_alloc().

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

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


Sorry, I misunderstood what you mean with previous answer.
However Yes, surely I can write my own code (replicating what already done by 
framepool).
Thank You
___
ffmpeg-devel mailing list
ffmpeg-devel@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] Performances improvement in "image_copy_plane"

[Marco Vianini]

On Wednesday, July 13, 2022 at 05:08:27 PM GMT+2, Paul B Mahol 
 wrote: 





On Wed, Jul 13, 2022 at 5:02 PM Marco Vianini <
marco_vianini-at-yahoo...@ffmpeg.org> wrote:

>  I did following tests on Windows 10 64bit.I compiled code in Release.
> I copied my pc camera frames 1000 times (resolution 1920x1080):
> With Coalesce (MY PATCH):copy_cnt=100  size=1920x1080
> tot_time_copy(us)=36574 (average=365.74)copy_cnt=200  size=1920x1080
> tot_time_copy(us)=78207 (average=391.035)copy_cnt=300  size=1920x1080
> tot_time_copy(us)=122170(average=407.233)copy_cnt=400  size=1920x1080
> tot_time_copy(us)=163678(average=409.195)copy_cnt=500  size=1920x1080
> tot_time_copy(us)=201872(average=403.744)copy_cnt=600  size=1920x1080
> tot_time_copy(us)=246174(average=410.29)copy_cnt=700  size=1920x1080
> tot_time_copy(us)=287043(average=410.061)copy_cnt=800  size=1920x1080
> tot_time_copy(us)=326462(average=408.077)copy_cnt=900  size=1920x1080
> tot_time_copy(us)=356882(average=396.536)copy_cnt=1000 size=1920x1080
> tot_time_copy(us)=394566(average=394.566)
> Without Coalesce:copy_cnt=100  size=1920x1080 tot_time_copy(us)=44303
> (average=443.03)copy_cnt=200  size=1920x1080
> tot_time_copy(us)=100501(average=502.505)copy_cnt=300  size=1920x1080
> tot_time_copy(us)=150097(average=500.323)copy_cnt=400  size=1920x1080
> tot_time_copy(us)=201010(average=502.525)copy_cnt=500  size=1920x1080
> tot_time_copy(us)=256818(average=513.636)copy_cnt=600  size=1920x1080
> tot_time_copy(us)=303273(average=505.455)copy_cnt=700  size=1920x1080
> tot_time_copy(us)=359152(average=513.074)copy_cnt=800  size=1920x1080
> tot_time_copy(us)=414413(average=518.016)copy_cnt=900  size=1920x1080
> tot_time_copy(us)=465315(average=517.017)copy_cnt=1000 size=1920x1080
> tot_time_copy(us)=520381(average=520.381)
> I think the results are very good.What do you think about?
> Thank You
>
>
First stop top posting.

Where is patch?


>
>    Il mercoledì 13 luglio 2022 11:52:23 CEST, Paul B Mahol <
> one...@gmail.com> ha scritto:
>
>  On Wed, Jul 13, 2022 at 11:38 AM Marco Vianini <
> marco_vianini-at-yahoo...@ffmpeg.org> wrote:
>
> >  You can get a very big improvement of performances in the special (but
> > very likely) case of: "(dst_linesize == bytewidth && src_linesize ==
> > bytewidth)"
> >
> > In this case in fact We can "Coalesce rows", that is using ONLY ONE
> > MEMCPY, instead of a smaller memcpy for every row (that is looping for
> > height times).
> >
> > Code:"static void image_copy_plane(uint8_t      *dst, ptrdiff_t
> > dst_linesize,                            const uint8_t *src, ptrdiff_t
> > src_linesize,                            ptrdiff_t bytewidth, int
> > height){    if (!dst || !src)        return;
> > av_assert0(abs(src_linesize) >= bytewidth);
> av_assert0(abs(dst_linesize)
> > >= bytewidth); // MY PATCH START    // Coalesce rows.    if (dst_linesize
> > == bytewidth && src_linesize == bytewidth) {      bytewidth *= height;
> > height = 1;      src_linesize = dst_linesize = 0;    }// MY PATCH STOP
> >    for (;height > 0; height--) {        memcpy(dst, src, bytewidth);
> >  dst += dst_linesize;        src += src_linesize;    }}"
> > What do You think about?Thank You
> >
>
> Show the benchmark numbers.
>
>
> > Marco Vianini
> > ___
> > ffmpeg-devel mailing list
> > ffmpeg-devel@ffmpeg.org
> > https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> >
> > To unsubscribe, visit link above, or email
> > ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
> >
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
> To unsubscribe, visit link above, or email
> ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

>
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@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".


Sorry, my mail client was using html format.
I hope now the mail will be sent correctly.


You can get a very big improvement of performances in the special (but very 
likely) case of: "(dst_linesize == bytewidth && src_linesize == bytewidth)"

In this case in fact We can "Coalesce rows", that is using ONLY ONE MEMCPY, 
instead of a smaller memcpy for every row (that is looping for height times).

Code:
"
static void image_copy_plane(uint8_t       *dst, ptrdiff_t dst_linesize,
                             const uint8_t *src, ptrdiff_t src_linesize,
                             ptrdiff_t bytewidth, int height)
{
    if (!dst || !src)
        return;
    

Re: [FFmpeg-devel] Performances improvement in "image_copy_plane"

[Timo Rothenpieler]

On 13.07.2022 11:38, Marco Vianini wrote:

  You can get a very big improvement of performances in the special (but very likely) case of: 
"(dst_linesize == bytewidth && src_linesize == bytewidth)"


Isn't all that matters dst_linesize == src_linesize, and then you can 
memcpy() the whole plane?



In this case in fact We can "Coalesce rows", that is using ONLY ONE MEMCPY, 
instead of a smaller memcpy for every row (that is looping for height times).

Code:"static void image_copy_plane(uint8_t       *dst, ptrdiff_t dst_linesize,                
             const uint8_t *src, ptrdiff_t src_linesize,                             ptrdiff_t 
bytewidth, int height){    if (!dst || !src)        return;    av_assert0(abs(src_linesize) >= 
bytewidth);    av_assert0(abs(dst_linesize) >= bytewidth); // MY PATCH START    // Coalesce 
rows.    if (dst_linesize == bytewidth && src_linesize == bytewidth) {      bytewidth *= 
height;      height = 1;      src_linesize = dst_linesize = 0;    }// MY PATCH STOP
     for (;height > 0; height--) {        memcpy(dst, src, bytewidth);        dst += 
dst_linesize;        src += src_linesize;    }}"
What do You think about?Thank You
Marco Vianini


That code is mangled by your mail client and practically unreadable.
___
ffmpeg-devel mailing list
ffmpeg-devel@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] Performances improvement in "image_copy_plane"

[Paul B Mahol]

On Wed, Jul 13, 2022 at 5:02 PM Marco Vianini <
marco_vianini-at-yahoo...@ffmpeg.org> wrote:

>  I did following tests on Windows 10 64bit.I compiled code in Release.
> I copied my pc camera frames 1000 times (resolution 1920x1080):
> With Coalesce (MY PATCH):copy_cnt=100  size=1920x1080
> tot_time_copy(us)=36574 (average=365.74)copy_cnt=200  size=1920x1080
> tot_time_copy(us)=78207 (average=391.035)copy_cnt=300  size=1920x1080
> tot_time_copy(us)=122170(average=407.233)copy_cnt=400  size=1920x1080
> tot_time_copy(us)=163678(average=409.195)copy_cnt=500  size=1920x1080
> tot_time_copy(us)=201872(average=403.744)copy_cnt=600  size=1920x1080
> tot_time_copy(us)=246174(average=410.29)copy_cnt=700  size=1920x1080
> tot_time_copy(us)=287043(average=410.061)copy_cnt=800  size=1920x1080
> tot_time_copy(us)=326462(average=408.077)copy_cnt=900  size=1920x1080
> tot_time_copy(us)=356882(average=396.536)copy_cnt=1000 size=1920x1080
> tot_time_copy(us)=394566(average=394.566)
> Without Coalesce:copy_cnt=100  size=1920x1080 tot_time_copy(us)=44303
> (average=443.03)copy_cnt=200  size=1920x1080
> tot_time_copy(us)=100501(average=502.505)copy_cnt=300  size=1920x1080
> tot_time_copy(us)=150097(average=500.323)copy_cnt=400  size=1920x1080
> tot_time_copy(us)=201010(average=502.525)copy_cnt=500  size=1920x1080
> tot_time_copy(us)=256818(average=513.636)copy_cnt=600  size=1920x1080
> tot_time_copy(us)=303273(average=505.455)copy_cnt=700  size=1920x1080
> tot_time_copy(us)=359152(average=513.074)copy_cnt=800  size=1920x1080
> tot_time_copy(us)=414413(average=518.016)copy_cnt=900  size=1920x1080
> tot_time_copy(us)=465315(average=517.017)copy_cnt=1000 size=1920x1080
> tot_time_copy(us)=520381(average=520.381)
> I think the results are very good.What do you think about?
> Thank You
>
>
First stop top posting.

Where is patch?


>
> Il mercoledì 13 luglio 2022 11:52:23 CEST, Paul B Mahol <
> one...@gmail.com> ha scritto:
>
>  On Wed, Jul 13, 2022 at 11:38 AM Marco Vianini <
> marco_vianini-at-yahoo...@ffmpeg.org> wrote:
>
> >  You can get a very big improvement of performances in the special (but
> > very likely) case of: "(dst_linesize == bytewidth && src_linesize ==
> > bytewidth)"
> >
> > In this case in fact We can "Coalesce rows", that is using ONLY ONE
> > MEMCPY, instead of a smaller memcpy for every row (that is looping for
> > height times).
> >
> > Code:"static void image_copy_plane(uint8_t  *dst, ptrdiff_t
> > dst_linesize,const uint8_t *src, ptrdiff_t
> > src_linesize,ptrdiff_t bytewidth, int
> > height){if (!dst || !src)return;
> > av_assert0(abs(src_linesize) >= bytewidth);
> av_assert0(abs(dst_linesize)
> > >= bytewidth); // MY PATCH START// Coalesce rows.if (dst_linesize
> > == bytewidth && src_linesize == bytewidth) {  bytewidth *= height;
> > height = 1;  src_linesize = dst_linesize = 0;}// MY PATCH STOP
> >for (;height > 0; height--) {memcpy(dst, src, bytewidth);
> >  dst += dst_linesize;src += src_linesize;}}"
> > What do You think about?Thank You
> >
>
> Show the benchmark numbers.
>
>
> > Marco Vianini
> > ___
> > ffmpeg-devel mailing list
> > ffmpeg-devel@ffmpeg.org
> > https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> >
> > To unsubscribe, visit link above, or email
> > ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
> >
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
> To unsubscribe, visit link above, or email
> ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
>
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@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] Performances improvement in "image_copy_plane"

[Marco Vianini]

 I did following tests on Windows 10 64bit.I compiled code in Release.
I copied my pc camera frames 1000 times (resolution 1920x1080):
With Coalesce (MY PATCH):copy_cnt=100  size=1920x1080 tot_time_copy(us)=36574 
(average=365.74)copy_cnt=200  size=1920x1080 tot_time_copy(us)=78207 
(average=391.035)copy_cnt=300  size=1920x1080 
tot_time_copy(us)=122170(average=407.233)copy_cnt=400  size=1920x1080 
tot_time_copy(us)=163678(average=409.195)copy_cnt=500  size=1920x1080 
tot_time_copy(us)=201872(average=403.744)copy_cnt=600  size=1920x1080 
tot_time_copy(us)=246174(average=410.29)copy_cnt=700  size=1920x1080 
tot_time_copy(us)=287043(average=410.061)copy_cnt=800  size=1920x1080 
tot_time_copy(us)=326462(average=408.077)copy_cnt=900  size=1920x1080 
tot_time_copy(us)=356882(average=396.536)copy_cnt=1000 size=1920x1080 
tot_time_copy(us)=394566(average=394.566)
Without Coalesce:copy_cnt=100  size=1920x1080 tot_time_copy(us)=44303 
(average=443.03)copy_cnt=200  size=1920x1080 
tot_time_copy(us)=100501(average=502.505)copy_cnt=300  size=1920x1080 
tot_time_copy(us)=150097(average=500.323)copy_cnt=400  size=1920x1080 
tot_time_copy(us)=201010(average=502.525)copy_cnt=500  size=1920x1080 
tot_time_copy(us)=256818(average=513.636)copy_cnt=600  size=1920x1080 
tot_time_copy(us)=303273(average=505.455)copy_cnt=700  size=1920x1080 
tot_time_copy(us)=359152(average=513.074)copy_cnt=800  size=1920x1080 
tot_time_copy(us)=414413(average=518.016)copy_cnt=900  size=1920x1080 
tot_time_copy(us)=465315(average=517.017)copy_cnt=1000 size=1920x1080 
tot_time_copy(us)=520381(average=520.381)
I think the results are very good.What do you think about?
Thank You


Il mercoledì 13 luglio 2022 11:52:23 CEST, Paul B Mahol  
ha scritto:  
 
 On Wed, Jul 13, 2022 at 11:38 AM Marco Vianini <
marco_vianini-at-yahoo...@ffmpeg.org> wrote:

>  You can get a very big improvement of performances in the special (but
> very likely) case of: "(dst_linesize == bytewidth && src_linesize ==
> bytewidth)"
>
> In this case in fact We can "Coalesce rows", that is using ONLY ONE
> MEMCPY, instead of a smaller memcpy for every row (that is looping for
> height times).
>
> Code:"static void image_copy_plane(uint8_t      *dst, ptrdiff_t
> dst_linesize,                            const uint8_t *src, ptrdiff_t
> src_linesize,                            ptrdiff_t bytewidth, int
> height){    if (!dst || !src)        return;
> av_assert0(abs(src_linesize) >= bytewidth);    av_assert0(abs(dst_linesize)
> >= bytewidth); // MY PATCH START    // Coalesce rows.    if (dst_linesize
> == bytewidth && src_linesize == bytewidth) {      bytewidth *= height;
> height = 1;      src_linesize = dst_linesize = 0;    }// MY PATCH STOP
>    for (;height > 0; height--) {        memcpy(dst, src, bytewidth);
>  dst += dst_linesize;        src += src_linesize;    }}"
> What do You think about?Thank You
>

Show the benchmark numbers.


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

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
  
___
ffmpeg-devel mailing list
ffmpeg-devel@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/9] lavfi: use AVFrame.duration instead of AVFrame.pkt_duration

[Nicolas George]

Anton Khirnov (12022-07-13):
> ---
>  doc/filters.texi|  2 +-
>  libavfilter/buffersrc.c |  7 +++
>  libavfilter/f_loop.c| 14 ++
>  libavfilter/vf_deshake_opencl.c |  7 +++
>  libavfilter/vf_drawtext.c   | 16 
>  5 files changed, 45 insertions(+), 1 deletion(-)

No objection from me.

But pkt_duration is mostly unused in libavfilter: the authoritative
information about a packet duration is given by the timestamp of the
next packet. What f_loop and vf_deshake_opencl currently do is slightly
bogus.

Regards,

-- 
  Nicolas George


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

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

Re: [FFmpeg-devel] [PATCH 1/3] avformat/mxfdec: SMPTE RDD 48:2018 support

[Dave Rice]

> On Jul 11, 2022, at 5:44 PM, Michael Niedermayer  
> wrote:
> 
> Signed-off-by: Michael Niedermayer 
> ---
> libavformat/mxf.c|  3 +++
> libavformat/mxf.h|  1 +
> libavformat/mxfdec.c | 48 
> 3 files changed, 52 insertions(+)
> 
> diff --git a/libavformat/mxf.c b/libavformat/mxf.c
> index 36d662b58c..8ef928b8fc 100644
> --- a/libavformat/mxf.c
> +++ b/libavformat/mxf.c
> @@ -66,6 +66,9 @@ const MXFCodecUL ff_mxf_codec_uls[] = {
> { { 
> 0x06,0x0E,0x2B,0x34,0x04,0x01,0x01,0x0A,0x04,0x01,0x02,0x01,0x01,0x02,0x02,0x01
>  }, 16,   AV_CODEC_ID_V210 }, /* V210 */
> { { 
> 0x06,0x0E,0x2B,0x34,0x04,0x01,0x01,0x01,0x0E,0x04,0x02,0x01,0x02,0x11,0x00,0x00
>  }, 14, AV_CODEC_ID_PRORES }, /* Avid MC7 ProRes */
> { { 
> 0x06,0x0E,0x2B,0x34,0x04,0x01,0x01,0x0D,0x04,0x01,0x02,0x02,0x03,0x06,0x00,0x00
>  }, 14, AV_CODEC_ID_PRORES }, /* Apple ProRes */
> +{ { 
> 0x06,0x0e,0x2b,0x34,0x04,0x01,0x01,0x0D,0x04,0x01,0x02,0x02,0x03,0x09,0x01,0x00
>  }, 15,   AV_CODEC_ID_FFV1 }, /*FFV1 V0 */
> +{ { 
> 0x06,0x0e,0x2b,0x34,0x04,0x01,0x01,0x0D,0x04,0x01,0x02,0x02,0x03,0x09,0x02,0x00
>  }, 15,   AV_CODEC_ID_FFV1 }, /*FFV1 V1 */
> +{ { 
> 0x06,0x0e,0x2b,0x34,0x04,0x01,0x01,0x0D,0x04,0x01,0x02,0x02,0x03,0x09,0x04,0x00
>  }, 15,   AV_CODEC_ID_FFV1 }, /*FFV1 V3 */
> /* SoundEssenceCompression */
> { { 
> 0x06,0x0e,0x2b,0x34,0x04,0x01,0x01,0x03,0x04,0x02,0x02,0x02,0x03,0x03,0x01,0x00
>  }, 14,AV_CODEC_ID_AAC }, /* MPEG-2 AAC ADTS (legacy) */
> { { 
> 0x06,0x0E,0x2B,0x34,0x04,0x01,0x01,0x01,0x04,0x02,0x02,0x01,0x00,0x00,0x00,0x00
>  }, 13,  AV_CODEC_ID_PCM_S16LE }, /* uncompressed */
> diff --git a/libavformat/mxf.h b/libavformat/mxf.h
> index 4d9f5119a3..2561605ce5 100644
> --- a/libavformat/mxf.h
> +++ b/libavformat/mxf.h
> @@ -54,6 +54,7 @@ enum MXFMetadataSetType {
> AudioChannelLabelSubDescriptor,
> SoundfieldGroupLabelSubDescriptor,
> GroupOfSoundfieldGroupsLabelSubDescriptor,
> +FFV1SubDescriptor,
> };
> 
> enum MXFFrameLayout {
> diff --git a/libavformat/mxfdec.c b/libavformat/mxfdec.c
> index 400941c348..c4d9d6ed93 100644
> --- a/libavformat/mxfdec.c
> +++ b/libavformat/mxfdec.c
> @@ -237,6 +237,12 @@ typedef struct MXFMCASubDescriptor {
> char *language;
> } MXFMCASubDescriptor;
> 
> +typedef struct MXFFFV1SubDescriptor {
> +MXFMetadataSet meta;
> +uint8_t *extradata;
> +int extradata_size;
> +} MXFFFV1SubDescriptor;
> +
> typedef struct MXFIndexTableSegment {
> MXFMetadataSet meta;
> int edit_unit_byte_count;
> @@ -337,6 +343,7 @@ static const uint8_t mxf_crypto_source_container_ul[] 
>  = { 0x06,0x0e,0x2b,0x
> static const uint8_t mxf_encrypted_triplet_key[]   = { 
> 0x06,0x0e,0x2b,0x34,0x02,0x04,0x01,0x07,0x0d,0x01,0x03,0x01,0x02,0x7e,0x01,0x00
>  };
> static const uint8_t mxf_encrypted_essence_container[] = { 
> 0x06,0x0e,0x2b,0x34,0x04,0x01,0x01,0x07,0x0d,0x01,0x03,0x01,0x02,0x0b,0x01,0x00
>  };
> static const uint8_t mxf_sony_mpeg4_extradata[]= { 
> 0x06,0x0e,0x2b,0x34,0x04,0x01,0x01,0x01,0x0e,0x06,0x06,0x02,0x02,0x01,0x00,0x00
>  };
> +static const uint8_t mxf_ffv1_extradata[]  = { 
> 0x06,0x0e,0x2b,0x34,0x01,0x01,0x01,0x0e,0x04,0x01,0x06,0x0c,0x01,0x00,0x00,0x00
>  };
> static const uint8_t mxf_avid_project_name[]   = { 
> 0xa5,0xfb,0x7b,0x25,0xf6,0x15,0x94,0xb9,0x62,0xfc,0x37,0x17,0x49,0x2d,0x42,0xbf
>  };
> static const uint8_t mxf_jp2k_rsiz[]   = { 
> 0x06,0x0e,0x2b,0x34,0x01,0x01,0x01,0x0a,0x04,0x01,0x06,0x03,0x01,0x00,0x00,0x00
>  };
> static const uint8_t mxf_indirect_value_utf16le[]  = { 
> 0x4c,0x00,0x02,0x10,0x01,0x00,0x00,0x00,0x00,0x06,0x0e,0x2b,0x34,0x01,0x04,0x01,0x01
>  };
> @@ -377,6 +384,9 @@ static void mxf_free_metadataset(MXFMetadataSet **ctx, 
> int freectx)
> av_freep(&((MXFDescriptor *)*ctx)->file_descriptors_refs);
> av_freep(&((MXFDescriptor *)*ctx)->sub_descriptors_refs);
> break;
> +case FFV1SubDescriptor:
> +av_freep(&((MXFFFV1SubDescriptor *)*ctx)->extradata);
> +break;
> case AudioChannelLabelSubDescriptor:
> case SoundfieldGroupLabelSubDescriptor:
> case GroupOfSoundfieldGroupsLabelSubDescriptor:
> @@ -1473,6 +1483,25 @@ static int mxf_read_mca_sub_descriptor(void *arg, 
> AVIOContext *pb, int tag, int
> return 0;
> }
> 
> +static int mxf_read_ffv1_sub_descriptor(void *arg, AVIOContext *pb, int tag, 
> int size, UID uid, int64_t klv_offset)
> +{
> +MXFFFV1SubDescriptor *ffv1_sub_descriptor = arg;
> +
> +if (IS_KLV_KEY(uid, mxf_ffv1_extradata)) {
> +if (ffv1_sub_descriptor->extradata)
> +av_log(NULL, AV_LOG_WARNING, "Duplicate ffv1_extradata\n");
> +av_free(ffv1_sub_descriptor->extradata);
> +ffv1_sub_descriptor->extradata_size = 0;
> +ffv1_sub_descriptor->extradata = av_malloc(size);
> +if (!ffv1_sub_descriptor->extradata)
> +  

Re: [FFmpeg-devel] [PATCH v3] ffmpeg: add option -isync

[Gyan Doshi]

On 2022-07-13 06:00 pm, Anton Khirnov wrote:

Quoting Gyan Doshi (2022-07-11 08:46:48)


On 2022-07-11 12:21 am, Anton Khirnov wrote:

Quoting Gyan Doshi (2022-07-10 20:02:38)

On 2022-07-10 10:46 pm, Anton Khirnov wrote:

Quoting Gyan Doshi (2022-07-08 05:56:21)

On 2022-07-07 03:11 pm, Anton Khirnov wrote:

Quoting Gyan Doshi (2022-07-04 18:29:12)

This is a per-file input option that adjusts an input's timestamps
with reference to another input, so that emitted packet timestamps
account for the difference between the start times of the two inputs.

Typical use case is to sync two or more live inputs such as from capture
devices. Both the target and reference input source timestamps should be
based on the same clock source.

If not all inputs have timestamps, the wallclock times at the time of
reception of inputs shall be used. FFmpeg must have been compiled with
thread support for this last case.

I'm wondering if simply using the other input's InputFile.ts_offset
wouldn't achieve the same effect with much less complexity.

That's what I initially did. But since the code can also use two other
sources for start times (start_time_realtime, first_pkt_wallclock),
those intervals may not exactly match the difference between
fmctx->start_times so I use a generic calculation.

In what cases is it better to use either of those two other sources?

As per the commit message, the timestamps of both inputs are supposed to
come from the same clock. Then it seems to me that offsetting each of
those streams by different amounts would break synchronization rather
than improve it.

The first preference, when available, stores the epoch time closest to
time of capture. That would eliminate some jitter.
The 2nd preference is the fmctx->start_time. The 3rd is the reception
wallclock. It is a fallback. It will likely lead to the worst sync.

You did not answer my question.
If both streams use the same clock, then how is offsetting them by
different amounts improve sync?

Because the clocks can be different at different stages of stream
conveyance  i.e. capture -> encode -> network relay -> ffmpeg reception.
As long as both use the same clock at a given stage, they represent the
same sync relation but with some jitter in the mix added with each stage.

Why would you send the streams separately and not synchronized before
network transmission?


Because they may arise from separate machines e.g. a video 
teleconference with multiple participants on the LAN, conveyed with NTP 
time of start of stream.


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

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

Re: [FFmpeg-devel] [PATCH 6/9] ffprobe: use AVFrame.duration instead of AVFrame.pkt_duration

[James Almer]

You should probably add new entries to the schema file instead.

https://git.videolan.org/?p=ffmpeg.git;a=blob;f=doc/ffprobe.xsd;h=3af621a17ae884adfeacb7cd50c60e1553808188;hb=HEAD#l93

Once frame->pkt_duration is gone, ffprobe shouldn't keep printing a 
frame->duration value as "pkt_duration" and "pkt_duration_time".
Also, if frame->duration is supposed to be able to have values other 
than those we wrote to pkt_duration, maybe keep printing the latter with 
the existing schema entries until it's all gone (You can use 
AV_NOWARN_DEPRECATED() to shut compilers up).


On 7/13/2022 6:17 AM, Anton Khirnov wrote:

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

diff --git a/fftools/ffprobe.c b/fftools/ffprobe.c
index f156663019..a041241e1e 100644
--- a/fftools/ffprobe.c
+++ b/fftools/ffprobe.c
@@ -2570,8 +2570,8 @@ static void show_frame(WriterContext *w, AVFrame *frame, 
AVStream *stream,
  print_time("pkt_dts_time",  frame->pkt_dts, >time_base);
  print_ts  ("best_effort_timestamp", frame->best_effort_timestamp);
  print_time("best_effort_timestamp_time", frame->best_effort_timestamp, 
>time_base);
-print_duration_ts  ("pkt_duration",  frame->pkt_duration);
-print_duration_time("pkt_duration_time", frame->pkt_duration, 
>time_base);
+print_duration_ts  ("pkt_duration",  frame->duration);
+print_duration_time("pkt_duration_time", frame->duration, 
>time_base);
  if (frame->pkt_pos != -1) print_fmt("pkt_pos", "%"PRId64, 
frame->pkt_pos);
  else  print_str_opt("pkt_pos", "N/A");
  if (frame->pkt_size != -1) print_val("pkt_size", frame->pkt_size, 
unit_byte_str);

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

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

Re: [FFmpeg-devel] [PATCH v3] ffmpeg: add option -isync

[Anton Khirnov]

Quoting Gyan Doshi (2022-07-11 08:46:48)
> 
> 
> On 2022-07-11 12:21 am, Anton Khirnov wrote:
> > Quoting Gyan Doshi (2022-07-10 20:02:38)
> >>
> >> On 2022-07-10 10:46 pm, Anton Khirnov wrote:
> >>> Quoting Gyan Doshi (2022-07-08 05:56:21)
>  On 2022-07-07 03:11 pm, Anton Khirnov wrote:
> > Quoting Gyan Doshi (2022-07-04 18:29:12)
> >> This is a per-file input option that adjusts an input's timestamps
> >> with reference to another input, so that emitted packet timestamps
> >> account for the difference between the start times of the two inputs.
> >>
> >> Typical use case is to sync two or more live inputs such as from 
> >> capture
> >> devices. Both the target and reference input source timestamps should 
> >> be
> >> based on the same clock source.
> >>
> >> If not all inputs have timestamps, the wallclock times at the time of
> >> reception of inputs shall be used. FFmpeg must have been compiled with
> >> thread support for this last case.
> > I'm wondering if simply using the other input's InputFile.ts_offset
> > wouldn't achieve the same effect with much less complexity.
>  That's what I initially did. But since the code can also use two other
>  sources for start times (start_time_realtime, first_pkt_wallclock),
>  those intervals may not exactly match the difference between
>  fmctx->start_times so I use a generic calculation.
> >>> In what cases is it better to use either of those two other sources?
> >>>
> >>> As per the commit message, the timestamps of both inputs are supposed to
> >>> come from the same clock. Then it seems to me that offsetting each of
> >>> those streams by different amounts would break synchronization rather
> >>> than improve it.
> >> The first preference, when available, stores the epoch time closest to
> >> time of capture. That would eliminate some jitter.
> >> The 2nd preference is the fmctx->start_time. The 3rd is the reception
> >> wallclock. It is a fallback. It will likely lead to the worst sync.
> > You did not answer my question.
> > If both streams use the same clock, then how is offsetting them by
> > different amounts improve sync?
> 
> Because the clocks can be different at different stages of stream 
> conveyance  i.e. capture -> encode -> network relay -> ffmpeg reception.
> As long as both use the same clock at a given stage, they represent the 
> same sync relation but with some jitter in the mix added with each stage.

Why would you send the streams separately and not synchronized before
network transmission?

-- 
Anton Khirnov
___
ffmpeg-devel mailing list
ffmpeg-devel@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] Request: make framepool visible externally

[James Almer]

On 7/13/2022 5:03 AM, Marco Vianini wrote:

  Actually I was speaking about framepool, and not bufferpool.
framepool is intended to get an "AVFrame *" from a pool, by "ff_frame_pool_get".
At the moment it is available only internally to "libavfilter".
It permits an important improvement on performances, by using a pool. So it 
should be very nice if I could use it in my own code.
To be possible framepool.h should become a public header.
Thank You


Please, do not top post in this list.

I know you want AVFrames. What i mean is that you should use the 
existing buffer pool API to achieve that. Write your own function that 
returns a freshly allocated AVFrame that fills the buf[] and data[] 
fields with buffers returned by av_buffer_pool_get() instead of 
av_buffer_alloc().

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

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

Re: [FFmpeg-devel] [PATCH 3/3] avcodec: Make init-threadsafety the default

[Anton Khirnov]

Quoting Andreas Rheinhardt (2022-07-10 01:10:21)
> and remove FF_CODEC_CAP_INIT_THREADSAFE
> All our native codecs are already init-threadsafe
> (only wrappers for external libraries and hwaccels
> are typically not marked as init-threadsafe yet),
> so it is only natural for this to also be the default state.
> 
> Signed-off-by: Andreas Rheinhardt 
> ---
> One could now also remove the check for "codec->init" from
> (un)lock_avcodec. It wouldn't matter.

Very nice. Congratulations on getting here, it was tons of work.

-- 
Anton Khirnov
___
ffmpeg-devel mailing list
ffmpeg-devel@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] libavutil: Add av_visibility_hidden for setting hidden symbol visibility

[Anton Khirnov]

Quoting Andreas Rheinhardt (2022-07-11 12:57:32)
> > 
> > Good point - attribute.h would otherwise have been the natural spot, but
> > I agree that it'd be better to not make it public at all. In what header
> > would you prefer to have it?
> > 
> 
> The typical place we put such things is libavutil/internal.h.

misc headers are evil

how about a non-installed attribute_internal.h?

-- 
Anton Khirnov
___
ffmpeg-devel mailing list
ffmpeg-devel@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] [EXTERNAL] [PATCH] [PATCH] libavformat/mov: Expose Quicktime poster_time value as metadata TAG.

[Anton Khirnov]

Quoting Bryce Newman (2022-07-12 19:20:17)
> Hello,
> Can someone please have a look at this patch request?
> Thank you in advance.

Metadata is intended for user-presentable strings, not structured
values.

The least bad way of exporting this I can think of is adding a
demuxer-private AV_OPT_FLAG_EXPORT option.

Also, avoid floating point - it is inexact.

-- 
Anton Khirnov
___
ffmpeg-devel mailing list
ffmpeg-devel@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 01/35] fftools/ffmpeg_mux: add private muxer context

[Anton Khirnov]

Quoting Michael Niedermayer (2022-07-08 18:58:11)
> On Fri, Jun 17, 2022 at 12:27:18PM +0200, Anton Khirnov wrote:
> > The current version of this set can also be found in my tree
> > git://git.khirnov.net/libav
> > branch ffmpeg_mt/mux
> 
> There are really many files changing, its hard to say for sure that all are 
> the
> same issue, but basically it all seems more or less frames in some streams
> including cases where there are hugely more or 0
> 
> Here are some examples:
> 
> 
> ffmpeg -i matrixbench_mpeg2.mpg -vcodec rawvideo -pix_fmt rgb555 
> -allow_raw_vfw 1 -vframes 1 -bitexact file-rgb555.mkv
> 
> the new file is much bigger (due to the audio track)
> 
> -rw-r- 1 michael michael 2765813 Jul  8 16:57 file-rgb555.mkv
> -rw-r- 1 michael michael  834643 Jul  8 17:02 file-rgb555-ref.mkv

Where can I find this file?

> another one:
> ./ffmpeg -y -i vlcticket/8344/DVR_NVR_IP\ 
> Camera01_20130321162325_20130321162358_576877.mp4 -vframes 1 -aframes 1 
> -bitexact -f framecrc -
> 
> This appears to loose the video stream
> 
>  #channel_layout_name 1: mono
> -0,  0,  0,1,  288, 0x4136bc92
>  1,112,112,  320,  640, 0x2cd73b36
> 
> sample in https://samples.ffmpeg.org/camera-dvr/hikvision/

The sync queue got confused by stale frame durations, which are now
overwritten in the updated version of 22/35.

But do note that there may be valid situations where a stream will
"disappear" when you specify -frames constraints on multiple streams,
because -frames is supposed to cut the whole file once the constraint is
reached, not just the stream it applies to. If you want a specific
number of frames in each stream, you should rather use the trim/atrim
filters.

See also my discussion with Andreas under 24/35 in this thread.

> This one fails a bit worse than before (ffmpeg succeeds before besides 
> producing errors as well)
> my notes say this worked better only before 
> 04aa09c4bcf2d5a634a35da3a3ae3fc1abe30ef8
> the file is a little big and i havnt found it anywhere online, i will try to
> send it privately to you
>  
> ffmpeg -i 2014-10-17\ 11.31\ i95Dev\ -\ Carlo\ Pazolini\ _\ KWI\ -\ 
> Meeting.g2m -bitexact -max_muxing_queue_size 8000 -vframes 2 file-g2m5.avi
> 
>   Metadata:
> DeviceConformanceTemplate: L2
> WMFSDKNeeded: 0.0.0.
> WMFSDKVersion   : 12.0.7601.17514
> IsVBR   : 1
> WM/ToolVersion  : 6.4.3 Build 1767
> WM/ToolName : GoToMeeting
> BitRateFrom the writer: 97087
> Audio samples   : 34341
> Video samples   : 3740
> recording time  : Fri, 17 Oct 2014 12:28:16 Eastern Daylight Time
>   Duration: 00:57:13.86, start: 0.00, bitrate: 100 kb/s
>   Stream #0:0: Audio: wmav2 (a[1][0][0] / 0x0161), 44100 Hz, mono, fltp, 48 
> kb/s
>   Stream #0:1: Data: none, 2 kb/s
>   Stream #0:2: Video: g2m (G2M5 / 0x354D3247), rgb24, 1440x900, 49 kb/s, 1k 
> tbr, 1k tbn
> Stream mapping:
>   Stream #0:2 -> #0:0 (g2m (native) -> mpeg4 (native))
>   Stream #0:0 -> #0:1 (wmav2 (native) -> mp3 (libmp3lame))
> Press [q] to stop, [?] for help
> [libmp3lame @ 0x55c17cf03140] Queue input is backward in time
> Output #0, avi, to 'file-g2m5.avi':
>   Metadata:
> DeviceConformanceTemplate: L2
> WMFSDKNeeded: 0.0.0.
> WMFSDKVersion   : 12.0.7601.17514
> IsVBR   : 1
> WM/ToolVersion  : 6.4.3 Build 1767
> WM/ToolName : GoToMeeting
> BitRateFrom the writer: 97087
> Audio samples   : 34341
> Video samples   : 3740
> recording time  : Fri, 17 Oct 2014 12:28:16 Eastern Daylight Time
>   Stream #0:0: Video: mpeg4 (FMP4 / 0x34504D46), yuv420p(tv, progressive), 
> 1440x900, q=2-31, 200 kb/s, 1k fps, 1k tbn
> Metadata:
>   encoder : Lavc mpeg4
> Side data:
>   cpb: bitrate max/min/avg: 0/0/20 buffer size: 0 vbv_delay: N/A
>   Stream #0:1: Audio: mp3 (U[0][0][0] / 0x0055), 44100 Hz, mono, fltp
> Metadata:
>   encoder : Lavc libmp3lame
> [avi @ 0x55c17cf31340] Too large number of skipped frames 194184 > 
> 60kbits/s speed= 140x
> av_interleaved_write_frame(): Invalid argument
> Error muxing a packet for output file #0
> [avi @ 0x55c17cf31340] Too large number of skipped frames 194085 > 6
> frame=2 fps=1.3 q=2.0 Lsize=1855kB time=00:03:14.18 bitrate=  
> 78.3kbits/s speed= 129x
> video:149kB audio:1517kB subtitle:0kB other streams:0kB global headers:0kB 
> muxing overhead: 11.381945%
> Conversion failed!

The new code ends up sending a few more audio packets to the muxer, so
av_interleaved_write_frame() returns an error, which results in a
non-zero exit status.

In the current code, the same error appears during flushing the muxing
queue in av_write_trailer() and is actually returned from
av_write_trailer(), but ffmpeg for some reason does not treat
av_write_trailer() errors the same way. I do not know why that is, seems
like a bug to me.

In any case, conversion is quite broken both before and 

[FFmpeg-devel] [PATCH] fftools/ffmpeg: rework -shortest implementation

[Anton Khirnov]

The -shortest option (which finishes the output file at the time the
shortest stream ends) is currently implemented by faking the -t option
when an output stream ends. This approach is fragile, since it depends
on the frames/packets being processed in a specific order. E.g. there
are currently some situations in which the output file length will
depend unpredictably on unrelated factors like encoder delay. More
importantly, the present work aiming at splitting various ffmpeg
components into different threads will make this approach completely
unworkable, since the frames/packets will arrive in effectively random
order.

This commit introduces a "sync queue", which is essentially a collection
of FIFOs, one per stream. Frames/packets are submitted to these FIFOs
and are then released for further processing (encoding or muxing) when
it is ensured that the frame in question will not cause its stream to
get ahead of the other streams (the logic is similar to libavformat's
interleaving queue).

These sync queues are then used for encoding and/or muxing when the
-shortest option is specified.

A new option – -shortest_buf_duration – controls the maximum number of
queued packets, to avoid runaway memory usage.

This commit changes the results of the following tests:
- copy-shortest[12]: the last audio frame is now gone. This is
  correct, since it actually outlasts the last video frame.
- shortest-sub: the video packets following the last subtitle packet are
  now gone. This is also correct.
---
Now setting video frame durations in do_video_out(), so the sync queue
can account for them correctly.
---
 Changelog |   1 +
 doc/ffmpeg.texi   |  16 ++
 fftools/Makefile  |   2 +
 fftools/ffmpeg.c  | 109 ++---
 fftools/ffmpeg.h  |   9 +
 fftools/ffmpeg_mux.c  |  67 +-
 fftools/ffmpeg_opt.c  |  82 +++
 fftools/sync_queue.c  | 425 ++
 fftools/sync_queue.h  | 100 
 tests/fate/ffmpeg.mak |   2 +-
 tests/ref/fate/copy-shortest1 |   1 -
 tests/ref/fate/copy-shortest2 |   1 -
 tests/ref/fate/shortest-sub   |   4 +-
 13 files changed, 778 insertions(+), 41 deletions(-)
 create mode 100644 fftools/sync_queue.c
 create mode 100644 fftools/sync_queue.h

diff --git a/Changelog b/Changelog
index ba679aa64e..9f0af86c9b 100644
--- a/Changelog
+++ b/Changelog
@@ -23,6 +23,7 @@ version 5.1:
 - virtualbass audio filter
 - VDPAU AV1 hwaccel
 - PHM image format support
+- ffmpeg -shortest_buf_duration option
 
 
 version 5.0:
diff --git a/doc/ffmpeg.texi b/doc/ffmpeg.texi
index 1a534ff1cc..e0186abcc2 100644
--- a/doc/ffmpeg.texi
+++ b/doc/ffmpeg.texi
@@ -1750,6 +1750,22 @@ Default value is 0.
 Enable bitexact mode for (de)muxer and (de/en)coder
 @item -shortest (@emph{output})
 Finish encoding when the shortest output stream ends.
+
+Note that this option may require buffering frames, which introduces extra
+latency. The maximum amount of this latency may be controlled with the
+@code{-shortest_buf_duration} option.
+
+@item -shortest_buf_duration @var{duration} (@emph{output})
+The @code{-shortest} option may require buffering potentially large amounts
+of data when at least one of the streams is "sparse" (i.e. has large gaps
+between frames – this is typically the case for subtitles).
+
+This option controls the maximum duration of buffered frames in seconds.
+Larger values may allow the @code{-shortest} option to produce more accurate
+results, but increase memory use and latency.
+
+The default value is 10 seconds.
+
 @item -dts_delta_threshold
 Timestamp discontinuity delta threshold.
 @item -dts_error_threshold @var{seconds}
diff --git a/fftools/Makefile b/fftools/Makefile
index 81ad6c4f4f..bc57ebe748 100644
--- a/fftools/Makefile
+++ b/fftools/Makefile
@@ -14,6 +14,8 @@ OBJS-ffmpeg +=  \
 fftools/ffmpeg_hw.o \
 fftools/ffmpeg_mux.o\
 fftools/ffmpeg_opt.o\
+fftools/objpool.o   \
+fftools/sync_queue.o\
 
 define DOFFTOOL
 OBJS-$(1) += fftools/cmdutils.o fftools/opt_common.o fftools/$(1).o 
$(OBJS-$(1)-yes)
diff --git a/fftools/ffmpeg.c b/fftools/ffmpeg.c
index 9ddd292512..b69f40cc8e 100644
--- a/fftools/ffmpeg.c
+++ b/fftools/ffmpeg.c
@@ -104,6 +104,7 @@
 
 #include "ffmpeg.h"
 #include "cmdutils.h"
+#include "sync_queue.h"
 
 #include "libavutil/avassert.h"
 
@@ -569,6 +570,7 @@ static void ffmpeg_cleanup(int ret)
 av_bsf_free(>bsf_ctx);
 
 av_frame_free(>filtered_frame);
+av_frame_free(>sq_frame);
 av_frame_free(>last_frame);
 av_packet_free(>pkt);
 av_dict_free(>encoder_opts);
@@ -691,13 +693,10 @@ static void update_benchmark(const char *fmt, ...)
 static void close_output_stream(OutputStream *ost)
 {
 OutputFile *of = output_files[ost->file_index];
-AVRational time_base = ost->stream_copy ? ost->mux_timebase : 
ost->enc_ctx->time_base;
-
 

Re: [FFmpeg-devel] Performances improvement in "image_copy_plane"

[Paul B Mahol]

On Wed, Jul 13, 2022 at 11:38 AM Marco Vianini <
marco_vianini-at-yahoo...@ffmpeg.org> wrote:

>  You can get a very big improvement of performances in the special (but
> very likely) case of: "(dst_linesize == bytewidth && src_linesize ==
> bytewidth)"
>
> In this case in fact We can "Coalesce rows", that is using ONLY ONE
> MEMCPY, instead of a smaller memcpy for every row (that is looping for
> height times).
>
> Code:"static void image_copy_plane(uint8_t   *dst, ptrdiff_t
> dst_linesize, const uint8_t *src, ptrdiff_t
> src_linesize, ptrdiff_t bytewidth, int
> height){if (!dst || !src)return;
> av_assert0(abs(src_linesize) >= bytewidth);av_assert0(abs(dst_linesize)
> >= bytewidth); // MY PATCH START// Coalesce rows.if (dst_linesize
> == bytewidth && src_linesize == bytewidth) {  bytewidth *= height;
> height = 1;  src_linesize = dst_linesize = 0;}// MY PATCH STOP
> for (;height > 0; height--) {memcpy(dst, src, bytewidth);
>   dst += dst_linesize;src += src_linesize;}}"
> What do You think about?Thank You
>

Show the benchmark numbers.


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

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

[FFmpeg-devel] Performances improvement in "image_copy_plane"

[Marco Vianini]

 You can get a very big improvement of performances in the special (but very 
likely) case of: "(dst_linesize == bytewidth && src_linesize == bytewidth)"

In this case in fact We can "Coalesce rows", that is using ONLY ONE MEMCPY, 
instead of a smaller memcpy for every row (that is looping for height times).

Code:"static void image_copy_plane(uint8_t       *dst, ptrdiff_t dst_linesize,  
                           const uint8_t *src, ptrdiff_t src_linesize,          
                   ptrdiff_t bytewidth, int height){    if (!dst || !src)       
 return;    av_assert0(abs(src_linesize) >= bytewidth);    
av_assert0(abs(dst_linesize) >= bytewidth); // MY PATCH START    // Coalesce 
rows.    if (dst_linesize == bytewidth && src_linesize == bytewidth) {      
bytewidth *= height;      height = 1;      src_linesize = dst_linesize = 0;    
}// MY PATCH STOP
    for (;height > 0; height--) {        memcpy(dst, src, bytewidth);        
dst += dst_linesize;        src += src_linesize;    }}"
What do You think about?Thank You
Marco Vianini
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

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

[FFmpeg-devel] [PATCH 7/9] ffmpeg: use AVFrame.duration instead of AVFrame.pkt_duration

[Anton Khirnov]

---
 fftools/ffmpeg.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/fftools/ffmpeg.c b/fftools/ffmpeg.c
index e7384f052a..effcfa1b91 100644
--- a/fftools/ffmpeg.c
+++ b/fftools/ffmpeg.c
@@ -1107,8 +1107,8 @@ static void do_video_out(OutputFile *of,
 (nb_filtergraphs == 0 || !filtergraphs[0]->graph_desc) &&
 next_picture &&
 ist &&
-lrintf(next_picture->pkt_duration * av_q2d(ist->st->time_base) / 
av_q2d(enc->time_base)) > 0) {
-duration = lrintf(next_picture->pkt_duration * 
av_q2d(ist->st->time_base) / av_q2d(enc->time_base));
+lrintf(next_picture->duration * av_q2d(ist->st->time_base) / 
av_q2d(enc->time_base)) > 0) {
+duration = lrintf(next_picture->duration * av_q2d(ist->st->time_base) 
/ av_q2d(enc->time_base));
 }
 
 if (!next_picture) {
@@ -2229,7 +2229,7 @@ static int decode_video(InputStream *ist, AVPacket *pkt, 
int *got_output, int64_
 ist->hwaccel_retrieved_pix_fmt = decoded_frame->format;
 
 best_effort_timestamp= decoded_frame->best_effort_timestamp;
-*duration_pts = decoded_frame->pkt_duration;
+*duration_pts = decoded_frame->duration;
 
 if (ist->framerate.num)
 best_effort_timestamp = ist->cfr_next_pts++;
-- 
2.34.1

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

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

[FFmpeg-devel] [PATCH 9/9] lavfi/vf_showinfo: print frame durations

[Anton Khirnov]

---
 libavfilter/vf_showinfo.c | 7 +--
 1 file changed, 5 insertions(+), 2 deletions(-)

diff --git a/libavfilter/vf_showinfo.c b/libavfilter/vf_showinfo.c
index 6efcafce28..2c8514fc80 100644
--- a/libavfilter/vf_showinfo.c
+++ b/libavfilter/vf_showinfo.c
@@ -709,10 +709,13 @@ static int filter_frame(AVFilterLink *inlink, AVFrame 
*frame)
 }
 
 av_log(ctx, AV_LOG_INFO,
-   "n:%4"PRId64" pts:%7s pts_time:%-7s pos:%9"PRId64" "
+   "n:%4"PRId64" pts:%7s pts_time:%-7s duration:%7"PRId64
+   " duration_time:%-7s pos:%9"PRId64" "
"fmt:%s sar:%d/%d s:%dx%d i:%c iskey:%d type:%c ",
inlink->frame_count_out,
-   av_ts2str(frame->pts), av_ts2timestr(frame->pts, 
>time_base), frame->pkt_pos,
+   av_ts2str(frame->pts), av_ts2timestr(frame->pts, 
>time_base),
+   frame->duration, av_ts2timestr(frame->duration, >time_base),
+   frame->pkt_pos,
desc->name,
frame->sample_aspect_ratio.num, frame->sample_aspect_ratio.den,
frame->width, frame->height,
-- 
2.34.1

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

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

[FFmpeg-devel] [PATCH 2/9] lavc: use AVFrame.duration instead of AVFrame.pkt_duration

[Anton Khirnov]

---
 libavcodec/crystalhd.c |  2 +-
 libavcodec/cuviddec.c  |  2 +-
 libavcodec/decode.c| 14 ++
 libavcodec/encode.c| 11 ++-
 libavcodec/gifdec.c|  2 +-
 libavcodec/libdav1d.c  |  2 +-
 libavcodec/mfenc.c |  2 +-
 libavcodec/rawdec.c|  2 +-
 8 files changed, 26 insertions(+), 11 deletions(-)

diff --git a/libavcodec/crystalhd.c b/libavcodec/crystalhd.c
index cf74f22e7d..211a485918 100644
--- a/libavcodec/crystalhd.c
+++ b/libavcodec/crystalhd.c
@@ -546,7 +546,7 @@ static inline CopyRet copy_frame(AVCodecContext *avctx,
 frame->pts = pkt_pts;
 
 frame->pkt_pos = -1;
-frame->pkt_duration = 0;
+frame->duration = 0;
 frame->pkt_size = -1;
 
 if (!priv->need_second_field) {
diff --git a/libavcodec/cuviddec.c b/libavcodec/cuviddec.c
index b544b3361d..d1b5dbc6f5 100644
--- a/libavcodec/cuviddec.c
+++ b/libavcodec/cuviddec.c
@@ -624,7 +624,7 @@ static int cuvid_output_frame(AVCodecContext *avctx, 
AVFrame *frame)
  * So set pkt_pts and clear all the other pkt_ fields.
  */
 frame->pkt_pos = -1;
-frame->pkt_duration = 0;
+frame->duration = 0;
 frame->pkt_size = -1;
 
 frame->interlaced_frame = !parsed_frame.is_deinterlacing && 
!parsed_frame.dispinfo.progressive_frame;
diff --git a/libavcodec/decode.c b/libavcodec/decode.c
index 1893caa6a6..14ce4c2e2f 100644
--- a/libavcodec/decode.c
+++ b/libavcodec/decode.c
@@ -394,8 +394,8 @@ FF_ENABLE_DEPRECATION_WARNINGS
 frame->pts += diff_ts;
 if(frame->pkt_dts!=AV_NOPTS_VALUE)
 frame->pkt_dts += diff_ts;
-if (frame->pkt_duration >= diff_ts)
-frame->pkt_duration -= diff_ts;
+if (frame->duration >= diff_ts)
+frame->duration -= diff_ts;
 } else {
 av_log(avctx, AV_LOG_WARNING, "Could not update timestamps 
for skipped samples.\n");
 }
@@ -417,7 +417,7 @@ FF_ENABLE_DEPRECATION_WARNINGS
 int64_t diff_ts = av_rescale_q(frame->nb_samples - 
discard_padding,
(AVRational){1, 
avctx->sample_rate},
avctx->pkt_timebase);
-frame->pkt_duration = diff_ts;
+frame->duration = diff_ts;
 } else {
 av_log(avctx, AV_LOG_WARNING, "Could not update timestamps 
for discarded samples.\n");
 }
@@ -549,6 +549,12 @@ static int decode_receive_frame_internal(AVCodecContext 
*avctx, AVFrame *frame)
  frame->pts,
  frame->pkt_dts);
 
+#if FF_API_PKT_DURATION
+FF_DISABLE_DEPRECATION_WARNINGS
+frame->pkt_duration = frame->duration;
+FF_ENABLE_DEPRECATION_WARNINGS
+#endif
+
 /* the only case where decode data is not set should be decoders
  * that do not call ff_get_buffer() */
 av_assert0((frame->private_ref && frame->private_ref->size == 
sizeof(FrameDecodeData)) ||
@@ -1267,7 +1273,7 @@ int ff_decode_frame_props(AVCodecContext *avctx, AVFrame 
*frame)
 if (!(ffcodec(avctx->codec)->caps_internal & 
FF_CODEC_CAP_SETS_FRAME_PROPS)) {
 frame->pts = pkt->pts;
 frame->pkt_pos  = pkt->pos;
-frame->pkt_duration = pkt->duration;
+frame->duration = pkt->duration;
 frame->pkt_size = pkt->size;
 
 for (int i = 0; i < FF_ARRAY_ELEMS(sd); i++) {
diff --git a/libavcodec/encode.c b/libavcodec/encode.c
index 1f39ab1a2f..310fe20777 100644
--- a/libavcodec/encode.c
+++ b/libavcodec/encode.c
@@ -339,7 +339,7 @@ static int encode_send_frame_internal(AVCodecContext 
*avctx, const AVFrame *src)
 return ret;
 
 avctx->internal->last_audio_frame = 1;
-return 0;
+goto finish;
 } else if (src->nb_samples > avctx->frame_size) {
 av_log(avctx, AV_LOG_ERROR, "nb_samples (%d) != frame_size 
(%d)\n", src->nb_samples, avctx->frame_size);
 return AVERROR(EINVAL);
@@ -351,6 +351,15 @@ static int encode_send_frame_internal(AVCodecContext 
*avctx, const AVFrame *src)
 if (ret < 0)
 return ret;
 
+finish:
+
+#if FF_API_PKT_DURATION
+FF_DISABLE_DEPRECATION_WARNINGS
+if (dst->pkt_duration && dst->pkt_duration != dst->duration)
+dst->duration = dst->pkt_duration;
+FF_ENABLE_DEPRECATION_WARNINGS
+#endif
+
 return 0;
 }
 
diff --git a/libavcodec/gifdec.c b/libavcodec/gifdec.c
index 3936de1cd2..fbb1ef6ad5 100644
--- a/libavcodec/gifdec.c
+++ b/libavcodec/gifdec.c
@@ -475,7 +475,7 @@ static int gif_decode_frame(AVCodecContext *avctx, AVFrame 
*rframe,
 
 s->frame->pts = avpkt->pts;
 s->frame->pkt_dts = avpkt->dts;
-s->frame->pkt_duration = avpkt->duration;
+ 

[FFmpeg-devel] [PATCH 5/9] lavd: use AVFrame.duration instead of AVFrame.pkt_duration

[Anton Khirnov]

---
 libavdevice/alsa_enc.c| 9 -
 libavdevice/pulse_audio_enc.c | 9 -
 2 files changed, 16 insertions(+), 2 deletions(-)

diff --git a/libavdevice/alsa_enc.c b/libavdevice/alsa_enc.c
index ac09e33c49..e461829d03 100644
--- a/libavdevice/alsa_enc.c
+++ b/libavdevice/alsa_enc.c
@@ -131,7 +131,14 @@ static int audio_write_frame(AVFormatContext *s1, int 
stream_index,
 pkt.data = (*frame)->data[0];
 pkt.size = (*frame)->nb_samples * s->frame_size;
 pkt.dts  = (*frame)->pkt_dts;
-pkt.duration = (*frame)->pkt_duration;
+#if FF_API_PKT_DURATION
+FF_DISABLE_DEPRECATION_WARNINGS
+if ((*frame)->pkt_duration)
+pkt.duration = (*frame)->pkt_duration;
+else
+FF_ENABLE_DEPRECATION_WARNINGS
+#endif
+pkt.duration = (*frame)->duration;
 return audio_write_packet(s1, );
 }
 
diff --git a/libavdevice/pulse_audio_enc.c b/libavdevice/pulse_audio_enc.c
index d5928e2b3f..038401c680 100644
--- a/libavdevice/pulse_audio_enc.c
+++ b/libavdevice/pulse_audio_enc.c
@@ -686,7 +686,14 @@ static int pulse_write_frame(AVFormatContext *h, int 
stream_index,
 pkt.data = (*frame)->data[0];
 pkt.size = (*frame)->nb_samples * 
av_get_bytes_per_sample((*frame)->format) * (*frame)->ch_layout.nb_channels;
 pkt.dts  = (*frame)->pkt_dts;
-pkt.duration = (*frame)->pkt_duration;
+#if FF_API_PKT_DURATION
+FF_DISABLE_DEPRECATION_WARNINGS
+if ((*frame)->pkt_duration)
+pkt.duration = (*frame)->pkt_duration;
+else
+FF_ENABLE_DEPRECATION_WARNINGS
+#endif
+pkt.duration = (*frame)->duration;
 return pulse_write_packet(h, );
 }
 
-- 
2.34.1

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

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

[FFmpeg-devel] [PATCH 8/9] tests/api: use AVFrame.duration instead of AVFrame.pkt_duration

[Anton Khirnov]

---
 tests/api/api-h264-test.c | 2 +-
 tests/api/api-seek-test.c | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/tests/api/api-h264-test.c b/tests/api/api-h264-test.c
index b9230c65cb..c89f1ba41a 100644
--- a/tests/api/api-h264-test.c
+++ b/tests/api/api-h264-test.c
@@ -154,7 +154,7 @@ static int video_decode_example(const char *input_filename)
 return number_of_written_bytes;
 }
 printf("%d, %s, %s, %8"PRId64", %8d, 0x%08"PRIx32"\n", 
video_stream,
-   av_ts2str(fr->pts), av_ts2str(fr->pkt_dts), 
fr->pkt_duration,
+   av_ts2str(fr->pts), av_ts2str(fr->pkt_dts), fr->duration,
number_of_written_bytes, av_adler32_update(0, (const 
uint8_t*)byte_buffer, number_of_written_bytes));
 
 av_frame_unref(fr);
diff --git a/tests/api/api-seek-test.c b/tests/api/api-seek-test.c
index 696af9cdfc..e86908e285 100644
--- a/tests/api/api-seek-test.c
+++ b/tests/api/api-seek-test.c
@@ -156,7 +156,7 @@ static int compute_crc_of_packets(AVFormatContext *fmt_ctx, 
int video_stream,
 }
 av_frame_unref(fr);
 }
-} while (result >= 0 && (no_seeking || (fr->pts + fr->pkt_duration <= 
ts_end)));
+} while (result >= 0 && (no_seeking || (fr->pts + fr->duration <= 
ts_end)));
 
 finish:
 av_freep(_buffer);
-- 
2.34.1

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

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

[FFmpeg-devel] [PATCH 6/9] ffprobe: use AVFrame.duration instead of AVFrame.pkt_duration

[Anton Khirnov]

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

diff --git a/fftools/ffprobe.c b/fftools/ffprobe.c
index f156663019..a041241e1e 100644
--- a/fftools/ffprobe.c
+++ b/fftools/ffprobe.c
@@ -2570,8 +2570,8 @@ static void show_frame(WriterContext *w, AVFrame *frame, 
AVStream *stream,
 print_time("pkt_dts_time",  frame->pkt_dts, >time_base);
 print_ts  ("best_effort_timestamp", frame->best_effort_timestamp);
 print_time("best_effort_timestamp_time", frame->best_effort_timestamp, 
>time_base);
-print_duration_ts  ("pkt_duration",  frame->pkt_duration);
-print_duration_time("pkt_duration_time", frame->pkt_duration, 
>time_base);
+print_duration_ts  ("pkt_duration",  frame->duration);
+print_duration_time("pkt_duration_time", frame->duration, 
>time_base);
 if (frame->pkt_pos != -1) print_fmt("pkt_pos", "%"PRId64, 
frame->pkt_pos);
 else  print_str_opt("pkt_pos", "N/A");
 if (frame->pkt_size != -1) print_val("pkt_size", frame->pkt_size, 
unit_byte_str);
-- 
2.34.1

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

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

[FFmpeg-devel] [PATCH 3/9] lavfi: use AVFrame.duration instead of AVFrame.pkt_duration

[Anton Khirnov]

---
 doc/filters.texi|  2 +-
 libavfilter/buffersrc.c |  7 +++
 libavfilter/f_loop.c| 14 ++
 libavfilter/vf_deshake_opencl.c |  7 +++
 libavfilter/vf_drawtext.c   | 16 
 5 files changed, 45 insertions(+), 1 deletion(-)

diff --git a/doc/filters.texi b/doc/filters.texi
index 40f21fb34c..0e7beac63d 100644
--- a/doc/filters.texi
+++ b/doc/filters.texi
@@ -11842,7 +11842,7 @@ The current packet's position in the input file or 
stream
 (in bytes, from the start of the input). A value of -1 indicates
 this info is not available.
 
-@item pkt_duration
+@item duration
 The current packet's duration, in seconds.
 
 @item pkt_size
diff --git a/libavfilter/buffersrc.c b/libavfilter/buffersrc.c
index a3190468bb..ae8bba19b0 100644
--- a/libavfilter/buffersrc.c
+++ b/libavfilter/buffersrc.c
@@ -243,6 +243,13 @@ FF_ENABLE_DEPRECATION_WARNINGS
 }
 }
 
+#if FF_API_PKT_DURATION
+FF_DISABLE_DEPRECATION_WARNINGS
+if (copy->pkt_duration && copy->pkt_duration != copy->duration)
+copy->duration = copy->pkt_duration;
+FF_ENABLE_DEPRECATION_WARNINGS
+#endif
+
 ret = ff_filter_frame(ctx->outputs[0], copy);
 if (ret < 0)
 return ret;
diff --git a/libavfilter/f_loop.c b/libavfilter/f_loop.c
index 672aa4c8f7..d217efe2fd 100644
--- a/libavfilter/f_loop.c
+++ b/libavfilter/f_loop.c
@@ -331,9 +331,16 @@ static int push_frame(AVFilterContext *ctx)
 if (!out)
 return AVERROR(ENOMEM);
 out->pts += s->duration - s->start_pts;
+#if FF_API_PKT_DURATION
+FF_DISABLE_DEPRECATION_WARNINGS
 if (out->pkt_duration)
 duration = out->pkt_duration;
 else
+FF_ENABLE_DEPRECATION_WARNINGS
+#endif
+if (out->duration)
+duration = out->duration;
+else
 duration = av_rescale_q(1, av_inv_q(outlink->frame_rate), 
outlink->time_base);
 pts = out->pts + duration;
 ret = ff_filter_frame(outlink, out);
@@ -368,9 +375,16 @@ static int filter_frame(AVFilterLink *inlink, AVFrame 
*frame)
 return AVERROR(ENOMEM);
 }
 s->nb_frames++;
+#if FF_API_PKT_DURATION
+FF_DISABLE_DEPRECATION_WARNINGS
 if (frame->pkt_duration)
 duration = frame->pkt_duration;
 else
+FF_ENABLE_DEPRECATION_WARNINGS
+#endif
+if (frame->duration)
+duration = frame->duration;
+else
 duration = av_rescale_q(1, av_inv_q(outlink->frame_rate), 
outlink->time_base);
 s->duration = frame->pts + duration;
 ret = ff_filter_frame(outlink, frame);
diff --git a/libavfilter/vf_deshake_opencl.c b/libavfilter/vf_deshake_opencl.c
index c2b5bef897..d488da7fa0 100644
--- a/libavfilter/vf_deshake_opencl.c
+++ b/libavfilter/vf_deshake_opencl.c
@@ -1413,8 +1413,15 @@ static int filter_frame(AVFilterLink *link, AVFrame 
*input_frame)
 _matches, 1);
 }
 
+#if FF_API_PKT_DURATION
+FF_DISABLE_DEPRECATION_WARNINGS
 if (input_frame->pkt_duration) {
 duration = input_frame->pkt_duration;
+} else
+FF_ENABLE_DEPRECATION_WARNINGS
+#endif
+if (input_frame->duration) {
+duration = input_frame->duration;
 } else {
 duration = av_rescale_q(1, av_inv_q(outlink->frame_rate), 
outlink->time_base);
 }
diff --git a/libavfilter/vf_drawtext.c b/libavfilter/vf_drawtext.c
index feb6898848..50012bb258 100644
--- a/libavfilter/vf_drawtext.c
+++ b/libavfilter/vf_drawtext.c
@@ -91,8 +91,11 @@ static const char *const var_names[] = {
 "y",
 "pict_type",
 "pkt_pos",
+#if FF_API_PKT_DURATION
 "pkt_duration",
+#endif
 "pkt_size",
+"duration",
 NULL
 };
 
@@ -131,8 +134,11 @@ enum var_name {
 VAR_Y,
 VAR_PICT_TYPE,
 VAR_PKT_POS,
+#if FF_API_PKT_DURATION
 VAR_PKT_DURATION,
+#endif
 VAR_PKT_SIZE,
+VAR_DURATION,
 VAR_VARS_NB
 };
 
@@ -1649,8 +1655,18 @@ static int filter_frame(AVFilterLink *inlink, AVFrame 
*frame)
 
 s->var_values[VAR_PICT_TYPE] = frame->pict_type;
 s->var_values[VAR_PKT_POS] = frame->pkt_pos;
+#if FF_API_PKT_DURATION
+FF_DISABLE_DEPRECATION_WARNINGS
 s->var_values[VAR_PKT_DURATION] = frame->pkt_duration * 
av_q2d(inlink->time_base);
+
+if (frame->pkt_duration)
+s->var_values[VAR_DURATION] = frame->pkt_duration * 
av_q2d(inlink->time_base);
+else
+FF_ENABLE_DEPRECATION_WARNINGS
+#endif
+s->var_values[VAR_DURATION] = frame->duration * av_q2d(inlink->time_base);
 s->var_values[VAR_PKT_SIZE] = frame->pkt_size;
+
 s->metadata = frame->metadata;
 
 for (int i = 0; i < loop; i++) {
-- 
2.34.1

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

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

[FFmpeg-devel] [PATCH 4/9] lavf: use AVFrame.duration instead of AVFrame.pkt_duration

[Anton Khirnov]

---
 libavformat/mux.c | 9 -
 1 file changed, 8 insertions(+), 1 deletion(-)

diff --git a/libavformat/mux.c b/libavformat/mux.c
index 31361f9b46..a3b50dadb6 100644
--- a/libavformat/mux.c
+++ b/libavformat/mux.c
@@ -1417,7 +1417,14 @@ static int write_uncoded_frame_internal(AVFormatContext 
*s, int stream_index,
 pkt->size = sizeof(frame);
 pkt->pts  =
 pkt->dts  = frame->pts;
-pkt->duration = frame->pkt_duration;
+#if FF_API_PKT_DURATION
+FF_DISABLE_DEPRECATION_WARNINGS
+if (frame->pkt_duration)
+pkt->duration = frame->pkt_duration;
+else
+FF_ENABLE_DEPRECATION_WARNINGS
+#endif
+pkt->duration = frame->duration;
 pkt->stream_index = stream_index;
 pkt->flags |= AV_PKT_FLAG_UNCODED_FRAME;
 }
-- 
2.34.1

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

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

[FFmpeg-devel] [PATCH 1/9] lavu/frame: add a duration field to AVFrame

[Anton Khirnov]

The only duration field currently present in AVFrame is pkt_duration,
which is semantically restricted to those frames that are output by
decoders.

Add a new field that stores the frame's duration without regard for how
that frame was produced. Deprecate pkt_duration.
---
 doc/APIchanges  |  3 +++
 libavutil/frame.c   | 10 ++
 libavutil/frame.h   | 10 ++
 libavutil/version.h |  3 ++-
 4 files changed, 25 insertions(+), 1 deletion(-)

diff --git a/doc/APIchanges b/doc/APIchanges
index 20b944933a..656362b40d 100644
--- a/doc/APIchanges
+++ b/doc/APIchanges
@@ -14,6 +14,9 @@ libavutil: 2021-04-27
 
 API changes, most recent first:
 
+2022-07-xx - xx - lavu 57.28.100 - frame.h
+  Add AVFrame.duration, deprecate AVFrame.pkt_duration.
+
 2022-06-12 - xx - lavf 59.25.100 - avio.h
   Add avio_vprintf(), similar to avio_printf() but allow to use it
   from within a function taking a variable argument list as input.
diff --git a/libavutil/frame.c b/libavutil/frame.c
index 4c16488c66..9c9bab3fcf 100644
--- a/libavutil/frame.c
+++ b/libavutil/frame.c
@@ -59,7 +59,12 @@ static void get_frame_defaults(AVFrame *frame)
 frame->pts   =
 frame->pkt_dts   = AV_NOPTS_VALUE;
 frame->best_effort_timestamp = AV_NOPTS_VALUE;
+frame->duration= 0;
+#if FF_API_PKT_DURATION
+FF_DISABLE_DEPRECATION_WARNINGS
 frame->pkt_duration= 0;
+FF_ENABLE_DEPRECATION_WARNINGS
+#endif
 frame->pkt_pos = -1;
 frame->pkt_size= -1;
 frame->time_base   = (AVRational){ 0, 1 };
@@ -283,6 +288,7 @@ static int frame_copy_props(AVFrame *dst, const AVFrame 
*src, int force_copy)
 dst->crop_left  = src->crop_left;
 dst->crop_right = src->crop_right;
 dst->pts= src->pts;
+dst->duration   = src->duration;
 dst->repeat_pict= src->repeat_pict;
 dst->interlaced_frame   = src->interlaced_frame;
 dst->top_field_first= src->top_field_first;
@@ -292,7 +298,11 @@ static int frame_copy_props(AVFrame *dst, const AVFrame 
*src, int force_copy)
 dst->pkt_dts= src->pkt_dts;
 dst->pkt_pos= src->pkt_pos;
 dst->pkt_size   = src->pkt_size;
+#if FF_API_PKT_DURATION
+FF_DISABLE_DEPRECATION_WARNINGS
 dst->pkt_duration   = src->pkt_duration;
+FF_ENABLE_DEPRECATION_WARNINGS
+#endif
 dst->time_base  = src->time_base;
 dst->reordered_opaque   = src->reordered_opaque;
 dst->quality= src->quality;
diff --git a/libavutil/frame.h b/libavutil/frame.h
index 33fac2054c..856959f979 100644
--- a/libavutil/frame.h
+++ b/libavutil/frame.h
@@ -604,13 +604,18 @@ typedef struct AVFrame {
  */
 int64_t pkt_pos;
 
+#if FF_API_PKT_DURATION
 /**
  * duration of the corresponding packet, expressed in
  * AVStream->time_base units, 0 if unknown.
  * - encoding: unused
  * - decoding: Read by user.
+ *
+ * @deprecated use duration instead
  */
+attribute_deprecated
 int64_t pkt_duration;
+#endif
 
 /**
  * metadata.
@@ -702,6 +707,11 @@ typedef struct AVFrame {
  * Channel layout of the audio data.
  */
 AVChannelLayout ch_layout;
+
+/**
+ * Duration of the frame, in the same units as pts. 0 if unknown.
+ */
+int64_t duration;
 } AVFrame;
 
 
diff --git a/libavutil/version.h b/libavutil/version.h
index 2e9e02dda8..1722f0427f 100644
--- a/libavutil/version.h
+++ b/libavutil/version.h
@@ -79,7 +79,7 @@
  */
 
 #define LIBAVUTIL_VERSION_MAJOR  57
-#define LIBAVUTIL_VERSION_MINOR  27
+#define LIBAVUTIL_VERSION_MINOR  28
 #define LIBAVUTIL_VERSION_MICRO 100
 
 #define LIBAVUTIL_VERSION_INT   AV_VERSION_INT(LIBAVUTIL_VERSION_MAJOR, \
@@ -114,6 +114,7 @@
 #define FF_API_XVMC (LIBAVUTIL_VERSION_MAJOR < 58)
 #define FF_API_OLD_CHANNEL_LAYOUT   (LIBAVUTIL_VERSION_MAJOR < 58)
 #define FF_API_AV_FOPEN_UTF8(LIBAVUTIL_VERSION_MAJOR < 58)
+#define FF_API_PKT_DURATION (LIBAVUTIL_VERSION_MAJOR < 58)
 
 /**
  * @}
-- 
2.34.1

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

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

Re: [FFmpeg-devel] Request: make framepool visible externally

[Marco Vianini]

Yes, I know the version 4.1.6 is very old. But I stuck in 4.1.x versions 
because I need NDI support.
In the file "framepool.h" there are only some very high level functions to deal 
with AVFrame pool:
"FFFramePool *ff_frame_pool_video_init(...);FFFramePool 
*ff_frame_pool_audio_init(...);void ff_frame_pool_uninit(FFFramePool 
**pool);int ff_frame_pool_get_video_config();int 
ff_frame_pool_get_audio_config();AVFrame *ff_frame_pool_get(FFFramePool *pool);"
In my debug tests I tried to make "framepool.h" public and to use it, and it 
worked like a charm!With an important improvement on performances (like a pool 
does).
Probably I don't understand what You mean with "It's also not in any way 
stable, so can break its API at any random point.".Can You please clarify?
I think that it is very stable, and contains only high level functions (see 
above).Then my request to make it public.
Thank You
Il martedì 12 luglio 2022 19:16:02 CEST, Timo Rothenpieler 
 ha scritto:
 
 
 On 12.07.2022 18:28, Marco Vianini wrote:
> Hi all
> I'm using Libav libraries (version 4.1.6) to make operations on audio/video 
> AVFrame: conversions, decoding, encoding, etc.

That is a really old version, and you should desperately update.

> To improve performances I'd like to use framepool.
> So I need to include "libavfilter/framepool.h", but I cannot, because this 
> file is not exported.
> Should be possible to add "framepool.h" to HEADERS in "libavfilter\Makefile" ?
> Code:"NAME = avfilterDESC = FFmpeg audio/video filtering library
> HEADERS = avfilter.h                                                    \     
>      buffersink.h                                                  \          
> buffersrc.h                                                   \          
> version.h                                                     \   framepool.h 
>                

framepool.h is not a public header, and contains no publicly exported 
functions.
Even if you got the header, you couldn't use the functions since they're 
not exported from the library.

So no, you can't use any of the stuff in there outside of libavfilter.
It's also not in any way stable, so can break its API at any random point.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

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

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

Re: [FFmpeg-devel] [PATCH v2 4/5] libswscale: Enable hscale_avx2 for all input sizes.

[Alan Kelly]

Pushing this back up to the top. This is required to enable the previous
patch in this chain. Thanks

On Fri, Apr 22, 2022 at 10:04 AM Alan Kelly  wrote:

> Ping!
>
> On Thu, Feb 17, 2022 at 11:04 AM Alan Kelly  wrote:
>
>> ff_shuffle_filter_coefficients shuffles the tail as required.
>> ---
>>  libswscale/utils.c   | 19 ---
>>  libswscale/x86/swscale.c |  6 ++
>>  2 files changed, 18 insertions(+), 7 deletions(-)
>>
>> diff --git a/libswscale/utils.c b/libswscale/utils.c
>> index 7c8e1bbdde..d818c9ce55 100644
>> --- a/libswscale/utils.c
>> +++ b/libswscale/utils.c
>> @@ -285,8 +285,7 @@ int ff_shuffle_filter_coefficients(SwsContext *c, int
>> *filterPos,
>>  #if ARCH_X86_64
>>  int i, j, k;
>>  int cpu_flags = av_get_cpu_flags();
>> -// avx2 hscale filter processes 16 pixel blocks.
>> -if (!filter || dstW % 16 != 0)
>> +if (!filter)
>>  return 0;
>>  if (EXTERNAL_AVX2_FAST(cpu_flags) && !(cpu_flags &
>> AV_CPU_FLAG_SLOW_GATHER)) {
>>  if ((c->srcBpc == 8) && (c->dstBpc <= 14)) {
>> @@ -298,9 +297,11 @@ int ff_shuffle_filter_coefficients(SwsContext *c,
>> int *filterPos,
>> }
>> // Do not swap filterPos for pixels which won't be processed
>> by
>> // the main loop.
>> -   for (i = 0; i + 8 <= dstW; i += 8) {
>> +   for (i = 0; i + 16 <= dstW; i += 16) {
>> FFSWAP(int, filterPos[i + 2], filterPos[i + 4]);
>> FFSWAP(int, filterPos[i + 3], filterPos[i + 5]);
>> +   FFSWAP(int, filterPos[i + 10], filterPos[i + 12]);
>> +   FFSWAP(int, filterPos[i + 11], filterPos[i + 13]);
>> }
>> if (filterSize > 4) {
>> // 16 pixels are processed at a time.
>> @@ -314,6 +315,18 @@ int ff_shuffle_filter_coefficients(SwsContext *c,
>> int *filterPos,
>> }
>> }
>> }
>> +   // 4 pixels are processed at a time in the tail.
>> +   for (; i < dstW; i += 4) {
>> +   // 4 filter coeffs are processed at a time.
>> +   int rem = dstW - i >= 4 ? 4 : dstW - i;
>> +   for (k = 0; k + 4 <= filterSize; k += 4) {
>> +   for (j = 0; j < rem; ++j) {
>> +   int from = (i + j) * filterSize + k;
>> +   int to = i * filterSize + j * 4 + k * 4;
>> +   memcpy([to], [from], 4 *
>> sizeof(int16_t));
>> +   }
>> +   }
>> +   }
>> }
>> av_free(filterCopy);
>>  }
>> diff --git a/libswscale/x86/swscale.c b/libswscale/x86/swscale.c
>> index 73869355b8..76f5a70fc5 100644
>> --- a/libswscale/x86/swscale.c
>> +++ b/libswscale/x86/swscale.c
>> @@ -691,10 +691,8 @@ switch(c->dstBpc){ \
>>
>>  if (EXTERNAL_AVX2_FAST(cpu_flags) && !(cpu_flags &
>> AV_CPU_FLAG_SLOW_GATHER)) {
>>  if ((c->srcBpc == 8) && (c->dstBpc <= 14)) {
>> -if (c->chrDstW % 16 == 0)
>> -ASSIGN_AVX2_SCALE_FUNC(c->hcScale, c->hChrFilterSize);
>> -if (c->dstW % 16 == 0)
>> -ASSIGN_AVX2_SCALE_FUNC(c->hyScale, c->hLumFilterSize);
>> +ASSIGN_AVX2_SCALE_FUNC(c->hcScale, c->hChrFilterSize);
>> +ASSIGN_AVX2_SCALE_FUNC(c->hyScale, c->hLumFilterSize);
>>  }
>>  }
>>
>> --
>> 2.35.1.265.g69c8d7142f-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".

Re: [FFmpeg-devel] [PATCH v2 3/5] libswscale: Avx2 hscale can process inputs of any size.

[Alan Kelly]

Hi,

Are there any further comments on this patch or can it be committed?

Thanks,

Alan

On Tue, Apr 26, 2022 at 10:00 AM Alan Kelly  wrote:

> The main loop processes blocks of 16 pixels. The tail processes blocks
> of size 4.
> ---
>  libswscale/x86/scale_avx2.asm | 44 ++-
>  1 file changed, 43 insertions(+), 1 deletion(-)
>
> diff --git a/libswscale/x86/scale_avx2.asm b/libswscale/x86/scale_avx2.asm
> index 20acdbd633..7657b2825f 100644
> --- a/libswscale/x86/scale_avx2.asm
> +++ b/libswscale/x86/scale_avx2.asm
> @@ -53,6 +53,9 @@ cglobal hscale8to15_%1, 7, 9, 16, pos0, dst, w, srcmem,
> filter, fltpos, fltsize,
>  mova m14, [four]
>  shr fltsized, 2
>  %endif
> +cmp wq, 16
> +jl .tail_loop
> +sub wq, 0x10
>  .loop:
>  movu m1, [fltposq]
>  movu m2, [fltposq+32]
> @@ -101,7 +104,46 @@ cglobal hscale8to15_%1, 7, 9, 16, pos0, dst, w,
> srcmem, filter, fltpos, fltsize,
>  add fltposq, 0x40
>  add countq, 0x10
>  cmp countq, wq
> -jl .loop
> +jle .loop
> +
> +add wq, 0x10
> +cmp countq, wq
> +jge .end
> +
> +.tail_loop:
> +movu xm1, [fltposq]
> +%ifidn %1, X4
> +pxor xm9, xm9
> +pxor xm10, xm10
> +xor innerq, innerq
> +.tail_innerloop:
> +%endif
> +vpcmpeqd  xm13, xm13
> +vpgatherdd xm3,[srcmemq + xm1], xm13
> +vpunpcklbw xm5, xm3, xm0
> +vpunpckhbw xm6, xm3, xm0
> +vpmaddwd xm5, xm5, [filterq]
> +vpmaddwd xm6, xm6, [filterq + 16]
> +add filterq, 0x20
> +%ifidn %1, X4
> +paddd xm9, xm5
> +paddd xm10, xm6
> +paddd xm1, xm14
> +add innerq, 1
> +cmp innerq, fltsizeq
> +jl .tail_innerloop
> +vphaddd xm5, xm9, xm10
> +%else
> +vphaddd xm5, xm5, xm6
> +%endif
> +vpsrad  xm5, 7
> +vpackssdw xm5, xm5, xm5
> +vmovq [dstq + countq * 2], xm5
> +add fltposq, 0x10
> +add countq, 0x4
> +cmp countq, wq
> +jl .tail_loop
> +.end:
>  REP_RET
>  %endmacro
>
> --
> 2.36.0.rc2.479.g8af0fa9b8e-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".

Re: [FFmpeg-devel] Request: make framepool visible externally

[Marco Vianini]

 Actually I was speaking about framepool, and not bufferpool.
framepool is intended to get an "AVFrame *" from a pool, by "ff_frame_pool_get".
At the moment it is available only internally to "libavfilter".
It permits an important improvement on performances, by using a pool. So it 
should be very nice if I could use it in my own code.
To be possible framepool.h should become a public header.
Thank You

Il martedì 12 luglio 2022 19:19:34 CEST, James Almer  ha 
scritto:  
 
 On 7/12/2022 1:28 PM, Marco Vianini wrote:
> Hi all
> I'm using Libav libraries (version 4.1.6) to make operations on audio/video 
> AVFrame: conversions, decoding, encoding, etc.
> 
> To improve performances I'd like to use framepool.
> So I need to include "libavfilter/framepool.h", but I cannot, because this 
> file is not exported.
> Should be possible to add "framepool.h" to HEADERS in "libavfilter\Makefile" ?
> Code:"NAME = avfilterDESC = FFmpeg audio/video filtering library
> HEADERS = avfilter.h                                                    \     
>      buffersink.h                                                  \          
> buffersrc.h                                                   \          
> version.h                                                     \   framepool.h 
>                                                   \   ...   "
> Thank YouMarco Vianini

What you want is to use the bufferpool API in libavutil for your frames.
___
ffmpeg-devel mailing list
ffmpeg-devel@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 1/3] avcodec/lagarith: Check dst/src in zero run code

[Paul B Mahol]

On Tue, Jul 12, 2022 at 8:43 PM Michael Niedermayer 
wrote:

> Fixes: out of array access
> Fixes:
> 48799/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_LAGARITH_fuzzer-4764457825337344
>
> Found-by: continuous fuzzing process
> https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
> Signed-off-by
> :
> Michael Niedermayer 
> ---
>  libavcodec/lagarith.c | 3 +++
>  1 file changed, 3 insertions(+)
>
> diff --git a/libavcodec/lagarith.c b/libavcodec/lagarith.c
> index 3aeb1c8a99..00e8005222 100644
> --- a/libavcodec/lagarith.c
> +++ b/libavcodec/lagarith.c
> @@ -409,6 +409,9 @@ output_zeros:
>  if (zero_run) {
>  zero_run = 0;
>  i += esc_count;
> +if (i >  end - dst ||
> +i >= src_end - src)
> +return AVERROR_INVALIDDATA;
>  memcpy(dst, src, i);
>  dst += i;
>  l->zeros_rem = lag_calc_zero_run(src[i]);
>

LGTM


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

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