Re: [FFmpeg-devel] [PATCH] avfilter: add colorhold filter

[Nicolas George]

Paul B Mahol (12019-05-11):
> 7 days passed, nobody voted against. So I will apply this filter soon.

Two people have objected to the vote itself. That is more than one.
Please realize you are using intimidation techniques that have
absolutely no place in a project like this one. If you insist on
legitimizing an invalid vote, then I will act on the fake invalid vote
that I posted.

Ask, politely, that somebody review this patch. That is easy.

-- 
  Nicolas George


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

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

Re: [FFmpeg-devel] [PATCH] avfilter: add colorhold filter

[Nicolas George]

Paul B Mahol (12019-05-11):
> I will kindly and slowly going to apply this splendid patch very soon.

By doing so, you will acknowledge that you do not respect the rules of
the project and of cooperation. As a consequence, you forfeit any right
to complain if these rules are not followed when it comes to you. And I
can assure you that I will not hesitate to make use of that forfeiture
to revert any patch from you that I do not like.

At this point, I almost hope that you will follow through and give me
that power on a platter. But I will only say this: if you spent half as
much effort to try to work WITH the people here as you spent to try to
work AGAINST us, you would achieve much more.

> If you want to object this patch inclusion into main FFmpeg tree than
> kindly review it.

You have a lot of nerve to ask something like that from somebody you
insulted a few days ago. I refuse. And I will revert this patch if it is
applied without following the rules.

-- 
  Nicolas George


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

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

Re: [FFmpeg-devel] [PATCH] ffplay: added option always on top for video window

[Michael Niedermayer]

On Fri, May 10, 2019 at 12:12:17PM +0200, Daniel Kucera wrote:
> From: Daniel Kucera 
> 
> Signed-off-by: Daniel Kucera 
> ---
>  doc/ffplay.texi  | 2 ++
>  fftools/ffplay.c | 4 
>  2 files changed, 6 insertions(+)
> 
> diff --git a/doc/ffplay.texi b/doc/ffplay.texi
> index c305465078..a37c02dc0d 100644
> --- a/doc/ffplay.texi
> +++ b/doc/ffplay.texi
> @@ -66,6 +66,8 @@ Set custom interval, in seconds, for seeking using 
> left/right keys. Default is 1
>  Disable graphical display.
>  @item -noborder
>  Borderless window.
> +@item -alwaysontop
> +Window always on top.
>  @item -volume
>  Set the startup volume. 0 means silence, 100 means no volume reduction or
>  amplification. Negative values are treated as 0, values above 100 are treated
> diff --git a/fftools/ffplay.c b/fftools/ffplay.c
> index 8f050e16e6..931dc08e2d 100644
> --- a/fftools/ffplay.c
> +++ b/fftools/ffplay.c
> @@ -324,6 +324,7 @@ static int seek_by_bytes = -1;
>  static float seek_interval = 10;
>  static int display_disable;
>  static int borderless;
> +static int alwaysontop;
>  static int startup_volume = 100;
>  static int show_status = 1;
>  static int av_sync_type = AV_SYNC_AUDIO_MASTER;
> @@ -3581,6 +3582,7 @@ static const OptionDef options[] = {
>  { "seek_interval", OPT_FLOAT | HAS_ARG, { _interval }, "set seek 
> interval for left/right keys, in seconds", "seconds" },
>  { "nodisp", OPT_BOOL, { _disable }, "disable graphical display" 
> },
>  { "noborder", OPT_BOOL, {  }, "borderless window" },
> +{ "alwaysontop", OPT_BOOL, {  }, "window always on top" },
>  { "volume", OPT_INT | HAS_ARG, { _volume}, "set startup volume 
> 0=min 100=max", "volume" },
>  { "f", HAS_ARG, { .func_arg = opt_format }, "force format", "fmt" },
>  { "pix_fmt", HAS_ARG | OPT_EXPERT | OPT_VIDEO, { .func_arg = 
> opt_frame_pix_fmt }, "set pixel format", "format" },
> @@ -3722,6 +3724,8 @@ int main(int argc, char **argv)
>  
>  if (!display_disable) {
>  int flags = SDL_WINDOW_HIDDEN;
> +if (alwaysontop)
> +flags |= SDL_WINDOW_ALWAYS_ON_TOP;

fails to build

fftools/ffplay.c: In function ‘main’:
fftools/ffplay.c:3728:22: error: ‘SDL_WINDOW_ALWAYS_ON_TOP’ undeclared (first 
use in this function)
 flags |= SDL_WINDOW_ALWAYS_ON_TOP;


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

In fact, the RIAA has been known to suggest that students drop out
of college or go to community college in order to be able to afford
settlements. -- The RIAA


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 v2] fix issues with transparent crop. (see https://trac.ffmpeg.org/ticket/7890)

[Paul B Mahol]

On 5/9/19, Bjorn Roche  wrote:
> From: Jacob Graff 
>
> Resolves issues with some transparent gifs.
> see https://trac.ffmpeg.org/ticket/7890
> contribution by Jacob Graff 
>

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

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

Re: [FFmpeg-devel] [PATCH] avfilter: add asr filter

[Paul B Mahol]

On 5/5/19, Paul B Mahol  wrote:
> Signed-off-by: Paul B Mahol 
> ---
>  configure|   4 +
>  doc/filters.texi |  32 +++
>  libavfilter/Makefile |   1 +
>  libavfilter/af_asr.c | 177 +++
>  libavfilter/allfilters.c |   1 +
>  5 files changed, 215 insertions(+)
>  create mode 100644 libavfilter/af_asr.c
>

Will 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] swscale: Add support for NV24 and NV42

[Michael Niedermayer]

On Sat, May 11, 2019 at 05:40:41PM +0200, Michael Niedermayer wrote:
> On Thu, May 09, 2019 at 10:59:12PM -0700, Philip Langdale wrote:
> > I don't think this is terribly useful, as the only thing out there that
> > can even handle NV24 content is VDPAU and the only time you have to
> > deal with it is when doing VDPAU OpenGL interop where swscale is
> > irrelevant. In the other cases you can use YV24 (YUV444P).
> > 
> > But anyway, I was asked to do this for the sake of completeness.
> > 
> > The implementation is pretty straight-forward. Most of the existing
> > NV12 codepaths work regardless of subsampling and are re-used as is.
> > Where necessary I wrote the slightly different NV24 versions.
> > 
> > Finally, the one thing that confused me for a long time was the
> > asm specific x86 path that did an explicit exclusion check for NV12.
> > I replaced that with a semi-planar check and also updated the
> > equivalent PPC code, but which I cannot test.
> > 
> > Signed-off-by: Philip Langdale 
> > ---
> >  libswscale/input.c   |  2 +
> >  libswscale/output.c  |  6 ++-
> >  libswscale/ppc/swscale_altivec.c |  3 +-
> >  libswscale/ppc/swscale_vsx.c |  3 +-
> >  libswscale/swscale_unscaled.c| 51 
> >  libswscale/utils.c   |  2 +
> >  libswscale/version.h |  2 +-
> >  libswscale/x86/swscale_template.c|  4 +-
> >  tests/ref/fate/filter-pixfmts-copy   |  2 +
> >  tests/ref/fate/filter-pixfmts-crop   |  2 +
> >  tests/ref/fate/filter-pixfmts-field  |  2 +
> >  tests/ref/fate/filter-pixfmts-fieldorder |  2 +
> >  tests/ref/fate/filter-pixfmts-hflip  |  2 +
> >  tests/ref/fate/filter-pixfmts-il |  2 +
> >  tests/ref/fate/filter-pixfmts-null   |  2 +
> >  tests/ref/fate/filter-pixfmts-pad|  2 +
> >  tests/ref/fate/filter-pixfmts-scale  |  2 +
> >  tests/ref/fate/filter-pixfmts-transpose  |  2 +
> >  tests/ref/fate/filter-pixfmts-vflip  |  2 +
> >  19 files changed, 86 insertions(+), 9 deletions(-)
> 
> was this tested with up/down scaling ?

also seems to require this:

diff --git a/tests/ref/fate/sws-pixdesc-query b/tests/ref/fate/sws-pixdesc-query
index 6c41a86e1e..bc8147e3c7 100644
--- a/tests/ref/fate/sws-pixdesc-query
+++ b/tests/ref/fate/sws-pixdesc-query
@@ -178,6 +178,8 @@ isYUV:
   nv20be
   nv20le
   nv21
+  nv24
+  nv42
   p010be
   p010le
   p016be
@@ -268,6 +270,8 @@ isPlanarYUV:
   nv20be
   nv20le
   nv21
+  nv24
+  nv42
   p010be
   p010le
   p016be
@@ -703,6 +707,8 @@ Planar:
   nv20be
   nv20le
   nv21
+  nv24
+  nv42
   p010be
   p010le
   p016be

[...]


-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Rewriting code that is poorly written but fully understood is good.
Rewriting code that one doesnt understand is a sign that one is less smart
then the original author, trying to rewrite it will not make it better.


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] lavf/h264: add support for h264 video from Arecont camera, fixes ticket #5154

[Shivam Goyal]

On 11-05-2019 04:27, Reimar Döffinger wrote:

> On Thu, May 09, 2019 at 11:45:59PM +0530, Shivam Goyal wrote: 
> 
>> @@ -117,4 +120,128 @@ static int h264_probe(const AVProbeData *p)
>> return 0;
>> }
>> 
>> +static const uint8_t arecont_sign[] = {0x2D, 0x2D, 0x66, 0x62, 0x64, 0x72, 
>> 0x0D, 0x0A};
> 
> I admit I was more thinking of either
> static const uint8_t arecont_sign[] = "--fbdr\r\n";
> which ends up 1 byte too long, or
> static const uint8_t arecont_sign[8] = "--fbdr\r\n";
> 
> Though there is also the option to go for
> static const uint64_t arecont_sign = AV_RL64("--fbdr\r\n");
> or similar.

   Okay, I will change it. 

>> +static int arecont_find_sign(unsigned char *data, int size)
> 
> You should be consistent with the types even if they are essentially
> the same.
> i.e. uint8_t instead of unsigned char *
> Also const, since this function does/should not modify "data".

   Will change it too, 

>> +int sign_size = sizeof(arecont_sign) / sizeof(arecont_sign[0]);
> 
> First, this is the expression of number of elements, so the
> division part is semantically wrong.
> Also it's pointless because it will be 1 always.

Will use strlen() as i am changing the above. 

>> +j = memchr(data, arecont_sign[0], size);
>> +while (j != NULL && size - sign_size >= (j - data)) {
>> +if (!memcmp(arecont_sign, j, sign_size))
>> +return (j - data);
>> +if (size - sign_size == (j - data))
>> +return -1;
>> +j = memchr(data + (j - data) + 1, arecont_sign[0], size - (j - 
>> data));
>> +}
> 
> I know I brought this memchr up, but did you do any benchmarks?
> Unless you have actual evidence of a speed problem AND can
> show that your solution actually makes it faster, I'd
> suggest to go with the simplest possible solution.

 Yeah, I checked the both approaches and perform test to compare time.
and found the previous one is good for shorter 
 strings (length < 300). and the newer version is good for strings
larger than this. The newer version is 4 microseconds faster 
 in our case(length ~ 1100). As the diff is small, so i think the
simpler version is better. 

>> +data = av_malloc(size);
>> +ret = avio_read_partial(s->pb, data, size);
>> +if (ret < 0) {
>> +av_free(data);
>> +av_packet_unref(pkt);
>> +return ret;
>> +}
>> +if (pos <= ARECONT_H264_MIME_SIZE) {
>> +avio_seek(s->pb, 0, SEEK_SET);
>> +start = pos;
>> +} else {
>> +avio_seek(s->pb, pos - ARECONT_H264_MIME_SIZE, SEEK_SET);
>> +start = ARECONT_H264_MIME_SIZE;
>> +}
>> +ret = avio_read_partial(s->pb, data, size);
>> +if (ret < 0 || start >= ret) {
>> +av_free(data);
>> +av_packet_unref(pkt);
>> +return ret;
>> +}
> 
> Unfortunately I still have no idea what that code is meant to do.
> First there is no point in allocating "data" when you have
> pkt->data already (yes, it would mean using memmove instead
> of memcpy later on, but that seems to be about it).
> Then the code reads TWICE into the same buffer for some reason,
> the first read seems completely pointless?
> Also the only point of the _partial variant of the read function
> is reducing latency, however the avio_seek is likely to be
> quite a bad hit for latency that this really seems like
> premature optimization.
> Also the avio_seek means this demuxer might not work at all
> if the stream is not seekable (might since I don't know
> if we maybe do enough buffering nowadays - but if the code
> relies on that there should be a check).

What i did in the above code is that as the packet can contain
partial http header at the start or end of the pkt, which needs to be
removed, i seeked backward 100 bytes( or at the start of the file if
necessory) and the i did the same to remove the partial http header at
the end, i seeked forward 100 bytes extra. 

  start  end 
stream..^.^ 
 |_| |_| 
| | 
  http headerhttp header 

I first filled the "data" and then searched for the http header, copied
the bytes before position of http header from "data" to pkt->data. And
then skipped the http header and again searched for another http header
in "data" and did the same thing. Also, the code is reading twice
because the first is just if any errors come( like file ended). because
after that the avio_seek() seek stream backwards and if it would do,
then error can't be detected. 

Yeah, i realized that the avio_seek() is not a good idea. One another
approach i thought is that to store 100 bytes (or 70) of the current
iteration for the next iteration. In this way we don't have to use
avio_seek.also there would not be any need of reading twice. Please
suggest if it is right. (Sorry, if i am asking too much doubts). 

>> +

Re: [FFmpeg-devel] [PATCH v2 2/2] fftools/ffmpeg: Add stream metadata from first frame's metadata

[Nicolas George]

Jun Li (12019-05-10):
> I think now I understand what you mean"lavfi does not support real
> reconfiguration of the stream properties. "
> Even we have a perfect filter for this case, we still have to dynamic
> turn on/off the filter per frame's metadata.

No, that is not what I meant: there is nothing to turn on or off if the
filters itself examines the frame metadata.

The problem is that if a filter does that, it can switch from outputting
1920×1080 to 1080×1920 when the orientation changes. Most filters and
the framework do not support that.

> Then I just wonder maybe we just need a function to rotate/flip the frame
> data, rather than using filter ? Do you mind sharing some advice ?

That would not change anything, since it was for the wrong problem.

Regards,

-- 
  Nicolas George


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

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

Re: [FFmpeg-devel] [PATCH] avfilter: add colorhold filter

[Timo Rothenpieler]

On 04.05.2019 16:13, Paul B Mahol wrote:

Signed-off-by: Paul B Mahol 
---
  doc/filters.texi  |  18 +++
  libavfilter/Makefile  |   1 +
  libavfilter/allfilters.c  |   1 +
  libavfilter/vf_colorkey.c | 102 +-
  4 files changed, 121 insertions(+), 1 deletion(-)

diff --git a/doc/filters.texi b/doc/filters.texi
index cd82869849..1ac37a32b8 100644
--- a/doc/filters.texi
+++ b/doc/filters.texi
@@ -6723,6 +6723,24 @@ ffmpeg -i background.png -i video.mp4 -filter_complex 
"[1:v]colorkey=0x3BBD1E:0.
  @end example
  @end itemize
  
+@section colorhold

+Remove all color information for all RGB colors except for certain one.
+
+The filter accepts the following options:
+
+@table @option
+@item color
+The color which will not be replaced with neutral gray.
+
+@item similarity
+Similarity percentage with the above color.
+0.01 matches only the exact key color, while 1.0 matches everything.
+
+@item blend
+Blend percentage. 0.0 makes pixels fully gray.
+Higher values result in more preserved color.
+@end table
+
  @section colorlevels
  
  Adjust video input frames using levels.

diff --git a/libavfilter/Makefile b/libavfilter/Makefile
index 59d12ce069..b41304d480 100644
--- a/libavfilter/Makefile
+++ b/libavfilter/Makefile
@@ -179,6 +179,7 @@ OBJS-$(CONFIG_COLORCHANNELMIXER_FILTER)  += 
vf_colorchannelmixer.o
  OBJS-$(CONFIG_COLORKEY_FILTER)   += vf_colorkey.o
  OBJS-$(CONFIG_COLORKEY_OPENCL_FILTER)+= vf_colorkey_opencl.o opencl.o 
\
  opencl/colorkey.o
+OBJS-$(CONFIG_COLORHOLD_FILTER)  += vf_colorkey.o
  OBJS-$(CONFIG_COLORLEVELS_FILTER)+= vf_colorlevels.o
  OBJS-$(CONFIG_COLORMATRIX_FILTER)+= vf_colormatrix.o
  OBJS-$(CONFIG_COLORSPACE_FILTER) += vf_colorspace.o colorspace.o 
colorspacedsp.o
diff --git a/libavfilter/allfilters.c b/libavfilter/allfilters.c
index ae725cb0e0..9bdfa7d1bc 100644
--- a/libavfilter/allfilters.c
+++ b/libavfilter/allfilters.c
@@ -167,6 +167,7 @@ extern AVFilter ff_vf_colorbalance;
  extern AVFilter ff_vf_colorchannelmixer;
  extern AVFilter ff_vf_colorkey;
  extern AVFilter ff_vf_colorkey_opencl;
+extern AVFilter ff_vf_colorhold;
  extern AVFilter ff_vf_colorlevels;
  extern AVFilter ff_vf_colormatrix;
  extern AVFilter ff_vf_colorspace;
diff --git a/libavfilter/vf_colorkey.c b/libavfilter/vf_colorkey.c
index 3d65e59d42..b546cd4122 100644
--- a/libavfilter/vf_colorkey.c
+++ b/libavfilter/vf_colorkey.c
@@ -34,6 +34,9 @@ typedef struct ColorkeyContext {
  uint8_t colorkey_rgba[4];
  float similarity;
  float blend;
+
+int (*do_slice)(AVFilterContext *ctx, void *arg,
+int jobnr, int nb_jobs);
  } ColorkeyContext;
  
  static uint8_t do_colorkey_pixel(ColorkeyContext *ctx, uint8_t r, uint8_t g, uint8_t b)

@@ -77,15 +80,65 @@ static int do_colorkey_slice(AVFilterContext *avctx, void 
*arg, int jobnr, int n
  return 0;
  }
  
+static int do_colorhold_slice(AVFilterContext *avctx, void *arg, int jobnr, int nb_jobs)

+{
+AVFrame *frame = arg;
+
+const int slice_start = (frame->height * jobnr) / nb_jobs;
+const int slice_end = (frame->height * (jobnr + 1)) / nb_jobs;
+
+ColorkeyContext *ctx = avctx->priv;
+
+int o, x, y;
+
+for (y = slice_start; y < slice_end; ++y) {
+for (x = 0; x < frame->width; ++x) {
+int t, r, g, b;


Nit, but I'd prefer to not mix "declaration at top" with intermittent 
declaration of vars.

In this case, I'd just put o down here as well.


+o = frame->linesize[0] * y + x * 4;
+r = frame->data[0][o + ctx->co[0]];
+g = frame->data[0][o + ctx->co[1]];
+b = frame->data[0][o + ctx->co[2]];
+
+t = do_colorkey_pixel(ctx, r, g, b);
+
+if (t > 0) {
+int a = (r + g + b) / 3;
+int rt = 255 - t;
+
+frame->data[0][o + ctx->co[0]] = (a * t + r * rt + 127) >> 8;
+frame->data[0][o + ctx->co[1]] = (a * t + g * rt + 127) >> 8;
+frame->data[0][o + ctx->co[2]] = (a * t + b * rt + 127) >> 8;
+}
+}
+}
+
+return 0;
+}
+
+static av_cold int init_filter(AVFilterContext *avctx)
+{
+ColorkeyContext *ctx = avctx->priv;
+
+if (!strcmp(avctx->filter->name, "colorkey")) {
+ctx->do_slice = do_colorkey_slice;
+} else {
+ctx->do_slice = do_colorhold_slice;
+}
+
+return 0;
+}
+
  static int filter_frame(AVFilterLink *link, AVFrame *frame)
  {
  AVFilterContext *avctx = link->dst;
+ColorkeyContext *ctx = avctx->priv;
  int res;
  
  if (res = av_frame_make_writable(frame))

  return res;
  
-if (res = avctx->internal->execute(avctx, do_colorkey_slice, frame, NULL, FFMIN(frame->height, ff_filter_get_nb_threads(avctx

+if (res = avctx->internal->execute(avctx, ctx->do_slice, frame, NULL, 
FFMIN(frame->height, 

Re: [FFmpeg-devel] [PATCH] swscale: Add support for NV24 and NV42

[Michael Niedermayer]

On Thu, May 09, 2019 at 10:59:12PM -0700, Philip Langdale wrote:
> I don't think this is terribly useful, as the only thing out there that
> can even handle NV24 content is VDPAU and the only time you have to
> deal with it is when doing VDPAU OpenGL interop where swscale is
> irrelevant. In the other cases you can use YV24 (YUV444P).
> 
> But anyway, I was asked to do this for the sake of completeness.
> 
> The implementation is pretty straight-forward. Most of the existing
> NV12 codepaths work regardless of subsampling and are re-used as is.
> Where necessary I wrote the slightly different NV24 versions.
> 
> Finally, the one thing that confused me for a long time was the
> asm specific x86 path that did an explicit exclusion check for NV12.
> I replaced that with a semi-planar check and also updated the
> equivalent PPC code, but which I cannot test.
> 
> Signed-off-by: Philip Langdale 
> ---
>  libswscale/input.c   |  2 +
>  libswscale/output.c  |  6 ++-
>  libswscale/ppc/swscale_altivec.c |  3 +-
>  libswscale/ppc/swscale_vsx.c |  3 +-
>  libswscale/swscale_unscaled.c| 51 
>  libswscale/utils.c   |  2 +
>  libswscale/version.h |  2 +-
>  libswscale/x86/swscale_template.c|  4 +-
>  tests/ref/fate/filter-pixfmts-copy   |  2 +
>  tests/ref/fate/filter-pixfmts-crop   |  2 +
>  tests/ref/fate/filter-pixfmts-field  |  2 +
>  tests/ref/fate/filter-pixfmts-fieldorder |  2 +
>  tests/ref/fate/filter-pixfmts-hflip  |  2 +
>  tests/ref/fate/filter-pixfmts-il |  2 +
>  tests/ref/fate/filter-pixfmts-null   |  2 +
>  tests/ref/fate/filter-pixfmts-pad|  2 +
>  tests/ref/fate/filter-pixfmts-scale  |  2 +
>  tests/ref/fate/filter-pixfmts-transpose  |  2 +
>  tests/ref/fate/filter-pixfmts-vflip  |  2 +
>  19 files changed, 86 insertions(+), 9 deletions(-)

was this tested with up/down scaling ?

thanks

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

There will always be a question for which you do not know the correct answer.


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] swscale: Add support for NV24 and NV42

[Philip Langdale]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On Sat, 11 May 2019 17:40:41 +0200
Michael Niedermayer  wrote:

> On Thu, May 09, 2019 at 10:59:12PM -0700, Philip Langdale wrote:
> > I don't think this is terribly useful, as the only thing out there
> > that can even handle NV24 content is VDPAU and the only time you
> > have to deal with it is when doing VDPAU OpenGL interop where
> > swscale is irrelevant. In the other cases you can use YV24
> > (YUV444P).
> > 
> > But anyway, I was asked to do this for the sake of completeness.
> > 
> > The implementation is pretty straight-forward. Most of the existing
> > NV12 codepaths work regardless of subsampling and are re-used as is.
> > Where necessary I wrote the slightly different NV24 versions.
> > 
> > Finally, the one thing that confused me for a long time was the
> > asm specific x86 path that did an explicit exclusion check for NV12.
> > I replaced that with a semi-planar check and also updated the
> > equivalent PPC code, but which I cannot test.
> > 
> > Signed-off-by: Philip Langdale 
> > ---
> >  libswscale/input.c   |  2 +
> >  libswscale/output.c  |  6 ++-
> >  libswscale/ppc/swscale_altivec.c |  3 +-
> >  libswscale/ppc/swscale_vsx.c |  3 +-
> >  libswscale/swscale_unscaled.c| 51
> >  libswscale/utils.c
> > |  2 + libswscale/version.h |  2 +-
> >  libswscale/x86/swscale_template.c|  4 +-
> >  tests/ref/fate/filter-pixfmts-copy   |  2 +
> >  tests/ref/fate/filter-pixfmts-crop   |  2 +
> >  tests/ref/fate/filter-pixfmts-field  |  2 +
> >  tests/ref/fate/filter-pixfmts-fieldorder |  2 +
> >  tests/ref/fate/filter-pixfmts-hflip  |  2 +
> >  tests/ref/fate/filter-pixfmts-il |  2 +
> >  tests/ref/fate/filter-pixfmts-null   |  2 +
> >  tests/ref/fate/filter-pixfmts-pad|  2 +
> >  tests/ref/fate/filter-pixfmts-scale  |  2 +
> >  tests/ref/fate/filter-pixfmts-transpose  |  2 +
> >  tests/ref/fate/filter-pixfmts-vflip  |  2 +
> >  19 files changed, 86 insertions(+), 9 deletions(-)  
> 
> was this tested with up/down scaling ?
> 
> thanks
> 

Yes.

- --phil
-BEGIN PGP SIGNATURE-

iHUEARYIAB0WIQRokRbWmcX6x+Nv+3hgE8jODULZ6QUCXNb+yQAKCRBgE8jODULZ
6eHxAP9gGwsOidh6k77QyWcRLMk8zr2Uh6qizKPT21h9PYzQEwD8CvYOiRAem/qS
UrTfd6pFClXNO27PQEL8aeioZqOH7g8=
=pTPw
-END 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] avfilter: add colorhold filter

[Paul B Mahol]

On 5/4/19, Paul B Mahol  wrote:
> Signed-off-by: Paul B Mahol 
> ---
>  doc/filters.texi  |  18 +++
>  libavfilter/Makefile  |   1 +
>  libavfilter/allfilters.c  |   1 +
>  libavfilter/vf_colorkey.c | 102 +-
>  4 files changed, 121 insertions(+), 1 deletion(-)
>

7 days passed, nobody voted against. So I will apply this filter soon.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

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

Re: [FFmpeg-devel] [PATCH] avfilter: add colorhold filter

[Paul B Mahol]

On 5/11/19, Nicolas George  wrote:
> Paul B Mahol (12019-05-11):
>> 7 days passed, nobody voted against. So I will apply this filter soon.
>
> Two people have objected to the vote itself. That is more than one.
> Please realize you are using intimidation techniques that have
> absolutely no place in a project like this one. If you insist on
> legitimizing an invalid vote, then I will act on the fake invalid vote
> that I posted.
>
> Ask, politely, that somebody review this patch. That is easy.
>

I will kindly and slowly going to apply this splendid patch very soon.

If you want to object this patch inclusion into main FFmpeg tree than
kindly review it.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

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

Re: [FFmpeg-devel] [PATCH] ffplay: added option always on top for video window

[Gyan]

On 11-05-2019 09:03 PM, Michael Niedermayer wrote:

On Fri, May 10, 2019 at 12:12:17PM +0200, Daniel Kucera wrote:

From: Daniel Kucera 

Signed-off-by: Daniel Kucera 
---
  doc/ffplay.texi  | 2 ++
  fftools/ffplay.c | 4 
  2 files changed, 6 insertions(+)

diff --git a/doc/ffplay.texi b/doc/ffplay.texi
index c305465078..a37c02dc0d 100644
--- a/doc/ffplay.texi
+++ b/doc/ffplay.texi
@@ -66,6 +66,8 @@ Set custom interval, in seconds, for seeking using left/right 
keys. Default is 1
  Disable graphical display.
  @item -noborder
  Borderless window.
+@item -alwaysontop
+Window always on top.
  @item -volume
  Set the startup volume. 0 means silence, 100 means no volume reduction or
  amplification. Negative values are treated as 0, values above 100 are treated
diff --git a/fftools/ffplay.c b/fftools/ffplay.c
index 8f050e16e6..931dc08e2d 100644
--- a/fftools/ffplay.c
+++ b/fftools/ffplay.c
@@ -324,6 +324,7 @@ static int seek_by_bytes = -1;
  static float seek_interval = 10;
  static int display_disable;
  static int borderless;
+static int alwaysontop;
  static int startup_volume = 100;
  static int show_status = 1;
  static int av_sync_type = AV_SYNC_AUDIO_MASTER;
@@ -3581,6 +3582,7 @@ static const OptionDef options[] = {
  { "seek_interval", OPT_FLOAT | HAS_ARG, { _interval }, "set seek interval for 
left/right keys, in seconds", "seconds" },
  { "nodisp", OPT_BOOL, { _disable }, "disable graphical display" },
  { "noborder", OPT_BOOL, {  }, "borderless window" },
+{ "alwaysontop", OPT_BOOL, {  }, "window always on top" },
  { "volume", OPT_INT | HAS_ARG, { _volume}, "set startup volume 0=min 
100=max", "volume" },
  { "f", HAS_ARG, { .func_arg = opt_format }, "force format", "fmt" },
  { "pix_fmt", HAS_ARG | OPT_EXPERT | OPT_VIDEO, { .func_arg = opt_frame_pix_fmt }, "set 
pixel format", "format" },
@@ -3722,6 +3724,8 @@ int main(int argc, char **argv)
  
  if (!display_disable) {

  int flags = SDL_WINDOW_HIDDEN;
+if (alwaysontop)
+flags |= SDL_WINDOW_ALWAYS_ON_TOP;

fails to build

fftools/ffplay.c: In function ‘main’:
fftools/ffplay.c:3728:22: error: ‘SDL_WINDOW_ALWAYS_ON_TOP’ undeclared (first 
use in this function)
  flags |= SDL_WINDOW_ALWAYS_ON_TOP;


Is qualified as 'X11 only, >= SDL 2.0.5' at 
https://wiki.libsdl.org/SDL_WindowFlags


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

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

[FFmpeg-devel] [PATCH 1/2] lavf/dashdec: fix the coding logic after open_input fail

[Jun Zhao]

From: Jun Zhao 

setting return status following goto will never be executed, so
adjust the location in the code.

Signed-off-by: Jun Zhao 
---
 libavformat/dashdec.c |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/libavformat/dashdec.c b/libavformat/dashdec.c
index 6e3e7e4..ce8bd4a 100644
--- a/libavformat/dashdec.c
+++ b/libavformat/dashdec.c
@@ -1793,8 +1793,8 @@ restart:
 ret = open_input(c, v, v->cur_seg);
 if (ret < 0) {
 if (ff_check_interrupt(c->interrupt_callback)) {
-goto end;
 ret = AVERROR_EXIT;
+goto end;
 }
 av_log(v->parent, AV_LOG_WARNING, "Failed to open fragment of 
playlist %d\n", v->rep_idx);
 v->cur_seq_no++;
-- 
1.7.1

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

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

Re: [FFmpeg-devel] [PATCH v2] libavutil: add an FFT & MDCT implementation

[Lynne]

May 10, 2019, 8:59 PM by ceffm...@gmail.com:

> Am Fr., 10. Mai 2019 um 19:54 Uhr schrieb Lynne <> d...@lynne.ee 
> > >:
>
>>
>> May 10, 2019, 4:14 PM by >> d...@lynne.ee >> :
>>
>> > Patch updated again.
>> > Made some more cleanups to the transforms, the tables and the main context.
>> > API changed again, now the init function populates the function pointer 
>> > for transform.
>> > I decided that having a separate function would encourage bad usage (e.g. 
>> > calling
>> > the function every time before doing a transform rather than storing the 
>> > pointer) when
>> > we're trying to avoid the overhead of function calls.
>> > Also adjusted file names to match the API.
>> >
>>
>> Forgot to change an include, new patch attached.
>>
>
> If I understand the commit message correctly, some of the code
> in the new file you are adding comes from other parts of FFmpeg.
> I am surprised that there is no copyright claim on the top of this
> new file.
> Is there none on top of the files you took the code from?
>

The project isn't consistent with updating nor putting copyright headers on 
files so
I'd rather keep the headers clean. Commit messages and authors are the only way 
to
know who authored what.
I could credit the authors fully in the commit message, then authorship can 
still be tracked
and the headers will be clean.
___
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] vf_thumbnail: support alpha

[Robert Nagy]

---
 libavfilter/vf_thumbnail.c | 8 +---
 1 file changed, 5 insertions(+), 3 deletions(-)

diff --git a/libavfilter/vf_thumbnail.c b/libavfilter/vf_thumbnail.c
index 0effdc91e9..30bb0dfdb8 100644
--- a/libavfilter/vf_thumbnail.c
+++ b/libavfilter/vf_thumbnail.c
@@ -136,6 +136,7 @@ static int filter_frame(AVFilterLink *inlink,
AVFrame *frame)
 AVFilterLink *outlink = ctx->outputs[0];
 int *hist = s->frames[s->n].histogram;
 const uint8_t *p = frame->data[0];
+int stride = frame->format == AV_PIX_FMT_BGRA || frame->format ==
AV_PIX_FMT_RGBA ? 4 : 3;

 // keep a reference of each frame
 s->frames[s->n].buf = frame;
@@ -143,9 +144,9 @@ static int filter_frame(AVFilterLink *inlink,
AVFrame *frame)
 // update current frame RGB histogram
 for (j = 0; j < inlink->h; j++) {
 for (i = 0; i < inlink->w; i++) {
-hist[0*256 + p[i*3]]++;
-hist[1*256 + p[i*3 + 1]]++;
-hist[2*256 + p[i*3 + 2]]++;
+hist[0*256 + p[i*stride]]++;
+hist[1*256 + p[i*stride + 1]]++;
+hist[2*256 + p[i*stride + 2]]++;
 }
 p += frame->linesize[0];
 }
@@ -197,6 +198,7 @@ static int query_formats(AVFilterContext *ctx)
 {
 static const enum AVPixelFormat pix_fmts[] = {
 AV_PIX_FMT_RGB24, AV_PIX_FMT_BGR24,
+AV_PIX_FMT_RGBA, AV_PIX_FMT_BGRA,
 AV_PIX_FMT_NONE
 };
 AVFilterFormats *fmts_list = ff_make_format_list(pix_fmts);
-- 
2.19.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

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

[FFmpeg-devel] [PATCH 2/2] lavf/dashdec: refactoring error handle logic for open_input

[Jun Zhao]

From: Jun Zhao 

refactoring error handle logic for open_input.

Signed-off-by: Jun Zhao 
---
 libavformat/dashdec.c |4 +---
 1 files changed, 1 insertions(+), 3 deletions(-)

diff --git a/libavformat/dashdec.c b/libavformat/dashdec.c
index ce8bd4a..2c50f23 100644
--- a/libavformat/dashdec.c
+++ b/libavformat/dashdec.c
@@ -1687,6 +1687,7 @@ static int open_input(DASHContext *c, struct 
representation *pls, struct fragmen
 
 url = av_mallocz(c->max_url_size);
 if (!url) {
+ret = AVERROR(ENOMEM);
 goto cleanup;
 }
 
@@ -1701,9 +1702,6 @@ static int open_input(DASHContext *c, struct 
representation *pls, struct fragmen
 av_log(pls->parent, AV_LOG_VERBOSE, "DASH request for url '%s', offset 
%"PRId64", playlist %d\n",
url, seg->url_offset, pls->rep_idx);
 ret = open_url(pls->parent, >input, url, c->avio_opts, opts, NULL);
-if (ret < 0) {
-goto cleanup;
-}
 
 cleanup:
 av_free(url);
-- 
1.7.1

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

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

Re: [FFmpeg-devel] [PATCH v2] libavutil: add an FFT & MDCT implementation

[Pedro Arthur]

Em sáb, 11 de mai de 2019 às 20:26, James Almer  escreveu:
>
> On 5/11/2019 8:08 PM, Carl Eugen Hoyos wrote:
> > Am So., 12. Mai 2019 um 01:00 Uhr schrieb Lynne :
> >>
> >> May 11, 2019, 11:08 PM by ceffm...@gmail.com:
> >>
> >>> Am Sa., 11. Mai 2019 um 14:41 Uhr schrieb Lynne <> d...@lynne.ee 
> >>> > >:
> >>>
> 
>  May 10, 2019, 8:59 PM by >> ceffm...@gmail.com 
>  >> :
> 
> > Am Fr., 10. Mai 2019 um 19:54 Uhr schrieb Lynne <> >> d...@lynne.ee 
> > >>  > d...@lynne.ee 
> > >> >> >:
> >
> >>
> >> May 10, 2019, 4:14 PM by >> >> d...@lynne.ee >>  
> >> > d...@lynne.ee >> >>> :
> >>
> >>> Patch updated again.
> >>> Made some more cleanups to the transforms, the tables and the main 
> >>> context.
> >>> API changed again, now the init function populates the function 
> >>> pointer for transform.
> >>> I decided that having a separate function would encourage bad usage 
> >>> (e.g. calling
> >>> the function every time before doing a transform rather than storing 
> >>> the pointer) when
> >>> we're trying to avoid the overhead of function calls.
> >>> Also adjusted file names to match the API.
> >>>
> >>
> >> Forgot to change an include, new patch attached.
> >>
> >
> > If I understand the commit message correctly, some of the code
> > in the new file you are adding comes from other parts of FFmpeg.
> > I am surprised that there is no copyright claim on the top of this
> > new file.
> > Is there none on top of the files you took the code from?
> >
> 
>  The project isn't consistent with updating nor putting copyright headers 
>  on files so
>  I'd rather keep the headers clean. Commit messages and authors are the 
>  only way to
>  know who authored what.
> 
> >>>
> >>> I don't think this is correct, but that is not the question: Copyright
> >>> law is (at least here)
> >>> very clear, if somebody put his name on top of the file, you must not 
> >>> remove it,
> >>> especially not when moving code from one file into another.
> >>>
> >>
> >> "Here"? You're probably referring to some county's laws, those don't apply 
> >> universally,
> >> especially not to the internet.
> >> Either way, that rule hasn't really been respected despite the major 
> >> refactoring that has
> >> happened in the past so I don't see why it has to be respected now.
> >
> > Please point me to the commit you indicate so I can fix this (claimed) 
> > copyright
> > violation.
> >
> >> The only parts I didn't rewrite are the power of two FFT, which I can NIH 
> >> in a week if
> >> necessary, and in fact lately with the research papers I've recently read 
> >> I'm thinking
> >> I should.
> >
> > Why don't you simply copy the copyright statement from the file where you 
> > copied
> > it from instead (if there is one)?
> > Wouldn't that be much quicker than this email exchange?
> >
> > Carl Eugen
>
> The commit message already states it takes parts of lavc's fft
> implementation, and the git story can't be rewritten, so authorship is
> known or can be easily figured out. Could we please focus on technical
> matters instead of wasting time in a back and forth about stuff like this?
>

Not saying this is the case, but if one interprets it as copying the
code, adding more code, removing some parts, and removing the
copyrights previously present it is clearly violating the license.
It seems wise to include copyrights from original code in the file.

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

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

[FFmpeg-devel] [PATCH v1] fftools/ffmpeg: Add support for per frame rotation and flip

[Jun Li]

Fix #6945
Current implementaion for autorotate works fine for stream
level rotataion but no support for frame level operation
and frame flip. This patch is for adding flip support and
per frame operations.
---
 fftools/cmdutils.c|  9 ++---
 fftools/cmdutils.h|  2 +-
 fftools/ffmpeg.c  | 21 +-
 fftools/ffmpeg.h  |  2 +
 fftools/ffmpeg_filter.c   | 81 ---
 fftools/ffplay.c  | 28 +++---
 libavutil/display.c   | 14 +++
 libavutil/display.h   | 14 +++
 libavutil/tests/display.c |  8 
 tests/ref/fate/display|  4 ++
 10 files changed, 166 insertions(+), 17 deletions(-)

diff --git a/fftools/cmdutils.c b/fftools/cmdutils.c
index 9cfbc45c2b..b8bb904419 100644
--- a/fftools/cmdutils.c
+++ b/fftools/cmdutils.c
@@ -2172,13 +2172,12 @@ void *grow_array(void *array, int elem_size, int *size, 
int new_size)
 return array;
 }
 
-double get_rotation(AVStream *st)
+double get_rotation_hflip(int32_t display_matrix[9], int* hflip)
 {
-uint8_t* displaymatrix = av_stream_get_side_data(st,
- 
AV_PKT_DATA_DISPLAYMATRIX, NULL);
 double theta = 0;
-if (displaymatrix)
-theta = -av_display_rotation_get((int32_t*) displaymatrix);
+
+if (display_matrix)
+theta = -av_display_rotation_hflip_get(display_matrix, hflip);
 
 theta -= 360*floor(theta/360 + 0.9/360);
 
diff --git a/fftools/cmdutils.h b/fftools/cmdutils.h
index 6e2e0a2acb..dce44ed6e1 100644
--- a/fftools/cmdutils.h
+++ b/fftools/cmdutils.h
@@ -643,6 +643,6 @@ void *grow_array(void *array, int elem_size, int *size, int 
new_size);
 char name[128];\
 av_get_channel_layout_string(name, sizeof(name), 0, ch_layout);
 
-double get_rotation(AVStream *st);
+double get_rotation_hflip(int32_t display_matrix[9], int* hflip);
 
 #endif /* FFTOOLS_CMDUTILS_H */
diff --git a/fftools/ffmpeg.c b/fftools/ffmpeg.c
index 01f04103cf..9ea1aaa930 100644
--- a/fftools/ffmpeg.c
+++ b/fftools/ffmpeg.c
@@ -2126,6 +2126,24 @@ static int ifilter_has_all_input_formats(FilterGraph *fg)
 return 1;
 }
 
+static int ifilter_display_matrix_need_from_frame(InputFilter *ifilter, 
AVFrame* frame)
+{
+int32_t* stream_matrix = 
(int32_t*)av_stream_get_side_data(ifilter->ist->st, 
+AV_PKT_DATA_DISPLAYMATRIX, 
NULL);
+// if we already have display matrix from stream, use it instead of 
extracting
+// from frame.
+if (stream_matrix) {
+memcpy(ifilter->display_matrix, stream_matrix, 4 * 9);
+return 0;
+}
+
+// cleanup the display matrix, may be from last frame
+memset(ifilter->display_matrix, 0, 4 * 9);
+av_display_rotation_set(ifilter->display_matrix, 0);
+
+return !!av_dict_get(frame->metadata, "Orientation", NULL, 0);
+}
+
 static int ifilter_send_frame(InputFilter *ifilter, AVFrame *frame)
 {
 FilterGraph *fg = ifilter->graph;
@@ -2141,7 +2159,8 @@ static int ifilter_send_frame(InputFilter *ifilter, 
AVFrame *frame)
ifilter->channel_layout != frame->channel_layout;
 break;
 case AVMEDIA_TYPE_VIDEO:
-need_reinit |= ifilter->width  != frame->width ||
+need_reinit |= ifilter_display_matrix_need_from_frame(ifilter, frame) 
||
+   ifilter->width  != frame->width ||
ifilter->height != frame->height;
 break;
 }
diff --git a/fftools/ffmpeg.h b/fftools/ffmpeg.h
index eb1eaf6363..8331720663 100644
--- a/fftools/ffmpeg.h
+++ b/fftools/ffmpeg.h
@@ -251,6 +251,8 @@ typedef struct InputFilter {
 int channels;
 uint64_t channel_layout;
 
+int32_t display_matrix[9];
+
 AVBufferRef *hw_frames_ctx;
 
 int eof;
diff --git a/fftools/ffmpeg_filter.c b/fftools/ffmpeg_filter.c
index 72838de1e2..1894f30561 100644
--- a/fftools/ffmpeg_filter.c
+++ b/fftools/ffmpeg_filter.c
@@ -328,6 +328,7 @@ static void init_input_filter(FilterGraph *fg, 
AVFilterInOut *in)
 fg->inputs[fg->nb_inputs - 1]->format = -1;
 fg->inputs[fg->nb_inputs - 1]->type = ist->st->codecpar->codec_type;
 fg->inputs[fg->nb_inputs - 1]->name = describe_filter_link(fg, in, 1);
+av_display_rotation_set(fg->inputs[fg->nb_inputs - 1]->display_matrix, 0);
 
 fg->inputs[fg->nb_inputs - 1]->frame_queue = av_fifo_alloc(8 * 
sizeof(AVFrame*));
 if (!fg->inputs[fg->nb_inputs - 1]->frame_queue)
@@ -807,22 +808,43 @@ static int configure_input_video_filter(FilterGraph *fg, 
InputFilter *ifilter,
 last_filter = ifilter->filter;
 
 if (ist->autorotate) {
-double theta = get_rotation(ist->st);
+int hflip = 0;
+double theta = get_rotation_hflip(ifilter->display_matrix, );
 
-if (fabs(theta - 90) < 1.0) {
+if (fabs(theta) < 1.0) {
+if (hflip)
+ret = insert_filter(_filter, _idx, "hflip", NULL);
+} else if (fabs(theta - 90) < 1.0) {
   

Re: [FFmpeg-devel] [PATCH v1] fftools/ffmpeg: Add support for per frame rotation and flip

[Jun Li]

On Sat, May 11, 2019 at 10:47 PM Jun Li  wrote:

> Fix #6945
> Current implementaion for autorotate works fine for stream
> level rotataion but no support for frame level operation
> and frame flip. This patch is for adding flip support and
> per frame operations.
> ---
>  fftools/cmdutils.c|  9 ++---
>  fftools/cmdutils.h|  2 +-
>  fftools/ffmpeg.c  | 21 +-
>  fftools/ffmpeg.h  |  2 +
>  fftools/ffmpeg_filter.c   | 81 ---
>  fftools/ffplay.c  | 28 +++---
>  libavutil/display.c   | 14 +++
>  libavutil/display.h   | 14 +++
>  libavutil/tests/display.c |  8 
>  tests/ref/fate/display|  4 ++
>  10 files changed, 166 insertions(+), 17 deletions(-)
>
> diff --git a/fftools/cmdutils.c b/fftools/cmdutils.c
> index 9cfbc45c2b..b8bb904419 100644
> --- a/fftools/cmdutils.c
> +++ b/fftools/cmdutils.c
> @@ -2172,13 +2172,12 @@ void *grow_array(void *array, int elem_size, int
> *size, int new_size)
>  return array;
>  }
>
> -double get_rotation(AVStream *st)
> +double get_rotation_hflip(int32_t display_matrix[9], int* hflip)
>  {
> -uint8_t* displaymatrix = av_stream_get_side_data(st,
> -
>  AV_PKT_DATA_DISPLAYMATRIX, NULL);
>  double theta = 0;
> -if (displaymatrix)
> -theta = -av_display_rotation_get((int32_t*) displaymatrix);
> +
> +if (display_matrix)
> +theta = -av_display_rotation_hflip_get(display_matrix, hflip);
>
>  theta -= 360*floor(theta/360 + 0.9/360);
>
> diff --git a/fftools/cmdutils.h b/fftools/cmdutils.h
> index 6e2e0a2acb..dce44ed6e1 100644
> --- a/fftools/cmdutils.h
> +++ b/fftools/cmdutils.h
> @@ -643,6 +643,6 @@ void *grow_array(void *array, int elem_size, int
> *size, int new_size);
>  char name[128];\
>  av_get_channel_layout_string(name, sizeof(name), 0, ch_layout);
>
> -double get_rotation(AVStream *st);
> +double get_rotation_hflip(int32_t display_matrix[9], int* hflip);
>
>  #endif /* FFTOOLS_CMDUTILS_H */
> diff --git a/fftools/ffmpeg.c b/fftools/ffmpeg.c
> index 01f04103cf..9ea1aaa930 100644
> --- a/fftools/ffmpeg.c
> +++ b/fftools/ffmpeg.c
> @@ -2126,6 +2126,24 @@ static int
> ifilter_has_all_input_formats(FilterGraph *fg)
>  return 1;
>  }
>
> +static int ifilter_display_matrix_need_from_frame(InputFilter *ifilter,
> AVFrame* frame)
> +{
> +int32_t* stream_matrix =
> (int32_t*)av_stream_get_side_data(ifilter->ist->st,
> +
> AV_PKT_DATA_DISPLAYMATRIX, NULL);
> +// if we already have display matrix from stream, use it instead of
> extracting
> +// from frame.
> +if (stream_matrix) {
> +memcpy(ifilter->display_matrix, stream_matrix, 4 * 9);
> +return 0;
> +}
> +
> +// cleanup the display matrix, may be from last frame
> +memset(ifilter->display_matrix, 0, 4 * 9);
> +av_display_rotation_set(ifilter->display_matrix, 0);
> +
> +return !!av_dict_get(frame->metadata, "Orientation", NULL, 0);
> +}
> +
>  static int ifilter_send_frame(InputFilter *ifilter, AVFrame *frame)
>  {
>  FilterGraph *fg = ifilter->graph;
> @@ -2141,7 +2159,8 @@ static int ifilter_send_frame(InputFilter *ifilter,
> AVFrame *frame)
> ifilter->channel_layout != frame->channel_layout;
>  break;
>  case AVMEDIA_TYPE_VIDEO:
> -need_reinit |= ifilter->width  != frame->width ||
> +need_reinit |= ifilter_display_matrix_need_from_frame(ifilter,
> frame) ||
> +   ifilter->width  != frame->width ||
> ifilter->height != frame->height;
>  break;
>  }
> diff --git a/fftools/ffmpeg.h b/fftools/ffmpeg.h
> index eb1eaf6363..8331720663 100644
> --- a/fftools/ffmpeg.h
> +++ b/fftools/ffmpeg.h
> @@ -251,6 +251,8 @@ typedef struct InputFilter {
>  int channels;
>  uint64_t channel_layout;
>
> +int32_t display_matrix[9];
> +
>  AVBufferRef *hw_frames_ctx;
>
>  int eof;
> diff --git a/fftools/ffmpeg_filter.c b/fftools/ffmpeg_filter.c
> index 72838de1e2..1894f30561 100644
> --- a/fftools/ffmpeg_filter.c
> +++ b/fftools/ffmpeg_filter.c
> @@ -328,6 +328,7 @@ static void init_input_filter(FilterGraph *fg,
> AVFilterInOut *in)
>  fg->inputs[fg->nb_inputs - 1]->format = -1;
>  fg->inputs[fg->nb_inputs - 1]->type = ist->st->codecpar->codec_type;
>  fg->inputs[fg->nb_inputs - 1]->name = describe_filter_link(fg, in, 1);
> +av_display_rotation_set(fg->inputs[fg->nb_inputs -
> 1]->display_matrix, 0);
>
>  fg->inputs[fg->nb_inputs - 1]->frame_queue = av_fifo_alloc(8 *
> sizeof(AVFrame*));
>  if (!fg->inputs[fg->nb_inputs - 1]->frame_queue)
> @@ -807,22 +808,43 @@ static int configure_input_video_filter(FilterGraph
> *fg, InputFilter *ifilter,
>  last_filter = ifilter->filter;
>
>  if (ist->autorotate) {
> -double theta = get_rotation(ist->st);
> +int hflip = 0;
> +double theta = get_rotation_hflip(ifilter->display_matrix,
> );
>
> -if (fabs(theta - 

[FFmpeg-devel] [PATCH] libavformat/utils: Interpolate missing timestamps in H264 and HEVC when no b-frames observed.

[Andriy Gelman]

From: Andriy Gelman 

Fixes Ticket #7895.

Currently, timestamp interpolation is disabled by default in H264 and
HEVC.  This creates playback issues when the demuxer does not output a
valid timestamp. This patch allows interpolation when no b-frames have
been observed during decoding, which fixes playback issues for some
missing timestamp cases.
---
 libavformat/utils.c | 11 +--
 1 file changed, 9 insertions(+), 2 deletions(-)

diff --git a/libavformat/utils.c b/libavformat/utils.c
index a63d71b0f4..0668ae3ad1 100644
--- a/libavformat/utils.c
+++ b/libavformat/utils.c
@@ -1233,7 +1233,9 @@ static void compute_pkt_fields(AVFormatContext *s, 
AVStream *st,
 int64_t offset;
 AVRational duration;
 int onein_oneout = st->codecpar->codec_id != AV_CODEC_ID_H264 &&
-   st->codecpar->codec_id != AV_CODEC_ID_HEVC;
+   st->codecpar->codec_id != AV_CODEC_ID_HEVC ||
+   (!st->internal->avctx->max_b_frames &&
+st->cur_dts != RELATIVE_TS_BASE);
 
 if (s->flags & AVFMT_FLAG_NOFILLIN)
 return;
@@ -1272,6 +1274,10 @@ static void compute_pkt_fields(AVFormatContext *s, 
AVStream *st,
 delay = st->internal->avctx->has_b_frames;
 presentation_delayed = 0;
 
+/*update max_b_frames if delay is larger */
+if (delay > st->internal->avctx->max_b_frames)
+  st->internal->avctx->max_b_frames = delay;
+
 /* XXX: need has_b_frame, but cannot get it if the codec is
  *  not initialized */
 if (delay &&
@@ -1337,7 +1343,8 @@ static void compute_pkt_fields(AVFormatContext *s, 
AVStream *st,
 presentation_delayed, av_ts2str(pkt->pts), av_ts2str(pkt->dts), 
av_ts2str(st->cur_dts),
 pkt->stream_index, pc, pkt->duration, delay, onein_oneout);
 
-/* Interpolate PTS and DTS if they are not present. We skip H264
+/* Interpolate PTS and DTS if they are not present. H264/HEVC timestamps 
are 
+ * interpolated only if no b-frames have been observed. Otherwise, we skip 
H264/HEVC
  * currently because delay and has_b_frames are not reliably set. */
 if ((delay == 0 || (delay == 1 && pc)) &&
 onein_oneout) {
-- 
2.21.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 1/3] avutil: Add NV24 and NV42 pixel formats

[Fu, Linjie]

> -Original Message-
> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf
> Of Carl Eugen Hoyos
> Sent: Sunday, May 12, 2019 06:25
> To: FFmpeg development discussions and patches  de...@ffmpeg.org>
> Subject: Re: [FFmpeg-devel] [PATCH 1/3] avutil: Add NV24 and NV42 pixel
> formats
> 
> Am Sa., 11. Mai 2019 um 20:32 Uhr schrieb Philip Langdale
> :
> >
> > These are the 4:4:4 variants of the semi-planar NV12/NV21 formats.
> >
> > These formats are not used much, so we've never had a reason to add
> > them until now. VDPAU recently added support HEVC 4:4:4 content
> > and when you use the OpenGL interop, the returned surfaces are in
> 
> I wonder if there is an "only" missing somewhere.
> 
> > NV24 format, so we need the pixel format for media players, even
> > if there's no direct use within ffmpeg.
> 
> Thank you!
> 
> > Separately, there are apparently webcams that use NV24, but I've
> > never seen one.
> 
> [...]
> 
> > diff --git a/libavutil/version.h b/libavutil/version.h
> > index c0968de621..4922e267cc 100644
> > --- a/libavutil/version.h
> > +++ b/libavutil/version.h
> > @@ -80,7 +80,7 @@
> >
> >  #define LIBAVUTIL_VERSION_MAJOR  56
> >  #define LIBAVUTIL_VERSION_MINOR  26
> > -#define LIBAVUTIL_VERSION_MICRO 101
> > +#define LIBAVUTIL_VERSION_MICRO 102
> 
> We typically raise minor for new pix_fmts, resetting
> micro was forgotten the last times afaict.
> 

Hi,

I'm working on adding support for HEVC 4:2:2/ 4:4:4, 8/10 bit, in vaapi 
decoding.
And I'm aslo thinking of add some new pix_fmt for packed FourCC:
444 8 bit :  AYUV
444 10 bit: Y410 
422 10 bit: Y210

So if I'd like to add these new pix_fmts, some modification is necessary too as 
far as I got from relevant threads:
1. add support in swscale for being able to convert to and from a format, 
including up and down scale;
2. add test.(maybe a query is needed too)
3. bump a new minor version.
Any other concerns should be followed?

I'm trying to make sure I understood this correctly.
Thanks in advance.

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

[FFmpeg-devel] [PATCH 1/3] avutil: Add NV24 and NV42 pixel formats

[Philip Langdale]

These are the 4:4:4 variants of the semi-planar NV12/NV21 formats.

These formats are not used much, so we've never had a reason to add
them until now. VDPAU recently added support HEVC 4:4:4 content
and when you use the OpenGL interop, the returned surfaces are in
NV24 format, so we need the pixel format for media players, even
if there's no direct use within ffmpeg.

Separately, there are apparently webcams that use NV24, but I've
never seen one.

Signed-off-by: Philip Langdale 
---
 libavutil/pixdesc.c   | 24 
 libavutil/pixfmt.h|  3 +++
 libavutil/tests/pixfmt_best.c |  1 +
 libavutil/version.h   |  2 +-
 4 files changed, 29 insertions(+), 1 deletion(-)

diff --git a/libavutil/pixdesc.c b/libavutil/pixdesc.c
index fe38344d73..b97b0665b0 100644
--- a/libavutil/pixdesc.c
+++ b/libavutil/pixdesc.c
@@ -2320,6 +2320,30 @@ static const AVPixFmtDescriptor 
av_pix_fmt_descriptors[AV_PIX_FMT_NB] = {
 },
 .flags = AV_PIX_FMT_FLAG_PLANAR | AV_PIX_FMT_FLAG_ALPHA,
 },
+[AV_PIX_FMT_NV24] = {
+.name = "nv24",
+.nb_components = 3,
+.log2_chroma_w = 0,
+.log2_chroma_h = 0,
+.comp = {
+{ 0, 1, 0, 0, 8, 0, 7, 1 },/* Y */
+{ 1, 2, 0, 0, 8, 1, 7, 1 },/* U */
+{ 1, 2, 1, 0, 8, 1, 7, 2 },/* V */
+},
+.flags = AV_PIX_FMT_FLAG_PLANAR,
+},
+[AV_PIX_FMT_NV42] = {
+.name = "nv42",
+.nb_components = 3,
+.log2_chroma_w = 0,
+.log2_chroma_h = 0,
+.comp = {
+{ 0, 1, 0, 0, 8, 0, 7, 1 },/* Y */
+{ 1, 2, 1, 0, 8, 1, 7, 2 },/* U */
+{ 1, 2, 0, 0, 8, 1, 7, 1 },/* V */
+},
+.flags = AV_PIX_FMT_FLAG_PLANAR,
+},
 };
 #if FF_API_PLUS1_MINUS1
 FF_ENABLE_DEPRECATION_WARNINGS
diff --git a/libavutil/pixfmt.h b/libavutil/pixfmt.h
index 24d1b7e415..8b54c9415b 100644
--- a/libavutil/pixfmt.h
+++ b/libavutil/pixfmt.h
@@ -345,6 +345,9 @@ enum AVPixelFormat {
 AV_PIX_FMT_YUVA444P12BE, ///< planar YUV 4:4:4,36bpp, (1 Cr & Cb sample 
per 1x1 Y samples), 12b alpha, big-endian
 AV_PIX_FMT_YUVA444P12LE, ///< planar YUV 4:4:4,36bpp, (1 Cr & Cb sample 
per 1x1 Y samples), 12b alpha, little-endian
 
+AV_PIX_FMT_NV24,  ///< planar YUV 4:4:4, 24bpp, 1 plane for Y and 1 
plane for the UV components, which are interleaved (first byte U and the 
following byte V)
+AV_PIX_FMT_NV42,  ///< as above, but U and V bytes are swapped
+
 AV_PIX_FMT_NB ///< number of pixel formats, DO NOT USE THIS if you 
want to link with shared libav* because the number of formats might differ 
between versions
 };
 
diff --git a/libavutil/tests/pixfmt_best.c b/libavutil/tests/pixfmt_best.c
index e98fcc19a5..53f7264207 100644
--- a/libavutil/tests/pixfmt_best.c
+++ b/libavutil/tests/pixfmt_best.c
@@ -76,6 +76,7 @@ int main(void)
 TEST(AV_PIX_FMT_P010,  AV_PIX_FMT_YUV420P10);
 TEST(AV_PIX_FMT_P016,  AV_PIX_FMT_YUV420P16);
 TEST(AV_PIX_FMT_NV16,  AV_PIX_FMT_YUV422P);
+TEST(AV_PIX_FMT_NV24,  AV_PIX_FMT_YUV444P);
 TEST(AV_PIX_FMT_YUYV422,   AV_PIX_FMT_YUV422P);
 TEST(AV_PIX_FMT_UYVY422,   AV_PIX_FMT_YUV422P);
 TEST(AV_PIX_FMT_BGR565,AV_PIX_FMT_RGB565);
diff --git a/libavutil/version.h b/libavutil/version.h
index c0968de621..4922e267cc 100644
--- a/libavutil/version.h
+++ b/libavutil/version.h
@@ -80,7 +80,7 @@
 
 #define LIBAVUTIL_VERSION_MAJOR  56
 #define LIBAVUTIL_VERSION_MINOR  26
-#define LIBAVUTIL_VERSION_MICRO 101
+#define LIBAVUTIL_VERSION_MICRO 102
 
 #define LIBAVUTIL_VERSION_INT   AV_VERSION_INT(LIBAVUTIL_VERSION_MAJOR, \
LIBAVUTIL_VERSION_MINOR, \
-- 
2.20.1

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

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

[FFmpeg-devel] [PATCH 3/3] swscale: Add test for isSemiPlanarYUV to pixdesc_query

[Philip Langdale]

Lauri had asked me what the semi planar formats were and that reminded
me that we could add it to pixdesc_query so we know exactly what the
list is.

Signed-off-by: Philip Langdale 
---
 libswscale/tests/pixdesc_query.c |  1 +
 tests/ref/fate/sws-pixdesc-query | 13 +
 2 files changed, 14 insertions(+)

diff --git a/libswscale/tests/pixdesc_query.c b/libswscale/tests/pixdesc_query.c
index a5585c4314..f6dd8bae68 100644
--- a/libswscale/tests/pixdesc_query.c
+++ b/libswscale/tests/pixdesc_query.c
@@ -32,6 +32,7 @@ static const struct {
 {"isBE",isBE},
 {"isYUV",   isYUV},
 {"isPlanarYUV", isPlanarYUV},
+{"isSemiPlanarYUV", isSemiPlanarYUV},
 {"isRGB",   isRGB},
 {"Gray",isGray},
 {"RGBinInt",isRGBinInt},
diff --git a/tests/ref/fate/sws-pixdesc-query b/tests/ref/fate/sws-pixdesc-query
index bc8147e3c7..e23492293e 100644
--- a/tests/ref/fate/sws-pixdesc-query
+++ b/tests/ref/fate/sws-pixdesc-query
@@ -347,6 +347,19 @@ isPlanarYUV:
   yuvj440p
   yuvj444p
 
+isSemiPlanarYUV:
+  nv12
+  nv16
+  nv20be
+  nv20le
+  nv21
+  nv24
+  nv42
+  p010be
+  p010le
+  p016be
+  p016le
+
 isRGB:
   0bgr
   0rgb
-- 
2.20.1

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

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

[FFmpeg-devel] [PATCH 2/3] swscale: Add support for NV24 and NV42

[Philip Langdale]

For the sake of completeness, I'm added NV24/NV42 support to swscale,
but the specific use-case I noted when adding the pixel formats
doesn't require swscale support (because it's OpenGL interop).

The implementation is pretty straight-forward. Most of the existing
NV12 codepaths work regardless of subsampling and are re-used as is.
Where necessary I wrote the slightly different NV24 versions.

Finally, the one thing that confused me for a long time was the
asm specific x86 path that did an explicit exclusion check for NV12.
I replaced that with a semi-planar check and also updated the
equivalent PPC code, which Lauri kindly checked.

Signed-off-by: Philip Langdale 
---
 libswscale/input.c   |  2 +
 libswscale/output.c  |  6 ++-
 libswscale/ppc/swscale_altivec.c |  3 +-
 libswscale/ppc/swscale_vsx.c |  3 +-
 libswscale/swscale_unscaled.c| 51 
 libswscale/utils.c   |  2 +
 libswscale/version.h |  2 +-
 libswscale/x86/swscale_template.c|  4 +-
 tests/ref/fate/filter-pixfmts-copy   |  2 +
 tests/ref/fate/filter-pixfmts-crop   |  2 +
 tests/ref/fate/filter-pixfmts-field  |  2 +
 tests/ref/fate/filter-pixfmts-fieldorder |  2 +
 tests/ref/fate/filter-pixfmts-hflip  |  2 +
 tests/ref/fate/filter-pixfmts-il |  2 +
 tests/ref/fate/filter-pixfmts-null   |  2 +
 tests/ref/fate/filter-pixfmts-pad|  2 +
 tests/ref/fate/filter-pixfmts-scale  |  2 +
 tests/ref/fate/filter-pixfmts-transpose  |  2 +
 tests/ref/fate/filter-pixfmts-vflip  |  2 +
 tests/ref/fate/sws-pixdesc-query |  6 +++
 20 files changed, 92 insertions(+), 9 deletions(-)

diff --git a/libswscale/input.c b/libswscale/input.c
index c2dc356b5d..064f8da314 100644
--- a/libswscale/input.c
+++ b/libswscale/input.c
@@ -1020,9 +1020,11 @@ av_cold void ff_sws_init_input_funcs(SwsContext *c)
 c->chrToYV12 = uyvyToUV_c;
 break;
 case AV_PIX_FMT_NV12:
+case AV_PIX_FMT_NV24:
 c->chrToYV12 = nv12ToUV_c;
 break;
 case AV_PIX_FMT_NV21:
+case AV_PIX_FMT_NV42:
 c->chrToYV12 = nv21ToUV_c;
 break;
 case AV_PIX_FMT_RGB8:
diff --git a/libswscale/output.c b/libswscale/output.c
index d3401f0cd1..26b0ff3d48 100644
--- a/libswscale/output.c
+++ b/libswscale/output.c
@@ -410,7 +410,8 @@ static void yuv2nv12cX_c(SwsContext *c, const int16_t 
*chrFilter, int chrFilterS
 const uint8_t *chrDither = c->chrDither8;
 int i;
 
-if (dstFormat == AV_PIX_FMT_NV12)
+if (dstFormat == AV_PIX_FMT_NV12 ||
+dstFormat == AV_PIX_FMT_NV24)
 for (i=0; isrcBpc == 8 && c->dstBpc <= 14) {
 c->hyScale = c->hcScale = hScale_real_altivec;
 }
-if (!is16BPS(dstFormat) && !isNBPS(dstFormat) &&
-dstFormat != AV_PIX_FMT_NV12 && dstFormat != AV_PIX_FMT_NV21 &&
+if (!is16BPS(dstFormat) && !isNBPS(dstFormat) && 
!isSemiPlanarYUV(dstFormat) &&
 dstFormat != AV_PIX_FMT_GRAYF32BE && dstFormat != AV_PIX_FMT_GRAYF32LE 
&&
 !c->needAlpha) {
 c->yuv2planeX = yuv2planeX_altivec;
diff --git a/libswscale/ppc/swscale_vsx.c b/libswscale/ppc/swscale_vsx.c
index a617f76741..75dee5ea58 100644
--- a/libswscale/ppc/swscale_vsx.c
+++ b/libswscale/ppc/swscale_vsx.c
@@ -2096,8 +2096,7 @@ av_cold void ff_sws_init_swscale_vsx(SwsContext *c)
  : hScale16To15_vsx;
 }
 }
-if (!is16BPS(dstFormat) && !isNBPS(dstFormat) &&
-dstFormat != AV_PIX_FMT_NV12 && dstFormat != AV_PIX_FMT_NV21 &&
+if (!is16BPS(dstFormat) && !isNBPS(dstFormat) && 
!isSemiPlanarYUV(dstFormat) &&
 dstFormat != AV_PIX_FMT_GRAYF32BE && dstFormat != AV_PIX_FMT_GRAYF32LE 
&&
 !c->needAlpha) {
 c->yuv2planeX = yuv2planeX_vsx;
diff --git a/libswscale/swscale_unscaled.c b/libswscale/swscale_unscaled.c
index be04a236d8..d7cc0bd4c5 100644
--- a/libswscale/swscale_unscaled.c
+++ b/libswscale/swscale_unscaled.c
@@ -180,6 +180,47 @@ static int nv12ToPlanarWrapper(SwsContext *c, const 
uint8_t *src[],
 return srcSliceH;
 }
 
+static int planarToNv24Wrapper(SwsContext *c, const uint8_t *src[],
+   int srcStride[], int srcSliceY,
+   int srcSliceH, uint8_t *dstParam[],
+   int dstStride[])
+{
+uint8_t *dst = dstParam[1] + dstStride[1] * srcSliceY;
+
+copyPlane(src[0], srcStride[0], srcSliceY, srcSliceH, c->srcW,
+  dstParam[0], dstStride[0]);
+
+if (c->dstFormat == AV_PIX_FMT_NV24)
+interleaveBytes(src[1], src[2], dst, c->chrSrcW, (srcSliceH + 1),
+srcStride[1], srcStride[2], dstStride[1]);
+else
+interleaveBytes(src[2], src[1], dst, c->chrSrcW, (srcSliceH + 1),
+srcStride[2], srcStride[1], dstStride[1]);
+
+return srcSliceH;
+}
+
+static int 

Re: [FFmpeg-devel] [PATCH] ffplay: added option always on top for video window

[Daniel Kučera]

Dňa so 11. 5. 2019, 18:00 Gyan  napísal(a):

>
>
> On 11-05-2019 09:03 PM, Michael Niedermayer wrote:
> > On Fri, May 10, 2019 at 12:12:17PM +0200, Daniel Kucera wrote:
> >> From: Daniel Kucera 
> >>
> >> Signed-off-by: Daniel Kucera 
> >> ---
> >>   doc/ffplay.texi  | 2 ++
> >>   fftools/ffplay.c | 4 
> >>   2 files changed, 6 insertions(+)
> >>
> >> diff --git a/doc/ffplay.texi b/doc/ffplay.texi
> >> index c305465078..a37c02dc0d 100644
> >> --- a/doc/ffplay.texi
> >> +++ b/doc/ffplay.texi
> >> @@ -66,6 +66,8 @@ Set custom interval, in seconds, for seeking using
> left/right keys. Default is 1
> >>   Disable graphical display.
> >>   @item -noborder
> >>   Borderless window.
> >> +@item -alwaysontop
> >> +Window always on top.
> >>   @item -volume
> >>   Set the startup volume. 0 means silence, 100 means no volume
> reduction or
> >>   amplification. Negative values are treated as 0, values above 100 are
> treated
> >> diff --git a/fftools/ffplay.c b/fftools/ffplay.c
> >> index 8f050e16e6..931dc08e2d 100644
> >> --- a/fftools/ffplay.c
> >> +++ b/fftools/ffplay.c
> >> @@ -324,6 +324,7 @@ static int seek_by_bytes = -1;
> >>   static float seek_interval = 10;
> >>   static int display_disable;
> >>   static int borderless;
> >> +static int alwaysontop;
> >>   static int startup_volume = 100;
> >>   static int show_status = 1;
> >>   static int av_sync_type = AV_SYNC_AUDIO_MASTER;
> >> @@ -3581,6 +3582,7 @@ static const OptionDef options[] = {
> >>   { "seek_interval", OPT_FLOAT | HAS_ARG, { _interval }, "set
> seek interval for left/right keys, in seconds", "seconds" },
> >>   { "nodisp", OPT_BOOL, { _disable }, "disable graphical
> display" },
> >>   { "noborder", OPT_BOOL, {  }, "borderless window" },
> >> +{ "alwaysontop", OPT_BOOL, {  }, "window always on
> top" },
> >>   { "volume", OPT_INT | HAS_ARG, { _volume}, "set startup
> volume 0=min 100=max", "volume" },
> >>   { "f", HAS_ARG, { .func_arg = opt_format }, "force format", "fmt"
> },
> >>   { "pix_fmt", HAS_ARG | OPT_EXPERT | OPT_VIDEO, { .func_arg =
> opt_frame_pix_fmt }, "set pixel format", "format" },
> >> @@ -3722,6 +3724,8 @@ int main(int argc, char **argv)
> >>
> >>   if (!display_disable) {
> >>   int flags = SDL_WINDOW_HIDDEN;
> >> +if (alwaysontop)
> >> +flags |= SDL_WINDOW_ALWAYS_ON_TOP;
> > fails to build
> >
> > fftools/ffplay.c: In function ‘main’:
> > fftools/ffplay.c:3728:22: error: ‘SDL_WINDOW_ALWAYS_ON_TOP’ undeclared
> (first use in this function)
> >   flags |= SDL_WINDOW_ALWAYS_ON_TOP;
>
> Is qualified as 'X11 only, >= SDL 2.0.5' at
> https://wiki.libsdl.org/SDL_WindowFlags
>
> Gyan
>

Since 2.0.6 it works on Windows too.

>
___
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 0/3] NV24/NV42 support

[Philip Langdale]

As I had to post an update, I've collected the changes together for
convenience.

Philip Langdale (3):
  avutil: Add NV24 and NV42 pixel formats
  swscale: Add support for NV24 and NV42
  swscale: Add test for isSemiPlanarYUV to pixdesc_query

 libavutil/pixdesc.c  | 24 +++
 libavutil/pixfmt.h   |  3 ++
 libavutil/tests/pixfmt_best.c|  1 +
 libavutil/version.h  |  2 +-
 libswscale/input.c   |  2 +
 libswscale/output.c  |  6 ++-
 libswscale/ppc/swscale_altivec.c |  3 +-
 libswscale/ppc/swscale_vsx.c |  3 +-
 libswscale/swscale_unscaled.c| 51 
 libswscale/tests/pixdesc_query.c |  1 +
 libswscale/utils.c   |  2 +
 libswscale/version.h |  2 +-
 libswscale/x86/swscale_template.c|  4 +-
 tests/ref/fate/filter-pixfmts-copy   |  2 +
 tests/ref/fate/filter-pixfmts-crop   |  2 +
 tests/ref/fate/filter-pixfmts-field  |  2 +
 tests/ref/fate/filter-pixfmts-fieldorder |  2 +
 tests/ref/fate/filter-pixfmts-hflip  |  2 +
 tests/ref/fate/filter-pixfmts-il |  2 +
 tests/ref/fate/filter-pixfmts-null   |  2 +
 tests/ref/fate/filter-pixfmts-pad|  2 +
 tests/ref/fate/filter-pixfmts-scale  |  2 +
 tests/ref/fate/filter-pixfmts-transpose  |  2 +
 tests/ref/fate/filter-pixfmts-vflip  |  2 +
 tests/ref/fate/sws-pixdesc-query | 19 +
 25 files changed, 135 insertions(+), 10 deletions(-)

-- 
2.20.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] Add S12M Timecode output as side data with -show_frame option (such as SEI TC)

[Antonin Gouzer]

---
 fftools/ffprobe.c | 8 
 1 file changed, 8 insertions(+)

diff --git a/fftools/ffprobe.c b/fftools/ffprobe.c
index dea489d02e..4763ce6d98 100644
--- a/fftools/ffprobe.c
+++ b/fftools/ffprobe.c
@@ -2199,6 +2199,14 @@ static void show_frame(WriterContext *w, AVFrame *frame, 
AVStream *stream,
 char tcbuf[AV_TIMECODE_STR_SIZE];
 av_timecode_make_mpeg_tc_string(tcbuf, *(int64_t *)(sd->data));
 print_str("timecode", tcbuf);
+} else if (sd->type == AV_FRAME_DATA_S12M_TIMECODE && sd->size >= 
8) {
+uint32_t *tc = (uint32_t*)sd->data;
+for (int j = 1; j <= tc[0]; j++) {
+char tcbuf[AV_TIMECODE_STR_SIZE];
+av_timecode_make_smpte_tc_string(tcbuf, tc[j], 0);
+print_str("timecode", tcbuf);
+}
+break;
 } else if (sd->type == AV_FRAME_DATA_MASTERING_DISPLAY_METADATA) {
 AVMasteringDisplayMetadata *metadata = 
(AVMasteringDisplayMetadata *)sd->data;
 
-- 
2.11.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] Add S12M Timecode output as side data with -show_frame option (such as SEI TC)

[Antonin Gouzer]

Hello,
Sorry for the first mail which was an error.
This patch just add the SEI Timecode output of H264 files as side data
in ffprobe (-show_frame).
This has been already implemented in the shwoinfo video filter but not
in ffprobe.

Thanks in advance.


Le sam. 11 mai 2019 à 21:24, Antonin Gouzer  a écrit :
>
> From: agouzer 
>
> ---
>  fftools/ffprobe.c | 8 +---
>  1 file changed, 5 insertions(+), 3 deletions(-)
>
> diff --git a/fftools/ffprobe.c b/fftools/ffprobe.c
> index 52e9bbf544..4763ce6d98 100644
> --- a/fftools/ffprobe.c
> +++ b/fftools/ffprobe.c
> @@ -2200,11 +2200,13 @@ static void show_frame(WriterContext *w, AVFrame 
> *frame, AVStream *stream,
>  av_timecode_make_mpeg_tc_string(tcbuf, *(int64_t 
> *)(sd->data));
>  print_str("timecode", tcbuf);
>  } else if (sd->type == AV_FRAME_DATA_S12M_TIMECODE && sd->size 
> >= 8) {
> -uint32_t *tc_sd;
> -tc_sd = (uint32_t*)sd->data;
> +uint32_t *tc = (uint32_t*)sd->data;
> +for (int j = 1; j <= tc[0]; j++) {
>  char tcbuf[AV_TIMECODE_STR_SIZE];
> -av_timecode_make_smpte_tc_string(tcbuf, tc_sd[1],0);
> +av_timecode_make_smpte_tc_string(tcbuf, tc[j], 0);
>  print_str("timecode", tcbuf);
> +}
> +break;
>  } else if (sd->type == AV_FRAME_DATA_MASTERING_DISPLAY_METADATA) 
> {
>  AVMasteringDisplayMetadata *metadata = 
> (AVMasteringDisplayMetadata *)sd->data;
>
> --
> 2.11.0
>
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

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

[FFmpeg-devel] [PATCH] avcodec/hq_hqa: Check available space before reading slice offsets

[Michael Niedermayer]

Fixes: Timeout (43sec -> 18sec)
Fixes: 
14556/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_HQ_HQA_fuzzer-5673543024508928

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

diff --git a/libavcodec/hq_hqa.c b/libavcodec/hq_hqa.c
index ec9da3e04f..90bafdc72a 100644
--- a/libavcodec/hq_hqa.c
+++ b/libavcodec/hq_hqa.c
@@ -248,6 +248,9 @@ static int hqa_decode_frame(HQContext *ctx, AVFrame *pic, 
size_t data_size)
 int width, height, quant;
 const uint8_t *src = ctx->gbc.buffer;
 
+if (bytestream2_get_bytes_left(>gbc) < 8 + 4*(num_slices + 1))
+return AVERROR_INVALIDDATA;
+
 width  = bytestream2_get_be16(>gbc);
 height = bytestream2_get_be16(>gbc);
 
-- 
2.21.0

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

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

[FFmpeg-devel] [PATCH] avcodec/h264_ps: Check offset_for_non_ref_pic and offset_for_top_to_bottom_field

[Michael Niedermayer]

Fixes: signed integer overflow: -2147483648 + -1 cannot be represented in type 
'int'
Fixes: 
1/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_H264_fuzzer-5675880333967360

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

diff --git a/libavcodec/h264_ps.c b/libavcodec/h264_ps.c
index 7c92c68b38..e38cf2a533 100644
--- a/libavcodec/h264_ps.c
+++ b/libavcodec/h264_ps.c
@@ -451,6 +451,15 @@ int ff_h264_decode_seq_parameter_set(GetBitContext *gb, 
AVCodecContext *avctx,
 sps->delta_pic_order_always_zero_flag = get_bits1(gb);
 sps->offset_for_non_ref_pic   = get_se_golomb_long(gb);
 sps->offset_for_top_to_bottom_field   = get_se_golomb_long(gb);
+
+if (   sps->offset_for_non_ref_pic == INT32_MIN
+|| sps->offset_for_top_to_bottom_field == INT32_MIN
+) {
+av_log(avctx, AV_LOG_ERROR,
+   "offset_for_non_ref_pic or offset_for_top_to_bottom_field 
underflow\n");
+goto fail;
+}
+
 sps->poc_cycle_length = get_ue_golomb(gb);
 
 if ((unsigned)sps->poc_cycle_length >=
-- 
2.21.0

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

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

[FFmpeg-devel] [PATCH][TESTERS WANTED] avfilter: add apitch filter

[Paul B Mahol]

Signed-off-by: Paul B Mahol 
---

This filter can dynamically change both tempo and pitch of audio.
Also scale range is bigger, from 0.01 to 100.

---
 libavfilter/Makefile |   1 +
 libavfilter/af_apitch.c  | 764 +++
 libavfilter/allfilters.c |   1 +
 3 files changed, 766 insertions(+)
 create mode 100644 libavfilter/af_apitch.c

diff --git a/libavfilter/Makefile b/libavfilter/Makefile
index b41304d480..3662d50ae0 100644
--- a/libavfilter/Makefile
+++ b/libavfilter/Makefile
@@ -68,6 +68,7 @@ OBJS-$(CONFIG_ANULL_FILTER)  += af_anull.o
 OBJS-$(CONFIG_APAD_FILTER)   += af_apad.o
 OBJS-$(CONFIG_APERMS_FILTER) += f_perms.o
 OBJS-$(CONFIG_APHASER_FILTER)+= af_aphaser.o 
generate_wave_table.o
+OBJS-$(CONFIG_APITCH_FILTER) += af_apitch.o
 OBJS-$(CONFIG_APULSATOR_FILTER)  += af_apulsator.o
 OBJS-$(CONFIG_AREALTIME_FILTER)  += f_realtime.o
 OBJS-$(CONFIG_ARESAMPLE_FILTER)  += af_aresample.o
diff --git a/libavfilter/af_apitch.c b/libavfilter/af_apitch.c
new file mode 100644
index 00..406951576b
--- /dev/null
+++ b/libavfilter/af_apitch.c
@@ -0,0 +1,764 @@
+/*
+ * Copyright (c) 2019 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 "libswresample/swresample.h"
+#include "libavutil/avassert.h"
+#include "libavutil/avstring.h"
+#include "libavutil/audio_fifo.h"
+#include "libavfilter/internal.h"
+#include "libavutil/common.h"
+#include "libavutil/opt.h"
+#include "libavcodec/avfft.h"
+#include "filters.h"
+#include "audio.h"
+
+typedef struct APitchContext {
+const AVClass *class;
+
+float pitch;
+float tempo;
+int window_size;
+int ratio;
+
+int power_change;
+int fft_bits;
+int nb_channels;
+
+FFTContext *fft, *ifft;
+AVAudioFifo *ififo;
+int64_t pts;
+int eof;
+float *window_func_lut;
+
+AVFrame *buffer;
+AVFrame *magnitude;
+AVFrame *phase;
+AVFrame *acc;
+AVFrame *new_phase;
+AVFrame *last_phase;
+AVFrame *osamples;
+AVFrame *peaks;
+AVFrame *map;
+
+int   input_overlap;
+int   output_overlap;
+int   samples_to_drain;
+float last_power;
+
+intflushed;
+intpitch_changed;
+struct SwrContext *swr;
+} APitchContext;
+
+#define OFFSET(x) offsetof(APitchContext, x)
+#define AF AV_OPT_FLAG_AUDIO_PARAM|AV_OPT_FLAG_FILTERING_PARAM
+
+static const AVOption apitch_options[] = {
+{ "pitch","set pitch scale factor", OFFSET(pitch),   
AV_OPT_TYPE_FLOAT, {.dbl=1},.01,   100, AF },
+{ "tempo","set tempo scale factor", OFFSET(tempo),   
AV_OPT_TYPE_FLOAT, {.dbl=1},.01,   100, AF },
+{ "oratio",   "set overlap ratio",  OFFSET(ratio),   
AV_OPT_TYPE_INT,   {.i64=4}, 1, 64, AF },
+{ NULL },
+};
+
+AVFILTER_DEFINE_CLASS(apitch);
+
+static int set_input_overlap(APitchContext *s, float rate)
+{
+s->input_overlap = s->output_overlap * rate;
+if (s->input_overlap <= 0)
+return AVERROR(EINVAL);
+return 0;
+}
+
+static int config_output(AVFilterLink *outlink)
+{
+AVFilterContext *ctx = outlink->src;
+AVFilterLink *inlink = ctx->inputs[0];
+APitchContext *s = ctx->priv;
+int ret;
+
+s->swr = swr_alloc();
+if (!s->swr)
+return AVERROR(ENOMEM);
+
+s->swr = swr_alloc_set_opts(s->swr,
+inlink->channel_layout, inlink->format, 
inlink->sample_rate,
+inlink->channel_layout, inlink->format, 
inlink->sample_rate * s->pitch,
+0, ctx);
+if (!s->swr)
+return AVERROR(ENOMEM);
+
+ret = swr_init(s->swr);
+if (ret < 0)
+return ret;
+
+s->window_size = inlink->sample_rate / 10;
+s->power_change = 1;
+s->pts  = AV_NOPTS_VALUE;
+s->fft_bits = av_log2(s->window_size);
+s->fft  = av_fft_init(s->fft_bits, 0);
+s->ifft = av_fft_init(s->fft_bits, 1);
+if (!s->fft || !s->ifft)
+return AVERROR(ENOMEM);
+
+s->window_size = 1 << s->fft_bits;
+
+s->ratio = FFMIN(1 << av_log2(s->ratio), s->window_size >> 1);
+s->nb_channels = outlink->channels;
+
+s->ififo = 

Re: [FFmpeg-devel] [PATCH v2] libavutil: add an FFT & MDCT implementation

[Carl Eugen Hoyos]

Am Sa., 11. Mai 2019 um 14:41 Uhr schrieb Lynne :
>
> May 10, 2019, 8:59 PM by ceffm...@gmail.com:
>
> > Am Fr., 10. Mai 2019 um 19:54 Uhr schrieb Lynne <> d...@lynne.ee 
> > > >:
> >
> >>
> >> May 10, 2019, 4:14 PM by >> d...@lynne.ee >> :
> >>
> >> > Patch updated again.
> >> > Made some more cleanups to the transforms, the tables and the main 
> >> > context.
> >> > API changed again, now the init function populates the function pointer 
> >> > for transform.
> >> > I decided that having a separate function would encourage bad usage 
> >> > (e.g. calling
> >> > the function every time before doing a transform rather than storing the 
> >> > pointer) when
> >> > we're trying to avoid the overhead of function calls.
> >> > Also adjusted file names to match the API.
> >> >
> >>
> >> Forgot to change an include, new patch attached.
> >>
> >
> > If I understand the commit message correctly, some of the code
> > in the new file you are adding comes from other parts of FFmpeg.
> > I am surprised that there is no copyright claim on the top of this
> > new file.
> > Is there none on top of the files you took the code from?
> >
>
> The project isn't consistent with updating nor putting copyright headers on 
> files so
> I'd rather keep the headers clean. Commit messages and authors are the only 
> way to
> know who authored what.

I don't think this is correct, but that is not the question: Copyright
law is (at least here)
very clear, if somebody put his name on top of the file, you must not remove it,
especially not when moving code from one file into another.

> I could credit the authors fully in the commit message, then authorship can 
> still be
> tracked and the headers will be clean.

There is nothing wrong with putting the authors in the commit message, this can
not replace the notice on top of the files though.

This of course only applies if there is such a notice in existing
files from which
you move or copy code.

Carl Eugen
___
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] libavutil: add an FFT & MDCT implementation

[Lynne]

May 11, 2019, 11:08 PM by ceffm...@gmail.com:

> Am Sa., 11. Mai 2019 um 14:41 Uhr schrieb Lynne <> d...@lynne.ee 
> > >:
>
>>
>> May 10, 2019, 8:59 PM by >> ceffm...@gmail.com >> 
>> :
>>
>> > Am Fr., 10. Mai 2019 um 19:54 Uhr schrieb Lynne <> >> d...@lynne.ee 
>> > >>  > d...@lynne.ee 
>> > >> >> >:
>> >
>> >>
>> >> May 10, 2019, 4:14 PM by >> >> d...@lynne.ee >>  
>> >> > d...@lynne.ee >> >>> :
>> >>
>> >> > Patch updated again.
>> >> > Made some more cleanups to the transforms, the tables and the main 
>> >> > context.
>> >> > API changed again, now the init function populates the function pointer 
>> >> > for transform.
>> >> > I decided that having a separate function would encourage bad usage 
>> >> > (e.g. calling
>> >> > the function every time before doing a transform rather than storing 
>> >> > the pointer) when
>> >> > we're trying to avoid the overhead of function calls.
>> >> > Also adjusted file names to match the API.
>> >> >
>> >>
>> >> Forgot to change an include, new patch attached.
>> >>
>> >
>> > If I understand the commit message correctly, some of the code
>> > in the new file you are adding comes from other parts of FFmpeg.
>> > I am surprised that there is no copyright claim on the top of this
>> > new file.
>> > Is there none on top of the files you took the code from?
>> >
>>
>> The project isn't consistent with updating nor putting copyright headers on 
>> files so
>> I'd rather keep the headers clean. Commit messages and authors are the only 
>> way to
>> know who authored what.
>>
>
> I don't think this is correct, but that is not the question: Copyright
> law is (at least here)
> very clear, if somebody put his name on top of the file, you must not remove 
> it,
> especially not when moving code from one file into another.
>

"Here"? You're probably referring to some county's laws, those don't apply 
universally,
especially not to the internet.
Either way, that rule hasn't really been respected despite the major 
refactoring that has
happened in the past so I don't see why it has to be respected now.
The only parts I didn't rewrite are the power of two FFT, which I can NIH in a 
week if
necessary, and in fact lately with the research papers I've recently read I'm 
thinking
I should.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

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

[FFmpeg-devel] [PATCH] Add S12M Timecode output as side data with -show_frame option (such as SEI TC)

[Antonin Gouzer]

From: agouzer 

---
 fftools/ffprobe.c | 8 +---
 1 file changed, 5 insertions(+), 3 deletions(-)

diff --git a/fftools/ffprobe.c b/fftools/ffprobe.c
index 52e9bbf544..4763ce6d98 100644
--- a/fftools/ffprobe.c
+++ b/fftools/ffprobe.c
@@ -2200,11 +2200,13 @@ static void show_frame(WriterContext *w, AVFrame 
*frame, AVStream *stream,
 av_timecode_make_mpeg_tc_string(tcbuf, *(int64_t *)(sd->data));
 print_str("timecode", tcbuf);
 } else if (sd->type == AV_FRAME_DATA_S12M_TIMECODE && sd->size >= 
8) {
-uint32_t *tc_sd;
-tc_sd = (uint32_t*)sd->data;
+uint32_t *tc = (uint32_t*)sd->data;
+for (int j = 1; j <= tc[0]; j++) {
 char tcbuf[AV_TIMECODE_STR_SIZE];
-av_timecode_make_smpte_tc_string(tcbuf, tc_sd[1],0);
+av_timecode_make_smpte_tc_string(tcbuf, tc[j], 0);
 print_str("timecode", tcbuf);
+}
+break;
 } else if (sd->type == AV_FRAME_DATA_MASTERING_DISPLAY_METADATA) {
 AVMasteringDisplayMetadata *metadata = 
(AVMasteringDisplayMetadata *)sd->data;
 
-- 
2.11.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 1/3] avutil: Add NV24 and NV42 pixel formats

[Carl Eugen Hoyos]

Am Sa., 11. Mai 2019 um 20:32 Uhr schrieb Philip Langdale :
>
> These are the 4:4:4 variants of the semi-planar NV12/NV21 formats.
>
> These formats are not used much, so we've never had a reason to add
> them until now. VDPAU recently added support HEVC 4:4:4 content
> and when you use the OpenGL interop, the returned surfaces are in

I wonder if there is an "only" missing somewhere.

> NV24 format, so we need the pixel format for media players, even
> if there's no direct use within ffmpeg.

Thank you!

> Separately, there are apparently webcams that use NV24, but I've
> never seen one.

[...]

> diff --git a/libavutil/version.h b/libavutil/version.h
> index c0968de621..4922e267cc 100644
> --- a/libavutil/version.h
> +++ b/libavutil/version.h
> @@ -80,7 +80,7 @@
>
>  #define LIBAVUTIL_VERSION_MAJOR  56
>  #define LIBAVUTIL_VERSION_MINOR  26
> -#define LIBAVUTIL_VERSION_MICRO 101
> +#define LIBAVUTIL_VERSION_MICRO 102

We typically raise minor for new pix_fmts, resetting
micro was forgotten the last times afaict.

Carl Eugen
___
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] libavutil: add an FFT & MDCT implementation

[Carl Eugen Hoyos]

Am So., 12. Mai 2019 um 01:00 Uhr schrieb Lynne :
>
> May 11, 2019, 11:08 PM by ceffm...@gmail.com:
>
> > Am Sa., 11. Mai 2019 um 14:41 Uhr schrieb Lynne <> d...@lynne.ee 
> > > >:
> >
> >>
> >> May 10, 2019, 8:59 PM by >> ceffm...@gmail.com 
> >> >> :
> >>
> >> > Am Fr., 10. Mai 2019 um 19:54 Uhr schrieb Lynne <> >> d...@lynne.ee 
> >> > >>  > d...@lynne.ee 
> >> > >> >> >:
> >> >
> >> >>
> >> >> May 10, 2019, 4:14 PM by >> >> d...@lynne.ee >>  
> >> >> > d...@lynne.ee >> >>> :
> >> >>
> >> >> > Patch updated again.
> >> >> > Made some more cleanups to the transforms, the tables and the main 
> >> >> > context.
> >> >> > API changed again, now the init function populates the function 
> >> >> > pointer for transform.
> >> >> > I decided that having a separate function would encourage bad usage 
> >> >> > (e.g. calling
> >> >> > the function every time before doing a transform rather than storing 
> >> >> > the pointer) when
> >> >> > we're trying to avoid the overhead of function calls.
> >> >> > Also adjusted file names to match the API.
> >> >> >
> >> >>
> >> >> Forgot to change an include, new patch attached.
> >> >>
> >> >
> >> > If I understand the commit message correctly, some of the code
> >> > in the new file you are adding comes from other parts of FFmpeg.
> >> > I am surprised that there is no copyright claim on the top of this
> >> > new file.
> >> > Is there none on top of the files you took the code from?
> >> >
> >>
> >> The project isn't consistent with updating nor putting copyright headers 
> >> on files so
> >> I'd rather keep the headers clean. Commit messages and authors are the 
> >> only way to
> >> know who authored what.
> >>
> >
> > I don't think this is correct, but that is not the question: Copyright
> > law is (at least here)
> > very clear, if somebody put his name on top of the file, you must not 
> > remove it,
> > especially not when moving code from one file into another.
> >
>
> "Here"? You're probably referring to some county's laws, those don't apply 
> universally,
> especially not to the internet.
> Either way, that rule hasn't really been respected despite the major 
> refactoring that has
> happened in the past so I don't see why it has to be respected now.

Please point me to the commit you indicate so I can fix this (claimed) copyright
violation.

> The only parts I didn't rewrite are the power of two FFT, which I can NIH in 
> a week if
> necessary, and in fact lately with the research papers I've recently read I'm 
> thinking
> I should.

Why don't you simply copy the copyright statement from the file where you copied
it from instead (if there is one)?
Wouldn't that be much quicker than this email exchange?

Carl Eugen
___
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] libavutil: add an FFT & MDCT implementation

[Carl Eugen Hoyos]

Am So., 12. Mai 2019 um 02:51 Uhr schrieb Pedro Arthur :
>
> Em sáb, 11 de mai de 2019 às 20:26, James Almer  escreveu:
> >
> > On 5/11/2019 8:08 PM, Carl Eugen Hoyos wrote:
> > > Am So., 12. Mai 2019 um 01:00 Uhr schrieb Lynne :
> > >>
> > >> May 11, 2019, 11:08 PM by ceffm...@gmail.com:
> > >>
> > >>> Am Sa., 11. Mai 2019 um 14:41 Uhr schrieb Lynne <> d...@lynne.ee 
> > >>> > >:
> > >>>
> > 
> >  May 10, 2019, 8:59 PM by >> ceffm...@gmail.com 
> >  >> :
> > 
> > > Am Fr., 10. Mai 2019 um 19:54 Uhr schrieb Lynne <> >> d...@lynne.ee 
> > > >>  > d...@lynne.ee 
> > > >> >> >:
> > >
> > >>
> > >> May 10, 2019, 4:14 PM by >> >> d...@lynne.ee 
> > >> >>  > d...@lynne.ee 
> > >> >> >>> :
> > >>
> > >>> Patch updated again.
> > >>> Made some more cleanups to the transforms, the tables and the main 
> > >>> context.
> > >>> API changed again, now the init function populates the function 
> > >>> pointer for transform.
> > >>> I decided that having a separate function would encourage bad usage 
> > >>> (e.g. calling
> > >>> the function every time before doing a transform rather than 
> > >>> storing the pointer) when
> > >>> we're trying to avoid the overhead of function calls.
> > >>> Also adjusted file names to match the API.
> > >>>
> > >>
> > >> Forgot to change an include, new patch attached.
> > >>
> > >
> > > If I understand the commit message correctly, some of the code
> > > in the new file you are adding comes from other parts of FFmpeg.
> > > I am surprised that there is no copyright claim on the top of this
> > > new file.
> > > Is there none on top of the files you took the code from?
> > >
> > 
> >  The project isn't consistent with updating nor putting copyright 
> >  headers on files so
> >  I'd rather keep the headers clean. Commit messages and authors are the 
> >  only way to
> >  know who authored what.
> > 
> > >>>
> > >>> I don't think this is correct, but that is not the question: Copyright
> > >>> law is (at least here)
> > >>> very clear, if somebody put his name on top of the file, you must not 
> > >>> remove it,
> > >>> especially not when moving code from one file into another.
> > >>>
> > >>
> > >> "Here"? You're probably referring to some county's laws, those don't 
> > >> apply universally,
> > >> especially not to the internet.
> > >> Either way, that rule hasn't really been respected despite the major 
> > >> refactoring that has
> > >> happened in the past so I don't see why it has to be respected now.
> > >
> > > Please point me to the commit you indicate so I can fix this (claimed) 
> > > copyright
> > > violation.
> > >
> > >> The only parts I didn't rewrite are the power of two FFT, which I can 
> > >> NIH in a week if
> > >> necessary, and in fact lately with the research papers I've recently 
> > >> read I'm thinking
> > >> I should.
> > >
> > > Why don't you simply copy the copyright statement from the file where you 
> > > copied
> > > it from instead (if there is one)?
> > > Wouldn't that be much quicker than this email exchange?
> > >
> > > Carl Eugen
> >
> > The commit message already states it takes parts of lavc's fft
> > implementation, and the git story can't be rewritten, so authorship is
> > known or can be easily figured out. Could we please focus on technical
> > matters instead of wasting time in a back and forth about stuff like this?
> >
>
> Not saying this is the case, but if one interprets it as copying the
> code, adding more code, removing some parts, and removing the
> copyrights previously present it is clearly violating the license.
> It seems wise to include copyrights from original code in the file.

Except if there never was a copyright notice in the original file.

Carl Eugen
___
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][TESTERS WANTED] avfilter: add apitch filter

[Nicolas George]

Paul B Mahol (12019-05-11):
> Signed-off-by: Paul B Mahol 
> ---
> 
> This filter can dynamically change both tempo and pitch of audio.
> Also scale range is bigger, from 0.01 to 100.
> 
> ---
>  libavfilter/Makefile |   1 +
>  libavfilter/af_apitch.c  | 764 +++
>  libavfilter/allfilters.c |   1 +
>  3 files changed, 766 insertions(+)
>  create mode 100644 libavfilter/af_apitch.c

For usability and maintenance reasons already explained, must be part of
atempo.

Also, missing doc.

-- 
  Nicolas George


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

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

Re: [FFmpeg-devel] [PATCH] avcodec/h264_ps: Check offset_for_non_ref_pic and offset_for_top_to_bottom_field

[James Almer]

On 5/11/2019 2:59 PM, Michael Niedermayer wrote:
> Fixes: signed integer overflow: -2147483648 + -1 cannot be represented in 
> type 'int'
> Fixes: 
> 1/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_H264_fuzzer-5675880333967360
> 
> Found-by: continuous fuzzing process 
> https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
> Signed-off-by: Michael Niedermayer 
> ---
>  libavcodec/h264_ps.c | 9 +
>  1 file changed, 9 insertions(+)
> 
> diff --git a/libavcodec/h264_ps.c b/libavcodec/h264_ps.c
> index 7c92c68b38..e38cf2a533 100644
> --- a/libavcodec/h264_ps.c
> +++ b/libavcodec/h264_ps.c
> @@ -451,6 +451,15 @@ int ff_h264_decode_seq_parameter_set(GetBitContext *gb, 
> AVCodecContext *avctx,
>  sps->delta_pic_order_always_zero_flag = get_bits1(gb);
>  sps->offset_for_non_ref_pic   = get_se_golomb_long(gb);
>  sps->offset_for_top_to_bottom_field   = get_se_golomb_long(gb);
> +
> +if (   sps->offset_for_non_ref_pic == INT32_MIN
> +|| sps->offset_for_top_to_bottom_field == INT32_MIN
> +) {
> +av_log(avctx, AV_LOG_ERROR,
> +   "offset_for_non_ref_pic or offset_for_top_to_bottom_field 
> underflow\n");
> +goto fail;
> +}

The valid range is INT32_MIN + 1 to INT32_MAX, so it should be good. But
maybe the error message should instead say it's out of range?

Fwiw, there's another get_se_golomb_long() call right below these, with
the same range constrains.

> +
>  sps->poc_cycle_length = get_ue_golomb(gb);
>  
>  if ((unsigned)sps->poc_cycle_length >=
> 

___
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][TESTERS WANTED] avfilter: add apitch filter

[Paul B Mahol]

Hi,

On 5/11/19, Nicolas George  wrote:
> Paul B Mahol (12019-05-11):
>> Signed-off-by: Paul B Mahol 
>> ---
>>
>> This filter can dynamically change both tempo and pitch of audio.
>> Also scale range is bigger, from 0.01 to 100.
>>
>> ---
>>  libavfilter/Makefile |   1 +
>>  libavfilter/af_apitch.c  | 764 +++
>>  libavfilter/allfilters.c |   1 +
>>  3 files changed, 766 insertions(+)
>>  create mode 100644 libavfilter/af_apitch.c
>
> For usability and maintenance reasons already explained, must be part of
> atempo.

Thanks for kind and very helpful comments.

It is currently separate filter for ease of testing.
It can not be "part" of current atempo implementation for numerous reasons,
most significant one being bad output quality with < 1 tempo scale
factor of current
atempo implementation. Also current atempo implementation have limits
for minimal
scale reduction, unlike rubberband filter in libavfilter.
Also rubberband filter having similar and bigger functionality.

That's way I request for quality testers.
Best would be to compare this filter with rubberband and current atempo filter.

This filter is supposed to be current atempo full replacement.
(atempo would be just this filter but with same first two options but
with swapped positions).

>
> Also, missing doc.

Options are self-explanatory, at least first two.
Documentation will appear later.

Regards, and have a nice day.
___
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] libavutil: add an FFT & MDCT implementation

[James Almer]

On 5/11/2019 8:08 PM, Carl Eugen Hoyos wrote:
> Am So., 12. Mai 2019 um 01:00 Uhr schrieb Lynne :
>>
>> May 11, 2019, 11:08 PM by ceffm...@gmail.com:
>>
>>> Am Sa., 11. Mai 2019 um 14:41 Uhr schrieb Lynne <> d...@lynne.ee 
>>> > >:
>>>

 May 10, 2019, 8:59 PM by >> ceffm...@gmail.com 
 >> :

> Am Fr., 10. Mai 2019 um 19:54 Uhr schrieb Lynne <> >> d...@lynne.ee 
> >>  > d...@lynne.ee 
> >> >> >:
>
>>
>> May 10, 2019, 4:14 PM by >> >> d...@lynne.ee >>  
>> > d...@lynne.ee >> >>> :
>>
>>> Patch updated again.
>>> Made some more cleanups to the transforms, the tables and the main 
>>> context.
>>> API changed again, now the init function populates the function pointer 
>>> for transform.
>>> I decided that having a separate function would encourage bad usage 
>>> (e.g. calling
>>> the function every time before doing a transform rather than storing 
>>> the pointer) when
>>> we're trying to avoid the overhead of function calls.
>>> Also adjusted file names to match the API.
>>>
>>
>> Forgot to change an include, new patch attached.
>>
>
> If I understand the commit message correctly, some of the code
> in the new file you are adding comes from other parts of FFmpeg.
> I am surprised that there is no copyright claim on the top of this
> new file.
> Is there none on top of the files you took the code from?
>

 The project isn't consistent with updating nor putting copyright headers 
 on files so
 I'd rather keep the headers clean. Commit messages and authors are the 
 only way to
 know who authored what.

>>>
>>> I don't think this is correct, but that is not the question: Copyright
>>> law is (at least here)
>>> very clear, if somebody put his name on top of the file, you must not 
>>> remove it,
>>> especially not when moving code from one file into another.
>>>
>>
>> "Here"? You're probably referring to some county's laws, those don't apply 
>> universally,
>> especially not to the internet.
>> Either way, that rule hasn't really been respected despite the major 
>> refactoring that has
>> happened in the past so I don't see why it has to be respected now.
> 
> Please point me to the commit you indicate so I can fix this (claimed) 
> copyright
> violation.
> 
>> The only parts I didn't rewrite are the power of two FFT, which I can NIH in 
>> a week if
>> necessary, and in fact lately with the research papers I've recently read 
>> I'm thinking
>> I should.
> 
> Why don't you simply copy the copyright statement from the file where you 
> copied
> it from instead (if there is one)?
> Wouldn't that be much quicker than this email exchange?
> 
> Carl Eugen

The commit message already states it takes parts of lavc's fft
implementation, and the git story can't be rewritten, so authorship is
known or can be easily figured out. Could we please focus on technical
matters instead of wasting time in a back and forth about stuff like this?

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

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

Re: [FFmpeg-devel] [PATCH v2] libavutil: add an FFT & MDCT implementation

[Carl Eugen Hoyos]

Am So., 12. Mai 2019 um 01:26 Uhr schrieb James Almer :
>
> On 5/11/2019 8:08 PM, Carl Eugen Hoyos wrote:
> > Am So., 12. Mai 2019 um 01:00 Uhr schrieb Lynne :
> >>
> >> May 11, 2019, 11:08 PM by ceffm...@gmail.com:
> >>
> >>> Am Sa., 11. Mai 2019 um 14:41 Uhr schrieb Lynne <> d...@lynne.ee 
> >>> > >:
> >>>
> 
>  May 10, 2019, 8:59 PM by >> ceffm...@gmail.com 
>  >> :
> 
> > Am Fr., 10. Mai 2019 um 19:54 Uhr schrieb Lynne <> >> d...@lynne.ee 
> > >>  > d...@lynne.ee 
> > >> >> >:
> >
> >>
> >> May 10, 2019, 4:14 PM by >> >> d...@lynne.ee >>  
> >> > d...@lynne.ee >> >>> :
> >>
> >>> Patch updated again.
> >>> Made some more cleanups to the transforms, the tables and the main 
> >>> context.
> >>> API changed again, now the init function populates the function 
> >>> pointer for transform.
> >>> I decided that having a separate function would encourage bad usage 
> >>> (e.g. calling
> >>> the function every time before doing a transform rather than storing 
> >>> the pointer) when
> >>> we're trying to avoid the overhead of function calls.
> >>> Also adjusted file names to match the API.
> >>>
> >>
> >> Forgot to change an include, new patch attached.
> >>
> >
> > If I understand the commit message correctly, some of the code
> > in the new file you are adding comes from other parts of FFmpeg.
> > I am surprised that there is no copyright claim on the top of this
> > new file.
> > Is there none on top of the files you took the code from?
> >
> 
>  The project isn't consistent with updating nor putting copyright headers 
>  on files so
>  I'd rather keep the headers clean. Commit messages and authors are the 
>  only way to
>  know who authored what.
> 
> >>>
> >>> I don't think this is correct, but that is not the question: Copyright
> >>> law is (at least here)
> >>> very clear, if somebody put his name on top of the file, you must not 
> >>> remove it,
> >>> especially not when moving code from one file into another.
> >>>
> >>
> >> "Here"? You're probably referring to some county's laws, those don't apply 
> >> universally,
> >> especially not to the internet.
> >> Either way, that rule hasn't really been respected despite the major 
> >> refactoring that has
> >> happened in the past so I don't see why it has to be respected now.
> >
> > Please point me to the commit you indicate so I can fix this (claimed) 
> > copyright
> > violation.
> >
> >> The only parts I didn't rewrite are the power of two FFT, which I can NIH 
> >> in a week if
> >> necessary, and in fact lately with the research papers I've recently read 
> >> I'm thinking
> >> I should.
> >
> > Why don't you simply copy the copyright statement from the file where you 
> > copied
> > it from instead (if there is one)?
> > Wouldn't that be much quicker than this email exchange?
> >
> > Carl Eugen
>
> The commit message already states it takes parts of lavc's fft
> implementation, and the git story can't be rewritten, so authorship is
> known or can be easily figured out. Could we please focus on technical
> matters instead of wasting time in a back and forth about stuff like this?

Are you talking about wasting time with copyright violations?

Carl Eugen
___
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] vf_thumbnail: support alpha

[Michael Niedermayer]

On Sat, May 11, 2019 at 12:19:22PM +0200, Robert Nagy wrote:
> ---
>  libavfilter/vf_thumbnail.c | 8 +---
>  1 file changed, 5 insertions(+), 3 deletions(-)
> 
> diff --git a/libavfilter/vf_thumbnail.c b/libavfilter/vf_thumbnail.c
> index 0effdc91e9..30bb0dfdb8 100644
> --- a/libavfilter/vf_thumbnail.c
> +++ b/libavfilter/vf_thumbnail.c
> @@ -136,6 +136,7 @@ static int filter_frame(AVFilterLink *inlink,
> AVFrame *frame)
>  AVFilterLink *outlink = ctx->outputs[0];
>  int *hist = s->frames[s->n].histogram;
>  const uint8_t *p = frame->data[0];
> +int stride = frame->format == AV_PIX_FMT_BGRA || frame->format ==
> AV_PIX_FMT_RGBA ? 4 : 3;

Applying: vf_thumbnail: support alpha
error: corrupt patch at line 10
error: could not build fake ancestor
Patch failed at 0001 vf_thumbnail: support alpha
hint: Use 'git am --show-current-patch' to see the failed patch
When you have resolved this problem, run "git am --continue".
If you prefer to skip this patch, run "git am --skip" instead.
To restore the original branch and stop patching, run "git am --abort".


[...]

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

If you fake or manipulate statistics in a paper in physics you will never
get a job again.
If you fake or manipulate statistics in a paper in medicin you will get
a job for life at the pharma industry.


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