Re: [FFmpeg-devel] [PATCH] avformat/mxfdec: support MCA audio information

2022-01-02 Thread Andreas Rheinhardt 
Pierre-Anthony Lemieux:
> On Sat, Jan 1, 2022 at 5:35 PM Andreas Rheinhardt
>  wrote:
>>
>> Pierre-Anthony Lemieux:
>>> Minor suggestion below.
>>>
>>> In addition, will sample file(s) be added to FATE? Below are two examples:
>>>
>>> http://ffmpeg-imf-samples-public.s3.us-west-1.amazonaws.com/callout_51_l_r_c_lfe_ls_rs.mxf
>>> http://ffmpeg-imf-samples-public.s3.us-west-1.amazonaws.com/callout_51_l_c_r_ls_rs_lfe.mxf
>>>
>>
>> These files are 1.62MiB each, having 49 packets of lossless audio. Would
>> it decrease coverage if this were reduced? After all, the amount of
>> audio should not matter for channel reorderings.
> 
> Each channel contains a synthesized human voice that announces the
> name of the channel, so that a reviewer can, by simple inspection,
> confirm the expected channel order. This will be particularly useful
> when automatic channel reordering is performed.
> 
> The contents of each channel could be changed to a single tone with
> each channel assigned a different tone, e.g. 1 to 6 kHz. This might
> make the files shorter.
> 

A human voice sounds like something that is nice to have; but does it
have to be 24bit? As I see it, mxf allows 16bit sound everywhere where
it allows 24bit. Furthermore, the channels will still be recognizably
different if the audio is cut off at 1s (this will cut off the "effect"
from "low frequency effect" and will also cut off beeps for the others).

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

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

[FFmpeg-devel] [PATCH] configure: Make IMF demuxer require MXF demuxer

2022-01-02 Thread Andreas Rheinhardt 
The former is useless without the latter.

Signed-off-by: Andreas Rheinhardt 
---
 configure | 1 +
 1 file changed, 1 insertion(+)

diff --git a/configure b/configure
index 6ad70b9f7b..e2ea473565 100755
--- a/configure
+++ b/configure
@@ -3416,6 +3416,7 @@ hls_muxer_suggest="gcrypt openssl"
 image2_alias_pix_demuxer_select="image2_demuxer"
 image2_brender_pix_demuxer_select="image2_demuxer"
 imf_demuxer_deps="libxml2"
+imf_demuxer_select="mxf_demuxer"
 ipod_muxer_select="mov_muxer"
 ismv_muxer_select="mov_muxer"
 ivf_muxer_select="av1_metadata_bsf vp9_superframe_bsf"
-- 
2.32.0

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

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

Re: [FFmpeg-devel] [PATCH v9 4/6] lavc: Implement Dolby Vision RPU parsing

2022-01-02 Thread Andreas Rheinhardt 
Hendrik Leppkes:
> Andreas Rheinhardt  schrieb am So., 2. Jan.
> 2022, 05:18:
> 
>> Niklas Haas:
>>> From: Niklas Haas 
>>>
>>> Based on a mixture of guesswork, partial documentation in patents, and
>>> reverse engineering of real-world samples. Confirmed working for all the
>>> samples I've thrown at it.
>>>
>>> Contains some annoying machinery to persist these values in between
>>> frames, which is needed in theory even though I've never actually seen a
>>> sample that relies on it in practice. May or may not work.
>>>
>>> Since the distinction matters greatly for parsing the color matrix
>>> values, this includes a small helper function to guess the right profile
>>> from the RPU itself in case the user has forgotten to forward the dovi
>>> configuration record to the decoder. (Which in practice, only ffmpeg.c
>>> and ffplay do..)
>>>
>>> Notable omissions / deviations:
>>> - CRC32 verification. This is based on the MPEG2 CRC32 type, which does
>>>   not seem to be implemented in lavu. (And I don't care enough to do so)
>>> - Linear interpolation support. Nothing documents this (beyond its
>>>   existence) and no samples use it, so impossible to implement.
>>> - All of the extension metadata blocks, but these contain values that
>>>   seem largely congruent with ST2094, HDR10, or other existing forms of
>>>   side data, so I will defer parsing/attaching them to a future commit.
>>> - The patent describes a mechanism for predicting coefficients from
>>>   previous RPUs, but the bit for the flag whether to use the
>>>   prediction deltas or signal entirely new coefficients does not seem to
>>>   be present in actual RPUs, so we ignore this subsystem entirely.
>>> - In the patent's spec, the NLQ subsystem also loops over
>>>   num_nlq_pivots, but even in the patent the number is hard-coded to one
>>>   iteration rather than signalled. So we only store one set of coefs.
>>>
>>> Heavily influenced by https://github.com/quietvoid/dovi_tool
>>> Documentation drawn from US Patent 10,701,399 B2 and ETSI GS CCM 001
>>>
>>> Signed-off-by: Niklas Haas 
>>> ---
>>>  configure |   2 +
>>>  libavcodec/Makefile   |   1 +
>>>  libavcodec/dovi_rpu.c | 430 ++
>>>  libavcodec/dovi_rpu.h |  71 +++
>>>  4 files changed, 504 insertions(+)
>>>  create mode 100644 libavcodec/dovi_rpu.c
>>>  create mode 100644 libavcodec/dovi_rpu.h
>>>
>>> diff --git a/configure b/configure
>>> index 0ccd3bda11..68658a847f 100755
>>> --- a/configure
>>> +++ b/configure
>>> @@ -2434,6 +2434,7 @@ CONFIG_EXTRA="
>>>  cbs_vp9
>>>  dirac_parse
>>>  dnn
>>> +dovi_rpu
>>>  dvprofile
>>>  exif
>>>  faandct
>>> @@ -2706,6 +2707,7 @@ cbs_mpeg2_select="cbs"
>>>  cbs_vp9_select="cbs"
>>>  dct_select="rdft"
>>>  dirac_parse_select="golomb"
>>> +dovi_rpu_select="golomb"
>>>  dnn_suggest="libtensorflow libopenvino"
>>>  dnn_deps="avformat swscale"
>>>  error_resilience_select="me_cmp"
>>> diff --git a/libavcodec/Makefile b/libavcodec/Makefile
>>> index fb90ecea84..7364c7a91f 100644
>>> --- a/libavcodec/Makefile
>>> +++ b/libavcodec/Makefile
>>> @@ -77,6 +77,7 @@ OBJS-$(CONFIG_CBS_MPEG2)   += cbs_mpeg2.o
>>>  OBJS-$(CONFIG_CBS_VP9) += cbs_vp9.o
>>>  OBJS-$(CONFIG_CRYSTALHD)   += crystalhd.o
>>>  OBJS-$(CONFIG_DCT) += dct.o dct32_fixed.o
>> dct32_float.o
>>> +OBJS-$(CONFIG_DOVI_RPU)+= dovi_rpu.o
>>>  OBJS-$(CONFIG_ERROR_RESILIENCE)+= error_resilience.o
>>>  OBJS-$(CONFIG_EXIF)+= exif.o tiff_common.o
>>>  OBJS-$(CONFIG_FAANDCT) += faandct.o
>>> diff --git a/libavcodec/dovi_rpu.c b/libavcodec/dovi_rpu.c
>>> new file mode 100644
>>> index 00..fc2e1fb2a1
>>> --- /dev/null
>>> +++ b/libavcodec/dovi_rpu.c
>>> @@ -0,0 +1,430 @@
>>> +/*
>>> + * Dolby Vision RPU decoder
>>> + *
>>> + * Copyright (C) 2021 Jan Ekström
>>> + * Copyright (C) 2021 Niklas Haas
>>> + *
>>> + * This file is part of FFmpeg.
>>> + *
>>> + * FFmpeg is free software; you can redistribute it and/or
>>> + * modify it under the terms of the GNU Lesser General Public
>>> + * License as published by the Free Software Foundation; either
>>> + * version 2.1 of the License, or (at your option) any later version.
>>> + *
>>> + * FFmpeg is distributed in the hope that it will be useful,
>>> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
>>> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
>>> + * Lesser General Public License for more details.
>>> + *
>>> + * You should have received a copy of the GNU Lesser General Public
>>> + * License along with FFmpeg; if not, write to the Free Software
>>> + * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA
>> 02110-1301 USA
>>> + */
>>> +
>>> +#include "libavutil/buffer.h"
>>> +
>>> +#include "dovi_rpu.h"
>>> +#include "golomb.h"
>>> +#include "get_bits.h"
>>> +
>>> +enum {
>>> +RPU_COEFF_FIXED = 0,
>>>

Re: [FFmpeg-devel] [PATCH 02/11] avcodec/raw: Reduce number of avpriv symbols

2022-01-02 Thread Andreas Rheinhardt 
Anton Khirnov:
> Quoting Andreas Rheinhardt (2021-12-15 13:35:32)
>> libavcodec currently exports four avpriv symbols that deal with
>> PixelFormatTags: avpriv_get_raw_pix_fmt_tags, avpriv_find_pix_fmt,
>> avpriv_pix_fmt_bps_avi and avpriv_pix_fmt_bps_mov. The latter two are
>> lists of PixelFormatTags, the former returns such a list and the second
>> searches a list for a pixel format that matches a given fourcc; only
>> one of the aforementioned three lists is ever searched.
>>
>> Yet for avpriv_pix_fmt_bps_avi, avpriv_pix_fmt_bps_mov and
>> avpriv_find_pix_fmt the overhead of exporting these functions actually
>> exceeds the size of said objects (at least for ELF; the following numbers
>> are for x64 Ubuntu 20.10):
>> The code size of avpriv_find_pix_fmt is small (GCC 10.2 37B, Clang 11 41B),
>> yet exporting it adds a 20B string for the name alone to the exporting
>> as well as to each importing library; there is more: Four bytes in the
>> exporting libraries .gnu.hash; two bytes each for the exporting as well
>> as each importing libraries .gnu.version; 24B in the exporting as well
>> as each importing libraries .dynsym; 16B+24B for an entry in .plt as
>> well as the accompanying relocation entry in .rela.plt for each
>> importing library.
>>
>> The overhead for the lists is similar: The strings are 23B and the
>> .plt+.rela.plt pair is replaced by 8B+24B for an entry in .got and
>> a relocation entry in .rela.dyn. These lists have a size of 80 resp.
>> 72 bytes.
>>
>> Yet for ff_raw_pix_fmt_tags, exporting it is advantageous compared to
>> duplicating it into libavformat and potentially libavdevice. Therefore
>> this commit replaces all library uses of the four symbols with a single
>> function that is exported for shared builds. It has an enum parameter
>> to choose the desired list besides the parameter for the fourcc. New
>> lists can be supported with new enum values.
>>
>> Unfortunately, avpriv_get_raw_pix_fmt_tags could not be removed, as the
>> fourcc2pixfmt tool uses the table of raw pix fmts. No other user of this
>> function remains.
>>
>> Signed-off-by: Andreas Rheinhardt 
>> ---
>> 1. It would make sense to deduplicate avpriv_pix_fmt_bps_(mov|avi)
>> size-wise if it is preferred to keep the lists accessible to users.
>> 2. One could handle the fourcc2pixfmt case in avpriv_pix_fmt_find(),
>> too, if one added another parameter (say count). In this case
>> avpriv_pix_fmt_find() will return the first pixfmt with the desired
>> fourcc if count is zero, the second one is count is 1 etc. (and
>> AV_PIX_FMT_NONE in case there is none any more). This would also make
>> this function more future-proof.
> 
> Would it not be simpler to add a second function returning a pointer to
> the full table?
> 

There is already a function to return the full table:
avpriv_get_raw_pix_fmt_tags. It is what fourcc2pixfmt uses. The goal of
the above considerations is to reduce the number of exported symbols,
namely avpriv_get_raw_pix_fmt_tags.

> Also, I would prefer making this completely public rather than avpriv.
> 

___
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] 5.0 release

2022-01-02 Thread Jean-Baptiste Kempf 
On Fri, 31 Dec 2021, at 20:40, Michael Niedermayer wrote:
>> It would be nice to have a public date set a few days into the future.
>
> yes, i intended to do that, unless people wanted a ASAP/NOW branch

So what are the open topics, besides the Audio Channel Layout API?

Best,

-- 
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] [PATCH] avformat/imfdec: Actually return error upon error

2022-01-02 Thread Andreas Rheinhardt 
Andreas Rheinhardt:
> Signed-off-by: Andreas Rheinhardt 
> ---
>  libavformat/imfdec.c | 3 +--
>  1 file changed, 1 insertion(+), 2 deletions(-)
> 
> diff --git a/libavformat/imfdec.c b/libavformat/imfdec.c
> index f17064cfcd..da8c6cddea 100644
> --- a/libavformat/imfdec.c
> +++ b/libavformat/imfdec.c
> @@ -564,9 +564,8 @@ static int 
> set_context_streams_from_tracks(AVFormatContext *s)
>  /* Copy stream information */
>  asset_stream = avformat_new_stream(s, NULL);
>  if (!asset_stream) {
> -ret = AVERROR(ENOMEM);
>  av_log(s, AV_LOG_ERROR, "Could not create stream\n");
> -break;
> +return AVERROR(ENOMEM);
>  }
>  asset_stream->id = i;
>  ret = avcodec_parameters_copy(asset_stream->codecpar, 
> first_resource_stream->codecpar);
> 
Sorry, I haven't realized that there is already a patch for this.

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

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

Re: [FFmpeg-devel] [PATCH] avfilter/vf_libvmaf: update filter for libvmaf v2.0.0

2022-01-02 Thread Andreas Rheinhardt 
Kyle Swanson:
> Hi,
> 
> On Sat, Dec 25, 2021 at 1:24 AM Paul B Mahol  wrote:
>>
>> On Fri, Dec 24, 2021 at 9:52 PM Kyle Swanson  wrote:
>>
>>> Hi,
>>>
>>> Never followed through on this vf_libvmaf patch from last June, and
>>> I've had several people asking about its status lately. Rebased patch
>>> attached. It's been a while, so I guess let's start the review again.
>>> Would be nice if we could get this in before 5.0.
>>>
>>>
>> Please read old reviews and follow them.
>> There is no exceptions.
> 
> Thank you, I've taken all of Mortiz's comments. Updated patch attached.
> 
> Thanks,
> Kyle
> 

> 
>  static const AVOption libvmaf_options[] = {
> -{"model_path",  "Set the model to be used for computing vmaf.",  
>OFFSET(model_path), AV_OPT_TYPE_STRING, 
> {.str="/usr/local/share/model/vmaf_v0.6.1.pkl"}, 0, 1, FLAGS},
> -{"log_path",  "Set the file path to be used to store logs.", 
>OFFSET(log_path), AV_OPT_TYPE_STRING, {.str=NULL}, 0, 1, FLAGS},
> -{"log_fmt",  "Set the format of the log (csv, json or xml).",
>OFFSET(log_fmt), AV_OPT_TYPE_STRING, {.str=NULL}, 0, 1, FLAGS},
> -{"enable_transform",  "Enables transform for computing vmaf.",   
>OFFSET(enable_transform), AV_OPT_TYPE_BOOL, {.i64=0}, 0, 1, FLAGS},
> -{"phone_model",  "Invokes the phone model that will generate higher VMAF 
> scores.",  OFFSET(phone_model), AV_OPT_TYPE_BOOL, {.i64=0}, 0, 1, FLAGS},
> -{"psnr",  "Enables computing psnr along with vmaf.", 
>OFFSET(psnr), AV_OPT_TYPE_BOOL, {.i64=0}, 0, 1, FLAGS},
> -{"ssim",  "Enables computing ssim along with vmaf.", 
>OFFSET(ssim), AV_OPT_TYPE_BOOL, {.i64=0}, 0, 1, FLAGS},
> -{"ms_ssim",  "Enables computing ms-ssim along with vmaf.",   
>OFFSET(ms_ssim), AV_OPT_TYPE_BOOL, {.i64=0}, 0, 1, FLAGS},
> -{"pool",  "Set the pool method to be used for computing vmaf.",  
>OFFSET(pool), AV_OPT_TYPE_STRING, {.str=NULL}, 0, 1, FLAGS},
> +{"model", "Set the model to be used for computing vmaf.",
>OFFSET(model_cfg), AV_OPT_TYPE_STRING, 
> {.str="version=vmaf_v0.6.1"}, 0, 1, FLAGS},
> +{"feature", "Set the feature to be used for computing vmaf.",
>OFFSET(feature_cfg), AV_OPT_TYPE_STRING, {.str=NULL}, 0, 1, FLAGS},
> +{"log_path",  "Set the file path to be used to write log.",  
>OFFSET(log_path), AV_OPT_TYPE_STRING, {.str=NULL}, 0, 1, FLAGS},
> +{"log_fmt",  "Set the format of the log (csv, json, xml, or sub).",  
>OFFSET(log_fmt), AV_OPT_TYPE_STRING, {.str="xml"}, 0, 1, FLAGS},
>  {"n_threads", "Set number of threads to be used when computing vmaf.",   
>OFFSET(n_threads), AV_OPT_TYPE_INT, {.i64=0}, 0, UINT_MAX, FLAGS},
>  {"n_subsample", "Set interval for frame subsampling used when computing 
> vmaf.", OFFSET(n_subsample), AV_OPT_TYPE_INT, {.i64=1}, 1, UINT_MAX, 
> FLAGS},
> -{"enable_conf_interval",  "Enables confidence interval.",
>OFFSET(enable_conf_interval), AV_OPT_TYPE_BOOL, {.i64=0}, 0, 1, 
> FLAGS},
>  { NULL }
>  };

You are removing lots of options; removing options is only permissible
during a major break and even then the options need to have been
deprecated before that.

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

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

[FFmpeg-devel] [PATCH] avformat/imfdec: Actually return error upon error

2022-01-02 Thread Andreas Rheinhardt 
Signed-off-by: Andreas Rheinhardt 
---
 libavformat/imfdec.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/libavformat/imfdec.c b/libavformat/imfdec.c
index f17064cfcd..da8c6cddea 100644
--- a/libavformat/imfdec.c
+++ b/libavformat/imfdec.c
@@ -564,9 +564,8 @@ static int set_context_streams_from_tracks(AVFormatContext 
*s)
 /* Copy stream information */
 asset_stream = avformat_new_stream(s, NULL);
 if (!asset_stream) {
-ret = AVERROR(ENOMEM);
 av_log(s, AV_LOG_ERROR, "Could not create stream\n");
-break;
+return AVERROR(ENOMEM);
 }
 asset_stream->id = i;
 ret = avcodec_parameters_copy(asset_stream->codecpar, 
first_resource_stream->codecpar);
-- 
2.32.0

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

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

Re: [FFmpeg-devel] [RFC/PATCH 1/2] lavf: add a flag for experimental (de)muxers

2022-01-02 Thread Andreas Rheinhardt 
Lynne:
> 2 Jan 2022, 18:46 by an...@khirnov.net:
> 
>> ---
>>  doc/APIchanges | 3 +++
>>  libavformat/avformat.h | 7 +++
>>  libavformat/format.c   | 2 ++
>>  libavformat/version.h  | 2 +-
>>  4 files changed, 13 insertions(+), 1 deletion(-)
>>
>> diff --git a/doc/APIchanges b/doc/APIchanges
>> index 670a59329e..29c235630e 100644
>> --- a/doc/APIchanges
>> +++ b/doc/APIchanges
>> @@ -14,6 +14,9 @@ libavutil: 2021-04-27
>>  
>>  API changes, most recent first:
>>  
>> +2022-01-xx - xx - lavf 59.13.100 - avformat.h
>> +  Add AVFMT_EXPERIMENTAL flag.
>> +
>>  2021-12-xx - xx - lavu 57.13.100 - hwcontext_videotoolbox.h
>>  Add av_vt_pixbuf_set_attachments
>>  
>> diff --git a/libavformat/avformat.h b/libavformat/avformat.h
>> index 70b36d7682..6ce367e854 100644
>> --- a/libavformat/avformat.h
>> +++ b/libavformat/avformat.h
>> @@ -463,6 +463,13 @@ typedef struct AVProbeData {
>>  /// Demuxer will use avio_open, no opened file should be provided by the 
>> caller.
>>  #define AVFMT_NOFILE0x0001
>>  #define AVFMT_NEEDNUMBER0x0002 /**< Needs '%d' in filename. */
>> +/**
>> + * The muxer/demuxer is experimental and should be used with caution.
>> + *
>> + * - demuxers: will not be selected automatically by probing, must be 
>> specified
>> + * explicitly.
>> + */
>> +#define AVFMT_EXPERIMENTAL  0x0004
>>  #define AVFMT_SHOW_IDS  0x0008 /**< Show format stream IDs numbers. */
>>  #define AVFMT_GLOBALHEADER  0x0040 /**< Format wants global header. */
>>  #define AVFMT_NOTIMESTAMPS  0x0080 /**< Format does not need / have any 
>> timestamps. */
>> diff --git a/libavformat/format.c b/libavformat/format.c
>> index 387627009e..52b85c16a2 100644
>> --- a/libavformat/format.c
>> +++ b/libavformat/format.c
>> @@ -158,6 +158,8 @@ const AVInputFormat *av_probe_input_format3(const 
>> AVProbeData *pd,
>>  }
>>  
>>  while ((fmt1 = av_demuxer_iterate(&i))) {
>> +if (fmt1->flags & AVFMT_EXPERIMENTAL)
>> +continue;
>>  if (!is_opened == !(fmt1->flags & AVFMT_NOFILE) && strcmp(fmt1->name, 
>> "image2"))
>>  continue;
>>  score = 0;
>> diff --git a/libavformat/version.h b/libavformat/version.h
>> index 917b9ffa5d..29dcce352b 100644
>> --- a/libavformat/version.h
>> +++ b/libavformat/version.h
>> @@ -32,7 +32,7 @@
>>  // Major bumping may affect Ticket5467, 5421, 5451(compatibility with 
>> Chromium)
>>  // Also please add any ticket numbers that you believe might be affected 
>> here
>>  #define LIBAVFORMAT_VERSION_MAJOR  59
>> -#define LIBAVFORMAT_VERSION_MINOR  12
>> +#define LIBAVFORMAT_VERSION_MINOR  13
>>  #define LIBAVFORMAT_VERSION_MICRO 100
>>  
>>  #define LIBAVFORMAT_VERSION_INT AV_VERSION_INT(LIBAVFORMAT_VERSION_MAJOR, \
>>
> 
> You should add it in libavformat/options_table.h too.

This is not a new AVFMT_FLAG_* value, but an AVFMT_* value (akin to a
codec cap).

> Apart from that, it looks fine. Should we move muxers previously
> behind strict_std_compliance > experimental like scd behind
> this flag or would that be an API breakage?

What (de)muxers (scd is a demuxer) would that be besides scd?

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

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

[FFmpeg-devel] [PATCH] lavu/hwcontext_drm: don't fail mapping when dst format is unset

2022-01-02 Thread Cameron Gutman 
av_hwframe_map() is documented to work with a blank dst frame, but
hwcontext_drm currently fails if dst->format == AV_PIX_FMT_NONE.

Signed-off-by: Cameron Gutman 
---
 libavutil/hwcontext_drm.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/libavutil/hwcontext_drm.c b/libavutil/hwcontext_drm.c
index 7a9fdbd263..85a9fd4984 100644
--- a/libavutil/hwcontext_drm.c
+++ b/libavutil/hwcontext_drm.c
@@ -287,7 +287,9 @@ static int drm_map_from(AVHWFramesContext *hwfc, AVFrame 
*dst,
 {
 int err;
 
-if (hwfc->sw_format != dst->format)
+if (dst->format == AV_PIX_FMT_NONE)
+dst->format = hwfc->sw_format;
+else if (hwfc->sw_format != dst->format)
 return AVERROR(ENOSYS);
 
 err = drm_map_frame(hwfc, dst, src, flags);
-- 
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 5/5] avfilter/vf_blend: fix un-checked potential memory allocation failure

2022-01-02 Thread Lynne 
2 Jan 2022, 15:51 by jianhua.wu-at-intel@ffmpeg.org:

> Signed-off-by: Wu Jianhua 
> ---
>  libavfilter/vf_blend.c | 6 +-
>  1 file changed, 5 insertions(+), 1 deletion(-)
>
> diff --git a/libavfilter/vf_blend.c b/libavfilter/vf_blend.c
> index b6f3c4fed3..2d433e439f 100644
> --- a/libavfilter/vf_blend.c
> +++ b/libavfilter/vf_blend.c
> @@ -279,7 +279,11 @@ static AVFrame *blend_frame(AVFilterContext *ctx, 
> AVFrame *top_buf,
>  dst_buf = ff_get_video_buffer(outlink, outlink->w, outlink->h);
>  if (!dst_buf)
>  return top_buf;
> -av_frame_copy_props(dst_buf, top_buf);
> +
> +if (av_frame_copy_props(dst_buf, top_buf) < 0) {
> +av_frame_free(&dst_buf);
> +return top_buf;
> +}
>  
>  for (plane = 0; plane < s->nb_planes; plane++) {
>  int hsub = plane == 1 || plane == 2 ? s->hsub : 0;
>

Pushed patches 2 and 3. The blend filter doesn't work for me:
https://0x0.st/osRM.jpg
This is not what it's meant to look like at all, for blank, default options.

Patch 1 is a driver bug. The driver should not advertise the
HDR extension as supported if there's no swapchain. The HDR
extension explicitly requires a swapchain, and the Vulkan specs
say that devices are meant to only advertise supported extensions,
which the HDR extension wouldn't be if the swapchain extension
has not been loaded.
I pushed an alternative version that just removes the HDR extension,
but you need to notify your Windows driver developers that it's
not doing what it should.
___
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] lavu/videotoolbox: add support for memory mapping frames

2022-01-02 Thread Cameron Gutman 
On 1/2/22 19:21, Aman Karmani wrote:
> 
> 
> On Sun, Jan 2, 2022 at 4:33 PM Cameron Gutman  > wrote:
> 
> Signed-off-by: Cameron Gutman  >
> ---
>  libavutil/hwcontext_videotoolbox.c | 25 +
>  1 file changed, 25 insertions(+)
> 
> diff --git a/libavutil/hwcontext_videotoolbox.c 
> b/libavutil/hwcontext_videotoolbox.c
> index 0a8dbe9f33..026127d412 100644
> --- a/libavutil/hwcontext_videotoolbox.c
> +++ b/libavutil/hwcontext_videotoolbox.c
> @@ -711,6 +711,30 @@ fail:
>      return err;
>  }
> 
> +static int vt_map_from(AVHWFramesContext *hwfc, AVFrame *dst,
> +                       const AVFrame *src, int flags)
> +{
> +    int err;
> +
> +    if (dst->format == AV_PIX_FMT_NONE)
> +        dst->format = hwfc->sw_format;
> +    else if (dst->format != hwfc->sw_format)
> +        return AVERROR(ENOSYS);
> +
> +    err = vt_map_frame(hwfc, dst, src, flags);
> +    if (err)
> +        return err;
> +
> +    dst->width  = src->width;
> +    dst->height = src->height;
> +
> +    err = av_frame_copy_props(dst, src);
> +    if (err)
> +        return err;
> +
> +    return 0;
> +}
> +
>  static int vt_device_create(AVHWDeviceContext *ctx, const char *device,
>                              AVDictionary *opts, int flags)
>  {
> @@ -736,6 +760,7 @@ const HWContextType ff_hwcontext_type_videotoolbox = {
>      .transfer_get_formats = vt_transfer_get_formats,
>      .transfer_data_to     = vt_transfer_data_to,
>      .transfer_data_from   = vt_transfer_data_from,
> +    .map_from             = vt_map_from,
> 
> 
> Thanks for this!
> 
> Does this add support for hwdownload filter? Or what's the best way to test 
> this patch?
> 
> Aman
> 
> 

I'm calling the C API directly (av_hwframe_map) from my application, but you 
can test it
with the command-line tool using something like this:

ffmpeg -hwaccel videotoolbox -hwaccel_output_format videotoolbox_vld -i 
1280x720.h264 -vf "hwmap,format=nv12" 1280x720.yuv

Replacing hwmap (which uses map_from) with hwdownload (which uses 
transfer_data_from)
yields the same decoded YUV output, as expected.



Cam

> 
>      .pix_fmts = (const enum AVPixelFormat[]){ AV_PIX_FMT_VIDEOTOOLBOX, 
> AV_PIX_FMT_NONE },
>  };
> -- 
> 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 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] lavu/videotoolbox: add support for memory mapping frames

2022-01-02 Thread Aman Karmani 
On Sun, Jan 2, 2022 at 4:33 PM Cameron Gutman  wrote:

> Signed-off-by: Cameron Gutman 
> ---
>  libavutil/hwcontext_videotoolbox.c | 25 +
>  1 file changed, 25 insertions(+)
>
> diff --git a/libavutil/hwcontext_videotoolbox.c
> b/libavutil/hwcontext_videotoolbox.c
> index 0a8dbe9f33..026127d412 100644
> --- a/libavutil/hwcontext_videotoolbox.c
> +++ b/libavutil/hwcontext_videotoolbox.c
> @@ -711,6 +711,30 @@ fail:
>  return err;
>  }
>
> +static int vt_map_from(AVHWFramesContext *hwfc, AVFrame *dst,
> +   const AVFrame *src, int flags)
> +{
> +int err;
> +
> +if (dst->format == AV_PIX_FMT_NONE)
> +dst->format = hwfc->sw_format;
> +else if (dst->format != hwfc->sw_format)
> +return AVERROR(ENOSYS);
> +
> +err = vt_map_frame(hwfc, dst, src, flags);
> +if (err)
> +return err;
> +
> +dst->width  = src->width;
> +dst->height = src->height;
> +
> +err = av_frame_copy_props(dst, src);
> +if (err)
> +return err;
> +
> +return 0;
> +}
> +
>  static int vt_device_create(AVHWDeviceContext *ctx, const char *device,
>  AVDictionary *opts, int flags)
>  {
> @@ -736,6 +760,7 @@ const HWContextType ff_hwcontext_type_videotoolbox = {
>  .transfer_get_formats = vt_transfer_get_formats,
>  .transfer_data_to = vt_transfer_data_to,
>  .transfer_data_from   = vt_transfer_data_from,
> +.map_from = vt_map_from,


Thanks for this!

Does this add support for hwdownload filter? Or what's the best way to test
this patch?

Aman


>
>  .pix_fmts = (const enum AVPixelFormat[]){ AV_PIX_FMT_VIDEOTOOLBOX,
> AV_PIX_FMT_NONE },
>  };
> --
> 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 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] lavu/videotoolbox: add support for memory mapping frames

2022-01-02 Thread Cameron Gutman 
Signed-off-by: Cameron Gutman 
---
 libavutil/hwcontext_videotoolbox.c | 25 +
 1 file changed, 25 insertions(+)

diff --git a/libavutil/hwcontext_videotoolbox.c 
b/libavutil/hwcontext_videotoolbox.c
index 0a8dbe9f33..026127d412 100644
--- a/libavutil/hwcontext_videotoolbox.c
+++ b/libavutil/hwcontext_videotoolbox.c
@@ -711,6 +711,30 @@ fail:
 return err;
 }
 
+static int vt_map_from(AVHWFramesContext *hwfc, AVFrame *dst,
+   const AVFrame *src, int flags)
+{
+int err;
+
+if (dst->format == AV_PIX_FMT_NONE)
+dst->format = hwfc->sw_format;
+else if (dst->format != hwfc->sw_format)
+return AVERROR(ENOSYS);
+
+err = vt_map_frame(hwfc, dst, src, flags);
+if (err)
+return err;
+
+dst->width  = src->width;
+dst->height = src->height;
+
+err = av_frame_copy_props(dst, src);
+if (err)
+return err;
+
+return 0;
+}
+
 static int vt_device_create(AVHWDeviceContext *ctx, const char *device,
 AVDictionary *opts, int flags)
 {
@@ -736,6 +760,7 @@ const HWContextType ff_hwcontext_type_videotoolbox = {
 .transfer_get_formats = vt_transfer_get_formats,
 .transfer_data_to = vt_transfer_data_to,
 .transfer_data_from   = vt_transfer_data_from,
+.map_from = vt_map_from,
 
 .pix_fmts = (const enum AVPixelFormat[]){ AV_PIX_FMT_VIDEOTOOLBOX, 
AV_PIX_FMT_NONE },
 };
-- 
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 v10 6/6] lavc/hevcdec: Parse DOVI RPU NALs

2022-01-02 Thread Niklas Haas 
From: Niklas Haas 

And expose the parsed values as frame side data. Update FATE results to
match.

It's worth documenting that this relies on the dovi configuration record
being present on the first AVPacket fed to the decoder, which in
practice is the case if if the API user has called something like
av_format_inject_global_side_data, which is unfortunately not the
default.

This commit is not the time and place to change that behavior, though.

Signed-off-by: Niklas Haas 
---
 configure  |   2 +-
 libavcodec/hevcdec.c   |  37 --
 libavcodec/hevcdec.h   |   2 +
 tests/ref/fate/hevc-dv-rpu | 224 +
 4 files changed, 256 insertions(+), 9 deletions(-)

diff --git a/configure b/configure
index 8303e1329e..3f71af77db 100755
--- a/configure
+++ b/configure
@@ -2826,7 +2826,7 @@ h264_decoder_suggest="error_resilience"
 hap_decoder_select="snappy texturedsp"
 hap_encoder_deps="libsnappy"
 hap_encoder_select="texturedspenc"
-hevc_decoder_select="atsc_a53 bswapdsp cabac golomb hevcparse videodsp"
+hevc_decoder_select="atsc_a53 bswapdsp cabac dovi_rpu golomb hevcparse 
videodsp"
 huffyuv_decoder_select="bswapdsp huffyuvdsp llviddsp"
 huffyuv_encoder_select="bswapdsp huffman huffyuvencdsp llvidencdsp"
 hymt_decoder_select="huffyuv_decoder"
diff --git a/libavcodec/hevcdec.c b/libavcodec/hevcdec.c
index 3aa70e2245..8d7a4f7147 100644
--- a/libavcodec/hevcdec.c
+++ b/libavcodec/hevcdec.c
@@ -2723,6 +2723,7 @@ error:
 static int set_side_data(HEVCContext *s)
 {
 AVFrame *out = s->ref->frame;
+int ret;
 
 if (s->sei.frame_packing.present &&
 s->sei.frame_packing.arrangement_type >= 3 &&
@@ -2977,6 +2978,9 @@ static int set_side_data(HEVCContext *s)
 s->rpu_buf = NULL;
 }
 
+if ((ret = ff_dovi_attach_side_data(&s->dovi_ctx, out)) < 0)
+return ret;
+
 return 0;
 }
 
@@ -3308,16 +3312,23 @@ static int decode_nal_units(HEVCContext *s, const 
uint8_t *buf, int length)
 if (s->pkt.nb_nals > 1 && s->pkt.nals[s->pkt.nb_nals - 1].type == 
HEVC_NAL_UNSPEC62 &&
 s->pkt.nals[s->pkt.nb_nals - 1].size > 2 && 
!s->pkt.nals[s->pkt.nb_nals - 1].nuh_layer_id
 && !s->pkt.nals[s->pkt.nb_nals - 1].temporal_id) {
+H2645NAL *nal = &s->pkt.nals[s->pkt.nb_nals - 1];
 if (s->rpu_buf) {
 av_buffer_unref(&s->rpu_buf);
 av_log(s->avctx, AV_LOG_WARNING, "Multiple Dolby Vision RPUs found 
in one AU. Skipping previous.\n");
 }
 
-s->rpu_buf = av_buffer_alloc(s->pkt.nals[s->pkt.nb_nals - 1].raw_size 
- 2);
+s->rpu_buf = av_buffer_alloc(nal->raw_size - 2);
 if (!s->rpu_buf)
 return AVERROR(ENOMEM);
+memcpy(s->rpu_buf->data, nal->raw_data + 2, nal->raw_size - 2);
 
-memcpy(s->rpu_buf->data, s->pkt.nals[s->pkt.nb_nals - 1].raw_data + 2, 
s->pkt.nals[s->pkt.nb_nals - 1].raw_size - 2);
+ret = ff_dovi_rpu_parse(&s->dovi_ctx, nal->data + 2, nal->size - 2);
+if (ret < 0) {
+av_buffer_unref(&s->rpu_buf);
+av_log(s->avctx, AV_LOG_WARNING, "Error parsing DOVI NAL unit.\n");
+/* ignore */
+}
 }
 
 /* decode the NAL units */
@@ -3450,8 +3461,8 @@ static int hevc_decode_frame(AVCodecContext *avctx, void 
*data, int *got_output,
  AVPacket *avpkt)
 {
 int ret;
-size_t new_extradata_size;
-uint8_t *new_extradata;
+uint8_t *sd;
+size_t sd_size;
 HEVCContext *s = avctx->priv_data;
 
 if (!avpkt->size) {
@@ -3463,14 +3474,17 @@ static int hevc_decode_frame(AVCodecContext *avctx, 
void *data, int *got_output,
 return 0;
 }
 
-new_extradata = av_packet_get_side_data(avpkt, AV_PKT_DATA_NEW_EXTRADATA,
-&new_extradata_size);
-if (new_extradata && new_extradata_size > 0) {
-ret = hevc_decode_extradata(s, new_extradata, new_extradata_size, 0);
+sd = av_packet_get_side_data(avpkt, AV_PKT_DATA_NEW_EXTRADATA, &sd_size);
+if (sd && sd_size > 0) {
+ret = hevc_decode_extradata(s, sd, sd_size, 0);
 if (ret < 0)
 return ret;
 }
 
+sd = av_packet_get_side_data(avpkt, AV_PKT_DATA_DOVI_CONF, &sd_size);
+if (sd && sd_size > 0)
+ff_dovi_update_cfg(&s->dovi_ctx, (AVDOVIDecoderConfigurationRecord *) 
sd);
+
 s->ref = NULL;
 ret= decode_nal_units(s, avpkt->data, avpkt->size);
 if (ret < 0)
@@ -3563,6 +3577,7 @@ static av_cold int hevc_decode_free(AVCodecContext *avctx)
 
 pic_arrays_free(s);
 
+ff_dovi_ctx_unref(&s->dovi_ctx);
 av_buffer_unref(&s->rpu_buf);
 
 av_freep(&s->md5_ctx);
@@ -3647,6 +3662,7 @@ static av_cold int hevc_init_context(AVCodecContext 
*avctx)
 
 ff_bswapdsp_init(&s->bdsp);
 
+s->dovi_ctx.logctx = avctx;
 s->context_initialized = 1;
 s->eos = 0;
 
@@ -3755,6 +3771,10 @@ static int hevc_update_thread_context(AVCodecContext 
*dst,
 if (ret < 0)

[FFmpeg-devel] [PATCH v10 1/6] lavu/frame: Add Dolby Vision metadata side data type

2022-01-02 Thread Niklas Haas 
From: Niklas Haas 

In order to be able to extend this struct later (as the Dolby Vision RPU
evolves), all of the structs are considered extensible, and the
individual constituent fields must instead be accessed via offsets. The
precedent for this style of access is set in


Signed-off-by: Niklas Haas 
---
 doc/APIchanges|   3 +
 libavutil/dovi_meta.c |  25 +++
 libavutil/dovi_meta.h | 170 ++
 libavutil/frame.c |   1 +
 libavutil/frame.h |   9 ++-
 libavutil/version.h   |   2 +-
 6 files changed, 208 insertions(+), 2 deletions(-)

diff --git a/doc/APIchanges b/doc/APIchanges
index 670a59329e..5721486f09 100644
--- a/doc/APIchanges
+++ b/doc/APIchanges
@@ -14,6 +14,9 @@ libavutil: 2021-04-27
 
 API changes, most recent first:
 
+2021-12-xx - xx - lavu 57.14.100 - frame.h
+  Add AV_FRAME_DATA_DOVI_METADATA.
+
 2021-12-xx - xx - lavu 57.13.100 - hwcontext_videotoolbox.h
   Add av_vt_pixbuf_set_attachments
 
diff --git a/libavutil/dovi_meta.c b/libavutil/dovi_meta.c
index 7bd08f6c54..9c50da561e 100644
--- a/libavutil/dovi_meta.c
+++ b/libavutil/dovi_meta.c
@@ -33,3 +33,28 @@ AVDOVIDecoderConfigurationRecord *av_dovi_alloc(size_t *size)
 
 return dovi;
 }
+
+typedef struct AVDOVIMetadataInternal {
+AVDOVIMetadata metadata;
+AVDOVIRpuDataHeader header;
+AVDOVIDataMapping mapping;
+AVDOVIColorMetadata color;
+} AVDOVIMetadataInternal;
+
+AVDOVIMetadata *av_dovi_metadata_alloc(size_t *size)
+{
+AVDOVIMetadataInternal *dovi = av_mallocz(sizeof(AVDOVIMetadataInternal));
+if (!dovi)
+return NULL;
+
+if (size)
+*size = sizeof(*dovi);
+
+dovi->metadata = (struct AVDOVIMetadata) {
+.header_offset  = offsetof(AVDOVIMetadataInternal, header),
+.mapping_offset = offsetof(AVDOVIMetadataInternal, mapping),
+.color_offset   = offsetof(AVDOVIMetadataInternal, color),
+};
+
+return &dovi->metadata;
+}
diff --git a/libavutil/dovi_meta.h b/libavutil/dovi_meta.h
index 299911d434..f4f40a4736 100644
--- a/libavutil/dovi_meta.h
+++ b/libavutil/dovi_meta.h
@@ -29,6 +29,7 @@
 
 #include 
 #include 
+#include "rational.h"
 
 /*
  * DOVI configuration
@@ -67,4 +68,173 @@ typedef struct AVDOVIDecoderConfigurationRecord {
  */
 AVDOVIDecoderConfigurationRecord *av_dovi_alloc(size_t *size);
 
+/**
+ * Dolby Vision RPU data header.
+ *
+ * @note sizeof(AVDOVIRpuDataHeader) is not part of the public ABI.
+ */
+typedef struct AVDOVIRpuDataHeader {
+uint8_t rpu_type;
+uint16_t rpu_format;
+uint8_t vdr_rpu_profile;
+uint8_t vdr_rpu_level;
+uint8_t chroma_resampling_explicit_filter_flag;
+uint8_t coef_data_type; /* informative, lavc always converts to fixed */
+uint8_t coef_log2_denom;
+uint8_t vdr_rpu_normalized_idc;
+uint8_t bl_video_full_range_flag;
+uint8_t bl_bit_depth; /* [8, 16] */
+uint8_t el_bit_depth; /* [8, 16] */
+uint8_t vdr_bit_depth; /* [8, 16] */
+uint8_t spatial_resampling_filter_flag;
+uint8_t el_spatial_resampling_filter_flag;
+uint8_t disable_residual_flag;
+} AVDOVIRpuDataHeader;
+
+enum AVDOVIMappingMethod {
+AV_DOVI_MAPPING_POLYNOMIAL = 0,
+AV_DOVI_MAPPING_MMR = 1,
+};
+
+/**
+ * Coefficients of a piece-wise function. The pieces of the function span the
+ * value ranges between two adjacent pivot values.
+ *
+ * @note sizeof(AVDOVIReshapingCurve) is not part of the public ABI.
+ */
+#define AV_DOVI_MAX_PIECES 8
+typedef struct AVDOVIReshapingCurve {
+uint8_t num_pivots; /* [2, 9] */
+uint16_t pivots[AV_DOVI_MAX_PIECES + 1];/* sorted ascending */
+enum AVDOVIMappingMethod mapping_idc[AV_DOVI_MAX_PIECES];
+/* AV_DOVI_MAPPING_POLYNOMIAL */
+uint8_t poly_order[AV_DOVI_MAX_PIECES]; /* [1, 2] */
+int64_t poly_coef[AV_DOVI_MAX_PIECES][3];   /* x^0, x^1, x^2 */
+/* AV_DOVI_MAPPING_MMR */
+uint8_t mmr_order[AV_DOVI_MAX_PIECES];  /* [1, 3] */
+int64_t mmr_constant[AV_DOVI_MAX_PIECES];
+int64_t mmr_coef[AV_DOVI_MAX_PIECES][3/* order - 1 */][7];
+} AVDOVIReshapingCurve;
+
+enum AVDOVINLQMethod {
+AV_DOVI_NLQ_NONE = -1,
+AV_DOVI_NLQ_LINEAR_DZ = 0,
+};
+
+/**
+ * Coefficients of the non-linear inverse quantization. For the interpretation
+ * of these, see ETSI GS CCM 001.
+ *
+ * @note sizeof(AVDOVINLQParams) is not part of the public ABI.
+ */
+typedef struct AVDOVINLQParams {
+uint64_t nlq_offset;
+uint64_t vdr_in_max;
+/* AV_DOVI_NLQ_LINEAR_DZ */
+uint64_t linear_deadzone_slope;
+uint64_t linear_deadzone_threshold;
+} AVDOVINLQParams;
+
+/**
+ * Dolby Vision RPU data mapping parameters.
+ *
+ * @note sizeof(AVDOVIDataMapping) is not part of the public ABI.
+ */
+typedef struct AVDOVIDataMapping {
+uint8_t vdr_rpu_id;
+uint8_t mapping_color_space;
+uint8_t mapping_chroma_format_idc;
+AVDOVIReshapingCurve curves[3]; /* per component */
+
+/* Non-linear inverse quantization */
+enum A

[FFmpeg-devel] [PATCH v10 4/6] lavc: Implement Dolby Vision RPU parsing

2022-01-02 Thread Niklas Haas 
From: Niklas Haas 

Based on a mixture of guesswork, partial documentation in patents, and
reverse engineering of real-world samples. Confirmed working for all the
samples I've thrown at it.

Contains some annoying machinery to persist these values in between
frames, which is needed in theory even though I've never actually seen a
sample that relies on it in practice. May or may not work.

Since the distinction matters greatly for parsing the color matrix
values, this includes a small helper function to guess the right profile
from the RPU itself in case the user has forgotten to forward the dovi
configuration record to the decoder. (Which in practice, only ffmpeg.c
and ffplay do..)

Notable omissions / deviations:
- CRC32 verification. This is based on the MPEG2 CRC32 type, which is
  similar to IEEE CRC32 but apparently different in subtle enough ways
  that I could not get it to pass verification no matter what parameters
  I fed to av_crc. It's possible the code needs some changes.
- Linear interpolation support. Nothing documents this (beyond its
  existence) and no samples use it, so impossible to implement.
- All of the extension metadata blocks, but these contain values that
  seem largely congruent with ST2094, HDR10, or other existing forms of
  side data, so I will defer parsing/attaching them to a future commit.
- The patent describes a mechanism for predicting coefficients from
  previous RPUs, but the bit for the flag whether to use the
  prediction deltas or signal entirely new coefficients does not seem to
  be present in actual RPUs, so we ignore this subsystem entirely.
- In the patent's spec, the NLQ subsystem also loops over
  num_nlq_pivots, but even in the patent the number is hard-coded to one
  iteration rather than signalled. So we only store one set of coefs.

Heavily influenced by https://github.com/quietvoid/dovi_tool
Documentation drawn from US Patent 10,701,399 B2 and ETSI GS CCM 001

Signed-off-by: Niklas Haas 
---
 configure |   2 +
 libavcodec/Makefile   |   1 +
 libavcodec/dovi_rpu.c | 449 ++
 libavcodec/dovi_rpu.h |  87 
 4 files changed, 539 insertions(+)
 create mode 100644 libavcodec/dovi_rpu.c
 create mode 100644 libavcodec/dovi_rpu.h

diff --git a/configure b/configure
index 6ad70b9f7b..8303e1329e 100755
--- a/configure
+++ b/configure
@@ -2434,6 +2434,7 @@ CONFIG_EXTRA="
 cbs_vp9
 dirac_parse
 dnn
+dovi_rpu
 dvprofile
 exif
 faandct
@@ -2706,6 +2707,7 @@ cbs_mpeg2_select="cbs"
 cbs_vp9_select="cbs"
 dct_select="rdft"
 dirac_parse_select="golomb"
+dovi_rpu_select="golomb"
 dnn_suggest="libtensorflow libopenvino"
 dnn_deps="avformat swscale"
 error_resilience_select="me_cmp"
diff --git a/libavcodec/Makefile b/libavcodec/Makefile
index 9577062eec..ceecdf05e1 100644
--- a/libavcodec/Makefile
+++ b/libavcodec/Makefile
@@ -77,6 +77,7 @@ OBJS-$(CONFIG_CBS_MPEG2)   += cbs_mpeg2.o
 OBJS-$(CONFIG_CBS_VP9) += cbs_vp9.o
 OBJS-$(CONFIG_CRYSTALHD)   += crystalhd.o
 OBJS-$(CONFIG_DCT) += dct.o dct32_fixed.o dct32_float.o
+OBJS-$(CONFIG_DOVI_RPU)+= dovi_rpu.o
 OBJS-$(CONFIG_ERROR_RESILIENCE)+= error_resilience.o
 OBJS-$(CONFIG_EXIF)+= exif.o tiff_common.o
 OBJS-$(CONFIG_FAANDCT) += faandct.o
diff --git a/libavcodec/dovi_rpu.c b/libavcodec/dovi_rpu.c
new file mode 100644
index 00..a87562c8a3
--- /dev/null
+++ b/libavcodec/dovi_rpu.c
@@ -0,0 +1,449 @@
+/*
+ * Dolby Vision RPU decoder
+ *
+ * Copyright (C) 2021 Jan Ekström
+ * Copyright (C) 2021 Niklas Haas
+ *
+ * This file is part of FFmpeg.
+ *
+ * FFmpeg is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public
+ * License as published by the Free Software Foundation; either
+ * version 2.1 of the License, or (at your option) any later version.
+ *
+ * FFmpeg is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+ * Lesser General Public License for more details.
+ *
+ * You should have received a copy of the GNU Lesser General Public
+ * License along with FFmpeg; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA
+ */
+
+#include "libavutil/buffer.h"
+
+#include "dovi_rpu.h"
+#include "golomb.h"
+#include "get_bits.h"
+
+enum {
+RPU_COEFF_FIXED = 0,
+RPU_COEFF_FLOAT = 1,
+};
+
+/**
+ * Private contents of vdr_ref.
+ */
+typedef struct DOVIVdrRef {
+AVDOVIDataMapping mapping;
+AVDOVIColorMetadata color;
+} DOVIVdrRef;
+
+void ff_dovi_ctx_unref(DOVIContext *s)
+{
+for (int i = 0; i < FF_ARRAY_ELEMS(s->vdr_ref); i++)
+av_buffer_unref(&s->vdr_ref[i]);
+
+*s = (DOVIContext) {
+.logctx = s->logctx,
+};
+}
+
+void ff_dovi_ctx_flush(

[FFmpeg-devel] [PATCH v10 2/6] lavfi/showinfo: Support AV_FRAME_DATA_DOVI_METADATA

2022-01-02 Thread Niklas Haas 
From: Niklas Haas 

Signed-off-by: Niklas Haas 
---
 libavfilter/vf_showinfo.c | 108 ++
 1 file changed, 108 insertions(+)

diff --git a/libavfilter/vf_showinfo.c b/libavfilter/vf_showinfo.c
index 62c7833247..909ad4f8d7 100644
--- a/libavfilter/vf_showinfo.c
+++ b/libavfilter/vf_showinfo.c
@@ -27,6 +27,7 @@
 #include "libavutil/bswap.h"
 #include "libavutil/adler32.h"
 #include "libavutil/display.h"
+#include "libavutil/dovi_meta.h"
 #include "libavutil/imgutils.h"
 #include "libavutil/internal.h"
 #include "libavutil/film_grain_params.h"
@@ -429,6 +430,110 @@ static void 
dump_sei_film_grain_params_metadata(AVFilterContext *ctx, const AVFr
 }
 }
 
+static void dump_dovi_metadata(AVFilterContext *ctx, const AVFrameSideData *sd)
+{
+const AVDOVIMetadata *dovi = (AVDOVIMetadata *) sd->data;
+const AVDOVIRpuDataHeader *hdr = av_dovi_get_header(dovi);
+const AVDOVIDataMapping *mapping = av_dovi_get_mapping(dovi);
+const AVDOVIColorMetadata *color = av_dovi_get_color(dovi);
+
+av_log(ctx, AV_LOG_INFO, "Dolby Vision Metadata:\n");
+av_log(ctx, AV_LOG_INFO, "rpu_type=%"PRIu8"; ", hdr->rpu_type);
+av_log(ctx, AV_LOG_INFO, "rpu_format=%"PRIu16"; ", hdr->rpu_format);
+av_log(ctx, AV_LOG_INFO, "vdr_rpu_profile=%"PRIu8"; ", 
hdr->vdr_rpu_profile);
+av_log(ctx, AV_LOG_INFO, "vdr_rpu_level=%"PRIu8"; ", hdr->vdr_rpu_level);
+av_log(ctx, AV_LOG_INFO, "chroma_resampling_explicit_filter_flag=%"PRIu8"; 
", hdr->chroma_resampling_explicit_filter_flag);
+av_log(ctx, AV_LOG_INFO, "coef_data_type=%"PRIu8"; ", hdr->coef_data_type);
+av_log(ctx, AV_LOG_INFO, "coef_log2_denom=%"PRIu8"; ", 
hdr->coef_log2_denom);
+av_log(ctx, AV_LOG_INFO, "vdr_rpu_normalized_idc=%"PRIu8"; ", 
hdr->vdr_rpu_normalized_idc);
+av_log(ctx, AV_LOG_INFO, "bl_video_full_range_flag=%"PRIu8"; ", 
hdr->bl_video_full_range_flag);
+av_log(ctx, AV_LOG_INFO, "bl_bit_depth=%"PRIu8"; ", hdr->bl_bit_depth);
+av_log(ctx, AV_LOG_INFO, "el_bit_depth=%"PRIu8"; ", hdr->el_bit_depth);
+av_log(ctx, AV_LOG_INFO, "vdr_bit_depth=%"PRIu8"; ", hdr->vdr_bit_depth);
+av_log(ctx, AV_LOG_INFO, "spatial_resampling_filter_flag=%"PRIu8"; ", 
hdr->spatial_resampling_filter_flag);
+av_log(ctx, AV_LOG_INFO, "el_spatial_resampling_filter_flag=%"PRIu8"; ", 
hdr->el_spatial_resampling_filter_flag);
+av_log(ctx, AV_LOG_INFO, "disable_residual_flag=%"PRIu8"\n", 
hdr->disable_residual_flag);
+
+av_log(ctx, AV_LOG_INFO, "data mapping: ");
+av_log(ctx, AV_LOG_INFO, "vdr_rpu_id=%"PRIu8"; ", mapping->vdr_rpu_id);
+av_log(ctx, AV_LOG_INFO, "mapping_color_space=%"PRIu8"; ", 
mapping->mapping_color_space);
+av_log(ctx, AV_LOG_INFO, "mapping_chroma_format_idc=%"PRIu8"; ", 
mapping->mapping_chroma_format_idc);
+av_log(ctx, AV_LOG_INFO, "nlq_method_idc=%d; ", (int) 
mapping->nlq_method_idc);
+av_log(ctx, AV_LOG_INFO, "num_x_partitions=%"PRIu32"; ", 
mapping->num_x_partitions);
+av_log(ctx, AV_LOG_INFO, "num_y_partitions=%"PRIu32"\n", 
mapping->num_y_partitions);
+
+for (int c = 0; c < 3; c++) {
+const AVDOVIReshapingCurve *curve = &mapping->curves[c];
+const AVDOVINLQParams *nlq = &mapping->nlq[c];
+av_log(ctx, AV_LOG_INFO, "  channel %d: ", c);
+av_log(ctx, AV_LOG_INFO, "pivots={ ");
+for (int i = 0; i < curve->num_pivots; i++)
+av_log(ctx, AV_LOG_INFO, "%"PRIu16" ", curve->pivots[i]);
+av_log(ctx, AV_LOG_INFO, "}; mapping_idc={ ");
+for (int i = 0; i < curve->num_pivots - 1; i++)
+av_log(ctx, AV_LOG_INFO, "%d ", (int) curve->mapping_idc[i]);
+av_log(ctx, AV_LOG_INFO, "}; poly_order={ ");
+for (int i = 0; i < curve->num_pivots - 1; i++)
+av_log(ctx, AV_LOG_INFO, "%"PRIu8" ", curve->poly_order[i]);
+av_log(ctx, AV_LOG_INFO, "}; poly_coef={ ");
+for (int i = 0; i < curve->num_pivots - 1; i++) {
+av_log(ctx, AV_LOG_INFO, "{%"PRIi64", %"PRIi64", %"PRIi64"} ",
+   curve->poly_coef[i][0],
+   curve->poly_coef[i][1],
+   curve->poly_coef[i][2]);
+}
+
+av_log(ctx, AV_LOG_INFO, "}; mmr_order={ ");
+for (int i = 0; i < curve->num_pivots - 1; i++)
+av_log(ctx, AV_LOG_INFO, "%"PRIu8" ", curve->mmr_order[i]);
+av_log(ctx, AV_LOG_INFO, "}; mmr_constant={ ");
+for (int i = 0; i < curve->num_pivots - 1; i++)
+av_log(ctx, AV_LOG_INFO, "%"PRIi64" ", curve->mmr_constant[i]);
+av_log(ctx, AV_LOG_INFO, "}; mmr_coef={ ");
+for (int i = 0; i < curve->num_pivots - 1; i++) {
+av_log(ctx, AV_LOG_INFO, "{");
+for (int j = 0; j < curve->mmr_order[i]; j++) {
+for (int k = 0; k < 7; k++)
+av_log(ctx, AV_LOG_INFO, "%"PRIi64" ", 
curve->mmr_coef[i][j][k]);
+}
+av_log(ctx, AV_LOG_INFO, "} ");
+}
+
+av_log(ctx, AV_LOG_

[FFmpeg-devel] [PATCH v10 5/6] fate: Limit Dolby Vision RPU test frame count

2022-01-02 Thread Niklas Haas 
From: Niklas Haas 

To avoid the ref for this growing to a very large size when attaching
the parsed RPU side data. Since this sample does not have any dynamic
metadata, two frames will serve just as well as 100.

Signed-off-by: Niklas Haas 
---
 tests/fate/hevc.mak|   2 +-
 tests/ref/fate/hevc-dv-rpu | 499 -
 2 files changed, 1 insertion(+), 500 deletions(-)

diff --git a/tests/fate/hevc.mak b/tests/fate/hevc.mak
index 6528df6e27..f294cff414 100644
--- a/tests/fate/hevc.mak
+++ b/tests/fate/hevc.mak
@@ -273,7 +273,7 @@ FATE_HEVC_FFPROBE-$(call DEMDEC, HEVC, HEVC) += 
fate-hevc-monochrome-crop
 fate-hevc-hdr10-plus-metadata: CMD = probeframes -show_entries 
frame=side_data_list $(TARGET_SAMPLES)/hevc/hdr10_plus_h265_sample.hevc
 FATE_HEVC_FFPROBE-$(call DEMDEC, HEVC, HEVC) += fate-hevc-hdr10-plus-metadata
 
-fate-hevc-dv-rpu: CMD = probeframes -show_entries frame=side_data_list 
-select_streams 0 $(TARGET_SAMPLES)/hevc/dv84.mov
+fate-hevc-dv-rpu: CMD = probeframes -show_entries frame=side_data_list 
-select_streams 0 -read_intervals "%+\#2" $(TARGET_SAMPLES)/hevc/dv84.mov
 FATE_HEVC_FFPROBE-$(call DEMDEC, HEVC, HEVC) += fate-hevc-dv-rpu
 
 fate-hevc-two-first-slice: CMD = threads=2 framemd5 -i 
$(TARGET_SAMPLES)/hevc/two_first_slice.mp4 -sws_flags bitexact -t 00:02.00 -an
diff --git a/tests/ref/fate/hevc-dv-rpu b/tests/ref/fate/hevc-dv-rpu
index 37ad9ffec2..416d9c51a6 100644
--- a/tests/ref/fate/hevc-dv-rpu
+++ b/tests/ref/fate/hevc-dv-rpu
@@ -11,502 +11,3 @@ side_data_type=Dolby Vision RPU Data
 side_data_type=Dolby Vision RPU Data
 [/SIDE_DATA]
 [/FRAME]
-[FRAME]
-[SIDE_DATA]
-side_data_type=Dolby Vision RPU Data
-[/SIDE_DATA]
-[/FRAME]
-[FRAME]
-[SIDE_DATA]
-side_data_type=Dolby Vision RPU Data
-[/SIDE_DATA]
-[/FRAME]
-[FRAME]
-[SIDE_DATA]
-side_data_type=Dolby Vision RPU Data
-[/SIDE_DATA]
-[/FRAME]
-[FRAME]
-[SIDE_DATA]
-side_data_type=Dolby Vision RPU Data
-[/SIDE_DATA]
-[/FRAME]
-[FRAME]
-[SIDE_DATA]
-side_data_type=Dolby Vision RPU Data
-[/SIDE_DATA]
-[/FRAME]
-[FRAME]
-[SIDE_DATA]
-side_data_type=Dolby Vision RPU Data
-[/SIDE_DATA]
-[/FRAME]
-[FRAME]
-[SIDE_DATA]
-side_data_type=Dolby Vision RPU Data
-[/SIDE_DATA]
-[/FRAME]
-[FRAME]
-[SIDE_DATA]
-side_data_type=Dolby Vision RPU Data
-[/SIDE_DATA]
-[/FRAME]
-[FRAME]
-[SIDE_DATA]
-side_data_type=Dolby Vision RPU Data
-[/SIDE_DATA]
-[/FRAME]
-[FRAME]
-[SIDE_DATA]
-side_data_type=Dolby Vision RPU Data
-[/SIDE_DATA]
-[/FRAME]
-[FRAME]
-[SIDE_DATA]
-side_data_type=Dolby Vision RPU Data
-[/SIDE_DATA]
-[/FRAME]
-[FRAME]
-[SIDE_DATA]
-side_data_type=Dolby Vision RPU Data
-[/SIDE_DATA]
-[/FRAME]
-[FRAME]
-[SIDE_DATA]
-side_data_type=Dolby Vision RPU Data
-[/SIDE_DATA]
-[/FRAME]
-[FRAME]
-[SIDE_DATA]
-side_data_type=Dolby Vision RPU Data
-[/SIDE_DATA]
-[/FRAME]
-[FRAME]
-[SIDE_DATA]
-side_data_type=Dolby Vision RPU Data
-[/SIDE_DATA]
-[/FRAME]
-[FRAME]
-[SIDE_DATA]
-side_data_type=Dolby Vision RPU Data
-[/SIDE_DATA]
-[/FRAME]
-[FRAME]
-[SIDE_DATA]
-side_data_type=Dolby Vision RPU Data
-[/SIDE_DATA]
-[/FRAME]
-[FRAME]
-[SIDE_DATA]
-side_data_type=Dolby Vision RPU Data
-[/SIDE_DATA]
-[/FRAME]
-[FRAME]
-[SIDE_DATA]
-side_data_type=Dolby Vision RPU Data
-[/SIDE_DATA]
-[/FRAME]
-[FRAME]
-[SIDE_DATA]
-side_data_type=Dolby Vision RPU Data
-[/SIDE_DATA]
-[/FRAME]
-[FRAME]
-[SIDE_DATA]
-side_data_type=Dolby Vision RPU Data
-[/SIDE_DATA]
-[/FRAME]
-[FRAME]
-[SIDE_DATA]
-side_data_type=Dolby Vision RPU Data
-[/SIDE_DATA]
-[/FRAME]
-[FRAME]
-[SIDE_DATA]
-side_data_type=Dolby Vision RPU Data
-[/SIDE_DATA]
-[/FRAME]
-[FRAME]
-[SIDE_DATA]
-side_data_type=Dolby Vision RPU Data
-[/SIDE_DATA]
-[/FRAME]
-[FRAME]
-[SIDE_DATA]
-side_data_type=Dolby Vision RPU Data
-[/SIDE_DATA]
-[/FRAME]
-[FRAME]
-[SIDE_DATA]
-side_data_type=Dolby Vision RPU Data
-[/SIDE_DATA]
-[/FRAME]
-[FRAME]
-[SIDE_DATA]
-side_data_type=Dolby Vision RPU Data
-[/SIDE_DATA]
-[/FRAME]
-[FRAME]
-[SIDE_DATA]
-side_data_type=Dolby Vision RPU Data
-[/SIDE_DATA]
-[/FRAME]
-[FRAME]
-[SIDE_DATA]
-side_data_type=Dolby Vision RPU Data
-[/SIDE_DATA]
-[/FRAME]
-[FRAME]
-[SIDE_DATA]
-side_data_type=Dolby Vision RPU Data
-[/SIDE_DATA]
-[/FRAME]
-[FRAME]
-[SIDE_DATA]
-side_data_type=H.26[45] User Data Unregistered SEI message
-[/SIDE_DATA]
-[SIDE_DATA]
-side_data_type=Dolby Vision RPU Data
-[/SIDE_DATA]
-[/FRAME]
-[FRAME]
-[SIDE_DATA]
-side_data_type=Dolby Vision RPU Data
-[/SIDE_DATA]
-[/FRAME]
-[FRAME]
-[SIDE_DATA]
-side_data_type=Dolby Vision RPU Data
-[/SIDE_DATA]
-[/FRAME]
-[FRAME]
-[SIDE_DATA]
-side_data_type=Dolby Vision RPU Data
-[/SIDE_DATA]
-[/FRAME]
-[FRAME]
-[SIDE_DATA]
-side_data_type=Dolby Vision RPU Data
-[/SIDE_DATA]
-[/FRAME]
-[FRAME]
-[SIDE_DATA]
-side_data_type=Dolby Vision RPU Data
-[/SIDE_DATA]
-[/FRAME]
-[FRAME]
-[SIDE_DATA]
-side_data_type=Dolby Vision RPU Data
-[/SIDE_DATA]
-[/FRAME]
-[FRAME]
-[SIDE_DATA]
-side_data_type=Dolby Vision RPU Data
-[/SIDE_DATA]
-[/FRAME]
-[FRAME]
-[SIDE_DATA]
-side_data_type=Dolby Vision RPU Data
-[/SIDE_DATA]
-[/FRAME]
-[FRAME]

[FFmpeg-devel] [PATCH v10 3/6] ffprobe: Support AV_FRAME_DATA_DOVI_METADATA

2022-01-02 Thread Niklas Haas 
From: Jan Ekström 

Co-authored-by: Niklas Haas 
---
 fftools/ffprobe.c | 173 +-
 1 file changed, 170 insertions(+), 3 deletions(-)

diff --git a/fftools/ffprobe.c b/fftools/ffprobe.c
index 906bb03b16..20582ca7ac 100644
--- a/fftools/ffprobe.c
+++ b/fftools/ffprobe.c
@@ -175,6 +175,10 @@ typedef enum {
 SECTION_ID_FRAME_SIDE_DATA,
 SECTION_ID_FRAME_SIDE_DATA_TIMECODE_LIST,
 SECTION_ID_FRAME_SIDE_DATA_TIMECODE,
+SECTION_ID_FRAME_SIDE_DATA_COMPONENT_LIST,
+SECTION_ID_FRAME_SIDE_DATA_COMPONENT,
+SECTION_ID_FRAME_SIDE_DATA_PIECE_LIST,
+SECTION_ID_FRAME_SIDE_DATA_PIECE,
 SECTION_ID_FRAME_LOG,
 SECTION_ID_FRAME_LOGS,
 SECTION_ID_LIBRARY_VERSION,
@@ -219,9 +223,13 @@ static struct section sections[] = {
 [SECTION_ID_FRAME] =  { SECTION_ID_FRAME, "frame", 0, { 
SECTION_ID_FRAME_TAGS, SECTION_ID_FRAME_SIDE_DATA_LIST, SECTION_ID_FRAME_LOGS, 
-1 } },
 [SECTION_ID_FRAME_TAGS] = { SECTION_ID_FRAME_TAGS, "tags", 
SECTION_FLAG_HAS_VARIABLE_FIELDS, { -1 }, .element_name = "tag", .unique_name = 
"frame_tags" },
 [SECTION_ID_FRAME_SIDE_DATA_LIST] ={ SECTION_ID_FRAME_SIDE_DATA_LIST, 
"side_data_list", SECTION_FLAG_IS_ARRAY, { SECTION_ID_FRAME_SIDE_DATA, -1 }, 
.element_name = "side_data", .unique_name = "frame_side_data_list" },
-[SECTION_ID_FRAME_SIDE_DATA] = { SECTION_ID_FRAME_SIDE_DATA, 
"side_data", 0, { SECTION_ID_FRAME_SIDE_DATA_TIMECODE_LIST, -1 } },
-[SECTION_ID_FRAME_SIDE_DATA_TIMECODE_LIST] = { 
SECTION_ID_FRAME_SIDE_DATA_TIMECODE_LIST, "timecodes", SECTION_FLAG_IS_ARRAY, { 
SECTION_ID_FRAME_SIDE_DATA_TIMECODE, -1 } },
-[SECTION_ID_FRAME_SIDE_DATA_TIMECODE] = { 
SECTION_ID_FRAME_SIDE_DATA_TIMECODE, "timecode", 0, { -1 } },
+[SECTION_ID_FRAME_SIDE_DATA] = { SECTION_ID_FRAME_SIDE_DATA, 
"side_data", 0, { SECTION_ID_FRAME_SIDE_DATA_TIMECODE_LIST, 
SECTION_ID_FRAME_SIDE_DATA_COMPONENT_LIST, -1 } },
+[SECTION_ID_FRAME_SIDE_DATA_TIMECODE_LIST] =  { 
SECTION_ID_FRAME_SIDE_DATA_TIMECODE_LIST, "timecodes", SECTION_FLAG_IS_ARRAY, { 
SECTION_ID_FRAME_SIDE_DATA_TIMECODE, -1 } },
+[SECTION_ID_FRAME_SIDE_DATA_TIMECODE] =   { 
SECTION_ID_FRAME_SIDE_DATA_TIMECODE, "timecode", 0, { -1 } },
+[SECTION_ID_FRAME_SIDE_DATA_COMPONENT_LIST] = { 
SECTION_ID_FRAME_SIDE_DATA_COMPONENT_LIST, "components", SECTION_FLAG_IS_ARRAY, 
{ SECTION_ID_FRAME_SIDE_DATA_COMPONENT, -1 } },
+[SECTION_ID_FRAME_SIDE_DATA_COMPONENT] =  { 
SECTION_ID_FRAME_SIDE_DATA_COMPONENT, "component", 0, { 
SECTION_ID_FRAME_SIDE_DATA_PIECE_LIST, -1 } },
+[SECTION_ID_FRAME_SIDE_DATA_PIECE_LIST] =   { 
SECTION_ID_FRAME_SIDE_DATA_PIECE_LIST, "pieces", SECTION_FLAG_IS_ARRAY, { 
SECTION_ID_FRAME_SIDE_DATA_PIECE, -1 } },
+[SECTION_ID_FRAME_SIDE_DATA_PIECE] ={ 
SECTION_ID_FRAME_SIDE_DATA_PIECE, "section", 0, { -1 } },
 [SECTION_ID_FRAME_LOGS] = { SECTION_ID_FRAME_LOGS, "logs", 
SECTION_FLAG_IS_ARRAY, { SECTION_ID_FRAME_LOG, -1 } },
 [SECTION_ID_FRAME_LOG] =  { SECTION_ID_FRAME_LOG, "log", 0, { -1 
},  },
 [SECTION_ID_LIBRARY_VERSIONS] =   { SECTION_ID_LIBRARY_VERSIONS, 
"library_versions", SECTION_FLAG_IS_ARRAY, { SECTION_ID_LIBRARY_VERSION, -1 } },
@@ -1809,6 +1817,16 @@ static void writer_register_all(void)
 writer_print_string(w, k, pbuf.str, 0);\
 } while (0)
 
+#define print_list_fmt(k, f, n, ...) do {   \
+av_bprint_clear(&pbuf); \
+for (int idx = 0; idx < n; idx++) { \
+if (idx > 0)\
+av_bprint_chars(&pbuf, ' ', 1); \
+av_bprintf(&pbuf, f, __VA_ARGS__);  \
+}   \
+writer_print_string(w, k, pbuf.str, 0); \
+} while (0)
+
 #define print_int(k, v) writer_print_integer(w, k, v)
 #define print_q(k, v, s)writer_print_rational(w, k, v, s)
 #define print_str(k, v) writer_print_string(w, k, v, 0)
@@ -1854,6 +1872,153 @@ static inline int show_tags(WriterContext *w, 
AVDictionary *tags, int section_id
 return ret;
 }
 
+static void print_dovi_metadata(WriterContext *w, const AVDOVIMetadata *dovi)
+{
+if (!dovi)
+return;
+
+{
+const AVDOVIRpuDataHeader *hdr = av_dovi_get_header(dovi);
+const AVDOVIDataMapping   *mapping = av_dovi_get_mapping(dovi);
+const AVDOVIColorMetadata *color   = av_dovi_get_color(dovi);
+AVBPrint pbuf;
+
+av_bprint_init(&pbuf, 1, AV_BPRINT_SIZE_UNLIMITED);
+
+// header
+print_int("rpu_type",hdr->rpu_type);
+print_int("rpu_format",  hdr->rpu_format);
+print_int("vdr_rpu_profile", hdr->vdr_rpu_profile);
+print_int("vdr_rpu_level",   hdr->vdr_rpu_level);
+print_int("chroma_resampling_explicit_filter_flag",
+  hdr->chroma_resampling_explicit_filter_flag);
+print_int("coef_data_type",   hdr->coef_data_type);
+

Re: [FFmpeg-devel] [PATCH v2] avformat/imf: add IMF CPL with repeated resources to FATE

2022-01-02 Thread Pierre-Anthony Lemieux 
On Sun, Jan 2, 2022 at 3:42 PM James Almer  wrote:
>
>
>
> On 1/2/2022 8:38 PM, Pierre-Anthony Lemieux wrote:
> > On Sun, Jan 2, 2022 at 3:28 PM James Almer  wrote:
> >>
> >>
> >>
> >> On 1/2/2022 8:16 PM, p...@sandflow.com wrote:
> >>> From: Pierre-Anthony Lemieux 
> >>>
> >>> Signed-off-by: Pierre-Anthony Lemieux 
> >>> ---
> >>>
> >>> Notes:
> >>>   The `fate-imf-cpl-with-repeat` target requires following files 
> >>> (<256 kB)
> >>>   to placed under $(TARGET_SAMPLES)/imf/countdown/:
> >>>   
> >>> http://ffmpeg-imf-samples-public.s3-website-us-west-1.amazonaws.com/countdown/ASSETMAP.xml
> >>>   
> >>> http://ffmpeg-imf-samples-public.s3-website-us-west-1.amazonaws.com/countdown/CPL_f5095caa-f204-4e1c-8a84-7af48c7ae16b.xml
> >>>   
> >>> http://ffmpeg-imf-samples-public.s3-website-us-west-1.amazonaws.com/countdown/PKL_4671220f-c87a-4660-bf2a-6ef848791a2c.xml
> >>>   
> >>> http://ffmpeg-imf-samples-public.s3-website-us-west-1.amazonaws.com/countdown/frame-counter.mxf
> >>>
> >>>tests/Makefile |  1 +
> >>>tests/fate/imf.mak | 12 
> >>>tests/ref/fate/imf-cpl-with-repeat | 46 ++
> >>>3 files changed, 59 insertions(+)
> >>>create mode 100644 tests/fate/imf.mak
> >>>create mode 100644 tests/ref/fate/imf-cpl-with-repeat
> >>>
> >>> diff --git a/tests/Makefile b/tests/Makefile
> >>> index 87807ed31f..c4c31ae871 100644
> >>> --- a/tests/Makefile
> >>> +++ b/tests/Makefile
> >>> @@ -153,6 +153,7 @@ include $(SRC_PATH)/tests/fate/hlsenc.mak
> >>>include $(SRC_PATH)/tests/fate/hw.mak
> >>>include $(SRC_PATH)/tests/fate/id3v2.mak
> >>>include $(SRC_PATH)/tests/fate/image.mak
> >>> +include $(SRC_PATH)/tests/fate/imf.mak
> >>>include $(SRC_PATH)/tests/fate/indeo.mak
> >>>include $(SRC_PATH)/tests/fate/libavcodec.mak
> >>>include $(SRC_PATH)/tests/fate/libavdevice.mak
> >>> diff --git a/tests/fate/imf.mak b/tests/fate/imf.mak
> >>> new file mode 100644
> >>> index 00..c9490d665b
> >>> --- /dev/null
> >>> +++ b/tests/fate/imf.mak
> >>> @@ -0,0 +1,12 @@
> >>> +FATE_IMF += fate-imf-cpl-with-repeat
> >>> +fate-imf-cpl-with-repeat: 
> >>> $(TARGET_SAMPLES)/imf/countdown/CPL_f5095caa-f204-4e1c-8a84-7af48c7ae16b.xml
> >>> +fate-imf-cpl-with-repeat: $(TARGET_SAMPLES)/imf/countdown/ASSETMAP.xml
> >>> +fate-imf-cpl-with-repeat: 
> >>> $(TARGET_SAMPLES)/imf/countdown/frame-counter.mxf
> >>> +fate-imf-cpl-with-repeat: 
> >>> $(TARGET_SAMPLES)/imf/countdown/PKL_4671220f-c87a-4660-bf2a-6ef848791a2c.xml
> >>
> >> No need for these four lines. They wrongly make the build system assume
> >> it needs to create these files if they are not available.
> >>
> >> Simply by adding the test to the FATE_SAMPLES_AVCONV list like you're
> >> doing below will make sure it's not run unless a samples directory was
> >> provided.
> >>
> >>> +fate-imf-cpl-with-repeat: CMD = framecrc -i 
> >>> $(TARGET_SAMPLES)/imf/countdown/CPL_f5095caa-f204-4e1c-8a84-7af48c7ae16b.xml
> >>>  -c:v copy
> >>> +
> >>> +FATE_IMF-$(CONFIG_IMF_DEMUXER) += $(FATE_IMF)
> >>
> >> This test also needs the mxf demuxer, right? Should instead be
> >>
> >> $(call ALLYES, IMF_DEMUXER MXF_DEMUXER) if so.
> >>
> >>> +
> >>> +FATE_SAMPLES_AVCONV += $(FATE_IMF-yes)
> >>> +
> >>> +fate-imf: $(FATE_IMF-yes)
> >>
> >> You can do
> >>
> >> FATE_SAMPLES_AVCONV-$(call ALLYES, IMF_DEMUXER MXF_DEMUXER) += $(FATE_IMF)
> >>
> >> fate-imf: $(FATE_IMF)
> >>
> >> And not bother adding a FATE_IMF-yes variable.
> >
> > ... so basically:
> >
> > ```
> > FATE_IMF += fate-imf-cpl-with-repeat
> > fate-imf-cpl-with-repeat: CMD = framecrc -i
> > $(TARGET_SAMPLES)/imf/countdown/CPL_f5095caa-f204-4e1c-8a84-7af48c7ae16b.xml
> > -c:v copy
> > FATE_SAMPLES_AVCONV-$(call ALLYES, IMF_DEMUXER MXF_DEMUXER) += $(FATE_IMF)
> > fate-imf: $(FATE_IMF)
> > ```
>
> Yes.

Thanks. See v3.

>
> >
> >>
> >>> diff --git a/tests/ref/fate/imf-cpl-with-repeat 
> >>> b/tests/ref/fate/imf-cpl-with-repeat
> >>> new file mode 100644
> >>> index 00..38092d542c
> >>> --- /dev/null
> >>> +++ b/tests/ref/fate/imf-cpl-with-repeat
> >>> @@ -0,0 +1,46 @@
> >>> +#tb 0: 1/24
> >>> +#media_type 0: video
> >>> +#codec_id 0: jpeg2000
> >>> +#dimensions 0: 1920x1080
> >>> +#sar 0: 0/1
> >>> +0,  0,  0,1, 5034, 0x29a972c1
> >>> +0,  1,  1,1, 7214, 0x704fb452
> >>> +0,  2,  2,1, 8496, 0xee9d2692
> >>> +0,  3,  3,1, 4917, 0xd35c1a2f
> >>> +0,  4,  4,1, 8803, 0xdc01ad91
> >>> +0,  5,  5,1, 8426, 0xacc4413a
> >>> +0,  6,  6,1, 9626, 0x46865f1e
> >>> +0,  7,  7,1, 7409, 0xa21efc69
> >>> +0,  8,  8,1, 7409, 0xa21efc69
> >>> +0,  9,  9,1, 7409, 0xa21efc69
> >>> +0, 10, 10,1, 74

[FFmpeg-devel] [PATCH v3] avformat/imf: add IMF CPL with repeated resources to FATE

2022-01-02 Thread pal 
From: Pierre-Anthony Lemieux 

Signed-off-by: Pierre-Anthony Lemieux 
---

Notes:
The `fate-imf-cpl-with-repeat` target requires following files (<256 kB)
to placed under $(TARGET_SAMPLES)/imf/countdown/:

http://ffmpeg-imf-samples-public.s3-website-us-west-1.amazonaws.com/countdown/ASSETMAP.xml

http://ffmpeg-imf-samples-public.s3-website-us-west-1.amazonaws.com/countdown/CPL_f5095caa-f204-4e1c-8a84-7af48c7ae16b.xml

http://ffmpeg-imf-samples-public.s3-website-us-west-1.amazonaws.com/countdown/PKL_4671220f-c87a-4660-bf2a-6ef848791a2c.xml

http://ffmpeg-imf-samples-public.s3-website-us-west-1.amazonaws.com/countdown/frame-counter.mxf

 tests/Makefile |  1 +
 tests/fate/imf.mak |  6 
 tests/ref/fate/imf-cpl-with-repeat | 46 ++
 3 files changed, 53 insertions(+)
 create mode 100644 tests/fate/imf.mak
 create mode 100644 tests/ref/fate/imf-cpl-with-repeat

diff --git a/tests/Makefile b/tests/Makefile
index 87807ed31f..c4c31ae871 100644
--- a/tests/Makefile
+++ b/tests/Makefile
@@ -153,6 +153,7 @@ include $(SRC_PATH)/tests/fate/hlsenc.mak
 include $(SRC_PATH)/tests/fate/hw.mak
 include $(SRC_PATH)/tests/fate/id3v2.mak
 include $(SRC_PATH)/tests/fate/image.mak
+include $(SRC_PATH)/tests/fate/imf.mak
 include $(SRC_PATH)/tests/fate/indeo.mak
 include $(SRC_PATH)/tests/fate/libavcodec.mak
 include $(SRC_PATH)/tests/fate/libavdevice.mak
diff --git a/tests/fate/imf.mak b/tests/fate/imf.mak
new file mode 100644
index 00..e2c35bef82
--- /dev/null
+++ b/tests/fate/imf.mak
@@ -0,0 +1,6 @@
+FATE_IMF += fate-imf-cpl-with-repeat
+fate-imf-cpl-with-repeat: CMD = framecrc -i 
$(TARGET_SAMPLES)/imf/countdown/CPL_f5095caa-f204-4e1c-8a84-7af48c7ae16b.xml 
-c:v copy
+
+FATE_SAMPLES_AVCONV-$(call ALLYES, IMF_DEMUXER MXF_DEMUXER) += $(FATE_IMF)
+
+fate-imf: $(FATE_IMF)
diff --git a/tests/ref/fate/imf-cpl-with-repeat 
b/tests/ref/fate/imf-cpl-with-repeat
new file mode 100644
index 00..38092d542c
--- /dev/null
+++ b/tests/ref/fate/imf-cpl-with-repeat
@@ -0,0 +1,46 @@
+#tb 0: 1/24
+#media_type 0: video
+#codec_id 0: jpeg2000
+#dimensions 0: 1920x1080
+#sar 0: 0/1
+0,  0,  0,1, 5034, 0x29a972c1
+0,  1,  1,1, 7214, 0x704fb452
+0,  2,  2,1, 8496, 0xee9d2692
+0,  3,  3,1, 4917, 0xd35c1a2f
+0,  4,  4,1, 8803, 0xdc01ad91
+0,  5,  5,1, 8426, 0xacc4413a
+0,  6,  6,1, 9626, 0x46865f1e
+0,  7,  7,1, 7409, 0xa21efc69
+0,  8,  8,1, 7409, 0xa21efc69
+0,  9,  9,1, 7409, 0xa21efc69
+0, 10, 10,1, 7409, 0xa21efc69
+0, 11, 11,1, 7409, 0xa21efc69
+0, 12, 12,1, 7409, 0xa21efc69
+0, 13, 13,1, 7409, 0xa21efc69
+0, 14, 14,1, 7409, 0xa21efc69
+0, 15, 15,1, 7409, 0xa21efc69
+0, 16, 16,1, 7409, 0xa21efc69
+0, 17, 17,1, 7409, 0xa21efc69
+0, 18, 18,1, 7409, 0xa21efc69
+0, 19, 19,1, 7409, 0xa21efc69
+0, 20, 20,1, 7409, 0xa21efc69
+0, 21, 21,1, 7409, 0xa21efc69
+0, 22, 22,1, 7409, 0xa21efc69
+0, 23, 23,1, 7409, 0xa21efc69
+0, 24, 24,1, 7409, 0xa21efc69
+0, 25, 25,1, 7409, 0xa21efc69
+0, 26, 26,1, 7409, 0xa21efc69
+0, 27, 27,1, 7409, 0xa21efc69
+0, 28, 28,1, 7409, 0xa21efc69
+0, 29, 29,1, 7409, 0xa21efc69
+0, 30, 30,1, 7409, 0xa21efc69
+0, 30, 31,1, 8426, 0xacc4413a
+0, 30, 32,1, 9626, 0x46865f1e
+0, 30, 33,1, 5412, 0xf4884a91
+0, 30, 34,1, 9129, 0xbdb77fb3
+0, 30, 35,1,10009, 0xac8a3ec5
+0, 30, 36,1, 7204, 0x4e239746
+0, 30, 37,1, 9413, 0x27620541
+0, 30, 38,1,10725, 0x2feb9589
+0, 30, 39,1, 7101, 0x62159f85
+0, 30, 40,1,10984, 0xa2eb2e49
-- 
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".

Re: [FFmpeg-devel] [PATCH v2] avformat/imf: add IMF CPL with repeated resources to FATE

2022-01-02 Thread James Almer 




On 1/2/2022 8:38 PM, Pierre-Anthony Lemieux wrote:

On Sun, Jan 2, 2022 at 3:28 PM James Almer  wrote:




On 1/2/2022 8:16 PM, p...@sandflow.com wrote:

From: Pierre-Anthony Lemieux 

Signed-off-by: Pierre-Anthony Lemieux 
---

Notes:
  The `fate-imf-cpl-with-repeat` target requires following files (<256 kB)
  to placed under $(TARGET_SAMPLES)/imf/countdown/:
  
http://ffmpeg-imf-samples-public.s3-website-us-west-1.amazonaws.com/countdown/ASSETMAP.xml
  
http://ffmpeg-imf-samples-public.s3-website-us-west-1.amazonaws.com/countdown/CPL_f5095caa-f204-4e1c-8a84-7af48c7ae16b.xml
  
http://ffmpeg-imf-samples-public.s3-website-us-west-1.amazonaws.com/countdown/PKL_4671220f-c87a-4660-bf2a-6ef848791a2c.xml
  
http://ffmpeg-imf-samples-public.s3-website-us-west-1.amazonaws.com/countdown/frame-counter.mxf

   tests/Makefile |  1 +
   tests/fate/imf.mak | 12 
   tests/ref/fate/imf-cpl-with-repeat | 46 ++
   3 files changed, 59 insertions(+)
   create mode 100644 tests/fate/imf.mak
   create mode 100644 tests/ref/fate/imf-cpl-with-repeat

diff --git a/tests/Makefile b/tests/Makefile
index 87807ed31f..c4c31ae871 100644
--- a/tests/Makefile
+++ b/tests/Makefile
@@ -153,6 +153,7 @@ include $(SRC_PATH)/tests/fate/hlsenc.mak
   include $(SRC_PATH)/tests/fate/hw.mak
   include $(SRC_PATH)/tests/fate/id3v2.mak
   include $(SRC_PATH)/tests/fate/image.mak
+include $(SRC_PATH)/tests/fate/imf.mak
   include $(SRC_PATH)/tests/fate/indeo.mak
   include $(SRC_PATH)/tests/fate/libavcodec.mak
   include $(SRC_PATH)/tests/fate/libavdevice.mak
diff --git a/tests/fate/imf.mak b/tests/fate/imf.mak
new file mode 100644
index 00..c9490d665b
--- /dev/null
+++ b/tests/fate/imf.mak
@@ -0,0 +1,12 @@
+FATE_IMF += fate-imf-cpl-with-repeat
+fate-imf-cpl-with-repeat: 
$(TARGET_SAMPLES)/imf/countdown/CPL_f5095caa-f204-4e1c-8a84-7af48c7ae16b.xml
+fate-imf-cpl-with-repeat: $(TARGET_SAMPLES)/imf/countdown/ASSETMAP.xml
+fate-imf-cpl-with-repeat: $(TARGET_SAMPLES)/imf/countdown/frame-counter.mxf
+fate-imf-cpl-with-repeat: 
$(TARGET_SAMPLES)/imf/countdown/PKL_4671220f-c87a-4660-bf2a-6ef848791a2c.xml


No need for these four lines. They wrongly make the build system assume
it needs to create these files if they are not available.

Simply by adding the test to the FATE_SAMPLES_AVCONV list like you're
doing below will make sure it's not run unless a samples directory was
provided.


+fate-imf-cpl-with-repeat: CMD = framecrc -i 
$(TARGET_SAMPLES)/imf/countdown/CPL_f5095caa-f204-4e1c-8a84-7af48c7ae16b.xml 
-c:v copy
+
+FATE_IMF-$(CONFIG_IMF_DEMUXER) += $(FATE_IMF)


This test also needs the mxf demuxer, right? Should instead be

$(call ALLYES, IMF_DEMUXER MXF_DEMUXER) if so.


+
+FATE_SAMPLES_AVCONV += $(FATE_IMF-yes)
+
+fate-imf: $(FATE_IMF-yes)


You can do

FATE_SAMPLES_AVCONV-$(call ALLYES, IMF_DEMUXER MXF_DEMUXER) += $(FATE_IMF)

fate-imf: $(FATE_IMF)

And not bother adding a FATE_IMF-yes variable.


... so basically:

```
FATE_IMF += fate-imf-cpl-with-repeat
fate-imf-cpl-with-repeat: CMD = framecrc -i
$(TARGET_SAMPLES)/imf/countdown/CPL_f5095caa-f204-4e1c-8a84-7af48c7ae16b.xml
-c:v copy
FATE_SAMPLES_AVCONV-$(call ALLYES, IMF_DEMUXER MXF_DEMUXER) += $(FATE_IMF)
fate-imf: $(FATE_IMF)
```


Yes.






diff --git a/tests/ref/fate/imf-cpl-with-repeat 
b/tests/ref/fate/imf-cpl-with-repeat
new file mode 100644
index 00..38092d542c
--- /dev/null
+++ b/tests/ref/fate/imf-cpl-with-repeat
@@ -0,0 +1,46 @@
+#tb 0: 1/24
+#media_type 0: video
+#codec_id 0: jpeg2000
+#dimensions 0: 1920x1080
+#sar 0: 0/1
+0,  0,  0,1, 5034, 0x29a972c1
+0,  1,  1,1, 7214, 0x704fb452
+0,  2,  2,1, 8496, 0xee9d2692
+0,  3,  3,1, 4917, 0xd35c1a2f
+0,  4,  4,1, 8803, 0xdc01ad91
+0,  5,  5,1, 8426, 0xacc4413a
+0,  6,  6,1, 9626, 0x46865f1e
+0,  7,  7,1, 7409, 0xa21efc69
+0,  8,  8,1, 7409, 0xa21efc69
+0,  9,  9,1, 7409, 0xa21efc69
+0, 10, 10,1, 7409, 0xa21efc69
+0, 11, 11,1, 7409, 0xa21efc69
+0, 12, 12,1, 7409, 0xa21efc69
+0, 13, 13,1, 7409, 0xa21efc69
+0, 14, 14,1, 7409, 0xa21efc69
+0, 15, 15,1, 7409, 0xa21efc69
+0, 16, 16,1, 7409, 0xa21efc69
+0, 17, 17,1, 7409, 0xa21efc69
+0, 18, 18,1, 7409, 0xa21efc69
+0, 19, 19,1, 7409, 0xa21efc69
+0, 20, 20,1, 7409, 0xa21efc69
+0, 21, 21,1, 7409, 0xa21efc69
+0, 22, 22,1, 7409, 0xa21efc69
+0

Re: [FFmpeg-devel] [PATCH v2] avformat/imf: add IMF CPL with repeated resources to FATE

2022-01-02 Thread Pierre-Anthony Lemieux 
On Sun, Jan 2, 2022 at 3:28 PM James Almer  wrote:
>
>
>
> On 1/2/2022 8:16 PM, p...@sandflow.com wrote:
> > From: Pierre-Anthony Lemieux 
> >
> > Signed-off-by: Pierre-Anthony Lemieux 
> > ---
> >
> > Notes:
> >  The `fate-imf-cpl-with-repeat` target requires following files (<256 
> > kB)
> >  to placed under $(TARGET_SAMPLES)/imf/countdown/:
> >  
> > http://ffmpeg-imf-samples-public.s3-website-us-west-1.amazonaws.com/countdown/ASSETMAP.xml
> >  
> > http://ffmpeg-imf-samples-public.s3-website-us-west-1.amazonaws.com/countdown/CPL_f5095caa-f204-4e1c-8a84-7af48c7ae16b.xml
> >  
> > http://ffmpeg-imf-samples-public.s3-website-us-west-1.amazonaws.com/countdown/PKL_4671220f-c87a-4660-bf2a-6ef848791a2c.xml
> >  
> > http://ffmpeg-imf-samples-public.s3-website-us-west-1.amazonaws.com/countdown/frame-counter.mxf
> >
> >   tests/Makefile |  1 +
> >   tests/fate/imf.mak | 12 
> >   tests/ref/fate/imf-cpl-with-repeat | 46 ++
> >   3 files changed, 59 insertions(+)
> >   create mode 100644 tests/fate/imf.mak
> >   create mode 100644 tests/ref/fate/imf-cpl-with-repeat
> >
> > diff --git a/tests/Makefile b/tests/Makefile
> > index 87807ed31f..c4c31ae871 100644
> > --- a/tests/Makefile
> > +++ b/tests/Makefile
> > @@ -153,6 +153,7 @@ include $(SRC_PATH)/tests/fate/hlsenc.mak
> >   include $(SRC_PATH)/tests/fate/hw.mak
> >   include $(SRC_PATH)/tests/fate/id3v2.mak
> >   include $(SRC_PATH)/tests/fate/image.mak
> > +include $(SRC_PATH)/tests/fate/imf.mak
> >   include $(SRC_PATH)/tests/fate/indeo.mak
> >   include $(SRC_PATH)/tests/fate/libavcodec.mak
> >   include $(SRC_PATH)/tests/fate/libavdevice.mak
> > diff --git a/tests/fate/imf.mak b/tests/fate/imf.mak
> > new file mode 100644
> > index 00..c9490d665b
> > --- /dev/null
> > +++ b/tests/fate/imf.mak
> > @@ -0,0 +1,12 @@
> > +FATE_IMF += fate-imf-cpl-with-repeat
> > +fate-imf-cpl-with-repeat: 
> > $(TARGET_SAMPLES)/imf/countdown/CPL_f5095caa-f204-4e1c-8a84-7af48c7ae16b.xml
> > +fate-imf-cpl-with-repeat: $(TARGET_SAMPLES)/imf/countdown/ASSETMAP.xml
> > +fate-imf-cpl-with-repeat: $(TARGET_SAMPLES)/imf/countdown/frame-counter.mxf
> > +fate-imf-cpl-with-repeat: 
> > $(TARGET_SAMPLES)/imf/countdown/PKL_4671220f-c87a-4660-bf2a-6ef848791a2c.xml
>
> No need for these four lines. They wrongly make the build system assume
> it needs to create these files if they are not available.
>
> Simply by adding the test to the FATE_SAMPLES_AVCONV list like you're
> doing below will make sure it's not run unless a samples directory was
> provided.
>
> > +fate-imf-cpl-with-repeat: CMD = framecrc -i 
> > $(TARGET_SAMPLES)/imf/countdown/CPL_f5095caa-f204-4e1c-8a84-7af48c7ae16b.xml
> >  -c:v copy
> > +
> > +FATE_IMF-$(CONFIG_IMF_DEMUXER) += $(FATE_IMF)
>
> This test also needs the mxf demuxer, right? Should instead be
>
> $(call ALLYES, IMF_DEMUXER MXF_DEMUXER) if so.
>
> > +
> > +FATE_SAMPLES_AVCONV += $(FATE_IMF-yes)
> > +
> > +fate-imf: $(FATE_IMF-yes)
>
> You can do
>
> FATE_SAMPLES_AVCONV-$(call ALLYES, IMF_DEMUXER MXF_DEMUXER) += $(FATE_IMF)
>
> fate-imf: $(FATE_IMF)
>
> And not bother adding a FATE_IMF-yes variable.

... so basically:

```
FATE_IMF += fate-imf-cpl-with-repeat
fate-imf-cpl-with-repeat: CMD = framecrc -i
$(TARGET_SAMPLES)/imf/countdown/CPL_f5095caa-f204-4e1c-8a84-7af48c7ae16b.xml
-c:v copy
FATE_SAMPLES_AVCONV-$(call ALLYES, IMF_DEMUXER MXF_DEMUXER) += $(FATE_IMF)
fate-imf: $(FATE_IMF)
```

>
> > diff --git a/tests/ref/fate/imf-cpl-with-repeat 
> > b/tests/ref/fate/imf-cpl-with-repeat
> > new file mode 100644
> > index 00..38092d542c
> > --- /dev/null
> > +++ b/tests/ref/fate/imf-cpl-with-repeat
> > @@ -0,0 +1,46 @@
> > +#tb 0: 1/24
> > +#media_type 0: video
> > +#codec_id 0: jpeg2000
> > +#dimensions 0: 1920x1080
> > +#sar 0: 0/1
> > +0,  0,  0,1, 5034, 0x29a972c1
> > +0,  1,  1,1, 7214, 0x704fb452
> > +0,  2,  2,1, 8496, 0xee9d2692
> > +0,  3,  3,1, 4917, 0xd35c1a2f
> > +0,  4,  4,1, 8803, 0xdc01ad91
> > +0,  5,  5,1, 8426, 0xacc4413a
> > +0,  6,  6,1, 9626, 0x46865f1e
> > +0,  7,  7,1, 7409, 0xa21efc69
> > +0,  8,  8,1, 7409, 0xa21efc69
> > +0,  9,  9,1, 7409, 0xa21efc69
> > +0, 10, 10,1, 7409, 0xa21efc69
> > +0, 11, 11,1, 7409, 0xa21efc69
> > +0, 12, 12,1, 7409, 0xa21efc69
> > +0, 13, 13,1, 7409, 0xa21efc69
> > +0, 14, 14,1, 7409, 0xa21efc69
> > +0, 15, 15,1, 7409, 0xa21efc69
> > +0, 16, 16,1, 7409, 0xa21efc69
> > +0, 17, 17,1, 7409, 0xa21efc69

Re: [FFmpeg-devel] [PATCH v2] avformat/imf: add IMF CPL with repeated resources to FATE

2022-01-02 Thread James Almer 




On 1/2/2022 8:16 PM, p...@sandflow.com wrote:

From: Pierre-Anthony Lemieux 

Signed-off-by: Pierre-Anthony Lemieux 
---

Notes:
 The `fate-imf-cpl-with-repeat` target requires following files (<256 kB)
 to placed under $(TARGET_SAMPLES)/imf/countdown/:
 
http://ffmpeg-imf-samples-public.s3-website-us-west-1.amazonaws.com/countdown/ASSETMAP.xml
 
http://ffmpeg-imf-samples-public.s3-website-us-west-1.amazonaws.com/countdown/CPL_f5095caa-f204-4e1c-8a84-7af48c7ae16b.xml
 
http://ffmpeg-imf-samples-public.s3-website-us-west-1.amazonaws.com/countdown/PKL_4671220f-c87a-4660-bf2a-6ef848791a2c.xml
 
http://ffmpeg-imf-samples-public.s3-website-us-west-1.amazonaws.com/countdown/frame-counter.mxf

  tests/Makefile |  1 +
  tests/fate/imf.mak | 12 
  tests/ref/fate/imf-cpl-with-repeat | 46 ++
  3 files changed, 59 insertions(+)
  create mode 100644 tests/fate/imf.mak
  create mode 100644 tests/ref/fate/imf-cpl-with-repeat

diff --git a/tests/Makefile b/tests/Makefile
index 87807ed31f..c4c31ae871 100644
--- a/tests/Makefile
+++ b/tests/Makefile
@@ -153,6 +153,7 @@ include $(SRC_PATH)/tests/fate/hlsenc.mak
  include $(SRC_PATH)/tests/fate/hw.mak
  include $(SRC_PATH)/tests/fate/id3v2.mak
  include $(SRC_PATH)/tests/fate/image.mak
+include $(SRC_PATH)/tests/fate/imf.mak
  include $(SRC_PATH)/tests/fate/indeo.mak
  include $(SRC_PATH)/tests/fate/libavcodec.mak
  include $(SRC_PATH)/tests/fate/libavdevice.mak
diff --git a/tests/fate/imf.mak b/tests/fate/imf.mak
new file mode 100644
index 00..c9490d665b
--- /dev/null
+++ b/tests/fate/imf.mak
@@ -0,0 +1,12 @@
+FATE_IMF += fate-imf-cpl-with-repeat
+fate-imf-cpl-with-repeat: 
$(TARGET_SAMPLES)/imf/countdown/CPL_f5095caa-f204-4e1c-8a84-7af48c7ae16b.xml
+fate-imf-cpl-with-repeat: $(TARGET_SAMPLES)/imf/countdown/ASSETMAP.xml
+fate-imf-cpl-with-repeat: $(TARGET_SAMPLES)/imf/countdown/frame-counter.mxf
+fate-imf-cpl-with-repeat: 
$(TARGET_SAMPLES)/imf/countdown/PKL_4671220f-c87a-4660-bf2a-6ef848791a2c.xml


No need for these four lines. They wrongly make the build system assume 
it needs to create these files if they are not available.


Simply by adding the test to the FATE_SAMPLES_AVCONV list like you're 
doing below will make sure it's not run unless a samples directory was 
provided.



+fate-imf-cpl-with-repeat: CMD = framecrc -i 
$(TARGET_SAMPLES)/imf/countdown/CPL_f5095caa-f204-4e1c-8a84-7af48c7ae16b.xml 
-c:v copy
+
+FATE_IMF-$(CONFIG_IMF_DEMUXER) += $(FATE_IMF)


This test also needs the mxf demuxer, right? Should instead be

$(call ALLYES, IMF_DEMUXER MXF_DEMUXER) if so.


+
+FATE_SAMPLES_AVCONV += $(FATE_IMF-yes)
+
+fate-imf: $(FATE_IMF-yes)


You can do

FATE_SAMPLES_AVCONV-$(call ALLYES, IMF_DEMUXER MXF_DEMUXER) += $(FATE_IMF)

fate-imf: $(FATE_IMF)

And not bother adding a FATE_IMF-yes variable.


diff --git a/tests/ref/fate/imf-cpl-with-repeat 
b/tests/ref/fate/imf-cpl-with-repeat
new file mode 100644
index 00..38092d542c
--- /dev/null
+++ b/tests/ref/fate/imf-cpl-with-repeat
@@ -0,0 +1,46 @@
+#tb 0: 1/24
+#media_type 0: video
+#codec_id 0: jpeg2000
+#dimensions 0: 1920x1080
+#sar 0: 0/1
+0,  0,  0,1, 5034, 0x29a972c1
+0,  1,  1,1, 7214, 0x704fb452
+0,  2,  2,1, 8496, 0xee9d2692
+0,  3,  3,1, 4917, 0xd35c1a2f
+0,  4,  4,1, 8803, 0xdc01ad91
+0,  5,  5,1, 8426, 0xacc4413a
+0,  6,  6,1, 9626, 0x46865f1e
+0,  7,  7,1, 7409, 0xa21efc69
+0,  8,  8,1, 7409, 0xa21efc69
+0,  9,  9,1, 7409, 0xa21efc69
+0, 10, 10,1, 7409, 0xa21efc69
+0, 11, 11,1, 7409, 0xa21efc69
+0, 12, 12,1, 7409, 0xa21efc69
+0, 13, 13,1, 7409, 0xa21efc69
+0, 14, 14,1, 7409, 0xa21efc69
+0, 15, 15,1, 7409, 0xa21efc69
+0, 16, 16,1, 7409, 0xa21efc69
+0, 17, 17,1, 7409, 0xa21efc69
+0, 18, 18,1, 7409, 0xa21efc69
+0, 19, 19,1, 7409, 0xa21efc69
+0, 20, 20,1, 7409, 0xa21efc69
+0, 21, 21,1, 7409, 0xa21efc69
+0, 22, 22,1, 7409, 0xa21efc69
+0, 23, 23,1, 7409, 0xa21efc69
+0, 24, 24,1, 7409, 0xa21efc69
+0, 25, 25,1, 7409, 0xa21efc69
+0, 26, 26,1, 7409, 0xa21efc69
+0, 27, 27,1, 7409, 0xa21efc69
+0, 28, 28,1, 7409, 0xa21efc69
+0, 29, 29,1, 7409, 0xa21efc69
+0, 30

Re: [FFmpeg-devel] [PATCH v1] avformat/imf: add IMF CPL with repeated resources to FATE

2022-01-02 Thread Pierre-Anthony Lemieux 
On Sun, Jan 2, 2022 at 2:48 PM James Almer  wrote:
>
>
>
> On 1/2/2022 3:54 PM, p...@sandflow.com wrote:
> > From: Pierre-Anthony Lemieux 
> >
> > Signed-off-by: Pierre-Anthony Lemieux 
> > ---
> >
> > Notes:
> >  The `fate-imf-cpl-with-repeat` target currently references online 
> > resources. The following files (<256 kB) will
> >  need to be added to FATE samples:
>
> Please, resend the patch with the test referencing the relevant files
> where they are meant to be inside the fate samples suite folder.

See v2, which adds explicit file paths and makefile dependencies.

>
> >  
> > http://ffmpeg-imf-samples-public.s3-website-us-west-1.amazonaws.com/countdown/ASSETMAP.xml
> >  
> > http://ffmpeg-imf-samples-public.s3-website-us-west-1.amazonaws.com/countdown/CPL_f5095caa-f204-4e1c-8a84-7af48c7ae16b.xml
> >  
> > http://ffmpeg-imf-samples-public.s3-website-us-west-1.amazonaws.com/countdown/PKL_4671220f-c87a-4660-bf2a-6ef848791a2c.xml
> >  
> > http://ffmpeg-imf-samples-public.s3-website-us-west-1.amazonaws.com/countdown/frame-counter.mxf
> >
> >   tests/Makefile |  1 +
> >   tests/fate/imf.mak |  9 ++
> >   tests/ref/fate/imf-cpl-with-repeat | 46 ++
> >   3 files changed, 56 insertions(+)
> >   create mode 100644 tests/fate/imf.mak
> >   create mode 100644 tests/ref/fate/imf-cpl-with-repeat
> >
> > diff --git a/tests/Makefile b/tests/Makefile
> > index 87807ed31f..c4c31ae871 100644
> > --- a/tests/Makefile
> > +++ b/tests/Makefile
> > @@ -153,6 +153,7 @@ include $(SRC_PATH)/tests/fate/hlsenc.mak
> >   include $(SRC_PATH)/tests/fate/hw.mak
> >   include $(SRC_PATH)/tests/fate/id3v2.mak
> >   include $(SRC_PATH)/tests/fate/image.mak
> > +include $(SRC_PATH)/tests/fate/imf.mak
> >   include $(SRC_PATH)/tests/fate/indeo.mak
> >   include $(SRC_PATH)/tests/fate/libavcodec.mak
> >   include $(SRC_PATH)/tests/fate/libavdevice.mak
> > diff --git a/tests/fate/imf.mak b/tests/fate/imf.mak
> > new file mode 100644
> > index 00..1304f04aac
> > --- /dev/null
> > +++ b/tests/fate/imf.mak
> > @@ -0,0 +1,9 @@
> > +
> > +FATE_IMF += fate-imf-cpl-with-repeat
> > +fate-imf-cpl-with-repeat: CMD = framecrc -i 
> > http://ffmpeg-imf-samples-public.s3-website-us-west-1.amazonaws.com/countdown/CPL_f5095caa-f204-4e1c-8a84-7af48c7ae16b.xml
> >  -c:v copy
> > +
> > +FATE_IMF-$(CONFIG_IMF_DEMUXER) += $(FATE_IMF)
> > +
> > +FATE_SAMPLES_AVCONV += $(FATE_IMF-yes)
> > +
> > +fate-imf: $(FATE_IMF-yes)
> > diff --git a/tests/ref/fate/imf-cpl-with-repeat 
> > b/tests/ref/fate/imf-cpl-with-repeat
> > new file mode 100644
> > index 00..38092d542c
> > --- /dev/null
> > +++ b/tests/ref/fate/imf-cpl-with-repeat
> > @@ -0,0 +1,46 @@
> > +#tb 0: 1/24
> > +#media_type 0: video
> > +#codec_id 0: jpeg2000
> > +#dimensions 0: 1920x1080
> > +#sar 0: 0/1
> > +0,  0,  0,1, 5034, 0x29a972c1
> > +0,  1,  1,1, 7214, 0x704fb452
> > +0,  2,  2,1, 8496, 0xee9d2692
> > +0,  3,  3,1, 4917, 0xd35c1a2f
> > +0,  4,  4,1, 8803, 0xdc01ad91
> > +0,  5,  5,1, 8426, 0xacc4413a
> > +0,  6,  6,1, 9626, 0x46865f1e
> > +0,  7,  7,1, 7409, 0xa21efc69
> > +0,  8,  8,1, 7409, 0xa21efc69
> > +0,  9,  9,1, 7409, 0xa21efc69
> > +0, 10, 10,1, 7409, 0xa21efc69
> > +0, 11, 11,1, 7409, 0xa21efc69
> > +0, 12, 12,1, 7409, 0xa21efc69
> > +0, 13, 13,1, 7409, 0xa21efc69
> > +0, 14, 14,1, 7409, 0xa21efc69
> > +0, 15, 15,1, 7409, 0xa21efc69
> > +0, 16, 16,1, 7409, 0xa21efc69
> > +0, 17, 17,1, 7409, 0xa21efc69
> > +0, 18, 18,1, 7409, 0xa21efc69
> > +0, 19, 19,1, 7409, 0xa21efc69
> > +0, 20, 20,1, 7409, 0xa21efc69
> > +0, 21, 21,1, 7409, 0xa21efc69
> > +0, 22, 22,1, 7409, 0xa21efc69
> > +0, 23, 23,1, 7409, 0xa21efc69
> > +0, 24, 24,1, 7409, 0xa21efc69
> > +0, 25, 25,1, 7409, 0xa21efc69
> > +0, 26, 26,1, 7409, 0xa21efc69
> > +0, 27, 27,1, 7409, 0xa21efc69
> > +0, 28, 28,1, 7409, 0xa21efc69
> > +0, 29, 29,1, 7409, 0xa21efc69
> > +0, 30, 30,1, 7409, 0xa21efc69
> > +0, 30, 31,1, 8426, 0xacc4413a
> > +0, 30, 32,1, 9626, 0x46865f1e
> > +0, 30, 33,

[FFmpeg-devel] [PATCH v2] avformat/imf: add IMF CPL with repeated resources to FATE

2022-01-02 Thread pal 
From: Pierre-Anthony Lemieux 

Signed-off-by: Pierre-Anthony Lemieux 
---

Notes:
The `fate-imf-cpl-with-repeat` target requires following files (<256 kB)
to placed under $(TARGET_SAMPLES)/imf/countdown/:

http://ffmpeg-imf-samples-public.s3-website-us-west-1.amazonaws.com/countdown/ASSETMAP.xml

http://ffmpeg-imf-samples-public.s3-website-us-west-1.amazonaws.com/countdown/CPL_f5095caa-f204-4e1c-8a84-7af48c7ae16b.xml

http://ffmpeg-imf-samples-public.s3-website-us-west-1.amazonaws.com/countdown/PKL_4671220f-c87a-4660-bf2a-6ef848791a2c.xml

http://ffmpeg-imf-samples-public.s3-website-us-west-1.amazonaws.com/countdown/frame-counter.mxf

 tests/Makefile |  1 +
 tests/fate/imf.mak | 12 
 tests/ref/fate/imf-cpl-with-repeat | 46 ++
 3 files changed, 59 insertions(+)
 create mode 100644 tests/fate/imf.mak
 create mode 100644 tests/ref/fate/imf-cpl-with-repeat

diff --git a/tests/Makefile b/tests/Makefile
index 87807ed31f..c4c31ae871 100644
--- a/tests/Makefile
+++ b/tests/Makefile
@@ -153,6 +153,7 @@ include $(SRC_PATH)/tests/fate/hlsenc.mak
 include $(SRC_PATH)/tests/fate/hw.mak
 include $(SRC_PATH)/tests/fate/id3v2.mak
 include $(SRC_PATH)/tests/fate/image.mak
+include $(SRC_PATH)/tests/fate/imf.mak
 include $(SRC_PATH)/tests/fate/indeo.mak
 include $(SRC_PATH)/tests/fate/libavcodec.mak
 include $(SRC_PATH)/tests/fate/libavdevice.mak
diff --git a/tests/fate/imf.mak b/tests/fate/imf.mak
new file mode 100644
index 00..c9490d665b
--- /dev/null
+++ b/tests/fate/imf.mak
@@ -0,0 +1,12 @@
+FATE_IMF += fate-imf-cpl-with-repeat
+fate-imf-cpl-with-repeat: 
$(TARGET_SAMPLES)/imf/countdown/CPL_f5095caa-f204-4e1c-8a84-7af48c7ae16b.xml
+fate-imf-cpl-with-repeat: $(TARGET_SAMPLES)/imf/countdown/ASSETMAP.xml
+fate-imf-cpl-with-repeat: $(TARGET_SAMPLES)/imf/countdown/frame-counter.mxf
+fate-imf-cpl-with-repeat: 
$(TARGET_SAMPLES)/imf/countdown/PKL_4671220f-c87a-4660-bf2a-6ef848791a2c.xml
+fate-imf-cpl-with-repeat: CMD = framecrc -i 
$(TARGET_SAMPLES)/imf/countdown/CPL_f5095caa-f204-4e1c-8a84-7af48c7ae16b.xml 
-c:v copy
+
+FATE_IMF-$(CONFIG_IMF_DEMUXER) += $(FATE_IMF)
+
+FATE_SAMPLES_AVCONV += $(FATE_IMF-yes)
+
+fate-imf: $(FATE_IMF-yes)
diff --git a/tests/ref/fate/imf-cpl-with-repeat 
b/tests/ref/fate/imf-cpl-with-repeat
new file mode 100644
index 00..38092d542c
--- /dev/null
+++ b/tests/ref/fate/imf-cpl-with-repeat
@@ -0,0 +1,46 @@
+#tb 0: 1/24
+#media_type 0: video
+#codec_id 0: jpeg2000
+#dimensions 0: 1920x1080
+#sar 0: 0/1
+0,  0,  0,1, 5034, 0x29a972c1
+0,  1,  1,1, 7214, 0x704fb452
+0,  2,  2,1, 8496, 0xee9d2692
+0,  3,  3,1, 4917, 0xd35c1a2f
+0,  4,  4,1, 8803, 0xdc01ad91
+0,  5,  5,1, 8426, 0xacc4413a
+0,  6,  6,1, 9626, 0x46865f1e
+0,  7,  7,1, 7409, 0xa21efc69
+0,  8,  8,1, 7409, 0xa21efc69
+0,  9,  9,1, 7409, 0xa21efc69
+0, 10, 10,1, 7409, 0xa21efc69
+0, 11, 11,1, 7409, 0xa21efc69
+0, 12, 12,1, 7409, 0xa21efc69
+0, 13, 13,1, 7409, 0xa21efc69
+0, 14, 14,1, 7409, 0xa21efc69
+0, 15, 15,1, 7409, 0xa21efc69
+0, 16, 16,1, 7409, 0xa21efc69
+0, 17, 17,1, 7409, 0xa21efc69
+0, 18, 18,1, 7409, 0xa21efc69
+0, 19, 19,1, 7409, 0xa21efc69
+0, 20, 20,1, 7409, 0xa21efc69
+0, 21, 21,1, 7409, 0xa21efc69
+0, 22, 22,1, 7409, 0xa21efc69
+0, 23, 23,1, 7409, 0xa21efc69
+0, 24, 24,1, 7409, 0xa21efc69
+0, 25, 25,1, 7409, 0xa21efc69
+0, 26, 26,1, 7409, 0xa21efc69
+0, 27, 27,1, 7409, 0xa21efc69
+0, 28, 28,1, 7409, 0xa21efc69
+0, 29, 29,1, 7409, 0xa21efc69
+0, 30, 30,1, 7409, 0xa21efc69
+0, 30, 31,1, 8426, 0xacc4413a
+0, 30, 32,1, 9626, 0x46865f1e
+0, 30, 33,1, 5412, 0xf4884a91
+0, 30, 34,1, 9129, 0xbdb77fb3
+0, 30, 35,1,10009, 0xac8a3ec5
+0, 30, 36,1, 7204, 0x4e239746
+0, 30, 37,1, 9413, 0x27620541
+0, 30, 38,1,10725, 0x2feb9589
+0, 30, 39,1, 7101, 0x62159f85
+0, 30, 40,1,10984, 0xa2eb2e49
--

Re: [FFmpeg-devel] [PATCH v1] avformat/imf: add IMF CPL with repeated resources to FATE

2022-01-02 Thread James Almer 




On 1/2/2022 3:54 PM, p...@sandflow.com wrote:

From: Pierre-Anthony Lemieux 

Signed-off-by: Pierre-Anthony Lemieux 
---

Notes:
 The `fate-imf-cpl-with-repeat` target currently references online resources. 
The following files (<256 kB) will
 need to be added to FATE samples:


Please, resend the patch with the test referencing the relevant files 
where they are meant to be inside the fate samples suite folder.



 
http://ffmpeg-imf-samples-public.s3-website-us-west-1.amazonaws.com/countdown/ASSETMAP.xml
 
http://ffmpeg-imf-samples-public.s3-website-us-west-1.amazonaws.com/countdown/CPL_f5095caa-f204-4e1c-8a84-7af48c7ae16b.xml
 
http://ffmpeg-imf-samples-public.s3-website-us-west-1.amazonaws.com/countdown/PKL_4671220f-c87a-4660-bf2a-6ef848791a2c.xml
 
http://ffmpeg-imf-samples-public.s3-website-us-west-1.amazonaws.com/countdown/frame-counter.mxf

  tests/Makefile |  1 +
  tests/fate/imf.mak |  9 ++
  tests/ref/fate/imf-cpl-with-repeat | 46 ++
  3 files changed, 56 insertions(+)
  create mode 100644 tests/fate/imf.mak
  create mode 100644 tests/ref/fate/imf-cpl-with-repeat

diff --git a/tests/Makefile b/tests/Makefile
index 87807ed31f..c4c31ae871 100644
--- a/tests/Makefile
+++ b/tests/Makefile
@@ -153,6 +153,7 @@ include $(SRC_PATH)/tests/fate/hlsenc.mak
  include $(SRC_PATH)/tests/fate/hw.mak
  include $(SRC_PATH)/tests/fate/id3v2.mak
  include $(SRC_PATH)/tests/fate/image.mak
+include $(SRC_PATH)/tests/fate/imf.mak
  include $(SRC_PATH)/tests/fate/indeo.mak
  include $(SRC_PATH)/tests/fate/libavcodec.mak
  include $(SRC_PATH)/tests/fate/libavdevice.mak
diff --git a/tests/fate/imf.mak b/tests/fate/imf.mak
new file mode 100644
index 00..1304f04aac
--- /dev/null
+++ b/tests/fate/imf.mak
@@ -0,0 +1,9 @@
+
+FATE_IMF += fate-imf-cpl-with-repeat
+fate-imf-cpl-with-repeat: CMD = framecrc -i 
http://ffmpeg-imf-samples-public.s3-website-us-west-1.amazonaws.com/countdown/CPL_f5095caa-f204-4e1c-8a84-7af48c7ae16b.xml
 -c:v copy
+
+FATE_IMF-$(CONFIG_IMF_DEMUXER) += $(FATE_IMF)
+
+FATE_SAMPLES_AVCONV += $(FATE_IMF-yes)
+
+fate-imf: $(FATE_IMF-yes)
diff --git a/tests/ref/fate/imf-cpl-with-repeat 
b/tests/ref/fate/imf-cpl-with-repeat
new file mode 100644
index 00..38092d542c
--- /dev/null
+++ b/tests/ref/fate/imf-cpl-with-repeat
@@ -0,0 +1,46 @@
+#tb 0: 1/24
+#media_type 0: video
+#codec_id 0: jpeg2000
+#dimensions 0: 1920x1080
+#sar 0: 0/1
+0,  0,  0,1, 5034, 0x29a972c1
+0,  1,  1,1, 7214, 0x704fb452
+0,  2,  2,1, 8496, 0xee9d2692
+0,  3,  3,1, 4917, 0xd35c1a2f
+0,  4,  4,1, 8803, 0xdc01ad91
+0,  5,  5,1, 8426, 0xacc4413a
+0,  6,  6,1, 9626, 0x46865f1e
+0,  7,  7,1, 7409, 0xa21efc69
+0,  8,  8,1, 7409, 0xa21efc69
+0,  9,  9,1, 7409, 0xa21efc69
+0, 10, 10,1, 7409, 0xa21efc69
+0, 11, 11,1, 7409, 0xa21efc69
+0, 12, 12,1, 7409, 0xa21efc69
+0, 13, 13,1, 7409, 0xa21efc69
+0, 14, 14,1, 7409, 0xa21efc69
+0, 15, 15,1, 7409, 0xa21efc69
+0, 16, 16,1, 7409, 0xa21efc69
+0, 17, 17,1, 7409, 0xa21efc69
+0, 18, 18,1, 7409, 0xa21efc69
+0, 19, 19,1, 7409, 0xa21efc69
+0, 20, 20,1, 7409, 0xa21efc69
+0, 21, 21,1, 7409, 0xa21efc69
+0, 22, 22,1, 7409, 0xa21efc69
+0, 23, 23,1, 7409, 0xa21efc69
+0, 24, 24,1, 7409, 0xa21efc69
+0, 25, 25,1, 7409, 0xa21efc69
+0, 26, 26,1, 7409, 0xa21efc69
+0, 27, 27,1, 7409, 0xa21efc69
+0, 28, 28,1, 7409, 0xa21efc69
+0, 29, 29,1, 7409, 0xa21efc69
+0, 30, 30,1, 7409, 0xa21efc69
+0, 30, 31,1, 8426, 0xacc4413a
+0, 30, 32,1, 9626, 0x46865f1e
+0, 30, 33,1, 5412, 0xf4884a91
+0, 30, 34,1, 9129, 0xbdb77fb3
+0, 30, 35,1,10009, 0xac8a3ec5
+0, 30, 36,1, 7204, 0x4e239746
+0, 30, 37,1, 9413, 0x27620541
+0, 30, 38,1,10725, 0x2feb9589
+0, 30, 39,1, 7101, 0x62159f85
+0, 30, 40,1,10984, 0xa2eb2e49

___
ffmpeg-devel mailing list
ffmpeg-

Re: [FFmpeg-devel] [RFC/PATCH 1/2] lavf: add a flag for experimental (de)muxers

2022-01-02 Thread Michael Niedermayer 
On Sun, Jan 02, 2022 at 06:46:04PM +0100, Anton Khirnov wrote:
> ---
>  doc/APIchanges | 3 +++
>  libavformat/avformat.h | 7 +++
>  libavformat/format.c   | 2 ++
>  libavformat/version.h  | 2 +-
>  4 files changed, 13 insertions(+), 1 deletion(-)

patchset LGTM

thx

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

During times of universal deceit, telling the truth becomes a
revolutionary act. -- George Orwell


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] 5.0 release

2022-01-02 Thread Michael Niedermayer 
On Sun, Jan 02, 2022 at 11:29:18PM +0100, Michael Niedermayer wrote:
> On Sun, Jan 02, 2022 at 07:12:54PM +0100, Lynne wrote:
> > 2 Jan 2022, 18:11 by mich...@niedermayer.cc:
> > 
> > > On Sun, Jan 02, 2022 at 05:28:24PM +0100, Lynne wrote:
> > >
> > >> 2 Jan 2022, 16:52 by z...@zanevaniperen.com:
> > >>
> > >> >
> > >> >
> > >> > On 3/1/22 01:09, James Almer wrote:
> > >> >
> > >>  Reverting something in the release branch is already going to be 
> > >>  dirty
> > >>  no matter what, because we do a minor bump to ensure the release 
> > >>  has its
> > >>  own soname. Right now that'd mean 5.0 will be lavf 59.13, while 
> > >>  lacking
> > >>  a demuxer available in lavf 59.12
> > >> 
> > >> >>>
> > >> >>> Depends on what you mean by "lacking a demuxer"... One (hacky) 
> > >> >>> option would
> > >> >>> be to replace it with a stub implementation that always fails.
> > >> >>>
> > >> >>
> > >> >> Or tag it as experimental.
> > >> >>
> > >> >
> > >> > That's much better. If we're not willing to wait, then I suggest we do 
> > >> > this.
> > >> >
> > >>
> > >> I'd rather have it reverted in master, branch 5.0, and add it back and 
> > >> bump minor
> > >> again. I'm not willing to wait for a month to get fuzzing, the release 
> > >> is way
> > >> overdue as-is. We generally don't put experimental on decoders or 
> > >> demuxers.
> > >>
> > >
> > > I think if we dont want it in the release either as you suggest
> > > revert in master or mark as experimental in master before the branch
> > >
> > > having special cases in the release branch feels a bit iffy
> > >
> > 
> > Okay, I can live with an experimental flag on it for the time being.
> 
> Ok, please add that experimental flag then

disregard that, just saw antons patch

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

Re: [FFmpeg-devel] 5.0 release

2022-01-02 Thread Michael Niedermayer 
On Sun, Jan 02, 2022 at 07:12:54PM +0100, Lynne wrote:
> 2 Jan 2022, 18:11 by mich...@niedermayer.cc:
> 
> > On Sun, Jan 02, 2022 at 05:28:24PM +0100, Lynne wrote:
> >
> >> 2 Jan 2022, 16:52 by z...@zanevaniperen.com:
> >>
> >> >
> >> >
> >> > On 3/1/22 01:09, James Almer wrote:
> >> >
> >>  Reverting something in the release branch is already going to be dirty
> >>  no matter what, because we do a minor bump to ensure the release has 
> >>  its
> >>  own soname. Right now that'd mean 5.0 will be lavf 59.13, while 
> >>  lacking
> >>  a demuxer available in lavf 59.12
> >> 
> >> >>>
> >> >>> Depends on what you mean by "lacking a demuxer"... One (hacky) option 
> >> >>> would
> >> >>> be to replace it with a stub implementation that always fails.
> >> >>>
> >> >>
> >> >> Or tag it as experimental.
> >> >>
> >> >
> >> > That's much better. If we're not willing to wait, then I suggest we do 
> >> > this.
> >> >
> >>
> >> I'd rather have it reverted in master, branch 5.0, and add it back and 
> >> bump minor
> >> again. I'm not willing to wait for a month to get fuzzing, the release is 
> >> way
> >> overdue as-is. We generally don't put experimental on decoders or demuxers.
> >>
> >
> > I think if we dont want it in the release either as you suggest
> > revert in master or mark as experimental in master before the branch
> >
> > having special cases in the release branch feels a bit iffy
> >
> 
> Okay, I can live with an experimental flag on it for the time being.

Ok, please add that experimental flag then

thx

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

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


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

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

Re: [FFmpeg-devel] [PATCH 1/5] avformat/aviobuf: set AVIOContext->error on bprint buffer ENOMEM

2022-01-02 Thread Marton Balint 




On Fri, 31 Dec 2021, Marton Balint wrote:




On Fri, 31 Dec 2021, Andreas Rheinhardt wrote:


 Marton Balint:

 This makes sure the error condition is kept in AVIOContext even if the
 user
 does not check the return value of avio_read_to_bprint or
 ff_read_line_to_bprint.

 Signed-off-by: Marton Balint 
 ---
  libavformat/aviobuf.c | 8 ++--
  1 file changed, 6 insertions(+), 2 deletions(-)

 diff --git a/libavformat/aviobuf.c b/libavformat/aviobuf.c
 index 29d4bd7510..6f8a822ee3 100644
 --- a/libavformat/aviobuf.c
 +++ b/libavformat/aviobuf.c
 @@ -875,8 +875,10 @@ static int64_t
 read_string_to_bprint_overwrite(AVIOContext *s, AVBPrint *bp,
  if (ret < 0)
  return ret;

 -if (!av_bprint_is_complete(bp))
 +if (!av_bprint_is_complete(bp)) {
 +s->error = AVERROR(ENOMEM);
  return AVERROR(ENOMEM);
 +}

  return bp->len;
 }
 @@ -1351,8 +1353,10 @@ int avio_read_to_bprint(AVIOContext *h, AVBPrint
 *pb, size_t max_size)
  if (ret <= 0)
  return ret;
  av_bprint_append_data(pb, buf, ret);
 -if (!av_bprint_is_complete(pb))
 +if (!av_bprint_is_complete(pb)) {
 +h->error = AVERROR(ENOMEM);
  return AVERROR(ENOMEM);
 +}
  max_size -= ret;
  }
  return 0;



 I don't really see the point of this: It is not a real read error that
 should stick to the AVIOContext (which can still be used afterwards
 without any issue).
 If the user does not check the errors, then the user
 has no one to blame but himself for missing errors.


AVIO read/write behaviour is to store IO errors in the context so the user 
does not have to check for them in every call. It is not well documented 
which calls should be checked always, so the user might be under the 
impression that errors during read/write may be checked sometime later.


Admittedly, ENOMEM is not an IO error, but I think it is better to store that 
as well in the context to keep the behaviour consistent, because in case of 
ENOMEM avio_read_to_bprint reads and drops undefined amount of data, so the 
context will also be in an undefined state.


Other possibilities:
- make avio_read_to_bprint read all the data regardless of AVBPrint fullness
 - mark avio_read_to_bprint av_warn_unused_result.
 - both :)

But these also forces the user to check return values... So I kind of like my 
original approach better, because it maintains avio_read/write call behaviour 
that it is safe to check errors sometime later.


Any more comments about this or the rest of the series? I plan to apply it 
tomorrow.


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

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

Re: [FFmpeg-devel] [PATCH v9 4/6] lavc: Implement Dolby Vision RPU parsing

2022-01-02 Thread Hendrik Leppkes 
Andreas Rheinhardt  schrieb am So., 2. Jan.
2022, 05:18:

> Niklas Haas:
> > From: Niklas Haas 
> >
> > Based on a mixture of guesswork, partial documentation in patents, and
> > reverse engineering of real-world samples. Confirmed working for all the
> > samples I've thrown at it.
> >
> > Contains some annoying machinery to persist these values in between
> > frames, which is needed in theory even though I've never actually seen a
> > sample that relies on it in practice. May or may not work.
> >
> > Since the distinction matters greatly for parsing the color matrix
> > values, this includes a small helper function to guess the right profile
> > from the RPU itself in case the user has forgotten to forward the dovi
> > configuration record to the decoder. (Which in practice, only ffmpeg.c
> > and ffplay do..)
> >
> > Notable omissions / deviations:
> > - CRC32 verification. This is based on the MPEG2 CRC32 type, which does
> >   not seem to be implemented in lavu. (And I don't care enough to do so)
> > - Linear interpolation support. Nothing documents this (beyond its
> >   existence) and no samples use it, so impossible to implement.
> > - All of the extension metadata blocks, but these contain values that
> >   seem largely congruent with ST2094, HDR10, or other existing forms of
> >   side data, so I will defer parsing/attaching them to a future commit.
> > - The patent describes a mechanism for predicting coefficients from
> >   previous RPUs, but the bit for the flag whether to use the
> >   prediction deltas or signal entirely new coefficients does not seem to
> >   be present in actual RPUs, so we ignore this subsystem entirely.
> > - In the patent's spec, the NLQ subsystem also loops over
> >   num_nlq_pivots, but even in the patent the number is hard-coded to one
> >   iteration rather than signalled. So we only store one set of coefs.
> >
> > Heavily influenced by https://github.com/quietvoid/dovi_tool
> > Documentation drawn from US Patent 10,701,399 B2 and ETSI GS CCM 001
> >
> > Signed-off-by: Niklas Haas 
> > ---
> >  configure |   2 +
> >  libavcodec/Makefile   |   1 +
> >  libavcodec/dovi_rpu.c | 430 ++
> >  libavcodec/dovi_rpu.h |  71 +++
> >  4 files changed, 504 insertions(+)
> >  create mode 100644 libavcodec/dovi_rpu.c
> >  create mode 100644 libavcodec/dovi_rpu.h
> >
> > diff --git a/configure b/configure
> > index 0ccd3bda11..68658a847f 100755
> > --- a/configure
> > +++ b/configure
> > @@ -2434,6 +2434,7 @@ CONFIG_EXTRA="
> >  cbs_vp9
> >  dirac_parse
> >  dnn
> > +dovi_rpu
> >  dvprofile
> >  exif
> >  faandct
> > @@ -2706,6 +2707,7 @@ cbs_mpeg2_select="cbs"
> >  cbs_vp9_select="cbs"
> >  dct_select="rdft"
> >  dirac_parse_select="golomb"
> > +dovi_rpu_select="golomb"
> >  dnn_suggest="libtensorflow libopenvino"
> >  dnn_deps="avformat swscale"
> >  error_resilience_select="me_cmp"
> > diff --git a/libavcodec/Makefile b/libavcodec/Makefile
> > index fb90ecea84..7364c7a91f 100644
> > --- a/libavcodec/Makefile
> > +++ b/libavcodec/Makefile
> > @@ -77,6 +77,7 @@ OBJS-$(CONFIG_CBS_MPEG2)   += cbs_mpeg2.o
> >  OBJS-$(CONFIG_CBS_VP9) += cbs_vp9.o
> >  OBJS-$(CONFIG_CRYSTALHD)   += crystalhd.o
> >  OBJS-$(CONFIG_DCT) += dct.o dct32_fixed.o
> dct32_float.o
> > +OBJS-$(CONFIG_DOVI_RPU)+= dovi_rpu.o
> >  OBJS-$(CONFIG_ERROR_RESILIENCE)+= error_resilience.o
> >  OBJS-$(CONFIG_EXIF)+= exif.o tiff_common.o
> >  OBJS-$(CONFIG_FAANDCT) += faandct.o
> > diff --git a/libavcodec/dovi_rpu.c b/libavcodec/dovi_rpu.c
> > new file mode 100644
> > index 00..fc2e1fb2a1
> > --- /dev/null
> > +++ b/libavcodec/dovi_rpu.c
> > @@ -0,0 +1,430 @@
> > +/*
> > + * Dolby Vision RPU decoder
> > + *
> > + * Copyright (C) 2021 Jan Ekström
> > + * Copyright (C) 2021 Niklas Haas
> > + *
> > + * This file is part of FFmpeg.
> > + *
> > + * FFmpeg is free software; you can redistribute it and/or
> > + * modify it under the terms of the GNU Lesser General Public
> > + * License as published by the Free Software Foundation; either
> > + * version 2.1 of the License, or (at your option) any later version.
> > + *
> > + * FFmpeg is distributed in the hope that it will be useful,
> > + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> > + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
> > + * Lesser General Public License for more details.
> > + *
> > + * You should have received a copy of the GNU Lesser General Public
> > + * License along with FFmpeg; if not, write to the Free Software
> > + * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA
> 02110-1301 USA
> > + */
> > +
> > +#include "libavutil/buffer.h"
> > +
> > +#include "dovi_rpu.h"
> > +#include "golomb.h"
> > +#include "get_bits.h"
> > +
> > +enum {
> > +RPU_COEFF_FIXED = 0,
> > +RPU_COEFF_FLOAT = 1,

Re: [FFmpeg-devel] [PATCH v9 4/6] lavc: Implement Dolby Vision RPU parsing

2022-01-02 Thread Hendrik Leppkes 
James Almer  schrieb am So., 2. Jan. 2022, 13:46:

> On 1/2/2022 1:18 AM, Andreas Rheinhardt wrote:
> > Niklas Haas:
> >> From: Niklas Haas 
> >>
> >> Based on a mixture of guesswork, partial documentation in patents, and
> >> reverse engineering of real-world samples. Confirmed working for all the
> >> samples I've thrown at it.
> >>
> >> Contains some annoying machinery to persist these values in between
> >> frames, which is needed in theory even though I've never actually seen a
> >> sample that relies on it in practice. May or may not work.
> >>
> >> Since the distinction matters greatly for parsing the color matrix
> >> values, this includes a small helper function to guess the right profile
> >> from the RPU itself in case the user has forgotten to forward the dovi
> >> configuration record to the decoder. (Which in practice, only ffmpeg.c
> >> and ffplay do..)
> >>
> >> Notable omissions / deviations:
> >> - CRC32 verification. This is based on the MPEG2 CRC32 type, which does
> >>not seem to be implemented in lavu. (And I don't care enough to do
> so)
> >> - Linear interpolation support. Nothing documents this (beyond its
> >>existence) and no samples use it, so impossible to implement.
> >> - All of the extension metadata blocks, but these contain values that
> >>seem largely congruent with ST2094, HDR10, or other existing forms of
> >>side data, so I will defer parsing/attaching them to a future commit.
> >> - The patent describes a mechanism for predicting coefficients from
> >>previous RPUs, but the bit for the flag whether to use the
> >>prediction deltas or signal entirely new coefficients does not seem
> to
> >>be present in actual RPUs, so we ignore this subsystem entirely.
> >> - In the patent's spec, the NLQ subsystem also loops over
> >>num_nlq_pivots, but even in the patent the number is hard-coded to
> one
> >>iteration rather than signalled. So we only store one set of coefs.
> >>
> >> Heavily influenced by https://github.com/quietvoid/dovi_tool
> >> Documentation drawn from US Patent 10,701,399 B2 and ETSI GS CCM 001
> >>
> >> Signed-off-by: Niklas Haas 
> >> ---
> >>   configure |   2 +
> >>   libavcodec/Makefile   |   1 +
> >>   libavcodec/dovi_rpu.c | 430 ++
> >>   libavcodec/dovi_rpu.h |  71 +++
> >>   4 files changed, 504 insertions(+)
> >>   create mode 100644 libavcodec/dovi_rpu.c
> >>   create mode 100644 libavcodec/dovi_rpu.h
> >>
> >> diff --git a/configure b/configure
> >> index 0ccd3bda11..68658a847f 100755
> >> --- a/configure
> >> +++ b/configure
> >> @@ -2434,6 +2434,7 @@ CONFIG_EXTRA="
> >>   cbs_vp9
> >>   dirac_parse
> >>   dnn
> >> +dovi_rpu
> >>   dvprofile
> >>   exif
> >>   faandct
> >> @@ -2706,6 +2707,7 @@ cbs_mpeg2_select="cbs"
> >>   cbs_vp9_select="cbs"
> >>   dct_select="rdft"
> >>   dirac_parse_select="golomb"
> >> +dovi_rpu_select="golomb"
> >>   dnn_suggest="libtensorflow libopenvino"
> >>   dnn_deps="avformat swscale"
> >>   error_resilience_select="me_cmp"
> >> diff --git a/libavcodec/Makefile b/libavcodec/Makefile
> >> index fb90ecea84..7364c7a91f 100644
> >> --- a/libavcodec/Makefile
> >> +++ b/libavcodec/Makefile
> >> @@ -77,6 +77,7 @@ OBJS-$(CONFIG_CBS_MPEG2)   += cbs_mpeg2.o
> >>   OBJS-$(CONFIG_CBS_VP9) += cbs_vp9.o
> >>   OBJS-$(CONFIG_CRYSTALHD)   += crystalhd.o
> >>   OBJS-$(CONFIG_DCT) += dct.o dct32_fixed.o
> dct32_float.o
> >> +OBJS-$(CONFIG_DOVI_RPU)+= dovi_rpu.o
> >>   OBJS-$(CONFIG_ERROR_RESILIENCE)+= error_resilience.o
> >>   OBJS-$(CONFIG_EXIF)+= exif.o tiff_common.o
> >>   OBJS-$(CONFIG_FAANDCT) += faandct.o
> >> diff --git a/libavcodec/dovi_rpu.c b/libavcodec/dovi_rpu.c
> >> new file mode 100644
> >> index 00..fc2e1fb2a1
> >> --- /dev/null
> >> +++ b/libavcodec/dovi_rpu.c
> >> @@ -0,0 +1,430 @@
> >> +/*
> >> + * Dolby Vision RPU decoder
> >> + *
> >> + * Copyright (C) 2021 Jan Ekström
> >> + * Copyright (C) 2021 Niklas Haas
> >> + *
> >> + * 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
> >> + */
> >> +
> >> +#

[FFmpeg-devel] [PATCH v1] avformat/imf: add IMF CPL with repeated resources to FATE

2022-01-02 Thread pal 
From: Pierre-Anthony Lemieux 

Signed-off-by: Pierre-Anthony Lemieux 
---

Notes:
The `fate-imf-cpl-with-repeat` target currently references online 
resources. The following files (<256 kB) will
need to be added to FATE samples:

http://ffmpeg-imf-samples-public.s3-website-us-west-1.amazonaws.com/countdown/ASSETMAP.xml

http://ffmpeg-imf-samples-public.s3-website-us-west-1.amazonaws.com/countdown/CPL_f5095caa-f204-4e1c-8a84-7af48c7ae16b.xml

http://ffmpeg-imf-samples-public.s3-website-us-west-1.amazonaws.com/countdown/PKL_4671220f-c87a-4660-bf2a-6ef848791a2c.xml

http://ffmpeg-imf-samples-public.s3-website-us-west-1.amazonaws.com/countdown/frame-counter.mxf

 tests/Makefile |  1 +
 tests/fate/imf.mak |  9 ++
 tests/ref/fate/imf-cpl-with-repeat | 46 ++
 3 files changed, 56 insertions(+)
 create mode 100644 tests/fate/imf.mak
 create mode 100644 tests/ref/fate/imf-cpl-with-repeat

diff --git a/tests/Makefile b/tests/Makefile
index 87807ed31f..c4c31ae871 100644
--- a/tests/Makefile
+++ b/tests/Makefile
@@ -153,6 +153,7 @@ include $(SRC_PATH)/tests/fate/hlsenc.mak
 include $(SRC_PATH)/tests/fate/hw.mak
 include $(SRC_PATH)/tests/fate/id3v2.mak
 include $(SRC_PATH)/tests/fate/image.mak
+include $(SRC_PATH)/tests/fate/imf.mak
 include $(SRC_PATH)/tests/fate/indeo.mak
 include $(SRC_PATH)/tests/fate/libavcodec.mak
 include $(SRC_PATH)/tests/fate/libavdevice.mak
diff --git a/tests/fate/imf.mak b/tests/fate/imf.mak
new file mode 100644
index 00..1304f04aac
--- /dev/null
+++ b/tests/fate/imf.mak
@@ -0,0 +1,9 @@
+
+FATE_IMF += fate-imf-cpl-with-repeat
+fate-imf-cpl-with-repeat: CMD = framecrc -i 
http://ffmpeg-imf-samples-public.s3-website-us-west-1.amazonaws.com/countdown/CPL_f5095caa-f204-4e1c-8a84-7af48c7ae16b.xml
 -c:v copy
+
+FATE_IMF-$(CONFIG_IMF_DEMUXER) += $(FATE_IMF)
+
+FATE_SAMPLES_AVCONV += $(FATE_IMF-yes)
+
+fate-imf: $(FATE_IMF-yes)
diff --git a/tests/ref/fate/imf-cpl-with-repeat 
b/tests/ref/fate/imf-cpl-with-repeat
new file mode 100644
index 00..38092d542c
--- /dev/null
+++ b/tests/ref/fate/imf-cpl-with-repeat
@@ -0,0 +1,46 @@
+#tb 0: 1/24
+#media_type 0: video
+#codec_id 0: jpeg2000
+#dimensions 0: 1920x1080
+#sar 0: 0/1
+0,  0,  0,1, 5034, 0x29a972c1
+0,  1,  1,1, 7214, 0x704fb452
+0,  2,  2,1, 8496, 0xee9d2692
+0,  3,  3,1, 4917, 0xd35c1a2f
+0,  4,  4,1, 8803, 0xdc01ad91
+0,  5,  5,1, 8426, 0xacc4413a
+0,  6,  6,1, 9626, 0x46865f1e
+0,  7,  7,1, 7409, 0xa21efc69
+0,  8,  8,1, 7409, 0xa21efc69
+0,  9,  9,1, 7409, 0xa21efc69
+0, 10, 10,1, 7409, 0xa21efc69
+0, 11, 11,1, 7409, 0xa21efc69
+0, 12, 12,1, 7409, 0xa21efc69
+0, 13, 13,1, 7409, 0xa21efc69
+0, 14, 14,1, 7409, 0xa21efc69
+0, 15, 15,1, 7409, 0xa21efc69
+0, 16, 16,1, 7409, 0xa21efc69
+0, 17, 17,1, 7409, 0xa21efc69
+0, 18, 18,1, 7409, 0xa21efc69
+0, 19, 19,1, 7409, 0xa21efc69
+0, 20, 20,1, 7409, 0xa21efc69
+0, 21, 21,1, 7409, 0xa21efc69
+0, 22, 22,1, 7409, 0xa21efc69
+0, 23, 23,1, 7409, 0xa21efc69
+0, 24, 24,1, 7409, 0xa21efc69
+0, 25, 25,1, 7409, 0xa21efc69
+0, 26, 26,1, 7409, 0xa21efc69
+0, 27, 27,1, 7409, 0xa21efc69
+0, 28, 28,1, 7409, 0xa21efc69
+0, 29, 29,1, 7409, 0xa21efc69
+0, 30, 30,1, 7409, 0xa21efc69
+0, 30, 31,1, 8426, 0xacc4413a
+0, 30, 32,1, 9626, 0x46865f1e
+0, 30, 33,1, 5412, 0xf4884a91
+0, 30, 34,1, 9129, 0xbdb77fb3
+0, 30, 35,1,10009, 0xac8a3ec5
+0, 30, 36,1, 7204, 0x4e239746
+0, 30, 37,1, 9413, 0x27620541
+0, 30, 38,1,10725, 0x2feb9589
+0, 30, 39,1, 7101, 0x62159f85
+0, 30, 40,1,10984, 0xa2eb2e49
-- 
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".

Re: [FFmpeg-devel] [PATCH] avfilter/vf_libvmaf: update filter for libvmaf v2.0.0

2022-01-02 Thread Kyle Swanson 
Hi,

On Thu, Dec 30, 2021 at 5:03 PM Kyle Swanson  wrote:
>
> Hi,
>
> On Sat, Dec 25, 2021 at 1:24 AM Paul B Mahol  wrote:
> >
> > On Fri, Dec 24, 2021 at 9:52 PM Kyle Swanson  wrote:
> >
> > > Hi,
> > >
> > > Never followed through on this vf_libvmaf patch from last June, and
> > > I've had several people asking about its status lately. Rebased patch
> > > attached. It's been a while, so I guess let's start the review again.
> > > Would be nice if we could get this in before 5.0.
> > >
> > >
> > Please read old reviews and follow them.
> > There is no exceptions.
>
> Thank you, I've taken all of Mortiz's comments. Updated patch attached.
>
> Thanks,
> Kyle

Unless there are any more reviews or questions, I will push soon.

Thanks,
Kyle
___
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/PATCH 1/2] lavf: add a flag for experimental (de)muxers

2022-01-02 Thread Lynne 
2 Jan 2022, 18:46 by an...@khirnov.net:

> ---
>  doc/APIchanges | 3 +++
>  libavformat/avformat.h | 7 +++
>  libavformat/format.c   | 2 ++
>  libavformat/version.h  | 2 +-
>  4 files changed, 13 insertions(+), 1 deletion(-)
>
> diff --git a/doc/APIchanges b/doc/APIchanges
> index 670a59329e..29c235630e 100644
> --- a/doc/APIchanges
> +++ b/doc/APIchanges
> @@ -14,6 +14,9 @@ libavutil: 2021-04-27
>  
>  API changes, most recent first:
>  
> +2022-01-xx - xx - lavf 59.13.100 - avformat.h
> +  Add AVFMT_EXPERIMENTAL flag.
> +
>  2021-12-xx - xx - lavu 57.13.100 - hwcontext_videotoolbox.h
>  Add av_vt_pixbuf_set_attachments
>  
> diff --git a/libavformat/avformat.h b/libavformat/avformat.h
> index 70b36d7682..6ce367e854 100644
> --- a/libavformat/avformat.h
> +++ b/libavformat/avformat.h
> @@ -463,6 +463,13 @@ typedef struct AVProbeData {
>  /// Demuxer will use avio_open, no opened file should be provided by the 
> caller.
>  #define AVFMT_NOFILE0x0001
>  #define AVFMT_NEEDNUMBER0x0002 /**< Needs '%d' in filename. */
> +/**
> + * The muxer/demuxer is experimental and should be used with caution.
> + *
> + * - demuxers: will not be selected automatically by probing, must be 
> specified
> + * explicitly.
> + */
> +#define AVFMT_EXPERIMENTAL  0x0004
>  #define AVFMT_SHOW_IDS  0x0008 /**< Show format stream IDs numbers. */
>  #define AVFMT_GLOBALHEADER  0x0040 /**< Format wants global header. */
>  #define AVFMT_NOTIMESTAMPS  0x0080 /**< Format does not need / have any 
> timestamps. */
> diff --git a/libavformat/format.c b/libavformat/format.c
> index 387627009e..52b85c16a2 100644
> --- a/libavformat/format.c
> +++ b/libavformat/format.c
> @@ -158,6 +158,8 @@ const AVInputFormat *av_probe_input_format3(const 
> AVProbeData *pd,
>  }
>  
>  while ((fmt1 = av_demuxer_iterate(&i))) {
> +if (fmt1->flags & AVFMT_EXPERIMENTAL)
> +continue;
>  if (!is_opened == !(fmt1->flags & AVFMT_NOFILE) && strcmp(fmt1->name, 
> "image2"))
>  continue;
>  score = 0;
> diff --git a/libavformat/version.h b/libavformat/version.h
> index 917b9ffa5d..29dcce352b 100644
> --- a/libavformat/version.h
> +++ b/libavformat/version.h
> @@ -32,7 +32,7 @@
>  // Major bumping may affect Ticket5467, 5421, 5451(compatibility with 
> Chromium)
>  // Also please add any ticket numbers that you believe might be affected here
>  #define LIBAVFORMAT_VERSION_MAJOR  59
> -#define LIBAVFORMAT_VERSION_MINOR  12
> +#define LIBAVFORMAT_VERSION_MINOR  13
>  #define LIBAVFORMAT_VERSION_MICRO 100
>  
>  #define LIBAVFORMAT_VERSION_INT AV_VERSION_INT(LIBAVFORMAT_VERSION_MAJOR, \
>

You should add it in libavformat/options_table.h too.
Apart from that, it looks fine. Should we move muxers previously
behind strict_std_compliance > experimental like scd behind
this flag or would that be an API breakage?
___
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] GitHub Integration

2022-01-02 Thread Soft Works 



> -Original Message-
> From: ffmpeg-devel  On Behalf Of Lynne
> Sent: Sunday, January 2, 2022 3:04 PM
> To: FFmpeg development discussions and patches 
> Subject: Re: [FFmpeg-devel] GitHub Integration
> 
> 2 Jan 2022, 04:28 by softwo...@hotmail.com:
> 
> >
> >
> >> -Original Message-
> >> From: ffmpeg-devel  On Behalf Of Soft
> Works
> >> Sent: Tuesday, December 28, 2021 10:58 PM
> >> To: FFmpeg development discussions and patches 
> >> Subject: Re: [FFmpeg-devel] GitHub Integration
> >>
> >> One component of the GitHub "Bridge" is a mirror of the ffmpeg-devel
> >> mailing list as a Git repository which provides a web interfaces, can be
> >> cloned via Git and can also be accessed from Atom feed readers.
> >> This allows to follow the mailing list without subscribing. The web UI
> >> might not be everybody's taste, though. It's the same that is used for
> >> Linux kernel mailing lists (https://lore.kernel.org/git/).
> >> I had to set this up as it's a requirement for the GitHub "Bridge", but
> >> maybe it's useful for someone in other ways:
> >>
> >> https://master.gitmailbox.com/ffmpegdev/
> >>
> >
> >
> > I have just ACTIVATED patch submission via GitHub and submitted the first
> > patch through this method.
> >
> > Pull requests can be created in this repository (for now):
> >
> > https://github.com/ffstaging/FFmpeg
> >
> >
> > What's not nice is that the submitted e-mail shows "ffmpegagent" as sender
> > and patchwork is showing it under that name as well.
> >
> > We'll need to see how this can be improved.
> >
> 
> I don't like it. Can't it use the author's name for emails?

I don't like this either. I'll try to find a way.

sw 

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

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

Re: [FFmpeg-devel] 5.0 release

2022-01-02 Thread Lynne 
2 Jan 2022, 18:11 by mich...@niedermayer.cc:

> On Sun, Jan 02, 2022 at 05:28:24PM +0100, Lynne wrote:
>
>> 2 Jan 2022, 16:52 by z...@zanevaniperen.com:
>>
>> >
>> >
>> > On 3/1/22 01:09, James Almer wrote:
>> >
>>  Reverting something in the release branch is already going to be dirty
>>  no matter what, because we do a minor bump to ensure the release has its
>>  own soname. Right now that'd mean 5.0 will be lavf 59.13, while lacking
>>  a demuxer available in lavf 59.12
>> 
>> >>>
>> >>> Depends on what you mean by "lacking a demuxer"... One (hacky) option 
>> >>> would
>> >>> be to replace it with a stub implementation that always fails.
>> >>>
>> >>
>> >> Or tag it as experimental.
>> >>
>> >
>> > That's much better. If we're not willing to wait, then I suggest we do 
>> > this.
>> >
>>
>> I'd rather have it reverted in master, branch 5.0, and add it back and bump 
>> minor
>> again. I'm not willing to wait for a month to get fuzzing, the release is way
>> overdue as-is. We generally don't put experimental on decoders or demuxers.
>>
>
> I think if we dont want it in the release either as you suggest
> revert in master or mark as experimental in master before the branch
>
> having special cases in the release branch feels a bit iffy
>

Okay, I can live with an experimental flag on it for the time being.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

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

[FFmpeg-devel] [RFC/PATCH 1/2] lavf: add a flag for experimental (de)muxers

2022-01-02 Thread Anton Khirnov 
---
 doc/APIchanges | 3 +++
 libavformat/avformat.h | 7 +++
 libavformat/format.c   | 2 ++
 libavformat/version.h  | 2 +-
 4 files changed, 13 insertions(+), 1 deletion(-)

diff --git a/doc/APIchanges b/doc/APIchanges
index 670a59329e..29c235630e 100644
--- a/doc/APIchanges
+++ b/doc/APIchanges
@@ -14,6 +14,9 @@ libavutil: 2021-04-27
 
 API changes, most recent first:
 
+2022-01-xx - xx - lavf 59.13.100 - avformat.h
+  Add AVFMT_EXPERIMENTAL flag.
+
 2021-12-xx - xx - lavu 57.13.100 - hwcontext_videotoolbox.h
   Add av_vt_pixbuf_set_attachments
 
diff --git a/libavformat/avformat.h b/libavformat/avformat.h
index 70b36d7682..6ce367e854 100644
--- a/libavformat/avformat.h
+++ b/libavformat/avformat.h
@@ -463,6 +463,13 @@ typedef struct AVProbeData {
 /// Demuxer will use avio_open, no opened file should be provided by the 
caller.
 #define AVFMT_NOFILE0x0001
 #define AVFMT_NEEDNUMBER0x0002 /**< Needs '%d' in filename. */
+/**
+ * The muxer/demuxer is experimental and should be used with caution.
+ *
+ * - demuxers: will not be selected automatically by probing, must be specified
+ * explicitly.
+ */
+#define AVFMT_EXPERIMENTAL  0x0004
 #define AVFMT_SHOW_IDS  0x0008 /**< Show format stream IDs numbers. */
 #define AVFMT_GLOBALHEADER  0x0040 /**< Format wants global header. */
 #define AVFMT_NOTIMESTAMPS  0x0080 /**< Format does not need / have any 
timestamps. */
diff --git a/libavformat/format.c b/libavformat/format.c
index 387627009e..52b85c16a2 100644
--- a/libavformat/format.c
+++ b/libavformat/format.c
@@ -158,6 +158,8 @@ const AVInputFormat *av_probe_input_format3(const 
AVProbeData *pd,
 }
 
 while ((fmt1 = av_demuxer_iterate(&i))) {
+if (fmt1->flags & AVFMT_EXPERIMENTAL)
+continue;
 if (!is_opened == !(fmt1->flags & AVFMT_NOFILE) && strcmp(fmt1->name, 
"image2"))
 continue;
 score = 0;
diff --git a/libavformat/version.h b/libavformat/version.h
index 917b9ffa5d..29dcce352b 100644
--- a/libavformat/version.h
+++ b/libavformat/version.h
@@ -32,7 +32,7 @@
 // Major bumping may affect Ticket5467, 5421, 5451(compatibility with Chromium)
 // Also please add any ticket numbers that you believe might be affected here
 #define LIBAVFORMAT_VERSION_MAJOR  59
-#define LIBAVFORMAT_VERSION_MINOR  12
+#define LIBAVFORMAT_VERSION_MINOR  13
 #define LIBAVFORMAT_VERSION_MICRO 100
 
 #define LIBAVFORMAT_VERSION_INT AV_VERSION_INT(LIBAVFORMAT_VERSION_MAJOR, \
-- 
2.33.0

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

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

[FFmpeg-devel] [RFC/PATCH 2/2] lavf/imfdec: mark as experimental

2022-01-02 Thread Anton Khirnov 
People have expressed concerns about its safety, so prevent it from
being auto-selected without explicit user indication.
---
 libavformat/imfdec.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/libavformat/imfdec.c b/libavformat/imfdec.c
index f17064cfcd..228ba494ae 100644
--- a/libavformat/imfdec.c
+++ b/libavformat/imfdec.c
@@ -889,6 +889,7 @@ static const AVClass imf_class = {
 const AVInputFormat ff_imf_demuxer = {
 .name   = "imf",
 .long_name  = NULL_IF_CONFIG_SMALL("IMF (Interoperable Master 
Format)"),
+.flags  = AVFMT_EXPERIMENTAL,
 .flags_internal = FF_FMT_INIT_CLEANUP,
 .priv_class = &imf_class,
 .priv_data_size = sizeof(IMFContext),
-- 
2.33.0

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

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

Re: [FFmpeg-devel] [PATCH] avformat/mxfdec: support MCA audio information

2022-01-02 Thread Michael Niedermayer 
On Sun, Jan 02, 2022 at 02:11:01AM +0100, Marton Balint wrote:
> 
> 
> On Sat, 1 Jan 2022, Pierre-Anthony Lemieux wrote:
> 
> > Minor suggestion below.
> > 
> > In addition, will sample file(s) be added to FATE? Below are two examples:
> > 
> > http://ffmpeg-imf-samples-public.s3.us-west-1.amazonaws.com/callout_51_l_r_c_lfe_ls_rs.mxf
> > http://ffmpeg-imf-samples-public.s3.us-west-1.amazonaws.com/callout_51_l_c_r_ls_rs_lfe.mxf
> 
> Good idea, can someone with access please upload these to the fate mxf
> folder?

you should CC samples-request once theres agreement what to upload

thx

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

Many that live deserve death. And some that die deserve life. Can you give
it to them? Then do not be too eager to deal out death in judgement. For
even the very wise cannot see all ends. -- Gandalf


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 v1] avformat/imf: Fix error handling in set_context_streams_from_tracks()

2022-01-02 Thread pal 
From: Pierre-Anthony Lemieux 

Signed-off-by: Pierre-Anthony Lemieux 
---
 libavformat/imfdec.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/libavformat/imfdec.c b/libavformat/imfdec.c
index f17064cfcd..da8c6cddea 100644
--- a/libavformat/imfdec.c
+++ b/libavformat/imfdec.c
@@ -564,9 +564,8 @@ static int set_context_streams_from_tracks(AVFormatContext 
*s)
 /* Copy stream information */
 asset_stream = avformat_new_stream(s, NULL);
 if (!asset_stream) {
-ret = AVERROR(ENOMEM);
 av_log(s, AV_LOG_ERROR, "Could not create stream\n");
-break;
+return AVERROR(ENOMEM);
 }
 asset_stream->id = i;
 ret = avcodec_parameters_copy(asset_stream->codecpar, 
first_resource_stream->codecpar);
-- 
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".

Re: [FFmpeg-devel] 5.0 release

2022-01-02 Thread Michael Niedermayer 
On Sun, Jan 02, 2022 at 05:28:24PM +0100, Lynne wrote:
> 2 Jan 2022, 16:52 by z...@zanevaniperen.com:
> 
> >
> >
> > On 3/1/22 01:09, James Almer wrote:
> >
>  Reverting something in the release branch is already going to be dirty
>  no matter what, because we do a minor bump to ensure the release has its
>  own soname. Right now that'd mean 5.0 will be lavf 59.13, while lacking
>  a demuxer available in lavf 59.12
> 
> >>>
> >>> Depends on what you mean by "lacking a demuxer"... One (hacky) option 
> >>> would
> >>> be to replace it with a stub implementation that always fails.
> >>>
> >>
> >> Or tag it as experimental.
> >>
> >
> > That's much better. If we're not willing to wait, then I suggest we do this.
> >
> 
> I'd rather have it reverted in master, branch 5.0, and add it back and bump 
> minor
> again. I'm not willing to wait for a month to get fuzzing, the release is way
> overdue as-is. We generally don't put experimental on decoders or demuxers.

I think if we dont want it in the release either as you suggest
revert in master or mark as experimental in master before the branch

having special cases in the release branch feels a bit iffy

thx

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

Any man who breaks a law that conscience tells him is unjust and willingly 
accepts the penalty by staying in jail in order to arouse the conscience of 
the community on the injustice of the law is at that moment expressing the 
very highest respect for law. - Martin Luther King Jr


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] avcodec/v4l2_m2m_dec: dequeue frame if input isn't ready

2022-01-02 Thread Andriy Gelman 
On Tue, 28. Dec 18:41, Andriy Gelman wrote:
> On Mon, 27. Dec 03:18, Cameron Gutman wrote:
> > On 12/27/21 00:17, Andriy Gelman wrote:
> > > On Tue, 14. Dec 02:12, Cameron Gutman wrote:
> > >> The V4L2M2M API operates asynchronously, so multiple packets can
> > >> be enqueued before getting a batch of frames back. Since it was
> > >> only possible to receive a frame by submitting another packet,
> > >> there wasn't a way to drain those excess output frames from when
> > >> avcodec_receive_frame() returned AVERROR(EAGAIN).
> > >>
> > > 
> > >> In my testing, this change reduced decode latency of a real-time
> > >> 60 FPS H.264 stream by approximately 10x (200ms -> 20ms) on a
> > >> Raspberry Pi 4.
> > > 
> > > I was doing some more tests today, but didn't have any luck dequeuing a 
> > > frame
> > > if ff_decode_get_packet() returned EAGAIN.
> > 
> > Hmm, maybe there is something different about your test harness?
> > I'm receiving 720p 60 FPS H.264 ES in real-time from the network.
> 
> I used ffmpeg, i.e.
> ./ffmpeg -codec:v h264_v4l2m2m -i 720p60.h264 -f null -
> 
> Anyway, I applied your patch but just removed the comment on latency
> because I couldn't reproduce it.
> 
> > 
> > For each H.264 encoded frame I receive off the network, my basic
> > approach is like this (simplified for brevity):
> > 
> > avcodec_send_packet(&pkt);
> > do {
> > frame = av_frame_alloc();
> > if ((err = avcodec_receive_frame(frame)) == 0) {
> > render_frame(frame);
> > }
> > } while (err == 0);
> > 
> > I'll usually get EAGAIN immediately for the first few frames I submit
> > (so no output frame yet), but then I'll get a batch of output frames
> > back after the first completed decode. That drains the excess latency
> > from the pipeline to avoid always being behind.
> > 
> > For cases where we want to prioritize latency over throughput, I've
> > had success with this approach too:
> > 
> > avcodec_send_packet(&pkt);
> > while (avcodec_receive_frame(frame) == AVERROR(EAGAIN)) {
> > msleep(1);
> > }
> > render_frame(frame);
> > 
> > In this case, we can retry avcodec_receive_frame() until we get the
> > frame back that we just submitted for decoding.
> 
> > 
> > The patch here enables both of these use-cases by allowing V4L2M2M
> > to retry getting a decoded frame without new input data. Both of
> > these also work with MMAL after the recent decoupled dataflow patch.
> > 
> > > Could you share the dataset?
> > > 
> > 
> 
> > It is 720p60.h264 from here:
> > https://onedrive.live.com/?authkey=%21ALoKfcPfFeKyhzs&id=C15BF9770619F56%21165617&cid=0C15BF9770619F56

> 
> I could not decode this dataset on rpi4 (before or after the patch). Tried to 
> upgrade kernel
> to 5.16, but still same problem. Odroid xu4 seems to work fine.

This patch fixes decoding on the RPi4 for me:
https://patchwork.ffmpeg.org/project/ffmpeg/patch/20210819085533.1174-2-ming.q...@nxp.com/

It would be nice to get the fix into the upcoming release.

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

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

Re: [FFmpeg-devel] [PATCH v4 3/3] avcodec/v4l2_m2m_dec: setup capture queue before enqueue the first frame

2022-01-02 Thread Andriy Gelman 
On Thu, 19. Aug 16:55, Ming Qian wrote:
> there are two proper ways to setup capture queue.
> 1. client wait the source change event,
>then setup the capture queue and streamon
> 2. client setup the capture queue in advance,
>but to avoid time issues, client should start
>the capture queue before it enqueue the sequence
>header to decoder driver through output queue.
>and the sequence header is always in the first
>frame, so client should start capture before
>enqueue the first frame.
> 
> ffmpeg use the method 2 to setup capture queue,
> but currently ffmpeg enqueue the first frame
> before starting the capture queue.
> so in driver side, there are time issues.
> when driver has parsed the resolution from sequence header,
> but the client may not finished setup the capture.
> so driver can't decide whether to notify a source change event to
> client. and the following flow may be chaotic.
> 
> And it's OK that client setup capture queue first, then enqueue the
> first frame.
> 
> Signed-off-by: Ming Qian 
> ---
>  libavcodec/v4l2_m2m_dec.c | 18 --
>  1 file changed, 8 insertions(+), 10 deletions(-)
> 
> diff --git a/libavcodec/v4l2_m2m_dec.c b/libavcodec/v4l2_m2m_dec.c
> index 224eb3d5e7be..6b936b6df2a9 100644
> --- a/libavcodec/v4l2_m2m_dec.c
> +++ b/libavcodec/v4l2_m2m_dec.c
> @@ -149,6 +149,14 @@ static int v4l2_receive_frame(AVCodecContext *avctx, 
> AVFrame *frame)
>  if (s->draining)
>  goto dequeue;
>  
> +ret = v4l2_try_start(avctx);
> +if (ret) {
> +/* can't recover */
> +if (ret != AVERROR(ENOMEM))
> +ret = 0;
> +goto fail;
> +}
> +
>  ret = ff_v4l2_context_enqueue_packet(output, &s->buf_pkt);
>  if (ret < 0 && ret != AVERROR(EAGAIN))
>  goto fail;
> @@ -157,16 +165,6 @@ static int v4l2_receive_frame(AVCodecContext *avctx, 
> AVFrame *frame)
>  if (ret != AVERROR(EAGAIN))
>  av_packet_unref(&s->buf_pkt);
>  
> -if (!s->draining) {
> -ret = v4l2_try_start(avctx);
> -if (ret) {
> -/* cant recover */
> -if (ret != AVERROR(ENOMEM))
> -ret = 0;
> -goto fail;
> -}
> -}
> -
>  dequeue:
>  return ff_v4l2_context_dequeue_frame(capture, frame, -1);
>  fail:

Unfortunately this does not work on odroid xu4.
It needs to parse the parameter sets before VIDIOC_G_FMT ioctl is called on the
capture queue:
https://github.com/hardkernel/linux/blob/odroid-5.4.y/drivers/media/platform/s5p-mfc/s5p_mfc_dec.c#L317

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

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

Re: [FFmpeg-devel] [PATCH v4 2/3] avcodec/v4l2_context: resume the decoding process after source change event received.

2022-01-02 Thread Andriy Gelman 
On Thu, 19. Aug 16:55, Ming Qian wrote:
> client need to resume the decoding process
> after it dequeues the source change event.
> no matter what's the return value of v4l2_resolution_changed().
> if the client doesn't resume the decoding process,
> the decoder may keep waiting
> 
> in documentation of v4l2 stateful decoder, we can see the following
> description:
>   The client must continue the sequence as described below to
>   continue the decoding process.
>   1.  Dequeue the source change event.
>   Important
>   A source change triggers an implicit decoder drain,
>   similar to the explicit Drain sequence. The decoder is
>   stopped after it completes. The decoding process must be
>   resumed with either a pair of calls to
>   VIDIOC_STREAMOFF() and VIDIOC_STREAMON() on the CAPTURE
>   queue, or a call to VIDIOC_DECODER_CMD() with the
>   V4L2_DEC_CMD_START command.
>   2.  Continue with the Capture Setup sequence.

Please also add that this fixes decoding of
https://streams.videolan.org/ffmpeg/incoming/720p60.mp4 on RPi4.

> 
> Signed-off-by: Ming Qian 
> ---
>  libavcodec/v4l2_context.c | 52 ---
>  1 file changed, 32 insertions(+), 20 deletions(-)
> 
> diff --git a/libavcodec/v4l2_context.c b/libavcodec/v4l2_context.c
> index dda5157698c3..b08f0015c2e5 100644
> --- a/libavcodec/v4l2_context.c
> +++ b/libavcodec/v4l2_context.c
> @@ -153,6 +153,21 @@ static inline void v4l2_save_to_context(V4L2Context* 
> ctx, struct v4l2_format_upd
>  }
>  }
>  
> +static int v4l2_start_decode(V4L2Context *ctx)
> +{
> +struct v4l2_decoder_cmd cmd = {
> +.cmd = V4L2_DEC_CMD_START,
> +.flags = 0,
> +};
> +int ret;
> +
> +ret = ioctl(ctx_to_m2mctx(ctx)->fd, VIDIOC_DECODER_CMD, &cmd);
> +if (ret)
> +return AVERROR(errno);
> +
> +return 0;
> +}
> +
>  /**
>   * handle resolution change event and end of stream event
>   * returns 1 if reinit was successful, negative if it failed
> @@ -163,7 +178,7 @@ static int v4l2_handle_event(V4L2Context *ctx)
>  V4L2m2mContext *s = ctx_to_m2mctx(ctx);
>  struct v4l2_format cap_fmt = s->capture.format;
>  struct v4l2_event evt = { 0 };
> -int reinit, ret;
> +int ret;
>  
>  ret = ioctl(s->fd, VIDIOC_DQEVENT, &evt);
>  if (ret < 0) {
> @@ -185,35 +200,29 @@ static int v4l2_handle_event(V4L2Context *ctx)
>  return 0;
>  }
>  
> -reinit = v4l2_resolution_changed(&s->capture, &cap_fmt);
> -if (reinit) {
> +if (v4l2_resolution_changed(&s->capture, &cap_fmt)) {
>  s->capture.height = v4l2_get_height(&cap_fmt);
>  s->capture.width = v4l2_get_width(&cap_fmt);
>  s->capture.sample_aspect_ratio = v4l2_get_sar(&s->capture);

> +} else {
> +v4l2_start_decode(ctx);
> +return 0;
>  }

You can minimize the diff just by adding this part and the
definition for v4l2_start_decode(). Then have a separate commit that cleans up
and removes the reinit variable.

>  
> -if (reinit)
> -s->reinit = 1;
> +s->reinit = 1;
>  
> -if (reinit) {
> -if (s->avctx)
> -ret = ff_set_dimensions(s->avctx, s->capture.width, 
> s->capture.height);
> -if (ret < 0)
> -av_log(logger(ctx), AV_LOG_WARNING, "update avcodec height and 
> width\n");
> +if (s->avctx)
> +ret = ff_set_dimensions(s->avctx, s->capture.width, 
> s->capture.height);
> +if (ret < 0)
> +av_log(logger(ctx), AV_LOG_WARNING, "update avcodec height and 
> width\n");
>  
> -ret = ff_v4l2_m2m_codec_reinit(s);
> -if (ret) {
> -av_log(logger(ctx), AV_LOG_ERROR, "v4l2_m2m_codec_reinit\n");
> -return AVERROR(EINVAL);
> -}
> -goto reinit_run;
> +ret = ff_v4l2_m2m_codec_reinit(s);
> +if (ret) {
> +av_log(logger(ctx), AV_LOG_ERROR, "v4l2_m2m_codec_reinit\n");
> +return AVERROR(EINVAL);
>  }
>  
> -/* dummy event received */
> -return 0;
> -
>  /* reinit executed */
> -reinit_run:
>  return 1;
>  }
>  
> @@ -551,6 +560,9 @@ int ff_v4l2_context_set_status(V4L2Context* ctx, uint32_t 
> cmd)
>  int type = ctx->type;
>  int ret;

>  
> +if (ctx->streamon == (cmd == VIDIOC_STREAMON))
> +return 0;
> +

This change looks unrelated.

>  ret = ioctl(ctx_to_m2mctx(ctx)->fd, cmd, &type);
>  if (ret < 0)
>  return AVERROR(errno);

Thanks,
-- 
Andriy
___
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] 5.0 release

2022-01-02 Thread Lynne 
2 Jan 2022, 16:52 by z...@zanevaniperen.com:

>
>
> On 3/1/22 01:09, James Almer wrote:
>
 Reverting something in the release branch is already going to be dirty
 no matter what, because we do a minor bump to ensure the release has its
 own soname. Right now that'd mean 5.0 will be lavf 59.13, while lacking
 a demuxer available in lavf 59.12

>>>
>>> Depends on what you mean by "lacking a demuxer"... One (hacky) option would
>>> be to replace it with a stub implementation that always fails.
>>>
>>
>> Or tag it as experimental.
>>
>
> That's much better. If we're not willing to wait, then I suggest we do this.
>

I'd rather have it reverted in master, branch 5.0, and add it back and bump 
minor
again. I'm not willing to wait for a month to get fuzzing, the release is way
overdue as-is. We generally don't put experimental on decoders or demuxers.


>> Also, unless ossfuzz compiles with libxml2 enabled, we're not going to see 
>> any kind of fuzzing for imf from it.
>>
>
> I just checked - it doesn't. I'm adding it and will send a PR.
>


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

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

Re: [FFmpeg-devel] [PATCH v4 1/3] avcodec/v4l2_context: don't reinit output queue when dynamic resolution change

2022-01-02 Thread Andriy Gelman 
On Thu, 19. Aug 16:55, Ming Qian wrote:
> in the v4l2 stateful video document, we can see the following
> description:
> During the resolution change sequence, the OUTPUT queue must remain
> streaming. Calling VIDIOC_STREAMOFF() on the OUTPUT queue would
> abort the sequence and initiate a seek.
> 
> In principle, the OUTPUT queue operates separately from the CAPTURE
> queue and this remains true for the duration of the entire
> resolution change sequence as well.
> 
> so don't reinit the output queue when handling the resolution change
> event
> 
> Signed-off-by: Ming Qian 
> ---
>  libavcodec/v4l2_context.c | 27 ++-
>  1 file changed, 2 insertions(+), 25 deletions(-)
> 
> diff --git a/libavcodec/v4l2_context.c b/libavcodec/v4l2_context.c
> index ff1ea8e57b08..dda5157698c3 100644
> --- a/libavcodec/v4l2_context.c
> +++ b/libavcodec/v4l2_context.c
> @@ -162,9 +162,8 @@ static int v4l2_handle_event(V4L2Context *ctx)
>  {
>  V4L2m2mContext *s = ctx_to_m2mctx(ctx);
>  struct v4l2_format cap_fmt = s->capture.format;
> -struct v4l2_format out_fmt = s->output.format;
>  struct v4l2_event evt = { 0 };
> -int full_reinit, reinit, ret;
> +int reinit, ret;
>  
>  ret = ioctl(s->fd, VIDIOC_DQEVENT, &evt);
>  if (ret < 0) {
> @@ -180,25 +179,12 @@ static int v4l2_handle_event(V4L2Context *ctx)
>  if (evt.type != V4L2_EVENT_SOURCE_CHANGE)
>  return 0;
>  
> -ret = ioctl(s->fd, VIDIOC_G_FMT, &out_fmt);
> -if (ret) {
> -av_log(logger(ctx), AV_LOG_ERROR, "%s VIDIOC_G_FMT\n", 
> s->output.name);
> -return 0;
> -}
> -
>  ret = ioctl(s->fd, VIDIOC_G_FMT, &cap_fmt);
>  if (ret) {
>  av_log(logger(ctx), AV_LOG_ERROR, "%s VIDIOC_G_FMT\n", 
> s->capture.name);
>  return 0;
>  }
>  
> -full_reinit = v4l2_resolution_changed(&s->output, &out_fmt);
> -if (full_reinit) {
> -s->output.height = v4l2_get_height(&out_fmt);
> -s->output.width = v4l2_get_width(&out_fmt);
> -s->output.sample_aspect_ratio = v4l2_get_sar(&s->output);
> -}
> -
>  reinit = v4l2_resolution_changed(&s->capture, &cap_fmt);
>  if (reinit) {
>  s->capture.height = v4l2_get_height(&cap_fmt);
> @@ -206,18 +192,9 @@ static int v4l2_handle_event(V4L2Context *ctx)
>  s->capture.sample_aspect_ratio = v4l2_get_sar(&s->capture);
>  }
>  
> -if (full_reinit || reinit)
> +if (reinit)
>  s->reinit = 1;
>  
> -if (full_reinit) {

> -ret = ff_v4l2_m2m_codec_full_reinit(s);

This is the only use of the function ff_v4l2_m2m_codec_full_reinit(). An option
is to remove the function in the commit. I can see how this private
function could be useful in the future though.. Do we then remove the function 
and add
it back in the future or just let it be?

Suggestion on IRC was to remove, but I also want to check on ML.

> -if (ret) {
> -av_log(logger(ctx), AV_LOG_ERROR, 
> "v4l2_m2m_codec_full_reinit\n");
> -return AVERROR(EINVAL);
> -}
> -goto reinit_run;
> -}
> -
>  if (reinit) {
>  if (s->avctx)
>  ret = ff_set_dimensions(s->avctx, s->capture.width, 
> s->capture.height);

Otherwise, the patch looks good to me.
Sorry for the delay.

Thanks,
-- 
Andriy
___
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] 5.0 release

2022-01-02 Thread Zane van Iperen 




On 3/1/22 01:09, James Almer wrote:



Reverting something in the release branch is already going to be dirty
no matter what, because we do a minor bump to ensure the release has its
own soname. Right now that'd mean 5.0 will be lavf 59.13, while lacking
a demuxer available in lavf 59.12


Depends on what you mean by "lacking a demuxer"... One (hacky) option would
be to replace it with a stub implementation that always fails.


Or tag it as experimental.



That's much better. If we're not willing to wait, then I suggest we do this.



Also, unless ossfuzz compiles with libxml2 enabled, we're not going to see any 
kind of fuzzing for imf from it.



I just checked - it doesn't. I'm adding it and will send a PR.
___
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] 5.0 release

2022-01-02 Thread James Almer 

On 1/2/2022 11:50 AM, Zane van Iperen wrote:

On Monday, 3 January 2022 12:29:02 AM AEST James Almer wrote:


There were some disagreements on IRC a few days ago about what should
and should not go into the release because of insufficient fuzzing and
the danger of introducing security issues.

To avoid conflicts around this in the future, I'd suggest (for future
releases) to create the release branch a significant time (e.g. a month)
before doing the actual release.

Opinions?


It's a good idea, but we need to be strict about it. As in, we need to
state that the moment the branch is made it's a definite feature freeze,
and only fixes, documentation changes and similar may be cherry-picked
into it (meaning nothing that usually comes with a version bump, even if
micro), much like we do for a point release, even if the initial release
was not tagged yet.



I completely agree, this is a *very* good idea. If people treat it like
an existing release branch, i.e. only bugfixes, etc., then it would
save this from happening again.

Also means there wouldn't need to be a "don't add big things" announcement
_somewhere_ on the ML.


Reverting something in the release branch is already going to be dirty
no matter what, because we do a minor bump to ensure the release has its
own soname. Right now that'd mean 5.0 will be lavf 59.13, while lacking
a demuxer available in lavf 59.12


Depends on what you mean by "lacking a demuxer"... One (hacky) option would
be to replace it with a stub implementation that always fails.


Or tag it as experimental.



Or we could just branch off at 7cee3b3718 and cherry-pick anything we need back.
There's only like four commits that need it (so far): 2f6360ff21, 9cfc7a2440,
c417616762, and d6b2357edd.


Branching at 7cee3b3718 will give you a snapshot with lavf 59.10. What 
do you do with the release branch exclusive bump? Can't be 59.11 as 
that's in master post branch creation. Same with 59.12. So you have to 
do 59.13, but then the 59.13 feature set is that of 59.10, thus lacking 
the stuff added in 59.{11,12}, And that's a real pain in the ass for 
anyone looking at our versioning to know what they can expect from the 
libraries.


The less-messy options at this point, besides your suggestion above or 
mine about tagging it as experimental, would be to revert the imf 
demuxer in master and then branch, or branch at the newest commit in the 
tree without a revert then delay tagging the release until a month has 
passed and the imf demuxer was tested somewhat (Which is what Anton 
suggested, but starting with this release instead).


Also, unless ossfuzz compiles with libxml2 enabled, we're not going to 
see any kind of fuzzing for imf from it.







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

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


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

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

[FFmpeg-devel] [PATCH 5/5] avfilter/vf_blend: fix un-checked potential memory allocation failure

2022-01-02 Thread Wu Jianhua 
Signed-off-by: Wu Jianhua 
---
 libavfilter/vf_blend.c | 6 +-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/libavfilter/vf_blend.c b/libavfilter/vf_blend.c
index b6f3c4fed3..2d433e439f 100644
--- a/libavfilter/vf_blend.c
+++ b/libavfilter/vf_blend.c
@@ -279,7 +279,11 @@ static AVFrame *blend_frame(AVFilterContext *ctx, AVFrame 
*top_buf,
 dst_buf = ff_get_video_buffer(outlink, outlink->w, outlink->h);
 if (!dst_buf)
 return top_buf;
-av_frame_copy_props(dst_buf, top_buf);
+
+if (av_frame_copy_props(dst_buf, top_buf) < 0) {
+av_frame_free(&dst_buf);
+return top_buf;
+}
 
 for (plane = 0; plane < s->nb_planes; plane++) {
 int hsub = plane == 1 || plane == 2 ? s->hsub : 0;
-- 
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 4/5] avfilter: add a blend_vulkan filter

2022-01-02 Thread Wu Jianhua 
This commit adds a blend_vulkan filter and a normal blend mode, and
reserves support for introducing the blend modes in the future.

Use the commands below to test: (href: https://trac.ffmpeg.org/wiki/Blend)
I. make an image for test
ffmpeg -f lavfi -i color=s=256x256,geq=r='H-1-Y':g='H-1-Y':b='H-1-Y' -frames 1 \
-y -pix_fmt yuv420p test.jpg

II. blend in sw
ffmpeg -i test.jpg -vf 
"split[a][b];[b]transpose[b];[a][b]blend=all_mode=normal,\
pseudocolor=preset=turbo" -y normal_sw.jpg

III. blend in vulkan
ffmpeg -init_hw_device vulkan -i test.jpg -vf "split[a][b];[b]transpose[b];\
[a]hwupload[a];[b]hwupload[b];[a][b]blend_vulkan=all_mode=normal,hwdownload,\
format=yuv420p,pseudocolor=preset=turbo" -y normal_vulkan.jpg

Signed-off-by: Wu Jianhua 
---
 configure |   1 +
 libavfilter/Makefile  |   1 +
 libavfilter/allfilters.c  |   1 +
 libavfilter/vf_blend_vulkan.c | 501 ++
 4 files changed, 504 insertions(+)
 create mode 100644 libavfilter/vf_blend_vulkan.c

diff --git a/configure b/configure
index 6ad70b9f7b..f6c9e38051 100755
--- a/configure
+++ b/configure
@@ -3609,6 +3609,7 @@ avgblur_opencl_filter_deps="opencl"
 avgblur_vulkan_filter_deps="vulkan spirv_compiler"
 azmq_filter_deps="libzmq"
 blackframe_filter_deps="gpl"
+blend_vulkan_filter_deps="vulkan spirv_compiler"
 bm3d_filter_deps="avcodec"
 bm3d_filter_select="dct"
 boxblur_filter_deps="gpl"
diff --git a/libavfilter/Makefile b/libavfilter/Makefile
index 090944a99c..ed727e3fd9 100644
--- a/libavfilter/Makefile
+++ b/libavfilter/Makefile
@@ -192,6 +192,7 @@ OBJS-$(CONFIG_BITPLANENOISE_FILTER)  += 
vf_bitplanenoise.o
 OBJS-$(CONFIG_BLACKDETECT_FILTER)+= vf_blackdetect.o
 OBJS-$(CONFIG_BLACKFRAME_FILTER) += vf_blackframe.o
 OBJS-$(CONFIG_BLEND_FILTER)  += vf_blend.o framesync.o
+OBJS-$(CONFIG_BLEND_VULKAN_FILTER)   += vf_blend_vulkan.o framesync.o 
vulkan.o vulkan_filter.o
 OBJS-$(CONFIG_BM3D_FILTER)   += vf_bm3d.o framesync.o
 OBJS-$(CONFIG_BOXBLUR_FILTER)+= vf_boxblur.o boxblur.o
 OBJS-$(CONFIG_BOXBLUR_OPENCL_FILTER) += vf_avgblur_opencl.o opencl.o \
diff --git a/libavfilter/allfilters.c b/libavfilter/allfilters.c
index caa755320e..84ba9fdf54 100644
--- a/libavfilter/allfilters.c
+++ b/libavfilter/allfilters.c
@@ -183,6 +183,7 @@ extern const AVFilter ff_vf_bitplanenoise;
 extern const AVFilter ff_vf_blackdetect;
 extern const AVFilter ff_vf_blackframe;
 extern const AVFilter ff_vf_blend;
+extern const AVFilter ff_vf_blend_vulkan;
 extern const AVFilter ff_vf_bm3d;
 extern const AVFilter ff_vf_boxblur;
 extern const AVFilter ff_vf_boxblur_opencl;
diff --git a/libavfilter/vf_blend_vulkan.c b/libavfilter/vf_blend_vulkan.c
new file mode 100644
index 00..fac1be532d
--- /dev/null
+++ b/libavfilter/vf_blend_vulkan.c
@@ -0,0 +1,501 @@
+/*
+ * copyright (c) 2021 Wu Jianhua 
+ * The blend modes are based on the blend.c.
+ *
+ * This file is part of FFmpeg.
+ *
+ * FFmpeg is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public
+ * License as published by the Free Software Foundation; either
+ * version 2.1 of the License, or (at your option) any later version.
+ *
+ * FFmpeg is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+ * Lesser General Public License for more details.
+ *
+ * You should have received a copy of the GNU Lesser General Public
+ * License along with FFmpeg; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA
+ */
+
+#include "libavutil/random_seed.h"
+#include "libavutil/opt.h"
+#include "vulkan_filter.h"
+#include "internal.h"
+#include "framesync.h"
+#include "blend.h"
+
+#define CGS 32
+
+typedef struct FilterParamsVulkan {
+const char *blend;
+const char *blend_func;
+double opacity;
+enum BlendMode mode;
+} FilterParamsVulkan;
+
+typedef struct BlendVulkanContext {
+FFVulkanContext vkctx;
+FFVkQueueFamilyCtx qf;
+FFVkExecContext *exec;
+FFVulkanPipeline *pl;
+FFFrameSync fs;
+
+VkDescriptorImageInfo top_images[3];
+VkDescriptorImageInfo bottom_images[3];
+VkDescriptorImageInfo output_images[3];
+
+FilterParamsVulkan params[4];
+double all_opacity;
+enum BlendMode all_mode;
+
+int initialized;
+} BlendVulkanContext;
+
+#define DEFINE_BLEND_MODE(MODE, EXPR) \
+static const char blend_##MODE[] = "blend_"#MODE; \
+static const char blend_##MODE##_func[] = { \
+C(0, vec4 blend_##MODE(vec4 top, vec4 bottom, float opacity) {   ) \
+C(1, vec4 dst = EXPR;) \
+C(1, return dst; ) \
+C(0, }   ) \
+};
+
+#de

[FFmpeg-devel] [PATCH 3/5] avfilter/vf_scale_vulkan: align struct ScaleVulkanContext

2022-01-02 Thread Wu Jianhua 
On 64 bit Operating System, sizeof(ScaleVulkanContext):
reduce from 2400 to 2392 on Linux
reduce from 2416 to 2408 on Windows

Signed-off-by: Wu Jianhua 
---
 libavfilter/vf_scale_vulkan.c | 8 +---
 1 file changed, 5 insertions(+), 3 deletions(-)

diff --git a/libavfilter/vf_scale_vulkan.c b/libavfilter/vf_scale_vulkan.c
index cfce5ab1f8..c87a8d7e2e 100644
--- a/libavfilter/vf_scale_vulkan.c
+++ b/libavfilter/vf_scale_vulkan.c
@@ -35,7 +35,6 @@ enum ScalerFunc {
 typedef struct ScaleVulkanContext {
 FFVulkanContext vkctx;
 
-int initialized;
 FFVkQueueFamilyCtx qf;
 FFVkExecContext *exec;
 FFVulkanPipeline *pl;
@@ -46,11 +45,14 @@ typedef struct ScaleVulkanContext {
 VkDescriptorImageInfo output_images[3];
 VkDescriptorBufferInfo params_desc;
 
-enum ScalerFunc scaler;
 char *out_format_string;
-enum AVColorRange out_range;
 char *w_expr;
 char *h_expr;
+
+enum ScalerFunc scaler;
+enum AVColorRange out_range;
+
+int initialized;
 } ScaleVulkanContext;
 
 static const char scale_bilinear[] = {
-- 
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] transpose_vulkan: add passthrough option

2022-01-02 Thread Wu Jianhua 
The following command is on how to apply passthrough option:

ffmpeg -init_hw_device vulkan -i input.264 -vf 
hwupload=extra_hw_frames=16,transpose_vulkan=passthrough=landscape,hwdownload,format=yuv420p
 output.264

Signed-off-by: Wu Jianhua 
---
 libavfilter/vf_transpose_vulkan.c | 22 ++
 1 file changed, 22 insertions(+)

diff --git a/libavfilter/vf_transpose_vulkan.c 
b/libavfilter/vf_transpose_vulkan.c
index ce83cf0fd7..30d052e08c 100644
--- a/libavfilter/vf_transpose_vulkan.c
+++ b/libavfilter/vf_transpose_vulkan.c
@@ -35,6 +35,7 @@ typedef struct TransposeVulkanContext {
 VkDescriptorImageInfo output_images[3];
 
 int dir;
+int passthrough;
 int initialized;
 } TransposeVulkanContext;
 
@@ -222,6 +223,9 @@ static int filter_frame(AVFilterLink *inlink, AVFrame *in)
 TransposeVulkanContext *s = ctx->priv;
 AVFilterLink *outlink = ctx->outputs[0];
 
+if (s->passthrough)
+return ff_filter_frame(outlink, in);
+
 out = ff_get_video_buffer(outlink, outlink->w, outlink->h);
 if (!out) {
 err = AVERROR(ENOMEM);
@@ -267,6 +271,17 @@ static int config_props_output(AVFilterLink *outlink)
 FFVulkanContext *vkctx = &s->vkctx;
 AVFilterLink *inlink = avctx->inputs[0];
 
+if ((inlink->w >= inlink->h && s->passthrough == 
TRANSPOSE_PT_TYPE_LANDSCAPE) ||
+(inlink->w <= inlink->h && s->passthrough == 
TRANSPOSE_PT_TYPE_PORTRAIT)) {
+av_log(avctx, AV_LOG_VERBOSE,
+   "w:%d h:%d -> w:%d h:%d (passthrough mode)\n",
+   inlink->w, inlink->h, inlink->w, inlink->h);
+outlink->hw_frames_ctx = av_buffer_ref(inlink->hw_frames_ctx);
+return outlink->hw_frames_ctx ? 0 : AVERROR(ENOMEM);
+} else {
+s->passthrough = TRANSPOSE_PT_TYPE_NONE;
+}
+
 vkctx->output_width  = inlink->h;
 vkctx->output_height = inlink->w;
 
@@ -288,6 +303,13 @@ static const AVOption transpose_vulkan_options[] = {
 { "clock",   "rotate clockwise",0, 
AV_OPT_TYPE_CONST, { .i64 = TRANSPOSE_CLOCK   }, .flags=FLAGS, .unit = 
"dir" },
 { "cclock",  "rotate counter-clockwise",0, 
AV_OPT_TYPE_CONST, { .i64 = TRANSPOSE_CCLOCK  }, .flags=FLAGS, .unit = 
"dir" },
 { "clock_flip",  "rotate clockwise with vertical flip", 0, 
AV_OPT_TYPE_CONST, { .i64 = TRANSPOSE_CLOCK_FLIP  }, .flags=FLAGS, .unit = 
"dir" },
+
+{ "passthrough", "do not apply transposition if the input matches the 
specified geometry",
+  OFFSET(passthrough), AV_OPT_TYPE_INT, {.i64=TRANSPOSE_PT_TYPE_NONE},  0, 
INT_MAX, FLAGS, "passthrough" },
+{ "none",  "always apply transposition",   0, AV_OPT_TYPE_CONST, 
{.i64=TRANSPOSE_PT_TYPE_NONE},  INT_MIN, INT_MAX, FLAGS, "passthrough" },
+{ "portrait",  "preserve portrait geometry",   0, AV_OPT_TYPE_CONST, 
{.i64=TRANSPOSE_PT_TYPE_PORTRAIT},  INT_MIN, INT_MAX, FLAGS, "passthrough" },
+{ "landscape", "preserve landscape geometry",  0, AV_OPT_TYPE_CONST, 
{.i64=TRANSPOSE_PT_TYPE_LANDSCAPE}, INT_MIN, INT_MAX, FLAGS, "passthrough" },
+
 { NULL }
 };
 
-- 
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] avutil/hwcontext_vulkan: fixed validation error VUID 01387

2022-01-02 Thread Wu Jianhua 
This commit fixed the validation error that occurred on the Windows platform.

Validation Error: [ VUID-vkCreateDevice-ppEnabledExtensionNames-01387 ] Object 
0: \
handle = 0x2ab1cfa0db0, type = VK_OBJECT_TYPE_INSTANCE; | MessageID = 
0x12537a2c | \
Missing extension required by the device extension VK_EXT_hdr_metadata: 
VK_KHR_swapchain. \
The Vulkan spec states: All required device extensions for each extension in 
the \
VkDeviceCreateInfo::ppEnabledExtensionNames list must also be present in that 
list \
(https://vulkan.lunarg.com/doc/view/1.2.198.1/windows/1.2-extensions/vkspec.html#\
VUID-vkCreateDevice-ppEnabledExtensionNames-01387)

Signed-off-by: Wu Jianhua 
---
 libavutil/hwcontext_vulkan.c | 9 -
 1 file changed, 8 insertions(+), 1 deletion(-)

diff --git a/libavutil/hwcontext_vulkan.c b/libavutil/hwcontext_vulkan.c
index 83a7527198..a2a175a063 100644
--- a/libavutil/hwcontext_vulkan.c
+++ b/libavutil/hwcontext_vulkan.c
@@ -335,7 +335,11 @@ typedef struct VulkanOptExtension {
 } VulkanOptExtension;
 
 static const VulkanOptExtension optional_instance_exts[] = {
-/* For future use */
+/* Misc or required by other extensions */
+#ifdef _WIN32
+{ VK_KHR_WIN32_SURFACE_EXTENSION_NAME,
FF_VK_EXT_NO_FLAG},
+{ VK_KHR_SURFACE_EXTENSION_NAME,  
FF_VK_EXT_NO_FLAG},
+#endif
 };
 
 static const VulkanOptExtension optional_device_exts[] = {
@@ -344,6 +348,9 @@ static const VulkanOptExtension optional_device_exts[] = {
 { VK_EXT_HDR_METADATA_EXTENSION_NAME, 
FF_VK_EXT_NO_FLAG},
 { VK_KHR_SAMPLER_YCBCR_CONVERSION_EXTENSION_NAME, 
FF_VK_EXT_NO_FLAG},
 { VK_KHR_SYNCHRONIZATION_2_EXTENSION_NAME,
FF_VK_EXT_NO_FLAG},
+#ifdef _WIN32
+{ VK_KHR_SWAPCHAIN_EXTENSION_NAME,
FF_VK_EXT_NO_FLAG},
+#endif
 
 /* Imports/exports */
 { VK_KHR_EXTERNAL_MEMORY_FD_EXTENSION_NAME,   
FF_VK_EXT_EXTERNAL_FD_MEMORY },
-- 
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] 5.0 release

2022-01-02 Thread Zane van Iperen 
On Monday, 3 January 2022 12:29:02 AM AEST James Almer wrote:

> > There were some disagreements on IRC a few days ago about what should
> > and should not go into the release because of insufficient fuzzing and
> > the danger of introducing security issues.
> > 
> > To avoid conflicts around this in the future, I'd suggest (for future
> > releases) to create the release branch a significant time (e.g. a month)
> > before doing the actual release.
> > 
> > Opinions?
> 
> It's a good idea, but we need to be strict about it. As in, we need to 
> state that the moment the branch is made it's a definite feature freeze, 
> and only fixes, documentation changes and similar may be cherry-picked 
> into it (meaning nothing that usually comes with a version bump, even if 
> micro), much like we do for a point release, even if the initial release 
> was not tagged yet.
> 

I completely agree, this is a *very* good idea. If people treat it like
an existing release branch, i.e. only bugfixes, etc., then it would
save this from happening again.

Also means there wouldn't need to be a "don't add big things" announcement
_somewhere_ on the ML.

> Reverting something in the release branch is already going to be dirty 
> no matter what, because we do a minor bump to ensure the release has its 
> own soname. Right now that'd mean 5.0 will be lavf 59.13, while lacking 
> a demuxer available in lavf 59.12

Depends on what you mean by "lacking a demuxer"... One (hacky) option would
be to replace it with a stub implementation that always fails.

Or we could just branch off at 7cee3b3718 and cherry-pick anything we need back.
There's only like four commits that need it (so far): 2f6360ff21, 9cfc7a2440,
c417616762, and d6b2357edd.




___
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] 5.0 release

2022-01-02 Thread James Almer 

On 1/2/2022 11:12 AM, Anton Khirnov wrote:

Quoting Michael Niedermayer (2021-12-31 20:40:24)

On Fri, Dec 31, 2021 at 10:45:46PM +0530, Gyan Doshi wrote:



On 2021-12-31 10:22 pm, Michael Niedermayer wrote:

On Tue, Dec 28, 2021 at 12:55:14AM +0100, Michael Niedermayer wrote:

On Wed, Dec 22, 2021 at 05:44:42PM +0100, Jean-Baptiste Kempf wrote:

On Wed, 22 Dec 2021, at 15:05, James Almer wrote:

Is the December target to get into the feature freeze schedule from
distros?

No, it was set by me, in order to get the distro freezes from January.

We can miss the target a bit this year, and then make it better for 2022.

as you seem to know the distro freeze shedules
can you clarify "a bit" ?

iam asking just in case the channel patch doesnt make it before
so i know when its time to stop waiting for it

ok
when do people want me to make the branch ?
any preferrances ?
should i do it now or continue waiting?

I saw on IRC some sugestions to make it at a past commit to keep some
code out


It would be nice to have a public date set a few days into the future.


yes, i intended to do that, unless people wanted a ASAP/NOW branch

i guess 3rd january seems like a good choice
1st and 2nd as being close to newyear probably would not be ideal so
3rd seems the soonest good date
but we can push this out more if people want? or also do it earlier
of course that assumes nothing unexpected happens
(and something unexpected always happens...)


There were some disagreements on IRC a few days ago about what should
and should not go into the release because of insufficient fuzzing and
the danger of introducing security issues.

To avoid conflicts around this in the future, I'd suggest (for future
releases) to create the release branch a significant time (e.g. a month)
before doing the actual release.

Opinions?


It's a good idea, but we need to be strict about it. As in, we need to 
state that the moment the branch is made it's a definite feature freeze, 
and only fixes, documentation changes and similar may be cherry-picked 
into it (meaning nothing that usually comes with a version bump, even if 
micro), much like we do for a point release, even if the initial release 
was not tagged yet.


Reverting something in the release branch is already going to be dirty 
no matter what, because we do a minor bump to ensure the release has its 
own soname. Right now that'd mean 5.0 will be lavf 59.13, while lacking 
a demuxer available in lavf 59.12

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

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

[FFmpeg-devel] [PATCH] lavc/flac_parser: use a custom FIFO implementation

2022-01-02 Thread Anton Khirnov 
FLAC parser currently uses AVFifoBuffer in a highly non-trivial manner,
modifying its "internals" (the whole struct is currently public, but no
other code touches its contents directly). E.g. it does not use any
av_fifo functions for reading the FIFO contents, but implements its own.

Reimplement the needed parts of the AVFifoBuffer API in the FLAC parser,
making it completely self-contained. This will allow us to make
AVFifoBuffer private.
---
 libavcodec/flac_parser.c | 194 +++
 1 file changed, 156 insertions(+), 38 deletions(-)

Dropped [rw]ndx completely as they are not necessary - the only thing we
need in addition to read/write pointers is single flag that
distinguishes between full/empty when rptr==wptr.
---

diff --git a/libavcodec/flac_parser.c b/libavcodec/flac_parser.c
index 3b27b152fc..cd9a2cb574 100644
--- a/libavcodec/flac_parser.c
+++ b/libavcodec/flac_parser.c
@@ -34,7 +34,6 @@
 
 #include "libavutil/attributes.h"
 #include "libavutil/crc.h"
-#include "libavutil/fifo.h"
 #include "bytestream.h"
 #include "parser.h"
 #include "flac.h"
@@ -57,6 +56,14 @@
 #define MAX_FRAME_HEADER_SIZE 16
 #define MAX_FRAME_VERIFY_SIZE (MAX_FRAME_HEADER_SIZE + 1)
 
+typedef struct FifoBuffer {
+uint8_t *buffer;
+uint8_t *end;
+uint8_t *rptr;
+uint8_t *wptr;
+int empty;
+} FifoBuffer;
+
 typedef struct FLACHeaderMarker {
 int offset;   /**< byte offset from start of FLACParseContext->buffer 
*/
 int link_penalty[FLAC_MAX_SEQUENTIAL_HEADERS]; /**< array of local scores
@@ -84,7 +91,7 @@ typedef struct FLACParseContext {
 int nb_headers_buffered;   /**< number of headers that are buffered   
*/
 int best_header_valid; /**< flag set when the parser returns junk;
 if set return best_header next time   
*/
-AVFifoBuffer *fifo_buf;/**< buffer to store all data until headers
+FifoBuffer fifo_buf;   /**< buffer to store all data until headers
 can be verified   
*/
 int end_padded;/**< specifies if fifo_buf's end is padded 
*/
 uint8_t *wrap_buf; /**< general fifo read buffer when wrapped 
*/
@@ -127,6 +134,18 @@ static int frame_header_is_valid(AVCodecContext *avctx, 
const uint8_t *buf,
 return 1;
 }
 
+static size_t flac_fifo_size(const FifoBuffer *f)
+{
+if (f->wptr <= f->rptr && !f->empty)
+return (f->wptr - f->buffer) + (f->end - f->rptr);
+return f->wptr - f->rptr;
+}
+
+static size_t flac_fifo_space(const FifoBuffer *f)
+{
+return f->end - f->buffer - flac_fifo_size(f);
+}
+
 /**
  * Non-destructive fast fifo pointer fetching
  * Returns a pointer from the specified offset.
@@ -143,7 +162,7 @@ static int frame_header_is_valid(AVCodecContext *avctx, 
const uint8_t *buf,
 static uint8_t *flac_fifo_read_wrap(FLACParseContext *fpc, int offset, int len,
 uint8_t **wrap_buf, int *allocated_size)
 {
-AVFifoBuffer *f   = fpc->fifo_buf;
+FifoBuffer   *f   = &fpc->fifo_buf;
 uint8_t *start= f->rptr + offset;
 uint8_t *tmp_buf;
 
@@ -180,9 +199,8 @@ static uint8_t *flac_fifo_read_wrap(FLACParseContext *fpc, 
int offset, int len,
  * A second call to flac_fifo_read (with new offset and len) should be called
  * to get the post-wrap buf if the returned len is less than the requested.
  **/
-static uint8_t *flac_fifo_read(FLACParseContext *fpc, int offset, int *len)
+static uint8_t *flac_fifo_read(FifoBuffer *f, int offset, int *len)
 {
-AVFifoBuffer *f   = fpc->fifo_buf;
 uint8_t *start= f->rptr + offset;
 
 if (start >= f->end)
@@ -191,6 +209,108 @@ static uint8_t *flac_fifo_read(FLACParseContext *fpc, int 
offset, int *len)
 return start;
 }
 
+static int flac_fifo_grow(FifoBuffer *f, size_t inc)
+{
+size_t size_old = f->end - f->buffer;
+size_t offset_r = f->rptr - f->buffer;
+size_t offset_w = f->wptr - f->buffer;
+size_t size_new;
+
+uint8_t *tmp;
+
+if (size_old > SIZE_MAX - inc)
+return AVERROR(EINVAL);
+size_new = size_old + inc;
+
+tmp = av_realloc(f->buffer, size_new);
+if (!tmp)
+return AVERROR(ENOMEM);
+
+// move the data from the beginning of the ring buffer
+// to the newly allocated space
+if (offset_w <= offset_r && !f->empty) {
+const size_t copy = FFMIN(inc, offset_w);
+memcpy(tmp + size_old, tmp, copy);
+if (copy < offset_w) {
+memmove(tmp, tmp + copy, offset_w - copy);
+offset_w -= copy;
+} else
+offset_w = size_old + copy;
+}
+
+f->buffer = tmp;
+f->end= f->buffer + size_new;
+f->rptr   = f->buffer + offset_r;
+f->wptr   = f->buffer + offset_w;
+
+return 0;
+}
+
+static int flac_fifo_write(FifoBuffer *f, const uint8_t *src, size_t size)
+{
+uint8_t *wptr;
+
+if (flac_fifo_space(f) < size) {
+

Re: [FFmpeg-devel] 5.0 release

2022-01-02 Thread Anton Khirnov 
Quoting Michael Niedermayer (2021-12-31 20:40:24)
> On Fri, Dec 31, 2021 at 10:45:46PM +0530, Gyan Doshi wrote:
> > 
> > 
> > On 2021-12-31 10:22 pm, Michael Niedermayer wrote:
> > > On Tue, Dec 28, 2021 at 12:55:14AM +0100, Michael Niedermayer wrote:
> > > > On Wed, Dec 22, 2021 at 05:44:42PM +0100, Jean-Baptiste Kempf wrote:
> > > > > On Wed, 22 Dec 2021, at 15:05, James Almer wrote:
> > > > > > Is the December target to get into the feature freeze schedule from
> > > > > > distros?
> > > > > No, it was set by me, in order to get the distro freezes from January.
> > > > > 
> > > > > We can miss the target a bit this year, and then make it better for 
> > > > > 2022.
> > > > as you seem to know the distro freeze shedules
> > > > can you clarify "a bit" ?
> > > > 
> > > > iam asking just in case the channel patch doesnt make it before
> > > > so i know when its time to stop waiting for it
> > > ok
> > > when do people want me to make the branch ?
> > > any preferrances ?
> > > should i do it now or continue waiting?
> > > 
> > > I saw on IRC some sugestions to make it at a past commit to keep some
> > > code out
> > 
> > It would be nice to have a public date set a few days into the future.
> 
> yes, i intended to do that, unless people wanted a ASAP/NOW branch
> 
> i guess 3rd january seems like a good choice
> 1st and 2nd as being close to newyear probably would not be ideal so
> 3rd seems the soonest good date
> but we can push this out more if people want? or also do it earlier
> of course that assumes nothing unexpected happens
> (and something unexpected always happens...)

There were some disagreements on IRC a few days ago about what should
and should not go into the release because of insufficient fuzzing and
the danger of introducing security issues.

To avoid conflicts around this in the future, I'd suggest (for future
releases) to create the release branch a significant time (e.g. a month)
before doing the actual release.

Opinions?

-- 
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] GitHub Integration

2022-01-02 Thread Lynne 
2 Jan 2022, 04:28 by softwo...@hotmail.com:

>
>
>> -Original Message-
>> From: ffmpeg-devel  On Behalf Of Soft Works
>> Sent: Tuesday, December 28, 2021 10:58 PM
>> To: FFmpeg development discussions and patches 
>> Subject: Re: [FFmpeg-devel] GitHub Integration
>>
>> One component of the GitHub "Bridge" is a mirror of the ffmpeg-devel
>> mailing list as a Git repository which provides a web interfaces, can be
>> cloned via Git and can also be accessed from Atom feed readers.
>> This allows to follow the mailing list without subscribing. The web UI
>> might not be everybody's taste, though. It's the same that is used for
>> Linux kernel mailing lists (https://lore.kernel.org/git/).
>> I had to set this up as it's a requirement for the GitHub "Bridge", but
>> maybe it's useful for someone in other ways:
>>
>> https://master.gitmailbox.com/ffmpegdev/
>>
>
>
> I have just ACTIVATED patch submission via GitHub and submitted the first 
> patch through this method.
>
> Pull requests can be created in this repository (for now):
>
> https://github.com/ffstaging/FFmpeg
>
>
> What's not nice is that the submitted e-mail shows "ffmpegagent" as sender
> and patchwork is showing it under that name as well.
>
> We'll need to see how this can be improved.
>

I don't like it. Can't it use the author's name for emails?
___
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 v9 4/6] lavc: Implement Dolby Vision RPU parsing

2022-01-02 Thread James Almer 

On 1/2/2022 1:18 AM, Andreas Rheinhardt wrote:

Niklas Haas:

From: Niklas Haas 

Based on a mixture of guesswork, partial documentation in patents, and
reverse engineering of real-world samples. Confirmed working for all the
samples I've thrown at it.

Contains some annoying machinery to persist these values in between
frames, which is needed in theory even though I've never actually seen a
sample that relies on it in practice. May or may not work.

Since the distinction matters greatly for parsing the color matrix
values, this includes a small helper function to guess the right profile
from the RPU itself in case the user has forgotten to forward the dovi
configuration record to the decoder. (Which in practice, only ffmpeg.c
and ffplay do..)

Notable omissions / deviations:
- CRC32 verification. This is based on the MPEG2 CRC32 type, which does
   not seem to be implemented in lavu. (And I don't care enough to do so)
- Linear interpolation support. Nothing documents this (beyond its
   existence) and no samples use it, so impossible to implement.
- All of the extension metadata blocks, but these contain values that
   seem largely congruent with ST2094, HDR10, or other existing forms of
   side data, so I will defer parsing/attaching them to a future commit.
- The patent describes a mechanism for predicting coefficients from
   previous RPUs, but the bit for the flag whether to use the
   prediction deltas or signal entirely new coefficients does not seem to
   be present in actual RPUs, so we ignore this subsystem entirely.
- In the patent's spec, the NLQ subsystem also loops over
   num_nlq_pivots, but even in the patent the number is hard-coded to one
   iteration rather than signalled. So we only store one set of coefs.

Heavily influenced by https://github.com/quietvoid/dovi_tool
Documentation drawn from US Patent 10,701,399 B2 and ETSI GS CCM 001

Signed-off-by: Niklas Haas 
---
  configure |   2 +
  libavcodec/Makefile   |   1 +
  libavcodec/dovi_rpu.c | 430 ++
  libavcodec/dovi_rpu.h |  71 +++
  4 files changed, 504 insertions(+)
  create mode 100644 libavcodec/dovi_rpu.c
  create mode 100644 libavcodec/dovi_rpu.h

diff --git a/configure b/configure
index 0ccd3bda11..68658a847f 100755
--- a/configure
+++ b/configure
@@ -2434,6 +2434,7 @@ CONFIG_EXTRA="
  cbs_vp9
  dirac_parse
  dnn
+dovi_rpu
  dvprofile
  exif
  faandct
@@ -2706,6 +2707,7 @@ cbs_mpeg2_select="cbs"
  cbs_vp9_select="cbs"
  dct_select="rdft"
  dirac_parse_select="golomb"
+dovi_rpu_select="golomb"
  dnn_suggest="libtensorflow libopenvino"
  dnn_deps="avformat swscale"
  error_resilience_select="me_cmp"
diff --git a/libavcodec/Makefile b/libavcodec/Makefile
index fb90ecea84..7364c7a91f 100644
--- a/libavcodec/Makefile
+++ b/libavcodec/Makefile
@@ -77,6 +77,7 @@ OBJS-$(CONFIG_CBS_MPEG2)   += cbs_mpeg2.o
  OBJS-$(CONFIG_CBS_VP9) += cbs_vp9.o
  OBJS-$(CONFIG_CRYSTALHD)   += crystalhd.o
  OBJS-$(CONFIG_DCT) += dct.o dct32_fixed.o dct32_float.o
+OBJS-$(CONFIG_DOVI_RPU)+= dovi_rpu.o
  OBJS-$(CONFIG_ERROR_RESILIENCE)+= error_resilience.o
  OBJS-$(CONFIG_EXIF)+= exif.o tiff_common.o
  OBJS-$(CONFIG_FAANDCT) += faandct.o
diff --git a/libavcodec/dovi_rpu.c b/libavcodec/dovi_rpu.c
new file mode 100644
index 00..fc2e1fb2a1
--- /dev/null
+++ b/libavcodec/dovi_rpu.c
@@ -0,0 +1,430 @@
+/*
+ * Dolby Vision RPU decoder
+ *
+ * Copyright (C) 2021 Jan Ekström
+ * Copyright (C) 2021 Niklas Haas
+ *
+ * This file is part of FFmpeg.
+ *
+ * FFmpeg is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public
+ * License as published by the Free Software Foundation; either
+ * version 2.1 of the License, or (at your option) any later version.
+ *
+ * FFmpeg is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+ * Lesser General Public License for more details.
+ *
+ * You should have received a copy of the GNU Lesser General Public
+ * License along with FFmpeg; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA
+ */
+
+#include "libavutil/buffer.h"
+
+#include "dovi_rpu.h"
+#include "golomb.h"
+#include "get_bits.h"
+
+enum {
+RPU_COEFF_FIXED = 0,
+RPU_COEFF_FLOAT = 1,
+};
+
+/**
+ * Private contents of vdr_ref.
+ */
+typedef struct DOVIVdrRef {
+AVDOVIDataMapping mapping;
+AVDOVIColorMetadata color;
+} DOVIVdrRef;
+
+void ff_dovi_ctx_unref(DOVIContext *s)
+{
+for (int i = 0; i < FF_ARRAY_ELEMS(s->vdr_ref); i++)
+av_buffer_unref(&s->vdr_ref[i]);
+
+/* Preserve the user-provided fields explicitly, reset everything else */
+*s = (DOVIContext) {
+.logctx = s->l

Re: [FFmpeg-devel] [PATCH] avformat/mxfdec: support MCA audio information

2022-01-02 Thread Marton Balint 




On Sat, 1 Jan 2022, Pierre-Anthony Lemieux wrote:


On Sat, Jan 1, 2022 at 5:35 PM Andreas Rheinhardt
 wrote:


Pierre-Anthony Lemieux:

Minor suggestion below.

In addition, will sample file(s) be added to FATE? Below are two examples:

http://ffmpeg-imf-samples-public.s3.us-west-1.amazonaws.com/callout_51_l_r_c_lfe_ls_rs.mxf
http://ffmpeg-imf-samples-public.s3.us-west-1.amazonaws.com/callout_51_l_c_r_ls_rs_lfe.mxf



These files are 1.62MiB each, having 49 packets of lossless audio. Would
it decrease coverage if this were reduced? After all, the amount of
audio should not matter for channel reorderings.


Each channel contains a synthesized human voice that announces the
name of the channel, so that a reviewer can, by simple inspection,
confirm the expected channel order. This will be particularly useful
when automatic channel reordering is performed.

The contents of each channel could be changed to a single tone with
each channel assigned a different tone, e.g. 1 to 6 kHz. This might
make the files shorter.


I'd rather stick to the human voice.

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

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

Re: [FFmpeg-devel] [PATCH] avformat/mxfdec: support MCA audio information

2022-01-02 Thread Marton Balint 




On Sat, 1 Jan 2022, Pierre-Anthony Lemieux wrote:


On Sat, Jan 1, 2022 at 5:11 PM Marton Balint  wrote:




On Sat, 1 Jan 2022, Pierre-Anthony Lemieux wrote:


Minor suggestion below.

In addition, will sample file(s) be added to FATE? Below are two examples:

http://ffmpeg-imf-samples-public.s3.us-west-1.amazonaws.com/callout_51_l_r_c_lfe_ls_rs.mxf
http://ffmpeg-imf-samples-public.s3.us-west-1.amazonaws.com/callout_51_l_c_r_ls_rs_lfe.mxf


Good idea, can someone with access please upload these to the fate mxf
folder?

[...]


I suggest adding the following audio channels, which are specified in
SMPTE ST 2067-8 [1] and have a direct mapping to ffmpeg audio
channels:AV_CH_STEREO_LEFT

urn:smpte:ul:060e2b34.0401010d.03020120.0300 (Left Total) ->
AV_CH_STEREO_LEFT
urn:smpte:ul:060e2b34.0401010d.03020120.0400 (RightTotal) ->
AV_CH_STEREO_RIGHT

[1] https://registry.smpte-ra.org/view/published/labels_view.html


Unfortunately this is a Dolby encoded stereo mix, not an ordinary LeftOnly
/ RightOnly mix. So I am not how this should be signalled.


My interpretation below.

In "mov_chan.c", AV_CH_LAYOUT_STEREO_DOWNMIX means
MOV_CH_LAYOUT_MATRIXSTEREO [1], which is defined in Core Audio [2].

LtRt, i.e. matrix-encoded audio, is not generally Dolby-specific [3].

[1] 
https://github.com/FFmpeg/FFmpeg/blob/d6b2357eddca392ee137cb2a92ff178a0a7d0cce/libavformat/mov_chan.c#L168
[2] 
https://developer.apple.com/documentation/coreaudiotypes/1572101-audio_channel_layout_tags/kaudiochannellayouttag_matrixstereo?changes=_8_7&language=objc
[3] https://en.wikipedia.org/wiki/Matrix_decoder


Well, ok, I will add these two labels then before pushing.

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

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

[FFmpeg-devel] [PATCH v2 5/5] avdevice/dshow: ensure pin's default format is set

2022-01-02 Thread Diederick Niehorster 
Fixes regression in a1c4929f: there apparently are devices out there
that expose a pin default format that has parameters outside the
capabilities of any of the formats exposed on the pin (sic?). The
VirtualCam plugin (v 2.0.5) of OBS-Studio (v 27.1.3) is such a device.
Now when a default format was found, but not selected when iterating all
formats, fall back to directly setting the default format.

Signed-off-by: Diederick Niehorster 
---
 libavdevice/dshow.c | 88 +++--
 1 file changed, 54 insertions(+), 34 deletions(-)

diff --git a/libavdevice/dshow.c b/libavdevice/dshow.c
index f2d95fa470..a435ae1807 100644
--- a/libavdevice/dshow.c
+++ b/libavdevice/dshow.c
@@ -758,6 +758,31 @@ static struct dshow_format_info 
*dshow_get_format_info(AM_MEDIA_TYPE *type)
 return fmt_info;
 }
 
+static void dshow_get_default_format(IPin *pin, IAMStreamConfig *config, enum 
dshowDeviceType devtype, AM_MEDIA_TYPE **type)
+{
+HRESULT hr;
+
+if ((hr = IAMStreamConfig_GetFormat(config, type)) != S_OK) {
+if (hr == E_NOTIMPL || !IsEqualGUID(&(*type)->majortype, devtype == 
VideoDevice ? &MEDIATYPE_Video : &MEDIATYPE_Audio)) {
+// default not available or of wrong type,
+// fall back to iterating exposed formats
+// until one of the right type is found
+IEnumMediaTypes* types = NULL;
+if (IPin_EnumMediaTypes(pin, &types) != S_OK)
+return;
+IEnumMediaTypes_Reset(types);
+while (IEnumMediaTypes_Next(types, 1, type, NULL) == S_OK) {
+if (IsEqualGUID(&(*type)->majortype, devtype == VideoDevice ? 
&MEDIATYPE_Video : &MEDIATYPE_Audio)) {
+break;
+}
+CoTaskMemFree(*type);
+*type = NULL;
+}
+IEnumMediaTypes_Release(types);
+}
+}
+}
+
 /**
  * Cycle through available formats available from the specified pin,
  * try to set parameters specified through AVOptions, or the pin's
@@ -813,32 +838,11 @@ dshow_cycle_formats(AVFormatContext *avctx, enum 
dshowDeviceType devtype,
 use_default = !dshow_should_set_format(avctx, devtype);
 if (use_default && pformat_set)
 {
-HRESULT hr;
-
 // get default
-if ((hr = IAMStreamConfig_GetFormat(config, &type)) != S_OK) {
-if (hr == E_NOTIMPL || !IsEqualGUID(&type->majortype, 
devtype==VideoDevice ? &MEDIATYPE_Video : &MEDIATYPE_Audio)) {
-// default not available or of wrong type,
-// fall back to iterating exposed formats
-// until one of the right type is found
-IEnumMediaTypes *types = NULL;
-if (IPin_EnumMediaTypes(pin, &types) != S_OK)
-goto end;
-IEnumMediaTypes_Reset(types);
-while (IEnumMediaTypes_Next(types, 1, &type, NULL) == S_OK) {
-if (IsEqualGUID(&type->majortype, devtype==VideoDevice ? 
&MEDIATYPE_Video : &MEDIATYPE_Audio)) {
-break;
-}
-CoTaskMemFree(type);
-type = NULL;
-}
-IEnumMediaTypes_Release(types);
-}
-
-if (!type)
-// this pin does not expose any formats of the expected type
-goto end;
-}
+dshow_get_default_format(pin, config, devtype, &type);
+if (!type)
+// this pin does not expose any formats of the expected type
+goto end;
 
 if (type) {
 // interrogate default format, so we know what to search for below
@@ -1040,15 +1044,31 @@ next:
 CoTaskMemFree(type);
 type = NULL;
 }
-// previously found a matching VIDEOINFOHEADER format and stored
-// it for safe keeping. Searching further for a matching
-// VIDEOINFOHEADER2 format yielded nothing. So set the pin's
-// format based on the VIDEOINFOHEADER format.
-// NB: this never applies to an audio format because
-// previous_match_type always NULL in that case
-if (pformat_set && !format_set && previous_match_type) {
-if (IAMStreamConfig_SetFormat(config, previous_match_type) == S_OK)
-format_set = 1;
+
+// set the pin's format, if wanted
+if (pformat_set && !format_set) {
+if (previous_match_type) {
+// previously found a matching VIDEOINFOHEADER format and stored
+// it for safe keeping. Searching further for a matching
+// VIDEOINFOHEADER2 format yielded nothing. So set the pin's
+// format based on the VIDEOINFOHEADER format.
+// NB: this never applies to an audio format because
+// previous_match_type always NULL in that case
+if (IAMStreamConfig_SetFormat(config, previous_match_type) == S_OK)
+format_set = 1;
+}
+else if (

[FFmpeg-devel] [PATCH v2 4/5] avdevice/dshow: only set pin format if wanted

2022-01-02 Thread Diederick Niehorster 
Signed-off-by: Diederick Niehorster 
---
 libavdevice/dshow.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/libavdevice/dshow.c b/libavdevice/dshow.c
index 4b6887881d..f2d95fa470 100644
--- a/libavdevice/dshow.c
+++ b/libavdevice/dshow.c
@@ -1046,7 +1046,7 @@ next:
 // format based on the VIDEOINFOHEADER format.
 // NB: this never applies to an audio format because
 // previous_match_type always NULL in that case
-if (!format_set && previous_match_type) {
+if (pformat_set && !format_set && previous_match_type) {
 if (IAMStreamConfig_SetFormat(config, previous_match_type) == S_OK)
 format_set = 1;
 }
-- 
2.28.0.windows.1

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

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

[FFmpeg-devel] [PATCH v2 3/5] avdevice/dshow: fix crash on x86

2022-01-02 Thread Diederick Niehorster 
fix regression introduced in 911ba8417e8881a7380842e69e11ca05fdc46575.
Removal of WINAPI decoration from function signatures caused crashed
when using dshow on x86.

Fixes #9568

Signed-off-by: Diederick Niehorster 
---
 libavdevice/dshow_capture.h| 120 ++---
 libavdevice/dshow_enummediatypes.c |   8 +-
 libavdevice/dshow_enumpins.c   |   8 +-
 libavdevice/dshow_filter.c |  24 +++---
 libavdevice/dshow_pin.c|  48 ++--
 5 files changed, 104 insertions(+), 104 deletions(-)

diff --git a/libavdevice/dshow_capture.h b/libavdevice/dshow_capture.h
index 5a2691518c..21f5cf7e83 100644
--- a/libavdevice/dshow_capture.h
+++ b/libavdevice/dshow_capture.h
@@ -70,7 +70,7 @@ enum dshowSourceFilterType {
 };
 
 #define DECLARE_QUERYINTERFACE(prefix, class, ...)   \
-long \
+long WINAPI  \
 ff_dshow_##prefix##_QueryInterface(class *this, const GUID *riid, void 
**ppvObject) \
 {\
 struct GUIDoffset ifaces[] = __VA_ARGS__;\
@@ -93,14 +93,14 @@ ff_dshow_##prefix##_QueryInterface(class *this, const GUID 
*riid, void **ppvObje
 return E_NOINTERFACE;\
 }
 #define DECLARE_ADDREF(prefix, class)\
-unsigned long\
+unsigned long WINAPI \
 ff_dshow_##prefix##_AddRef(class *this)  \
 {\
 dshowdebug("ff_dshow_"AV_STRINGIFY(prefix)"_AddRef(%p)\t%ld\n", this, 
this->ref+1); \
 return InterlockedIncrement(&this->ref); \
 }
 #define DECLARE_RELEASE(prefix, class)   \
-unsigned long\
+unsigned long WINAPI \
 ff_dshow_##prefix##_Release(class *this) \
 {\
 long ref = InterlockedDecrement(&this->ref); \
@@ -167,34 +167,34 @@ struct DShowPin {
 IMemInputPinVtbl *imemvtbl;
 };
 
-long  ff_dshow_pin_QueryInterface  (DShowPin *, const GUID *, 
void **);
-unsigned long ff_dshow_pin_AddRef  (DShowPin *);
-unsigned long ff_dshow_pin_Release (DShowPin *);
-long  ff_dshow_pin_Connect (DShowPin *, IPin *, const 
AM_MEDIA_TYPE *);
-long  ff_dshow_pin_ReceiveConnection   (DShowPin *, IPin *, const 
AM_MEDIA_TYPE *);
-long  ff_dshow_pin_Disconnect  (DShowPin *);
-long  ff_dshow_pin_ConnectedTo (DShowPin *, IPin **);
-long  ff_dshow_pin_ConnectionMediaType (DShowPin *, AM_MEDIA_TYPE 
*);
-long  ff_dshow_pin_QueryPinInfo(DShowPin *, PIN_INFO *);
-long  ff_dshow_pin_QueryDirection  (DShowPin *, PIN_DIRECTION 
*);
-long  ff_dshow_pin_QueryId (DShowPin *, wchar_t **);
-long  ff_dshow_pin_QueryAccept (DShowPin *, const 
AM_MEDIA_TYPE *);
-long  ff_dshow_pin_EnumMediaTypes  (DShowPin *, 
IEnumMediaTypes **);
-long  ff_dshow_pin_QueryInternalConnections(DShowPin *, IPin **, 
unsigned long *);
-long  ff_dshow_pin_EndOfStream (DShowPin *);
-long  ff_dshow_pin_BeginFlush  (DShowPin *);
-long  ff_dshow_pin_EndFlush(DShowPin *);
-long  ff_dshow_pin_NewSegment  (DShowPin *, 
REFERENCE_TIME, REFERENCE_TIME, double);
-
-long  ff_dshow_meminputpin_QueryInterface  (DShowMemInputPin 
*, const GUID *, void **);
-unsigned long ff_dshow_meminputpin_AddRef  (DShowMemInputPin 
*);
-unsigned long ff_dshow_meminputpin_Release (DShowMemInputPin 
*);
-long  ff_dshow_meminputpin_GetAllocator(DShowMemInputPin 
*, IMemAllocator **);
-long  ff_dshow_meminputpin_NotifyAllocator (DShowMemInputPin 
*, IMemAllocator *, BOOL);
-long  ff_dshow_meminputpin_GetAllocatorRequirements(DShowMemInputPin 
*, ALLOCATOR_PROPERTIES *);
-long  ff_dshow_meminputpin_Receive (DShowMemInputPin 
*, IMediaSample *);
-long  ff_dshow_meminputpin_ReceiveMultiple (DShowMemInputPin 
*, IMediaSample **, long, long *);
-long  ff_dshow_meminputpin_ReceiveCanBlock (DShowMemInputPin 
*);
+long  WINAPI ff_dshow_pin_QueryInterface  (DShowPin *, const 
GU

[FFmpeg-devel] [PATCH v2 2/5] avdevice/dshow: proper cleanup of queried media types

2022-01-02 Thread Diederick Niehorster 
Signed-off-by: Diederick Niehorster 
---
 libavdevice/dshow.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/libavdevice/dshow.c b/libavdevice/dshow.c
index 30f1be1ead..4b6887881d 100644
--- a/libavdevice/dshow.c
+++ b/libavdevice/dshow.c
@@ -953,7 +953,7 @@ dshow_cycle_formats(AVFormatContext *avctx, enum 
dshowDeviceType devtype,
 av_log(avctx, AV_LOG_INFO, "(%s)", chroma ? chroma : 
"unknown");
 
 av_log(avctx, AV_LOG_INFO, "\n");
-continue;
+goto next;
 }
 if (requested_video_codec_id != AV_CODEC_ID_RAWVIDEO) {
 if (requested_video_codec_id != fmt_info->codec_id)
@@ -1038,6 +1038,7 @@ next:
 if (type && type->pbFormat)
 CoTaskMemFree(type->pbFormat);
 CoTaskMemFree(type);
+type = NULL;
 }
 // previously found a matching VIDEOINFOHEADER format and stored
 // it for safe keeping. Searching further for a matching
-- 
2.28.0.windows.1

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

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

[FFmpeg-devel] [PATCH v2 1/5] avdevice/dshow: tv_tuner_audio_dialog cleanup missing

2022-01-02 Thread Diederick Niehorster 
Cleanup was missing for when the show_analog_tv_tuner_audio_dialog is
true.

Signed-off-by: Diederick Niehorster 
---
 libavdevice/dshow_crossbar.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/libavdevice/dshow_crossbar.c b/libavdevice/dshow_crossbar.c
index 2438683cde..961defe690 100644
--- a/libavdevice/dshow_crossbar.c
+++ b/libavdevice/dshow_crossbar.c
@@ -204,5 +204,9 @@ end:
 IAMTVTuner_Release(tv_tuner_filter);
 if (tv_tuner_base_filter)
 IBaseFilter_Release(tv_tuner_base_filter);
+if (tv_audio_filter)
+IAMAudioInputMixer_Release(tv_audio_filter);
+if (tv_audio_base_filter)
+IBaseFilter_Release(tv_audio_base_filter);
 return hr;
 }
-- 
2.28.0.windows.1

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

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

[FFmpeg-devel] [PATCH v2 0/5] avdevice/dshow fixups

2022-01-02 Thread Diederick Niehorster 
These five patches fix two regressions (one crashing bug making dshow
unusable on x86, and one regression introduced by my recent patches due
to which devices that seem to not behave according to spec but worked
fine before my patches could no longer be used.
They furthermore fix three small issues i found looking through the dshow code: 
2x needed cleanup not being done, and one where to skip setting format for a 
pin when its useless.

new in v2 is fixing of the x86 crash

Diederick Niehorster (5):
  avdevice/dshow: tv_tuner_audio_dialog cleanup missing
  avdevice/dshow: proper cleanup of queried media types
  avdevice/dshow: fix crash on x86
  avdevice/dshow: only set pin format if wanted
  avdevice/dshow: ensure pin's default format is set

 libavdevice/dshow.c|  93 +-
 libavdevice/dshow_capture.h| 120 ++---
 libavdevice/dshow_crossbar.c   |   4 +
 libavdevice/dshow_enummediatypes.c |   8 +-
 libavdevice/dshow_enumpins.c   |   8 +-
 libavdevice/dshow_filter.c |  24 +++---
 libavdevice/dshow_pin.c|  48 ++--
 7 files changed, 165 insertions(+), 140 deletions(-)

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