date:20200515

Re: [FFmpeg-devel] [PATCH] avformat/mpegts: Check the next sync byte to avoid incorrectt detected raw packet size

2020-05-15 Thread lance . lmwang

On Fri, May 15, 2020 at 06:52:55PM +0200, Marton Balint wrote:
> 
> 
> On Fri, 15 May 2020, lance.lmw...@gmail.com wrote:
> 
> > On Fri, May 15, 2020 at 08:02:44PM +0800, myp...@gmail.com wrote:
> > > On Fri, May 15, 2020 at 6:23 PM  wrote:
> > > >
> > > > From: Limin Wang 
> > > >
> > > > reanalyze() may misdetect the new packet size as 204, but it's 188 
> > > > still actualy,
> > > > it'll cause many cc errors report and cannot be recovered. So it's 
> > > > better to check
> > > > the next sync byte before skip the extra unused bytes.
> > > >
> > > > Also, it is best to change SIZE_STAT_THRESHOLD from 10 to 100? If the 
> > > > input stream has
> > > > a master/slave switch serveral times, the raw size can be easily 
> > > > detected by mistake.
> > > >
> > > > Signed-off-by: Limin Wang 
> > > > ---
> > > >  libavformat/mpegts.c | 13 +++--
> > > >  1 file changed, 7 insertions(+), 6 deletions(-)
> > > >
> > > > diff --git a/libavformat/mpegts.c b/libavformat/mpegts.c
> > > > index 0833d62..049555c 100644
> > > > --- a/libavformat/mpegts.c
> > > > +++ b/libavformat/mpegts.c
> > > > @@ -2932,11 +2932,12 @@ static int read_packet(AVFormatContext *s, 
> > > > uint8_t *buf, int raw_packet_size,
> > > >  return 0;
> > > >  }
> > > >
> > > > -static void finished_reading_packet(AVFormatContext *s, int 
> > > > raw_packet_size)
> > > > +static void finished_reading_packet(AVFormatContext *s, const uint8_t 
> > > > *data, int raw_packet_size)
> > > >  {
> > > >  AVIOContext *pb = s->pb;
> > > >  int skip = raw_packet_size - TS_PACKET_SIZE;
> > > > -if (skip > 0)
> > > > +/* Check the next sync byte to avoid incorrectt detected raw 
> > > > packet size */
> > > > +if (skip > 0 && data[TS_PACKET_SIZE] != 0x47)
> > > >  avio_skip(pb, skip);
> > > >  }
> > > >
> > > > @@ -2985,7 +2986,7 @@ static int handle_packets(MpegTSContext *ts, 
> > > > int64_t nb_packets)
> > > >  if (ret != 0)
> > > >  break;
> > > >  ret = handle_packet(ts, data, avio_tell(s->pb));
> > > > -finished_reading_packet(s, ts->raw_packet_size);
> > > > +finished_reading_packet(s, data, ts->raw_packet_size);
> > > >  if (ret != 0)
> > > >  break;
> > > >  }
> > > > @@ -3137,7 +3138,7 @@ static int mpegts_read_header(AVFormatContext *s)
> > > >  pid = AV_RB16(data + 1) & 0x1fff;
> > > >  if ((pcr_pid == -1 || pcr_pid == pid) &&
> > > >  parse_pcr(&pcr_h, &pcr_l, data) == 0) {
> > > > -finished_reading_packet(s, ts->raw_packet_size);
> > > > +finished_reading_packet(s, data, ts->raw_packet_size);
> > > >  pcr_pid = pid;
> > > >  packet_count[nb_pcrs] = nb_packets;
> > > >  pcrs[nb_pcrs] = pcr_h * 300 + pcr_l;
> > > > @@ -3154,7 +3155,7 @@ static int mpegts_read_header(AVFormatContext *s)
> > > >  }
> > > >  }
> > > >  } else {
> > > > -finished_reading_packet(s, ts->raw_packet_size);
> > > > +finished_reading_packet(s, data, ts->raw_packet_size);
> > > >  }
> > > >  nb_packets++;
> > > >  }
> > > > @@ -3194,7 +3195,7 @@ static int mpegts_raw_read_packet(AVFormatContext 
> > > > *s, AVPacket *pkt)
> > > >  }
> > > >  if (data != pkt->data)
> > > >  memcpy(pkt->data, data, ts->raw_packet_size);
> > > > -finished_reading_packet(s, ts->raw_packet_size);
> > > > +finished_reading_packet(s, data, ts->raw_packet_size);
> > > >  if (ts->mpeg2ts_compute_pcr) {
> > > >  /* compute exact PCR for each packet */
> > > >  if (parse_pcr(&pcr_h, &pcr_l, pkt->data) == 0) {
> > > > --
> > > > 1.8.3.1
> > > >
> > > Do you have a case to reproduce the cc errors report?
> > 
> > Yes, it's real case which can be reproduced in lab.
> 
> Can you share the sample?

No, tested with master and slave udp ts stream which switch between the master 
and slave stream
more than five times, it'll cause tons of cc error report and can't be 
recovered.

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

-- 
Thanks,
Limin Wang
___
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/hlsenc: Don't segfault on uncommon names

2020-05-15 Thread Andreas Rheinhardt

Andreas Rheinhardt:
> The parsing process of the AVOpt-enabled string controlling the mapping
> of input streams to variant streams is roughly as follows: Space and tab
> separate variant stream group maps while the entries in each variant
> stream group map are separated by ','.
> 
> The parsing process of each variant stream group proceeded as follows:
> At first the number of occurences of "a:", "v:" and "s:" in each variant
> stream group is calculated so that one can can allocate an array of
> streams with this number of entries. Then the string is split along ','
> and each substring is parsed. If such a substring starts with "a:", "s:"
> or "v:" it is treated as stream specifier and (if there is a correct
> number after ':') a stream of the variant stream is mapped to one of the
> actual input streams.
> 
> Nothing actually guarantees that the number of streams allocated initially
> equals the number of streams that are mapped to an actual input stream.
> These numbers can differ if e.g. the name, the sgroup, agroup or ccgroup
> of the variant stream contain "a:", "s:" or "v:".
> 
> The problem hereby is that the rest of the code presumes these numbers
> to be equal and segfaults if it isn't (because the corresponding input
> stream is NULL).
> 
> This commit fixes this by modifying the initial counting process to only
> count occurences of "a:", "s:" or "v:" that are at the beginning or that
> immediately follow a ','.
> 
> Signed-off-by: Andreas Rheinhardt 
> ---
> Alternatively, one could error out if these two counts differed (in
> which case one can conclude that one of the other values must have
> contained "a:", "s:" or "v:"). I have not done so, because using these
> doesn't seem to be forbidden at all and there might even be usecases
> (think of "name:The_Lord_of_the_Rings:_The_Two_Towers" or "Avengers:").
> 
> Furthermore modifying the check has the advantage of not allocating to
> much and it also allows to introduce keys that end with 'a', 's' or 'v'.
> 
>  libavformat/hlsenc.c | 5 -
>  1 file changed, 4 insertions(+), 1 deletion(-)
> 
> diff --git a/libavformat/hlsenc.c b/libavformat/hlsenc.c
> index 5695c6cc95..a381ca3e9e 100644
> --- a/libavformat/hlsenc.c
> +++ b/libavformat/hlsenc.c
> @@ -1951,10 +1951,13 @@ static int 
> parse_variant_stream_mapstring(AVFormatContext *s)
>  return AVERROR(EINVAL);
>  
>  q = varstr;
> -while (q < varstr + strlen(varstr)) {
> +while (1) {
>  if (!av_strncasecmp(q, "a:", 2) || !av_strncasecmp(q, "v:", 2) ||
>  !av_strncasecmp(q, "s:", 2))
>  vs->nb_streams++;
> +q = strchr(q, ',');
> +if (!q)
> +break;
>  q++;
>  }
>  vs->streams = av_mallocz(sizeof(AVStream *) * vs->nb_streams);
> 
Will apply this tomorrow if there are no objections.

- 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 00/10] Vulkan code general/performance improvements

2020-05-15 Thread Lynne

Just posting this as a single email not to spam the ML too much.
Going to push this sometime over the weekend alongside the other 3 patches to 
finish
all work on Vulkan before the next release.
Satisfied with the code, though the last patch is slightly ugly.
Performance improvements out of async code: 78% on a toy GPU with 1 queue for 
an upload+scale
Probably closer to 200% on a discrete GPU with 4 transfer/compute queues.

>From cbf54e68dd253581515d76f930c7e7e8d77809b7 Mon Sep 17 00:00:00 2001
From: Lynne 
Date: Thu, 14 May 2020 00:37:21 +0100
Subject: [PATCH 10/10] lavfi/vulkan: use all enabled queues in the queue
 family

This should significantly improve the performance with certain
filterchains.
---
 libavfilter/vf_avgblur_vulkan.c   |  39 ++--
 libavfilter/vf_chromaber_vulkan.c |  30 +--
 libavfilter/vf_overlay_vulkan.c   |  37 ++--
 libavfilter/vf_scale_vulkan.c |  30 +--
 libavfilter/vulkan.c  | 296 +++---
 libavfilter/vulkan.h  |  74 ++--
 6 files changed, 371 insertions(+), 135 deletions(-)

diff --git a/libavfilter/vf_avgblur_vulkan.c b/libavfilter/vf_avgblur_vulkan.c
index 105d753f73..12d57e0875 100644
--- a/libavfilter/vf_avgblur_vulkan.c
+++ b/libavfilter/vf_avgblur_vulkan.c
@@ -97,6 +97,10 @@ static av_cold int init_filter(AVFilterContext *ctx, AVFrame *in)
 if (!sampler)
 return AVERROR_EXTERNAL;
 
+s->vkctx.queue_family_idx = s->vkctx.hwctx->queue_family_comp_index;
+s->vkctx.queue_count = GET_QUEUE_COUNT(s->vkctx.hwctx, 0, 1, 0);
+s->vkctx.cur_queue_idx = rand() % s->vkctx.queue_count;
+
 { /* Create shader for the horizontal pass */
 desc_i[0].updater = s->input_images;
 desc_i[1].updater = s->tmp_images;
@@ -184,8 +188,7 @@ static av_cold int init_filter(AVFilterContext *ctx, AVFrame *in)
 }
 
 /* Execution context */
-RET(ff_vk_create_exec_ctx(ctx, &s->exec,
-  s->vkctx.hwctx->queue_family_comp_index));
+RET(ff_vk_create_exec_ctx(ctx, &s->exec));
 
 s->initialized = 1;
 
@@ -198,22 +201,30 @@ fail:
 static int process_frames(AVFilterContext *avctx, AVFrame *out_f, AVFrame *tmp_f, AVFrame *in_f)
 {
 int err;
+VkCommandBuffer cmd_buf;
 AvgBlurVulkanContext *s = avctx->priv;
 AVVkFrame *in = (AVVkFrame *)in_f->data[0];
 AVVkFrame *tmp = (AVVkFrame *)tmp_f->data[0];
 AVVkFrame *out = (AVVkFrame *)out_f->data[0];
 int planes = av_pix_fmt_count_planes(s->vkctx.output_format);
 
+/* Update descriptors and init the exec context */
+ff_vk_start_exec_recording(avctx, s->exec);
+cmd_buf = ff_vk_get_exec_buf(avctx, s->exec);
+
 for (int i = 0; i < planes; i++) {
-RET(ff_vk_create_imageview(avctx, &s->input_images[i].imageView, in->img[i],
+RET(ff_vk_create_imageview(avctx, s->exec, &s->input_images[i].imageView,
+   in->img[i],
av_vkfmt_from_pixfmt(s->vkctx.input_format)[i],
ff_comp_identity_map));
 
-RET(ff_vk_create_imageview(avctx, &s->tmp_images[i].imageView, tmp->img[i],
+RET(ff_vk_create_imageview(avctx, s->exec, &s->tmp_images[i].imageView,
+   tmp->img[i],
av_vkfmt_from_pixfmt(s->vkctx.output_format)[i],
ff_comp_identity_map));
 
-RET(ff_vk_create_imageview(avctx, &s->output_images[i].imageView, out->img[i],
+RET(ff_vk_create_imageview(avctx, s->exec, &s->output_images[i].imageView,
+   out->img[i],
av_vkfmt_from_pixfmt(s->vkctx.output_format)[i],
ff_comp_identity_map));
 
@@ -225,8 +236,6 @@ static int process_frames(AVFilterContext *avctx, AVFrame *out_f, AVFrame *tmp_f
 ff_vk_update_descriptor_set(avctx, s->pl_hor, 0);
 ff_vk_update_descriptor_set(avctx, s->pl_ver, 0);
 
-ff_vk_start_exec_recording(avctx, s->exec);
-
 for (int i = 0; i < planes; i++) {
 VkImageMemoryBarrier bar[] = {
 {
@@ -270,7 +279,7 @@ static int process_frames(AVFilterContext *avctx, AVFrame *out_f, AVFrame *tmp_f
 },
 };
 
-vkCmdPipelineBarrier(s->exec->buf, VK_PIPELINE_STAGE_TOP_OF_PIPE_BIT,
+vkCmdPipelineBarrier(cmd_buf, VK_PIPELINE_STAGE_TOP_OF_PIPE_BIT,
  VK_PIPELINE_STAGE_COMPUTE_SHADER_BIT, 0,
  0, NULL, 0, NULL, FF_ARRAY_ELEMS(bar), bar);
 
@@ -286,12 +295,12 @@ static int process_frames(AVFilterContext *avctx, AVFrame *out_f, AVFrame *tmp_f
 
 ff_vk_bind_pipeline_exec(avctx, s->exec, s->pl_hor);
 
-vkCmdDispatch(s->exec->buf, FFALIGN(s->vkctx.output_width, CGS)/CGS,
+vkCmdDispatch(cmd_buf, FFALIGN(s->vkctx.output_width, CGS)/CGS,
   s->vkctx.output_height, 1);
 
 ff_vk_bind_pipeline_exec(avctx, s->exec, s-

Re: [FFmpeg-devel] [PATCH 5/5] [mov] Don't allow negative sample sizes.

2020-05-15 Thread Michael Niedermayer

On Thu, May 14, 2020 at 03:31:55PM -0700, Dale Curtis wrote:
> Signed-off-by: Dale Curtis 
> ---
>  libavformat/mov.c | 4 
>  1 file changed, 4 insertions(+)

will apply

thx

[...]

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

The educated differ from the uneducated as much as the living from the
dead. -- Aristotle 

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

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

Re: [FFmpeg-devel] [PATCH] [libavutil] Add saturated add/sub operations for int64_t.

2020-05-15 Thread Michael Niedermayer

On Thu, May 14, 2020 at 12:46:56PM -0700, Dale Curtis wrote:
> On Thu, May 14, 2020 at 11:47 AM Michael Niedermayer 
> wrote:
> 
> > On Fri, May 01, 2020 at 11:42:43AM -0700, Dale Curtis wrote:
> > > On Fri, May 1, 2020 at 10:57 AM Carl Eugen Hoyos 
> > wrote:
> > >
> > > > Could you confirm that you attached the wrong patch?
> > > >
> > >
> > > No, I sent the patches without completing the rebase. Sorry.
> > >
> > > - dale
> >
> > >  common.h |   36 
> > >  1 file changed, 36 insertions(+)
> > > f5567ae046c0c2d4ac9053611457b9d9045b6ccb  sat_math_v4.patch
> > > From 06c20d84e3bf0f56bcba63ef8e74812e796f3ffe Mon Sep 17 00:00:00 2001
> > > From: Dale Curtis 
> > > Date: Thu, 30 Apr 2020 15:16:31 -0700
> > > Subject: [PATCH 1/2] Add saturated add/sub operations for int64_t.
> > >
> > > Many places are using their own custom code for handling overflow
> > > around timestamps or other int64_t values. There are enough of these
> > > now that having some common saturated math functions seems sound.
> > >
> > > Signed-off-by: Dale Curtis 
> > > ---
> > >  libavutil/common.h | 36 
> > >  1 file changed, 36 insertions(+)
> > >
> > > diff --git a/libavutil/common.h b/libavutil/common.h
> > > index 142ff9abe7..11907e5ba7 100644
> > > --- a/libavutil/common.h
> > > +++ b/libavutil/common.h
> > > @@ -291,6 +291,36 @@ static av_always_inline int av_sat_dsub32_c(int a,
> > int b)
> > >  return av_sat_sub32(a, av_sat_add32(b, b));
> > >  }
> > >
> > > +/**
> > > + * Add two signed 64-bit values with saturation.
> > > + *
> > > + * @param  a one value
> > > + * @param  b another value
> > > + * @return sum with signed saturation
> > > + */
> > > +static av_always_inline int64_t av_sat_add64_c(int64_t a, int64_t b) {
> > > +  if (b >= 0 && a >= INT64_MAX - b)
> > > +return INT64_MAX;
> > > +  if (b <= 0 && a <= INT64_MIN - b)
> > > +return INT64_MIN;
> > > +  return a + b;
> > > +}
> > > +
> > > +/**
> > > + * Subtract two signed 64-bit values with saturation.
> > > + *
> > > + * @param  a one value
> > > + * @param  b another value
> > > + * @return difference with signed saturation
> > > + */
> > > +static av_always_inline int64_t av_sat_sub64_c(int64_t a, int64_t b) {
> > > +  if (b <= 0 && a >= INT64_MAX + b) {
> > > +return INT64_MAX;
> > > +  if (b >= 0 && a <= INT64_MIN + b) {
> > > +return INT64_MIN;
> >
> > the { are not paired with }
> > this will not build
> >
> > indention level also does not match the rest of the code
> >
> >
> Fixed, sorry about that.
> 
> - dale

>  common.h |   36 
>  1 file changed, 36 insertions(+)
> 15c7cc73889c7f758aaf2dc341f192918cd2828c  sat_math_v5.patch
> From 4becb3c5f712db8b10f4b86b2c7a9f3e4eb27e98 Mon Sep 17 00:00:00 2001
> From: Dale Curtis 
> Date: Thu, 30 Apr 2020 15:16:31 -0700
> Subject: [PATCH 1/2] Add saturated add/sub operations for int64_t.
> 
> Many places are using their own custom code for handling overflow
> around timestamps or other int64_t values. There are enough of these
> now that having some common saturated math functions seems sound.
> 
> Signed-off-by: Dale Curtis 
> ---
>  libavutil/common.h | 36 
>  1 file changed, 36 insertions(+)

will apply

thx

[...]

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

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


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

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

Re: [FFmpeg-devel] [PATCH] [libavformat/mov.c] Read the QT Metadata Keys only once

2020-05-15 Thread Michael Niedermayer

On Fri, May 15, 2020 at 10:00:02AM -0700, Thierry Foucu wrote:
> On Thu, May 14, 2020 at 12:26 PM Derek Buitenhuis <
> derek.buitenh...@gmail.com> wrote:
> 
> > On 14/05/2020 18:19, Thierry Foucu wrote:
> > > Looking at
> > >
> > https://developer.apple.com/library/archive/documentation/QuickTime/QTFF/Metadata/Metadata.html
> > > The spec does not seem to say 1 or more. But because the `keys` atom is a
> > > list of indexes used by the `ilst` and the spec for `keys` said:
> > > Indexes into the metadata item keys atom are 1-based (1…entry_count).
> > >
> > > having 2+ `keys` atoms will conflict with this, as which one will be
> > index 1
> > >
> > > I'm assuming that only `keys` could only work.
> > > instead of skipping the consecutive `keys` atom, I could change the code
> > to
> > > free the keys and re-alloc it for each `keys` atom found. So you will get
> > > only the data from the last `keys` atom.
> > >
> > > so, it is either the 1st `keys` or the last `keys`. Up to you.
> >
> > LGTM as-is then.
> >
> 
> Thanks for the review, Derek.
> Any chance to have someone to submit it?

will apply

thx

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

The real ebay dictionary, page 1
"Used only once"- "Some unspecified defect prevented a second use"
"In good condition" - "Can be repaird by experienced expert"
"As is" - "You wouldnt want it even if you were payed for it, if you knew ..."


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

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

Re: [FFmpeg-devel] [PATCH v4 1/2] avcodec: add adpcm_ima_ssi encoder

2020-05-15 Thread Michael Niedermayer

On Fri, May 08, 2020 at 02:31:27PM +, Zane van Iperen wrote:
> Signed-off-by: Zane van Iperen 
> ---
>  Changelog  |  1 +
>  doc/general.texi   |  2 +-
>  libavcodec/Makefile|  1 +
>  libavcodec/adpcmenc.c  | 65 +++---
>  libavcodec/allcodecs.c |  1 +
>  libavcodec/utils.c |  1 +
>  libavcodec/version.h   |  2 +-
>  7 files changed, 55 insertions(+), 18 deletions(-)
> 
> diff --git a/Changelog b/Changelog
> index b75d2b6b96..002fccb5cf 100644
> --- a/Changelog
> +++ b/Changelog
> @@ -66,6 +66,7 @@ version :
>  - asubboost filter
>  - Pro Pinball Series Soundbank demuxer
>  - pcm_rechunk bitstream filter
> +- Simon & Schuster Interactive ADPCM encoder
>  
>  
>  version 4.2:
> diff --git a/doc/general.texi b/doc/general.texi
> index 4aaf506e56..9b0ee96752 100644
> --- a/doc/general.texi
> +++ b/doc/general.texi
> @@ -1108,7 +1108,7 @@ following image formats are supported:
>  @item ADPCM IMA Funcom   @tab @tab  X
>  @item ADPCM IMA High Voltage Software ALP   @tab @tab  X
>  @item ADPCM IMA QuickTime@tab  X  @tab  X
> -@item ADPCM IMA Simon & Schuster Interactive   @tab  @tab  X
> +@item ADPCM IMA Simon & Schuster Interactive   @tab  X  @tab  X
>  @item ADPCM IMA Ubisoft APM  @tab @tab X
>  @item ADPCM IMA Loki SDL MJPEG  @tab @tab  X
>  @item ADPCM IMA WAV  @tab  X  @tab  X
> diff --git a/libavcodec/Makefile b/libavcodec/Makefile
> index 38f6f07680..2fab8dc40b 100644
> --- a/libavcodec/Makefile
> +++ b/libavcodec/Makefile
> @@ -856,6 +856,7 @@ OBJS-$(CONFIG_ADPCM_IMA_QT_DECODER)   += adpcm.o 
> adpcm_data.o
>  OBJS-$(CONFIG_ADPCM_IMA_QT_ENCODER)   += adpcmenc.o adpcm_data.o
>  OBJS-$(CONFIG_ADPCM_IMA_RAD_DECODER)  += adpcm.o adpcm_data.o
>  OBJS-$(CONFIG_ADPCM_IMA_SSI_DECODER)  += adpcm.o adpcm_data.o
> +OBJS-$(CONFIG_ADPCM_IMA_SSI_ENCODER)  += adpcmenc.o adpcm_data.o
>  OBJS-$(CONFIG_ADPCM_IMA_SMJPEG_DECODER)   += adpcm.o adpcm_data.o
>  OBJS-$(CONFIG_ADPCM_IMA_WAV_DECODER)  += adpcm.o adpcm_data.o
>  OBJS-$(CONFIG_ADPCM_IMA_WAV_ENCODER)  += adpcmenc.o adpcm_data.o
> diff --git a/libavcodec/adpcmenc.c b/libavcodec/adpcmenc.c
> index 668939c778..d1194c1f8f 100644
> --- a/libavcodec/adpcmenc.c
> +++ b/libavcodec/adpcmenc.c
> @@ -77,6 +77,15 @@ static av_cold int adpcm_encode_init(AVCodecContext *avctx)
>  return AVERROR(EINVAL);
>  }
>  
> +if (avctx->trellis && avctx->codec->id == AV_CODEC_ID_ADPCM_IMA_SSI) {
> +/*
> + * The current trellis implementation doesn't work for extended
> + * runs of samples without periodic resets. Disallow it.
> + */
> +av_log(avctx, AV_LOG_ERROR, "trellis not supported\n");

> +return AVERROR(EINVAL);

AVERROR_PATCHWELCOME

[...]
> @@ -706,21 +737,23 @@ static const enum AVSampleFormat sample_fmts_p[] = {
>  AV_SAMPLE_FMT_S16P, AV_SAMPLE_FMT_NONE
>  };
>  
> -#define ADPCM_ENCODER(id_, name_, sample_fmts_, long_name_) \
> -AVCodec ff_ ## name_ ## _encoder = {\
> -.name   = #name_,   \
> -.long_name  = NULL_IF_CONFIG_SMALL(long_name_), \
> -.type   = AVMEDIA_TYPE_AUDIO,   \
> -.id = id_,  \
> -.priv_data_size = sizeof(ADPCMEncodeContext),   \
> -.init   = adpcm_encode_init,\
> -.encode2= adpcm_encode_frame,   \
> -.close  = adpcm_encode_close,   \
> -.sample_fmts= sample_fmts_, \
> +#define ADPCM_ENCODER(id_, name_, sample_fmts_, capabilities_, long_name_) \
> +AVCodec ff_ ## name_ ## _encoder = {   \
> +.name   = #name_,  \
> +.long_name  = NULL_IF_CONFIG_SMALL(long_name_),\
> +.type   = AVMEDIA_TYPE_AUDIO,  \
> +.id = id_, \
> +.priv_data_size = sizeof(ADPCMEncodeContext),  \
> +.init   = adpcm_encode_init,   \
> +.encode2= adpcm_encode_frame,  \
> +.close  = adpcm_encode_close,  \
> +.sample_fmts= sample_fmts_,\
> +.capabilities   = capabilities_,   \
>  }
>  
> -ADPCM_ENCODER(AV_CODEC_ID_ADPCM_IMA_QT,  adpcm_ima_qt,  sample_fmts_p, 
> "ADPCM IMA QuickTime");
> -ADPCM_ENCODER(AV_CODEC_ID_ADPCM_IMA_WAV, adpcm_ima_wav, sample_fmts_p, 
> "ADPCM IMA WAV");
> -ADPCM_ENCODER(AV_CODEC_ID_ADPCM_MS,  adpcm_ms,  sample_fmts,   
> "ADPCM Microsoft");
> -ADPCM_ENCODER(AV_CODEC_ID_ADPCM_SWF, adpcm_swf, sample_fmts,   
> "ADPCM Shockwave

Re: [FFmpeg-devel] [PATCH v2 2/2] swscale: aarch64: Add a NEON implementation of interleaveBytes

2020-05-15 Thread Josh de Kock


On 15/05/2020 19:11, Martin Storsjö wrote:

This allows speeding up format conversions from yuv420 to nv12.

  Cortex A53  A72  A73
interleave_bytes_c: 86077.5  51433.0  66972.0
interleave_bytes_neon:  19701.7  23019.2  15859.2
interleave_bytes_aligned_c: 86603.0  52017.2  67484.2
interleave_bytes_aligned_neon:   9061.0   7623.0   6309.0
---
v2: Made the stride handling signed, to properly handle negative strides,
fixing filter-pixfmts-vflip.
---
  libswscale/aarch64/Makefile   |  4 +-
  libswscale/aarch64/rgb2rgb.c  | 41 
  libswscale/aarch64/rgb2rgb_neon.S | 79 +++
  libswscale/rgb2rgb.c  |  2 +
  libswscale/rgb2rgb.h  |  1 +
  5 files changed, 126 insertions(+), 1 deletion(-)
  create mode 100644 libswscale/aarch64/rgb2rgb.c
  create mode 100644 libswscale/aarch64/rgb2rgb_neon.S

diff --git a/libswscale/aarch64/Makefile b/libswscale/aarch64/Makefile
index 64a3fe208d..da1d909561 100644
--- a/libswscale/aarch64/Makefile
+++ b/libswscale/aarch64/Makefile
@@ -1,6 +1,8 @@
-OBJS+= aarch64/swscale.o\
+OBJS+= aarch64/rgb2rgb.o\
+   aarch64/swscale.o\
 aarch64/swscale_unscaled.o   \
  
  NEON-OBJS   += aarch64/hscale.o \

 aarch64/output.o \
+   aarch64/rgb2rgb_neon.o   \
 aarch64/yuv2rgb_neon.o   \
diff --git a/libswscale/aarch64/rgb2rgb.c b/libswscale/aarch64/rgb2rgb.c
new file mode 100644
index 00..a9bf6ff9e0
--- /dev/null
+++ b/libswscale/aarch64/rgb2rgb.c
@@ -0,0 +1,41 @@
+/*
+ * This file is part of FFmpeg.
+ *
+ * FFmpeg is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public
+ * License as published by the Free Software Foundation; either
+ * version 2.1 of the License, or (at your option) any later version.
+ *
+ * FFmpeg is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+ * Lesser General Public License for more details.
+ *
+ * You should have received a copy of the GNU Lesser General Public
+ * License along with FFmpeg; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA
+ */
+
+#include 
+
+#include "config.h"
+#include "libavutil/attributes.h"
+#include "libavutil/aarch64/cpu.h"
+#include "libavutil/cpu.h"
+#include "libavutil/bswap.h"
+#include "libswscale/rgb2rgb.h"
+#include "libswscale/swscale.h"
+#include "libswscale/swscale_internal.h"
+
+void ff_interleave_bytes_neon(const uint8_t *src1, const uint8_t *src2,
+  uint8_t *dest, int width, int height,
+  int src1Stride, int src2Stride, int dstStride);
+
+av_cold void rgb2rgb_init_aarch64(void)
+{
+int cpu_flags = av_get_cpu_flags();
+
+if (have_neon(cpu_flags)) {
+interleaveBytes = ff_interleave_bytes_neon;
+}
+}
diff --git a/libswscale/aarch64/rgb2rgb_neon.S 
b/libswscale/aarch64/rgb2rgb_neon.S
new file mode 100644
index 00..d81110ec57
--- /dev/null
+++ b/libswscale/aarch64/rgb2rgb_neon.S
@@ -0,0 +1,79 @@
+/*
+ * Copyright (c) 2020 Martin Storsjo
+ *
+ * This file is part of FFmpeg.
+ *
+ * FFmpeg is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public
+ * License as published by the Free Software Foundation; either
+ * version 2.1 of the License, or (at your option) any later version.
+ *
+ * FFmpeg is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+ * Lesser General Public License for more details.
+ *
+ * You should have received a copy of the GNU Lesser General Public
+ * License along with FFmpeg; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA
+ */
+
+#include "libavutil/aarch64/asm.S"
+
+// void ff_interleave_bytes_neon(const uint8_t *src1, const uint8_t *src2,
+//   uint8_t *dest, int width, int height,
+//   int src1Stride, int src2Stride, int 
dstStride);
+function ff_interleave_bytes_neon, export=1
+sub w5,  w5,  w3
+sub w6,  w6,  w3
+sub w7,  w7,  w3, lsl #1
+1:
+andsw8,  w3,  #0xfff0 // & ~15
+b.eq3f
+2:
+ld1 {v0.16b}, [x0], #16
+ld1 {v1.16b}, [x1], #16
+subsw8,  w8,  #16
+st2 {v0.16b, v1.16b}, [x2], #32
+b.gt2b
+
+tst w3,  #15
+

Re: [FFmpeg-devel] [PATCH] swscale: fix arm NEON hscale init

2020-05-15 Thread Josh de Kock


On 15/05/2020 19:35, Martin Storsjö wrote:

From: Josh de Kock 

The NEON hscale function only supports X8 filter sizes and should only
be selected when these are being used. At the moment filterAlign is
set to 8 but in the future when extra NEON assembly for specific sizes is
added they will need to have checks here too.

The immediate usecase for this change is making the hscale checkasm
test easier and without NEON specific edge-cases (x86 already has these
guards).

This applies the same fix from 718c8f9aa59751bb490e2688acf2b5cb68fd5ad1
on the 32 bit arm version of the function, fixing fate-checkasm-sw_scale
there.

Signed-off-by: Martin Storsjö 
---
  libswscale/arm/swscale.c | 5 -
  1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/libswscale/arm/swscale.c b/libswscale/arm/swscale.c
index 1ec360fe24..7b8fbcbc79 100644
--- a/libswscale/arm/swscale.c
+++ b/libswscale/arm/swscale.c
@@ -34,7 +34,10 @@ av_cold void ff_sws_init_swscale_arm(SwsContext *c)
  int cpu_flags = av_get_cpu_flags();
  
  if (have_neon(cpu_flags)) {

-if (c->srcBpc == 8 && c->dstBpc <= 14) {
+if (c->srcBpc == 8 && c->dstBpc <= 14 &&
+(c->hLumFilterSize % 8) == 0 &&
+(c->hChrFilterSize % 8) == 0)
+{
  c->hyScale = c->hcScale = ff_hscale_8_to_15_neon;
  }
  if (c->dstBpc == 8) {



LGTM

--
Josh
___
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 00/10] Vulkan code general/performance improvements

2020-05-15 Thread James Almer

On 5/15/2020 3:36 PM, Lynne wrote:
> Just posting this as a single email not to spam the ML too much.
> Going to push this sometime over the weekend alongside the other 3 patches to 
> finish
> all work on Vulkan before the next release.

The new release is not going to happen tomorrow or even next week, so
you could give people more than two days to look at a dozen patches...

> Satisfied with the code, though the last patch is slightly ugly.
> Performance improvements out of async code: 78% on a toy GPU with 1 queue for 
> an upload+scale
> Probably closer to 200% on a discrete GPU with 4 transfer/compute queues.

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

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

Re: [FFmpeg-devel] [PATCH 3/3] libavcodec: aarch64: Add a NEON implementation of pixblockdsp

2020-05-15 Thread Martin Storsjö


On Wed, 13 May 2020, Martin Storsjö wrote:


   Cortex A53A72A73
get_pixels_c:140.7   87.7   72.5
get_pixels_neon:  46.0   20.0   19.5
get_pixels_unaligned_c:  140.7   87.7   73.0
get_pixels_unaligned_neon:49.2   20.2   26.2
diff_pixels_c:   209.7  133.7  138.7
diff_pixels_neon: 54.2   31.7   23.5
diff_pixels_unaligned_c: 209.7  134.2  139.0
diff_pixels_unaligned_neon:   68.0   27.7   41.7
---
libavcodec/aarch64/Makefile   |  2 +
libavcodec/aarch64/pixblockdsp_init_aarch64.c | 46 +
libavcodec/aarch64/pixblockdsp_neon.S | 51 +++
libavcodec/pixblockdsp.c  |  2 +
libavcodec/pixblockdsp.h  |  2 +
5 files changed, 103 insertions(+)
create mode 100644 libavcodec/aarch64/pixblockdsp_init_aarch64.c
create mode 100644 libavcodec/aarch64/pixblockdsp_neon.S


Will apply this set (checkasm test + arm + aarch64 asm implementations) 
soon, as it's fairly trivial.


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

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

Re: [FFmpeg-devel] [PATCH 5/5] checkasm: aarch64: Check for stack overflows

2020-05-15 Thread Martin Storsjö


On Fri, 15 May 2020, Henrik Gramner wrote:


All 5 lgtm.


Thanks, pushed.

// Martin

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

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

[FFmpeg-devel] [PATCH] swscale: fix arm NEON hscale init

2020-05-15 Thread Martin Storsjö

From: Josh de Kock 

The NEON hscale function only supports X8 filter sizes and should only
be selected when these are being used. At the moment filterAlign is
set to 8 but in the future when extra NEON assembly for specific sizes is
added they will need to have checks here too.

The immediate usecase for this change is making the hscale checkasm
test easier and without NEON specific edge-cases (x86 already has these
guards).

This applies the same fix from 718c8f9aa59751bb490e2688acf2b5cb68fd5ad1
on the 32 bit arm version of the function, fixing fate-checkasm-sw_scale
there.

Signed-off-by: Martin Storsjö 
---
 libswscale/arm/swscale.c | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/libswscale/arm/swscale.c b/libswscale/arm/swscale.c
index 1ec360fe24..7b8fbcbc79 100644
--- a/libswscale/arm/swscale.c
+++ b/libswscale/arm/swscale.c
@@ -34,7 +34,10 @@ av_cold void ff_sws_init_swscale_arm(SwsContext *c)
 int cpu_flags = av_get_cpu_flags();
 
 if (have_neon(cpu_flags)) {
-if (c->srcBpc == 8 && c->dstBpc <= 14) {
+if (c->srcBpc == 8 && c->dstBpc <= 14 &&
+(c->hLumFilterSize % 8) == 0 &&
+(c->hChrFilterSize % 8) == 0)
+{
 c->hyScale = c->hcScale = ff_hscale_8_to_15_neon;
 }
 if (c->dstBpc == 8) {
-- 
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 v2 2/2] swscale: aarch64: Add a NEON implementation of interleaveBytes

2020-05-15 Thread Martin Storsjö

This allows speeding up format conversions from yuv420 to nv12.

 Cortex A53  A72  A73
interleave_bytes_c: 86077.5  51433.0  66972.0
interleave_bytes_neon:  19701.7  23019.2  15859.2
interleave_bytes_aligned_c: 86603.0  52017.2  67484.2
interleave_bytes_aligned_neon:   9061.0   7623.0   6309.0
---
v2: Made the stride handling signed, to properly handle negative strides,
fixing filter-pixfmts-vflip.
---
 libswscale/aarch64/Makefile   |  4 +-
 libswscale/aarch64/rgb2rgb.c  | 41 
 libswscale/aarch64/rgb2rgb_neon.S | 79 +++
 libswscale/rgb2rgb.c  |  2 +
 libswscale/rgb2rgb.h  |  1 +
 5 files changed, 126 insertions(+), 1 deletion(-)
 create mode 100644 libswscale/aarch64/rgb2rgb.c
 create mode 100644 libswscale/aarch64/rgb2rgb_neon.S

diff --git a/libswscale/aarch64/Makefile b/libswscale/aarch64/Makefile
index 64a3fe208d..da1d909561 100644
--- a/libswscale/aarch64/Makefile
+++ b/libswscale/aarch64/Makefile
@@ -1,6 +1,8 @@
-OBJS+= aarch64/swscale.o\
+OBJS+= aarch64/rgb2rgb.o\
+   aarch64/swscale.o\
aarch64/swscale_unscaled.o   \
 
 NEON-OBJS   += aarch64/hscale.o \
aarch64/output.o \
+   aarch64/rgb2rgb_neon.o   \
aarch64/yuv2rgb_neon.o   \
diff --git a/libswscale/aarch64/rgb2rgb.c b/libswscale/aarch64/rgb2rgb.c
new file mode 100644
index 00..a9bf6ff9e0
--- /dev/null
+++ b/libswscale/aarch64/rgb2rgb.c
@@ -0,0 +1,41 @@
+/*
+ * This file is part of FFmpeg.
+ *
+ * FFmpeg is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public
+ * License as published by the Free Software Foundation; either
+ * version 2.1 of the License, or (at your option) any later version.
+ *
+ * FFmpeg is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+ * Lesser General Public License for more details.
+ *
+ * You should have received a copy of the GNU Lesser General Public
+ * License along with FFmpeg; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA
+ */
+
+#include 
+
+#include "config.h"
+#include "libavutil/attributes.h"
+#include "libavutil/aarch64/cpu.h"
+#include "libavutil/cpu.h"
+#include "libavutil/bswap.h"
+#include "libswscale/rgb2rgb.h"
+#include "libswscale/swscale.h"
+#include "libswscale/swscale_internal.h"
+
+void ff_interleave_bytes_neon(const uint8_t *src1, const uint8_t *src2,
+  uint8_t *dest, int width, int height,
+  int src1Stride, int src2Stride, int dstStride);
+
+av_cold void rgb2rgb_init_aarch64(void)
+{
+int cpu_flags = av_get_cpu_flags();
+
+if (have_neon(cpu_flags)) {
+interleaveBytes = ff_interleave_bytes_neon;
+}
+}
diff --git a/libswscale/aarch64/rgb2rgb_neon.S 
b/libswscale/aarch64/rgb2rgb_neon.S
new file mode 100644
index 00..d81110ec57
--- /dev/null
+++ b/libswscale/aarch64/rgb2rgb_neon.S
@@ -0,0 +1,79 @@
+/*
+ * Copyright (c) 2020 Martin Storsjo
+ *
+ * This file is part of FFmpeg.
+ *
+ * FFmpeg is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public
+ * License as published by the Free Software Foundation; either
+ * version 2.1 of the License, or (at your option) any later version.
+ *
+ * FFmpeg is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+ * Lesser General Public License for more details.
+ *
+ * You should have received a copy of the GNU Lesser General Public
+ * License along with FFmpeg; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA
+ */
+
+#include "libavutil/aarch64/asm.S"
+
+// void ff_interleave_bytes_neon(const uint8_t *src1, const uint8_t *src2,
+//   uint8_t *dest, int width, int height,
+//   int src1Stride, int src2Stride, int 
dstStride);
+function ff_interleave_bytes_neon, export=1
+sub w5,  w5,  w3
+sub w6,  w6,  w3
+sub w7,  w7,  w3, lsl #1
+1:
+andsw8,  w3,  #0xfff0 // & ~15
+b.eq3f
+2:
+ld1 {v0.16b}, [x0], #16
+ld1 {v1.16b}, [x1], #16
+subsw8,  w8,  #16
+st2 {v0.16b, v1.16b}, [x2], #32
+b.gt2b
+
+tst w3,  #15
+b.eq9f
+
+3:
+tst w3,  #8
+

[FFmpeg-devel] [PATCH v2 1/2] checkasm: sw_rgb: Add a test for interleaveBytes

2020-05-15 Thread Martin Storsjö

---
This depends on "checkasm: Add functions for printing pixel buffers".

The existing x86 implementations of interleaveBytes seem to slow
down significantly for unaligned copies (GCC 7.5, Sandy Bridge):

interleave_bytes_c:  36251.6
interleave_bytes_mmx:10038.8
interleave_bytes_mmxext: 58450.3
interleave_bytes_sse2:   57746.3

For the properly aligned case, it behaves better:

interleave_bytes_aligned_c: 36109.8
interleave_bytes_aligned_mmx:6033.8
interleave_bytes_aligned_mmxext: 6473.1
interleave_bytes_aligned_sse2:   6163.1

But Clang (in Xcode 11.3, run on Kaby Lake) seems to beat all the asm
implementations, in its (autovectorized?) C version:

interleave_bytes_c:   9893.0
interleave_bytes_mmx:23153.5
interleave_bytes_mmxext: 43693.8
interleave_bytes_sse2:   55894.8

interleave_bytes_aligned_c:  3456.0
interleave_bytes_aligned_mmx:5780.0
interleave_bytes_aligned_mmxext: 4913.8
interleave_bytes_aligned_sse2:   4154.3

v2: Extended the test further to test all combinations of negative
strides for all three buffers.
---
 tests/checkasm/sw_rgb.c | 70 +
 1 file changed, 70 insertions(+)

diff --git a/tests/checkasm/sw_rgb.c b/tests/checkasm/sw_rgb.c
index 000420d8f7..1e8ea151c0 100644
--- a/tests/checkasm/sw_rgb.c
+++ b/tests/checkasm/sw_rgb.c
@@ -111,6 +111,73 @@ static void check_uyvy_to_422p(void)
 }
 }
 
+static void check_interleave_bytes(void)
+{
+LOCAL_ALIGNED_16(uint8_t, src0_buf, [MAX_STRIDE*MAX_HEIGHT+1]);
+LOCAL_ALIGNED_16(uint8_t, src1_buf, [MAX_STRIDE*MAX_HEIGHT+1]);
+LOCAL_ALIGNED_16(uint8_t, dst0_buf, [2*MAX_STRIDE*MAX_HEIGHT+2]);
+LOCAL_ALIGNED_16(uint8_t, dst1_buf, [2*MAX_STRIDE*MAX_HEIGHT+2]);
+// Intentionally using unaligned buffers, as this function doesn't have
+// any alignment requirements.
+uint8_t *src0 = src0_buf + 1;
+uint8_t *src1 = src1_buf + 1;
+uint8_t *dst0 = dst0_buf + 2;
+uint8_t *dst1 = dst1_buf + 2;
+
+declare_func_emms(AV_CPU_FLAG_MMX, void, const uint8_t *, const uint8_t *,
+   uint8_t *, int, int, int, int, int);
+
+randomize_buffers(src0, MAX_STRIDE * MAX_HEIGHT);
+randomize_buffers(src1, MAX_STRIDE * MAX_HEIGHT);
+
+if (check_func(interleaveBytes, "interleave_bytes")) {
+for (int i = 0; i <= 16; i++) {
+// Try all widths [1,16], and try one random width.
+
+int w = i > 0 ? i : (1 + (rnd() % (MAX_STRIDE-2)));
+int h = 1 + (rnd() % (MAX_HEIGHT-2));
+
+memset(dst0, 0, 2 * MAX_STRIDE * MAX_HEIGHT);
+memset(dst1, 0, 2 * MAX_STRIDE * MAX_HEIGHT);
+
+int src0_offset = 0, src0_stride = MAX_STRIDE;
+int src1_offset = 0, src1_stride = MAX_STRIDE;
+int dst_offset  = 0, dst_stride  = 2 * MAX_STRIDE;
+// Try different combinations of negative strides
+if (i & 1) {
+src0_offset = (h-1)*src0_stride;
+src0_stride = -src0_stride;
+}
+if (i & 2) {
+src1_offset = (h-1)*src1_stride;
+src1_stride = -src1_stride;
+}
+if (i & 4) {
+dst_offset = (h-1)*dst_stride;
+dst_stride = -dst_stride;
+}
+
+call_ref(src0 + src0_offset, src1 + src1_offset, dst0 + dst_offset,
+ w, h, src0_stride, src1_stride, dst_stride);
+call_new(src0 + src0_offset, src1 + src1_offset, dst1 + dst_offset,
+ w, h, src0_stride, src1_stride, dst_stride);
+// Check a one pixel-pair edge around the destination area,
+// to catch overwrites past the end.
+checkasm_check(uint8_t, dst0, 2*MAX_STRIDE, dst1, 2*MAX_STRIDE,
+   2 * w + 2, h + 1, "dst");
+}
+
+bench_new(src0, src1, dst1, 127, MAX_HEIGHT,
+  MAX_STRIDE, MAX_STRIDE, 2*MAX_STRIDE);
+}
+if (check_func(interleaveBytes, "interleave_bytes_aligned")) {
+// Bench the function in a more typical case, with aligned
+// buffers and widths.
+bench_new(src0_buf, src1_buf, dst1_buf, 128, MAX_HEIGHT,
+  MAX_STRIDE, MAX_STRIDE, 2*MAX_STRIDE);
+}
+}
+
 void checkasm_check_sw_rgb(void)
 {
 ff_sws_rgb2rgb_init();
@@ -132,4 +199,7 @@ void checkasm_check_sw_rgb(void)
 
 check_uyvy_to_422p();
 report("uyvytoyuv422");
+
+check_interleave_bytes();
+report("interleave_bytes");
 }
-- 
2.17.1

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

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

Re: [FFmpeg-devel] [PATCH] [libavformat/mov.c] Read the QT Metadata Keys only once

2020-05-15 Thread Thierry Foucu

On Thu, May 14, 2020 at 12:26 PM Derek Buitenhuis <
derek.buitenh...@gmail.com> wrote:

> On 14/05/2020 18:19, Thierry Foucu wrote:
> > Looking at
> >
> https://developer.apple.com/library/archive/documentation/QuickTime/QTFF/Metadata/Metadata.html
> > The spec does not seem to say 1 or more. But because the `keys` atom is a
> > list of indexes used by the `ilst` and the spec for `keys` said:
> > Indexes into the metadata item keys atom are 1-based (1…entry_count).
> >
> > having 2+ `keys` atoms will conflict with this, as which one will be
> index 1
> >
> > I'm assuming that only `keys` could only work.
> > instead of skipping the consecutive `keys` atom, I could change the code
> to
> > free the keys and re-alloc it for each `keys` atom found. So you will get
> > only the data from the last `keys` atom.
> >
> > so, it is either the 1st `keys` or the last `keys`. Up to you.
>
> LGTM as-is then.
>

Thanks for the review, Derek.
Any chance to have someone to submit it?


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



-- 

Thierry Foucu
___
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/mpegts: Check the next sync byte to avoid incorrectt detected raw packet size

2020-05-15 Thread Marton Balint




On Fri, 15 May 2020, lance.lmw...@gmail.com wrote:


On Fri, May 15, 2020 at 08:02:44PM +0800, myp...@gmail.com wrote:

On Fri, May 15, 2020 at 6:23 PM  wrote:
>
> From: Limin Wang 
>
> reanalyze() may misdetect the new packet size as 204, but it's 188 still 
actualy,
> it'll cause many cc errors report and cannot be recovered. So it's better to 
check
> the next sync byte before skip the extra unused bytes.
>
> Also, it is best to change SIZE_STAT_THRESHOLD from 10 to 100? If the input 
stream has
> a master/slave switch serveral times, the raw size can be easily detected by 
mistake.
>
> Signed-off-by: Limin Wang 
> ---
>  libavformat/mpegts.c | 13 +++--
>  1 file changed, 7 insertions(+), 6 deletions(-)
>
> diff --git a/libavformat/mpegts.c b/libavformat/mpegts.c
> index 0833d62..049555c 100644
> --- a/libavformat/mpegts.c
> +++ b/libavformat/mpegts.c
> @@ -2932,11 +2932,12 @@ static int read_packet(AVFormatContext *s, uint8_t 
*buf, int raw_packet_size,
>  return 0;
>  }
>
> -static void finished_reading_packet(AVFormatContext *s, int raw_packet_size)
> +static void finished_reading_packet(AVFormatContext *s, const uint8_t *data, 
int raw_packet_size)
>  {
>  AVIOContext *pb = s->pb;
>  int skip = raw_packet_size - TS_PACKET_SIZE;
> -if (skip > 0)
> +/* Check the next sync byte to avoid incorrectt detected raw packet size 
*/
> +if (skip > 0 && data[TS_PACKET_SIZE] != 0x47)
>  avio_skip(pb, skip);
>  }
>
> @@ -2985,7 +2986,7 @@ static int handle_packets(MpegTSContext *ts, int64_t 
nb_packets)
>  if (ret != 0)
>  break;
>  ret = handle_packet(ts, data, avio_tell(s->pb));
> -finished_reading_packet(s, ts->raw_packet_size);
> +finished_reading_packet(s, data, ts->raw_packet_size);
>  if (ret != 0)
>  break;
>  }
> @@ -3137,7 +3138,7 @@ static int mpegts_read_header(AVFormatContext *s)
>  pid = AV_RB16(data + 1) & 0x1fff;
>  if ((pcr_pid == -1 || pcr_pid == pid) &&
>  parse_pcr(&pcr_h, &pcr_l, data) == 0) {
> -finished_reading_packet(s, ts->raw_packet_size);
> +finished_reading_packet(s, data, ts->raw_packet_size);
>  pcr_pid = pid;
>  packet_count[nb_pcrs] = nb_packets;
>  pcrs[nb_pcrs] = pcr_h * 300 + pcr_l;
> @@ -3154,7 +3155,7 @@ static int mpegts_read_header(AVFormatContext *s)
>  }
>  }
>  } else {
> -finished_reading_packet(s, ts->raw_packet_size);
> +finished_reading_packet(s, data, ts->raw_packet_size);
>  }
>  nb_packets++;
>  }
> @@ -3194,7 +3195,7 @@ static int mpegts_raw_read_packet(AVFormatContext *s, 
AVPacket *pkt)
>  }
>  if (data != pkt->data)
>  memcpy(pkt->data, data, ts->raw_packet_size);
> -finished_reading_packet(s, ts->raw_packet_size);
> +finished_reading_packet(s, data, ts->raw_packet_size);
>  if (ts->mpeg2ts_compute_pcr) {
>  /* compute exact PCR for each packet */
>  if (parse_pcr(&pcr_h, &pcr_l, pkt->data) == 0) {
> --
> 1.8.3.1
>
Do you have a case to reproduce the cc errors report?


Yes, it's real case which can be reproduced in lab.


Can you share the sample?

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

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

Re: [FFmpeg-devel] [PATCH 2/2] Revert "avfilter/vf_framerate: if metadata lavfi.scd.mafd exists, we'll use it first"

2020-05-15 Thread Marton Balint




On Fri, 15 May 2020, Limin Wang wrote:


On Thu, May 14, 2020 at 11:03:49PM +0200, Marton Balint wrote:

This reverts commit 339593ca90cb3e05d659ec99a1479904ec742294.

Fixes null pointer dereference.




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

diff --git a/libavfilter/vf_framerate.c b/libavfilter/vf_framerate.c
index 8d16998457..6c8d01c94b 100644
--- a/libavfilter/vf_framerate.c
+++ b/libavfilter/vf_framerate.c
@@ -71,20 +71,13 @@ static double get_scene_score(AVFilterContext *ctx, AVFrame 
*crnt, AVFrame *next

 if (crnt->height == next->height &&
 crnt->width  == next->width) {
-AVDictionaryEntry *e_mafd = NULL;
 uint64_t sad;
-double mafd = HUGE_VAL, diff;
-char *tail = NULL;
+double mafd, diff;

 ff_dlog(ctx, "get_scene_score() process\n");
-e_mafd = av_dict_get(next->metadata, "lavfi.scd.mafd", NULL, 
AV_DICT_MATCH_CASE);
-if (e_mafd)
-mafd = strtod(e_mafd->value, &tail);


just have time to look at the issue, I prefer to add one extra checking for 
!tail to fix
it, it's better than revert. I'll post patch for the fixes.


Applied the revert patches for now, because it seems there are other 
changes requested. Also the documentation should also mention that scene 
change detection depends on metadata.


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

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

Re: [FFmpeg-devel] [PATCH 1/2] Revert "avfilter/vf_minterpolate: if metadata lavfi.scd.mafd exists, we'll use it first"

2020-05-15 Thread Paul B Mahol

Why was this applied without review?

Please revert ASAP!

On 5/14/20, Marton Balint  wrote:
> This reverts commit d88e1c9838dbcfe29d7835f2705ffc9ee6a36bf3.
>
> Fixes null pointer dereference.
>
> Signed-off-by: Marton Balint 
> ---
>  libavfilter/vf_minterpolate.c | 16 
>  1 file changed, 4 insertions(+), 12 deletions(-)
>
> diff --git a/libavfilter/vf_minterpolate.c b/libavfilter/vf_minterpolate.c
> index ef47140946..c9ce80420d 100644
> --- a/libavfilter/vf_minterpolate.c
> +++ b/libavfilter/vf_minterpolate.c
> @@ -834,19 +834,11 @@ static int detect_scene_change(MIContext *mi_ctx)
>  ptrdiff_t linesize2 = mi_ctx->frames[2].avf->linesize[0];
>
>  if (mi_ctx->scd_method == SCD_METHOD_FDIFF) {
> -double ret = 0, mafd = HUGE_VAL, diff;
> +double ret = 0, mafd, diff;
>  uint64_t sad;
> -AVDictionaryEntry *e_mafd = NULL;
> -char *tail = NULL;
> -
> -e_mafd = av_dict_get(mi_ctx->frames[2].avf->metadata,
> "lavfi.scd.mafd", NULL, AV_DICT_MATCH_CASE);
> -if (e_mafd)
> -mafd = strtod(e_mafd->value, &tail);
> -if (*tail || mafd == HUGE_VAL) {
> -mi_ctx->sad(p1, linesize1, p2, linesize2, me_ctx->width,
> me_ctx->height, &sad);
> -emms_c();
> -mafd = (double) sad * 100.0 / (me_ctx->height * me_ctx->width)
> / (1 << mi_ctx->bitdepth);
> -}
> +mi_ctx->sad(p1, linesize1, p2, linesize2, me_ctx->width,
> me_ctx->height, &sad);
> +emms_c();
> +mafd = (double) sad * 100.0 / (me_ctx->height * me_ctx->width) / (1
> << mi_ctx->bitdepth);
>  diff = fabs(mafd - mi_ctx->prev_mafd);
>  ret  = av_clipf(FFMIN(mafd, diff), 0, 100.0);
>  mi_ctx->prev_mafd = mafd;
> --
> 2.16.4
>
> ___
> 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 5/5] checkasm: aarch64: Check for stack overflows

2020-05-15 Thread Henrik Gramner

All 5 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] avfilter: add gradients source video filter

2020-05-15 Thread Paul B Mahol

Signed-off-by: Paul B Mahol 
---
 doc/filters.texi |  27 
 libavfilter/Makefile |   1 +
 libavfilter/allfilters.c |   1 +
 libavfilter/vsrc_gradients.c | 290 +++
 4 files changed, 319 insertions(+)
 create mode 100644 libavfilter/vsrc_gradients.c

diff --git a/doc/filters.texi b/doc/filters.texi
index f73d4057c1..53303f6867 100644
--- a/doc/filters.texi
+++ b/doc/filters.texi
@@ -22281,6 +22281,33 @@ need for a nullsrc video source.
 @end itemize
 
 
+@section gradients
+Generate several gradients.
+
+@table @option
+@item size, s
+Set frame size. For the syntax of this option, check the @ref{video size 
syntax,,"Video
+size" section in the ffmpeg-utils manual,ffmpeg-utils}. Default value is 
"640x480".
+
+@item rate, r
+Set frame rate, expressed as number of frames per second. Default
+value is "25".
+
+@item c0, c1, c2, c3, c4, c5, c6, c7
+Set 8 colors. Default values for colors is to pick random one.
+
+@item x0, y0, y0, y1
+Set gradient line source and destination points. If negative or out of range, 
random ones
+are picked.
+
+@item nb_colors, n
+Set number of colors to use at once. Allowed range is from 2 to 8. Default 
value is 2.
+
+@item seed
+Set seed for picking gradient line points.
+@end table
+
+
 @section mandelbrot
 
 Generate a Mandelbrot set fractal, and progressively zoom towards the
diff --git a/libavfilter/Makefile b/libavfilter/Makefile
index b2086f6fa9..4d07bb6948 100644
--- a/libavfilter/Makefile
+++ b/libavfilter/Makefile
@@ -471,6 +471,7 @@ OBJS-$(CONFIG_CELLAUTO_FILTER)   += 
vsrc_cellauto.o
 OBJS-$(CONFIG_COLOR_FILTER)  += vsrc_testsrc.o
 OBJS-$(CONFIG_COREIMAGESRC_FILTER)   += vf_coreimage.o
 OBJS-$(CONFIG_FREI0R_SRC_FILTER) += vf_frei0r.o
+OBJS-$(CONFIG_GRADIENTS_FILTER)  += vsrc_gradients.o
 OBJS-$(CONFIG_HALDCLUTSRC_FILTER)+= vsrc_testsrc.o
 OBJS-$(CONFIG_LIFE_FILTER)   += vsrc_life.o
 OBJS-$(CONFIG_MANDELBROT_FILTER) += vsrc_mandelbrot.o
diff --git a/libavfilter/allfilters.c b/libavfilter/allfilters.c
index 8830c8d871..6d7ad68f38 100644
--- a/libavfilter/allfilters.c
+++ b/libavfilter/allfilters.c
@@ -449,6 +449,7 @@ extern AVFilter ff_vsrc_cellauto;
 extern AVFilter ff_vsrc_color;
 extern AVFilter ff_vsrc_coreimagesrc;
 extern AVFilter ff_vsrc_frei0r_src;
+extern AVFilter ff_vsrc_gradients;
 extern AVFilter ff_vsrc_haldclutsrc;
 extern AVFilter ff_vsrc_life;
 extern AVFilter ff_vsrc_mandelbrot;
diff --git a/libavfilter/vsrc_gradients.c b/libavfilter/vsrc_gradients.c
new file mode 100644
index 00..984227017e
--- /dev/null
+++ b/libavfilter/vsrc_gradients.c
@@ -0,0 +1,290 @@
+/*
+ * Copyright (c) 2020 Paul B Mahol
+ *
+ * This file is part of FFmpeg.
+ *
+ * FFmpeg is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public
+ * License as published by the Free Software Foundation; either
+ * version 2.1 of the License, or (at your option) any later version.
+ *
+ * FFmpeg is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+ * Lesser General Public License for more details.
+ *
+ * You should have received a copy of the GNU Lesser General Public
+ * License along with FFmpeg; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA
+ */
+
+#include "avfilter.h"
+#include "formats.h"
+#include "video.h"
+#include "internal.h"
+#include "libavutil/imgutils.h"
+#include "libavutil/intreadwrite.h"
+#include "libavutil/opt.h"
+#include "libavutil/parseutils.h"
+#include "libavutil/lfg.h"
+#include "libavutil/random_seed.h"
+#include 
+#include 
+
+typedef struct GradientsContext {
+const AVClass *class;
+int w, h;
+int type;
+AVRational frame_rate;
+uint64_t pts;
+
+uint8_t color_rgba[8][4];
+int nb_colors;
+int x0, y0, x1, y1;
+float fx0, fy0, fx1, fy1;
+
+int64_t seed;
+
+AVLFG lfg;
+int (*draw_slice)(AVFilterContext *ctx, void *arg, int job, int nb_jobs);
+} GradientsContext;
+
+#define OFFSET(x) offsetof(GradientsContext, x)
+#define FLAGS AV_OPT_FLAG_VIDEO_PARAM|AV_OPT_FLAG_FILTERING_PARAM
+
+static const AVOption gradients_options[] = {
+{"size",  "set frame size", OFFSET(w), 
AV_OPT_TYPE_IMAGE_SIZE, {.str="640x480"},  0, 0, FLAGS },
+{"s", "set frame size", OFFSET(w), 
AV_OPT_TYPE_IMAGE_SIZE, {.str="640x480"},  0, 0, FLAGS },
+{"rate",  "set frame rate", OFFSET(frame_rate),
AV_OPT_TYPE_VIDEO_RATE, {.str="25"},   0, INT_MAX, FLAGS },
+{"r", "set frame rate", OFFSET(frame_rate),
AV_OPT_TYPE_VIDEO_RATE, {.str="25"},   0, INT_MAX, FLAGS },
+{"c0","set 1st color",  OFFSET(color_rgba[0]), AV_OPT_TYPE_COLOR,  
{.str = "random"}, 0

Re: [FFmpeg-devel] [PATCH] lavfi: add untile filter.

2020-05-15 Thread Paul B Mahol

On 4/16/20, Nicolas George  wrote:
> Signed-off-by: Nicolas George 
> ---
>  doc/filters.texi |  34 ++
>  libavfilter/Makefile |   1 +
>  libavfilter/allfilters.c |   1 +
>  libavfilter/vf_untile.c  | 198 +++
>  tests/fate/filter-video.mak  |   3 +
>  tests/ref/fate/filter-untile |  13 +++
>  6 files changed, 250 insertions(+)
>  create mode 100644 libavfilter/vf_untile.c
>  create mode 100644 tests/ref/fate/filter-untile
>

When to apply?
___
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/mpegts: Check the next sync byte to avoid incorrectt detected raw packet size

2020-05-15 Thread lance . lmwang

On Fri, May 15, 2020 at 08:02:44PM +0800, myp...@gmail.com wrote:
> On Fri, May 15, 2020 at 6:23 PM  wrote:
> >
> > From: Limin Wang 
> >
> > reanalyze() may misdetect the new packet size as 204, but it's 188 still 
> > actualy,
> > it'll cause many cc errors report and cannot be recovered. So it's better 
> > to check
> > the next sync byte before skip the extra unused bytes.
> >
> > Also, it is best to change SIZE_STAT_THRESHOLD from 10 to 100? If the input 
> > stream has
> > a master/slave switch serveral times, the raw size can be easily detected 
> > by mistake.
> >
> > Signed-off-by: Limin Wang 
> > ---
> >  libavformat/mpegts.c | 13 +++--
> >  1 file changed, 7 insertions(+), 6 deletions(-)
> >
> > diff --git a/libavformat/mpegts.c b/libavformat/mpegts.c
> > index 0833d62..049555c 100644
> > --- a/libavformat/mpegts.c
> > +++ b/libavformat/mpegts.c
> > @@ -2932,11 +2932,12 @@ static int read_packet(AVFormatContext *s, uint8_t 
> > *buf, int raw_packet_size,
> >  return 0;
> >  }
> >
> > -static void finished_reading_packet(AVFormatContext *s, int 
> > raw_packet_size)
> > +static void finished_reading_packet(AVFormatContext *s, const uint8_t 
> > *data, int raw_packet_size)
> >  {
> >  AVIOContext *pb = s->pb;
> >  int skip = raw_packet_size - TS_PACKET_SIZE;
> > -if (skip > 0)
> > +/* Check the next sync byte to avoid incorrectt detected raw packet 
> > size */
> > +if (skip > 0 && data[TS_PACKET_SIZE] != 0x47)
> >  avio_skip(pb, skip);
> >  }
> >
> > @@ -2985,7 +2986,7 @@ static int handle_packets(MpegTSContext *ts, int64_t 
> > nb_packets)
> >  if (ret != 0)
> >  break;
> >  ret = handle_packet(ts, data, avio_tell(s->pb));
> > -finished_reading_packet(s, ts->raw_packet_size);
> > +finished_reading_packet(s, data, ts->raw_packet_size);
> >  if (ret != 0)
> >  break;
> >  }
> > @@ -3137,7 +3138,7 @@ static int mpegts_read_header(AVFormatContext *s)
> >  pid = AV_RB16(data + 1) & 0x1fff;
> >  if ((pcr_pid == -1 || pcr_pid == pid) &&
> >  parse_pcr(&pcr_h, &pcr_l, data) == 0) {
> > -finished_reading_packet(s, ts->raw_packet_size);
> > +finished_reading_packet(s, data, ts->raw_packet_size);
> >  pcr_pid = pid;
> >  packet_count[nb_pcrs] = nb_packets;
> >  pcrs[nb_pcrs] = pcr_h * 300 + pcr_l;
> > @@ -3154,7 +3155,7 @@ static int mpegts_read_header(AVFormatContext *s)
> >  }
> >  }
> >  } else {
> > -finished_reading_packet(s, ts->raw_packet_size);
> > +finished_reading_packet(s, data, ts->raw_packet_size);
> >  }
> >  nb_packets++;
> >  }
> > @@ -3194,7 +3195,7 @@ static int mpegts_raw_read_packet(AVFormatContext *s, 
> > AVPacket *pkt)
> >  }
> >  if (data != pkt->data)
> >  memcpy(pkt->data, data, ts->raw_packet_size);
> > -finished_reading_packet(s, ts->raw_packet_size);
> > +finished_reading_packet(s, data, ts->raw_packet_size);
> >  if (ts->mpeg2ts_compute_pcr) {
> >  /* compute exact PCR for each packet */
> >  if (parse_pcr(&pcr_h, &pcr_l, pkt->data) == 0) {
> > --
> > 1.8.3.1
> >
> Do you have a case to reproduce the cc errors report?

Yes, it's real case which can be reproduced in lab.


-- 
Thanks,
Limin Wang
___
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/mpegts: Check the next sync byte to avoid incorrectt detected raw packet size

2020-05-15 Thread myp...@gmail.com

On Fri, May 15, 2020 at 6:23 PM  wrote:
>
> From: Limin Wang 
>
> reanalyze() may misdetect the new packet size as 204, but it's 188 still 
> actualy,
> it'll cause many cc errors report and cannot be recovered. So it's better to 
> check
> the next sync byte before skip the extra unused bytes.
>
> Also, it is best to change SIZE_STAT_THRESHOLD from 10 to 100? If the input 
> stream has
> a master/slave switch serveral times, the raw size can be easily detected by 
> mistake.
>
> Signed-off-by: Limin Wang 
> ---
>  libavformat/mpegts.c | 13 +++--
>  1 file changed, 7 insertions(+), 6 deletions(-)
>
> diff --git a/libavformat/mpegts.c b/libavformat/mpegts.c
> index 0833d62..049555c 100644
> --- a/libavformat/mpegts.c
> +++ b/libavformat/mpegts.c
> @@ -2932,11 +2932,12 @@ static int read_packet(AVFormatContext *s, uint8_t 
> *buf, int raw_packet_size,
>  return 0;
>  }
>
> -static void finished_reading_packet(AVFormatContext *s, int raw_packet_size)
> +static void finished_reading_packet(AVFormatContext *s, const uint8_t *data, 
> int raw_packet_size)
>  {
>  AVIOContext *pb = s->pb;
>  int skip = raw_packet_size - TS_PACKET_SIZE;
> -if (skip > 0)
> +/* Check the next sync byte to avoid incorrectt detected raw packet size 
> */
> +if (skip > 0 && data[TS_PACKET_SIZE] != 0x47)
>  avio_skip(pb, skip);
>  }
>
> @@ -2985,7 +2986,7 @@ static int handle_packets(MpegTSContext *ts, int64_t 
> nb_packets)
>  if (ret != 0)
>  break;
>  ret = handle_packet(ts, data, avio_tell(s->pb));
> -finished_reading_packet(s, ts->raw_packet_size);
> +finished_reading_packet(s, data, ts->raw_packet_size);
>  if (ret != 0)
>  break;
>  }
> @@ -3137,7 +3138,7 @@ static int mpegts_read_header(AVFormatContext *s)
>  pid = AV_RB16(data + 1) & 0x1fff;
>  if ((pcr_pid == -1 || pcr_pid == pid) &&
>  parse_pcr(&pcr_h, &pcr_l, data) == 0) {
> -finished_reading_packet(s, ts->raw_packet_size);
> +finished_reading_packet(s, data, ts->raw_packet_size);
>  pcr_pid = pid;
>  packet_count[nb_pcrs] = nb_packets;
>  pcrs[nb_pcrs] = pcr_h * 300 + pcr_l;
> @@ -3154,7 +3155,7 @@ static int mpegts_read_header(AVFormatContext *s)
>  }
>  }
>  } else {
> -finished_reading_packet(s, ts->raw_packet_size);
> +finished_reading_packet(s, data, ts->raw_packet_size);
>  }
>  nb_packets++;
>  }
> @@ -3194,7 +3195,7 @@ static int mpegts_raw_read_packet(AVFormatContext *s, 
> AVPacket *pkt)
>  }
>  if (data != pkt->data)
>  memcpy(pkt->data, data, ts->raw_packet_size);
> -finished_reading_packet(s, ts->raw_packet_size);
> +finished_reading_packet(s, data, ts->raw_packet_size);
>  if (ts->mpeg2ts_compute_pcr) {
>  /* compute exact PCR for each packet */
>  if (parse_pcr(&pcr_h, &pcr_l, pkt->data) == 0) {
> --
> 1.8.3.1
>
Do you have a case to reproduce the cc errors report?
___
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/url: check the result of the strrchr

2020-05-15 Thread Steven Liu

Steven Liu  于2020年5月15日周五 下午6:02写道：
>
> because it need be check for success, is should not
> change the old way if it failure.
Change the comments:
because it need be checked for success status, it should not
change the old way if it failure.
>
> Signed-off-by: Steven Liu 
> ---
>  libavformat/url.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/libavformat/url.c b/libavformat/url.c
> index 7cd9e0c705..6956f6dc10 100644
> --- a/libavformat/url.c
> +++ b/libavformat/url.c
> @@ -182,7 +182,7 @@ void ff_make_absolute_url(char *buf, int size, const char 
> *base,
>
>  /* Remove the file name from the base url */
>  sep = strrchr(buf, '/');
> -if (sep <= root)
> +if (sep && sep <= root)
>  sep = root;
>
>  if (sep)
> --
> 2.25.0
>
>
>
>
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
> To unsubscribe, visit link above, or email
> ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

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

Re: [FFmpeg-devel] [PATCH v4 1/2] avcodec: add adpcm_ima_ssi encoder

2020-05-15 Thread Zane van Iperen

On Fri, 08 May 2020 14:31:27 +
"Zane van Iperen"  wrote:

> 
> Signed-off-by: Zane van Iperen 
> ---
>  Changelog  |  1 +
>  doc/general.texi   |  2 +-
>  libavcodec/Makefile|  1 +
>  libavcodec/adpcmenc.c  | 65
> +++--- libavcodec/allcodecs.c |
> 1 + libavcodec/utils.c |  1 +
>  libavcodec/version.h   |  2 +-
>  7 files changed, 55 insertions(+), 18 deletions(-)

Ping.

Zane

___
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] checkasm: Add functions for printing pixel buffers

2020-05-15 Thread Josh de Kock


On 14/05/2020 22:28, Martin Storsjö wrote:

On Thu, 14 May 2020, Josh de Kock wrote:


From: Martin Storsjö 

This was ported from dav1d (c950e7101bdf5f7117bfca816984a21e550509f0).

Signed-off-by: Josh de Kock 
---
tests/checkasm/checkasm.c | 42 +++
tests/checkasm/checkasm.h | 16 +++
2 files changed, 58 insertions(+)


This looks good to me, although I might be biased :-)



Pushed with amended commit message (I don't think it's necessary to 
mention pixels as it's a more general function for checking and diffing 
rectangular sections of memory).


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

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

Re: [FFmpeg-devel] [PATCH v3] checkasm: add hscale test

2020-05-15 Thread Josh de Kock


On 15/05/2020 09:41, Martin Storsjö wrote:

On Thu, 14 May 2020, Josh de Kock wrote:


This tests the hscale 8bpp to 14bpp functions with different filter
sizes.

Signed-off-by: Josh de Kock 
---

Adds support for checking corner cases for signed and large
coefficients. Also makes the padded coefficients random data.

Tested on x86_64 and aarch64.

tests/checkasm/Makefile   |   2 +-
tests/checkasm/checkasm.c |   1 +
tests/checkasm/checkasm.h |   1 +
tests/checkasm/sw_scale.c | 134 ++
4 files changed, 137 insertions(+), 1 deletion(-)
create mode 100644 tests/checkasm/sw_scale.c


I forgot to point out, this is missing an addition to 
tests/fate/checkasm.mak - as the tests are run in separate checkasm 
invocations, we need to add new tests groups there, otherwise they 
aren't run as part of "make fate".




Thanks for the reviews! Pushed with both fixes.

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

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

Re: [FFmpeg-devel] [PATCH 1/2] swscale: fix NEON hscale init

2020-05-15 Thread Josh de Kock


On 08/05/2020 12:25, Michael Niedermayer wrote:

On Thu, May 07, 2020 at 12:25:34PM +0100, Josh de Kock wrote:

The NEON hscale function only supports X8 filter sizes and should only
be selected when these are being used.

Signed-off-by: Josh de Kock 
---
  libswscale/aarch64/swscale.c | 5 -
  1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/libswscale/aarch64/swscale.c b/libswscale/aarch64/swscale.c
index 54a3beabe8..eecbea88ca 100644
--- a/libswscale/aarch64/swscale.c
+++ b/libswscale/aarch64/swscale.c
@@ -34,7 +34,10 @@ av_cold void ff_sws_init_swscale_aarch64(SwsContext *c)
  int cpu_flags = av_get_cpu_flags();
  
  if (have_neon(cpu_flags)) {

-if (c->srcBpc == 8 && c->dstBpc <= 14) {
+if (c->srcBpc == 8 && c->dstBpc <= 14 &&
+(c->hLumFilterSize % 8) == 0 &&
+(c->hChrFilterSize % 8) == 0)
+{
  c->hyScale = c->hcScale = ff_hscale_8_to_15_neon;
  }


isnt filterAlign set to 8 when neon is available ?

[...]



Discussed on IRC. Pushed with set.

--
Josh

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

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

[FFmpeg-devel] [PATCH] avformat/mpegts: Check the next sync byte to avoid incorrectt detected raw packet size

2020-05-15 Thread lance . lmwang

From: Limin Wang 

reanalyze() may misdetect the new packet size as 204, but it's 188 still 
actualy,
it'll cause many cc errors report and cannot be recovered. So it's better to 
check
the next sync byte before skip the extra unused bytes.

Also, it is best to change SIZE_STAT_THRESHOLD from 10 to 100? If the input 
stream has
a master/slave switch serveral times, the raw size can be easily detected by 
mistake.

Signed-off-by: Limin Wang 
---
 libavformat/mpegts.c | 13 +++--
 1 file changed, 7 insertions(+), 6 deletions(-)

diff --git a/libavformat/mpegts.c b/libavformat/mpegts.c
index 0833d62..049555c 100644
--- a/libavformat/mpegts.c
+++ b/libavformat/mpegts.c
@@ -2932,11 +2932,12 @@ static int read_packet(AVFormatContext *s, uint8_t 
*buf, int raw_packet_size,
 return 0;
 }
 
-static void finished_reading_packet(AVFormatContext *s, int raw_packet_size)
+static void finished_reading_packet(AVFormatContext *s, const uint8_t *data, 
int raw_packet_size)
 {
 AVIOContext *pb = s->pb;
 int skip = raw_packet_size - TS_PACKET_SIZE;
-if (skip > 0)
+/* Check the next sync byte to avoid incorrectt detected raw packet size */
+if (skip > 0 && data[TS_PACKET_SIZE] != 0x47)
 avio_skip(pb, skip);
 }
 
@@ -2985,7 +2986,7 @@ static int handle_packets(MpegTSContext *ts, int64_t 
nb_packets)
 if (ret != 0)
 break;
 ret = handle_packet(ts, data, avio_tell(s->pb));
-finished_reading_packet(s, ts->raw_packet_size);
+finished_reading_packet(s, data, ts->raw_packet_size);
 if (ret != 0)
 break;
 }
@@ -3137,7 +3138,7 @@ static int mpegts_read_header(AVFormatContext *s)
 pid = AV_RB16(data + 1) & 0x1fff;
 if ((pcr_pid == -1 || pcr_pid == pid) &&
 parse_pcr(&pcr_h, &pcr_l, data) == 0) {
-finished_reading_packet(s, ts->raw_packet_size);
+finished_reading_packet(s, data, ts->raw_packet_size);
 pcr_pid = pid;
 packet_count[nb_pcrs] = nb_packets;
 pcrs[nb_pcrs] = pcr_h * 300 + pcr_l;
@@ -3154,7 +3155,7 @@ static int mpegts_read_header(AVFormatContext *s)
 }
 }
 } else {
-finished_reading_packet(s, ts->raw_packet_size);
+finished_reading_packet(s, data, ts->raw_packet_size);
 }
 nb_packets++;
 }
@@ -3194,7 +3195,7 @@ static int mpegts_raw_read_packet(AVFormatContext *s, 
AVPacket *pkt)
 }
 if (data != pkt->data)
 memcpy(pkt->data, data, ts->raw_packet_size);
-finished_reading_packet(s, ts->raw_packet_size);
+finished_reading_packet(s, data, ts->raw_packet_size);
 if (ts->mpeg2ts_compute_pcr) {
 /* compute exact PCR for each packet */
 if (parse_pcr(&pcr_h, &pcr_l, pkt->data) == 0) {
-- 
1.8.3.1

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

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

[FFmpeg-devel] [PATCH] avformat/url: check the result of the strrchr

2020-05-15 Thread Steven Liu

because it need be check for success, is should not
change the old way if it failure.

Signed-off-by: Steven Liu 
---
 libavformat/url.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/libavformat/url.c b/libavformat/url.c
index 7cd9e0c705..6956f6dc10 100644
--- a/libavformat/url.c
+++ b/libavformat/url.c
@@ -182,7 +182,7 @@ void ff_make_absolute_url(char *buf, int size, const char 
*base,
 
 /* Remove the file name from the base url */
 sep = strrchr(buf, '/');
-if (sep <= root)
+if (sep && sep <= root)
 sep = root;
 
 if (sep)
-- 
2.25.0




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

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

Re: [FFmpeg-devel] [PATCH v6 2/4] avfilter/vf_framerate: if metadata lavfi.scd.mafd exists, we'll use it first

2020-05-15 Thread lance . lmwang

On Fri, May 15, 2020 at 11:50:08AM +0200, Paul B Mahol wrote:
> On 5/15/20, lance.lmw...@gmail.com  wrote:
> > On Fri, May 15, 2020 at 11:27:00AM +0200, Paul B Mahol wrote:
> >> On 5/15/20, lance.lmw...@gmail.com  wrote:
> >> > On Fri, May 15, 2020 at 10:27:35AM +0200, Paul B Mahol wrote:
> >> >> On 5/15/20, lance.lmw...@gmail.com  wrote:
> >> >> > On Thu, May 14, 2020 at 09:00:21PM +0200, Marton Balint wrote:
> >> >> >>
> >> >> >>
> >> >> >> On Thu, 14 May 2020, Marton Balint wrote:
> >> >> >>
> >> >> >> >
> >> >> >> >
> >> >> >> > On Thu, 14 May 2020, Nicolas George wrote:
> >> >> >> >
> >> >> >> > > Marton Balint (12020-05-14):
> >> >> >> > > > I am not a huge fan of this patch, mafd refers to a score
> >> >> >> > > > between this
> >> >> >> > frame
> >> >> >> > > > and the previous frame, we cannot ensure that there were no
> >> >> >> > > > additional
> >> >> >> > frame
> >> >> >> > > > processing between scdet and this filter which may have
> >> >> >> > > > duplicated
> >> >> >> > > > or
> >> >> >> > > > removed frames. So I'd rather not add this feature.
> >> >> >> > >
> >> >> >> > > It can only happen if the user has put filters in the middle. I
> >> >> >> > > move
> >> >> >> > > we
> >> >> >> > > trust users who insert such obscure filters to do what they want
> >> >> >> > > to,
> >> >> >> > > or
> >> >> >> > > to fix their issues if they have some.
> >> >> >> >
> >> >> >> > Fine, I am not blocking this if null pointer deref issues are
> >> >> >> > fixed.
> >> >> >> >
> >> >> >> > I think we can also assume that if the metadata exists, it will
> >> >> >> > contain
> >> >> >> > a valid number, so I suggest this code:
> >> >> >> >
> >> >> >> > e_mafd = av_dict_get(next->metadata, "lavfi.scd.mafd",
> >> >> >> > NULL,
> >> >> >> > AV_DICT_MATCH_CASE);
> >> >> >> > if (e_mafd) {
> >> >> >> > mafd = strtod(e_mafd->value, NULL);
> >> >> >> > } else {
> >> >> >> > s->sad(crnt->data[0], crnt->linesize[0],
> >> >> >> > next->data[0],
> >> >> >> > next->linesize[0], crnt->width, crnt->height, &sad);
> >> >> >> > emms_c();
> >> >> >> > mafd = (double)sad * 100.0 / (crnt->width *
> >> >> >> > crnt->height)
> >> >> >> > /
> >> >> >> > (1 << s->bitdepth);
> >> >> >> > }
> >> >> >>
> >> >> >> Why this patch was committed without a recent review???
> >> >> >
> >> >> > Sorry, I consider it's reviewed old patchset, but it seems it's
> >> >> > incomplete.
> >> >>
> >> >> Also it uses scd for metadata filter name, which is bad. It should use
> >> >> full filter name.
> >> >
> >> > Sorry, in fact I intentionally did not use the filter name. At that
> >> > time, I
> >> > considered
> >> > that there may be different filters for scene detection, but for filters
> >> > that use the metadata,
> >> > the processing method should be the same. So I didn't use the filter
> >> > name.
> >>
> >> That is really bad explanation, Different filters writting to same
> >> metadata entry is invalid.
> >
> > Maybe my thoughts isn't complete as I assume user should choose one scene
> > detect filter.
> > One example is facedetect, now we have opencv facedetect, in future, we may
> > add
> > dnn facedetect and even more, for example, the drawbox care for the face
> > detect
> > result instead of which filter detect I think. That's my consideration.
> 
> facedetect is not scene change detection.

It's my consideration only, I'll change it by your request if no other comments.
thx.

> 
> 
> >
> >
> >>
> >> >
> >> >
> >> >>
> >> >> >
> >> >> >>
> >> >> >> Thanks,
> >> >> >> Marton
> >> >> >> ___
> >> >> >> ffmpeg-devel mailing list
> >> >> >> ffmpeg-devel@ffmpeg.org
> >> >> >> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> >> >> >>
> >> >> >> To unsubscribe, visit link above, or email
> >> >> >> ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
> >> >> >
> >> >> > --
> >> >> > Thanks,
> >> >> > Limin Wang
> >> >> > ___
> >> >> > 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".
> >> >
> >> > --
> >> > Thanks,
> >> > Limin Wang
> >> > ___
> >> > ffmpeg-devel mailing list
> >> > ffmpeg-devel@ffmpeg.org
> >> > https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> >> >
> >> > To unsubscribe, visit link above, or email
> >> > ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
> >> _

Re: [FFmpeg-devel] [PATCH v6 2/4] avfilter/vf_framerate: if metadata lavfi.scd.mafd exists, we'll use it first

2020-05-15 Thread Paul B Mahol

On 5/15/20, lance.lmw...@gmail.com  wrote:
> On Fri, May 15, 2020 at 11:27:00AM +0200, Paul B Mahol wrote:
>> On 5/15/20, lance.lmw...@gmail.com  wrote:
>> > On Fri, May 15, 2020 at 10:27:35AM +0200, Paul B Mahol wrote:
>> >> On 5/15/20, lance.lmw...@gmail.com  wrote:
>> >> > On Thu, May 14, 2020 at 09:00:21PM +0200, Marton Balint wrote:
>> >> >>
>> >> >>
>> >> >> On Thu, 14 May 2020, Marton Balint wrote:
>> >> >>
>> >> >> >
>> >> >> >
>> >> >> > On Thu, 14 May 2020, Nicolas George wrote:
>> >> >> >
>> >> >> > > Marton Balint (12020-05-14):
>> >> >> > > > I am not a huge fan of this patch, mafd refers to a score
>> >> >> > > > between this
>> >> >> > frame
>> >> >> > > > and the previous frame, we cannot ensure that there were no
>> >> >> > > > additional
>> >> >> > frame
>> >> >> > > > processing between scdet and this filter which may have
>> >> >> > > > duplicated
>> >> >> > > > or
>> >> >> > > > removed frames. So I'd rather not add this feature.
>> >> >> > >
>> >> >> > > It can only happen if the user has put filters in the middle. I
>> >> >> > > move
>> >> >> > > we
>> >> >> > > trust users who insert such obscure filters to do what they want
>> >> >> > > to,
>> >> >> > > or
>> >> >> > > to fix their issues if they have some.
>> >> >> >
>> >> >> > Fine, I am not blocking this if null pointer deref issues are
>> >> >> > fixed.
>> >> >> >
>> >> >> > I think we can also assume that if the metadata exists, it will
>> >> >> > contain
>> >> >> > a valid number, so I suggest this code:
>> >> >> >
>> >> >> > e_mafd = av_dict_get(next->metadata, "lavfi.scd.mafd",
>> >> >> > NULL,
>> >> >> > AV_DICT_MATCH_CASE);
>> >> >> > if (e_mafd) {
>> >> >> > mafd = strtod(e_mafd->value, NULL);
>> >> >> > } else {
>> >> >> > s->sad(crnt->data[0], crnt->linesize[0],
>> >> >> > next->data[0],
>> >> >> > next->linesize[0], crnt->width, crnt->height, &sad);
>> >> >> > emms_c();
>> >> >> > mafd = (double)sad * 100.0 / (crnt->width *
>> >> >> > crnt->height)
>> >> >> > /
>> >> >> > (1 << s->bitdepth);
>> >> >> > }
>> >> >>
>> >> >> Why this patch was committed without a recent review???
>> >> >
>> >> > Sorry, I consider it's reviewed old patchset, but it seems it's
>> >> > incomplete.
>> >>
>> >> Also it uses scd for metadata filter name, which is bad. It should use
>> >> full filter name.
>> >
>> > Sorry, in fact I intentionally did not use the filter name. At that
>> > time, I
>> > considered
>> > that there may be different filters for scene detection, but for filters
>> > that use the metadata,
>> > the processing method should be the same. So I didn't use the filter
>> > name.
>>
>> That is really bad explanation, Different filters writting to same
>> metadata entry is invalid.
>
> Maybe my thoughts isn't complete as I assume user should choose one scene
> detect filter.
> One example is facedetect, now we have opencv facedetect, in future, we may
> add
> dnn facedetect and even more, for example, the drawbox care for the face
> detect
> result instead of which filter detect I think. That's my consideration.

facedetect is not scene change detection.


>
>
>>
>> >
>> >
>> >>
>> >> >
>> >> >>
>> >> >> Thanks,
>> >> >> Marton
>> >> >> ___
>> >> >> ffmpeg-devel mailing list
>> >> >> ffmpeg-devel@ffmpeg.org
>> >> >> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>> >> >>
>> >> >> To unsubscribe, visit link above, or email
>> >> >> ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
>> >> >
>> >> > --
>> >> > Thanks,
>> >> > Limin Wang
>> >> > ___
>> >> > 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".
>> >
>> > --
>> > Thanks,
>> > Limin Wang
>> > ___
>> > 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".
>
> --
> Thanks,
> Limin Wang
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
> To

Re: [FFmpeg-devel] [PATCH v6 2/4] avfilter/vf_framerate: if metadata lavfi.scd.mafd exists, we'll use it first

2020-05-15 Thread lance . lmwang

On Fri, May 15, 2020 at 11:27:00AM +0200, Paul B Mahol wrote:
> On 5/15/20, lance.lmw...@gmail.com  wrote:
> > On Fri, May 15, 2020 at 10:27:35AM +0200, Paul B Mahol wrote:
> >> On 5/15/20, lance.lmw...@gmail.com  wrote:
> >> > On Thu, May 14, 2020 at 09:00:21PM +0200, Marton Balint wrote:
> >> >>
> >> >>
> >> >> On Thu, 14 May 2020, Marton Balint wrote:
> >> >>
> >> >> >
> >> >> >
> >> >> > On Thu, 14 May 2020, Nicolas George wrote:
> >> >> >
> >> >> > > Marton Balint (12020-05-14):
> >> >> > > > I am not a huge fan of this patch, mafd refers to a score
> >> >> > > > between this
> >> >> > frame
> >> >> > > > and the previous frame, we cannot ensure that there were no
> >> >> > > > additional
> >> >> > frame
> >> >> > > > processing between scdet and this filter which may have
> >> >> > > > duplicated
> >> >> > > > or
> >> >> > > > removed frames. So I'd rather not add this feature.
> >> >> > >
> >> >> > > It can only happen if the user has put filters in the middle. I
> >> >> > > move
> >> >> > > we
> >> >> > > trust users who insert such obscure filters to do what they want
> >> >> > > to,
> >> >> > > or
> >> >> > > to fix their issues if they have some.
> >> >> >
> >> >> > Fine, I am not blocking this if null pointer deref issues are fixed.
> >> >> >
> >> >> > I think we can also assume that if the metadata exists, it will
> >> >> > contain
> >> >> > a valid number, so I suggest this code:
> >> >> >
> >> >> > e_mafd = av_dict_get(next->metadata, "lavfi.scd.mafd", NULL,
> >> >> > AV_DICT_MATCH_CASE);
> >> >> > if (e_mafd) {
> >> >> > mafd = strtod(e_mafd->value, NULL);
> >> >> > } else {
> >> >> > s->sad(crnt->data[0], crnt->linesize[0], next->data[0],
> >> >> > next->linesize[0], crnt->width, crnt->height, &sad);
> >> >> > emms_c();
> >> >> > mafd = (double)sad * 100.0 / (crnt->width * crnt->height)
> >> >> > /
> >> >> > (1 << s->bitdepth);
> >> >> > }
> >> >>
> >> >> Why this patch was committed without a recent review???
> >> >
> >> > Sorry, I consider it's reviewed old patchset, but it seems it's
> >> > incomplete.
> >>
> >> Also it uses scd for metadata filter name, which is bad. It should use
> >> full filter name.
> >
> > Sorry, in fact I intentionally did not use the filter name. At that time, I
> > considered
> > that there may be different filters for scene detection, but for filters
> > that use the metadata,
> > the processing method should be the same. So I didn't use the filter name.
> 
> That is really bad explanation, Different filters writting to same
> metadata entry is invalid.

Maybe my thoughts isn't complete as I assume user should choose one scene 
detect filter.
One example is facedetect, now we have opencv facedetect, in future, we may add
dnn facedetect and even more, for example, the drawbox care for the face detect
result instead of which filter detect I think. That's my consideration.


> 
> >
> >
> >>
> >> >
> >> >>
> >> >> Thanks,
> >> >> Marton
> >> >> ___
> >> >> ffmpeg-devel mailing list
> >> >> ffmpeg-devel@ffmpeg.org
> >> >> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> >> >>
> >> >> To unsubscribe, visit link above, or email
> >> >> ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
> >> >
> >> > --
> >> > Thanks,
> >> > Limin Wang
> >> > ___
> >> > 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".
> >
> > --
> > Thanks,
> > Limin Wang
> > ___
> > 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".

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

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

Re: [FFmpeg-devel] [PATCH v6 2/4] avfilter/vf_framerate: if metadata lavfi.scd.mafd exists, we'll use it first

2020-05-15 Thread Paul B Mahol

On 5/15/20, lance.lmw...@gmail.com  wrote:
> On Fri, May 15, 2020 at 10:27:35AM +0200, Paul B Mahol wrote:
>> On 5/15/20, lance.lmw...@gmail.com  wrote:
>> > On Thu, May 14, 2020 at 09:00:21PM +0200, Marton Balint wrote:
>> >>
>> >>
>> >> On Thu, 14 May 2020, Marton Balint wrote:
>> >>
>> >> >
>> >> >
>> >> > On Thu, 14 May 2020, Nicolas George wrote:
>> >> >
>> >> > > Marton Balint (12020-05-14):
>> >> > > > I am not a huge fan of this patch, mafd refers to a score
>> >> > > > between this
>> >> > frame
>> >> > > > and the previous frame, we cannot ensure that there were no
>> >> > > > additional
>> >> > frame
>> >> > > > processing between scdet and this filter which may have
>> >> > > > duplicated
>> >> > > > or
>> >> > > > removed frames. So I'd rather not add this feature.
>> >> > >
>> >> > > It can only happen if the user has put filters in the middle. I
>> >> > > move
>> >> > > we
>> >> > > trust users who insert such obscure filters to do what they want
>> >> > > to,
>> >> > > or
>> >> > > to fix their issues if they have some.
>> >> >
>> >> > Fine, I am not blocking this if null pointer deref issues are fixed.
>> >> >
>> >> > I think we can also assume that if the metadata exists, it will
>> >> > contain
>> >> > a valid number, so I suggest this code:
>> >> >
>> >> > e_mafd = av_dict_get(next->metadata, "lavfi.scd.mafd", NULL,
>> >> > AV_DICT_MATCH_CASE);
>> >> > if (e_mafd) {
>> >> > mafd = strtod(e_mafd->value, NULL);
>> >> > } else {
>> >> > s->sad(crnt->data[0], crnt->linesize[0], next->data[0],
>> >> > next->linesize[0], crnt->width, crnt->height, &sad);
>> >> > emms_c();
>> >> > mafd = (double)sad * 100.0 / (crnt->width * crnt->height)
>> >> > /
>> >> > (1 << s->bitdepth);
>> >> > }
>> >>
>> >> Why this patch was committed without a recent review???
>> >
>> > Sorry, I consider it's reviewed old patchset, but it seems it's
>> > incomplete.
>>
>> Also it uses scd for metadata filter name, which is bad. It should use
>> full filter name.
>
> Sorry, in fact I intentionally did not use the filter name. At that time, I
> considered
> that there may be different filters for scene detection, but for filters
> that use the metadata,
> the processing method should be the same. So I didn't use the filter name.

That is really bad explanation, Different filters writting to same
metadata entry is invalid.

>
>
>>
>> >
>> >>
>> >> Thanks,
>> >> Marton
>> >> ___
>> >> ffmpeg-devel mailing list
>> >> ffmpeg-devel@ffmpeg.org
>> >> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>> >>
>> >> To unsubscribe, visit link above, or email
>> >> ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
>> >
>> > --
>> > Thanks,
>> > Limin Wang
>> > ___
>> > 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".
>
> --
> Thanks,
> Limin Wang
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
> To unsubscribe, visit link above, or email
> ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

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

Re: [FFmpeg-devel] [PATCH v6 2/4] avfilter/vf_framerate: if metadata lavfi.scd.mafd exists, we'll use it first

2020-05-15 Thread lance . lmwang

On Fri, May 15, 2020 at 10:27:35AM +0200, Paul B Mahol wrote:
> On 5/15/20, lance.lmw...@gmail.com  wrote:
> > On Thu, May 14, 2020 at 09:00:21PM +0200, Marton Balint wrote:
> >>
> >>
> >> On Thu, 14 May 2020, Marton Balint wrote:
> >>
> >> >
> >> >
> >> > On Thu, 14 May 2020, Nicolas George wrote:
> >> >
> >> > > Marton Balint (12020-05-14):
> >> > > > I am not a huge fan of this patch, mafd refers to a score
> >> > > > between this
> >> > frame
> >> > > > and the previous frame, we cannot ensure that there were no
> >> > > > additional
> >> > frame
> >> > > > processing between scdet and this filter which may have duplicated
> >> > > > or
> >> > > > removed frames. So I'd rather not add this feature.
> >> > >
> >> > > It can only happen if the user has put filters in the middle. I move
> >> > > we
> >> > > trust users who insert such obscure filters to do what they want to,
> >> > > or
> >> > > to fix their issues if they have some.
> >> >
> >> > Fine, I am not blocking this if null pointer deref issues are fixed.
> >> >
> >> > I think we can also assume that if the metadata exists, it will contain
> >> > a valid number, so I suggest this code:
> >> >
> >> > e_mafd = av_dict_get(next->metadata, "lavfi.scd.mafd", NULL,
> >> > AV_DICT_MATCH_CASE);
> >> > if (e_mafd) {
> >> > mafd = strtod(e_mafd->value, NULL);
> >> > } else {
> >> > s->sad(crnt->data[0], crnt->linesize[0], next->data[0],
> >> > next->linesize[0], crnt->width, crnt->height, &sad);
> >> > emms_c();
> >> > mafd = (double)sad * 100.0 / (crnt->width * crnt->height) /
> >> > (1 << s->bitdepth);
> >> > }
> >>
> >> Why this patch was committed without a recent review???
> >
> > Sorry, I consider it's reviewed old patchset, but it seems it's incomplete.
> 
> Also it uses scd for metadata filter name, which is bad. It should use
> full filter name.

Sorry, in fact I intentionally did not use the filter name. At that time, I 
considered
that there may be different filters for scene detection, but for filters that 
use the metadata,
the processing method should be the same. So I didn't use the filter name.


> 
> >
> >>
> >> Thanks,
> >> Marton
> >> ___
> >> ffmpeg-devel mailing list
> >> ffmpeg-devel@ffmpeg.org
> >> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> >>
> >> To unsubscribe, visit link above, or email
> >> ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
> >
> > --
> > Thanks,
> > Limin Wang
> > ___
> > 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".

-- 
Thanks,
Limin Wang
___
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] swscale: aarch64: Add a NEON implementation of interleaveBytes

2020-05-15 Thread Martin Storsjö

This allows speeding up format conversions from yuv420 to nv12.

 Cortex A53  A72  A73
interleave_bytes_c: 86077.5  51433.0  66972.0
interleave_bytes_neon:  19701.7  23019.2  15859.2
interleave_bytes_aligned_c: 86603.0  52017.2  67484.2
interleave_bytes_aligned_neon:   9061.0   7623.0   6309.0
---
 libswscale/aarch64/Makefile   |  4 +-
 libswscale/aarch64/rgb2rgb.c  | 41 
 libswscale/aarch64/rgb2rgb_neon.S | 79 +++
 libswscale/rgb2rgb.c  |  2 +
 libswscale/rgb2rgb.h  |  1 +
 5 files changed, 126 insertions(+), 1 deletion(-)
 create mode 100644 libswscale/aarch64/rgb2rgb.c
 create mode 100644 libswscale/aarch64/rgb2rgb_neon.S

diff --git a/libswscale/aarch64/Makefile b/libswscale/aarch64/Makefile
index 64a3fe208d..da1d909561 100644
--- a/libswscale/aarch64/Makefile
+++ b/libswscale/aarch64/Makefile
@@ -1,6 +1,8 @@
-OBJS+= aarch64/swscale.o\
+OBJS+= aarch64/rgb2rgb.o\
+   aarch64/swscale.o\
aarch64/swscale_unscaled.o   \
 
 NEON-OBJS   += aarch64/hscale.o \
aarch64/output.o \
+   aarch64/rgb2rgb_neon.o   \
aarch64/yuv2rgb_neon.o   \
diff --git a/libswscale/aarch64/rgb2rgb.c b/libswscale/aarch64/rgb2rgb.c
new file mode 100644
index 00..a9bf6ff9e0
--- /dev/null
+++ b/libswscale/aarch64/rgb2rgb.c
@@ -0,0 +1,41 @@
+/*
+ * This file is part of FFmpeg.
+ *
+ * FFmpeg is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public
+ * License as published by the Free Software Foundation; either
+ * version 2.1 of the License, or (at your option) any later version.
+ *
+ * FFmpeg is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+ * Lesser General Public License for more details.
+ *
+ * You should have received a copy of the GNU Lesser General Public
+ * License along with FFmpeg; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA
+ */
+
+#include 
+
+#include "config.h"
+#include "libavutil/attributes.h"
+#include "libavutil/aarch64/cpu.h"
+#include "libavutil/cpu.h"
+#include "libavutil/bswap.h"
+#include "libswscale/rgb2rgb.h"
+#include "libswscale/swscale.h"
+#include "libswscale/swscale_internal.h"
+
+void ff_interleave_bytes_neon(const uint8_t *src1, const uint8_t *src2,
+  uint8_t *dest, int width, int height,
+  int src1Stride, int src2Stride, int dstStride);
+
+av_cold void rgb2rgb_init_aarch64(void)
+{
+int cpu_flags = av_get_cpu_flags();
+
+if (have_neon(cpu_flags)) {
+interleaveBytes = ff_interleave_bytes_neon;
+}
+}
diff --git a/libswscale/aarch64/rgb2rgb_neon.S 
b/libswscale/aarch64/rgb2rgb_neon.S
new file mode 100644
index 00..d8b282b6a5
--- /dev/null
+++ b/libswscale/aarch64/rgb2rgb_neon.S
@@ -0,0 +1,79 @@
+/*
+ * Copyright (c) 2020 Martin Storsjo
+ *
+ * This file is part of FFmpeg.
+ *
+ * FFmpeg is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public
+ * License as published by the Free Software Foundation; either
+ * version 2.1 of the License, or (at your option) any later version.
+ *
+ * FFmpeg is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+ * Lesser General Public License for more details.
+ *
+ * You should have received a copy of the GNU Lesser General Public
+ * License along with FFmpeg; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA
+ */
+
+#include "libavutil/aarch64/asm.S"
+
+// void ff_interleave_bytes_neon(const uint8_t *src1, const uint8_t *src2,
+//   uint8_t *dest, int width, int height,
+//   int src1Stride, int src2Stride, int 
dstStride);
+function ff_interleave_bytes_neon, export=1
+sub w5,  w5,  w3
+sub w6,  w6,  w3
+sub w7,  w7,  w3, lsl #1
+1:
+andsw8,  w3,  #0xfff0 // & ~15
+b.eq3f
+2:
+ld1 {v0.16b}, [x0], #16
+ld1 {v1.16b}, [x1], #16
+subsw8,  w8,  #16
+st2 {v0.16b, v1.16b}, [x2], #32
+b.gt2b
+
+tst w3,  #15
+b.eq9f
+
+3:
+tst w3,  #8
+b.eq4f
+ld1 {v0.8b}, [x0], #8
+ld1 {v1.8b}, [x1

[FFmpeg-devel] [PATCH 1/2] checkasm: sw_rgb: Add a test for interleaveBytes

2020-05-15 Thread Martin Storsjö

---
This depends on "checkasm: Add functions for printing pixel buffers".

The existing x86 implementations of interleaveBytes seem to slow
down significantly for unaligned copies (GCC 7.5, Sandy Bridge):

interleave_bytes_c:  36251.6
interleave_bytes_mmx:10038.8
interleave_bytes_mmxext: 58450.3
interleave_bytes_sse2:   57746.3

For the properly aligned case, it behaves better:

interleave_bytes_aligned_c: 36109.8
interleave_bytes_aligned_mmx:6033.8
interleave_bytes_aligned_mmxext: 6473.1
interleave_bytes_aligned_sse2:   6163.1

But Clang (in Xcode 11.3, run on Kaby Lake) seems to beat all the asm
implementations, in its (autovectorized?) C version:

interleave_bytes_c:   9893.0
interleave_bytes_mmx:23153.5
interleave_bytes_mmxext: 43693.8
interleave_bytes_sse2:   55894.8

interleave_bytes_aligned_c:  3456.0
interleave_bytes_aligned_mmx:5780.0
interleave_bytes_aligned_mmxext: 4913.8
interleave_bytes_aligned_sse2:   4154.3
---
 tests/checkasm/sw_rgb.c | 53 +
 1 file changed, 53 insertions(+)

diff --git a/tests/checkasm/sw_rgb.c b/tests/checkasm/sw_rgb.c
index 000420d8f7..41c486a2d7 100644
--- a/tests/checkasm/sw_rgb.c
+++ b/tests/checkasm/sw_rgb.c
@@ -111,6 +111,56 @@ static void check_uyvy_to_422p(void)
 }
 }
 
+static void check_interleave_bytes(void)
+{
+LOCAL_ALIGNED_16(uint8_t, src0_buf, [MAX_STRIDE*MAX_HEIGHT+1]);
+LOCAL_ALIGNED_16(uint8_t, src1_buf, [MAX_STRIDE*MAX_HEIGHT+1]);
+LOCAL_ALIGNED_16(uint8_t, dst0_buf, [2*MAX_STRIDE*MAX_HEIGHT+2]);
+LOCAL_ALIGNED_16(uint8_t, dst1_buf, [2*MAX_STRIDE*MAX_HEIGHT+2]);
+// Intentionally using unaligned buffers, as this function doesn't have
+// any alignment requirements.
+uint8_t *src0 = src0_buf + 1;
+uint8_t *src1 = src1_buf + 1;
+uint8_t *dst0 = dst0_buf + 2;
+uint8_t *dst1 = dst1_buf + 2;
+
+declare_func_emms(AV_CPU_FLAG_MMX, void, const uint8_t *, const uint8_t *,
+   uint8_t *, int, int, int, int, int);
+
+randomize_buffers(src0, MAX_STRIDE * MAX_HEIGHT);
+randomize_buffers(src1, MAX_STRIDE * MAX_HEIGHT);
+
+if (check_func(interleaveBytes, "interleave_bytes")) {
+for (int i = 0; i <= 16; i++) {
+// Try all widths [1,16], and try one random width.
+
+int w = i > 0 ? i : (1 + (rnd() % (MAX_STRIDE-2)));
+int h = 1 + (rnd() % (MAX_HEIGHT-2));
+
+memset(dst0, 0, 2 * MAX_STRIDE * MAX_HEIGHT);
+memset(dst1, 0, 2 * MAX_STRIDE * MAX_HEIGHT);
+
+call_ref(src0, src1, dst0, w, h,
+ MAX_STRIDE, MAX_STRIDE, 2*MAX_STRIDE);
+call_new(src0, src1, dst1, w, h,
+ MAX_STRIDE, MAX_STRIDE, 2*MAX_STRIDE);
+// Check a one pixel-pair edge around the destination area,
+// to catch overwrites past the end.
+checkasm_check(uint8_t, dst0, 2*MAX_STRIDE, dst1, 2*MAX_STRIDE,
+   2 * w + 2, h + 1, "dst");
+}
+
+bench_new(src0, src1, dst1, 127, MAX_HEIGHT,
+  MAX_STRIDE, MAX_STRIDE, 2*MAX_STRIDE);
+}
+if (check_func(interleaveBytes, "interleave_bytes_aligned")) {
+// Bench the function in a more typical case, with aligned
+// buffers and widths.
+bench_new(src0_buf, src1_buf, dst1_buf, 128, MAX_HEIGHT,
+  MAX_STRIDE, MAX_STRIDE, 2*MAX_STRIDE);
+}
+}
+
 void checkasm_check_sw_rgb(void)
 {
 ff_sws_rgb2rgb_init();
@@ -132,4 +182,7 @@ void checkasm_check_sw_rgb(void)
 
 check_uyvy_to_422p();
 report("uyvytoyuv422");
+
+check_interleave_bytes();
+report("interleave_bytes");
 }
-- 
2.17.1

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

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

Re: [FFmpeg-devel] [PATCH v3] checkasm: add hscale test

2020-05-15 Thread Martin Storsjö


On Thu, 14 May 2020, Josh de Kock wrote:


This tests the hscale 8bpp to 14bpp functions with different filter
sizes.

Signed-off-by: Josh de Kock 
---

Adds support for checking corner cases for signed and large
coefficients. Also makes the padded coefficients random data.

Tested on x86_64 and aarch64.

tests/checkasm/Makefile   |   2 +-
tests/checkasm/checkasm.c |   1 +
tests/checkasm/checkasm.h |   1 +
tests/checkasm/sw_scale.c | 134 ++
4 files changed, 137 insertions(+), 1 deletion(-)
create mode 100644 tests/checkasm/sw_scale.c


I forgot to point out, this is missing an addition to 
tests/fate/checkasm.mak - as the tests are run in separate checkasm 
invocations, we need to add new tests groups there, otherwise they aren't 
run as part of "make fate".


// Martin

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

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

Re: [FFmpeg-devel] [PATCH v6 1/4] avfilter/vf_scdet: add filter to detect scene change

2020-05-15 Thread Paul B Mahol

On 5/14/20, lance.lmw...@gmail.com  wrote:
> From: Limin Wang 
>
> Reviewed-by: Paul B Mahol 

Please use full filter name when exporting metadata to rest of filtergraph.

> Signed-off-by: Limin Wang 
> ---
> rebase with master and update the version and Changelog
>
>  Changelog|   1 +
>  configure|   1 +
>  doc/filters.texi |  35 
>  libavfilter/Makefile |   1 +
>  libavfilter/allfilters.c |   1 +
>  libavfilter/version.h|   2 +-
>  libavfilter/vf_scdet.c   | 224
> +++
>  7 files changed, 264 insertions(+), 1 deletion(-)
>  create mode 100644 libavfilter/vf_scdet.c
>
> diff --git a/Changelog b/Changelog
> index b75d2b6..f56674f 100644
> --- a/Changelog
> +++ b/Changelog
> @@ -66,6 +66,7 @@ version :
>  - asubboost filter
>  - Pro Pinball Series Soundbank demuxer
>  - pcm_rechunk bitstream filter
> +- scdet filter
>
>
>  version 4.2:
> diff --git a/configure b/configure
> index a45c0fb..34afdaa 100755
> --- a/configure
> +++ b/configure
> @@ -3569,6 +3569,7 @@ sab_filter_deps="gpl swscale"
>  scale2ref_filter_deps="swscale"
>  scale_filter_deps="swscale"
>  scale_qsv_filter_deps="libmfx"
> +scdet_filter_select="scene_sad"
>  select_filter_select="scene_sad"
>  sharpness_vaapi_filter_deps="vaapi"
>  showcqt_filter_deps="avcodec avformat swscale"
> diff --git a/doc/filters.texi b/doc/filters.texi
> index d19fd34..a3e78b1 100644
> --- a/doc/filters.texi
> +++ b/doc/filters.texi
> @@ -16578,6 +16578,41 @@ Set the horizontal scrolling speed.
>  Set the vertical scrolling speed.
>  @end table
>
> +@anchor{scdet}
> +@section scdet
> +
> +Detect video scene change.
> +
> +This filter sets frame metadata with mafd between frame, the scene score,
> and
> +forward the frame to the next filter, so they can use these metadata to
> detect
> +scene change or others.
> +
> +In addition, this filter logs a message and sets frame metadata when it
> detects
> +a scene change by @option{threshold}.
> +
> +@code{lavfi.scd.mafd} metadata keys are set with mafd for every frame.
> +
> +@code{lavfi.scd.score} metadata keys are set with scene change score for
> every frame
> +to detect scene change.
> +
> +@code{lavfi.scd.time} metadata keys are set with current filtered frame
> time which
> +detect scene change with @option{threshold}.
> +
> +The filter accepts the following options:
> +
> +@table @option
> +@item threshold, t
> +Set the scene change detection threshold as a percentage of maximum change.
> Good
> +values are in the @code{[8.0, 14.0]} range. The range for
> @option{threshold} is
> +@code{[0., 100.]}.
> +
> +Default value is @code{10.}.
> +
> +@item sc_pass, s
> +Set the flag to pass scene change frames to the next filter. Default value
> is @code{0}
> +You can enable it if you want to get snapshot of scene change frames only.
> +@end table
> +
>  @anchor{selectivecolor}
>  @section selectivecolor
>
> diff --git a/libavfilter/Makefile b/libavfilter/Makefile
> index f982afe..b2086f6 100644
> --- a/libavfilter/Makefile
> +++ b/libavfilter/Makefile
> @@ -376,6 +376,7 @@ OBJS-$(CONFIG_SCALE_QSV_FILTER)  +=
> vf_scale_qsv.o
>  OBJS-$(CONFIG_SCALE_VAAPI_FILTER)+= vf_scale_vaapi.o
> scale_eval.o vaapi_vpp.o
>  OBJS-$(CONFIG_SCALE_VULKAN_FILTER)   += vf_scale_vulkan.o vulkan.o
>  OBJS-$(CONFIG_SCALE2REF_FILTER)  += vf_scale.o scale_eval.o
> +OBJS-$(CONFIG_SCDET_FILTER)  += vf_scdet.o
>  OBJS-$(CONFIG_SCROLL_FILTER) += vf_scroll.o
>  OBJS-$(CONFIG_SELECT_FILTER) += f_select.o
>  OBJS-$(CONFIG_SELECTIVECOLOR_FILTER) += vf_selectivecolor.o
> diff --git a/libavfilter/allfilters.c b/libavfilter/allfilters.c
> index 1b94501..8830c8d 100644
> --- a/libavfilter/allfilters.c
> +++ b/libavfilter/allfilters.c
> @@ -358,6 +358,7 @@ extern AVFilter ff_vf_scale_qsv;
>  extern AVFilter ff_vf_scale_vaapi;
>  extern AVFilter ff_vf_scale_vulkan;
>  extern AVFilter ff_vf_scale2ref;
> +extern AVFilter ff_vf_scdet;
>  extern AVFilter ff_vf_scroll;
>  extern AVFilter ff_vf_select;
>  extern AVFilter ff_vf_selectivecolor;
> diff --git a/libavfilter/version.h b/libavfilter/version.h
> index c0d4966..8bb22c3 100644
> --- a/libavfilter/version.h
> +++ b/libavfilter/version.h
> @@ -30,7 +30,7 @@
>  #include "libavutil/version.h"
>
>  #define LIBAVFILTER_VERSION_MAJOR   7
> -#define LIBAVFILTER_VERSION_MINOR  80
> +#define LIBAVFILTER_VERSION_MINOR  81
>  #define LIBAVFILTER_VERSION_MICRO 100
>
>
> diff --git a/libavfilter/vf_scdet.c b/libavfilter/vf_scdet.c
> new file mode 100644
> index 000..b91d91f
> --- /dev/null
> +++ b/libavfilter/vf_scdet.c
> @@ -0,0 +1,224 @@
> +/*
> + * This file is part of FFmpeg.
> + *
> + * FFmpeg is free software; you can redistribute it and/or
> + * modify it under the terms of the GNU Lesser General Public
> + * License as published by the Free Software Foundation; either
> + * version 2.1 of the License, or (at your op

Re: [FFmpeg-devel] [PATCH v6 2/4] avfilter/vf_framerate: if metadata lavfi.scd.mafd exists, we'll use it first

2020-05-15 Thread Paul B Mahol

On 5/15/20, lance.lmw...@gmail.com  wrote:
> On Thu, May 14, 2020 at 09:00:21PM +0200, Marton Balint wrote:
>>
>>
>> On Thu, 14 May 2020, Marton Balint wrote:
>>
>> >
>> >
>> > On Thu, 14 May 2020, Nicolas George wrote:
>> >
>> > > Marton Balint (12020-05-14):
>> > > > I am not a huge fan of this patch, mafd refers to a score
>> > > > between this
>> > frame
>> > > > and the previous frame, we cannot ensure that there were no
>> > > > additional
>> > frame
>> > > > processing between scdet and this filter which may have duplicated
>> > > > or
>> > > > removed frames. So I'd rather not add this feature.
>> > >
>> > > It can only happen if the user has put filters in the middle. I move
>> > > we
>> > > trust users who insert such obscure filters to do what they want to,
>> > > or
>> > > to fix their issues if they have some.
>> >
>> > Fine, I am not blocking this if null pointer deref issues are fixed.
>> >
>> > I think we can also assume that if the metadata exists, it will contain
>> > a valid number, so I suggest this code:
>> >
>> > e_mafd = av_dict_get(next->metadata, "lavfi.scd.mafd", NULL,
>> > AV_DICT_MATCH_CASE);
>> > if (e_mafd) {
>> > mafd = strtod(e_mafd->value, NULL);
>> > } else {
>> > s->sad(crnt->data[0], crnt->linesize[0], next->data[0],
>> > next->linesize[0], crnt->width, crnt->height, &sad);
>> > emms_c();
>> > mafd = (double)sad * 100.0 / (crnt->width * crnt->height) /
>> > (1 << s->bitdepth);
>> > }
>>
>> Why this patch was committed without a recent review???
>
> Sorry, I consider it's reviewed old patchset, but it seems it's incomplete.

Also it uses scd for metadata filter name, which is bad. It should use
full filter name.

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

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

Re: [FFmpeg-devel] [PATCH, v2 1/2] lavc/qsvdec: add decode support for HEVC 4:2:2 8-bit and 10-bit

2020-05-15 Thread Max Dmitrichenko

On Fri, May 15, 2020 at 9:06 AM Fu, Linjie  wrote:

> > From: ffmpeg-devel  On Behalf Of
> > Artem Galin
> > Sent: Tuesday, April 28, 2020 00:26
> > To: FFmpeg development discussions and patches  > de...@ffmpeg.org>
> > Cc: Zhong Li 
> > Subject: Re: [FFmpeg-devel] [PATCH, v2 1/2] lavc/qsvdec: add decode
> > support for HEVC 4:2:2 8-bit and 10-bit
> >
> > On Wed, 15 Apr 2020 at 05:02, Fu, Linjie  wrote:
> >
> > > > From: Zhong Li 
> > > > Sent: Wednesday, April 15, 2020 09:58
> > > > To: FFmpeg development discussions and patches  > > > de...@ffmpeg.org>
> > > > Cc: Fu, Linjie 
> > > > Subject: Re: [FFmpeg-devel] [PATCH, v2 1/2] lavc/qsvdec: add decode
> > > > support for HEVC 4:2:2 8-bit and 10-bit
> > > >
> > > > Linjie Fu  于2020年2月26日周三 下午4:43写道：
> > > > >
> > > > > Enables HEVC Range Extension decoding support (Linux) for 4:2:2
> 8/10
> > > bit
> > > > > on ICL+ (gen11 +) platform.
> > > > >
> > > > > Signed-off-by: Linjie Fu 
> > > > > ---
> > > > > [v2]: restrict to support on Linux.
> > > > >
> > > > >  libavcodec/qsv.c  | 16 
> > > > >  libavutil/hwcontext_qsv.c | 24 
> > > > >  2 files changed, 40 insertions(+)
> > > > >
> > > > > diff --git a/libavcodec/qsv.c b/libavcodec/qsv.c
> > > > > index db98c75..171a8d6 100644
> > > > > --- a/libavcodec/qsv.c
> > > > > +++ b/libavcodec/qsv.c
> > > > > @@ -195,6 +195,12 @@ enum AVPixelFormat
> > ff_qsv_map_fourcc(uint32_t
> > > > fourcc)
> > > > >  case MFX_FOURCC_NV12: return AV_PIX_FMT_NV12;
> > > > >  case MFX_FOURCC_P010: return AV_PIX_FMT_P010;
> > > > >  case MFX_FOURCC_P8:   return AV_PIX_FMT_PAL8;
> > > > > +#if CONFIG_VAAPI
> > >
> > LGTM. CONFIG_VAAPI is not needed here because crash does not related to
> > these changes.
> > Full support MFX_FOURCC_YUY2 is WIP for Windows.
> >
> > > > > +case MFX_FOURCC_YUY2: return AV_PIX_FMT_YUYV422;
> > > >
> > > > There is no VAAPI structures here, so should not use CONFIG_VAAPI to
> > > > disable them.
> > > >
> > >
> > > This is pointed out in [1] that D3D code doesn't support YUYV format,
> and
> > > indeed
> > > It leads to unexpected crash in windows.(instead of working or
> reporting
> > > unsupported
> > > On ICL- platform)
> > >
> > > Hence this patch restricted to add support on linux only.
> > >
> > > And I admit the best solution should be get this fully supported on
> both
> > > linux and windows.
> > > (I believe Max and Artem is helping on windows side)
> > >
> > > Thanks for the review,
> > > Linjie
> > >
> > > [1]
> > > https://patchwork.ffmpeg.org/project/ffmpeg/patch/1582596080-1035-1-
> > git-send-email-linjie...@intel.com/
>
> Synced with Zhong, will keep the restriction for now and apply this set
> soon. (if no objections)
>
>
it make sense, as patch is clearly Linux focused



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



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

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

Re: [FFmpeg-devel] [PATCH 4/4] vaapi_encode_h265: Enable 4:2:2 support

2020-05-15 Thread Fu, Linjie

> From: ffmpeg-devel  On Behalf Of
> Mark Thompson
> Sent: Sunday, March 8, 2020 00:15
> To: ffmpeg-devel@ffmpeg.org
> Subject: Re: [FFmpeg-devel] [PATCH 4/4] vaapi_encode_h265: Enable 4:2:2
> support
> 
> On 05/03/2020 02:49, Fu, Linjie wrote:
> > 2. recon surface of Y210 or 444 (AYUV and Y410 in media-driver) depends
> on the surface hint [3] in
> > libva and corresponding code in media-driver to resize the recon surface
> which is not upstreamed
> > yet.
> 
> What is the reasoning for forcing the user to pass new extra attributes with
> this rather than handling it transparently so that it works like all other
> encoders?
> 
> In some places in Mesa surfaces are reallocated with different properties
> when they are used for a purpose they don't currently support, which avoids
> weird constraints being exported to the user (e.g. see
>  a/surface.c#n1000>).  Since reconstructed picture surfaces are pretty unlikely
> to be used for anything else (just being copied out for debugging maybe?), it
> seems like an answer like that would be simpler in this case too.  (Though
> perhaps I'm missing something weird about the Intel hardware which makes
> this case uglier.)
> 

Implemented the surface reallocation inside media driver in [1], merged the 
query
support in [2],  verified that it works for both AYUV(or XYUV)/Y410, yuyv422.

And for Y210, it seems to be better to implement render target support in
vaapi_encoder in this patch as well:
{ "YUV422_10", VA_RT_FORMAT_YUV422_10,10, 3, 1, 0 },

Hence patch LGTM with or without above modifications, thx.

- Linjie

[1] < https://github.com/intel/media-driver/pull/915>
[2] < https://github.com/intel/media-driver/pull/855>

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

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

Re: [FFmpeg-devel] [PATCH v3] checkasm: add hscale test

2020-05-15 Thread Martin Storsjö


On Thu, 14 May 2020, Josh de Kock wrote:


This tests the hscale 8bpp to 14bpp functions with different filter
sizes.


^ 8bpp to 14, and to 18, right?


Signed-off-by: Josh de Kock 
---

Adds support for checking corner cases for signed and large
coefficients. Also makes the padded coefficients random data.

Tested on x86_64 and aarch64.




+for (j = 0; j < width; j++) {
+filter[i * width + j] = -((1 << 14) / (width - 1));
+}
+filter[i * width + (rnd() % (width - 1))] = ((1 << 15) - 1);


Actually, shouldn't this be i*width + (rnd() % width)?

LGTM with that addressed.

// Martin

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

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

Re: [FFmpeg-devel] [PATCH, v2 1/2] lavc/qsvdec: add decode support for HEVC 4:2:2 8-bit and 10-bit

2020-05-15 Thread Fu, Linjie

> From: ffmpeg-devel  On Behalf Of
> Artem Galin
> Sent: Tuesday, April 28, 2020 00:26
> To: FFmpeg development discussions and patches  de...@ffmpeg.org>
> Cc: Zhong Li 
> Subject: Re: [FFmpeg-devel] [PATCH, v2 1/2] lavc/qsvdec: add decode
> support for HEVC 4:2:2 8-bit and 10-bit
> 
> On Wed, 15 Apr 2020 at 05:02, Fu, Linjie  wrote:
> 
> > > From: Zhong Li 
> > > Sent: Wednesday, April 15, 2020 09:58
> > > To: FFmpeg development discussions and patches  > > de...@ffmpeg.org>
> > > Cc: Fu, Linjie 
> > > Subject: Re: [FFmpeg-devel] [PATCH, v2 1/2] lavc/qsvdec: add decode
> > > support for HEVC 4:2:2 8-bit and 10-bit
> > >
> > > Linjie Fu  于2020年2月26日周三 下午4:43写道：
> > > >
> > > > Enables HEVC Range Extension decoding support (Linux) for 4:2:2 8/10
> > bit
> > > > on ICL+ (gen11 +) platform.
> > > >
> > > > Signed-off-by: Linjie Fu 
> > > > ---
> > > > [v2]: restrict to support on Linux.
> > > >
> > > >  libavcodec/qsv.c  | 16 
> > > >  libavutil/hwcontext_qsv.c | 24 
> > > >  2 files changed, 40 insertions(+)
> > > >
> > > > diff --git a/libavcodec/qsv.c b/libavcodec/qsv.c
> > > > index db98c75..171a8d6 100644
> > > > --- a/libavcodec/qsv.c
> > > > +++ b/libavcodec/qsv.c
> > > > @@ -195,6 +195,12 @@ enum AVPixelFormat
> ff_qsv_map_fourcc(uint32_t
> > > fourcc)
> > > >  case MFX_FOURCC_NV12: return AV_PIX_FMT_NV12;
> > > >  case MFX_FOURCC_P010: return AV_PIX_FMT_P010;
> > > >  case MFX_FOURCC_P8:   return AV_PIX_FMT_PAL8;
> > > > +#if CONFIG_VAAPI
> >
> LGTM. CONFIG_VAAPI is not needed here because crash does not related to
> these changes.
> Full support MFX_FOURCC_YUY2 is WIP for Windows.
> 
> > > > +case MFX_FOURCC_YUY2: return AV_PIX_FMT_YUYV422;
> > >
> > > There is no VAAPI structures here, so should not use CONFIG_VAAPI to
> > > disable them.
> > >
> >
> > This is pointed out in [1] that D3D code doesn't support YUYV format, and
> > indeed
> > It leads to unexpected crash in windows.(instead of working or reporting
> > unsupported
> > On ICL- platform)
> >
> > Hence this patch restricted to add support on linux only.
> >
> > And I admit the best solution should be get this fully supported on both
> > linux and windows.
> > (I believe Max and Artem is helping on windows side)
> >
> > Thanks for the review,
> > Linjie
> >
> > [1]
> > https://patchwork.ffmpeg.org/project/ffmpeg/patch/1582596080-1035-1-
> git-send-email-linjie...@intel.com/

Synced with Zhong, will keep the restriction for now and apply this set soon. 
(if no objections)

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

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

Re: [FFmpeg-devel] [PATCH v2] avcodec: Add MediaFoundation encoder wrapper

2020-05-15 Thread Martin Storsjö


On Tue, 12 May 2020, Martin Storsjö wrote:


From: wm4 

This contains encoder wrappers for H264, HEVC, AAC, AC3 and MP3.

This is based on top of an original patch by wm4
. The original patch supported both encoding
and decoding, but this patch only includes encoding.

The patch contains further changes by Paweł Wegner
 (primarily for splitting out the encoding
parts of the original patch) and further cleanup, build compatibility
fixes and tweaks for use with Qualcomm encoders by Martin Storsjö.
---
v2: Added AV_CODEC_CAP_HYBRID, removed a leftover unused AVBSFContext,
added changelog and encoders.text entries, renamed the configure option
and config item to "mediafoundation" instead of "mf", changed the
makefile to keep individual additions of object files for each
individual encoder (so that it isn't compiled if all encoders are
disabled, even if CONFIG_MEDIAFOUNDATION is enabled).


Any further comments on this, or is it ok to be merged now?

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

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

46 matches

Mail list logo