[FFmpeg-devel] X (Twitter) Access

2023-08-17 Thread Kieran Kunhya via ffmpeg-devel
Hello,

X (Twitter) has changed the way accounts can post under @ffmpeg.
Please could the person with the main login to @ffmpeg delegate myself
("kierank_") and Derek ("Daemon404") and delegate @ffmpeg access to
both of us.

We have tested this with the @videolan account and it works without a
blue tick for anyone.

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

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


Re: [FFmpeg-devel] [PATCH v2 1/2] avcodec: add ambient viewing environment packet side data.

2023-08-17 Thread Damiano Galassi
Ping
___
ffmpeg-devel mailing list
ffmpeg-devel@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 v26 5/9] avcodec/evc_decoder: Provided support for EVC decoder

2023-08-17 Thread Dawid Kozinski/Multimedia (PLT) /SRPOL/Staff Engineer/Samsung Electronics




> -Original Message-
> From: ffmpeg-devel  On Behalf Of James
> Almer
> Sent: środa, 26 lipca 2023 17:46
> To: ffmpeg-devel@ffmpeg.org
> Subject: Re: [FFmpeg-devel] [PATCH v26 5/9] avcodec/evc_decoder: Provided
> support for EVC decoder
> 
> On 6/15/2023 8:48 AM, Dawid Kozinski wrote:
> > - Added EVC decoder wrapper
> > - Changes in project configuration file and libavcodec Makefile
> > - Added documentation for xevd wrapper
> >
> > Signed-off-by: Dawid Kozinski 
> 
> I'm getting
> 
> [evc @ 01ee1ba7e960] An invalid frame was output by a decoder. This is
a
> bug, please report it.
> [vist#0:0/evc @ 01ee1d47f220] Decoding error: Internal bug, should not
> have happened
> 
> With akiyo_cif.evc, so there's something wrong.

Done.
I've fixed that. The change has been pushed to a new patchset (v27)
containing implementations of EVC encoder and decoder wrappers. 
The remaining things you mentioned below have also been taken into account.
> 
> > ---
> >   configure |   4 +
> >   doc/decoders.texi |  24 ++
> >   doc/general_contents.texi |  10 +-
> >   libavcodec/Makefile   |   1 +
> >   libavcodec/allcodecs.c|   1 +
> >   libavcodec/libxevd.c  | 479 ++
> >   6 files changed, 518 insertions(+), 1 deletion(-)
> >   create mode 100644 libavcodec/libxevd.c
> >
> > diff --git a/configure b/configure
> > index e2370a23bb..cae3b666a5 100755
> > --- a/configure
> > +++ b/configure
> > @@ -293,6 +293,7 @@ External library support:
> > --enable-libx264 enable H.264 encoding via x264 [no]
> > --enable-libx265 enable HEVC encoding via x265 [no]
> > --enable-libxeve enable EVC encoding via libxeve [no]
> > +  --enable-libxevd enable EVC decoding via libxevd [no]
> > --enable-libxavs enable AVS encoding via xavs [no]
> > --enable-libxavs2enable AVS2 encoding via xavs2 [no]
> > --enable-libxcb  enable X11 grabbing using XCB [autodetect]
> > @@ -1904,6 +1905,7 @@ EXTERNAL_LIBRARY_LIST="
> >   libvorbis
> >   libvpx
> >   libwebp
> > +libxevd
> >   libxeve
> >   libxml2
> >   libzimg
> > @@ -3460,6 +3462,7 @@ libx265_encoder_deps="libx265"
> >   libx265_encoder_select="atsc_a53"
> >   libxavs_encoder_deps="libxavs"
> >   libxavs2_encoder_deps="libxavs2"
> > +libxevd_decoder_deps="libxevd"
> >   libxeve_encoder_deps="libxeve"
> >   libxvid_encoder_deps="libxvid"
> >   libzvbi_teletext_decoder_deps="libzvbi"
> > @@ -6835,6 +6838,7 @@ enabled libx265   && require_pkg_config
> libx265 x265 x265.h x265_api_get
> >require_cpp_condition libx265 x265.h
"X265_BUILD >= 89"
> >   enabled libxavs   && require libxavs "stdint.h xavs.h"
> xavs_encoder_encode "-lxavs $pthreads_extralibs $libm_extralibs"
> >   enabled libxavs2  && require_pkg_config libxavs2 "xavs2 >=
1.3.0"
> "stdint.h xavs2.h" xavs2_api_get
> > +enabled libxevd   && require_pkg_config libxevd "xevd >= 0.4.1"
"xevd.h"
> xevd_decode
> >   enabled libxeve   && require_pkg_config libxeve "xeve >=
0.4.3" "xeve.h"
> xeve_encode
> >   enabled libxvid   && require libxvid xvid.h xvid_global
-lxvidcore
> >   enabled libzimg   && require_pkg_config libzimg "zimg >=
2.7.0" zimg.h
> zimg_get_api_version
> > diff --git a/doc/decoders.texi b/doc/decoders.texi index
> > 09b8314dd2..6311af229f 100644
> > --- a/doc/decoders.texi
> > +++ b/doc/decoders.texi
> > @@ -130,6 +130,30 @@ Set amount of frame threads to use during
> > decoding. The default value is 0 (auto
> >
> >   @end table
> >
> > +@section libxevd
> > +
> > +eXtra-fast Essential Video Decoder (XEVD) MPEG-5 EVC decoder wrapper.
> > +
> > +This decoder requires the presence of the libxevd headers and library
> > +during configuration. You need to explicitly configure the build with
> > +@option{--enable-libxevd}.
> > +
> > +The xevd project website is at
> @url{https://protect2.fireeye.com/v1/url?k=b6ce3a07-d7452f31-b6cfb148-
> 74fe485cbff1-251589a888281453&q=1&e=49c754eb-4416-4e31-90e9-
> ee8e7d469d1f&u=https%3A%2F%2Fgithub.com%2Fmpeg5%2Fxevd%257D.
> > +
> > +@subsection Options
> > +
> > +The following options are supported by the libxevd wrapper.
> > +The xevd-equivalent options or values are listed in parentheses for
easy
> migration.
> > +
> > +To get a more accurate and extensive documentation of the libxevd
> > +options, invoke the command  @code{xevd_app --help} or consult the
libxevd
> documentation.
> > +
> > +@table @option
> > +@item threads (@emph{threads})
> > +Force to use a specific number of threads
> > +
> > +@end table
> > +
> >   @section QSV Decoders
> >
> >   The family of Intel QuickSync Video decoders (VC1, MPEG-2, H.264,
> > HEVC, diff --git a/doc/general_contents.texi
> > b/doc/general_contents.texi index c6a997bfd6..8e08f5ebc3 100644
> > --- a/doc/general_contents.texi
> > +++ b/doc/general_contents.texi
> > @@ -351,6 +351,

Re: [FFmpeg-devel] [PATCH v3 05/12] avutil/frame: add helper for adding side data to set

2023-08-17 Thread Andreas Rheinhardt
Jan Ekström:
> Additionally, add an API test to check that the no-duplicates
> addition works after duplicates have been inserted.
> ---
>  libavutil/Makefile  |  1 +
>  libavutil/frame.c   | 34 
>  libavutil/frame.h   | 18 +
>  libavutil/tests/side_data_set.c | 71 +
>  tests/fate/libavutil.mak|  4 ++
>  tests/ref/fate/side_data_set|  7 
>  6 files changed, 135 insertions(+)
>  create mode 100644 libavutil/tests/side_data_set.c
>  create mode 100644 tests/ref/fate/side_data_set
> 
> diff --git a/libavutil/Makefile b/libavutil/Makefile
> index 7828c94dc5..339eaf3539 100644
> --- a/libavutil/Makefile
> +++ b/libavutil/Makefile
> @@ -264,6 +264,7 @@ TESTPROGS = adler32   
>   \
>  ripemd  \
>  sha \
>  sha512  \
> +side_data_set   \
>  softfloat   \
>  tree\
>  twofish \
> diff --git a/libavutil/frame.c b/libavutil/frame.c
> index 46ea603511..27ccbc52c7 100644
> --- a/libavutil/frame.c
> +++ b/libavutil/frame.c
> @@ -846,6 +846,40 @@ AVFrameSideData *av_frame_new_side_data(AVFrame *frame,
>  return ret;
>  }
>  
> +
> +AVFrameSideData *av_side_data_set_new_item(AVFrameSideDataSet *set,
> +   enum AVFrameSideDataType type,
> +   size_t size,
> +   unsigned int allow_duplicates)
> +{
> +AVBufferRef *buf = av_buffer_alloc(size);
> +AVFrameSideData *ret = NULL;
> +
> +if (!allow_duplicates) {
> +for (int i = 0; i < set->nb_sd; i++) {
> +if (set->sd[i]->type != type)
> +continue;
> +
> +free_side_data(&set->sd[i]);
> +
> +for (int j = i + 1; j < set->nb_sd; j++) {
> +set->sd[j - 1] = set->sd[j];

Ever heard of memmove?
(Alternatively, if the order is not to be preserved, one could simply
move the last side data to the just freed slot, similarly how
av_frame_remove_side_data() does it.)

> +}
> +
> +// finally, cause a retry of the same index and update state
> +// regarding there being one less side data item in the set.
> +i--;

In code like this, it is easier to count down instead of up. This also
has the advantage that entries that are removed later are not
unnecessarily moved.

> +set->nb_sd--;
> +}
> +}
> +
> +ret = add_side_data_to_set_from_buf(set, type, buf);
> +if (!ret)
> +av_buffer_unref(&buf);
> +
> +return ret;
> +}
> +
>  AVFrameSideData *av_frame_get_side_data(const AVFrame *frame,
>  enum AVFrameSideDataType type)
>  {
> diff --git a/libavutil/frame.h b/libavutil/frame.h
> index e5ca7af651..b9d7c76461 100644
> --- a/libavutil/frame.h
> +++ b/libavutil/frame.h
> @@ -1065,6 +1065,24 @@ const char *av_frame_side_data_name(enum 
> AVFrameSideDataType type);
>   */
>  void av_side_data_set_uninit(AVFrameSideDataSet *set);
>  
> +/**
> + * Add a new side data entry to a set.
> + *
> + * @param set a set to which the side data should be added
> + * @param type type of the added side data
> + * @param size size of the side data
> + * @param allow_duplicates an unsigned integer noting whether duplicates are
> + * allowed or not. If duplicates are not allowed, all
> + * entries of the same side data type are first 
> removed
> + * and freed before the new entry is added.

Why not flags?

> + *
> + * @return newly added side data on success, NULL on error

This does not mention whether duplicates have been removed on error (if
allow_duplicates == 0).

> + */
> +AVFrameSideData *av_side_data_set_new_item(AVFrameSideDataSet *set,
> +   enum AVFrameSideDataType type,
> +   size_t size,
> +   unsigned int allow_duplicates);
> +
>  /**
>   * @}
>   */
> diff --git a/libavutil/tests/side_data_set.c b/libavutil/tests/side_data_set.c
> new file mode 100644
> index 00..ad420440d5
> --- /dev/null
> +++ b/libavutil/tests/side_data_set.c
> @@ -0,0 +1,71 @@
> +/*
> + * Copyright (c) 2023 Jan Ekström 
> + *
> + * This file is part of FFmpeg.
> + *
> + * FFmpeg is free software; you can redistribute it and/or
> + * modify it under the terms of the GNU Lesser General Public
> + * License as publishe

Re: [FFmpeg-devel] [PATCH] avformat/avcodec: Add DTS-UHD demuxer and parser, movenc support.

2023-08-17 Thread Roy Funderburk


On 8/17/23 3:31 PM, Paul B Mahol wrote:
> Is decoder part still missing or?

This is just intended to read audio from a .dtsx file and output an mp4/mov 
file. There will not be a .dtsx to PCM decoder.

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

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


Re: [FFmpeg-devel] [PATCH] avformat/avcodec: Add DTS-UHD demuxer and parser, movenc support.

2023-08-17 Thread Paul B Mahol
Is decoder part still missing or?
___
ffmpeg-devel mailing list
ffmpeg-devel@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] avutil/channel_layout: make pre-defined channel layouts C++ friendly

2023-08-17 Thread James Almer

On 8/17/2023 11:27 AM, Zhao Zhili wrote:

From: Zhao Zhili 

C++ doesn't support designated initializers until C++20. We have
a bunch of pre-defined channel layouts, the gains to make them
usable in C++ exceed the losses.

Bump minor version so C++ project can check before use these defines.

Also initialize .opaque field explicitly to reduce warning in C++.
---
v2:
1. Keep field names in comments.
2. Bump minor version.
3. Add comments so it won't be reverted by accident.

  libavutil/channel_layout.h | 5 +++--
  libavutil/version.h| 4 ++--
  2 files changed, 5 insertions(+), 4 deletions(-)

diff --git a/libavutil/channel_layout.h b/libavutil/channel_layout.h
index f345415c55..f019b3d7ad 100644
--- a/libavutil/channel_layout.h
+++ b/libavutil/channel_layout.h
@@ -358,8 +358,9 @@ typedef struct AVChannelLayout {
  void *opaque;
  } AVChannelLayout;
  
+/* Don't use designated initializers since C++ doesn't support it until C++20. */

  #define AV_CHANNEL_LAYOUT_MASK(nb, m) \
-{ .order = AV_CHANNEL_ORDER_NATIVE, .nb_channels = (nb), .u = { .mask = 
(m) }}
+{ /* .order */ AV_CHANNEL_ORDER_NATIVE, /* .nb_channels */  (nb), /* 
.u.mask */ { m }, /* .opaque */ NULL }
  
  /**

   * @name Common pre-defined channel layouts
@@ -397,7 +398,7 @@ typedef struct AVChannelLayout {
  #define AV_CHANNEL_LAYOUT_STEREO_DOWNMIXAV_CHANNEL_LAYOUT_MASK(2,  
AV_CH_LAYOUT_STEREO_DOWNMIX)
  #define AV_CHANNEL_LAYOUT_22POINT2  AV_CHANNEL_LAYOUT_MASK(24, 
AV_CH_LAYOUT_22POINT2)
  #define AV_CHANNEL_LAYOUT_AMBISONIC_FIRST_ORDER \
-{ .order = AV_CHANNEL_ORDER_AMBISONIC, .nb_channels = 4, .u = { .mask = 0 
}}
+{ /* .order */ AV_CHANNEL_ORDER_AMBISONIC, /* .nb_channels */ 4, /* 
.u.mask */ { 0 }, NULL }
  /** @} */
  
  struct AVBPrint;

diff --git a/libavutil/version.h b/libavutil/version.h
index 5a4d4d3d73..bc43baca9f 100644
--- a/libavutil/version.h
+++ b/libavutil/version.h
@@ -79,8 +79,8 @@
   */
  
  #define LIBAVUTIL_VERSION_MAJOR  58

-#define LIBAVUTIL_VERSION_MINOR  16
-#define LIBAVUTIL_VERSION_MICRO 101
+#define LIBAVUTIL_VERSION_MINOR  17
+#define LIBAVUTIL_VERSION_MICRO 100
  
  #define LIBAVUTIL_VERSION_INT   AV_VERSION_INT(LIBAVUTIL_VERSION_MAJOR, \

 LIBAVUTIL_VERSION_MINOR, \


Will apply with some cosmetic changes.
___
ffmpeg-devel mailing list
ffmpeg-devel@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 v3 12/12] avcodec/libx265: add support for writing out CLL and MDCV

2023-08-17 Thread Jan Ekström
The newer of these two are the separate integers for content light
level, introduced in 3952bf3e98c76c31594529a3fe34e056d3e3e2ea ,
with X265_BUILD 75. As we already require X265_BUILD of at least
89, no further conditions are required.
---
 libavcodec/libx265.c | 82 
 tests/fate/enc_external.mak  |  5 +++
 tests/ref/fate/libx265-hdr10 | 16 +++
 3 files changed, 103 insertions(+)
 create mode 100644 tests/ref/fate/libx265-hdr10

diff --git a/libavcodec/libx265.c b/libavcodec/libx265.c
index 873b3021ee..2204b5146a 100644
--- a/libavcodec/libx265.c
+++ b/libavcodec/libx265.c
@@ -28,9 +28,11 @@
 #include 
 
 #include "libavutil/avassert.h"
+#include "libavutil/bprint.h"
 #include "libavutil/buffer.h"
 #include "libavutil/internal.h"
 #include "libavutil/common.h"
+#include "libavutil/mastering_display_metadata.h"
 #include "libavutil/opt.h"
 #include "libavutil/pixdesc.h"
 #include "avcodec.h"
@@ -179,6 +181,79 @@ static av_cold int libx265_param_parse_int(AVCodecContext 
*avctx,
 return 0;
 }
 
+static int handle_mdcv(AVCodecContext *avctx, const x265_api *api,
+   x265_param *params,
+   const AVMasteringDisplayMetadata *mdcv)
+{
+int ret = AVERROR_BUG;
+static const char *option = "master-display";
+AVBPrint buf;
+av_bprint_init(&buf, 0, AV_BPRINT_SIZE_AUTOMATIC);
+
+// G(%hu,%hu)B(%hu,%hu)R(%hu,%hu)WP(%hu,%hu)L(%u,%u)
+av_bprintf(
+&buf,
+"G(%"PRId64",%"PRId64")B(%"PRId64",%"PRId64")R(%"PRId64",%"PRId64")"
+"WP(%"PRId64",%"PRId64")L(%"PRId64",%"PRId64")",
+av_rescale_q(1, mdcv->display_primaries[1][0], (AVRational){ 1, 5 
}),
+av_rescale_q(1, mdcv->display_primaries[1][1], (AVRational){ 1, 5 
}),
+av_rescale_q(1, mdcv->display_primaries[2][0], (AVRational){ 1, 5 
}),
+av_rescale_q(1, mdcv->display_primaries[2][1], (AVRational){ 1, 5 
}),
+av_rescale_q(1, mdcv->display_primaries[0][0], (AVRational){ 1, 5 
}),
+av_rescale_q(1, mdcv->display_primaries[0][1], (AVRational){ 1, 5 
}),
+av_rescale_q(1, mdcv->white_point[0], (AVRational){ 1, 5 }),
+av_rescale_q(1, mdcv->white_point[1], (AVRational){ 1, 5 }),
+av_rescale_q(1, mdcv->max_luminance,  (AVRational){ 1, 1 }),
+av_rescale_q(1, mdcv->min_luminance,  (AVRational){ 1, 1 }));
+
+if (!av_bprint_is_complete(&buf)) {
+ret = AVERROR(ENOMEM);
+goto end;
+}
+
+if (api->param_parse(params, option, buf.str) ==
+X265_PARAM_BAD_VALUE) {
+av_log(avctx, AV_LOG_ERROR,
+   "Invalid value \"%s\" for param \"%s\".\n",
+   buf.str, option);
+ret = AVERROR(EINVAL);
+goto end;
+}
+
+ret = 0;
+
+end:
+av_bprint_finalize(&buf, NULL);
+
+return ret;
+}
+
+static int handle_side_data(AVCodecContext *avctx, const x265_api *api,
+x265_param *params)
+{
+const AVFrameSideDataSet set = avctx->side_data_set;
+const AVFrameSideData *cll_sd =
+av_side_data_set_get_item(set, AV_FRAME_DATA_CONTENT_LIGHT_LEVEL);
+const AVFrameSideData *mdcv_sd =
+av_side_data_set_get_item(set, 
AV_FRAME_DATA_MASTERING_DISPLAY_METADATA);
+
+if (cll_sd) {
+const AVContentLightMetadata *cll =
+(AVContentLightMetadata *)cll_sd->data;
+
+params->maxCLL  = cll->MaxCLL;
+params->maxFALL = cll->MaxFALL;
+}
+
+if (mdcv_sd) {
+int ret = handle_mdcv(avctx, api, params, (AVMasteringDisplayMetadata 
*)mdcv_sd->data);
+if (ret < 0)
+return ret;
+}
+
+return 0;
+}
+
 static av_cold int libx265_encode_init(AVCodecContext *avctx)
 {
 libx265Context *ctx = avctx->priv_data;
@@ -339,6 +414,13 @@ FF_ENABLE_DEPRECATION_WARNINGS
 return AVERROR_BUG;
 }
 
+ret = handle_side_data(avctx, ctx->api, ctx->params);
+if (ret < 0) {
+av_log(avctx, AV_LOG_ERROR, "Failed handling side data! (%s)\n",
+   av_err2str(ret));
+return ret;
+}
+
 if (ctx->crf >= 0) {
 char crf[6];
 
diff --git a/tests/fate/enc_external.mak b/tests/fate/enc_external.mak
index 90d8894d04..8d6df2febd 100644
--- a/tests/fate/enc_external.mak
+++ b/tests/fate/enc_external.mak
@@ -12,5 +12,10 @@ FATE_ENC_EXTERNAL-$(call ENCDEC, LIBX264 HEVC, MOV, 
HEVC_DEMUXER H264_DECODER) +
 fate-libx264-hdr10: CMD = enc_external 
$(TARGET_SAMPLES)/hevc/hdr10_plus_h265_sample.hevc \
 mp4 "-c:v libx264" "-show_frames -show_entries frame=side_data_list -of 
flat"
 
+# test for x265 MDCV and CLL passthrough during encoding
+FATE_ENC_EXTERNAL-$(call ENCDEC, LIBX265 HEVC, MOV, HEVC_DEMUXER) += 
fate-libx265-hdr10
+fate-libx265-hdr10: CMD = enc_external 
$(TARGET_SAMPLES)/hevc/hdr10_plus_h265_sample.hevc \
+mp4 "-c:v libx265" "-show_frames -show_entries frame=side_data_list -of 
flat"
+
 FATE_SAMPLES_FFMPEG_FFPROBE += $(F

[FFmpeg-devel] [PATCH v3 11/12] avcodec/libx264: add support for writing out CLL and MDCV

2023-08-17 Thread Jan Ekström
Both of these two structures were first available with X264_BUILD
163, so make relevant functionality conditional on the version
being at least such.

Keep handle_side_data available in all cases as this way X264_init
does not require additional version based conditions within it.

Finally, add a FATE test which verifies that pass-through of the
MDCV/CLL side data is working during encoding.
---
 libavcodec/libx264.c | 79 
 tests/fate/enc_external.mak  |  5 +++
 tests/ref/fate/libx264-hdr10 | 15 +++
 3 files changed, 99 insertions(+)
 create mode 100644 tests/ref/fate/libx264-hdr10

diff --git a/libavcodec/libx264.c b/libavcodec/libx264.c
index 1a7dc7bdd5..30ea3dae4c 100644
--- a/libavcodec/libx264.c
+++ b/libavcodec/libx264.c
@@ -25,6 +25,7 @@
 #include "libavutil/eval.h"
 #include "libavutil/internal.h"
 #include "libavutil/opt.h"
+#include "libavutil/mastering_display_metadata.h"
 #include "libavutil/mem.h"
 #include "libavutil/pixdesc.h"
 #include "libavutil/stereo3d.h"
@@ -842,6 +843,82 @@ static int convert_pix_fmt(enum AVPixelFormat pix_fmt)
 return AVERROR(EINVAL);\
 }
 
+#if X264_BUILD >= 163
+static void handle_mdcv(x264_param_t *params,
+const AVMasteringDisplayMetadata *mdcv)
+{
+int *points[][2] = {
+{
+¶ms->mastering_display.i_red_x,
+¶ms->mastering_display.i_red_y
+},
+{
+¶ms->mastering_display.i_green_x,
+¶ms->mastering_display.i_green_y
+},
+{
+¶ms->mastering_display.i_blue_x,
+¶ms->mastering_display.i_blue_y
+},
+};
+
+if (!mdcv->has_primaries && !mdcv->has_luminance)
+return;
+
+params->mastering_display.b_mastering_display = 1;
+
+if (!mdcv->has_primaries)
+goto skip_primaries;
+
+for (int i = 0; i < 3; i++) {
+const AVRational *src = mdcv->display_primaries[i];
+int *dst[2] = { points[i][0], points[i][1] };
+
+*dst[0] = av_rescale_q(1, src[0], (AVRational){ 1, 5 });
+*dst[1] = av_rescale_q(1, src[1], (AVRational){ 1, 5 });
+}
+
+params->mastering_display.i_white_x =
+av_rescale_q(1, mdcv->white_point[0], (AVRational){ 1, 5 });
+params->mastering_display.i_white_y =
+av_rescale_q(1, mdcv->white_point[1], (AVRational){ 1, 5 });
+
+skip_primaries:
+if (!mdcv->has_luminance)
+return;
+
+params->mastering_display.i_display_max =
+av_rescale_q(1, mdcv->max_luminance, (AVRational){ 1, 1 });
+params->mastering_display.i_display_min =
+av_rescale_q(1, mdcv->min_luminance, (AVRational){ 1, 1 });
+}
+#endif // X264_BUILD >= 163
+
+static void handle_side_data(AVCodecContext *avctx, x264_param_t *params)
+{
+#if X264_BUILD >= 163
+const AVFrameSideDataSet set = avctx->side_data_set;
+const AVFrameSideData *cll_sd =
+av_side_data_set_get_item(set, AV_FRAME_DATA_CONTENT_LIGHT_LEVEL);
+const AVFrameSideData *mdcv_sd =
+av_side_data_set_get_item(set, 
AV_FRAME_DATA_MASTERING_DISPLAY_METADATA);
+
+if (cll_sd) {
+const AVContentLightMetadata *cll =
+(AVContentLightMetadata *)cll_sd->data;
+
+params->content_light_level.i_max_cll  = cll->MaxCLL;
+params->content_light_level.i_max_fall = cll->MaxFALL;
+
+params->content_light_level.b_cll = 1;
+}
+
+if (mdcv_sd) {
+handle_mdcv(params, (AVMasteringDisplayMetadata *)mdcv_sd->data);
+}
+#endif // X264_BUILD >= 163
+}
+
 static av_cold int X264_init(AVCodecContext *avctx)
 {
 X264Context *x4 = avctx->priv_data;
@@ -1142,6 +1219,8 @@ FF_ENABLE_DEPRECATION_WARNINGS
 if (avctx->chroma_sample_location != AVCHROMA_LOC_UNSPECIFIED)
 x4->params.vui.i_chroma_loc = avctx->chroma_sample_location - 1;
 
+handle_side_data(avctx, &x4->params);
+
 if (avctx->flags & AV_CODEC_FLAG_GLOBAL_HEADER)
 x4->params.b_repeat_headers = 0;
 
diff --git a/tests/fate/enc_external.mak b/tests/fate/enc_external.mak
index d787941c16..90d8894d04 100644
--- a/tests/fate/enc_external.mak
+++ b/tests/fate/enc_external.mak
@@ -7,5 +7,10 @@ FATE_ENC_EXTERNAL-$(call ENCDEC, LIBSVTAV1 HEVC, MOV, 
HEVC_DEMUXER LIBDAV1D_DECO
 fate-libsvtav1-hdr10: CMD = enc_external 
$(TARGET_SAMPLES)/hevc/hdr10_plus_h265_sample.hevc \
 mp4 "-c:v libsvtav1" "-show_frames -show_entries frame=side_data_list -of 
flat"
 
+# test for x264 MDCV and CLL passthrough during encoding
+FATE_ENC_EXTERNAL-$(call ENCDEC, LIBX264 HEVC, MOV, HEVC_DEMUXER H264_DECODER) 
+= fate-libx264-hdr10
+fate-libx264-hdr10: CMD = enc_external 
$(TARGET_SAMPLES)/hevc/hdr10_plus_h265_sample.hevc \
+mp4 "-c:v libx264" "-show_frames -show_entries frame=side_data_list -of 
flat"
+
 FATE_SAMPLES_FFMPEG_FFPROBE += $(FATE_ENC_EXTERNAL-yes)
 fate-enc-external: $(FATE_ENC_EXTERNAL-yes)
diff --git a/tests/ref/fate/libx264-hdr10 b/tests/ref/fate/libx264-hdr10
new fi

[FFmpeg-devel] [PATCH v3 10/12] avcodec/libsvtav1: add support for writing out CLL and MDCV

2023-08-17 Thread Jan Ekström
These two were added in 28e23d7f348c78d49a726c7469f9d4e38edec341
and 3558c1f2e97455e0b89edef31b9a72ab7fa30550 for version 0.9.0 of
SVT-AV1, which is also our minimum requirement right now.

In other words, no additional version limiting conditions seem
to be required.

Additionally, add a FATE test which verifies that pass-through of
the MDCV/CLL side data is working during encoding.
---
 libavcodec/libsvtav1.c | 70 ++
 tests/fate/enc_external.mak|  5 +++
 tests/ref/fate/libsvtav1-hdr10 | 14 +++
 3 files changed, 89 insertions(+)
 create mode 100644 tests/ref/fate/libsvtav1-hdr10

diff --git a/libavcodec/libsvtav1.c b/libavcodec/libsvtav1.c
index f2b73361d8..d4f9fa14ba 100644
--- a/libavcodec/libsvtav1.c
+++ b/libavcodec/libsvtav1.c
@@ -24,9 +24,11 @@
 #include 
 #include 
 
+#include "libavutil/bswap.h"
 #include "libavutil/common.h"
 #include "libavutil/frame.h"
 #include "libavutil/imgutils.h"
+#include "libavutil/mastering_display_metadata.h"
 #include "libavutil/opt.h"
 #include "libavutil/pixdesc.h"
 #include "libavutil/avassert.h"
@@ -146,6 +148,72 @@ static int alloc_buffer(EbSvtAv1EncConfiguration *config, 
SvtContext *svt_enc)
 
 }
 
+static void handle_mdcv(struct EbSvtAv1MasteringDisplayInfo *dst,
+const AVMasteringDisplayMetadata *mdcv)
+{
+struct EbSvtAv1ChromaPoints *points[] = {
+&dst->r,
+&dst->g,
+&dst->b,
+};
+
+if (!mdcv->has_primaries)
+goto skip_primaries;
+
+for (int i = 0; i < 3; i++) {
+struct EbSvtAv1ChromaPoints *dst = points[i];
+const  AVRational   *src = mdcv->display_primaries[i];
+
+dst->x =
+AV_BSWAP16C(av_rescale_q(1, src[0],
+ (AVRational){ 1, (1 << 16) }));
+dst->y =
+AV_BSWAP16C(av_rescale_q(1, src[1],
+ (AVRational){ 1, (1 << 16) }));
+}
+
+dst->white_point.x =
+AV_BSWAP16C(av_rescale_q(1, mdcv->white_point[0],
+ (AVRational){ 1, (1 << 16) }));
+dst->white_point.y =
+AV_BSWAP16C(av_rescale_q(1, mdcv->white_point[1],
+ (AVRational){ 1, (1 << 16) }));
+
+skip_primaries:
+if (!mdcv->has_luminance)
+return;
+
+dst->max_luma =
+AV_BSWAP32C(av_rescale_q(1, mdcv->max_luminance,
+ (AVRational){ 1, (1 << 8) }));
+dst->min_luma =
+AV_BSWAP32C(av_rescale_q(1, mdcv->min_luminance,
+ (AVRational){ 1, (1 << 14) }));
+}
+
+static void handle_side_data(AVCodecContext *avctx,
+ EbSvtAv1EncConfiguration *param)
+{
+const AVFrameSideDataSet set = avctx->side_data_set;
+const AVFrameSideData *cll_sd =
+av_side_data_set_get_item(set, AV_FRAME_DATA_CONTENT_LIGHT_LEVEL);
+const AVFrameSideData *mdcv_sd =
+av_side_data_set_get_item(set, 
AV_FRAME_DATA_MASTERING_DISPLAY_METADATA);
+
+if (cll_sd) {
+const AVContentLightMetadata *cll =
+(AVContentLightMetadata *)cll_sd->data;
+
+param->content_light_level.max_cll  = AV_BSWAP16C(cll->MaxCLL);
+param->content_light_level.max_fall = AV_BSWAP16C(cll->MaxFALL);
+}
+
+if (mdcv_sd) {
+handle_mdcv(¶m->mastering_display,
+(AVMasteringDisplayMetadata *)mdcv_sd->data);
+}
+}
+
 static int config_enc_params(EbSvtAv1EncConfiguration *param,
  AVCodecContext *avctx)
 {
@@ -273,6 +341,8 @@ FF_ENABLE_DEPRECATION_WARNINGS
 /* 2 = IDR, closed GOP, 1 = CRA, open GOP */
 param->intra_refresh_type = avctx->flags & AV_CODEC_FLAG_CLOSED_GOP ? 2 : 
1;
 
+handle_side_data(avctx, param);
+
 #if SVT_AV1_CHECK_VERSION(0, 9, 1)
 while ((en = av_dict_get(svt_enc->svtav1_opts, "", en, 
AV_DICT_IGNORE_SUFFIX))) {
 EbErrorType ret = svt_av1_enc_parse_parameter(param, en->key, 
en->value);
diff --git a/tests/fate/enc_external.mak b/tests/fate/enc_external.mak
index 7eabebcc51..d787941c16 100644
--- a/tests/fate/enc_external.mak
+++ b/tests/fate/enc_external.mak
@@ -2,5 +2,10 @@ FATE_ENC_EXTERNAL-$(call ENCDEC, LIBX264 H264, MOV, 
H264_DEMUXER) += fate-libx26
 fate-libx264-simple: CMD = enc_external 
$(TARGET_SAMPLES)/h264-conformance/BA1_Sony_D.jsv \
 mp4 "-c:v libx264" "-show_entries frame=width,height,pix_fmt,pts,pkt_dts 
-of flat"
 
+# test for SVT-AV1 MDCV and CLL passthrough during encoding
+FATE_ENC_EXTERNAL-$(call ENCDEC, LIBSVTAV1 HEVC, MOV, HEVC_DEMUXER 
LIBDAV1D_DECODER) += fate-libsvtav1-hdr10
+fate-libsvtav1-hdr10: CMD = enc_external 
$(TARGET_SAMPLES)/hevc/hdr10_plus_h265_sample.hevc \
+mp4 "-c:v libsvtav1" "-show_frames -show_entries frame=side_data_list -of 
flat"
+
 FATE_SAMPLES_FFMPEG_FFPROBE += $(FATE_ENC_EXTERNAL-yes)
 fate-enc-external: $(FATE_ENC_EXTERNAL-yes)
diff --git a/tests/ref/fate/libsvtav1-hdr10 b/tests/ref/fate/libsvt

[FFmpeg-devel] [PATCH v3 09/12] ffmpeg: pass first video AVFrame's side data to encoder

2023-08-17 Thread Jan Ekström
This enables further configuration of output based on the results
of input decoding and filtering in a similar manner as the color
information.
---
 fftools/ffmpeg_enc.c | 11 +++
 1 file changed, 11 insertions(+)

diff --git a/fftools/ffmpeg_enc.c b/fftools/ffmpeg_enc.c
index 96424272bf..de60a14868 100644
--- a/fftools/ffmpeg_enc.c
+++ b/fftools/ffmpeg_enc.c
@@ -314,6 +314,17 @@ int enc_open(OutputStream *ost, AVFrame *frame)
 enc_ctx->colorspace = frame->colorspace;
 enc_ctx->chroma_sample_location = frame->chroma_location;
 
+ret = av_side_data_set_extend(&enc_ctx->side_data_set,
+  (const AVFrameSideDataSet){
+ .sd= frame->side_data,
+ .nb_sd = frame->nb_side_data
+  }, 0);
+if (ret < 0) {
+av_log(NULL, AV_LOG_ERROR, "failed to configure video encoder: 
%s!\n",
+   av_err2str(ret));
+return ret;
+}
+
 enc_ctx->framerate = fr;
 
 ost->st->avg_frame_rate = fr;
-- 
2.41.0

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

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


[FFmpeg-devel] [PATCH v3 08/12] avcodec: add side data set to AVCodecContext

2023-08-17 Thread Jan Ekström
This allows configuring an encoder by using AVFrameSideData.
---
 libavcodec/avcodec.h | 7 +++
 libavcodec/options.c | 1 +
 2 files changed, 8 insertions(+)

diff --git a/libavcodec/avcodec.h b/libavcodec/avcodec.h
index 649411ac79..500a8f3e49 100644
--- a/libavcodec/avcodec.h
+++ b/libavcodec/avcodec.h
@@ -2100,6 +2100,13 @@ typedef struct AVCodecContext {
  *   an error.
  */
 int64_t frame_num;
+
+/**
+ * Set containing static side data, such as HDR10 CLL / MDCV structures.
+ * - encoding: set by user
+ * - decoding: unused
+ */
+AVFrameSideDataSet side_data_set;
 } AVCodecContext;
 
 /**
diff --git a/libavcodec/options.c b/libavcodec/options.c
index a9b35ee1c3..fff2c53ae3 100644
--- a/libavcodec/options.c
+++ b/libavcodec/options.c
@@ -180,6 +180,7 @@ void avcodec_free_context(AVCodecContext **pavctx)
 av_freep(&avctx->inter_matrix);
 av_freep(&avctx->rc_override);
 av_channel_layout_uninit(&avctx->ch_layout);
+av_side_data_set_uninit(&avctx->side_data_set);
 
 av_freep(pavctx);
 }
-- 
2.41.0

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

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


[FFmpeg-devel] [PATCH v3 07/12] avutil/frame: add helper for extending a set of side data

2023-08-17 Thread Jan Ekström
---
 libavutil/frame.c | 23 +++
 libavutil/frame.h | 16 
 2 files changed, 39 insertions(+)

diff --git a/libavutil/frame.c b/libavutil/frame.c
index d8910a2120..04d56853f0 100644
--- a/libavutil/frame.c
+++ b/libavutil/frame.c
@@ -880,6 +880,29 @@ AVFrameSideData 
*av_side_data_set_new_item(AVFrameSideDataSet *set,
 return ret;
 }
 
+int av_side_data_set_extend(AVFrameSideDataSet *dst,
+const AVFrameSideDataSet src,
+unsigned int allow_duplicates)
+{
+for (int i = 0; i < src.nb_sd; i++) {
+const AVFrameSideData *sd_src = src.sd[i];
+AVFrameSideData *sd_dst =
+av_side_data_set_new_item(dst, sd_src->type,
+  sd_src->size,
+  allow_duplicates);
+if (!sd_dst) {
+av_side_data_set_uninit(dst);
+return AVERROR(ENOMEM);
+}
+
+memcpy(sd_dst->data, sd_src->data, sd_src->size);
+
+av_dict_copy(&sd_dst->metadata, sd_src->metadata, 0);
+}
+
+return 0;
+}
+
 AVFrameSideData *av_side_data_set_get_item(const AVFrameSideDataSet set,
enum AVFrameSideDataType type)
 {
diff --git a/libavutil/frame.h b/libavutil/frame.h
index 0cafc9c51f..2413000c9a 100644
--- a/libavutil/frame.h
+++ b/libavutil/frame.h
@@ -1083,6 +1083,22 @@ AVFrameSideData 
*av_side_data_set_new_item(AVFrameSideDataSet *set,
size_t size,
unsigned int allow_duplicates);
 
+/**
+ * Add multiple side data entries to a set in one go.
+ *
+ * @param dst a set to which the side data should be added
+ * @param src a set from which the side data should be copied from
+ * @param allow_duplicates an unsigned integer noting whether duplicates are
+ * allowed or not. If duplicates are not allowed, all
+ * entries of the same side data type are first removed
+ * and freed before the new entry is added.
+ *
+ * @return negative error code on failure, >=0 on success.
+ */
+int av_side_data_set_extend(AVFrameSideDataSet *dst,
+const AVFrameSideDataSet src,
+unsigned int allow_duplicates);
+
 /**
  * Get a side data entry of a specific type from a set.
  *
-- 
2.41.0

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

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


[FFmpeg-devel] [PATCH v3 06/12] avutil/frame: add helper for getting side data from set

2023-08-17 Thread Jan Ekström
---
 libavutil/frame.c | 22 +-
 libavutil/frame.h | 12 
 2 files changed, 29 insertions(+), 5 deletions(-)

diff --git a/libavutil/frame.c b/libavutil/frame.c
index 27ccbc52c7..d8910a2120 100644
--- a/libavutil/frame.c
+++ b/libavutil/frame.c
@@ -880,16 +880,28 @@ AVFrameSideData 
*av_side_data_set_new_item(AVFrameSideDataSet *set,
 return ret;
 }
 
-AVFrameSideData *av_frame_get_side_data(const AVFrame *frame,
-enum AVFrameSideDataType type)
+AVFrameSideData *av_side_data_set_get_item(const AVFrameSideDataSet set,
+   enum AVFrameSideDataType type)
 {
-for (int i = 0; i < frame->nb_side_data; i++) {
-if (frame->side_data[i]->type == type)
-return frame->side_data[i];
+for (int i = 0; i < set.nb_sd; i++) {
+if (set.sd[i]->type == type)
+return set.sd[i];
 }
 return NULL;
 }
 
+AVFrameSideData *av_frame_get_side_data(const AVFrame *frame,
+enum AVFrameSideDataType type)
+{
+return av_side_data_set_get_item(
+(const AVFrameSideDataSet){
+.sd= frame->side_data,
+.nb_sd = frame->nb_side_data
+},
+type
+);
+}
+
 static int frame_copy_video(AVFrame *dst, const AVFrame *src)
 {
 const uint8_t *src_data[4];
diff --git a/libavutil/frame.h b/libavutil/frame.h
index b9d7c76461..0cafc9c51f 100644
--- a/libavutil/frame.h
+++ b/libavutil/frame.h
@@ -1083,6 +1083,18 @@ AVFrameSideData 
*av_side_data_set_new_item(AVFrameSideDataSet *set,
size_t size,
unsigned int allow_duplicates);
 
+/**
+ * Get a side data entry of a specific type from a set.
+ *
+ * @param set the set from which side data should be queried from
+ * @param type type of side data to be queried
+ *
+ * @return a pointer to the side data of a given type on success, NULL if there
+ * is no side data with such type in this set.
+ */
+AVFrameSideData *av_side_data_set_get_item(const AVFrameSideDataSet set,
+   enum AVFrameSideDataType type);
+
 /**
  * @}
  */
-- 
2.41.0

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

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


[FFmpeg-devel] [PATCH v3 05/12] avutil/frame: add helper for adding side data to set

2023-08-17 Thread Jan Ekström
Additionally, add an API test to check that the no-duplicates
addition works after duplicates have been inserted.
---
 libavutil/Makefile  |  1 +
 libavutil/frame.c   | 34 
 libavutil/frame.h   | 18 +
 libavutil/tests/side_data_set.c | 71 +
 tests/fate/libavutil.mak|  4 ++
 tests/ref/fate/side_data_set|  7 
 6 files changed, 135 insertions(+)
 create mode 100644 libavutil/tests/side_data_set.c
 create mode 100644 tests/ref/fate/side_data_set

diff --git a/libavutil/Makefile b/libavutil/Makefile
index 7828c94dc5..339eaf3539 100644
--- a/libavutil/Makefile
+++ b/libavutil/Makefile
@@ -264,6 +264,7 @@ TESTPROGS = adler32 
\
 ripemd  \
 sha \
 sha512  \
+side_data_set   \
 softfloat   \
 tree\
 twofish \
diff --git a/libavutil/frame.c b/libavutil/frame.c
index 46ea603511..27ccbc52c7 100644
--- a/libavutil/frame.c
+++ b/libavutil/frame.c
@@ -846,6 +846,40 @@ AVFrameSideData *av_frame_new_side_data(AVFrame *frame,
 return ret;
 }
 
+
+AVFrameSideData *av_side_data_set_new_item(AVFrameSideDataSet *set,
+   enum AVFrameSideDataType type,
+   size_t size,
+   unsigned int allow_duplicates)
+{
+AVBufferRef *buf = av_buffer_alloc(size);
+AVFrameSideData *ret = NULL;
+
+if (!allow_duplicates) {
+for (int i = 0; i < set->nb_sd; i++) {
+if (set->sd[i]->type != type)
+continue;
+
+free_side_data(&set->sd[i]);
+
+for (int j = i + 1; j < set->nb_sd; j++) {
+set->sd[j - 1] = set->sd[j];
+}
+
+// finally, cause a retry of the same index and update state
+// regarding there being one less side data item in the set.
+i--;
+set->nb_sd--;
+}
+}
+
+ret = add_side_data_to_set_from_buf(set, type, buf);
+if (!ret)
+av_buffer_unref(&buf);
+
+return ret;
+}
+
 AVFrameSideData *av_frame_get_side_data(const AVFrame *frame,
 enum AVFrameSideDataType type)
 {
diff --git a/libavutil/frame.h b/libavutil/frame.h
index e5ca7af651..b9d7c76461 100644
--- a/libavutil/frame.h
+++ b/libavutil/frame.h
@@ -1065,6 +1065,24 @@ const char *av_frame_side_data_name(enum 
AVFrameSideDataType type);
  */
 void av_side_data_set_uninit(AVFrameSideDataSet *set);
 
+/**
+ * Add a new side data entry to a set.
+ *
+ * @param set a set to which the side data should be added
+ * @param type type of the added side data
+ * @param size size of the side data
+ * @param allow_duplicates an unsigned integer noting whether duplicates are
+ * allowed or not. If duplicates are not allowed, all
+ * entries of the same side data type are first removed
+ * and freed before the new entry is added.
+ *
+ * @return newly added side data on success, NULL on error
+ */
+AVFrameSideData *av_side_data_set_new_item(AVFrameSideDataSet *set,
+   enum AVFrameSideDataType type,
+   size_t size,
+   unsigned int allow_duplicates);
+
 /**
  * @}
  */
diff --git a/libavutil/tests/side_data_set.c b/libavutil/tests/side_data_set.c
new file mode 100644
index 00..ad420440d5
--- /dev/null
+++ b/libavutil/tests/side_data_set.c
@@ -0,0 +1,71 @@
+/*
+ * Copyright (c) 2023 Jan Ekström 
+ *
+ * This file is part of FFmpeg.
+ *
+ * FFmpeg is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public
+ * License as published by the Free Software Foundation; either
+ * version 2.1 of the License, or (at your option) any later version.
+ *
+ * FFmpeg is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+ * Lesser General Public License for more details.
+ *
+ * You should have received a copy of the GNU Lesser General Public
+ * License along with FFmpeg; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA
+ */
+
+#include 
+#include "libavutil/frame.c"
+#include "libavutil/mastering_display_metadata.h"
+
+static void print_clls

[FFmpeg-devel] [PATCH v3 04/12] avutil/frame: split side_data_from_buf to base and AVFrame func

2023-08-17 Thread Jan Ekström
---
 libavutil/frame.c | 31 +++
 1 file changed, 23 insertions(+), 8 deletions(-)

diff --git a/libavutil/frame.c b/libavutil/frame.c
index c90bf5d9b1..46ea603511 100644
--- a/libavutil/frame.c
+++ b/libavutil/frame.c
@@ -787,23 +787,22 @@ FF_ENABLE_DEPRECATION_WARNINGS
 return NULL;
 }
 
-AVFrameSideData *av_frame_new_side_data_from_buf(AVFrame *frame,
- enum AVFrameSideDataType type,
- AVBufferRef *buf)
+static AVFrameSideData *add_side_data_to_set_from_buf(AVFrameSideDataSet *set,
+  enum AVFrameSideDataType 
type,
+  AVBufferRef *buf)
 {
 AVFrameSideData *ret, **tmp;
 
 if (!buf)
 return NULL;
 
-if (frame->nb_side_data > INT_MAX / sizeof(*frame->side_data) - 1)
+if (set->nb_sd > INT_MAX / sizeof(*set->sd) - 1)
 return NULL;
 
-tmp = av_realloc(frame->side_data,
- (frame->nb_side_data + 1) * sizeof(*frame->side_data));
+tmp = av_realloc(set->sd, (set->nb_sd + 1) * sizeof(*set->sd));
 if (!tmp)
 return NULL;
-frame->side_data = tmp;
+set->sd = tmp;
 
 ret = av_mallocz(sizeof(*ret));
 if (!ret)
@@ -814,7 +813,23 @@ AVFrameSideData *av_frame_new_side_data_from_buf(AVFrame 
*frame,
 ret->size = buf->size;
 ret->type = type;
 
-frame->side_data[frame->nb_side_data++] = ret;
+set->sd[set->nb_sd++] = ret;
+
+return ret;
+}
+
+AVFrameSideData *av_frame_new_side_data_from_buf(AVFrame *frame,
+ enum AVFrameSideDataType type,
+ AVBufferRef *buf)
+{
+AVFrameSideDataSet set = {
+.sd= frame->side_data,
+.nb_sd = frame->nb_side_data,
+};
+AVFrameSideData *ret = add_side_data_to_set_from_buf(&set, type, buf);
+
+frame->side_data= set.sd;
+frame->nb_side_data = set.nb_sd;
 
 return ret;
 }
-- 
2.41.0

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

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


[FFmpeg-devel] [PATCH v3 03/12] avutil/frame: add helper for uninitializing side data sets

2023-08-17 Thread Jan Ekström
---
 libavutil/frame.c | 5 +
 libavutil/frame.h | 8 
 2 files changed, 13 insertions(+)

diff --git a/libavutil/frame.c b/libavutil/frame.c
index 4b8481b756..c90bf5d9b1 100644
--- a/libavutil/frame.c
+++ b/libavutil/frame.c
@@ -90,6 +90,11 @@ static void frame_side_data_wipe(AVFrame *frame)
 wipe_side_data(&frame->side_data, &frame->nb_side_data);
 }
 
+void av_side_data_set_uninit(AVFrameSideDataSet *set)
+{
+wipe_side_data(&set->sd, &set->nb_sd);
+}
+
 AVFrame *av_frame_alloc(void)
 {
 AVFrame *frame = av_malloc(sizeof(*frame));
diff --git a/libavutil/frame.h b/libavutil/frame.h
index 6155226c1d..e5ca7af651 100644
--- a/libavutil/frame.h
+++ b/libavutil/frame.h
@@ -1057,6 +1057,14 @@ int av_frame_apply_cropping(AVFrame *frame, int flags);
  */
 const char *av_frame_side_data_name(enum AVFrameSideDataType type);
 
+/**
+ * Free all side data items and their contents, then zeroes out the
+ * struct values.
+ *
+ * @param set the set which should be uninitialized
+ */
+void av_side_data_set_uninit(AVFrameSideDataSet *set);
+
 /**
  * @}
  */
-- 
2.41.0

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

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


[FFmpeg-devel] [PATCH v3 02/12] avutil/frame: split side data list wiping out to non-AVFrame function

2023-08-17 Thread Jan Ekström
This will make it possible to to reuse logic in further commits.
---
 libavutil/frame.c | 23 ++-
 1 file changed, 14 insertions(+), 9 deletions(-)

diff --git a/libavutil/frame.c b/libavutil/frame.c
index b6cee2d886..4b8481b756 100644
--- a/libavutil/frame.c
+++ b/libavutil/frame.c
@@ -75,14 +75,19 @@ static void free_side_data(AVFrameSideData **ptr_sd)
 av_freep(ptr_sd);
 }
 
-static void wipe_side_data(AVFrame *frame)
+static void wipe_side_data(AVFrameSideData ***sd, int *nb_side_data)
 {
-for (int i = 0; i < frame->nb_side_data; i++) {
-free_side_data(&frame->side_data[i]);
+for (int i = 0; i < *nb_side_data; i++) {
+free_side_data(&((*sd)[i]));
 }
-frame->nb_side_data = 0;
+*nb_side_data = 0;
+
+av_freep(sd);
+}
 
-av_freep(&frame->side_data);
+static void frame_side_data_wipe(AVFrame *frame)
+{
+wipe_side_data(&frame->side_data, &frame->nb_side_data);
 }
 
 AVFrame *av_frame_alloc(void)
@@ -337,7 +342,7 @@ FF_ENABLE_DEPRECATION_WARNINGS
 sd_dst = av_frame_new_side_data(dst, sd_src->type,
 sd_src->size);
 if (!sd_dst) {
-wipe_side_data(dst);
+frame_side_data_wipe(dst);
 return AVERROR(ENOMEM);
 }
 memcpy(sd_dst->data, sd_src->data, sd_src->size);
@@ -346,7 +351,7 @@ FF_ENABLE_DEPRECATION_WARNINGS
 sd_dst = av_frame_new_side_data_from_buf(dst, sd_src->type, ref);
 if (!sd_dst) {
 av_buffer_unref(&ref);
-wipe_side_data(dst);
+frame_side_data_wipe(dst);
 return AVERROR(ENOMEM);
 }
 }
@@ -525,7 +530,7 @@ FF_DISABLE_DEPRECATION_WARNINGS
 FF_ENABLE_DEPRECATION_WARNINGS
 #endif
 
-wipe_side_data(dst);
+frame_side_data_wipe(dst);
 av_dict_free(&dst->metadata);
 ret = frame_copy_props(dst, src, 0);
 if (ret < 0)
@@ -624,7 +629,7 @@ void av_frame_unref(AVFrame *frame)
 if (!frame)
 return;
 
-wipe_side_data(frame);
+frame_side_data_wipe(frame);
 
 for (int i = 0; i < FF_ARRAY_ELEMS(frame->buf); i++)
 av_buffer_unref(&frame->buf[i]);
-- 
2.41.0

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

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


[FFmpeg-devel] [PATCH v3 01/12] avutil/frame: add AVFrameSideDataSet for passing sets of side data

2023-08-17 Thread Jan Ekström
---
 libavutil/frame.h | 8 
 1 file changed, 8 insertions(+)

diff --git a/libavutil/frame.h b/libavutil/frame.h
index c0c1b23db7..6155226c1d 100644
--- a/libavutil/frame.h
+++ b/libavutil/frame.h
@@ -251,6 +251,14 @@ typedef struct AVFrameSideData {
 AVBufferRef *buf;
 } AVFrameSideData;
 
+/**
+ * Structure to hold a set of AVFrameSideData
+ */
+typedef struct AVFrameSideDataSet {
+AVFrameSideData **sd;
+intnb_sd;
+} AVFrameSideDataSet;
+
 /**
  * Structure describing a single Region Of Interest.
  *
-- 
2.41.0

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

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


[FFmpeg-devel] [PATCH v3 00/12] encoder AVCodecContext configuration side data

2023-08-17 Thread Jan Ekström
Differences to v2:
1. rebased on top of current master
2. addition of external encoder tests as the attached side data can now be
   parsed from all formats after the movement of side data from being HEVC
   specific to the common h2645 SEI parsing.
3. Various miscellaneous fixups/updates.

This patch set I've now been working for a while since I felt like it was weird
we couldn't pass through information such as static HDR metadata to encoders
from decoded input. This initial version adds the necessary framework, as well
as adds static HDR metadata support for libsvtav1, libx264 as well as libx265
wrappers.

An alternative to this would be to make encoders only properly initialize when
they receive the first AVFrame, but that seems to be a bigger, nastier change
than introducing an AVFrameSideDataSet in avctx as everything seems to
presume that extradata etc are available after opening the encoder.

Note: Any opinions on whether FFCodec or AVCodec should have
  handled_side_data list, so that if format specific generic logic is
  added, it could be checked whether the codec itself handles this side
  data? This could also be utilized to list handled side data from f.ex.
  `ffmpeg -h encoder=libsvtav1`.

Jan

Jan Ekström (12):
  avutil/frame: add AVFrameSideDataSet for passing sets of side data
  avutil/frame: split side data list wiping out to non-AVFrame function
  avutil/frame: add helper for uninitializing side data sets
  avutil/frame: split side_data_from_buf to base and AVFrame func
  avutil/frame: add helper for adding side data to set
  avutil/frame: add helper for getting side data from set
  avutil/frame: add helper for extending a set of side data
  avcodec: add side data set to AVCodecContext
  ffmpeg: pass first video AVFrame's side data to encoder
  avcodec/libsvtav1: add support for writing out CLL and MDCV
  avcodec/libx264: add support for writing out CLL and MDCV
  avcodec/libx265: add support for writing out CLL and MDCV

 fftools/ffmpeg_enc.c|  11 +++
 libavcodec/avcodec.h|   7 ++
 libavcodec/libsvtav1.c  |  70 
 libavcodec/libx264.c|  79 ++
 libavcodec/libx265.c|  82 +++
 libavcodec/options.c|   1 +
 libavutil/Makefile  |   1 +
 libavutil/frame.c   | 138 +++-
 libavutil/frame.h   |  62 ++
 libavutil/tests/side_data_set.c |  71 
 tests/fate/enc_external.mak |  15 
 tests/fate/libavutil.mak|   4 +
 tests/ref/fate/libsvtav1-hdr10  |  14 
 tests/ref/fate/libx264-hdr10|  15 
 tests/ref/fate/libx265-hdr10|  16 
 tests/ref/fate/side_data_set|   7 ++
 16 files changed, 571 insertions(+), 22 deletions(-)
 create mode 100644 libavutil/tests/side_data_set.c
 create mode 100644 tests/ref/fate/libsvtav1-hdr10
 create mode 100644 tests/ref/fate/libx264-hdr10
 create mode 100644 tests/ref/fate/libx265-hdr10
 create mode 100644 tests/ref/fate/side_data_set

-- 
2.41.0

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

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


Re: [FFmpeg-devel] [PATCH] avformat/avcodec: Add DTS-UHD demuxer and parser, movenc support.

2023-08-17 Thread Roy Funderburk
Updated for master branch changes.

--- Begin Message ---
Parsing of DTS-UHD input files per ETSI TS 102 114 is added
as parser for codec id AV_CODEC_ID_DTSUHD.

Signed-off-by: Roy Funderburk 
---
 libavcodec/Makefile|   1 +
 libavcodec/codec_desc.c|   7 +
 libavcodec/codec_id.h  |   1 +
 libavcodec/dtsuhd_common.c | 982 +
 libavcodec/dtsuhd_common.h |  83 
 libavcodec/dtsuhd_parser.c | 141 ++
 libavcodec/parsers.c   |   1 +
 libavcodec/version.h   |   2 +-
 8 files changed, 1217 insertions(+), 1 deletion(-)
 create mode 100644 libavcodec/dtsuhd_common.c
 create mode 100644 libavcodec/dtsuhd_common.h
 create mode 100644 libavcodec/dtsuhd_parser.c

diff --git a/libavcodec/Makefile b/libavcodec/Makefile
index 3c16b51462..583abd1f88 100644
--- a/libavcodec/Makefile
+++ b/libavcodec/Makefile
@@ -1167,6 +1167,7 @@ OBJS-$(CONFIG_DIRAC_PARSER)+= dirac_parser.o
 OBJS-$(CONFIG_DNXHD_PARSER)+= dnxhd_parser.o dnxhddata.o
 OBJS-$(CONFIG_DOLBY_E_PARSER)  += dolby_e_parser.o dolby_e_parse.o
 OBJS-$(CONFIG_DPX_PARSER)  += dpx_parser.o
+OBJS-$(CONFIG_DTSUHD_PARSER)   += dtsuhd_parser.o dtsuhd_common.o
 OBJS-$(CONFIG_DVAUDIO_PARSER)  += dvaudio_parser.o
 OBJS-$(CONFIG_DVBSUB_PARSER)   += dvbsub_parser.o
 OBJS-$(CONFIG_DVD_NAV_PARSER)  += dvd_nav_parser.o
diff --git a/libavcodec/codec_desc.c b/libavcodec/codec_desc.c
index 4406dd8318..e6af7f2e99 100644
--- a/libavcodec/codec_desc.c
+++ b/libavcodec/codec_desc.c
@@ -3413,6 +3413,13 @@ static const AVCodecDescriptor codec_descriptors[] = {
 .long_name = NULL_IF_CONFIG_SMALL("AC-4"),
 .props = AV_CODEC_PROP_LOSSY,
 },
+{
+.id= AV_CODEC_ID_DTSUHD,
+.type  = AVMEDIA_TYPE_AUDIO,
+.name  = "dtsuhd",
+.long_name = NULL_IF_CONFIG_SMALL("DTSUHD (DTS-UHD Audio Format)"),
+.props = AV_CODEC_PROP_LOSSY,
+},
 
 /* subtitle codecs */
 {
diff --git a/libavcodec/codec_id.h b/libavcodec/codec_id.h
index a5a0cb8525..3e87aa1fe5 100644
--- a/libavcodec/codec_id.h
+++ b/libavcodec/codec_id.h
@@ -543,6 +543,7 @@ enum AVCodecID {
 AV_CODEC_ID_WAVARC,
 AV_CODEC_ID_RKA,
 AV_CODEC_ID_AC4,
+AV_CODEC_ID_DTSUHD,
 
 /* subtitle codecs */
 AV_CODEC_ID_FIRST_SUBTITLE = 0x17000,  ///< A dummy ID pointing at 
the start of subtitle codecs.
diff --git a/libavcodec/dtsuhd_common.c b/libavcodec/dtsuhd_common.c
new file mode 100644
index 00..3d6b4ab4e0
--- /dev/null
+++ b/libavcodec/dtsuhd_common.c
@@ -0,0 +1,982 @@
+/*
+ * DTS-UHD common audio frame parsing code
+ * Copyright (c) 2023 Xperi Corporation / DTS, Inc.
+ *
+ * This file is part of FFmpeg.
+ *
+ * FFmpeg is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public
+ * License as published by the Free Software Foundation; either
+ * version 2.1 of the License, or (at your option) any later version.
+ *
+ * FFmpeg is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+ * Lesser General Public License for more details.
+ *
+ * You should have received a copy of the GNU Lesser General Public
+ * License along with FFmpeg; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA
+ */
+
+/**
+ * @file
+ * Parse DTS-UHD audio frame headers, report frame sizes and configuration.
+ * Specification: ETSI TS 103 491 V1.2.1
+ */
+
+#include 
+
+#include "dtsuhd_common.h"
+#include "get_bits.h"
+#include "libavutil/channel_layout.h"
+#include "libavutil/crc.h"
+
+#define DTSUHD_ALLOC_INCREMENT 16
+#define DTSUHD_CHUNK_HEADER16
+#define DTSUHD_CRC_SEED 0x
+
+enum RepType {
+REP_TYPE_CH_MASK_BASED,
+REP_TYPE_MTRX2D_CH_MASK_BASED,
+REP_TYPE_MTRX3D_CH_MASK_BASED,
+REP_TYPE_BINAURAL,
+REP_TYPE_AMBISONIC,
+REP_TYPE_AUDIO_TRACKS,
+REP_TYPE_3D_OBJECT_SINGLE_SRC_PER_WF,
+REP_TYPE_3D_MONO_OBJECT_SINGLE_SRC_PER_WF,
+};
+
+typedef struct MDObject {
+int started;  /* Object seen since last reset. */
+int pres_index;
+int rep_type;
+int ch_activity_mask;
+} MDObject;
+
+typedef struct MD01 {
+GetBitContext gb;
+MDObject object[257]; /* object id max value is 256 */
+int chunk_id;
+int object_list[256]; int object_list_count;
+int packets_acquired;
+int static_md_extracted;
+int static_md_packets;
+int static_md_packet_size;
+int static_md_update_flag;
+uint8_t *buf; int buf_bytes; /* temporary buffer to accumulate static data 
*/
+} MD01;
+
+typedef struct NAVI {
+int bytes;
+int id;
+int index;
+int present;
+} NAVI;
+
+typedef struct UHDAudio {
+int mask;
+int selectable;
+} UHDAudio;
+
+typedef struct UHDChunk {
+int crc_flag;
+int

Re: [FFmpeg-devel] [PATCH] avcodec/exr: tag gamma=1.0 output as linear light

2023-08-17 Thread Leo Izen

On 8/17/23 08:59, Tomas Härdin wrote:

ons 2023-08-16 klockan 01:20 -0400 skrev Leo Izen:

By default the OpenEXR decoder outputs linear light pixel data by
applying a gamma=1.0 transfer (i.e. a no-op). When it does so, it
should tag the data as linear so color-managed filters or other tools
can work with it correctly.

Signed-off-by: Leo Izen 
---
  libavcodec/exr.c | 2 ++
  1 file changed, 2 insertions(+)

diff --git a/libavcodec/exr.c b/libavcodec/exr.c
index fae1d08ab0..518066facf 100644
--- a/libavcodec/exr.c
+++ b/libavcodec/exr.c
@@ -2088,6 +2088,8 @@ static int decode_frame(AVCodecContext *avctx,
AVFrame *picture,
  
  if (s->apply_trc_type != AVCOL_TRC_UNSPECIFIED)

  avctx->color_trc = s->apply_trc_type;
+    else if (s->gamma > 0.f && s->gamma < 1.0001f)
+    avctx->color_trc = AVCOL_TRC_LINEAR;


I'm going to be difficult here and point out that gamma=0.1 is not
linear. It's probably linear *enough* most of the time, but also 1.0
can be exactly represented by float so an equality check seems
appropriate.


This exact check exists elsewhere in the source file. There's a branch 
where it sets up a LUT if gamma is not between those values, and has a 
no-op track otherwise - so in the event you request 0.5 or something 
of that form, the code that does the color conversion treats it as 1.0f.


- Leo Izen


___
ffmpeg-devel mailing list
ffmpeg-devel@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] VDD conference invitation - Dublin 22-24 Sept 2023

2023-08-17 Thread Jean-Baptiste Kempf
Hello FFfolks,

I'm glad to invite you to VDD 2023 in Dublin, at the end of next month.
I wish I could have invited you to Iceland, but it proved too difficult to 
organize over there. I'll do better next year, I promise :)

What is it?
---
The format of the conference is going to be similar to the previous years:
- Friday 22nd, community day in Dublin, where we'll do some activities (will be 
communicated later) and then drinks on the evening
- Saturday 23rd, start of the actual conferences, with talks by members from 
our communities on very technical subjects, in the morning, until lunch.
- Saturday afternoon, technical sessions (VLC and FFmpeg in // probably) in an 
unconference manner.
- Saturday night, a dinner in Dublin.
- Sunday morning, lightning talks, for the early people
- Sunday morning and afternoon, workshops and technical sessions (x264, dav1d, 
VLC mobile, placebo...)

We will be at Trinity College, in Dublin.

Who is welcome to join?
---
Everyone that cares about any open source multimedia project, VLC, FFmpeg, 
x264, dav1d, placebo, mpv, kodi, phonon, x265... is welcome.
If you are a GSoC student, you should also come. If you are just a fan and a 
user, you shall probably come.

How do I register?
--
You can register here: https://framaforms.org/vdd-2023-1691924544
Registration will close at the end of this month.

How do I get reimbursed?
--
If you are an active member of one of our open source communities, VideoLAN 
will cover your costs, meaning Hotels + Flight/Train/Boat to Dublin.
If you are part of the VideoLAN non-profit, if you are part of the FFmpeg GA, 
you are invited.
If you have commits on git.ffmpeg.org or code.videolan.org, you are invited.
If you are a GSoC student, your costs will be covered too.
If you are unsure about if you are eligible, you should mail me...

What should I do now?
-
1. Register
2. Book your flights.
3. Help us.

For your flights, please try and find flights that are not too expensive, if 
VideoLAN cover your costs.
We have no sponsors this year, so be mindful about our costs.
(Today flights from Berlin can be found easily at 100-150e, and 200e from 
Paris. Coming from SF can be found at 800e)

How can I help?
---
Propose a talk, from 5min to 30min.
Help the organisation.
Bring smile and join to VDD.

Questions?

For any question, please mail me :)

Thanks and see you soon.

jbk

Remarks:
- this is a technical conference. If you are not a technical person, this will 
probably bore you.
- VideoLAN CoC applies to VDD.

-- 
Jean-Baptiste Kempf -  President
+33 672 704 734
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

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


Re: [FFmpeg-devel] [RFC] swscale RGB24->YUV420P

2023-08-17 Thread Michael Niedermayer
On Thu, Aug 17, 2023 at 10:42:13AM +0100, John Cox wrote:
> On Wed, 16 Aug 2023 19:37:02 +0200, you wrote:
> 
> >On Wed, Aug 16, 2023 at 05:15:23PM +0100, John Cox wrote:
> >> Hi
> >> 
> >> The Pi has a use for a fast RGB24->YUV420P path for encoding camera
> >> video. There is an existing BGR24 converter but if I build a RGB24
> >> converter using the same logic (rearrange the conversion matrix and use
> >> the same code) I get a fate fail on filter-fps-cfr (and possibly others)
> >> which appears to decode a file to RGB24, convert to YUV420P and take the
> >> CRC of that so almost any change to the conversion breaks this
> >> (unrelated?) test.
> >> 
> >> My initial assumption was that if the code to conversion in
> >> libswscale/rgb2rgb_template:bgr24toyv12_c was good enough for BGR24->YUV
> >> then it should be good enough for RGB24->YUV too. However it breaks this
> >> fate case - what is an acceptable way to resolve this?
> >
> >update the checksum (if needed), and put the code under appropriate bitexact 
> >flags checks
> >(there may be remaining issues but hard to say without seeing and being
> >abel to test the code)
> 
> Thanks for the prompt answer. The current test invocation goes:
> 
>  /home/jc/work/rpi/ffmpeg2/out/x86/ffmpeg -nostdin -nostats
> -noauto_conversion_filters -cpuflags all -auto_conversion_filters
> -hwaccel none -threads 1 -thread_type frame+slice -i
> /home/jc/rpi/conform/fate-suite/qtrle/apple-animation-variable-fps-bug.mov
> -r 30 -vsync cfr -pix_fmt yuv420p -bitexact -f framecrc -
> 
> Which appears, at first sight, to already have the required bitexact
> flag in it, however it doesn't get passed to the swscale context - in
> order for that to happen I need something like:
> 
>  /home/jc/work/rpi/ffmpeg2/out/x86/ffmpeg -fflags bitexact -nostdin
> -nostats -noauto_conversion_filters -cpuflags all
> -auto_conversion_filters -hwaccel none -threads 1 -thread_type
> frame+slice -i
> /home/jc/rpi/conform/fate-suite/qtrle/apple-animation-variable-fps-bug.mov
> -r 30 -vsync cfr -vf scale=sws_flags=bitexact -pix_fmt yuv420p -bitexact
> -f framecrc -
> 
> i.e. adding an explicit "-vf scale=sws_flags=bitexact". Is this the
> correct answer or is it a bug that the auto conversion fails to respect
> the existing bitexact flag?

It would be ideal that the main "-bitexact" gets passed to sws_flags

a patch fixing that would be welcome! But one needs to still be
able to remove the bitexact flag from sws_flags, only the default should
change when -bitexact is specfied and nothing specific is specified for 
sws_flags

thx

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

Republics decline into democracies and democracies degenerate into
despotisms. -- Aristotle


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

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


[FFmpeg-devel] [PATCH v2] avutil/channel_layout: make pre-defined channel layouts C++ friendly

2023-08-17 Thread Zhao Zhili
From: Zhao Zhili 

C++ doesn't support designated initializers until C++20. We have
a bunch of pre-defined channel layouts, the gains to make them
usable in C++ exceed the losses.

Bump minor version so C++ project can check before use these defines.

Also initialize .opaque field explicitly to reduce warning in C++.
---
v2:
1. Keep field names in comments.
2. Bump minor version.
3. Add comments so it won't be reverted by accident.

 libavutil/channel_layout.h | 5 +++--
 libavutil/version.h| 4 ++--
 2 files changed, 5 insertions(+), 4 deletions(-)

diff --git a/libavutil/channel_layout.h b/libavutil/channel_layout.h
index f345415c55..f019b3d7ad 100644
--- a/libavutil/channel_layout.h
+++ b/libavutil/channel_layout.h
@@ -358,8 +358,9 @@ typedef struct AVChannelLayout {
 void *opaque;
 } AVChannelLayout;
 
+/* Don't use designated initializers since C++ doesn't support it until C++20. 
*/
 #define AV_CHANNEL_LAYOUT_MASK(nb, m) \
-{ .order = AV_CHANNEL_ORDER_NATIVE, .nb_channels = (nb), .u = { .mask = 
(m) }}
+{ /* .order */ AV_CHANNEL_ORDER_NATIVE, /* .nb_channels */  (nb), /* 
.u.mask */ { m }, /* .opaque */ NULL }
 
 /**
  * @name Common pre-defined channel layouts
@@ -397,7 +398,7 @@ typedef struct AVChannelLayout {
 #define AV_CHANNEL_LAYOUT_STEREO_DOWNMIXAV_CHANNEL_LAYOUT_MASK(2,  
AV_CH_LAYOUT_STEREO_DOWNMIX)
 #define AV_CHANNEL_LAYOUT_22POINT2  AV_CHANNEL_LAYOUT_MASK(24, 
AV_CH_LAYOUT_22POINT2)
 #define AV_CHANNEL_LAYOUT_AMBISONIC_FIRST_ORDER \
-{ .order = AV_CHANNEL_ORDER_AMBISONIC, .nb_channels = 4, .u = { .mask = 0 
}}
+{ /* .order */ AV_CHANNEL_ORDER_AMBISONIC, /* .nb_channels */ 4, /* 
.u.mask */ { 0 }, NULL }
 /** @} */
 
 struct AVBPrint;
diff --git a/libavutil/version.h b/libavutil/version.h
index 5a4d4d3d73..bc43baca9f 100644
--- a/libavutil/version.h
+++ b/libavutil/version.h
@@ -79,8 +79,8 @@
  */
 
 #define LIBAVUTIL_VERSION_MAJOR  58
-#define LIBAVUTIL_VERSION_MINOR  16
-#define LIBAVUTIL_VERSION_MICRO 101
+#define LIBAVUTIL_VERSION_MINOR  17
+#define LIBAVUTIL_VERSION_MICRO 100
 
 #define LIBAVUTIL_VERSION_INT   AV_VERSION_INT(LIBAVUTIL_VERSION_MAJOR, \
LIBAVUTIL_VERSION_MINOR, \
-- 
2.34.1

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

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


Re: [FFmpeg-devel] [PATCH] avutil/channel_layout: make pre-defined channel layouts C++ friendly

2023-08-17 Thread zhilizhao(赵志立)


> On Aug 17, 2023, at 20:57, Tomas Härdin  wrote:
> 
> ons 2023-08-16 klockan 23:44 +0800 skrev Zhao Zhili:
>> From: Zhao Zhili 
>> 
>> C++ doesn't support designated initializers until C++20. We have
>> a bunch of pre-defined channel layouts, the gains to make them
>> usable in C++ exceed the losses.
>> 
>> Signed-off-by: Zhao Zhili 
>> ---
>>  libavutil/channel_layout.h | 4 ++--
>>  1 file changed, 2 insertions(+), 2 deletions(-)
>> 
>> diff --git a/libavutil/channel_layout.h b/libavutil/channel_layout.h
>> index f345415c55..817a5ad370 100644
>> --- a/libavutil/channel_layout.h
>> +++ b/libavutil/channel_layout.h
>> @@ -359,7 +359,7 @@ typedef struct AVChannelLayout {
>>  } AVChannelLayout;
>>  
>>  #define AV_CHANNEL_LAYOUT_MASK(nb, m) \
>> -{ .order = AV_CHANNEL_ORDER_NATIVE, .nb_channels = (nb), .u = {
>> .mask = (m) }}
>> +{ AV_CHANNEL_ORDER_NATIVE, (nb), { m }, NULL }
>>  
>>  /**
>>   * @name Common pre-defined channel layouts
>> @@ -397,7 +397,7 @@ typedef struct AVChannelLayout {
>>  #define AV_CHANNEL_LAYOUT_STEREO_DOWNMIX   
>> AV_CHANNEL_LAYOUT_MASK(2,  AV_CH_LAYOUT_STEREO_DOWNMIX)
>>  #define AV_CHANNEL_LAYOUT_22POINT2 
>> AV_CHANNEL_LAYOUT_MASK(24, AV_CH_LAYOUT_22POINT2)
>>  #define AV_CHANNEL_LAYOUT_AMBISONIC_FIRST_ORDER \
>> -{ .order = AV_CHANNEL_ORDER_AMBISONIC, .nb_channels = 4, .u = {
>> .mask = 0 }}
>> +{ AV_CHANNEL_ORDER_AMBISONIC, 4, { 0 }, NULL }
> 
> For C++ compat you could use some constructor magic instead, and turn
> these into proper constants. Hidden behind #ifdef __cplusplus of
> course.

I’m trying to avoid more debate to not refer to __cplusplus on purpose.

> 
> IMO having untyped #defines like this is mega ugly. At the very least
> it should be (AVChannelLayout){...}. It's likely cargo culted from when
> channel layouts were bitmasks.

(AVChannelLayout){…} can be invalid in C++. AV_TIME_BASE_Q has the problem
already.

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


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

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


Re: [FFmpeg-devel] [PATCH v2 1/8] cbs_h266: fix inference for sh_lmcs_used_flag and sh_explicit_scaling_list_used_flag

2023-08-17 Thread James Almer

On 8/8/2023 7:58 AM, Nuo Mi wrote:

if sh_picture_header_in_slice_header_flag is true
sh_lmcs_used_flag and sh_explicit_scaling_list_used_flag are infered from ph

Failed clips:
LMCS: CLM_A_KDDI_2.bit STILL444_A_KDDI_1.bit
Scaling: SCALING_B_InterDigital_1.bit SCALING_A_InterDigital_1.bit
---
  libavcodec/cbs_h266_syntax_template.c | 24 ++--
  1 file changed, 14 insertions(+), 10 deletions(-)

diff --git a/libavcodec/cbs_h266_syntax_template.c 
b/libavcodec/cbs_h266_syntax_template.c
index 98a8e033bf..857882655b 100644
--- a/libavcodec/cbs_h266_syntax_template.c
+++ b/libavcodec/cbs_h266_syntax_template.c
@@ -3151,17 +3151,21 @@ static int FUNC(slice_header) (CodedBitstreamContext 
*ctx, RWContext *rw,
  infer(sh_alf_enabled_flag, 0);
  }
  
-if (ph->ph_lmcs_enabled_flag &&

-!current->sh_picture_header_in_slice_header_flag)
-flag(sh_lmcs_used_flag);
-else
-infer(sh_lmcs_used_flag, 0);
+if (current->sh_picture_header_in_slice_header_flag) {
+infer(sh_lmcs_used_flag, ph->ph_lmcs_enabled_flag);
+infer(sh_explicit_scaling_list_used_flag,
+ph->ph_explicit_scaling_list_enabled_flag);
+} else {
+if (ph->ph_lmcs_enabled_flag)
+flag(sh_lmcs_used_flag);
+else
+infer(sh_lmcs_used_flag, 0);
  
-if (ph->ph_explicit_scaling_list_enabled_flag &&

-!current->sh_picture_header_in_slice_header_flag)
-flag(sh_explicit_scaling_list_used_flag);
-else
-infer(sh_explicit_scaling_list_used_flag, 0);
+if (ph->ph_explicit_scaling_list_enabled_flag)
+flag(sh_explicit_scaling_list_used_flag);
+else
+infer(sh_explicit_scaling_list_used_flag, 0);
+}
  
  if (!pps->pps_rpl_info_in_ph_flag &&

  ((nal_unit_type != VVC_IDR_W_RADL &&


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

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


Re: [FFmpeg-devel] [PATCH] avcodec/exr: tag gamma=1.0 output as linear light

2023-08-17 Thread Tomas Härdin
ons 2023-08-16 klockan 01:20 -0400 skrev Leo Izen:
> By default the OpenEXR decoder outputs linear light pixel data by
> applying a gamma=1.0 transfer (i.e. a no-op). When it does so, it
> should tag the data as linear so color-managed filters or other tools
> can work with it correctly.
> 
> Signed-off-by: Leo Izen 
> ---
>  libavcodec/exr.c | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/libavcodec/exr.c b/libavcodec/exr.c
> index fae1d08ab0..518066facf 100644
> --- a/libavcodec/exr.c
> +++ b/libavcodec/exr.c
> @@ -2088,6 +2088,8 @@ static int decode_frame(AVCodecContext *avctx,
> AVFrame *picture,
>  
>  if (s->apply_trc_type != AVCOL_TRC_UNSPECIFIED)
>  avctx->color_trc = s->apply_trc_type;
> +    else if (s->gamma > 0.f && s->gamma < 1.0001f)
> +    avctx->color_trc = AVCOL_TRC_LINEAR;

I'm going to be difficult here and point out that gamma=0.1 is not
linear. It's probably linear *enough* most of the time, but also 1.0
can be exactly represented by float so an equality check seems
appropriate

/Tomas

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

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


Re: [FFmpeg-devel] [PATCH] avutil/channel_layout: make pre-defined channel layouts C++ friendly

2023-08-17 Thread Tomas Härdin
ons 2023-08-16 klockan 23:44 +0800 skrev Zhao Zhili:
> From: Zhao Zhili 
> 
> C++ doesn't support designated initializers until C++20. We have
> a bunch of pre-defined channel layouts, the gains to make them
> usable in C++ exceed the losses.
> 
> Signed-off-by: Zhao Zhili 
> ---
>  libavutil/channel_layout.h | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/libavutil/channel_layout.h b/libavutil/channel_layout.h
> index f345415c55..817a5ad370 100644
> --- a/libavutil/channel_layout.h
> +++ b/libavutil/channel_layout.h
> @@ -359,7 +359,7 @@ typedef struct AVChannelLayout {
>  } AVChannelLayout;
>  
>  #define AV_CHANNEL_LAYOUT_MASK(nb, m) \
> -    { .order = AV_CHANNEL_ORDER_NATIVE, .nb_channels = (nb), .u = {
> .mask = (m) }}
> +    { AV_CHANNEL_ORDER_NATIVE, (nb), { m }, NULL }
>  
>  /**
>   * @name Common pre-defined channel layouts
> @@ -397,7 +397,7 @@ typedef struct AVChannelLayout {
>  #define AV_CHANNEL_LAYOUT_STEREO_DOWNMIX   
> AV_CHANNEL_LAYOUT_MASK(2,  AV_CH_LAYOUT_STEREO_DOWNMIX)
>  #define AV_CHANNEL_LAYOUT_22POINT2 
> AV_CHANNEL_LAYOUT_MASK(24, AV_CH_LAYOUT_22POINT2)
>  #define AV_CHANNEL_LAYOUT_AMBISONIC_FIRST_ORDER \
> -    { .order = AV_CHANNEL_ORDER_AMBISONIC, .nb_channels = 4, .u = {
> .mask = 0 }}
> +    { AV_CHANNEL_ORDER_AMBISONIC, 4, { 0 }, NULL }

For C++ compat you could use some constructor magic instead, and turn
these into proper constants. Hidden behind #ifdef __cplusplus of
course.

IMO having untyped #defines like this is mega ugly. At the very least
it should be (AVChannelLayout){...}. It's likely cargo culted from when
channel layouts were bitmasks.

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

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


[FFmpeg-devel] [PATCH v1 1/1] lavc/qsvdec: fix dead loop of qsv decoding

2023-08-17 Thread Ting Hu
From: tinghu3 

MFXVideoDECODE_DecodeFrameAsync always return MFX_WRN_DEVICE_BUSY in special 
scenario.

Signed-off-by: tinghu3 
---
 libavcodec/qsvdec.c | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/libavcodec/qsvdec.c b/libavcodec/qsvdec.c
index da700f25e9..35102fb476 100644
--- a/libavcodec/qsvdec.c
+++ b/libavcodec/qsvdec.c
@@ -703,6 +703,7 @@ static int qsv_decode(AVCodecContext *avctx, QSVContext *q,
 mfxSyncPoint *sync;
 mfxBitstream bs = { { { 0 } } };
 int ret;
+int max_count = 0;
 
 if (avpkt->size) {
 bs.Data   = avpkt->data;
@@ -730,7 +731,9 @@ static int qsv_decode(AVCodecContext *avctx, QSVContext *q,
   insurf, &outsurf, sync);
 if (ret == MFX_WRN_DEVICE_BUSY)
 av_usleep(500);
-
+/* Check the max wait time 500ms to avoid dead loop */
+if (++max_count == 1000)
+return ret;
 } while (ret == MFX_WRN_DEVICE_BUSY || ret == MFX_ERR_MORE_SURFACE);
 
 if (ret == MFX_ERR_INCOMPATIBLE_VIDEO_PARAM) {
-- 
2.38.1

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

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


Re: [FFmpeg-devel] [RFC] swscale RGB24->YUV420P

2023-08-17 Thread John Cox
On Wed, 16 Aug 2023 19:37:02 +0200, you wrote:

>On Wed, Aug 16, 2023 at 05:15:23PM +0100, John Cox wrote:
>> Hi
>> 
>> The Pi has a use for a fast RGB24->YUV420P path for encoding camera
>> video. There is an existing BGR24 converter but if I build a RGB24
>> converter using the same logic (rearrange the conversion matrix and use
>> the same code) I get a fate fail on filter-fps-cfr (and possibly others)
>> which appears to decode a file to RGB24, convert to YUV420P and take the
>> CRC of that so almost any change to the conversion breaks this
>> (unrelated?) test.
>> 
>> My initial assumption was that if the code to conversion in
>> libswscale/rgb2rgb_template:bgr24toyv12_c was good enough for BGR24->YUV
>> then it should be good enough for RGB24->YUV too. However it breaks this
>> fate case - what is an acceptable way to resolve this?
>
>update the checksum (if needed), and put the code under appropriate bitexact 
>flags checks
>(there may be remaining issues but hard to say without seeing and being
>abel to test the code)

Thanks for the prompt answer. The current test invocation goes:

 /home/jc/work/rpi/ffmpeg2/out/x86/ffmpeg -nostdin -nostats
-noauto_conversion_filters -cpuflags all -auto_conversion_filters
-hwaccel none -threads 1 -thread_type frame+slice -i
/home/jc/rpi/conform/fate-suite/qtrle/apple-animation-variable-fps-bug.mov
-r 30 -vsync cfr -pix_fmt yuv420p -bitexact -f framecrc -

Which appears, at first sight, to already have the required bitexact
flag in it, however it doesn't get passed to the swscale context - in
order for that to happen I need something like:

 /home/jc/work/rpi/ffmpeg2/out/x86/ffmpeg -fflags bitexact -nostdin
-nostats -noauto_conversion_filters -cpuflags all
-auto_conversion_filters -hwaccel none -threads 1 -thread_type
frame+slice -i
/home/jc/rpi/conform/fate-suite/qtrle/apple-animation-variable-fps-bug.mov
-r 30 -vsync cfr -vf scale=sws_flags=bitexact -pix_fmt yuv420p -bitexact
-f framecrc -

i.e. adding an explicit "-vf scale=sws_flags=bitexact". Is this the
correct answer or is it a bug that the auto conversion fails to respect
the existing bitexact flag?

>> A further question assuming that the above can be resolved - I have also
>> written aarch64 asm for this (RGB24/BGR24->YUV420P). It costs nothing in
>> the asm to round the output values to nearest rather than just rounding
>> down as the C template does and doing so improves the accuracy reported
>> by tests/swscale - however at that point the asm and the C don't produce
>> identical results. I assume that the x86 asm for BGR24 conversion does
>> match the C. What is the best thing to do here?
>
>The more differences there are between implementations the more annoying
>it is but there is a bitexact flag that allows differences

Thanks

John Cox

>thx
>
>[...]
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

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