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

[Andreas Rheinhardt]

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

I still don't like storing ENOMEM in the AVIOContext and I don't see why
having to check the error is so burdensome. But if you want it so bad,
then go ahead.

- 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 5/5] avfilter/vf_blend: fix un-checked potential memory allocation failure

[Wu, Jianhua]

 Lynne:
> Sent: Monday, January 3, 2022 10:23 AM
> To: FFmpeg development discussions and patches  de...@ffmpeg.org>
> Subject: Re: [FFmpeg-devel] [PATCH 5/5] avfilter/vf_blend: fix un-checked
> potential memory allocation failure
> 
> 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.
> 

I'm afraid of it's not the problem of the blend_vulkan filter. Could you help 
try the other Vulkan filters and
see if they are still work?

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

Removing it is okay if it  is not used totally. And I' sorry we may have a 
mistake here.
Below is my development environment on this patch:
Operating System: Windows 10
Physical Device: Nvidia RTX3070
Driver version: GeForce Game Ready Driver 497.29
I'll add something like these to commit message if I fix similar problems.

And there is one more question, may I know why there is a suffix "@ffmpeg.org"
behind my commit Author email?

Thanks,
Jianhua
___
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 v10 1/6] lavu/frame: Add Dolby Vision metadata side data type

[Niklas Haas]

On Mon, 03 Jan 2022 01:27:22 +0100 Niklas Haas  wrote:
> +/**
> + * 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 AVDOVINLQMethod nlq_method_idc;
> +uint32_t num_x_partitions;
> +uint32_t num_y_partitions;
> +AVDOVINLQParams nlq[3]; /* per component */
> +} AVDOVIDataMapping;

It just occurred to me that we also cannot make AVDOVIReshapingCurve or
AVDOVINLQParams extensible if we're going to store them in an array.

So I think that locks us into making these structs fixed size, avoiding
the issue altogether, but probably making future extensions to this API
somewhat uglier.

Thoughts?
___
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 v10 1/6] lavu/frame: Add Dolby Vision metadata side data type

[Andreas Rheinhardt]

Niklas Haas:
> On Mon, 03 Jan 2022 01:27:22 +0100 Niklas Haas  wrote:
>> +/**
>> + * 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 AVDOVINLQMethod nlq_method_idc;
>> +uint32_t num_x_partitions;
>> +uint32_t num_y_partitions;
>> +AVDOVINLQParams nlq[3]; /* per component */
>> +} AVDOVIDataMapping;
> 
> It just occurred to me that we also cannot make AVDOVIReshapingCurve or
> AVDOVINLQParams extensible if we're going to store them in an array.
> 
> So I think that locks us into making these structs fixed size, avoiding
> the issue altogether, but probably making future extensions to this API
> somewhat uglier.
> 
> Thoughts?

Future extensions are still possible by adding e.g.
"AVDOVIReshapingCurveExtension curves_ext[3]" (which is probably what
you meant by uglier), so I am ok with this approach.
(Hopefully we won't need multiple extensions...).

- 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 v11] lavu/frame: Add Dolby Vision metadata side data type

[Niklas Haas]

From: Niklas Haas 

Yeah, I think I agree that this is probably the best compromise here.

Updated documentation (and also changed one unnecessarily-large uint64_t
to uint16_t)

---
In order to be able to extend this struct later (as the Dolby Vision RPU
evolves), all of the 'container' 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 | 166 ++
 libavutil/frame.c |   1 +
 libavutil/frame.h |   9 ++-
 libavutil/version.h   |   2 +-
 6 files changed, 204 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..3d11e02bff 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,169 @@ 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.
+ */
+#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.
+ */
+typedef struct AVDOVINLQParams {
+uint16_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 inve

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

[Andreas Rheinhardt]

p...@sandflow.com:
> 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)

Please use FATE_SAMPLES_FFMPEG, the fork is dead.
Also given that IMF is unusable without the MXF demuxer, it makes more
sense to just add such a dependency to configure. I sent a patch for this.

> +
> +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

Could the filesize be reduced by using a smaller resolution?

> +#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,  

Re: [FFmpeg-devel] [RFC] avdevice: lock to minor version of avformat

[Andreas Rheinhardt]

Diederick C. Niehorster:
> FWIW, the macro
> #define AV_MAKE_MAJOR_MINOR_FUNC_NAME(name,major,minor)
> AV_GLUE(av,name)AV_GLUE(_version_,major)AV_GLUE(_,minor)
> doesn't compile on patchwork
> (https://patchwork.ffmpeg.org/check/49062/), but worked fine for me on
> MSVC. Is MSVC non-compliant somehow? Suggestions appreciated, I'm no
> star in C macros.
> 

AV_GLUE(av,name)AV_GLUE(_version_,major)AV_GLUE(_,minor) will yield
three preprocessor tokens after macro expansion, one for each AV_GLUE.
There will be no whitespace between them and yet they are different
preprocessor tokens. After the preprocessor has been run, these
preprocessor tokens are directly converted into tokens; there is no
"rescan" that joins preprocessor tokens that are not separated by
whitespace (and therefore appear to you to be a single token). And
therefore the result is incompliant.
It seems like MSVC does such a rescan, but the specs allow a compiler to
omit it (and GCC apparently does so).

> In any case, this is a discussion starter, so let it not compiling not
> hold us back from that.
> 
> Cheers,
> Dee
> 
> On Sun, Dec 26, 2021 at 6:17 PM Diederick Niehorster  
> wrote:
>>
>> As per discussion on the list (
>> https://ffmpeg.org/pipermail/ffmpeg-devel/2021-June/281513.html, see
>> especially https://ffmpeg.org/pipermail/ffmpeg-devel/2021-June/281586.html),
>> to resolve the the unholy ABI-relationship between libavdevice and
>> libavformat and allow easier working on the part of the avdevice API
>> that lives in avformat, lock avdevice to a specific major and minor
>> version of avformat.
>>
>> Signed-off-by: Diederick Niehorster 
>> ---
>>  libavdevice/avdevice.c | 10 ++
>>  libavdevice/version.h  | 10 ++
>>  libavformat/utils.c|  5 +
>>  libavformat/version.h  | 11 +++
>>  libavutil/macros.h |  2 ++
>>  5 files changed, 38 insertions(+)
>>
>> diff --git a/libavdevice/avdevice.c b/libavdevice/avdevice.c
>> index 8f460c7564..b608ec532f 100644
>> --- a/libavdevice/avdevice.c
>> +++ b/libavdevice/avdevice.c
>> @@ -38,6 +38,16 @@ unsigned avdevice_version(void)
>>  return LIBAVDEVICE_VERSION_INT;
>>  }
>>
>> +unsigned avdevice_version_same_minor()
>> +{
>> +// check version of loaded lavf has same major and minor version as
>> +// this library was compiled against
>> +if ((avformat_version_same_minor()) & ~0xFF != (LIBAVFORMAT_VERSION_INT 
>> & ~0xFF))
>> +abort();
>> +
>> +return avformat_version();
>> +}
>> +
>>  const char * avdevice_configuration(void)
>>  {
>>  return FFMPEG_CONFIGURATION;
>> diff --git a/libavdevice/version.h b/libavdevice/version.h
>> index 41f568d6b0..4c511a7f53 100644
>> --- a/libavdevice/version.h
>> +++ b/libavdevice/version.h
>> @@ -26,6 +26,7 @@
>>   */
>>
>>  #include "libavutil/version.h"
>> +#include "libavutil/macros.h"
>>
>>  #define LIBAVDEVICE_VERSION_MAJOR  59
>>  #define LIBAVDEVICE_VERSION_MINOR   1
>> @@ -48,4 +49,13 @@
>>   */
>>  #define FF_API_DEVICE_CAPABILITIES (LIBAVDEVICE_VERSION_MAJOR < 60)
>>
>> +/**
>> + * avdevice_version_same_minor() expands to a function with
>> + * the same minor and major version it was compiled against
>> + * encoded in it. Enables linking locking to the minor version
>> + * of other libraries they were compiled against.
>> + */
>> +#define avdevice_version_same_minor 
>> AV_MAKE_MAJOR_MINOR_FUNC_NAME(device,LIBAVFORMAT_VERSION_MAJOR,LIBAVFORMAT_VERSION_MINOR)
>> +unsigned avdevice_version_same_minor();
>> +
>>  #endif /* AVDEVICE_VERSION_H */
>> diff --git a/libavformat/utils.c b/libavformat/utils.c
>> index 332ba534d2..607a777c3f 100644
>> --- a/libavformat/utils.c
>> +++ b/libavformat/utils.c
>> @@ -63,6 +63,11 @@ unsigned avformat_version(void)
>>  return LIBAVFORMAT_VERSION_INT;
>>  }
>>
>> +unsigned avformat_version_same_minor()
>> +{
>> +return avformat_version();
>> +}
>> +
>>  const char *avformat_configuration(void)
>>  {
>>  return FFMPEG_CONFIGURATION;
>> diff --git a/libavformat/version.h b/libavformat/version.h
>> index 379a68cc7c..2423800687 100644
>> --- a/libavformat/version.h
>> +++ b/libavformat/version.h
>> @@ -28,6 +28,7 @@
>>   */
>>
>>  #include "libavutil/version.h"
>> +#include "libavutil/macros.h"
>>
>>  // Major bumping may affect Ticket5467, 5421, 5451(compatibility with 
>> Chromium)
>>  // Also please add any ticket numbers that you believe might be affected 
>> here
>> @@ -63,4 +64,14 @@
>>
>>
>>  #define FF_API_R_FRAME_RATE1
>> +
>> +/**
>> + * avformat_version_same_minor() expands to a function with
>> + * the same minor and major version it was compiled against
>> + * encoded in it. Enables linking locking to the minor version
>> + * of other libraries they were compiled against.
>> + */
>> +#define avformat_version_same_minor 
>> AV_MAKE_MAJOR_MINOR_FUNC_NAME(format,LIBAVFORMAT_VERSION_MAJOR,LIBAVFORMAT_VERSION_MINOR)
>> +unsigned avformat_version_same_minor();
>> +
>>  #endif /* AVFORMAT_VERSION_H */
>> diff --git a/libavutil/macros

Re: [FFmpeg-devel] [RFC v2] avdevice: lock to minor version of avformat

[Andreas Rheinhardt]

Diederick Niehorster:
> As per discussion on the list (
> https://ffmpeg.org/pipermail/ffmpeg-devel/2021-June/281513.html, see
> especially https://ffmpeg.org/pipermail/ffmpeg-devel/2021-June/281586.html),
> to resolve the the unholy ABI-relationship between libavdevice and
> libavformat and allow easier working on the part of the avdevice API
> that lives in avformat, lock avdevice to a specific major and minor
> version of avformat.
> 
> Signed-off-by: Diederick Niehorster 
> ---

1. If this patch intends to make it illegal to use libavdevice together
with libavformat with a different minor version than it was compiled
against, then the most basic requirement of this is to actually properly
document it and not add stuff that might cause linking failure if used
in a way that runs afoul of your undocumented new requirements.
2. Is avdevice_version_same_minor() supposed to cause linking failures
by virtue of its AV_MAKE_MAJOR_MINOR_FUNC_NAME generated symbol name? Or
is the user actually supposed to run this function explicitly?
Anyway, it is not clear from the documentation that this function calls
abort on failure.

>  libavdevice/avdevice.c | 10 ++
>  libavdevice/version.h  | 10 ++
>  libavformat/utils.c|  5 +
>  libavformat/version.h  | 11 +++
>  libavutil/macros.h |  3 +++
>  5 files changed, 39 insertions(+)
> 
> diff --git a/libavdevice/avdevice.c b/libavdevice/avdevice.c
> index 8f460c7564..0c9b702eda 100644
> --- a/libavdevice/avdevice.c
> +++ b/libavdevice/avdevice.c
> @@ -38,6 +38,16 @@ unsigned avdevice_version(void)
>  return LIBAVDEVICE_VERSION_INT;
>  }
>  
> +unsigned avdevice_version_same_minor()
> +{
> +// check version of loaded lavf has same major and minor version as
> +// this library was compiled against
> +if ((avformat_version_same_minor()) & ~0xFF != (LIBAVFORMAT_VERSION_INT 
> & ~0xFF))
> +abort();
> +
> +return avdevice_version();
> +}
> +
>  const char * avdevice_configuration(void)
>  {
>  return FFMPEG_CONFIGURATION;
> diff --git a/libavdevice/version.h b/libavdevice/version.h
> index 41f568d6b0..83d8c67511 100644
> --- a/libavdevice/version.h
> +++ b/libavdevice/version.h
> @@ -26,6 +26,7 @@
>   */
>  
>  #include "libavutil/version.h"
> +#include "libavutil/macros.h"
>  
>  #define LIBAVDEVICE_VERSION_MAJOR  59
>  #define LIBAVDEVICE_VERSION_MINOR   1
> @@ -48,4 +49,13 @@
>   */
>  #define FF_API_DEVICE_CAPABILITIES (LIBAVDEVICE_VERSION_MAJOR < 60)
>  
> +/**
> + * avdevice_version_same_minor() expands to a function with
> + * the same minor and major version it was compiled against
> + * encoded in it. Enables locking to the minor version of
> + * other libraries they were compiled against.
> + */
> +#define avdevice_version_same_minor 
> AV_MAKE_MAJOR_MINOR_FUNC_NAME(device,LIBAVFORMAT_VERSION_MAJOR,LIBAVFORMAT_VERSION_MINOR)
> +unsigned avdevice_version_same_minor();
> +
>  #endif /* AVDEVICE_VERSION_H */
> diff --git a/libavformat/utils.c b/libavformat/utils.c
> index 332ba534d2..607a777c3f 100644
> --- a/libavformat/utils.c
> +++ b/libavformat/utils.c
> @@ -63,6 +63,11 @@ unsigned avformat_version(void)
>  return LIBAVFORMAT_VERSION_INT;
>  }
>  
> +unsigned avformat_version_same_minor()
> +{
> +return avformat_version();
> +}
> +
>  const char *avformat_configuration(void)
>  {
>  return FFMPEG_CONFIGURATION;
> diff --git a/libavformat/version.h b/libavformat/version.h
> index 379a68cc7c..661d074b12 100644
> --- a/libavformat/version.h
> +++ b/libavformat/version.h
> @@ -28,6 +28,7 @@
>   */
>  
>  #include "libavutil/version.h"
> +#include "libavutil/macros.h"
>  
>  // Major bumping may affect Ticket5467, 5421, 5451(compatibility with 
> Chromium)
>  // Also please add any ticket numbers that you believe might be affected here
> @@ -63,4 +64,14 @@
>  
>  
>  #define FF_API_R_FRAME_RATE1
> +
> +/**
> + * avformat_version_same_minor() expands to a function with
> + * the same minor and major version it was compiled against
> + * encoded in it. Enables locking to the minor version of
> + * other libraries they were compiled against. 
> + */
> +#define avformat_version_same_minor 
> AV_MAKE_MAJOR_MINOR_FUNC_NAME(format,LIBAVFORMAT_VERSION_MAJOR,LIBAVFORMAT_VERSION_MINOR)
> +unsigned avformat_version_same_minor();
> +
>  #endif /* AVFORMAT_VERSION_H */
> diff --git a/libavutil/macros.h b/libavutil/macros.h
> index 2a7567c3ea..dab530a8a0 100644
> --- a/libavutil/macros.h
> +++ b/libavutil/macros.h
> @@ -73,6 +73,9 @@
>   * @}
>   */
>  
> +#define AV_MAKE_MAJOR_MINOR_FUNC_NAME_IMPL(name,major,minor) av ## name ## 
> _version_ ## major ## _ ## minor
> +#define AV_MAKE_MAJOR_MINOR_FUNC_NAME(name,major,minor) 
> AV_MAKE_MAJOR_MINOR_FUNC_NAME_IMPL(name,major,minor)
> +
>  #define AV_PRAGMA(s) _Pragma(#s)
>  
>  #define FFALIGN(x, a) (((x)+(a)-1)&~((a)-1))
> 

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

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

[Andreas Rheinhardt]

Andreas Rheinhardt:
> 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.
> 
>  libavcodec/raw.c | 40 +++-
>  libavcodec/raw.h | 13 +++--
>  libavcodec/rawdec.c  |  8 
>  libavcodec/utils.c   | 11 ---
>  libavdevice/dshow.c  |  2 +-
>  libavformat/avienc.c |  2 +-
>  libavformat/demux.c  |  2 +-
>  libavformat/movenc.c |  2 +-
>  8 files changed, 50 insertions(+), 30 deletions(-)
> 
> diff --git a/libavcodec/raw.c b/libavcodec/raw.c
> index 079d5c5d10..5efc1eb465 100644
> --- a/libavcodec/raw.c
> +++ b/libavcodec/raw.c
> @@ -28,7 +28,7 @@
>  #include "raw.h"
>  #include "libavutil/common.h"
>  
> -const PixelFormatTag ff_raw_pix_fmt_tags[] = {
> +static const PixelFormatTag raw_pix_fmt_tags[] = {
>  { AV_PIX_FMT_YUV420P, MKTAG('I', '4', '2', '0') }, /* Planar formats */
>  { AV_PIX_FMT_YUV420P, MKTAG('I', 'Y', 'U', 'V') },
>  { AV_PIX_FMT_YUV420P, MKTAG('y', 'v', '1', '2') },
> @@ -299,12 +299,12 @@ const PixelFormatTag ff_raw_pix_fmt_tags[] = {
>  
>  const struct PixelFormatTag *avpriv_get_raw_pix_fmt_tags(void)
>  {
> -return ff_raw_pix_fmt_tags;
> +return raw_pix_fmt_tags;
>  }
>  
>  unsigned int avcodec_pix_fmt_to_codec_tag(enum AVPixelFormat fmt)
>  {
> -const PixelFormatTag *tags = ff_raw_pix_fmt_tags;
> +const PixelFormatTag *tags = raw_pix_fmt_tags;
>  while (tags->pix_fmt >= 0) {
>  if (tags->pix_fmt == fmt)
>  return tags->fourcc;
> @@ -313,7 +313,7 @@ unsigned int avcodec_pix_fmt_to_codec_tag(enum 
> AVPixelFormat fmt)
>  return 0;
>  }
>  
> -const PixelFormatTag avpriv_pix_fmt_bps_avi[] = {
> +static const PixelFormatTag pix_fmt_bps_avi[] = {
>  { AV_PIX_FMT_PAL8,1 },
>  { AV_PIX_FMT_PAL8,2 },
>  { AV_PIX_FMT_PAL8,4 },
> @@ -326,7 +326,7 @@ const PixelFormatTag avpriv_pix_fmt_bps_avi[] = {
>  { AV_PIX_FMT_NONE,0 },
>  };
>  
> -const PixelFormatTag avpriv_pix_fmt_bps_mov[] = {
> +static const PixelFormatTag pix_fmt_bps_mov[] = {
>  { AV_PIX_FMT_PAL8,  1 },
>  { AV_PIX_FMT_PAL8,  2 },
>  { AV_PIX_FMT_PAL8,  4 },
> @@ -337,3 +337,33 @@ const PixelFormatTag avpriv_pix_fmt_bps_mov[] = {
>  { AV_PIX_FMT_PAL8, 33 },
>  { AV_PIX_FMT_NONE,  0 },
>  };
> +
> +static enum AVPixelFormat find_pix_fmt(const PixelFormatTag *tags,
> +   unsigned int fourcc)
> +{
> +while (tags->pix_fmt != AV_PIX_FMT_NONE) {
> +if (tag

Re: [FFmpeg-devel] [RFC v2] avdevice: lock to minor version of avformat

[Diederick C. Niehorster]

Hi Andreas,

Thanks for the comments!

On Mon, Jan 3, 2022 at 11:02 AM Andreas Rheinhardt
 wrote:
>
> Diederick Niehorster:
> > As per discussion on the list (
> > https://ffmpeg.org/pipermail/ffmpeg-devel/2021-June/281513.html, see
> > especially https://ffmpeg.org/pipermail/ffmpeg-devel/2021-June/281586.html),
> > to resolve the the unholy ABI-relationship between libavdevice and
> > libavformat and allow easier working on the part of the avdevice API
> > that lives in avformat, lock avdevice to a specific major and minor
> > version of avformat.
> >
> > Signed-off-by: Diederick Niehorster 
> > ---
>
> 1. If this patch intends to make it illegal to use libavdevice together
> with libavformat with a different minor version than it was compiled
> against, then the most basic requirement of this is to actually properly
> document it and not add stuff that might cause linking failure if used
> in a way that runs afoul of your undocumented new requirements.

Absolutely, documentation is required. Should that be in (amongst
local to the function in the header)?
I wanted to have the discussion first, or would docs be good to have
ready to help the discussion?

> 2. Is avdevice_version_same_minor() supposed to cause linking failures
> by virtue of its AV_MAKE_MAJOR_MINOR_FUNC_NAME generated symbol name? Or
> is the user actually supposed to run this function explicitly?
> Anyway, it is not clear from the documentation that this function calls
> abort on failure.

The implementation is as suggested by Nicolas as suggested here
https://ffmpeg.org/pipermail/ffmpeg-devel/2021-August/284492.html (And
thanks for letting me know about preprocessor rescan, my v2 fixes most
except ppc, see https://patchwork.ffmpeg.org/check/49132/, and now i
know why :p).

The idea is that it causes linker failure. I've tested this indeed,
when trying to load incompatible avformat and avdevice dlls the
dynamic linker throws an error. So strictly the function doesn't have
to abort, nor does it have to be called at all, but it's nicely
documenting.

> >  libavdevice/avdevice.c | 10 ++
> >  libavdevice/version.h  | 10 ++
> >  libavformat/utils.c|  5 +
> >  libavformat/version.h  | 11 +++
> >  libavutil/macros.h |  3 +++
> >  5 files changed, 39 insertions(+)
> >
> > diff --git a/libavdevice/avdevice.c b/libavdevice/avdevice.c
> > index 8f460c7564..0c9b702eda 100644
> > --- a/libavdevice/avdevice.c
> > +++ b/libavdevice/avdevice.c
> > @@ -38,6 +38,16 @@ unsigned avdevice_version(void)
> >  return LIBAVDEVICE_VERSION_INT;
> >  }
> >
> > +unsigned avdevice_version_same_minor()
> > +{
> > +// check version of loaded lavf has same major and minor version as
> > +// this library was compiled against
> > +if ((avformat_version_same_minor()) & ~0xFF != 
> > (LIBAVFORMAT_VERSION_INT & ~0xFF))
> > +abort();
> > +
> > +return avdevice_version();
> > +}
> > +
> >  const char * avdevice_configuration(void)
> >  {
> >  return FFMPEG_CONFIGURATION;
> > diff --git a/libavdevice/version.h b/libavdevice/version.h
> > index 41f568d6b0..83d8c67511 100644
> > --- a/libavdevice/version.h
> > +++ b/libavdevice/version.h
> > @@ -26,6 +26,7 @@
> >   */
> >
> >  #include "libavutil/version.h"
> > +#include "libavutil/macros.h"
> >
> >  #define LIBAVDEVICE_VERSION_MAJOR  59
> >  #define LIBAVDEVICE_VERSION_MINOR   1
> > @@ -48,4 +49,13 @@
> >   */
> >  #define FF_API_DEVICE_CAPABILITIES (LIBAVDEVICE_VERSION_MAJOR < 60)
> >
> > +/**
> > + * avdevice_version_same_minor() expands to a function with
> > + * the same minor and major version it was compiled against
> > + * encoded in it. Enables locking to the minor version of
> > + * other libraries they were compiled against.
> > + */
> > +#define avdevice_version_same_minor 
> > AV_MAKE_MAJOR_MINOR_FUNC_NAME(device,LIBAVFORMAT_VERSION_MAJOR,LIBAVFORMAT_VERSION_MINOR)
> > +unsigned avdevice_version_same_minor();
> > +
> >  #endif /* AVDEVICE_VERSION_H */
> > diff --git a/libavformat/utils.c b/libavformat/utils.c
> > index 332ba534d2..607a777c3f 100644
> > --- a/libavformat/utils.c
> > +++ b/libavformat/utils.c
> > @@ -63,6 +63,11 @@ unsigned avformat_version(void)
> >  return LIBAVFORMAT_VERSION_INT;
> >  }
> >
> > +unsigned avformat_version_same_minor()
> > +{
> > +return avformat_version();
> > +}
> > +
> >  const char *avformat_configuration(void)
> >  {
> >  return FFMPEG_CONFIGURATION;
> > diff --git a/libavformat/version.h b/libavformat/version.h
> > index 379a68cc7c..661d074b12 100644
> > --- a/libavformat/version.h
> > +++ b/libavformat/version.h
> > @@ -28,6 +28,7 @@
> >   */
> >
> >  #include "libavutil/version.h"
> > +#include "libavutil/macros.h"
> >
> >  // Major bumping may affect Ticket5467, 5421, 5451(compatibility with 
> > Chromium)
> >  // Also please add any ticket numbers that you believe might be affected 
> > here
> > @@ -63,4 +64,14 @@
> >
> >
> >  #define FF_API_R_FRAME_RATE1
> > +
> > +/**
> > + * avforma

Re: [FFmpeg-devel] Optimize Mpeg4 decoding for loongarch

[殷时友]

> 2021年12月29日 下午6:18，Hao Chen  写道：
> 
> ./ffmpeg -i 8_mpeg4_1080p_24fps_12Mbps.avi -f rawvideo -y /dev/null -an
> before:376fps
> after :552fps
> 
> V2: Revised PATCH 1/3 according to the comments.
> V3: Resubmit these patches due to miss PATCH v2 1/3.
> 
> [PATCH v3 1/3] avcodec: [loongarch] Optimize hpeldsp with LASX.
> [PATCH v3 2/3] avcodec: [loongarch] Optimize idctdstp with LASX.
> [PATCH v3 3/3] avcodec: [loongarch] Optimize prefetch with loongarch.
> 

LGTM.

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

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

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

[Zane van Iperen]

On Monday, 3 January 2022 4:19:05 PM AEST Andreas Rheinhardt wrote:
> 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"
> 

lgtm


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

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

Re: [FFmpeg-devel] [PATCH v1] avformat/imf: Fix error handling in set_context_streams_from_tracks()

[Zane van Iperen]

On Monday, 3 January 2022 3:22:26 AM AEST p...@sandflow.com wrote:
> 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);
> 

lgtm


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

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

[FFmpeg-devel] [PATCH] avcodec/golomb: Factor writing golomb codes out

[Andreas Rheinhardt]

Most users only want to either read or write golomb codes, not both.
By splitting these headers one avoids having unnecesssary
(get|put)_hits.h inclusions.

Signed-off-by: Andreas Rheinhardt 
---
 libavcodec/ffv1enc.c  |   2 +-
 libavcodec/flacenc.c  |   2 +-
 libavcodec/golomb.h   | 132 --
 libavcodec/hevc_ps_enc.c  |   2 +-
 libavcodec/jpeglsenc.c|   2 +-
 libavcodec/put_golomb.h   | 168 ++
 libavcodec/sonic.c|   1 +
 libavcodec/tests/golomb.c |   1 +
 8 files changed, 174 insertions(+), 136 deletions(-)
 create mode 100644 libavcodec/put_golomb.h

diff --git a/libavcodec/ffv1enc.c b/libavcodec/ffv1enc.c
index 69b9065343..d29f62bf56 100644
--- a/libavcodec/ffv1enc.c
+++ b/libavcodec/ffv1enc.c
@@ -36,8 +36,8 @@
 #include "encode.h"
 #include "internal.h"
 #include "put_bits.h"
+#include "put_golomb.h"
 #include "rangecoder.h"
-#include "golomb.h"
 #include "mathops.h"
 #include "ffv1.h"
 
diff --git a/libavcodec/flacenc.c b/libavcodec/flacenc.c
index 595928927d..9f6f449323 100644
--- a/libavcodec/flacenc.c
+++ b/libavcodec/flacenc.c
@@ -30,7 +30,7 @@
 #include "bswapdsp.h"
 #include "encode.h"
 #include "put_bits.h"
-#include "golomb.h"
+#include "put_golomb.h"
 #include "internal.h"
 #include "lpc.h"
 #include "flac.h"
diff --git a/libavcodec/golomb.h b/libavcodec/golomb.h
index 4d531cf805..8233871137 100644
--- a/libavcodec/golomb.h
+++ b/libavcodec/golomb.h
@@ -33,7 +33,6 @@
 #include 
 
 #include "get_bits.h"
-#include "put_bits.h"
 
 #define INVALID_VLC   0x8000
 
@@ -615,135 +614,4 @@ static inline int get_te(GetBitContext *s, int r, char 
*file, const char *func,
 #define get_te0_golomb(a, r) get_te(a, r, __FILE__, __func__, __LINE__)
 
 #endif /* TRACE */
-
-/**
- * write unsigned exp golomb code. 2^16 - 2 at most
- */
-static inline void set_ue_golomb(PutBitContext *pb, int i)
-{
-av_assert2(i >= 0);
-av_assert2(i <= 0xFFFE);
-
-if (i < 256)
-put_bits(pb, ff_ue_golomb_len[i], i + 1);
-else {
-int e = av_log2(i + 1);
-put_bits(pb, 2 * e + 1, i + 1);
-}
-}
-
-/**
- * write unsigned exp golomb code. 2^32-2 at most.
- */
-static inline void set_ue_golomb_long(PutBitContext *pb, uint32_t i)
-{
-av_assert2(i <= (UINT32_MAX - 1));
-
-if (i < 256)
-put_bits(pb, ff_ue_golomb_len[i], i + 1);
-else {
-int e = av_log2(i + 1);
-put_bits64(pb, 2 * e + 1, i + 1);
-}
-}
-
-/**
- * write truncated unsigned exp golomb code.
- */
-static inline void set_te_golomb(PutBitContext *pb, int i, int range)
-{
-av_assert2(range >= 1);
-av_assert2(i <= range);
-
-if (range == 2)
-put_bits(pb, 1, i ^ 1);
-else
-set_ue_golomb(pb, i);
-}
-
-/**
- * write signed exp golomb code. 16 bits at most.
- */
-static inline void set_se_golomb(PutBitContext *pb, int i)
-{
-i = 2 * i - 1;
-if (i < 0)
-i ^= -1;//FIXME check if gcc does the right thing
-set_ue_golomb(pb, i);
-}
-
-/**
- * write unsigned golomb rice code (ffv1).
- */
-static inline void set_ur_golomb(PutBitContext *pb, int i, int k, int limit,
- int esc_len)
-{
-int e;
-
-av_assert2(i >= 0);
-
-e = i >> k;
-if (e < limit)
-put_bits(pb, e + k + 1, (1 << k) + av_mod_uintp2(i, k));
-else
-put_bits(pb, limit + esc_len, i - limit + 1);
-}
-
-/**
- * write unsigned golomb rice code (jpegls).
- */
-static inline void set_ur_golomb_jpegls(PutBitContext *pb, int i, int k,
-int limit, int esc_len)
-{
-int e;
-
-av_assert2(i >= 0);
-
-e = (i >> k) + 1;
-if (e < limit) {
-while (e > 31) {
-put_bits(pb, 31, 0);
-e -= 31;
-}
-put_bits(pb, e, 1);
-if (k)
-put_sbits(pb, k, i);
-} else {
-while (limit > 31) {
-put_bits(pb, 31, 0);
-limit -= 31;
-}
-put_bits(pb, limit, 1);
-put_bits(pb, esc_len, i - 1);
-}
-}
-
-/**
- * write signed golomb rice code (ffv1).
- */
-static inline void set_sr_golomb(PutBitContext *pb, int i, int k, int limit,
- int esc_len)
-{
-int v;
-
-v  = -2 * i - 1;
-v ^= (v >> 31);
-
-set_ur_golomb(pb, v, k, limit, esc_len);
-}
-
-/**
- * write signed golomb rice code (flac).
- */
-static inline void set_sr_golomb_flac(PutBitContext *pb, int i, int k,
-  int limit, int esc_len)
-{
-int v;
-
-v  = -2 * i - 1;
-v ^= (v >> 31);
-
-set_ur_golomb_jpegls(pb, v, k, limit, esc_len);
-}
-
 #endif /* AVCODEC_GOLOMB_H */
diff --git a/libavcodec/hevc_ps_enc.c b/libavcodec/hevc_ps_enc.c
index 47f252dd2c..72641b2ffb 100644
--- a/libavcodec/hevc_ps_enc.c
+++ b/libavcodec/hevc_ps_enc.c
@@ -18,7 +18,7 @@
  * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA
  */
 
-#include "golo

[FFmpeg-devel] [PATCH] avdevice/alldevices: constify some function parameters

[James Almer]

Signed-off-by: James Almer 
---
 libavdevice/alldevices.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/libavdevice/alldevices.c b/libavdevice/alldevices.c
index fbbe187a51..3db489b83c 100644
--- a/libavdevice/alldevices.c
+++ b/libavdevice/alldevices.c
@@ -68,7 +68,7 @@ void avdevice_register_all(void)
 avpriv_register_devices(outdev_list, indev_list);
 }
 
-static const void *next_input(const AVInputFormat *prev, AVClassCategory c2)
+static const void *next_input(const AVInputFormat *prev, const AVClassCategory 
c2)
 {
 const AVClass *pc;
 const AVClassCategory c1 = AV_CLASS_CATEGORY_DEVICE_INPUT;
@@ -94,7 +94,7 @@ static const void *next_input(const AVInputFormat *prev, 
AVClassCategory c2)
 return fmt;
 }
 
-static const void *next_output(const AVOutputFormat *prev, AVClassCategory c2)
+static const void *next_output(const AVOutputFormat *prev, const 
AVClassCategory c2)
 {
 const AVClass *pc;
 const AVClassCategory c1 = AV_CLASS_CATEGORY_DEVICE_OUTPUT;
-- 
2.34.1

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

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

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

[Timo Rothenpieler]

On 03.01.2022 09:39, Wu, Jianhua wrote:

And there is one more question, may I know why there is a suffix "@ffmpeg.org"
behind my commit Author email?


Your E-Mail server is enforcing strict policy via DKIM/DMARC, so it's 
impossible for any other mail-servers, like mailing lists, to send 
E-Mails from @intel.com.
Hence the only option the list server has is to mangle the sender 
address like that.


smime.p7s
Description: S/MIME Cryptographic 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] avdevice/alldevices: constify some function parameters

[Andreas Rheinhardt]

James Almer:
> Signed-off-by: James Almer 
> ---
>  libavdevice/alldevices.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/libavdevice/alldevices.c b/libavdevice/alldevices.c
> index fbbe187a51..3db489b83c 100644
> --- a/libavdevice/alldevices.c
> +++ b/libavdevice/alldevices.c
> @@ -68,7 +68,7 @@ void avdevice_register_all(void)
>  avpriv_register_devices(outdev_list, indev_list);
>  }
>  
> -static const void *next_input(const AVInputFormat *prev, AVClassCategory c2)
> +static const void *next_input(const AVInputFormat *prev, const 
> AVClassCategory c2)
>  {
>  const AVClass *pc;
>  const AVClassCategory c1 = AV_CLASS_CATEGORY_DEVICE_INPUT;
> @@ -94,7 +94,7 @@ static const void *next_input(const AVInputFormat *prev, 
> AVClassCategory c2)
>  return fmt;
>  }
>  
> -static const void *next_output(const AVOutputFormat *prev, AVClassCategory 
> c2)
> +static const void *next_output(const AVOutputFormat *prev, const 
> AVClassCategory c2)
>  {
>  const AVClass *pc;
>  const AVClassCategory c1 = AV_CLASS_CATEGORY_DEVICE_OUTPUT;
> 

AVClassCategory is an ordinary arithmetic type, not a pointer type; due
to call-by-value you can't change the caller's value at all. We
typically don't constify such parameters and doing so is highly unusual.
That being said, I am not against changing this policy.

- 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 5/5] avfilter/vf_blend: fix un-checked potential memory allocation failure

[Wu Jianhua]

Timo Rothenpieler wrote:

> On 03.01.2022 09:39, Wu, Jianhua wrote:
>> And there is one more question, may I know why there is a suffix 
>> "@ffmpeg.org"
>> behind my commit Author email?
>
> Your E-Mail server is enforcing strict policy via DKIM/DMARC, so it's
> impossible for any other mail-servers, like mailing lists, to send
> E-Mails from @intel.com.
> Hence the only option the list server has is to mangle the sender
> address like that.

Got it. Thanks for your answer. Maybe it's better to send patches as 
attachments in case the commit message gets broken.

Best Regards,
Jianhua

___
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] lavfi/drawtext: Add localtime_ms for millisecond precision

[Thilo Borgmann]

Am 29.12.21 um 12:46 schrieb Nicolas George:
> "zhilizhao(赵志立)" (12021-12-29):
>> How about add a restriction like this:
>>
>> if (format.endsWith(“%S"))
>> enable the feature
>> else
>> warning message
>>
>> It’s a useful feature, it shouldn't create unexpected results, but
>> doesn’t need to support every use case.
> 
> I would not oppose it, but I find it inelegant, especially because it
> requires a different expansion function, localtime_ms instead of
> localtime.
> 
> What about this: with the original function "localtime", if the format
> ends in "%3N", then append the millisecond. It can later be expanded to
> support %xN at any place in the format for any value of x.

I think best will be to scan the format string for %S and extend it there with 
.ms part before expanding the rest of it, not? Shouldn't be too expensive for 
the filter.

Just need to find time to actually implement it. 

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

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

[FFmpeg-devel] [PATCH v1] avformat/imf: fix bad free() when directory name of the input url is empty

[pal]

From: Pierre-Anthony Lemieux 

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

Notes:
Found through manual fuzzing.

 libavformat/imfdec.c | 6 +-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/libavformat/imfdec.c b/libavformat/imfdec.c
index f17064cfcd..4e42db8d30 100644
--- a/libavformat/imfdec.c
+++ b/libavformat/imfdec.c
@@ -622,11 +622,15 @@ static int imf_read_header(AVFormatContext *s)
 int ret = 0;
 
 c->interrupt_callback = &s->interrupt_callback;
+
 tmp_str = av_strdup(s->url);
 if (!tmp_str)
 return AVERROR(ENOMEM);
+c->base_url = av_strdup(av_dirname(tmp_str));
+av_freep(&tmp_str);
+if (!c->base_url)
+return AVERROR(ENOMEM);
 
-c->base_url = av_dirname(tmp_str);
 if ((ret = ffio_copy_url_options(s->pb, &c->avio_opts)) < 0)
 return ret;
 
-- 
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

[Michael Niedermayer]

On Mon, Jan 03, 2022 at 06:31:37AM +0100, Jean-Baptiste Kempf wrote:
> 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?

the mov issue was fixed, channels dont seem to happen
theres a regression with 946493eb3e072b499909f606625480c928834a44
that ive reported 1 day after the patch was posted and pinged 11 days later

221073 rsF 1112 16:11 To ffmpeg-devel (2,3K) Re: [FFmpeg-devel] [FFmpeg-cvslog] 
avcodec/mlpdec: cover case when >2 channels are in single substream
221074  sF 1123  0:00 To ffmpeg-devel (3,5K) └─>

thats not branch blocking, a bugfix is just a normal backport
I dont have the file that 946493eb3e072b499909f606625480c928834a44 fixes
so trying to fix it is like working blindfolded, thats why ive so far
waited for the author to respond and take a look

There may be other features someone wants in but i think delaying the release
for features is in general a bad idea. (there may be individual exceptions
where it makes sense)

And regressions & security issues, i hope there are no major ones.
If there are they should not block making the branch though

thx

[...]

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Old school: Use the lowest level language in which you can solve the problem
conveniently.
New school: Use the highest level language in which the latest supercomputer
can solve the problem without the user falling asleep waiting.


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

[Hendrik Leppkes]

On Mon, Jan 3, 2022 at 5:14 PM Michael Niedermayer
 wrote:
>
> On Mon, Jan 03, 2022 at 06:31:37AM +0100, Jean-Baptiste Kempf wrote:
> > 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?
>
> the mov issue was fixed, channels dont seem to happen
> theres a regression with 946493eb3e072b499909f606625480c928834a44
> that ive reported 1 day after the patch was posted and pinged 11 days later
>
> 221073 rsF 1112 16:11 To ffmpeg-devel (2,3K) Re: [FFmpeg-devel] 
> [FFmpeg-cvslog] avcodec/mlpdec: cover case when >2 channels are in single 
> substream
> 221074  sF 1123  0:00 To ffmpeg-devel (3,5K) └─>
>
> thats not branch blocking, a bugfix is just a normal backport
> I dont have the file that 946493eb3e072b499909f606625480c928834a44 fixes
> so trying to fix it is like working blindfolded, thats why ive so far
> waited for the author to respond and take a look
>

As far as I can tell, the recent mlpdec changes seem to be intended to
fix playback of streams made by our own experimental encoder, and not
independent samples.
So perhaps those should be reverted for a stable release (or
generally), seeing as there is no response 2 months later, and no
indication what they actually fix.

The  available whitepapers and bitstream syntax document on TrueHD/MLP
also do not seem to support more then 2 channel in the first
substream, limiting it to a stereo presentation in the first, up to 6
channel in the second, and up to 8 channel in the third substream (and
16 in the extended substream)

Unfortunately the patch was also never on the ML for discussion or review.

- Hendrik
___
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

[Hendrik Leppkes]

On Mon, Jan 3, 2022 at 6:17 PM Hendrik Leppkes  wrote:
>
> Unfortunately the patch was also never on the ML for discussion or review.
>

 Sorry, I was blind, it was in fact on the ML. I must've been thinking
of something else..

- Hendrik
___
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

[Paul B Mahol]

On Mon, Jan 3, 2022 at 6:18 PM Hendrik Leppkes  wrote:

> On Mon, Jan 3, 2022 at 5:14 PM Michael Niedermayer
>  wrote:
> >
> > On Mon, Jan 03, 2022 at 06:31:37AM +0100, Jean-Baptiste Kempf wrote:
> > > 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?
> >
> > the mov issue was fixed, channels dont seem to happen
> > theres a regression with 946493eb3e072b499909f606625480c928834a44
> > that ive reported 1 day after the patch was posted and pinged 11 days
> later
> >
> > 221073 rsF 1112 16:11 To ffmpeg-devel (2,3K) Re: [FFmpeg-devel]
> [FFmpeg-cvslog] avcodec/mlpdec: cover case when >2 channels are in single
> substream
> > 221074  sF 1123  0:00 To ffmpeg-devel (3,5K) └─>
> >
> > thats not branch blocking, a bugfix is just a normal backport
> > I dont have the file that 946493eb3e072b499909f606625480c928834a44 fixes
> > so trying to fix it is like working blindfolded, thats why ive so far
> > waited for the author to respond and take a look
> >
>
> As far as I can tell, the recent mlpdec changes seem to be intended to
> fix playback of streams made by our own experimental encoder, and not
> independent samples.
> So perhaps those should be reverted for a stable release (or
> generally), seeing as there is no response 2 months later, and no
> indication what they actually fix.
>
> The  available whitepapers and bitstream syntax document on TrueHD/MLP
> also do not seem to support more then 2 channel in the first
> substream, limiting it to a stereo presentation in the first, up to 6
> channel in the second, and up to 8 channel in the third substream (and
> 16 in the extended substream)
>

This statement is not in sync with reality.

I have sample that 946... fixes, single stream with > 2 channels.


>
> Unfortunately the patch was also never on the ML for discussion or review.
>
> - Hendrik
> ___
> 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] 5.0 release

[Michael Niedermayer]

On Mon, Jan 03, 2022 at 07:04:48PM +0100, Paul B Mahol wrote:
> On Mon, Jan 3, 2022 at 6:18 PM Hendrik Leppkes  wrote:
> 
> > On Mon, Jan 3, 2022 at 5:14 PM Michael Niedermayer
> >  wrote:
> > >
> > > On Mon, Jan 03, 2022 at 06:31:37AM +0100, Jean-Baptiste Kempf wrote:
> > > > 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?
> > >
> > > the mov issue was fixed, channels dont seem to happen
> > > theres a regression with 946493eb3e072b499909f606625480c928834a44
> > > that ive reported 1 day after the patch was posted and pinged 11 days
> > later
> > >
> > > 221073 rsF 1112 16:11 To ffmpeg-devel (2,3K) Re: [FFmpeg-devel]
> > [FFmpeg-cvslog] avcodec/mlpdec: cover case when >2 channels are in single
> > substream
> > > 221074  sF 1123  0:00 To ffmpeg-devel (3,5K) └─>
> > >
> > > thats not branch blocking, a bugfix is just a normal backport
> > > I dont have the file that 946493eb3e072b499909f606625480c928834a44 fixes
> > > so trying to fix it is like working blindfolded, thats why ive so far
> > > waited for the author to respond and take a look
> > >
> >
> > As far as I can tell, the recent mlpdec changes seem to be intended to
> > fix playback of streams made by our own experimental encoder, and not
> > independent samples.

How can that be reproduced ?
I tried with a 5.1 stream and the decoded output is not changing with this
patch


> > So perhaps those should be reverted for a stable release (or
> > generally), seeing as there is no response 2 months later, and no
> > indication what they actually fix.
> >
> > The  available whitepapers and bitstream syntax document on TrueHD/MLP
> > also do not seem to support more then 2 channel in the first
> > substream, limiting it to a stereo presentation in the first, up to 6
> > channel in the second, and up to 8 channel in the third substream (and
> > 16 in the extended substream)
> >
> 
> This statement is not in sync with reality.
> 
> I have sample that 946... fixes, single stream with > 2 channels.

Iam not sure i understand what you mean exactly but

the sample which it breaks is here:
https://samples.ffmpeg.org/ffmpeg-bugs/trac/ticket1726/Mono.thd

can you look into this issue, you as author of the change maybe
remember why you did it and so are better qualified to adjust it.

thx

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

Homeopathy is like voting while filling the ballot out with transparent ink.
Sometimes the outcome one wanted occurs. Rarely its worse than filling out
a ballot properly.


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] Build break: VideoToolbox VP9 support breaks H.264-only build

[Cameron Gutman]

I am building minimal ffmpeg libraries for my application using the following
configure command:

./configure --enable-shared --disable-all --enable-avcodec 
--enable-decoder=h264 --enable-hwaccel=h264_videotoolbox

libavcodec.dylib now fails to link after the following commit:

commit a41a2efc85f8c88caec10040ee437562f9d0b947
Author: rcombs 
Date:   Sat Nov 13 02:43:06 2021 -0600

lavc/videotoolbox: add VP9 hardware acceleration

On M1 Max, this supports profiles 0 and 2, but not 1 and 3.


The error is:

Undefined symbols for architecture x86_64:
  "_ff_videotoolbox_vpcc_extradata_create", referenced from:
  _videotoolbox_start in videotoolbox.o
ld: symbol(s) not found for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see invocation)
make: *** [libavcodec/libavcodec.59.dylib] Error 1


Perhaps ff_videotoolbox_vpcc_extradata_create() needs to go in videotoolbox.c
like the other ff_videotoolbox_*_extradata_create() functions?



Regards,
Cam
___
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

[Marton Balint]

On Mon, 3 Jan 2022, Andreas Rheinhardt wrote:


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.



I still don't like storing ENOMEM in the AVIOContext and I don't see why
having to check the error is so burdensome. But if you want it so bad,
then go ahead.


I don't feel strongly about it, it just looked convenient/consistent. But 
I will just skip this patch then and apply the rest.


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

[Michael Niedermayer]

On Mon, Jan 03, 2022 at 05:14:13PM +0100, Michael Niedermayer wrote:
> On Mon, Jan 03, 2022 at 06:31:37AM +0100, Jean-Baptiste Kempf wrote:
> > 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?
> 
> the mov issue was fixed, channels dont seem to happen
> theres a regression with 946493eb3e072b499909f606625480c928834a44
> that ive reported 1 day after the patch was posted and pinged 11 days later
> 
> 221073 rsF 1112 16:11 To ffmpeg-devel (2,3K) Re: [FFmpeg-devel] 
> [FFmpeg-cvslog] avcodec/mlpdec: cover case when >2 channels are in single 
> substream
> 221074  sF 1123  0:00 To ffmpeg-devel (3,5K) └─>
> 
> thats not branch blocking, a bugfix is just a normal backport
> I dont have the file that 946493eb3e072b499909f606625480c928834a44 fixes
> so trying to fix it is like working blindfolded, thats why ive so far
> waited for the author to respond and take a look
> 
> There may be other features someone wants in but i think delaying the release
> for features is in general a bad idea. (there may be individual exceptions
> where it makes sense)
> 
> And regressions & security issues, i hope there are no major ones.
> If there are they should not block making the branch though

Also 

imfdec / experimental flag
we have a patchset from anton, there where some comments, i think nothing
blocking it but it needs to be applied

thx

[...]

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

No snowflake in an avalanche ever feels responsible. -- Voltaire


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

[Paul B Mahol]

On Mon, Jan 3, 2022 at 7:58 PM Michael Niedermayer 
wrote:

> On Mon, Jan 03, 2022 at 07:04:48PM +0100, Paul B Mahol wrote:
> > On Mon, Jan 3, 2022 at 6:18 PM Hendrik Leppkes 
> wrote:
> >
> > > On Mon, Jan 3, 2022 at 5:14 PM Michael Niedermayer
> > >  wrote:
> > > >
> > > > On Mon, Jan 03, 2022 at 06:31:37AM +0100, Jean-Baptiste Kempf wrote:
> > > > > 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?
> > > >
> > > > the mov issue was fixed, channels dont seem to happen
> > > > theres a regression with 946493eb3e072b499909f606625480c928834a44
> > > > that ive reported 1 day after the patch was posted and pinged 11 days
> > > later
> > > >
> > > > 221073 rsF 1112 16:11 To ffmpeg-devel (2,3K) Re: [FFmpeg-devel]
> > > [FFmpeg-cvslog] avcodec/mlpdec: cover case when >2 channels are in
> single
> > > substream
> > > > 221074  sF 1123  0:00 To ffmpeg-devel (3,5K) └─>
> > > >
> > > > thats not branch blocking, a bugfix is just a normal backport
> > > > I dont have the file that 946493eb3e072b499909f606625480c928834a44
> fixes
> > > > so trying to fix it is like working blindfolded, thats why ive so far
> > > > waited for the author to respond and take a look
> > > >
> > >
> > > As far as I can tell, the recent mlpdec changes seem to be intended to
> > > fix playback of streams made by our own experimental encoder, and not
> > > independent samples.
>
> How can that be reproduced ?
> I tried with a 5.1 stream and the decoded output is not changing with this
> patch
>
>
> > > So perhaps those should be reverted for a stable release (or
> > > generally), seeing as there is no response 2 months later, and no
> > > indication what they actually fix.
> > >
> > > The  available whitepapers and bitstream syntax document on TrueHD/MLP
> > > also do not seem to support more then 2 channel in the first
> > > substream, limiting it to a stereo presentation in the first, up to 6
> > > channel in the second, and up to 8 channel in the third substream (and
> > > 16 in the extended substream)
> > >
> >
> > This statement is not in sync with reality.
> >
> > I have sample that 946... fixes, single stream with > 2 channels.
>
> Iam not sure i understand what you mean exactly but
>
> the sample which it breaks is here:
> https://samples.ffmpeg.org/ffmpeg-bugs/trac/ticket1726/Mono.thd
>
> can you look into this issue, you as author of the change maybe
> remember why you did it and so are better qualified to adjust it.
>

Sorry but that sample was never decoded properly. As it is not mono and it
is not stereo.


>
> thx
>
> [...]
> --
> Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
>
> Homeopathy is like voting while filling the ballot out with transparent
> ink.
> Sometimes the outcome one wanted occurs. Rarely its worse than filling out
> a ballot properly.
> ___
> 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] [RFC/PATCH 1/2] lavf: add a flag for experimental (de)muxers

[Anton Khirnov]

Quoting Michael Niedermayer (2022-01-02 23:45:19)
> 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

pushed

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

[FFmpeg-devel] [PATCH 1/2] avcodec/apedec: Fix integer overflows in predictor_update_3930()

[Michael Niedermayer]

Fixes: signed integer overflow: 1074134419 - -1075212485 cannot be represented 
in type 'int'
Fixes: 
43273/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_APE_fuzzer-4706880883130368

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

diff --git a/libavcodec/apedec.c b/libavcodec/apedec.c
index b932263012e..607304fe363 100644
--- a/libavcodec/apedec.c
+++ b/libavcodec/apedec.c
@@ -1088,13 +1088,13 @@ static av_always_inline int 
predictor_update_3930(APEPredictor *p,
   const int delayA)
 {
 int32_t predictionA, sign;
-int32_t d0, d1, d2, d3;
+uint32_t d0, d1, d2, d3;
 
 p->buf[delayA] = p->lastA[filter];
 d0 = p->buf[delayA];
-d1 = p->buf[delayA] - p->buf[delayA - 1];
-d2 = p->buf[delayA - 1] - p->buf[delayA - 2];
-d3 = p->buf[delayA - 2] - p->buf[delayA - 3];
+d1 = p->buf[delayA] - (unsigned)p->buf[delayA - 1];
+d2 = p->buf[delayA - 1] - (unsigned)p->buf[delayA - 2];
+d3 = p->buf[delayA - 2] - (unsigned)p->buf[delayA - 3];
 
 predictionA = d0 * p->coeffsA[filter][0] +
   d1 * p->coeffsA[filter][1] +
@@ -1105,10 +1105,10 @@ static av_always_inline int 
predictor_update_3930(APEPredictor *p,
 p->filterA[filter] = p->lastA[filter] + ((int)(p->filterA[filter] * 31U) 
>> 5);
 
 sign = APESIGN(decoded);
-p->coeffsA[filter][0] += ((d0 < 0) * 2 - 1) * sign;
-p->coeffsA[filter][1] += ((d1 < 0) * 2 - 1) * sign;
-p->coeffsA[filter][2] += ((d2 < 0) * 2 - 1) * sign;
-p->coeffsA[filter][3] += ((d3 < 0) * 2 - 1) * sign;
+p->coeffsA[filter][0] += (((int32_t)d0 < 0) * 2 - 1) * sign;
+p->coeffsA[filter][1] += (((int32_t)d1 < 0) * 2 - 1) * sign;
+p->coeffsA[filter][2] += (((int32_t)d2 < 0) * 2 - 1) * sign;
+p->coeffsA[filter][3] += (((int32_t)d3 < 0) * 2 - 1) * sign;
 
 return p->filterA[filter];
 }
-- 
2.17.1

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

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

[FFmpeg-devel] [PATCH 2/2] doc/APIchanges: Fill in missing things

[Michael Niedermayer]

Signed-off-by: Michael Niedermayer 
---
 doc/APIchanges | 72 +-
 1 file changed, 36 insertions(+), 36 deletions(-)

diff --git a/doc/APIchanges b/doc/APIchanges
index 670a59329e3..bfe17c39360 100644
--- a/doc/APIchanges
+++ b/doc/APIchanges
@@ -14,82 +14,82 @@ libavutil: 2021-04-27
 
 API changes, most recent first:
 
-2021-12-xx - xx - lavu 57.13.100 - hwcontext_videotoolbox.h
+2021-12-22 - b7e1ec7bda9 - lavu 57.13.100 - hwcontext_videotoolbox.h
   Add av_vt_pixbuf_set_attachments
 
-2021-12-xx - xx - lavu 57.13.100 - hwcontext_videotoolbox.h
+2021-12-22 - 69bd95dcd8d - lavu 57.13.100 - hwcontext_videotoolbox.h
   Add av_map_videotoolbox_chroma_loc_from_av
   Add av_map_videotoolbox_color_matrix_from_av
   Add av_map_videotoolbox_color_primaries_from_av
   Add av_map_videotoolbox_color_trc_from_av
 
-2021-12-21 - xx - lavu 57.12.100 - cpu.h
+2021-12-21 - ffbab99f2c2 - lavu 57.12.100 - cpu.h
   Add AV_CPU_FLAG_SLOW_GATHER.
 
-2021-12-20 - xx - lavu 57.11.101 - display.h
+2021-12-20 - 278068dc60d - lavu 57.11.101 - display.h
   Modified the documentation of av_display_rotation_set()
   to match its longstanding actual behaviour of treating
   the angle as directed clockwise.
 
-2021-12-xx - xx - lavf 59.10.100 - avformat.h
+2021-12-12 - 64834bb86a1 - lavf 59.10.100 - avformat.h
   Add AVFormatContext io_close2 which returns an int
 
-2021-11-10 - xx - lavu 57.11.100 - hwcontext_vulkan.h
+2021-12-10 - f45cbb775e4 - lavu 57.11.100 - hwcontext_vulkan.h
   Add AVVkFrame.offset and AVVulkanFramesContext.flags.
 
-2021-11-xx - xx - lavfi 8.19.100 - avfilter.h
+2021-12-04 - b9c928a486f - lavfi 8.19.100 - avfilter.h
   Add AVFILTER_FLAG_METADATA_ONLY.
 
-2021-12-03 - xx - lavu 57.10.100 - frame.h
+2021-12-03 - b236ef0a594 - lavu 57.10.100 - frame.h
   Add AVFrame.time_base
 
-2021-11-22 - xx - lavu 57.9.100 - pixfmt.h
+2021-11-22 - b2cd1fb2ec6 - lavu 57.9.100 - pixfmt.h
   Add AV_PIX_FMT_P210, AV_PIX_FMT_P410, AV_PIX_FMT_P216, and AV_PIX_FMT_P416.
 
-2021-11-17 - xx - lavf 57.9.100 - frame.h
+2021-11-17 - 54e65aa38ab - lavf 57.9.100 - frame.h
   Add AV_FRAME_DATA_DOVI_RPU_BUFFER.
 
-2021-11-xx - xx - lavf 59.9.100 - avformat.h
+2021-11-16 - ed75a08d36c - lavf 59.9.100 - avformat.h
   Add av_stream_get_class(). Schedule adding AVStream.av_class at libavformat
   major version 60.
   Add av_disposition_to_string() and av_disposition_from_string().
   Add "disposition" AVOption to AVStream's class.
 
-2021-11-12 - xx - lavu 57.8.100 - hwcontext_vulkan.h
+2021-11-12 - 8478d60d5b5 - lavu 57.8.100 - hwcontext_vulkan.h
   Added AVVkFrame.sem_value, AVVulkanDeviceContext.queue_family_encode_index,
   nb_encode_queues, queue_family_decode_index, and nb_decode_queues.
 
-2021-10-18 - xx - lavf 59.8.100 - avio.h
+2021-10-18 - 682bafdb125 - lavf 59.8.100 - avio.h
   Introduce public bytes_{read,written} statistic fields to AVIOContext.
 
-2021-10-13 - xx - lavf 59.7.100 - avio.h
+2021-10-13 - a5622ed16f8 - lavf 59.7.100 - avio.h
   Deprecate AVIOContext.written. Originally added as a private entry in
   commit 3f75e5116b900f1428aa13041fc7d6301bf1988a, its grouping with
   the comment noting its private state was missed during merging of the field
   from Libav (most likely due to an already existing field in between).
 
-2021-09-21 - xx - lavu 57.7.100 - pixfmt.h
+2021-09-21 - 0760d9153c3 - lavu 57.7.100 - pixfmt.h
   Add AV_PIX_FMT_X2BGR10.
 
-2021-09-20 - xx - lavu 57.6.100 - mem.h
+2021-09-20 - 8d5de914d31 - lavu 57.6.100 - mem.h
   Deprecate av_mallocz_array() as it is identical to av_calloc().
 
-2021-09-20 - xx - lavc 59.9.100 - avcodec.h
+2021-09-20 - 176b8d785bf - lavc 59.9.100 - avcodec.h
   Deprecate AVCodecContext.sub_text_format and the corresponding
   AVOptions. It is unused since the last major bump.
 
-2021-09-20 - xx - lavc 59.8.100 - avcodec.h codec.h
+2021-09-20 - dd846bc4a91 - lavc 59.8.100 - avcodec.h codec.h
   Deprecate AV_CODEC_FLAG_TRUNCATED and AV_CODEC_CAP_TRUNCATED,
   as they are redundant with parsers.
 
-2021-09-17 - xx - lavu 57.5.101 - buffer.h
+2021-09-17 - ccfdef79b13 - lavu 57.5.101 - buffer.h
   Constified the input parameters in av_buffer_replace(), av_buffer_ref(),
   and av_buffer_pool_buffer_get_opaque().
 
-2021-09-08 - xx - lavu 57.5.100 - hwcontext_d3d11va.h
+2021-09-08 - 4f78711f9c2 - lavu 57.5.100 - hwcontext_d3d11va.h
   Add AVD3D11VAFramesContext.texture_infos
 
-2021-09-06 - xx - lsws 6.1.100 - swscale.h
+2021-09-06 - 42cd64c1826 - lsws 6.1.100 - swscale.h
   Add AVFrame-based scaling API:
 - sws_scale_frame()
 - sws_frame_start()
@@ -98,54 +98,54 @@ API changes, most recent first:
 - sws_receive_slice()
 - sws_receive_slice_alignment()
 
-2021-09-02 - xx - lavc 59.7.100 - avcodec.h
+2021-09-02 - cbf111059d2 - lavc 59.7.100 - avcodec.h
   

Re: [FFmpeg-devel] [PATCH 2/2] doc/APIchanges: Fill in missing things

[James Almer]

On 1/3/2022 5:01 PM, Michael Niedermayer wrote:

Signed-off-by: Michael Niedermayer 
---
  doc/APIchanges | 72 +-
  1 file changed, 36 insertions(+), 36 deletions(-)

diff --git a/doc/APIchanges b/doc/APIchanges
index 670a59329e3..bfe17c39360 100644
--- a/doc/APIchanges
+++ b/doc/APIchanges
@@ -14,82 +14,82 @@ libavutil: 2021-04-27
  
  API changes, most recent first:


Doesn't apply after be97d2a825. But should be ok after also including 
that extra entry.


  
-2021-12-xx - xx - lavu 57.13.100 - hwcontext_videotoolbox.h

+2021-12-22 - b7e1ec7bda9 - lavu 57.13.100 - hwcontext_videotoolbox.h
Add av_vt_pixbuf_set_attachments
  
-2021-12-xx - xx - lavu 57.13.100 - hwcontext_videotoolbox.h

+2021-12-22 - 69bd95dcd8d - lavu 57.13.100 - hwcontext_videotoolbox.h
Add av_map_videotoolbox_chroma_loc_from_av
Add av_map_videotoolbox_color_matrix_from_av
Add av_map_videotoolbox_color_primaries_from_av
Add av_map_videotoolbox_color_trc_from_av
  
-2021-12-21 - xx - lavu 57.12.100 - cpu.h

+2021-12-21 - ffbab99f2c2 - lavu 57.12.100 - cpu.h
Add AV_CPU_FLAG_SLOW_GATHER.
  
-2021-12-20 - xx - lavu 57.11.101 - display.h

+2021-12-20 - 278068dc60d - lavu 57.11.101 - display.h
Modified the documentation of av_display_rotation_set()
to match its longstanding actual behaviour of treating
the angle as directed clockwise.
  
-2021-12-xx - xx - lavf 59.10.100 - avformat.h

+2021-12-12 - 64834bb86a1 - lavf 59.10.100 - avformat.h
Add AVFormatContext io_close2 which returns an int
  
-2021-11-10 - xx - lavu 57.11.100 - hwcontext_vulkan.h

+2021-12-10 - f45cbb775e4 - lavu 57.11.100 - hwcontext_vulkan.h
Add AVVkFrame.offset and AVVulkanFramesContext.flags.
  
-2021-11-xx - xx - lavfi 8.19.100 - avfilter.h

+2021-12-04 - b9c928a486f - lavfi 8.19.100 - avfilter.h
Add AVFILTER_FLAG_METADATA_ONLY.
  
-2021-12-03 - xx - lavu 57.10.100 - frame.h

+2021-12-03 - b236ef0a594 - lavu 57.10.100 - frame.h
Add AVFrame.time_base
  
-2021-11-22 - xx - lavu 57.9.100 - pixfmt.h

+2021-11-22 - b2cd1fb2ec6 - lavu 57.9.100 - pixfmt.h
Add AV_PIX_FMT_P210, AV_PIX_FMT_P410, AV_PIX_FMT_P216, and AV_PIX_FMT_P416.
  
-2021-11-17 - xx - lavf 57.9.100 - frame.h

+2021-11-17 - 54e65aa38ab - lavf 57.9.100 - frame.h
Add AV_FRAME_DATA_DOVI_RPU_BUFFER.
  
-2021-11-xx - xx - lavf 59.9.100 - avformat.h

+2021-11-16 - ed75a08d36c - lavf 59.9.100 - avformat.h
Add av_stream_get_class(). Schedule adding AVStream.av_class at libavformat
major version 60.
Add av_disposition_to_string() and av_disposition_from_string().
Add "disposition" AVOption to AVStream's class.
  
-2021-11-12 - xx - lavu 57.8.100 - hwcontext_vulkan.h

+2021-11-12 - 8478d60d5b5 - lavu 57.8.100 - hwcontext_vulkan.h
Added AVVkFrame.sem_value, AVVulkanDeviceContext.queue_family_encode_index,
nb_encode_queues, queue_family_decode_index, and nb_decode_queues.
  
-2021-10-18 - xx - lavf 59.8.100 - avio.h

+2021-10-18 - 682bafdb125 - lavf 59.8.100 - avio.h
Introduce public bytes_{read,written} statistic fields to AVIOContext.
  
-2021-10-13 - xx - lavf 59.7.100 - avio.h

+2021-10-13 - a5622ed16f8 - lavf 59.7.100 - avio.h
Deprecate AVIOContext.written. Originally added as a private entry in
commit 3f75e5116b900f1428aa13041fc7d6301bf1988a, its grouping with
the comment noting its private state was missed during merging of the field
from Libav (most likely due to an already existing field in between).
  
-2021-09-21 - xx - lavu 57.7.100 - pixfmt.h

+2021-09-21 - 0760d9153c3 - lavu 57.7.100 - pixfmt.h
Add AV_PIX_FMT_X2BGR10.
  
-2021-09-20 - xx - lavu 57.6.100 - mem.h

+2021-09-20 - 8d5de914d31 - lavu 57.6.100 - mem.h
Deprecate av_mallocz_array() as it is identical to av_calloc().
  
-2021-09-20 - xx - lavc 59.9.100 - avcodec.h

+2021-09-20 - 176b8d785bf - lavc 59.9.100 - avcodec.h
Deprecate AVCodecContext.sub_text_format and the corresponding
AVOptions. It is unused since the last major bump.
  
-2021-09-20 - xx - lavc 59.8.100 - avcodec.h codec.h

+2021-09-20 - dd846bc4a91 - lavc 59.8.100 - avcodec.h codec.h
Deprecate AV_CODEC_FLAG_TRUNCATED and AV_CODEC_CAP_TRUNCATED,
as they are redundant with parsers.
  
-2021-09-17 - xx - lavu 57.5.101 - buffer.h

+2021-09-17 - ccfdef79b13 - lavu 57.5.101 - buffer.h
Constified the input parameters in av_buffer_replace(), av_buffer_ref(),
and av_buffer_pool_buffer_get_opaque().
  
-2021-09-08 - xx - lavu 57.5.100 - hwcontext_d3d11va.h

+2021-09-08 - 4f78711f9c2 - lavu 57.5.100 - hwcontext_d3d11va.h
Add AVD3D11VAFramesContext.texture_infos
  
-2021-09-06 - xx - lsws 6.1.100 - swscale.h

+2021-09-06 - 42cd64c1826 - lsws 6.1.100 - swscale.h
Add AVFrame-based scaling API:
  - sws_scale_frame()
  - sws_frame_start()
@

Re: [FFmpeg-devel] 5.0 release

[Michael Niedermayer]

On Mon, Jan 03, 2022 at 08:25:44PM +0100, Paul B Mahol wrote:
> On Mon, Jan 3, 2022 at 7:58 PM Michael Niedermayer 
> wrote:
> 
> > On Mon, Jan 03, 2022 at 07:04:48PM +0100, Paul B Mahol wrote:
> > > On Mon, Jan 3, 2022 at 6:18 PM Hendrik Leppkes 
> > wrote:
> > >
> > > > On Mon, Jan 3, 2022 at 5:14 PM Michael Niedermayer
> > > >  wrote:
> > > > >
> > > > > On Mon, Jan 03, 2022 at 06:31:37AM +0100, Jean-Baptiste Kempf wrote:
> > > > > > 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?
> > > > >
> > > > > the mov issue was fixed, channels dont seem to happen
> > > > > theres a regression with 946493eb3e072b499909f606625480c928834a44
> > > > > that ive reported 1 day after the patch was posted and pinged 11 days
> > > > later
> > > > >
> > > > > 221073 rsF 1112 16:11 To ffmpeg-devel (2,3K) Re: [FFmpeg-devel]
> > > > [FFmpeg-cvslog] avcodec/mlpdec: cover case when >2 channels are in
> > single
> > > > substream
> > > > > 221074  sF 1123  0:00 To ffmpeg-devel (3,5K) └─>
> > > > >
> > > > > thats not branch blocking, a bugfix is just a normal backport
> > > > > I dont have the file that 946493eb3e072b499909f606625480c928834a44
> > fixes
> > > > > so trying to fix it is like working blindfolded, thats why ive so far
> > > > > waited for the author to respond and take a look
> > > > >
> > > >
> > > > As far as I can tell, the recent mlpdec changes seem to be intended to
> > > > fix playback of streams made by our own experimental encoder, and not
> > > > independent samples.
> >
> > How can that be reproduced ?
> > I tried with a 5.1 stream and the decoded output is not changing with this
> > patch
> >
> >
> > > > So perhaps those should be reverted for a stable release (or
> > > > generally), seeing as there is no response 2 months later, and no
> > > > indication what they actually fix.
> > > >
> > > > The  available whitepapers and bitstream syntax document on TrueHD/MLP
> > > > also do not seem to support more then 2 channel in the first
> > > > substream, limiting it to a stereo presentation in the first, up to 6
> > > > channel in the second, and up to 8 channel in the third substream (and
> > > > 16 in the extended substream)
> > > >
> > >
> > > This statement is not in sync with reality.
> > >
> > > I have sample that 946... fixes, single stream with > 2 channels.
> >
> > Iam not sure i understand what you mean exactly but
> >
> > the sample which it breaks is here:
> > https://samples.ffmpeg.org/ffmpeg-bugs/trac/ticket1726/Mono.thd
> >
> > can you look into this issue, you as author of the change maybe
> > remember why you did it and so are better qualified to adjust it.
> >
> 
> Sorry but that sample was never decoded properly. As it is not mono and it
> is not stereo.

around the time of 3.2 it was decoded as mono and it sounds reasonable
after that until 946... it was decoded as stereo with only the left channel
after 946... it now doesnt decode at all

it would be nice if we could support this kind of file

thx

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

Those who are too smart to engage in politics are punished by being
governed by those who are dumber. -- Plato 


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 v3] libavcodec/flacenc: add backward-compatible 32 bit-per-sample capability

[Martijn van Beurden]

Enables creation of FLAC files with up to 32 bits-per-sample, up from the
previous limit of 24 bit. This is a feature requested for RAWcooked, the
archiving community has a need for storing files with 32-bit integer audio
samples. See https://github.com/MediaArea/RAWcooked/issues/356

Restrictions to the encoder are added so created files are compatible with
existing decoders. Stereo decorrelation is disabled on 32 bit-per-sample,
because a side channel would need 33 bit-per-sample, causing problems in
existing 32 bit datapaths. Also only LPC encoding is enabled, because
decoders capable of processing 24-bit files already use 64-bit processing
for LPC, but not for fixed subframes.

Furthermore, predictions and residuals are checked for causing integer
overflow, reverting to a verbatim (store) subframe in case no LPC coeffs
can be found that do not cause overflow.

ffmpeg's FLAC decoder has been forward-compatible with this change since
commit c720b9ce98 (May 2015). libFLAC is forward-compatible since release
1.2.1 (September 2007), the flac command line tool however blocks 32-bit
files out of caution, it having been untested until now.

To create 32 bit files, -bits_per_raw_sample 32 must be specified because
of trac ticket 9563
---
 libavcodec/flacdsp.c | 45 +
 libavcodec/flacdsp.h |  3 ++
 libavcodec/flacenc.c | 94 +---
 3 files changed, 127 insertions(+), 15 deletions(-)

diff --git a/libavcodec/flacdsp.c b/libavcodec/flacdsp.c
index bc9a5dbed9..b6c163981e 100644
--- a/libavcodec/flacdsp.c
+++ b/libavcodec/flacdsp.c
@@ -43,6 +43,51 @@
 #define PLANAR 1
 #include "flacdsp_template.c"
 
+#define ZIGZAG_32BIT_MAX  0x3FFF
+#define ZIGZAG_32BIT_MIN -0x3FFF
+
+int ff_flacdsp_lpc_encode_c_32_overflow_detect(int32_t *res, const int32_t 
*smp, int len,
+   int order, int32_t *coefs, int 
shift)
+{
+/* This function checks for every prediction and every residual
+ * whether they cause integer overflow in existing decoders. In
+ * case the prediction exceeds int32_t limits, prediction
+ * coefficients are lowered accordingly. If the residual exceeds
+ * ZIGZAG_32BIT_MAX and _MIN or coefficients have been lowered
+ * twice but the prediction still overflows, give up */
+int lpc_reduction_tries = 0;
+int64_t pmax;
+for (int i = 0; i < order; i++)
+res[i] = smp[i];
+do {
+pmax = 0;
+for (int i = order; i < len; i++) {
+int64_t p = 0, tmp;
+for (int j = 0; j < order; j++)
+p += (int64_t)coefs[j]*smp[(i-1)-j];
+p >>= shift;
+tmp = smp[i] - p;
+if (p > INT32_MAX && p > pmax)
+pmax = p;
+else if (p < INT32_MIN && (p * -1) > pmax)
+pmax = p * -1;
+if (tmp > ZIGZAG_32BIT_MAX || tmp < ZIGZAG_32BIT_MIN)
+return 0;
+res[i] = tmp;
+}
+
+if (pmax > 0) {
+if (lpc_reduction_tries >= 2)
+return 0;
+lpc_reduction_tries++;
+for (int i = 0; i < order; i++)
+coefs[i] = ((int64_t)coefs[i] * INT32_MAX) / pmax;
+}
+} while (pmax > 0);
+return 1;
+}
+
+
 static void flac_lpc_16_c(int32_t *decoded, const int coeffs[32],
   int pred_order, int qlevel, int len)
 {
diff --git a/libavcodec/flacdsp.h b/libavcodec/flacdsp.h
index 7bb0dd0e9a..5978a4722a 100644
--- a/libavcodec/flacdsp.h
+++ b/libavcodec/flacdsp.h
@@ -40,4 +40,7 @@ void ff_flacdsp_init(FLACDSPContext *c, enum AVSampleFormat 
fmt, int channels, i
 void ff_flacdsp_init_arm(FLACDSPContext *c, enum AVSampleFormat fmt, int 
channels, int bps);
 void ff_flacdsp_init_x86(FLACDSPContext *c, enum AVSampleFormat fmt, int 
channels, int bps);
 
+int ff_flacdsp_lpc_encode_c_32_overflow_detect(int32_t *res, const int32_t 
*smp, int len,
+   int order, int32_t *coefs, int 
shift);
+
 #endif /* AVCODEC_FLACDSP_H */
diff --git a/libavcodec/flacenc.c b/libavcodec/flacenc.c
index 595928927d..bb7138acb3 100644
--- a/libavcodec/flacenc.c
+++ b/libavcodec/flacenc.c
@@ -254,10 +254,30 @@ static av_cold int flac_encode_init(AVCodecContext *avctx)
 s->bps_code= 4;
 break;
 case AV_SAMPLE_FMT_S32:
-if (avctx->bits_per_raw_sample != 24)
-av_log(avctx, AV_LOG_WARNING, "encoding as 24 bits-per-sample\n");
-avctx->bits_per_raw_sample = 24;
-s->bps_code= 6;
+if (avctx->bits_per_raw_sample <= 24) {
+if (avctx->bits_per_raw_sample < 24)
+av_log(avctx, AV_LOG_WARNING, "encoding as 24 
bits-per-sample\n");
+avctx->bits_per_raw_sample = 24;
+s->bps_code= 6;
+} else {
+av_log(avctx, AV_LOG_WARNING, "non-streamable bits-per-sample\n");
+ 

Re: [FFmpeg-devel] 5.0 release

[Paul B Mahol]

On Mon, Jan 3, 2022 at 9:14 PM Michael Niedermayer 
wrote:

> On Mon, Jan 03, 2022 at 08:25:44PM +0100, Paul B Mahol wrote:
> > On Mon, Jan 3, 2022 at 7:58 PM Michael Niedermayer <
> mich...@niedermayer.cc>
> > wrote:
> >
> > > On Mon, Jan 03, 2022 at 07:04:48PM +0100, Paul B Mahol wrote:
> > > > On Mon, Jan 3, 2022 at 6:18 PM Hendrik Leppkes 
> > > wrote:
> > > >
> > > > > On Mon, Jan 3, 2022 at 5:14 PM Michael Niedermayer
> > > > >  wrote:
> > > > > >
> > > > > > On Mon, Jan 03, 2022 at 06:31:37AM +0100, Jean-Baptiste Kempf
> wrote:
> > > > > > > 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?
> > > > > >
> > > > > > the mov issue was fixed, channels dont seem to happen
> > > > > > theres a regression with 946493eb3e072b499909f606625480c928834a44
> > > > > > that ive reported 1 day after the patch was posted and pinged 11
> days
> > > > > later
> > > > > >
> > > > > > 221073 rsF 1112 16:11 To ffmpeg-devel (2,3K) Re: [FFmpeg-devel]
> > > > > [FFmpeg-cvslog] avcodec/mlpdec: cover case when >2 channels are in
> > > single
> > > > > substream
> > > > > > 221074  sF 1123  0:00 To ffmpeg-devel (3,5K) └─>
> > > > > >
> > > > > > thats not branch blocking, a bugfix is just a normal backport
> > > > > > I dont have the file that
> 946493eb3e072b499909f606625480c928834a44
> > > fixes
> > > > > > so trying to fix it is like working blindfolded, thats why ive
> so far
> > > > > > waited for the author to respond and take a look
> > > > > >
> > > > >
> > > > > As far as I can tell, the recent mlpdec changes seem to be
> intended to
> > > > > fix playback of streams made by our own experimental encoder, and
> not
> > > > > independent samples.
> > >
> > > How can that be reproduced ?
> > > I tried with a 5.1 stream and the decoded output is not changing with
> this
> > > patch
> > >
> > >
> > > > > So perhaps those should be reverted for a stable release (or
> > > > > generally), seeing as there is no response 2 months later, and no
> > > > > indication what they actually fix.
> > > > >
> > > > > The  available whitepapers and bitstream syntax document on
> TrueHD/MLP
> > > > > also do not seem to support more then 2 channel in the first
> > > > > substream, limiting it to a stereo presentation in the first, up
> to 6
> > > > > channel in the second, and up to 8 channel in the third substream
> (and
> > > > > 16 in the extended substream)
> > > > >
> > > >
> > > > This statement is not in sync with reality.
> > > >
> > > > I have sample that 946... fixes, single stream with > 2 channels.
> > >
> > > Iam not sure i understand what you mean exactly but
> > >
> > > the sample which it breaks is here:
> > > https://samples.ffmpeg.org/ffmpeg-bugs/trac/ticket1726/Mono.thd
> > >
> > > can you look into this issue, you as author of the change maybe
> > > remember why you did it and so are better qualified to adjust it.
> > >
> >
> > Sorry but that sample was never decoded properly. As it is not mono and
> it
> > is not stereo.
>
> around the time of 3.2 it was decoded as mono and it sounds reasonable
> after that until 946... it was decoded as stereo with only the left channel
> after 946... it now doesnt decode at all
>
> it would be nice if we could support this kind of file
>

To really support it, it needs both streams to be presented.


>
> thx
>
> [...]
> --
> Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
>
> Those who are too smart to engage in politics are punished by being
> governed by those who are dumber. -- Plato
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
> To unsubscribe, visit link above, or email
> ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
>
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

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

Re: [FFmpeg-devel] 5.0 release

[Michael Niedermayer]

On Mon, Jan 03, 2022 at 09:29:40PM +0100, Paul B Mahol wrote:
> On Mon, Jan 3, 2022 at 9:14 PM Michael Niedermayer 
> wrote:
> 
> > On Mon, Jan 03, 2022 at 08:25:44PM +0100, Paul B Mahol wrote:
> > > On Mon, Jan 3, 2022 at 7:58 PM Michael Niedermayer <
> > mich...@niedermayer.cc>
> > > wrote:
> > >
> > > > On Mon, Jan 03, 2022 at 07:04:48PM +0100, Paul B Mahol wrote:
> > > > > On Mon, Jan 3, 2022 at 6:18 PM Hendrik Leppkes 
> > > > wrote:
> > > > >
> > > > > > On Mon, Jan 3, 2022 at 5:14 PM Michael Niedermayer
> > > > > >  wrote:
> > > > > > >
> > > > > > > On Mon, Jan 03, 2022 at 06:31:37AM +0100, Jean-Baptiste Kempf
> > wrote:
> > > > > > > > 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?
> > > > > > >
> > > > > > > the mov issue was fixed, channels dont seem to happen
> > > > > > > theres a regression with 946493eb3e072b499909f606625480c928834a44
> > > > > > > that ive reported 1 day after the patch was posted and pinged 11
> > days
> > > > > > later
> > > > > > >
> > > > > > > 221073 rsF 1112 16:11 To ffmpeg-devel (2,3K) Re: [FFmpeg-devel]
> > > > > > [FFmpeg-cvslog] avcodec/mlpdec: cover case when >2 channels are in
> > > > single
> > > > > > substream
> > > > > > > 221074  sF 1123  0:00 To ffmpeg-devel (3,5K) └─>
> > > > > > >
> > > > > > > thats not branch blocking, a bugfix is just a normal backport
> > > > > > > I dont have the file that
> > 946493eb3e072b499909f606625480c928834a44
> > > > fixes
> > > > > > > so trying to fix it is like working blindfolded, thats why ive
> > so far
> > > > > > > waited for the author to respond and take a look
> > > > > > >
> > > > > >
> > > > > > As far as I can tell, the recent mlpdec changes seem to be
> > intended to
> > > > > > fix playback of streams made by our own experimental encoder, and
> > not
> > > > > > independent samples.
> > > >
> > > > How can that be reproduced ?
> > > > I tried with a 5.1 stream and the decoded output is not changing with
> > this
> > > > patch
> > > >
> > > >
> > > > > > So perhaps those should be reverted for a stable release (or
> > > > > > generally), seeing as there is no response 2 months later, and no
> > > > > > indication what they actually fix.
> > > > > >
> > > > > > The  available whitepapers and bitstream syntax document on
> > TrueHD/MLP
> > > > > > also do not seem to support more then 2 channel in the first
> > > > > > substream, limiting it to a stereo presentation in the first, up
> > to 6
> > > > > > channel in the second, and up to 8 channel in the third substream
> > (and
> > > > > > 16 in the extended substream)
> > > > > >
> > > > >
> > > > > This statement is not in sync with reality.
> > > > >
> > > > > I have sample that 946... fixes, single stream with > 2 channels.
> > > >
> > > > Iam not sure i understand what you mean exactly but
> > > >
> > > > the sample which it breaks is here:
> > > > https://samples.ffmpeg.org/ffmpeg-bugs/trac/ticket1726/Mono.thd
> > > >
> > > > can you look into this issue, you as author of the change maybe
> > > > remember why you did it and so are better qualified to adjust it.
> > > >
> > >
> > > Sorry but that sample was never decoded properly. As it is not mono and
> > it
> > > is not stereo.
> >
> > around the time of 3.2 it was decoded as mono and it sounds reasonable
> > after that until 946... it was decoded as stereo with only the left channel
> > after 946... it now doesnt decode at all
> >
> > it would be nice if we could support this kind of file
> >
> 
> To really support it, it needs both streams to be presented.

yes

thx

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

No great genius has ever existed without some touch of madness. -- Aristotle


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

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

[FFmpeg-devel] [RFC] QSV: Introduce min Compile-SDK Version and check for Runtime-Versions instead

[Soft Works]

Hi,

this is a follow-up to my recently submitted patch:

“avfilter/vpp_qsv: fix regression on older api versions (e.g. 1.11)”

That patch only fixes the one important regression from multiple issues which 
have been introduced by recent changes. Those changes have gone in a less
than ideal direction, because they have introduced checks based on the version
of the MSDK which ffmpeg is being compiled against, but they didn’t add 
checks for the runtime libmfx/MSDK versions – and this causes failures, 
sometimes even for functionality which has worked before (=>regressions).

Background

- the compile-sdk version determines which features can be used
  but only when
  - the runtime SDK version supports it
and
  - the hardware (GPU gen) supports it
- ALL compile-sdk versions can interface with ALL runtime MSDK 
  versions (basically), no matter whether runtime version is newer or
  older
- At least on Windows, some hw is stuck at a certain runtime version,
  e.g.: there are new drivers for Broadwell, but the MSDK runtime
  is always 1.11


Conclusion

Adding checks for the runtime MSDK versions is required wherever a feature
might not be supported by older MSDK runtimes - I think that's an obvious
necessity.


Question

Having both - run-time and compile-time checks all over the code is adding 
a lot of complexity and makes it difficult to maintain and work with.

Hence, I'm wondering whether we couldn't/shouldn't introduce a minimum 
MSDK compile-time version, for example 1.22, or even later?

This would allow simplification of the QSV code in many places where run-time
version checks are actually needed instead.

Over time, there have been better and worse MSDK versions, and there 
should still be enough room for choosing, but I don't think there's any
reason why somebody would still want to compile against some really old 
(e.g. < 1.22) MSDK version. 

Please share your thoughts on this subject..

softworkz


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

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

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

[Kyle Swanson]

Hi,

On Sun, Jan 2, 2022 at 9:21 PM Andreas Rheinhardt
 wrote:
> >
> >  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.

Good point, thanks. New patch attached. No more missing options,
everything that should be deprecated has been marked as deprecated and
appropriate fallback behavior implemented.

Thanks,
Kyle


0001-avfilter-vf_libvmaf-update-filter-for-libvmaf-v2.0.0.patch
Description: Binary data
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

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

Re: [FFmpeg-devel] [PATCH v7 01/12] avdevice/dshow: prevent NULL access

[Roger Pack]

On Fri, Dec 24, 2021 at 1:50 AM Gyan Doshi  wrote:
>
>
>
> On 2021-12-23 10:54 am, Gyan Doshi wrote:
> >
> >
> > On 2021-12-23 10:39 am, Roger Pack wrote:
> >> These LGTM, could someone apply them for me?
> >> Thanks!
> >
> > Tomorrow, if no else does, or objects.
>
> Pushed as
>
> 7b21841ce45ef4ab486c3c94a714345b878a70fd...a1c4929f65cc75b7175622a007b1e4bd37043d41
>
> Had to correct a few trailing whitespace errors.
>
> Regards,
> Gyan

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

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

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

[Roger Pack]

These LGTM.  Feel free to add yourself as a dshow maintainer if so
interested, as well! :)

On Sun, Jan 2, 2022 at 2:50 AM Diederick Niehorster  wrote:
>
> 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".
___
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

[Soft Works]

> -Original Message-
> From: ffmpeg-devel  On Behalf Of Jean-
> Baptiste Kempf
> Sent: Monday, January 3, 2022 6:32 AM
> To: ffmpeg-devel@ffmpeg.org
> Subject: Re: [FFmpeg-devel] 5.0 release
> 
> 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?

If you don't want to ship a regression:

[PATCH v2] avfilter/vpp_qsv: fix regression on older api versions (e.g. 1.11)

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

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

Re: [FFmpeg-devel] [PATCH v2] avfilter/vpp_qsv: fix regression on older api versions (e.g. 1.11)

[Xiang, Haihao]

On Sun, 2022-01-02 at 03:41 +, ffmpegagent wrote:
> From: softworkz 
> 
> Commit 8b83dad82512a6948b63408f964463b063ad24c9 introduced a
> regression in a way that scaling via vpp_qsv doesn't work any longer
> for devices with an MSDK runtime version lower than 1.19. This is true
> for older CPUs which are stuck at 1.11.
> The commit added checks for the compile-sdk version but it didn't test
> for the runtime version.
> 
> Signed-off-by: softworkz 
> ---
> avfilter/vpp_qsv: fix regression on older api versions (e.g. 1.11)
> 
> Fix a recently introduced regression when using QSV VPP.
> 
> v2: Fixed commit message wrapping
> 
> Published-As: 
> https://github.com/ffstaging/FFmpeg/releases/tag/pr-ffstaging-15%2Fsoftworkz%2Fqsv_vpp_regression-v2
> Fetch-It-Via: git fetch https://github.com/ffstaging/FFmpeg pr-ffstaging-
> 15/softworkz/qsv_vpp_regression-v2
> Pull-Request: https://github.com/ffstaging/FFmpeg/pull/15
> 
> Range-diff vs v1:
> 
>  1:  eea966f702 ! 1:  ccede9d840 avfilter/vpp_qsv: fix regression on older api
> versions (e.g. 1.11)
>  @@ Metadata
>## Commit message ##
>   avfilter/vpp_qsv: fix regression on older api versions (e.g. 1.11)
>   
>  -Commit 8b83dad82512a6948b63408f964463b063ad24c9 introduced a
> regression in a way
>  -that scaling via vpp_qsv didn't work any longer for devices with an
> MSDK runtime
>  -version lower than 1.19. This is true for older CPUs which are stuck
> at 1.11.
>  -The commit added checks for the compile-sdk version but it didn't
> test for the
>  -runtime version.
>  +Commit 8b83dad82512a6948b63408f964463b063ad24c9 introduced a
>  +regression in a way that scaling via vpp_qsv doesn't work any longer
>  +for devices with an MSDK runtime version lower than 1.19. This is
> true
>  +for older CPUs which are stuck at 1.11.
>  +The commit added checks for the compile-sdk version but it didn't
> test
>  +for the runtime version.
>   
>   Signed-off-by: softworkz 
>   
> 
> 
>  libavfilter/vf_vpp_qsv.c | 32 
>  1 file changed, 20 insertions(+), 12 deletions(-)
> 
> diff --git a/libavfilter/vf_vpp_qsv.c b/libavfilter/vf_vpp_qsv.c
> index ab58a5777e..09590157e3 100644
> --- a/libavfilter/vf_vpp_qsv.c
> +++ b/libavfilter/vf_vpp_qsv.c
> @@ -139,8 +139,9 @@ static const AVOption options[] = {
>  { "height", "Output video height", OFFSET(oh), AV_OPT_TYPE_STRING, {
> .str="w*ch/cw" }, 0, 255, .flags = FLAGS },
>  { "format", "Output pixel format", OFFSET(output_format_str),
> AV_OPT_TYPE_STRING, { .str = "same" }, .flags = FLAGS },
>  { "async_depth", "Internal parallelization depth, the higher the value
> the higher the latency.", OFFSET(async_depth), AV_OPT_TYPE_INT, { .i64 = 0 },
> 0, INT_MAX, .flags = FLAGS },
> +#ifdef QSV_HAVE_SCALING_CONFIG
>  { "scale_mode", "scale mode: 0=auto, 1=low power, 2=high quality",
> OFFSET(scale_mode), AV_OPT_TYPE_INT, { .i64 = MFX_SCALING_MODE_DEFAULT },
> MFX_SCALING_MODE_DEFAULT, MFX_SCALING_MODE_QUALITY, .flags = FLAGS, "scale
> mode" },
> -
> +#endif
>  { NULL }
>  };
>  
> @@ -304,6 +305,7 @@ static int config_output(AVFilterLink *outlink)
>  QSVVPPParam param = { NULL };
>  QSVVPPCrop  crop  = { 0 };
>  mfxExtBuffer*ext_buf[ENH_FILTERS_COUNT];
> +mfxVersion  mfx_version;
>  AVFilterLink*inlink = ctx->inputs[0];
>  enum AVPixelFormat in_format;
>  
> @@ -317,6 +319,11 @@ static int config_output(AVFilterLink *outlink)
>  param.ext_buf   = ext_buf;
>  param.async_depth   = vpp->async_depth;
>  
> +if (MFXQueryVersion(vpp->qsv->session, &mfx_version) < 0) {
> +av_log(ctx, AV_LOG_ERROR, "Failed to query mfx version.\n");
> +return AVERROR(EINVAL);
> +}
> +
>  if (inlink->format == AV_PIX_FMT_QSV) {
>   if (!inlink->hw_frames_ctx || !inlink->hw_frames_ctx->data)
>   return AVERROR(EINVAL);
> @@ -467,19 +474,20 @@ static int config_output(AVFilterLink *outlink)
>  #endif
>  }
>  
> -if (inlink->w != outlink->w || inlink->h != outlink->h) {
>  #ifdef QSV_HAVE_SCALING_CONFIG
> -memset(&vpp->scale_conf, 0, sizeof(mfxExtVPPScaling));
> -vpp->scale_conf.Header.BufferId= MFX_EXTBUFF_VPP_SCALING;
> -vpp->scale_conf.Header.BufferSz= sizeof(mfxExtVPPScaling);
> -vpp->scale_conf.ScalingMode= vpp->scale_mode;
> -
> -param.ext_buf[param.num_ext_buf++] = (mfxExtBuffer*)&vpp->scale_conf;
> -#else
> -av_log(ctx, AV_LOG_WARNING, "The QSV VPP Scale option is "
> -"not supported with this MSDK version.\n");
> -#endif
> +if (inlink->w != outlink->w || inlink->h != outlink->h) {
> +if (QSV_RUNTIME_VERSION_ATLEAST(mfx_version, 1, 19)) {
> +memset(&vpp->scale_conf, 0, sizeof(mfxExtVPPScaling));
> +vpp->scale_conf.Header.BufferId= MFX_EXTBUFF

[FFmpeg-devel] [PATCH] avcodec/dvdsubdec: fix incorrect yellow appearance of dvd subtitles

[ffmpegagent]

From: softworkz 

The guess_palette() implementation is questionable in itself
as its results don't match those from other DVD subtitle decoders.

This commit starts cleanup by fixing an obvious bug which has made
certain DVD subs appear yellow instead of white or grey for more than
10 years..

Signed-off-by: softworkz 
---
avcodec/dvdsubdec: fix incorrect yellow appearance of dvd subtitles

Fixes an age-old bug in decoding DVD subtitles.

Ever wondered why certain DVD subtitles are shown in yellow color when
ffmpeg is involved...

Published-As: 
https://github.com/ffstaging/FFmpeg/releases/tag/pr-ffstaging-16%2Fsoftworkz%2Fpatch_dvdsubdec_fix-v1
Fetch-It-Via: git fetch https://github.com/ffstaging/FFmpeg 
pr-ffstaging-16/softworkz/patch_dvdsubdec_fix-v1
Pull-Request: https://github.com/ffstaging/FFmpeg/pull/16

 libavcodec/dvdsubdec.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/libavcodec/dvdsubdec.c b/libavcodec/dvdsubdec.c
index 52259f0730..a3fdb535a5 100644
--- a/libavcodec/dvdsubdec.c
+++ b/libavcodec/dvdsubdec.c
@@ -400,7 +400,7 @@ static int decode_dvd_subtitles(DVDSubContext *ctx, 
AVSubtitle *sub_header,
 } else {
 sub_header->rects[0]->nb_colors = 4;
 guess_palette(ctx, 
(uint32_t*)sub_header->rects[0]->data[1],
-  0x00);
+  0xff);
 }
 sub_header->rects[0]->x = x1;
 sub_header->rects[0]->y = y1;

base-commit: 573b6b8a607398c5f34108efda9c29d41c5727ff
-- 
ffmpeg-codebot
___
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] avfilter/vpp_qsv: fix regression on older api versions (e.g. 1.11)

[Soft Works]

> -Original Message-
> From: Xiang, Haihao 
> Sent: Tuesday, January 4, 2022 3:16 AM
> To: ffmpeg-devel@ffmpeg.org
> Cc: softwo...@hotmail.com
> Subject: Re: [FFmpeg-devel] [PATCH v2] avfilter/vpp_qsv: fix regression on
> older api versions (e.g. 1.11)
> 
> On Sun, 2022-01-02 at 03:41 +, ffmpegagent wrote:
> > From: softworkz 
> >
> > Commit 8b83dad82512a6948b63408f964463b063ad24c9 introduced a
> > regression in a way that scaling via vpp_qsv doesn't work any longer
> > for devices with an MSDK runtime version lower than 1.19. This is true
> > for older CPUs which are stuck at 1.11.
> > The commit added checks for the compile-sdk version but it didn't test
> > for the runtime version.
> >
> > Signed-off-by: softworkz 
> > ---
> > avfilter/vpp_qsv: fix regression on older api versions (e.g. 1.11)
> >
> > Fix a recently introduced regression when using QSV VPP.
> >
> > v2: Fixed commit message wrapping
> >
> > Published-As:
> > https://github.com/ffstaging/FFmpeg/releases/tag/pr-ffstaging-
> 15%2Fsoftworkz%2Fqsv_vpp_regression-v2
> > Fetch-It-Via: git fetch https://github.com/ffstaging/FFmpeg pr-ffstaging-
> > 15/softworkz/qsv_vpp_regression-v2
> > Pull-Request: https://github.com/ffstaging/FFmpeg/pull/15
> >
> > Range-diff vs v1:
> >
> >  1:  eea966f702 ! 1:  ccede9d840 avfilter/vpp_qsv: fix regression on older
> api
> > versions (e.g. 1.11)
> >  @@ Metadata
> >## Commit message ##
> >   avfilter/vpp_qsv: fix regression on older api versions (e.g.
> 1.11)
> >
> >  -Commit 8b83dad82512a6948b63408f964463b063ad24c9 introduced a
> > regression in a way
> >  -that scaling via vpp_qsv didn't work any longer for devices with
> an
> > MSDK runtime
> >  -version lower than 1.19. This is true for older CPUs which are
> stuck
> > at 1.11.
> >  -The commit added checks for the compile-sdk version but it didn't
> > test for the
> >  -runtime version.
> >  +Commit 8b83dad82512a6948b63408f964463b063ad24c9 introduced a
> >  +regression in a way that scaling via vpp_qsv doesn't work any
> longer
> >  +for devices with an MSDK runtime version lower than 1.19. This is
> > true
> >  +for older CPUs which are stuck at 1.11.
> >  +The commit added checks for the compile-sdk version but it didn't
> > test
> >  +for the runtime version.
> >
> >   Signed-off-by: softworkz 
> >
> >
> >
> >  libavfilter/vf_vpp_qsv.c | 32 
> >  1 file changed, 20 insertions(+), 12 deletions(-)
> >
> > diff --git a/libavfilter/vf_vpp_qsv.c b/libavfilter/vf_vpp_qsv.c
> > index ab58a5777e..09590157e3 100644
> > --- a/libavfilter/vf_vpp_qsv.c
> > +++ b/libavfilter/vf_vpp_qsv.c
> > @@ -139,8 +139,9 @@ static const AVOption options[] = {
> >  { "height", "Output video height", OFFSET(oh), AV_OPT_TYPE_STRING, {
> > .str="w*ch/cw" }, 0, 255, .flags = FLAGS },
> >  { "format", "Output pixel format", OFFSET(output_format_str),
> > AV_OPT_TYPE_STRING, { .str = "same" }, .flags = FLAGS },
> >  { "async_depth", "Internal parallelization depth, the higher the value
> > the higher the latency.", OFFSET(async_depth), AV_OPT_TYPE_INT, { .i64 = 0
> },
> > 0, INT_MAX, .flags = FLAGS },
> > +#ifdef QSV_HAVE_SCALING_CONFIG
> >  { "scale_mode", "scale mode: 0=auto, 1=low power, 2=high quality",
> > OFFSET(scale_mode), AV_OPT_TYPE_INT, { .i64 = MFX_SCALING_MODE_DEFAULT },
> > MFX_SCALING_MODE_DEFAULT, MFX_SCALING_MODE_QUALITY, .flags = FLAGS, "scale
> > mode" },
> > -
> > +#endif
> >  { NULL }
> >  };
> >
> > @@ -304,6 +305,7 @@ static int config_output(AVFilterLink *outlink)
> >  QSVVPPParam param = { NULL };
> >  QSVVPPCrop  crop  = { 0 };
> >  mfxExtBuffer*ext_buf[ENH_FILTERS_COUNT];
> > +mfxVersion  mfx_version;
> >  AVFilterLink*inlink = ctx->inputs[0];
> >  enum AVPixelFormat in_format;
> >
> > @@ -317,6 +319,11 @@ static int config_output(AVFilterLink *outlink)
> >  param.ext_buf   = ext_buf;
> >  param.async_depth   = vpp->async_depth;
> >
> > +if (MFXQueryVersion(vpp->qsv->session, &mfx_version) < 0) {
> > +av_log(ctx, AV_LOG_ERROR, "Failed to query mfx version.\n");
> > +return AVERROR(EINVAL);
> > +}
> > +
> >  if (inlink->format == AV_PIX_FMT_QSV) {
> >   if (!inlink->hw_frames_ctx || !inlink->hw_frames_ctx->data)
> >   return AVERROR(EINVAL);
> > @@ -467,19 +474,20 @@ static int config_output(AVFilterLink *outlink)
> >  #endif
> >  }
> >
> > -if (inlink->w != outlink->w || inlink->h != outlink->h) {
> >  #ifdef QSV_HAVE_SCALING_CONFIG
> > -memset(&vpp->scale_conf, 0, sizeof(mfxExtVPPScaling));
> > -vpp->scale_conf.Header.BufferId= MFX_EXTBUFF_VPP_SCALING;
> > -vpp->scale_conf.Header.BufferSz= sizeof(mfxExtVPPScaling);
> > -vpp->scale_conf.ScalingMode= vpp->scale_mode;
> > -
> > -param.ext_buf[param.num_ex

Re: [FFmpeg-devel] [PATCH v2] avfilter/vpp_qsv: fix regression on older api versions (e.g. 1.11)

[Xiang, Haihao]

On Tue, 2022-01-04 at 02:25 +, Soft Works wrote:
> > -Original Message-
> > From: Xiang, Haihao 
> > Sent: Tuesday, January 4, 2022 3:16 AM
> > To: ffmpeg-devel@ffmpeg.org
> > Cc: softwo...@hotmail.com
> > Subject: Re: [FFmpeg-devel] [PATCH v2] avfilter/vpp_qsv: fix regression on
> > older api versions (e.g. 1.11)
> > 
> > On Sun, 2022-01-02 at 03:41 +, ffmpegagent wrote:
> > > From: softworkz 
> > > 
> > > Commit 8b83dad82512a6948b63408f964463b063ad24c9 introduced a
> > > regression in a way that scaling via vpp_qsv doesn't work any longer
> > > for devices with an MSDK runtime version lower than 1.19. This is true
> > > for older CPUs which are stuck at 1.11.
> > > The commit added checks for the compile-sdk version but it didn't test
> > > for the runtime version.
> > > 
> > > Signed-off-by: softworkz 
> > > ---
> > > avfilter/vpp_qsv: fix regression on older api versions (e.g. 1.11)
> > > 
> > > Fix a recently introduced regression when using QSV VPP.
> > > 
> > > v2: Fixed commit message wrapping
> > > 
> > > Published-As:
> > > https://github.com/ffstaging/FFmpeg/releases/tag/pr-ffstaging-
> > 
> > 15%2Fsoftworkz%2Fqsv_vpp_regression-v2
> > > Fetch-It-Via: git fetch https://github.com/ffstaging/FFmpeg pr-ffstaging-
> > > 15/softworkz/qsv_vpp_regression-v2
> > > Pull-Request: https://github.com/ffstaging/FFmpeg/pull/15
> > > 
> > > Range-diff vs v1:
> > > 
> > >  1:  eea966f702 ! 1:  ccede9d840 avfilter/vpp_qsv: fix regression on older
> > 
> > api
> > > versions (e.g. 1.11)
> > >  @@ Metadata
> > >## Commit message ##
> > >   avfilter/vpp_qsv: fix regression on older api versions (e.g.
> > 
> > 1.11)
> > > 
> > >  -Commit 8b83dad82512a6948b63408f964463b063ad24c9 introduced a
> > > regression in a way
> > >  -that scaling via vpp_qsv didn't work any longer for devices with
> > 
> > an
> > > MSDK runtime
> > >  -version lower than 1.19. This is true for older CPUs which are
> > 
> > stuck
> > > at 1.11.
> > >  -The commit added checks for the compile-sdk version but it
> > > didn't
> > > test for the
> > >  -runtime version.
> > >  +Commit 8b83dad82512a6948b63408f964463b063ad24c9 introduced a
> > >  +regression in a way that scaling via vpp_qsv doesn't work any
> > 
> > longer
> > >  +for devices with an MSDK runtime version lower than 1.19. This
> > > is
> > > true
> > >  +for older CPUs which are stuck at 1.11.
> > >  +The commit added checks for the compile-sdk version but it
> > > didn't
> > > test
> > >  +for the runtime version.
> > > 
> > >   Signed-off-by: softworkz 
> > > 
> > > 
> > > 
> > >  libavfilter/vf_vpp_qsv.c | 32 
> > >  1 file changed, 20 insertions(+), 12 deletions(-)
> > > 
> > > diff --git a/libavfilter/vf_vpp_qsv.c b/libavfilter/vf_vpp_qsv.c
> > > index ab58a5777e..09590157e3 100644
> > > --- a/libavfilter/vf_vpp_qsv.c
> > > +++ b/libavfilter/vf_vpp_qsv.c
> > > @@ -139,8 +139,9 @@ static const AVOption options[] = {
> > >  { "height", "Output video height", OFFSET(oh), AV_OPT_TYPE_STRING, {
> > > .str="w*ch/cw" }, 0, 255, .flags = FLAGS },
> > >  { "format", "Output pixel format", OFFSET(output_format_str),
> > > AV_OPT_TYPE_STRING, { .str = "same" }, .flags = FLAGS },
> > >  { "async_depth", "Internal parallelization depth, the higher the
> > > value
> > > the higher the latency.", OFFSET(async_depth), AV_OPT_TYPE_INT, { .i64 = 0
> > 
> > },
> > > 0, INT_MAX, .flags = FLAGS },
> > > +#ifdef QSV_HAVE_SCALING_CONFIG
> > >  { "scale_mode", "scale mode: 0=auto, 1=low power, 2=high quality",
> > > OFFSET(scale_mode), AV_OPT_TYPE_INT, { .i64 = MFX_SCALING_MODE_DEFAULT },
> > > MFX_SCALING_MODE_DEFAULT, MFX_SCALING_MODE_QUALITY, .flags = FLAGS, "scale
> > > mode" },
> > > -
> > > +#endif
> > >  { NULL }
> > >  };
> > > 
> > > @@ -304,6 +305,7 @@ static int config_output(AVFilterLink *outlink)
> > >  QSVVPPParam param = { NULL };
> > >  QSVVPPCrop  crop  = { 0 };
> > >  mfxExtBuffer*ext_buf[ENH_FILTERS_COUNT];
> > > +mfxVersion  mfx_version;
> > >  AVFilterLink*inlink = ctx->inputs[0];
> > >  enum AVPixelFormat in_format;
> > > 
> > > @@ -317,6 +319,11 @@ static int config_output(AVFilterLink *outlink)
> > >  param.ext_buf   = ext_buf;
> > >  param.async_depth   = vpp->async_depth;
> > > 
> > > +if (MFXQueryVersion(vpp->qsv->session, &mfx_version) < 0) {
> > > +av_log(ctx, AV_LOG_ERROR, "Failed to query mfx version.\n");
> > > +return AVERROR(EINVAL);
> > > +}
> > > +
> > >  if (inlink->format == AV_PIX_FMT_QSV) {
> > >   if (!inlink->hw_frames_ctx || !inlink->hw_frames_ctx->data)
> > >   return AVERROR(EINVAL);
> > > @@ -467,19 +474,20 @@ static int config_output(AVFilterLink *outlink)
> > >  #endif
> > >  }
> > > 
> > > -if (inlink->w != outlink->w || inlink->h != outlink->h) {
> >

Re: [FFmpeg-devel] [PATCH v2] avfilter/vpp_qsv: fix regression on older api versions (e.g. 1.11)

[Soft Works]

> -Original Message-
> From: Xiang, Haihao 
> Sent: Tuesday, January 4, 2022 3:37 AM
> To: ffmpeg-devel@ffmpeg.org; softwo...@hotmail.com
> Subject: Re: [FFmpeg-devel] [PATCH v2] avfilter/vpp_qsv: fix regression on
> older api versions (e.g. 1.11)
> 
> On Tue, 2022-01-04 at 02:25 +, Soft Works wrote:
> > > -Original Message-
> > > From: Xiang, Haihao 
> > > Sent: Tuesday, January 4, 2022 3:16 AM
> > > To: ffmpeg-devel@ffmpeg.org
> > > Cc: softwo...@hotmail.com
> > > Subject: Re: [FFmpeg-devel] [PATCH v2] avfilter/vpp_qsv: fix regression
> on
> > > older api versions (e.g. 1.11)
> > >
> > > On Sun, 2022-01-02 at 03:41 +, ffmpegagent wrote:
> > > > From: softworkz 
> > > >
> > > > Commit 8b83dad82512a6948b63408f964463b063ad24c9 introduced a
> > > > regression in a way that scaling via vpp_qsv doesn't work any longer
> > > > for devices with an MSDK runtime version lower than 1.19. This is true
> > > > for older CPUs which are stuck at 1.11.
> > > > The commit added checks for the compile-sdk version but it didn't test
> > > > for the runtime version.
> > > >
> > > > Signed-off-by: softworkz 
> > > > ---
> > > > avfilter/vpp_qsv: fix regression on older api versions (e.g. 1.11)
> > > >
> > > > Fix a recently introduced regression when using QSV VPP.
> > > >
> > > > v2: Fixed commit message wrapping
> > > >
> > > > Published-As:
> > > > https://github.com/ffstaging/FFmpeg/releases/tag/pr-ffstaging-
> > >
> > > 15%2Fsoftworkz%2Fqsv_vpp_regression-v2
> > > > Fetch-It-Via: git fetch https://github.com/ffstaging/FFmpeg pr-
> ffstaging-
> > > > 15/softworkz/qsv_vpp_regression-v2
> > > > Pull-Request: https://github.com/ffstaging/FFmpeg/pull/15
> > > >
> > > > Range-diff vs v1:
> > > >
> > > >  1:  eea966f702 ! 1:  ccede9d840 avfilter/vpp_qsv: fix regression on
> older
> > >
> > > api
> > > > versions (e.g. 1.11)
> > > >  @@ Metadata
> > > >## Commit message ##
> > > >   avfilter/vpp_qsv: fix regression on older api versions (e.g.
> > >
> > > 1.11)
> > > >
> > > >  -Commit 8b83dad82512a6948b63408f964463b063ad24c9 introduced a
> > > > regression in a way
> > > >  -that scaling via vpp_qsv didn't work any longer for devices
> with
> > >
> > > an
> > > > MSDK runtime
> > > >  -version lower than 1.19. This is true for older CPUs which
> are
> > >
> > > stuck
> > > > at 1.11.
> > > >  -The commit added checks for the compile-sdk version but it
> > > > didn't
> > > > test for the
> > > >  -runtime version.
> > > >  +Commit 8b83dad82512a6948b63408f964463b063ad24c9 introduced a
> > > >  +regression in a way that scaling via vpp_qsv doesn't work any
> > >
> > > longer
> > > >  +for devices with an MSDK runtime version lower than 1.19.
> This
> > > > is
> > > > true
> > > >  +for older CPUs which are stuck at 1.11.
> > > >  +The commit added checks for the compile-sdk version but it
> > > > didn't
> > > > test
> > > >  +for the runtime version.
> > > >
> > > >   Signed-off-by: softworkz 
> > > >
> > > >
> > > >
> > > >  libavfilter/vf_vpp_qsv.c | 32 
> > > >  1 file changed, 20 insertions(+), 12 deletions(-)
> > > >
> > > > diff --git a/libavfilter/vf_vpp_qsv.c b/libavfilter/vf_vpp_qsv.c
> > > > index ab58a5777e..09590157e3 100644
> > > > --- a/libavfilter/vf_vpp_qsv.c
> > > > +++ b/libavfilter/vf_vpp_qsv.c
> > > > @@ -139,8 +139,9 @@ static const AVOption options[] = {
> > > >  { "height", "Output video height", OFFSET(oh), AV_OPT_TYPE_STRING,
> {
> > > > .str="w*ch/cw" }, 0, 255, .flags = FLAGS },
> > > >  { "format", "Output pixel format", OFFSET(output_format_str),
> > > > AV_OPT_TYPE_STRING, { .str = "same" }, .flags = FLAGS },
> > > >  { "async_depth", "Internal parallelization depth, the higher the
> > > > value
> > > > the higher the latency.", OFFSET(async_depth), AV_OPT_TYPE_INT, { .i64
> = 0
> > >
> > > },
> > > > 0, INT_MAX, .flags = FLAGS },
> > > > +#ifdef QSV_HAVE_SCALING_CONFIG
> > > >  { "scale_mode", "scale mode: 0=auto, 1=low power, 2=high quality",
> > > > OFFSET(scale_mode), AV_OPT_TYPE_INT, { .i64 = MFX_SCALING_MODE_DEFAULT
> },
> > > > MFX_SCALING_MODE_DEFAULT, MFX_SCALING_MODE_QUALITY, .flags = FLAGS,
> "scale
> > > > mode" },
> > > > -
> > > > +#endif
> > > >  { NULL }
> > > >  };
> > > >
> > > > @@ -304,6 +305,7 @@ static int config_output(AVFilterLink *outlink)
> > > >  QSVVPPParam param = { NULL };
> > > >  QSVVPPCrop  crop  = { 0 };
> > > >  mfxExtBuffer*ext_buf[ENH_FILTERS_COUNT];
> > > > +mfxVersion  mfx_version;
> > > >  AVFilterLink*inlink = ctx->inputs[0];
> > > >  enum AVPixelFormat in_format;
> > > >
> > > > @@ -317,6 +319,11 @@ static int config_output(AVFilterLink *outlink)
> > > >  param.ext_buf   = ext_buf;
> > > >  param.async_depth   = vpp->async_depth;
> > > >
> > > > +if (MFXQueryVersion(vpp->qsv->session, &mfx_version)

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

[Gyan Doshi]

On 2022-01-04 05:02 am, Roger Pack wrote:

These LGTM.  Feel free to add yourself as a dshow maintainer if so
interested, as well! :)


I assume these need to be pushed too.

Gyan



On Sun, Jan 2, 2022 at 2:50 AM Diederick Niehorster  wrote:

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

___
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] avformat/mxfdec: support MCA audio information

[Pierre-Anthony Lemieux]

On Sun, Jan 2, 2022 at 11:13 PM Andreas Rheinhardt
 wrote:
>
> 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.

I have never seen or created an MXF file that uses MCA and that has
16-bit PCM. I do not recommend treading new ground.

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

Ok. See:

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

>
> - 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 mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

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

[FFmpeg-devel] [PATCH v3 1/6] lavc/arm: dont assign hevc_qpel functions for non-multiple of 8 widths

[J. Dekker]

The assembly is written assuming that the width is a multiple of 8.

However the real issue is the functions were errorneously assigned to
the 2, 4, 6 & 12 widths. This behaviour never broke the decoder as
samples which trigger the functions for these widths have not been found
in the wild. This relies on the mappings in ff_hevc_pel_weight[].

Signed-off-by: J. Dekker 
---
 libavcodec/arm/hevcdsp_init_neon.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

 This set has already been reviewed by Martin, sending to list for
 transparency.

diff --git a/libavcodec/arm/hevcdsp_init_neon.c 
b/libavcodec/arm/hevcdsp_init_neon.c
index 201a088dac..112edb5edd 100644
--- a/libavcodec/arm/hevcdsp_init_neon.c
+++ b/libavcodec/arm/hevcdsp_init_neon.c
@@ -270,7 +270,8 @@ av_cold void ff_hevc_dsp_init_neon(HEVCDSPContext *c, const 
int bit_depth)
 put_hevc_qpel_uw_neon[3][1]  = ff_hevc_put_qpel_uw_h1v3_neon_8;
 put_hevc_qpel_uw_neon[3][2]  = ff_hevc_put_qpel_uw_h2v3_neon_8;
 put_hevc_qpel_uw_neon[3][3]  = ff_hevc_put_qpel_uw_h3v3_neon_8;
-for (x = 0; x < 10; x++) {
+for (x = 3; x < 10; x++) {
+if (x == 4) continue;
 c->put_hevc_qpel[x][1][0] = ff_hevc_put_qpel_neon_wrapper;
 c->put_hevc_qpel[x][0][1] = ff_hevc_put_qpel_neon_wrapper;
 c->put_hevc_qpel[x][1][1] = ff_hevc_put_qpel_neon_wrapper;
-- 
2.32.0 (Apple Git-132)

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

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

[FFmpeg-devel] [PATCH v3 2/6] Revert "arm: hevc_qpel: Fix the assembly to work with non-multiple of 8 widths"

[J. Dekker]

This reverts commit 2589060b92eeeb944c6e2b50e38412c0c5fabcf4 which was
originally to fix the FATE test. The real cause of the test breakage was
fixed in 8dc8f04036eb27c8ad419839d4ed3bc67c44fe7a.

Signed-off-by: J. Dekker 
---
 libavcodec/arm/hevcdsp_qpel_neon.S | 18 +-
 1 file changed, 9 insertions(+), 9 deletions(-)

diff --git a/libavcodec/arm/hevcdsp_qpel_neon.S 
b/libavcodec/arm/hevcdsp_qpel_neon.S
index f71bec05ed..caa6efa766 100644
--- a/libavcodec/arm/hevcdsp_qpel_neon.S
+++ b/libavcodec/arm/hevcdsp_qpel_neon.S
@@ -237,7 +237,7 @@
 vld1.8{d23}, [r2], r3
 bne 8b
 subs  r5, #8
-ble   99f
+beq   99f
 mov r4, r12
 add r6, #16
 mov r0, r6
@@ -280,7 +280,7 @@
 vld1.8{d23}, [r2], r3
 bne 8b
 subs  r5, #8
-ble   99f
+beq   99f
 mov r4, r12
 add r6, #8
 mov r0, r6
@@ -310,7 +310,7 @@
 vld1.8{d23}, [r2], r3
 bne 8b
 subs  r5, #8
-ble   99f
+beq   99f
 mov r4, r12
 add r6, #8
 mov r0, r6
@@ -377,7 +377,7 @@ endfunc
 vst1.16   {q7}, [r0], r1
 bne   8b
 subs  r5, #8
-ble   99f
+beq  99f
 mov   r4, r12
 add   r6, #16
 mov   r0, r6
@@ -417,7 +417,7 @@ endfunc
 vst1.8d0, [r0], r1
 bne   8b
 subs  r5, #8
-ble   99f
+beq  99f
 mov   r4, r12
 add   r6, #8
 mov   r0, r6
@@ -446,7 +446,7 @@ endfunc
 vst1.8 d0, [r0], r1
 bne   8b
 subs  r5, #8
-ble   99f
+beq  99f
 mov   r4, r12
 add   r6, #8
 add   r10, #16
@@ -533,7 +533,7 @@ endfunc
 \filterh q7
 bne 8b
 subs  r5, #8
-ble 99f
+beq 99f
 mov r4, r12
 add r6, #16
 mov r0, r6
@@ -594,7 +594,7 @@ endfunc
 \filterh q7
 bne 8b
 subs  r5, #8
-ble 99f
+beq 99f
 mov r4, r12
 add r6, #8
 mov r0, r6
@@ -641,7 +641,7 @@ endfunc
 \filterh q7
 bne 8b
 subs  r5, #8
-ble 99f
+beq 99f
 mov r4, r12
 add r6, #8
 mov r0, r6
-- 
2.32.0 (Apple Git-132)

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

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

[FFmpeg-devel] [PATCH v3 3/6] lavc/aarch64: add hevc sao edge 16x16

[J. Dekker]

bench on AWS Graviton:

hevc_sao_edge_16x16_8_c: 1857.0
hevc_sao_edge_16x16_8_neon: 211.0
hevc_sao_edge_32x32_8_c: 7802.2
hevc_sao_edge_32x32_8_neon: 808.2
hevc_sao_edge_48x48_8_c: 16764.2
hevc_sao_edge_48x48_8_neon: 1796.5
hevc_sao_edge_64x64_8_c: 32647.5
hevc_sao_edge_64x64_8_neon: 3118.5

Signed-off-by: J. Dekker 
---
 libavcodec/aarch64/hevcdsp_init_aarch64.c |  8 ++-
 libavcodec/aarch64/hevcdsp_sao_neon.S | 65 +++
 2 files changed, 71 insertions(+), 2 deletions(-)

diff --git a/libavcodec/aarch64/hevcdsp_init_aarch64.c 
b/libavcodec/aarch64/hevcdsp_init_aarch64.c
index c785e46f79..747ff0412d 100644
--- a/libavcodec/aarch64/hevcdsp_init_aarch64.c
+++ b/libavcodec/aarch64/hevcdsp_init_aarch64.c
@@ -57,8 +57,8 @@ void ff_hevc_sao_band_filter_8x8_8_neon(uint8_t *_dst, 
uint8_t *_src,
   ptrdiff_t stride_dst, ptrdiff_t stride_src,
   int16_t *sao_offset_val, int sao_left_class,
   int width, int height);
-
-
+void ff_hevc_sao_edge_filter_16x16_8_neon(uint8_t *dst, uint8_t *src, 
ptrdiff_t stride_dst,
+  int16_t *sao_offset_val, int eo, int 
width, int height);
 
 av_cold void ff_hevc_dsp_init_aarch64(HEVCDSPContext *c, const int bit_depth)
 {
@@ -76,6 +76,10 @@ av_cold void ff_hevc_dsp_init_aarch64(HEVCDSPContext *c, 
const int bit_depth)
 c->idct_dc[2]  = ff_hevc_idct_16x16_dc_8_neon;
 c->idct_dc[3]  = ff_hevc_idct_32x32_dc_8_neon;
 c->sao_band_filter[0]  = ff_hevc_sao_band_filter_8x8_8_neon;
+c->sao_edge_filter[1]  =
+c->sao_edge_filter[2]  =
+c->sao_edge_filter[3]  =
+c->sao_edge_filter[4]  = ff_hevc_sao_edge_filter_16x16_8_neon;
 }
 if (bit_depth == 10) {
 c->add_residual[0] = ff_hevc_add_residual_4x4_10_neon;
diff --git a/libavcodec/aarch64/hevcdsp_sao_neon.S 
b/libavcodec/aarch64/hevcdsp_sao_neon.S
index f9fed8345b..4b895959d8 100644
--- a/libavcodec/aarch64/hevcdsp_sao_neon.S
+++ b/libavcodec/aarch64/hevcdsp_sao_neon.S
@@ -85,3 +85,68 @@ function ff_hevc_sao_band_filter_8x8_8_neon, export=1
 bne 1b
 ret
 endfunc
+
+// ASSUMES STRIDE_SRC = 192
+.Lsao_edge_pos:
+.word 1 // horizontal
+.word 192 // vertical
+.word 192 + 1 // 45 degree
+.word 192 - 1 // 135 degree
+
+// ff_hevc_sao_edge_filter_16x16_8_neon(char *dst, char *src, ptrdiff 
stride_dst,
+//  int16 *sao_offset_val, int eo, int 
width, int height)
+function ff_hevc_sao_edge_filter_16x16_8_neon, export=1
+adr x7, .Lsao_edge_pos
+ld1 {v3.8h}, [x3]  // load sao_offset_val
+sxtwx5, w5
+ldr w4, [x7, w4, uxtw #2]  // stride_src
+mov v3.h[7], v3.h[0]   // reorder to [1,2,0,3,4]
+mov v3.h[0], v3.h[1]
+mov v3.h[1], v3.h[2]
+mov v3.h[2], v3.h[7]
+// split 16bit values into two tables
+uzp2v1.16b, v3.16b, v3.16b // sao_offset_val -> upper
+uzp1v0.16b, v3.16b, v3.16b // sao_offset_val -> lower
+moviv2.16b, #2
+mov x15, #192
+// strides between end of line and next src/dst
+sub x15, x15, x5   // stride_src - width
+sub x16, x2, x5// stride_dst - width
+mov x11, x1// copy base src
+1:  // new line
+mov x14, x5// copy width
+sub x12, x11, x4   // src_a (prev) = src - 
sao_edge_pos
+add x13, x11, x4   // src_b (next) = src + 
sao_edge_pos
+2:  // process 16 bytes
+ld1 {v3.16b}, [x11], #16   // load src
+ld1 {v4.16b}, [x12], #16   // load src_a (prev)
+ld1 {v5.16b}, [x13], #16   // load src_b (next)
+cmhiv16.16b, v4.16b, v3.16b// (prev > cur)
+cmhiv17.16b, v3.16b, v4.16b// (cur > prev)
+cmhiv18.16b, v5.16b, v3.16b// (next > cur)
+cmhiv19.16b, v3.16b, v5.16b// (cur > next)
+sub v20.16b, v16.16b, v17.16b  // diff0 = CMP(cur, prev) = 
(cur > prev) - (cur < prev)
+sub v21.16b, v18.16b, v19.16b  // diff1 = CMP(cur, next) = 
(cur > next) - (cur < next)
+add v20.16b, v20.16b, v21.16b  // diff = diff0 + diff1
+add v20.16b, v20.16b, v2.16b   // offset_val = diff + 2
+tbl v16.16b, {v0.16b}, v20.16b
+tbl v17.16b, {v1.16b}, v20.16b
+uxtlv20.8h, v3.8b  // src[0:7]
+uxtl2  

[FFmpeg-devel] [PATCH v3 4/6] lavc/aarch64: add hevc sao edge 8x8

[J. Dekker]

bench on AWS Graviton:

hevc_sao_edge_8x8_8_c: 516.0
hevc_sao_edge_8x8_8_neon: 81.0

Signed-off-by: J. Dekker 
---
 libavcodec/aarch64/hevcdsp_init_aarch64.c |  3 ++
 libavcodec/aarch64/hevcdsp_sao_neon.S | 51 +++
 2 files changed, 54 insertions(+)

diff --git a/libavcodec/aarch64/hevcdsp_init_aarch64.c 
b/libavcodec/aarch64/hevcdsp_init_aarch64.c
index 747ff0412d..b93cec9e44 100644
--- a/libavcodec/aarch64/hevcdsp_init_aarch64.c
+++ b/libavcodec/aarch64/hevcdsp_init_aarch64.c
@@ -59,6 +59,8 @@ void ff_hevc_sao_band_filter_8x8_8_neon(uint8_t *_dst, 
uint8_t *_src,
   int width, int height);
 void ff_hevc_sao_edge_filter_16x16_8_neon(uint8_t *dst, uint8_t *src, 
ptrdiff_t stride_dst,
   int16_t *sao_offset_val, int eo, int 
width, int height);
+void ff_hevc_sao_edge_filter_8x8_8_neon(uint8_t *dst, uint8_t *src, ptrdiff_t 
stride_dst,
+  int16_t *sao_offset_val, int eo, int 
width, int height);
 
 av_cold void ff_hevc_dsp_init_aarch64(HEVCDSPContext *c, const int bit_depth)
 {
@@ -76,6 +78,7 @@ av_cold void ff_hevc_dsp_init_aarch64(HEVCDSPContext *c, 
const int bit_depth)
 c->idct_dc[2]  = ff_hevc_idct_16x16_dc_8_neon;
 c->idct_dc[3]  = ff_hevc_idct_32x32_dc_8_neon;
 c->sao_band_filter[0]  = ff_hevc_sao_band_filter_8x8_8_neon;
+c->sao_edge_filter[0]  = ff_hevc_sao_edge_filter_8x8_8_neon;
 c->sao_edge_filter[1]  =
 c->sao_edge_filter[2]  =
 c->sao_edge_filter[3]  =
diff --git a/libavcodec/aarch64/hevcdsp_sao_neon.S 
b/libavcodec/aarch64/hevcdsp_sao_neon.S
index 4b895959d8..167b9676d8 100644
--- a/libavcodec/aarch64/hevcdsp_sao_neon.S
+++ b/libavcodec/aarch64/hevcdsp_sao_neon.S
@@ -150,3 +150,54 @@ function ff_hevc_sao_edge_filter_16x16_8_neon, export=1
 // no lines to filter
 ret
 endfunc
+
+// ff_hevc_sao_edge_filter_8x8_8_neon(char *dst, char *src, ptrdiff stride_dst,
+//int16 *sao_offset_val, int eo, int 
width, int height)
+function ff_hevc_sao_edge_filter_8x8_8_neon, export=1
+adr x7, .Lsao_edge_pos
+ldr w4, [x7, w4, uxtw #2]
+ld1 {v3.8h}, [x3]
+mov v3.h[7], v3.h[0]
+mov v3.h[0], v3.h[1]
+mov v3.h[1], v3.h[2]
+mov v3.h[2], v3.h[7]
+uzp2v1.16b, v3.16b, v3.16b
+uzp1v0.16b, v3.16b, v3.16b
+moviv2.16b, #2
+add x16, x0, x2
+lsl x2,  x2, #1
+mov x15, #192
+mov x8,  x1
+sub x9,  x1, x4
+add x10, x1, x4
+mov x17, #4
+1:  ld1 {v3.d}[0], [ x8], x15
+ld1 {v4.d}[0], [ x9], x15
+ld1 {v5.d}[0], [x10], x15
+ld1 {v3.d}[1], [ x8], x15
+ld1 {v4.d}[1], [ x9], x15
+ld1 {v5.d}[1], [x10], x15
+cmhiv16.16b, v4.16b, v3.16b
+cmhiv17.16b, v3.16b, v4.16b
+cmhiv18.16b, v5.16b, v3.16b
+cmhiv19.16b, v3.16b, v5.16b
+sub v20.16b, v16.16b, v17.16b
+sub v21.16b, v18.16b, v19.16b
+add v20.16b, v20.16b, v21.16b
+add v20.16b, v20.16b, v2.16b
+tbl v16.16b, {v0.16b}, v20.16b
+tbl v17.16b, {v1.16b}, v20.16b
+uxtlv20.8h, v3.8b
+uxtl2   v21.8h, v3.16b
+zip1v18.16b, v16.16b, v17.16b
+zip2v19.16b, v16.16b, v17.16b
+sqadd   v20.8h, v18.8h, v20.8h
+sqadd   v21.8h, v19.8h, v21.8h
+sqxtun  v6.8b, v20.8h
+sqxtun  v7.8b, v21.8h
+st1 {v6.8b}, [ x0], x2
+st1 {v7.8b}, [x16], x2
+subsx17, x17, #1
+b.ne1b
+ret
+endfunc
-- 
2.32.0 (Apple Git-132)

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

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

[FFmpeg-devel] [PATCH v3 5/6] lavc/aarch64: clean-up sao band 8x8 function formatting

[J. Dekker]

Signed-off-by: J. Dekker 
---
 libavcodec/aarch64/hevcdsp_sao_neon.S | 65 +++
 1 file changed, 25 insertions(+), 40 deletions(-)

diff --git a/libavcodec/aarch64/hevcdsp_sao_neon.S 
b/libavcodec/aarch64/hevcdsp_sao_neon.S
index 167b9676d8..73b0b3b056 100644
--- a/libavcodec/aarch64/hevcdsp_sao_neon.S
+++ b/libavcodec/aarch64/hevcdsp_sao_neon.S
@@ -30,24 +30,21 @@
 //  int width, int height)
 function ff_hevc_sao_band_filter_8x8_8_neon, export=1
 sub sp,  sp, #64
-stpxzr, xzr, [sp]
-stpxzr, xzr, [sp, #16]
-stpxzr, xzr, [sp, #32]
-stpxzr, xzr, [sp, #48]
+stp xzr, xzr, [sp]
+stp xzr, xzr, [sp, #16]
+stp xzr, xzr, [sp, #32]
+stp xzr, xzr, [sp, #48]
 mov w8,  #4
-0:
-ldrsh   x9, [x4,  x8, lsl #1] // x9 = sao_offset_val[k+1]
+0:  ldrsh   x9, [x4,  x8, lsl #1]  // sao_offset_val[k+1]
 subsw8,  w8,  #1
-addw10,  w8,  w5 // x10 = k + sao_left_class
-andw10, w10, #0x1F
+add w10, w8,  w5   // k + sao_left_class
+and w10, w10, #0x1F
 strhw9, [sp, x10, lsl #1]
 bne 0b
-ld1{v16.16b-v19.16b}, [sp], #64
-movi   v20.8h,   #1
-1:  // beginning of line
-mov w8,  w6
-2:
-// Simple layout for accessing 16bit values
+ld1 {v16.16b-v19.16b}, [sp], #64
+moviv20.8h,   #1
+1:  mov w8,  w6// beginning of line
+2:  // Simple layout for accessing 16bit values
 // with 8bit LUT.
 //
 //   00  01  02  03  04  05  06  07
@@ -55,33 +52,21 @@ function ff_hevc_sao_band_filter_8x8_8_neon, export=1
 // |xDE#xAD|xCA#xFE|xBE#xEF|xFE#xED|
 // +--->
 //i-0 i-1 i-2 i-3
-// dst[x] = av_clip_pixel(src[x] + offset_table[src[x] >> shift]);
-ld1{v2.8b}, [x1]
-// load src[x]
-uxtlv0.8h,  v2.8b
-// >> shift
-ushrv2.8h,  v0.8h, #3 // BIT_DEPTH - 3
-// x2 (access lower short)
-shl v1.8h,  v2.8h, #1 // low (x2, accessing short)
-// +1 access upper short
-add v3.8h,  v1.8h, v20.8h
-// shift insert index to upper byte
-sli v1.8h,  v3.8h, #8
-// table
-tbxv2.16b, {v16.16b-v19.16b}, v1.16b
-// src[x] + table
-add v1.8h,  v0.8h, v2.8h
-// clip + narrow
-sqxtun  v4.8b,  v1.8h
-// store
-st1{v4.8b}, [x0]
-// done 8 pixels
-subsw8, w8,  #8
+ld1 {v2.8b}, [x1]  // dst[x] = 
av_clip_pixel(src[x] + offset_table[src[x] >> shift]);
+uxtlv0.8h,  v2.8b  // load src[x]
+ushrv2.8h,  v0.8h, #3  // >> BIT_DEPTH - 3
+shl v1.8h,  v2.8h, #1  // low (x2, accessing short)
+add v3.8h,  v1.8h, v20.8h  // +1 access upper short
+sli v1.8h,  v3.8h, #8  // shift insert index to 
upper byte
+tbx v2.16b, {v16.16b-v19.16b}, v1.16b // table
+add v1.8h,  v0.8h, v2.8h   // src[x] + table
+sqxtun  v4.8b,  v1.8h  // clip + narrow
+st1 {v4.8b}, [x0]  // store
+subsw8, w8,  #8// done 8 pixels
 bne 2b
-// finished line
-subsw7, w7,  #1
-add x0, x0,  x2 // dst += stride_dst
-add x1, x1,  x3 // src += stride_src
+subsw7, w7,  #1// finished line, prep. new
+add x0, x0,  x2// dst += stride_dst
+add x1, x1,  x3// src += stride_src
 bne 1b
 ret
 endfunc
-- 
2.32.0 (Apple Git-132)

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

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

[FFmpeg-devel] [PATCH v3 6/6] lavc/aarch64: add hevc sao band 8x8 tiling

[J. Dekker]

--bench on AWS Graviton:

hevc_sao_band_8x8_8_c: 317.5
hevc_sao_band_8x8_8_neon: 97.5
hevc_sao_band_16x16_8_c: 1115.0
hevc_sao_band_16x16_8_neon: 322.7
hevc_sao_band_32x32_8_c: 4599.2
hevc_sao_band_32x32_8_neon: 1246.2
hevc_sao_band_48x48_8_c: 10021.7
hevc_sao_band_48x48_8_neon: 2740.5
hevc_sao_band_64x64_8_c: 17635.0
hevc_sao_band_64x64_8_neon: 4875.7

Signed-off-by: J. Dekker 
---
 libavcodec/aarch64/hevcdsp_init_aarch64.c |  6 +-
 libavcodec/aarch64/hevcdsp_sao_neon.S | 11 +++
 2 files changed, 12 insertions(+), 5 deletions(-)

diff --git a/libavcodec/aarch64/hevcdsp_init_aarch64.c 
b/libavcodec/aarch64/hevcdsp_init_aarch64.c
index b93cec9e44..2002530266 100644
--- a/libavcodec/aarch64/hevcdsp_init_aarch64.c
+++ b/libavcodec/aarch64/hevcdsp_init_aarch64.c
@@ -77,7 +77,11 @@ av_cold void ff_hevc_dsp_init_aarch64(HEVCDSPContext *c, 
const int bit_depth)
 c->idct_dc[1]  = ff_hevc_idct_8x8_dc_8_neon;
 c->idct_dc[2]  = ff_hevc_idct_16x16_dc_8_neon;
 c->idct_dc[3]  = ff_hevc_idct_32x32_dc_8_neon;
-c->sao_band_filter[0]  = ff_hevc_sao_band_filter_8x8_8_neon;
+c->sao_band_filter[0]  =
+c->sao_band_filter[1]  =
+c->sao_band_filter[2]  =
+c->sao_band_filter[3]  =
+c->sao_band_filter[4]  = ff_hevc_sao_band_filter_8x8_8_neon;
 c->sao_edge_filter[0]  = ff_hevc_sao_edge_filter_8x8_8_neon;
 c->sao_edge_filter[1]  =
 c->sao_edge_filter[2]  =
diff --git a/libavcodec/aarch64/hevcdsp_sao_neon.S 
b/libavcodec/aarch64/hevcdsp_sao_neon.S
index 73b0b3b056..d524323fe8 100644
--- a/libavcodec/aarch64/hevcdsp_sao_neon.S
+++ b/libavcodec/aarch64/hevcdsp_sao_neon.S
@@ -3,7 +3,7 @@
  *
  * AArch64 NEON optimised SAO functions for HEVC decoding
  *
- * Copyright (c) 2020 Josh Dekker 
+ * Copyright (c) 2020-2021  J. Dekker 
  *
  * This file is part of FFmpeg.
  *
@@ -35,6 +35,7 @@ function ff_hevc_sao_band_filter_8x8_8_neon, export=1
 stp xzr, xzr, [sp, #32]
 stp xzr, xzr, [sp, #48]
 mov w8,  #4
+sxtwx6,  w6
 0:  ldrsh   x9, [x4,  x8, lsl #1]  // sao_offset_val[k+1]
 subsw8,  w8,  #1
 add w10, w8,  w5   // k + sao_left_class
@@ -43,7 +44,9 @@ function ff_hevc_sao_band_filter_8x8_8_neon, export=1
 bne 0b
 ld1 {v16.16b-v19.16b}, [sp], #64
 moviv20.8h,   #1
-1:  mov w8,  w6// beginning of line
+sub x2,  x2, x6// stride_dst - width
+sub x3,  x3, x6// stride_src - width
+1:  mov x8,  x6// beginning of line
 2:  // Simple layout for accessing 16bit values
 // with 8bit LUT.
 //
@@ -52,7 +55,7 @@ function ff_hevc_sao_band_filter_8x8_8_neon, export=1
 // |xDE#xAD|xCA#xFE|xBE#xEF|xFE#xED|
 // +--->
 //i-0 i-1 i-2 i-3
-ld1 {v2.8b}, [x1]  // dst[x] = 
av_clip_pixel(src[x] + offset_table[src[x] >> shift]);
+ld1 {v2.8b}, [x1], #8  // dst[x] = 
av_clip_pixel(src[x] + offset_table[src[x] >> shift]);
 uxtlv0.8h,  v2.8b  // load src[x]
 ushrv2.8h,  v0.8h, #3  // >> BIT_DEPTH - 3
 shl v1.8h,  v2.8h, #1  // low (x2, accessing short)
@@ -61,7 +64,7 @@ function ff_hevc_sao_band_filter_8x8_8_neon, export=1
 tbx v2.16b, {v16.16b-v19.16b}, v1.16b // table
 add v1.8h,  v0.8h, v2.8h   // src[x] + table
 sqxtun  v4.8b,  v1.8h  // clip + narrow
-st1 {v4.8b}, [x0]  // store
+st1 {v4.8b}, [x0], #8  // store
 subsw8, w8,  #8// done 8 pixels
 bne 2b
 subsw7, w7,  #1// finished line, prep. new
-- 
2.32.0 (Apple Git-132)

___
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 CPL parsing error handling

[pal]

From: Pierre-Anthony Lemieux 

Signed-off-by: Pierre-Anthony Lemieux 
---
 libavformat/imf_cpl.c | 51 +++
 1 file changed, 27 insertions(+), 24 deletions(-)

diff --git a/libavformat/imf_cpl.c b/libavformat/imf_cpl.c
index 167244a5a2..72fc7ffec8 100644
--- a/libavformat/imf_cpl.c
+++ b/libavformat/imf_cpl.c
@@ -807,34 +807,37 @@ int ff_imf_parse_cpl(AVIOContext *in, FFIMFCPL **cpl)
 av_log(NULL, AV_LOG_ERROR, "Cannot read IMF CPL\n");
 if (ret == 0)
 ret = AVERROR_INVALIDDATA;
-} else {
-LIBXML_TEST_VERSION
-
-filesize = buf.len;
-doc = xmlReadMemory(buf.str, filesize, NULL, NULL, 0);
-if (!doc) {
-av_log(NULL,
-   AV_LOG_ERROR,
-   "XML parsing failed when reading the IMF CPL\n");
-ret = AVERROR_INVALIDDATA;
-}
+goto clean_up;
+}
 
-if ((ret = ff_imf_parse_cpl_from_xml_dom(doc, cpl))) {
-av_log(NULL, AV_LOG_ERROR, "Cannot parse IMF CPL\n");
-} else {
-av_log(NULL,
-   AV_LOG_INFO,
-   "IMF CPL ContentTitle: %s\n",
-   (*cpl)->content_title_utf8);
-av_log(NULL,
-   AV_LOG_INFO,
-   "IMF CPL Id: " FF_IMF_UUID_FORMAT "\n",
-   UID_ARG((*cpl)->id_uuid));
-}
+LIBXML_TEST_VERSION
 
-xmlFreeDoc(doc);
+filesize = buf.len;
+doc = xmlReadMemory(buf.str, filesize, NULL, NULL, 0);
+if (!doc) {
+av_log(NULL,
+AV_LOG_ERROR,
+"XML parsing failed when reading the IMF CPL\n");
+ret = AVERROR_INVALIDDATA;
+goto clean_up;
 }
 
+if ((ret = ff_imf_parse_cpl_from_xml_dom(doc, cpl))) {
+av_log(NULL, AV_LOG_ERROR, "Cannot parse IMF CPL\n");
+} else {
+av_log(NULL,
+AV_LOG_INFO,
+"IMF CPL ContentTitle: %s\n",
+(*cpl)->content_title_utf8);
+av_log(NULL,
+AV_LOG_INFO,
+"IMF CPL Id: " FF_IMF_UUID_FORMAT "\n",
+UID_ARG((*cpl)->id_uuid));
+}
+
+xmlFreeDoc(doc);
+
+clean_up:
 av_bprint_finalize(&buf, NULL);
 
 return ret;
-- 
2.17.1

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

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

[FFmpeg-devel] [PATCH v1] avformat/imf: fix error CPL root element is absent

[pal]

From: Pierre-Anthony Lemieux 

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

Notes:
Found through manual fuzzing.

 libavformat/imf_cpl.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/libavformat/imf_cpl.c b/libavformat/imf_cpl.c
index 7055b49ae8..167244a5a2 100644
--- a/libavformat/imf_cpl.c
+++ b/libavformat/imf_cpl.c
@@ -688,7 +688,7 @@ int ff_imf_parse_cpl_from_xml_dom(xmlDocPtr doc, FFIMFCPL 
**cpl)
 }
 
 cpl_element = xmlDocGetRootElement(doc);
-if (xmlStrcmp(cpl_element->name, "CompositionPlaylist")) {
+if ((!cpl_element) || xmlStrcmp(cpl_element->name, "CompositionPlaylist")) 
{
 av_log(NULL, AV_LOG_ERROR, "The root element of the CPL is not 
CompositionPlaylist\n");
 ret = AVERROR_INVALIDDATA;
 goto cleanup;
-- 
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] [EXT] Re: [PATCH v4 1/3] avcodec/v4l2_context: don't reinit output queue when dynamic resolution change

[Ming Qian]

> -Original Message-
> From: Andriy Gelman [mailto:andriy.gel...@gmail.com]
> Sent: Monday, January 3, 2022 12:24 AM
> To: FFmpeg development discussions and patches 
> Cc: Ming Qian 
> Subject: [EXT] Re: [FFmpeg-devel] [PATCH v4 1/3] avcodec/v4l2_context: don't
> reinit output queue when dynamic resolution change
> 
> Caution: EXT Email
> 
> 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.

Hi Andriy,
  I think we can just keep it, if you really need to remove it, I think we can 
submit a single patch that remove it.

> 
> > -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] [EXT] Re: [PATCH v4 2/3] avcodec/v4l2_context: resume the decoding process after source change event received.

[Ming Qian]

> -Original Message-
> From: Andriy Gelman [mailto:andriy.gel...@gmail.com]
> Sent: Monday, January 3, 2022 12:41 AM
> To: FFmpeg development discussions and patches 
> Cc: Ming Qian 
> Subject: [EXT] Re: [FFmpeg-devel] [PATCH v4 2/3] avcodec/v4l2_context:
> resume the decoding process after source change event received.
> 
> Caution: EXT Email
> 
> 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://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fstreams
> .videolan.org%2Fffmpeg%2Fincoming%2F720p60.mp4&data=04%7C01%
> 7Cming.qian%40nxp.com%7Cea94a9c4cc0643b0a41f08d9ce0eadc5%7C686e
> a1d3bc2b4c6fa92cd99c5c301635%7C0%7C1%7C637767384703207931%7CU
> nknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6
> Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=X4rKQX19MQg1gO3ILiBCQ
> qSLIvqovZLA95KKiyoVNzI%3D&reserved=0 on RPi4.
> 

Hi Andriy,
What's wrong with this stream? Everything is normal on my side when I play 
it using ffplay.

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

OK, I'll split it into two parts.

> >
> > -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_cod