Re: [FFmpeg-devel] [PATCH V2 1/2] lavf/vc1test: fix vc1test can't probe some RCV file.

2018-10-13 Thread myp...@gmail.com
On Sun, Oct 14, 2018 at 3:07 AM Michael Niedermayer
 wrote:
>
> On Fri, Oct 12, 2018 at 09:41:04PM +0800, Jun Zhao wrote:
> > case 1:
> > use the hexdump -C SMM0005.rcv get:
> >  size  skip (size - 4)
> >   ||
> >   VV
> >   18 00 00 c5 05 00 00 00  4d f1 0a 11 00 e0 01 00
> > 0010  00 d0 02 00 00 0c 00 00  00 88 13 00 00 c0 65 52
> >  ^
> >|
> >size + 16
> > case 2:
> > same the command for SMM0015.rcv get:
> > size
> >   |
> >   V
> >   19 00 00 c5 04 00 00 00  41 f3 80 01 40 02 00 00
> > 0010  d0 02 00 00 0c 00 00 00  00 00 00 10 00 00 00 00
> >   ^
> > |
> >  size + 16
> >
> > There are different the RCV file format for VC-1, vc1test
> > just handle the case 2 now, this fix will support the case 1.
> > (Both of test clips come from: RP 228:2008 - SMPTE
> > Recommended Practice - VC-1 Decoder and Bitstream Conformance).
> >
> > Signed-off-by: Jun Zhao 
> > Signed-off-by: Yan, FengX 
> > ---
> >  libavformat/vc1test.c |   11 +--
> >  1 files changed, 9 insertions(+), 2 deletions(-)
> >
> > diff --git a/libavformat/vc1test.c b/libavformat/vc1test.c
> > index a801f4b..82e155a 100644
> > --- a/libavformat/vc1test.c
> > +++ b/libavformat/vc1test.c
> > @@ -34,9 +34,13 @@
> >
> >  static int vc1t_probe(AVProbeData *p)
> >  {
> > +int size;
> > +
> >  if (p->buf_size < 24)
> >  return 0;
> > -if (p->buf[3] != 0xC5 || AV_RL32(&p->buf[4]) != 4 || 
> > AV_RL32(&p->buf[20]) != 0xC)
> > +
> > +size = AV_RL32(&p->buf[4]);
> > +if (p->buf[3] != 0xC5 || AV_RL32(&p->buf[size+16]) != 0xC)
>
> this doesnt check size and could crash
>
Will add size check in V3
>
> [...]
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel


Re: [FFmpeg-devel] [PATCH 02/12] avformat/mxfenc: write index delta entry array needed by sony vegas pro 11

2018-10-13 Thread Michael Niedermayer
On Sat, Oct 13, 2018 at 06:24:52PM +0200, Martin Vignali wrote:
> >
> > Applied
> >
> >
> Seems like fate-mxf-reel_name doesn't pass after your patchs
> make fate-mxf-reel_name SAMPLES=fate-suite

this also broke 2 other fate tests:
make: *** [fate-mxf-reel_name] Error 1
make: *** [fate-copy-trac4914] Error 1
make: *** [fate-time_base] Error 1

i would look at it but i just now noticed and i need to go to bed :(
 
also when testing i needed a "rm tests/data/fate/time_base.out", this seemd
not to be removed (thats unrelated to the commit i assume, iam just saying
so noone wastes time debuging a mysterious long standing failure)
 
[...]

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

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


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


Re: [FFmpeg-devel] [PATCH] avformat: add H264 and HEVC support in IVF muxer

2018-10-13 Thread Michael Niedermayer
On Fri, Oct 12, 2018 at 01:13:45AM +0100, Derek Buitenhuis wrote:
> On 11/10/2018 23:39, Alex Sukhanov wrote:
> > The only "spec" I'm aware of:https://wiki.multimedia.cx/index.php/IVF
> 
> Yeah, not really a spec.
> 
> I have no strong objections, I guess.

so IIUC noone is against this ?
if so i will apply the last patch in a few days unless i forget or
someone else does before

thx

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

Everything should be made as simple as possible, but not simpler.
-- Albert Einstein


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


[FFmpeg-devel] [PATCH V3 0/2] *** SUBJECT HERE ***

2018-10-13 Thread Jun Zhao
v3: - add size check when probe as Michael's comments.
- update commit msg
- for Jerome's comments, I don't find a way to adjusted the handle for 
"0x000c"
v2: - split the patch (Carl Eugen Hoyos's comments).

Jun Zhao (2):
  lavf/vc1test: fix vc1test can't probe some RCV file.
  lavf/vc1test: add rcv to vc1test demuxer extensions

 libavformat/vc1test.c |   12 ++--
 1 files changed, 10 insertions(+), 2 deletions(-)

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


[FFmpeg-devel] [PATCH V3 1/2] lavf/vc1test: fix vc1test can't probe some RCV file.

2018-10-13 Thread Jun Zhao
case 1:
use the hexdump -C SMM0005.rcv get:
 size  skip (size - 4)
  ||
  VV
  18 00 00 c5 05 00 00 00  4d f1 0a 11 00 e0 01 00
0010  00 d0 02 00 00 0c 00 00  00 88 13 00 00 c0 65 52
 ^
 |
 size + 16
case 2:
same the command for SMM0015.rcv get:
size
  |
  V
  19 00 00 c5 04 00 00 00  41 f3 80 01 40 02 00 00
0010  d0 02 00 00 0c 00 00 00  00 00 00 10 00 00 00 00
  ^
  |
   size + 16

There are different the RCV file format for VC-1, vc1test
just handle the case 2 now, this fix will support the case 1.
(Both of test clips come from: SMPTE Recommended Practice -
VC-1 Decoder and Bitstream Conformance). And I think I got
a older VC-1 test clip in the case 1.

Reviewed-by: Carl Eugen Hoyos 
Reviewed-by: Jerome Borsboom 
Reviewed-by: Michael Niedermayer 
Signed-off-by: Jun Zhao 
Signed-off-by: Yan, FengX 
---
 libavformat/vc1test.c |   11 +--
 1 files changed, 9 insertions(+), 2 deletions(-)

diff --git a/libavformat/vc1test.c b/libavformat/vc1test.c
index a801f4b..e029ff4 100644
--- a/libavformat/vc1test.c
+++ b/libavformat/vc1test.c
@@ -34,9 +34,13 @@
 
 static int vc1t_probe(AVProbeData *p)
 {
+int size;
+
 if (p->buf_size < 24)
 return 0;
-if (p->buf[3] != 0xC5 || AV_RL32(&p->buf[4]) != 4 || AV_RL32(&p->buf[20]) 
!= 0xC)
+
+size = AV_RL32(&p->buf[4]);
+if (p->buf[3] != 0xC5 || size < 4 || AV_RL32(&p->buf[size+16]) != 0xC)
 return 0;
 
 return AVPROBE_SCORE_EXTENSION;
@@ -48,9 +52,10 @@ static int vc1t_read_header(AVFormatContext *s)
 AVStream *st;
 int frames;
 uint32_t fps;
+int size;
 
 frames = avio_rl24(pb);
-if(avio_r8(pb) != 0xC5 || avio_rl32(pb) != 4)
+if (avio_r8(pb) != 0xC5 || ((size = avio_rl32(pb)) < 4))
 return AVERROR_INVALIDDATA;
 
 /* init video codec */
@@ -63,6 +68,8 @@ static int vc1t_read_header(AVFormatContext *s)
 
 if (ff_get_extradata(s, st->codecpar, pb, VC1_EXTRADATA_SIZE) < 0)
 return AVERROR(ENOMEM);
+
+avio_skip(pb, size - 4);
 st->codecpar->height = avio_rl32(pb);
 st->codecpar->width = avio_rl32(pb);
 if(avio_rl32(pb) != 0xC)
-- 
1.7.1

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


[FFmpeg-devel] [PATCH V3 2/2] lavf/vc1test: add rcv to vc1test demuxer extensions

2018-10-13 Thread Jun Zhao
rcv is commonly used as extension for vc1 test stream files.

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

diff --git a/libavformat/vc1test.c b/libavformat/vc1test.c
index e029ff4..39b7716 100644
--- a/libavformat/vc1test.c
+++ b/libavformat/vc1test.c
@@ -121,5 +121,6 @@ AVInputFormat ff_vc1t_demuxer = {
 .read_probe = vc1t_probe,
 .read_header= vc1t_read_header,
 .read_packet= vc1t_read_packet,
+.extensions = "rcv",
 .flags  = AVFMT_GENERIC_INDEX,
 };
-- 
1.7.1

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


[FFmpeg-devel] [PATCH] avfilter: add sinc source filter

2018-10-13 Thread Paul B Mahol
Signed-off-by: Paul B Mahol 
---
 libavfilter/Makefile |   1 +
 libavfilter/allfilters.c |   1 +
 libavfilter/asrc_sinc.c  | 457 +++
 3 files changed, 459 insertions(+)
 create mode 100644 libavfilter/asrc_sinc.c

diff --git a/libavfilter/Makefile b/libavfilter/Makefile
index 62cc2f561f..b03b2457eb 100644
--- a/libavfilter/Makefile
+++ b/libavfilter/Makefile
@@ -141,6 +141,7 @@ OBJS-$(CONFIG_ANOISESRC_FILTER)  += 
asrc_anoisesrc.o
 OBJS-$(CONFIG_ANULLSRC_FILTER)   += asrc_anullsrc.o
 OBJS-$(CONFIG_FLITE_FILTER)  += asrc_flite.o
 OBJS-$(CONFIG_HILBERT_FILTER)+= asrc_hilbert.o
+OBJS-$(CONFIG_SINC_FILTER)   += asrc_sinc.o
 OBJS-$(CONFIG_SINE_FILTER)   += asrc_sine.o
 
 OBJS-$(CONFIG_ANULLSINK_FILTER)  += asink_anullsink.o
diff --git a/libavfilter/allfilters.c b/libavfilter/allfilters.c
index 5e72803b13..725bac94a0 100644
--- a/libavfilter/allfilters.c
+++ b/libavfilter/allfilters.c
@@ -134,6 +134,7 @@ extern AVFilter ff_asrc_anoisesrc;
 extern AVFilter ff_asrc_anullsrc;
 extern AVFilter ff_asrc_flite;
 extern AVFilter ff_asrc_hilbert;
+extern AVFilter ff_asrc_sinc;
 extern AVFilter ff_asrc_sine;
 
 extern AVFilter ff_asink_anullsink;
diff --git a/libavfilter/asrc_sinc.c b/libavfilter/asrc_sinc.c
new file mode 100644
index 00..0b2714f04c
--- /dev/null
+++ b/libavfilter/asrc_sinc.c
@@ -0,0 +1,457 @@
+/*
+ * Copyright (c) 2008-2009 Rob Sykes 
+ * Copyright (c) 2017 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 "libavutil/avassert.h"
+#include "libavutil/opt.h"
+
+#include "libavcodec/avfft.h"
+
+#include "audio.h"
+#include "avfilter.h"
+#include "internal.h"
+
+typedef struct SincContext {
+const AVClass *class;
+
+int sample_rate, nb_samples;
+float att, beta, phase, Fc0, Fc1, tbw0, tbw1;
+int num_taps[2];
+int round;
+
+int n, rdft_len;
+float *coeffs;
+int64_t pts;
+
+RDFTContext *rdft, *irdft;
+} SincContext;
+
+static int request_frame(AVFilterLink *outlink)
+{
+AVFilterContext *ctx = outlink->src;
+SincContext *s = ctx->priv;
+const float *coeffs = s->coeffs;
+AVFrame *frame = NULL;
+int nb_samples;
+
+nb_samples = FFMIN(s->nb_samples, s->n - s->pts);
+if (!nb_samples)
+return AVERROR_EOF;
+
+if (!(frame = ff_get_audio_buffer(outlink, nb_samples)))
+return AVERROR(ENOMEM);
+
+memcpy(frame->data[0], coeffs + s->pts, nb_samples * sizeof(float));
+
+frame->pts = s->pts;
+s->pts+= nb_samples;
+
+return ff_filter_frame(outlink, frame);
+}
+
+static int query_formats(AVFilterContext *ctx)
+{
+SincContext *s = ctx->priv;
+static const int64_t chlayouts[] = { AV_CH_LAYOUT_MONO, -1 };
+int sample_rates[] = { s->sample_rate, -1 };
+static const enum AVSampleFormat sample_fmts[] = { AV_SAMPLE_FMT_FLT,
+   AV_SAMPLE_FMT_NONE };
+AVFilterFormats *formats;
+AVFilterChannelLayouts *layouts;
+int ret;
+
+formats = ff_make_format_list(sample_fmts);
+if (!formats)
+return AVERROR(ENOMEM);
+ret = ff_set_common_formats (ctx, formats);
+if (ret < 0)
+return ret;
+
+layouts = avfilter_make_format64_list(chlayouts);
+if (!layouts)
+return AVERROR(ENOMEM);
+ret = ff_set_common_channel_layouts(ctx, layouts);
+if (ret < 0)
+return ret;
+
+formats = ff_make_format_list(sample_rates);
+if (!formats)
+return AVERROR(ENOMEM);
+return ff_set_common_samplerates(ctx, formats);
+}
+
+static float bessel_I_0(float x)
+{
+float term = 1, sum = 1, last_sum, x2 = x / 2;
+int i = 1;
+
+do {
+float y = x2 / i++;
+
+last_sum = sum;
+sum += term *= y * y;
+} while (sum != last_sum);
+
+return sum;
+}
+
+static float *make_lpf(int num_taps, float Fc, float beta, float rho,
+   float scale, int dc_norm)
+{
+int i, m = num_taps - 1;
+float *h = av_calloc(num_taps, sizeof(*h)), sum = 0;
+float mult = scale / bessel_I_0(beta), mult1 = 1 / (.5 * m + rho);
+
+av_assert0(Fc >= 0 && Fc <= 1);
+
+for (i = 0; i <= m / 2; i

Re: [FFmpeg-devel] [PATCH] libavcodec/qsvenc_hevc: correction for QSV HEVC default plugin selection on Windows

2018-10-13 Thread Maxym Dmytrychenko
On Sat, Oct 13, 2018 at 6:43 PM Mark Thompson  wrote:

> On 06/10/18 07:21, Landgraph wrote:
> > 1. Old logic meaned: everywhere, except Windows, ffmpeg has to use HW
> acceleration, but on Windows ffmpeg has to use (unavailable) software
> encode by default
> > 2. Software encode is available only if you provide corresponding
> software MediaSDK library, which isn't provided with ffmpeg. More
> information could be found in
> https://github.com/Intel-Media-SDK/MediaSDK/blob/master/doc/samples/readme-encode_linux.pdf
> > 3. HW encode is available on Windows in the driver by default
>
> This has been proposed before - I can't find the original discussion
> (maybe it was on IRC), but I did find <
> https://lists.libav.org/pipermail/libav-devel/2016-November/080419.html>.
> The reason for not doing it is that a subset of the Intel drivers segfault
> immediately when the hardware plugin is loaded on some platforms.  That's a
> pain for anyone wanting to support diverse systems, so the decision was to
> continue to load the sw plugin by default so it doesn't crash (even if the
> software plugin isn't present), and leave the non-default case as the
> crashing one so the user has to do something to trigger it.
>
> If you can characterise either the set of platforms it crashes on or a set
> of platforms it definitely works on then maybe we could conditionally
> change the default behaviour?
>
> - Mark
>
>
it was 2 years old discussion and with early drivers (we even had this
development a bit ahead of general driver availability)
now it should be working on most of the platforms - I would suggest to make
a positive side.



>
> > ---
> >  libavcodec/qsvenc_hevc.c | 4 
> >  1 file changed, 4 deletions(-)
> >
> > diff --git a/libavcodec/qsvenc_hevc.c b/libavcodec/qsvenc_hevc.c
> > index 4339b316a3..e7ca27d49f 100644
> > --- a/libavcodec/qsvenc_hevc.c
> > +++ b/libavcodec/qsvenc_hevc.c
> > @@ -217,11 +217,7 @@ static av_cold int qsv_enc_close(AVCodecContext
> *avctx)
> >  return ff_qsv_enc_close(avctx, &q->qsv);
> >  }
> >
> > -#if defined(_WIN32)
> > -#define LOAD_PLUGIN_DEFAULT LOAD_PLUGIN_HEVC_SW
> > -#else
> >  #define LOAD_PLUGIN_DEFAULT LOAD_PLUGIN_HEVC_HW
> > -#endif
> >
> >  #define OFFSET(x) offsetof(QSVHEVCEncContext, x)
> >  #define VE AV_OPT_FLAG_VIDEO_PARAM | AV_OPT_FLAG_ENCODING_PARAM
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel


Re: [FFmpeg-devel] [PATCH V2 1/2] lavf/vc1test: fix vc1test can't probe some RCV file.

2018-10-13 Thread Michael Niedermayer
On Fri, Oct 12, 2018 at 09:41:04PM +0800, Jun Zhao wrote:
> case 1:
> use the hexdump -C SMM0005.rcv get:
>  size  skip (size - 4)
>   ||
>   VV
>   18 00 00 c5 05 00 00 00  4d f1 0a 11 00 e0 01 00
> 0010  00 d0 02 00 00 0c 00 00  00 88 13 00 00 c0 65 52
>  ^
>|
>size + 16
> case 2:
> same the command for SMM0015.rcv get:
> size
>   |
>   V
>   19 00 00 c5 04 00 00 00  41 f3 80 01 40 02 00 00
> 0010  d0 02 00 00 0c 00 00 00  00 00 00 10 00 00 00 00
>   ^
> |
>  size + 16
> 
> There are different the RCV file format for VC-1, vc1test
> just handle the case 2 now, this fix will support the case 1.
> (Both of test clips come from: RP 228:2008 - SMPTE
> Recommended Practice - VC-1 Decoder and Bitstream Conformance).
> 
> Signed-off-by: Jun Zhao 
> Signed-off-by: Yan, FengX 
> ---
>  libavformat/vc1test.c |   11 +--
>  1 files changed, 9 insertions(+), 2 deletions(-)
> 
> diff --git a/libavformat/vc1test.c b/libavformat/vc1test.c
> index a801f4b..82e155a 100644
> --- a/libavformat/vc1test.c
> +++ b/libavformat/vc1test.c
> @@ -34,9 +34,13 @@
>  
>  static int vc1t_probe(AVProbeData *p)
>  {
> +int size;
> +
>  if (p->buf_size < 24)
>  return 0;
> -if (p->buf[3] != 0xC5 || AV_RL32(&p->buf[4]) != 4 || 
> AV_RL32(&p->buf[20]) != 0xC)
> +
> +size = AV_RL32(&p->buf[4]);
> +if (p->buf[3] != 0xC5 || AV_RL32(&p->buf[size+16]) != 0xC)

this doesnt check size and could crash


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

If a bugfix only changes things apparently unrelated to the bug with no
further explanation, that is a good sign that the bugfix is wrong.


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


Re: [FFmpeg-devel] [PATCH v3] fate: add api-h264-slice test

2018-10-13 Thread Hendrik Leppkes
On Sat, Oct 13, 2018 at 8:28 PM Hendrik Leppkes  wrote:
>
> On Sat, Oct 13, 2018 at 8:26 PM Michael Niedermayer
>  wrote:
> >
> > On Fri, Oct 12, 2018 at 02:35:04PM +0100, jos...@ob-encoder.com wrote:
> > > From: Josh de Kock 
> > >
> > > This test ensures that you are able to send N number of slice NALUs in 
> > > slice threaded mode to be decoded simultaneously
> > > ---
> > >
> > >  Ignore the previous patch, had some dead code in it. This now
> > >  works in MinGW as well.
> > >
> > >  tests/api/Makefile  |   1 +
> > >  tests/api/api-h264-slice-test.c | 207 +
> > >  tests/fate/api.mak  |   4 +
> > >  tests/ref/fate/api-h264-slice   | 309 
> > >  4 files changed, 521 insertions(+)
> > >  create mode 100644 tests/api/api-h264-slice-test.c
> > >  create mode 100644 tests/ref/fate/api-h264-slice
> >
> > fails to build on linux
> > make -j12 fate-api-h264-slice
> > ...
> > tests/api/api-h264-slice-test.c: In function ‘main’:
> > tests/api/api-h264-slice-test.c:125:5: error: implicit declaration of 
> > function ‘setmode’ [-Werror=implicit-function-declaration]
> >  setmode(fileno(stdout), O_BINARY);
> >  ^
> > tests/api/api-h264-slice-test.c:125:29: error: ‘O_BINARY’ undeclared (first 
> > use in this function)
> >  setmode(fileno(stdout), O_BINARY);
> >  ^
> > tests/api/api-h264-slice-test.c:125:29: note: each undeclared identifier is 
> > reported only once for each function it appears in
> > cc1: some warnings being treated as errors
> > make: *** [tests/api/api-h264-slice-test.o] Error 1
> > make: *** Waiting for unfinished jobs
> >
>
> Probably need to include unistd.h. Note: unistd.h is not present
> everywhere, use the config.h define for it!
>
> #if HAVE_UNISTD_H
> #include 
> #endif
>

Or possibly io.h, apparently it varies on different systems. We also
have HAVE_IO_H.

Realistically its only needed on windows, my original recommendating
was to only use it there, but apparently that was missed when I
suggested that solution.

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


Re: [FFmpeg-devel] [PATCH v3] fate: add api-h264-slice test

2018-10-13 Thread Hendrik Leppkes
On Sat, Oct 13, 2018 at 8:26 PM Michael Niedermayer
 wrote:
>
> On Fri, Oct 12, 2018 at 02:35:04PM +0100, jos...@ob-encoder.com wrote:
> > From: Josh de Kock 
> >
> > This test ensures that you are able to send N number of slice NALUs in 
> > slice threaded mode to be decoded simultaneously
> > ---
> >
> >  Ignore the previous patch, had some dead code in it. This now
> >  works in MinGW as well.
> >
> >  tests/api/Makefile  |   1 +
> >  tests/api/api-h264-slice-test.c | 207 +
> >  tests/fate/api.mak  |   4 +
> >  tests/ref/fate/api-h264-slice   | 309 
> >  4 files changed, 521 insertions(+)
> >  create mode 100644 tests/api/api-h264-slice-test.c
> >  create mode 100644 tests/ref/fate/api-h264-slice
>
> fails to build on linux
> make -j12 fate-api-h264-slice
> ...
> tests/api/api-h264-slice-test.c: In function ‘main’:
> tests/api/api-h264-slice-test.c:125:5: error: implicit declaration of 
> function ‘setmode’ [-Werror=implicit-function-declaration]
>  setmode(fileno(stdout), O_BINARY);
>  ^
> tests/api/api-h264-slice-test.c:125:29: error: ‘O_BINARY’ undeclared (first 
> use in this function)
>  setmode(fileno(stdout), O_BINARY);
>  ^
> tests/api/api-h264-slice-test.c:125:29: note: each undeclared identifier is 
> reported only once for each function it appears in
> cc1: some warnings being treated as errors
> make: *** [tests/api/api-h264-slice-test.o] Error 1
> make: *** Waiting for unfinished jobs
>

Probably need to include unistd.h. Note: unistd.h is not present
everywhere, use the config.h define for it!

#if HAVE_UNISTD_H
#include 
#endif

Also, we have a configure test for O_BINARY, so use that as well.
Basically check libavutil/file.c, that uses setmode with O_BINARY, all
required things should be in there.

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


Re: [FFmpeg-devel] [PATCH v3] fate: add api-h264-slice test

2018-10-13 Thread Michael Niedermayer
On Fri, Oct 12, 2018 at 02:35:04PM +0100, jos...@ob-encoder.com wrote:
> From: Josh de Kock 
> 
> This test ensures that you are able to send N number of slice NALUs in slice 
> threaded mode to be decoded simultaneously
> ---
> 
>  Ignore the previous patch, had some dead code in it. This now
>  works in MinGW as well.
> 
>  tests/api/Makefile  |   1 +
>  tests/api/api-h264-slice-test.c | 207 +
>  tests/fate/api.mak  |   4 +
>  tests/ref/fate/api-h264-slice   | 309 
>  4 files changed, 521 insertions(+)
>  create mode 100644 tests/api/api-h264-slice-test.c
>  create mode 100644 tests/ref/fate/api-h264-slice

fails to build on linux
make -j12 fate-api-h264-slice
...
tests/api/api-h264-slice-test.c: In function ‘main’:
tests/api/api-h264-slice-test.c:125:5: error: implicit declaration of function 
‘setmode’ [-Werror=implicit-function-declaration]
 setmode(fileno(stdout), O_BINARY);
 ^
tests/api/api-h264-slice-test.c:125:29: error: ‘O_BINARY’ undeclared (first use 
in this function)
 setmode(fileno(stdout), O_BINARY);
 ^
tests/api/api-h264-slice-test.c:125:29: note: each undeclared identifier is 
reported only once for each function it appears in
cc1: some warnings being treated as errors
make: *** [tests/api/api-h264-slice-test.o] Error 1
make: *** Waiting for unfinished jobs

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

Concerning the gods, I have no means of knowing whether they exist or not
or of what sort they may be, because of the obscurity of the subject, and
the brevity of human life -- Protagoras


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


[FFmpeg-devel] swscale/x86/rgb2rgb.asm : add Ivo van Poorten name at the top of the file

2018-10-13 Thread Martin Vignali
Hello,

Following Carl Eugen comment,
and this commit  :
http://git.videolan.org/?p=ffmpeg.git;a=commitdiff;h=b38d4874

Add name of the author of the inline mmxext version of shuffle2103 at the
top of the asm file

Martin


0001-swscale-x86-rgb2rgb.asm-add-Ivo-Van-Poorten-name-to-.patch
Description: Binary data
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel


[FFmpeg-devel] [PATCH] avcodec: add Amuse Graphics decoder

2018-10-13 Thread Paul B Mahol
This work is partially sponsored by VideoLAN.

Signed-off-by: Paul B Mahol 
---
 libavcodec/Makefile |   1 +
 libavcodec/agm.c| 701 
 libavcodec/allcodecs.c  |   1 +
 libavcodec/avcodec.h|   1 +
 libavcodec/codec_desc.c |   7 +
 libavformat/riff.c  |   2 +
 6 files changed, 713 insertions(+)
 create mode 100644 libavcodec/agm.c

diff --git a/libavcodec/Makefile b/libavcodec/Makefile
index ce766aa466..3a396c2d85 100644
--- a/libavcodec/Makefile
+++ b/libavcodec/Makefile
@@ -173,6 +173,7 @@ OBJS-$(CONFIG_AC3_FIXED_DECODER)   += ac3dec_fixed.o 
ac3dec_data.o ac3.o kbd
 OBJS-$(CONFIG_AC3_ENCODER) += ac3enc_float.o ac3enc.o ac3tab.o \
   ac3.o kbdwin.o
 OBJS-$(CONFIG_AC3_FIXED_ENCODER)   += ac3enc_fixed.o ac3enc.o ac3tab.o 
ac3.o
+OBJS-$(CONFIG_AGM_DECODER) += agm.o
 OBJS-$(CONFIG_AIC_DECODER) += aic.o
 OBJS-$(CONFIG_ALAC_DECODER)+= alac.o alac_data.o alacdsp.o
 OBJS-$(CONFIG_ALAC_ENCODER)+= alacenc.o alac_data.o
diff --git a/libavcodec/agm.c b/libavcodec/agm.c
new file mode 100644
index 00..8b2a9a0c92
--- /dev/null
+++ b/libavcodec/agm.c
@@ -0,0 +1,701 @@
+/*
+ * Amuse Graphics Movie decoder
+ *
+ * Copyright (c) 2018 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 
+#include 
+#include 
+
+#define BITSTREAM_READER_LE
+
+#include "avcodec.h"
+#include "bytestream.h"
+#include "copy_block.h"
+#include "get_bits.h"
+#include "idctdsp.h"
+#include "internal.h"
+
+static const uint8_t unscaled_luma[64] = {
+16, 11, 10, 16, 24, 40, 51, 61, 12, 12, 14, 19,
+26, 58, 60, 55, 14, 13, 16, 24, 40, 57, 69, 56,
+14, 17, 22, 29, 51, 87, 80, 62, 18, 22, 37, 56,
+68,109,103, 77, 24, 35, 55, 64, 81,104,113, 92,
+49, 64, 78, 87,103,121,120,101, 72, 92, 95, 98,
+112,100,103,99
+};
+
+static const uint8_t unscaled_chroma[64] = {
+17, 18, 24, 47, 99, 99, 99, 99, 18, 21, 26, 66,
+99, 99, 99, 99, 24, 26, 56, 99, 99, 99, 99, 99,
+47, 66, 99, 99, 99, 99, 99, 99, 99, 99, 99, 99,
+99, 99, 99, 99, 99, 99, 99, 99, 99, 99, 99, 99,
+99, 99, 99, 99, 99, 99, 99, 99, 99, 99, 99, 99,
+99, 99, 99, 99
+};
+
+typedef struct MotionVector {
+int16_t x, y;
+} MotionVector;
+
+typedef struct AGMContext {
+const AVClass  *class;
+AVCodecContext *avctx;
+GetBitContext   gb;
+GetByteContext  gbyte;
+
+int key_frame;
+int bitstream_size;
+int compression;
+int blocks_w;
+int blocks_h;
+int size[3];
+int plus;
+int flags;
+
+MotionVector *mvectors;
+int   mvectors_size;
+
+AVFrame *prev_frame;
+
+int luma_quant_matrix[64];
+int chroma_quant_matrix[64];
+
+ScanTable scantable;
+DECLARE_ALIGNED(32, int16_t, block)[64];
+IDCTDSPContext idsp;
+} AGMContext;
+
+static int read_code2(GetBitContext *gb, int *oskip, int *level)
+{
+int max, len = 0, skip = 0;
+
+if (show_bits(gb, 2)) {
+switch (show_bits(gb, 4)) {
+case 1:
+case 9:
+len = 1;
+skip = 3;
+break;
+case 2:
+len = 3;
+skip = 4;
+break;
+case 3:
+len = 7;
+skip = 4;
+break;
+case 5:
+case 0xD:
+len = 2;
+skip = 3;
+break;
+case 6:
+len = 4;
+skip = 4;
+break;
+case 7:
+len = 8;
+skip = 4;
+break;
+case 0xA:
+len = 5;
+skip = 4;
+break;
+case 0xB:
+len = 9;
+skip = 4;
+break;
+case 0xE:
+len = 6;
+skip = 4;
+break;
+case 0xF:
+len = ((show_bits(gb, 5) & 0x10) | 0xA0) >> 4;
+skip = 5;
+break;
+default:
+return AVERROR_INVALIDDATA;
+}
+skip_bits(gb, skip);
+*level = get_bits(gb, len);
+*oskip = 0;
+max = 1 << (len - 1);
+if (*level < max)
+*level = -(max + *level);
+} else if (show_bits(gb, 3) & 4) {
+   

Re: [FFmpeg-devel] [PATCH] avformat: add SER demuxer

2018-10-13 Thread Paul B Mahol
On 10/13/18, Carl Eugen Hoyos  wrote:
> 2018-10-13 19:16 GMT+02:00, Paul B Mahol :
>> On 10/13/18, Carl Eugen Hoyos  wrote:
>>> 2018-10-13 14:35 GMT+02:00, Paul B Mahol :
 On 10/12/18, Paul B Mahol  wrote:
> Fixes #6821.
>

 Will comitt with this above sentence removed.
>>>
>>> Why did you remove it?
>>
>> Because I have not got any reply regarding mplayer.
>
> Would you like to elaborate?

I asked you some questions in different mails and never
got any reply.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel


Re: [FFmpeg-devel] [PATCH] avformat: add SER demuxer

2018-10-13 Thread Carl Eugen Hoyos
2018-10-13 19:16 GMT+02:00, Paul B Mahol :
> On 10/13/18, Carl Eugen Hoyos  wrote:
>> 2018-10-13 14:35 GMT+02:00, Paul B Mahol :
>>> On 10/12/18, Paul B Mahol  wrote:
 Fixes #6821.

>>>
>>> Will comitt with this above sentence removed.
>>
>> Why did you remove it?
>
> Because I have not got any reply regarding mplayer.

Would you like to elaborate?

Carl Eugen
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel


Re: [FFmpeg-devel] [PATCH] avformat: add SER demuxer

2018-10-13 Thread Paul B Mahol
On 10/13/18, Carl Eugen Hoyos  wrote:
> 2018-10-13 14:35 GMT+02:00, Paul B Mahol :
>> On 10/12/18, Paul B Mahol  wrote:
>>> Fixes #6821.
>>>
>>
>> Will comitt with this above sentence removed.
>
> Why did you remove it?

Because I have not got any reply regarding mplayer.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel


Re: [FFmpeg-devel] [PATCH] avformat: add SER demuxer

2018-10-13 Thread Carl Eugen Hoyos
2018-10-13 14:35 GMT+02:00, Paul B Mahol :
> On 10/12/18, Paul B Mahol  wrote:
>> Fixes #6821.
>>
>
> Will comitt with this above sentence removed.

Why did you remove it?

Carl Eugen
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel


Re: [FFmpeg-devel] avfilter/vsrc_testsrc : add allgray generator and fate test for it

2018-10-13 Thread Martin Vignali
> > You mean, increase the height of the output frame ?
> > If yes :
> > Do you think it's better to duplicate each value, or duplicate the
> current
> > lines several times ?
>
> Your pick.
>

New patch in attach,
for gray 8, 9, 10, duplicate lines ramp several times, to have 16 pix height
(probably more convenient for testing purpose)

Martin


0001-avfilter-vsrc_testsrc-add-allgray-generator.patch
Description: Binary data
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel


Re: [FFmpeg-devel] [FFmpeg-cvslog] lavu/qsv: make a copy as libmfx alignment requirement for uploading

2018-10-13 Thread Mark Thompson
On 11/10/18 06:38, Zhong Li wrote:
> ffmpeg | branch: master | Zhong Li  | Mon Sep 17 19:16:44 
> 2018 +0800| [681aa7d14f97fd98181ca6d61e11be48fe65692d] | committer: Zhong Li
> 
> lavu/qsv: make a copy as libmfx alignment requirement for uploading
> 
> Libmfx requires 16 bytes aligned input/output for uploading.
> Currently only output is 16 byte aligned and assigning same width/height to
> input with smaller buffer size actually, thus definitely will cause segment 
> fault.
> 
> Can reproduce with any 1080p nv12 rawvideo input:
> ffmpeg -init_hw_device qsv=qsv:hw -hwaccel qsv -filter_hw_device qsv -f 
> rawvideo -pix_fmt nv12 -s:v 1920x1080
> -i 1080p_nv12.yuv -vf 
> 'format=nv12,hwupload=extra_hw_frames=16,hwdownload,format=nv12' -an -y 
> out_nv12.yuv
> 
> It can fix #7418
> 
> Signed-off-by: Zhong Li 
> 
>> http://git.videolan.org/gitweb.cgi/ffmpeg.git/?a=commit;h=681aa7d14f97fd98181ca6d61e11be48fe65692d
> ---
> 
>  libavutil/hwcontext_qsv.c | 31 +--
>  1 file changed, 29 insertions(+), 2 deletions(-)
> 
> diff --git a/libavutil/hwcontext_qsv.c b/libavutil/hwcontext_qsv.c
> index 33e121b416..814ce215ce 100644
> --- a/libavutil/hwcontext_qsv.c
> +++ b/libavutil/hwcontext_qsv.c
> @@ -862,6 +862,10 @@ static int qsv_transfer_data_to(AVHWFramesContext *ctx, 
> AVFrame *dst,
>  mfxSyncPoint sync = NULL;
>  mfxStatus err;
>  int ret = 0;
> +/* make a copy if the input is not padded as libmfx requires */
> +AVFrame tmp_frame, *src_frame;
> +int realigned = 0;
> +
>  
>  while (!s->session_upload_init && !s->session_upload && !ret) {
>  #if HAVE_PTHREADS
> @@ -887,16 +891,36 @@ static int qsv_transfer_data_to(AVHWFramesContext *ctx, 
> AVFrame *dst,
>  if (ret < 0)
>  return ret;
>  
> +
> +if (src->height & 16 || src->linesize[0] & 16) {

Doesn't this still need to check that the layout is compatible with other the 
limitations that libmfx has before trying to do the upload?  In particular, 
that the pitches for the different planes are actually all the same - I 
certainly wouldn't expect them to be for YUV420P.

(IIRC there was a requirement 0 < frame->data[N] - frame->data[0] < 2^24 as 
well (or something like that, I might be wrong), which also need not be true.)

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


Re: [FFmpeg-devel] [PATCH] libavcodec/qsvenc_hevc: correction for QSV HEVC default plugin selection on Windows

2018-10-13 Thread Mark Thompson
On 06/10/18 07:21, Landgraph wrote:
> 1. Old logic meaned: everywhere, except Windows, ffmpeg has to use HW 
> acceleration, but on Windows ffmpeg has to use (unavailable) software encode 
> by default
> 2. Software encode is available only if you provide corresponding software 
> MediaSDK library, which isn't provided with ffmpeg. More information could be 
> found in 
> https://github.com/Intel-Media-SDK/MediaSDK/blob/master/doc/samples/readme-encode_linux.pdf
> 3. HW encode is available on Windows in the driver by default

This has been proposed before - I can't find the original discussion (maybe it 
was on IRC), but I did find 
.  The 
reason for not doing it is that a subset of the Intel drivers segfault 
immediately when the hardware plugin is loaded on some platforms.  That's a 
pain for anyone wanting to support diverse systems, so the decision was to 
continue to load the sw plugin by default so it doesn't crash (even if the 
software plugin isn't present), and leave the non-default case as the crashing 
one so the user has to do something to trigger it.

If you can characterise either the set of platforms it crashes on or a set of 
platforms it definitely works on then maybe we could conditionally change the 
default behaviour?

- Mark


> ---
>  libavcodec/qsvenc_hevc.c | 4 
>  1 file changed, 4 deletions(-)
> 
> diff --git a/libavcodec/qsvenc_hevc.c b/libavcodec/qsvenc_hevc.c
> index 4339b316a3..e7ca27d49f 100644
> --- a/libavcodec/qsvenc_hevc.c
> +++ b/libavcodec/qsvenc_hevc.c
> @@ -217,11 +217,7 @@ static av_cold int qsv_enc_close(AVCodecContext *avctx)
>  return ff_qsv_enc_close(avctx, &q->qsv);
>  }
> 
> -#if defined(_WIN32)
> -#define LOAD_PLUGIN_DEFAULT LOAD_PLUGIN_HEVC_SW
> -#else
>  #define LOAD_PLUGIN_DEFAULT LOAD_PLUGIN_HEVC_HW
> -#endif
> 
>  #define OFFSET(x) offsetof(QSVHEVCEncContext, x)
>  #define VE AV_OPT_FLAG_VIDEO_PARAM | AV_OPT_FLAG_ENCODING_PARAM
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel


Re: [FFmpeg-devel] [PATCH 02/12] avformat/mxfenc: write index delta entry array needed by sony vegas pro 11

2018-10-13 Thread Martin Vignali
>
> Applied
>
>
Seems like fate-mxf-reel_name doesn't pass after your patchs
make fate-mxf-reel_name SAMPLES=fate-suite

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


Re: [FFmpeg-devel] avfilter/vsrc_testsrc : add allgray generator and fate test for it

2018-10-13 Thread Paul B Mahol
On 10/13/18, Martin Vignali  wrote:
>>
>> The 256x <=16 size is not very useful.
>>
>
> You mean, increase the height of the output frame ?
> If yes :
> Do you think it's better to duplicate each value, or duplicate the current
> lines several times ?

Your pick.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel


Re: [FFmpeg-devel] avfilter/vsrc_testsrc : add allgray generator and fate test for it

2018-10-13 Thread Martin Vignali
>
> The 256x <=16 size is not very useful.
>

You mean, increase the height of the output frame ?
If yes :
Do you think it's better to duplicate each value, or duplicate the current
lines several times ?

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


Re: [FFmpeg-devel] avfilter/vsrc_testsrc : add allgray generator and fate test for it

2018-10-13 Thread Paul B Mahol
On 10/13/18, Martin Vignali  wrote:
> Hello,
>
> Patch in attach add a video generator which output all gray value for the
> given pix_fmt
> Also add fate test for each target pix_fmt.
>
> The goal is to have a generator for testing swscale unscaled conversion
> later
>
> The size of the output depend of the pix_fmt
> gray8 output a 256x1 frame
> gray9 le/be : output 256x2
> gray10 le/be : output 256x4
> gray12 le/be : output 256x16
> gray14 le/be : output 256x64
> gray16 le/be : output 256x256
>
> Martin
>

The 256x <=16 size is not very useful.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel


[FFmpeg-devel] avfilter/vsrc_testsrc : add allgray generator and fate test for it

2018-10-13 Thread Martin Vignali
Hello,

Patch in attach add a video generator which output all gray value for the
given pix_fmt
Also add fate test for each target pix_fmt.

The goal is to have a generator for testing swscale unscaled conversion
later

The size of the output depend of the pix_fmt
gray8 output a 256x1 frame
gray9 le/be : output 256x2
gray10 le/be : output 256x4
gray12 le/be : output 256x16
gray14 le/be : output 256x64
gray16 le/be : output 256x256

Martin


0001-avfilter-vsrc_testsrc-add-allgray-generator.patch
Description: Binary data
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel


Re: [FFmpeg-devel] [PATCH] avcodec: add Amuse Graphics decoder

2018-10-13 Thread Paul B Mahol
On 10/13/18, Michael Niedermayer  wrote:
> On Wed, Oct 10, 2018 at 01:22:24PM +0200, Paul B Mahol wrote:
>> This work is partially sponsored by VideoLAN.
>>
>> Signed-off-by: Paul B Mahol 
>> ---
>>
>
>> The AGM3 variant decodes with some artifacts.
>
> I looked a bit as you asked on IRC but wasnt able to really fix it in
> the time i had available
>
> The following patch avoids the green blocks but it does not feel correct
>
> diff --git a/libavcodec/agm.c b/libavcodec/agm.c
> index 424b906eac..a6d9a9a7a6 100644
> --- a/libavcodec/agm.c
> +++ b/libavcodec/agm.c
> @@ -358,10 +358,12 @@ static int decode_inter_plane(AGMContext *s,
> GetBitContext *gb, int size,
>  if (ret < 0)
>  return ret;
>
> -if (mv_x < min) {
> +if (mv_x < min && s->block[0] > 512) {
>  s->idsp.idct_put(frame->data[plane] + (s->blocks_h - 1
> - y) * 8 * frame->linesize[plane] + x * 8,
>   frame->linesize[plane], s->block);
>  } else {
> +if (mv_x < min)
> +mv_x = 0;
>  if (y * 8 + mv_y < 0 || y * 8 + mv_y >= h ||
>  x * 8 + mv_x < 0 || x * 8 + mv_x >= w)
>  return AVERROR_INVALIDDATA;
> [...]
>
>> +
>> +static int read_code2(GetBitContext *gb, int *oskip, int *level)
>> +{
>> +int max, len = 0, skip = 0;
>> +
>> +if (show_bits(gb, 2)) {
>> +switch (show_bits(gb, 4)) {
>> +case 1:
>> +case 9:
>> +len = 1;
>> +skip = 3;
>> +break;
>> +case 2:
>> +len = 3;
>> +skip = 4;
>> +break;
>> +case 3:
>> +len = 7;
>> +skip = 4;
>> +break;
>> +case 5:
>> +case 0xD:
>> +len = 2;
>> +skip = 3;
>> +break;
>> +case 6:
>> +len = 4;
>> +skip = 4;
>> +break;
>> +case 7:
>> +len = 8;
>> +skip = 4;
>> +break;
>> +case 0xA:
>> +len = 5;
>> +skip = 4;
>> +break;
>> +case 0xB:
>> +len = 9;
>> +skip = 4;
>> +break;
>> +case 0xE:
>> +len = 6;
>> +skip = 4;
>> +break;
>> +case 0xF:
>> +len = ((show_bits(gb, 5) & 0x10) | 0xA0) >> 4;
>> +skip = 5;
>> +break;
>> +default:
>> +return AVERROR_INVALIDDATA;
>> +}
>> +skip_bits(gb, skip);
>> +*level = get_bits(gb, len);
>> +*oskip = 0;
>> +max = 1 << (len - 1);
>> +if (*level < max)
>> +*level = -(max + *level);
>> +} else if (show_bits(gb, 3) & 4) {
>> +skip_bits(gb, 3);
>
>> +if (show_bits(gb, 4)) {
>> +if (show_bits(gb, 4) == 1) {
>> +skip_bits(gb, 4);
>> +*oskip = get_bits(gb, 16);
>> +*level = 0;
>> +} else {
>> +*oskip = get_bits(gb, 4);
>> +*level = 0;
>> +}
>> +} else {
>> +skip_bits(gb, 4);
>> +*oskip = get_bits(gb, 10);
>> +*level = 0;
>> +}
>
> The oskip values which can be represented as shorter codes here (if they
> occur) likely are errors, this could be checked for. Not sure its useful
>
>
> [...]
>
>> +
>> +static int decode_frame(AVCodecContext *avctx, void *data,
>> +int *got_frame, AVPacket *avpkt)
>> +{
>> +AGMContext *s = avctx->priv_data;
>> +GetBitContext *gb = &s->gb;
>> +GetByteContext *gbyte = &s->gbyte;
>> +AVFrame *frame = data;
>> +int w, h, header;
>> +int ret;
>> +
>> +if (!avpkt->size)
>> +return 0;
>> +
>> +bytestream2_init(gbyte, avpkt->data, avpkt->size);
>> +
>> +header = bytestream2_get_le32(gbyte);
>> +if (header)
>> +avpriv_request_sample(avctx, "header %X", header);
>> +s->bitstream_size = bytestream2_get_le24(gbyte);
>> +if (avpkt->size < s->bitstream_size + 8)
>> +return AVERROR_INVALIDDATA;
>> +
>> +s->key_frame = bytestream2_get_byte(gbyte) == 32;
>> +frame->key_frame = s->key_frame;
>> +frame->pict_type = s->key_frame ? AV_PICTURE_TYPE_I :
>> AV_PICTURE_TYPE_P;
>> +
>> +s->flags = 0;
>> +w = bytestream2_get_le32(gbyte);
>> +if (w < 0) {
>> +w = -w;
>> +s->flags |= 2;
>> +}
>> +h = bytestream2_get_le32(gbyte);
>> +if (h < 0) {
>> +avpriv_request_sample(avctx, "negative height");
>> +h = -h;
>> +s->flags |= 1;
>> +}
>> +
>> +ret = ff_set_dimensions(avctx, w, h);
>> +if (ret < 0)
>> +return ret;
>
> i suspect this has issues with odd width / height
> the motion vectors, and luma and chroma plane sizes probably wont ali

Re: [FFmpeg-devel] [PATCH] avcodec: add Amuse Graphics decoder

2018-10-13 Thread Michael Niedermayer
On Wed, Oct 10, 2018 at 01:22:24PM +0200, Paul B Mahol wrote:
> This work is partially sponsored by VideoLAN.
> 
> Signed-off-by: Paul B Mahol 
> ---
> 

> The AGM3 variant decodes with some artifacts.

I looked a bit as you asked on IRC but wasnt able to really fix it in
the time i had available

The following patch avoids the green blocks but it does not feel correct

diff --git a/libavcodec/agm.c b/libavcodec/agm.c
index 424b906eac..a6d9a9a7a6 100644
--- a/libavcodec/agm.c
+++ b/libavcodec/agm.c
@@ -358,10 +358,12 @@ static int decode_inter_plane(AGMContext *s, 
GetBitContext *gb, int size,
 if (ret < 0)
 return ret;
 
-if (mv_x < min) {
+if (mv_x < min && s->block[0] > 512) {
 s->idsp.idct_put(frame->data[plane] + (s->blocks_h - 1 - 
y) * 8 * frame->linesize[plane] + x * 8,
  frame->linesize[plane], s->block);
 } else {
+if (mv_x < min)
+mv_x = 0;
 if (y * 8 + mv_y < 0 || y * 8 + mv_y >= h ||
 x * 8 + mv_x < 0 || x * 8 + mv_x >= w)
 return AVERROR_INVALIDDATA;
[...]

> +
> +static int read_code2(GetBitContext *gb, int *oskip, int *level)
> +{
> +int max, len = 0, skip = 0;
> +
> +if (show_bits(gb, 2)) {
> +switch (show_bits(gb, 4)) {
> +case 1:
> +case 9:
> +len = 1;
> +skip = 3;
> +break;
> +case 2:
> +len = 3;
> +skip = 4;
> +break;
> +case 3:
> +len = 7;
> +skip = 4;
> +break;
> +case 5:
> +case 0xD:
> +len = 2;
> +skip = 3;
> +break;
> +case 6:
> +len = 4;
> +skip = 4;
> +break;
> +case 7:
> +len = 8;
> +skip = 4;
> +break;
> +case 0xA:
> +len = 5;
> +skip = 4;
> +break;
> +case 0xB:
> +len = 9;
> +skip = 4;
> +break;
> +case 0xE:
> +len = 6;
> +skip = 4;
> +break;
> +case 0xF:
> +len = ((show_bits(gb, 5) & 0x10) | 0xA0) >> 4;
> +skip = 5;
> +break;
> +default:
> +return AVERROR_INVALIDDATA;
> +}
> +skip_bits(gb, skip);
> +*level = get_bits(gb, len);
> +*oskip = 0;
> +max = 1 << (len - 1);
> +if (*level < max)
> +*level = -(max + *level);
> +} else if (show_bits(gb, 3) & 4) {
> +skip_bits(gb, 3);

> +if (show_bits(gb, 4)) {
> +if (show_bits(gb, 4) == 1) {
> +skip_bits(gb, 4);
> +*oskip = get_bits(gb, 16);
> +*level = 0;
> +} else {
> +*oskip = get_bits(gb, 4);
> +*level = 0;
> +}
> +} else {
> +skip_bits(gb, 4);
> +*oskip = get_bits(gb, 10);
> +*level = 0;
> +}

The oskip values which can be represented as shorter codes here (if they
occur) likely are errors, this could be checked for. Not sure its useful


[...]

> +
> +static int decode_frame(AVCodecContext *avctx, void *data,
> +int *got_frame, AVPacket *avpkt)
> +{
> +AGMContext *s = avctx->priv_data;
> +GetBitContext *gb = &s->gb;
> +GetByteContext *gbyte = &s->gbyte;
> +AVFrame *frame = data;
> +int w, h, header;
> +int ret;
> +
> +if (!avpkt->size)
> +return 0;
> +
> +bytestream2_init(gbyte, avpkt->data, avpkt->size);
> +
> +header = bytestream2_get_le32(gbyte);
> +if (header)
> +avpriv_request_sample(avctx, "header %X", header);
> +s->bitstream_size = bytestream2_get_le24(gbyte);
> +if (avpkt->size < s->bitstream_size + 8)
> +return AVERROR_INVALIDDATA;
> +
> +s->key_frame = bytestream2_get_byte(gbyte) == 32;
> +frame->key_frame = s->key_frame;
> +frame->pict_type = s->key_frame ? AV_PICTURE_TYPE_I : AV_PICTURE_TYPE_P;
> +
> +s->flags = 0;
> +w = bytestream2_get_le32(gbyte);
> +if (w < 0) {
> +w = -w;
> +s->flags |= 2;
> +}
> +h = bytestream2_get_le32(gbyte);
> +if (h < 0) {
> +avpriv_request_sample(avctx, "negative height");
> +h = -h;
> +s->flags |= 1;
> +}
> +
> +ret = ff_set_dimensions(avctx, w, h);
> +if (ret < 0)
> +return ret;

i suspect this has issues with odd width / height
the motion vectors, and luma and chroma plane sizes probably wont align and then
likely not work as intended as each rounds differently


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

Old school: Use the lowest level language in which you can solve the problem
   

Re: [FFmpeg-devel] [PATCH] avformat: add SER demuxer

2018-10-13 Thread Paul B Mahol
On 10/12/18, Paul B Mahol  wrote:
> Fixes #6821.
>

Will comitt with this above sentence removed.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel


Re: [FFmpeg-devel] swscale/x86/rgb2rgb : port shuffle2103 to external asm

2018-10-13 Thread Martin Vignali
> thats eliminates my concern
>
> Pushed, thanks.

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


Re: [FFmpeg-devel] prores_ks: use CodecContext for color information if specified

2018-10-13 Thread Martin Vignali
Le mer. 10 oct. 2018 à 17:13, Marc-Antoine ARNAUD <
arnaud.marcanto...@gmail.com> a écrit :

> I have updated the patch with our discussion.
> It took information only from the codec context.
>
> Marc-Antoine
>
> Hello,

If i correctly understand (which is not sure :-) :

the colorspace for AVCodecContext, is when all frame use the same colorspace

The colorspace in AVFrame, manage the case where colorspace can not be the
same inside each frame.
and this info is use inside filtering graph.

If this is correct, then prores encoder need to use AVFrame colorspace for
each frame
and if the colorspace information is wrong, or if user need to set another
one, a filter need to be use to edit the frame (set colorspace information
or convert from one colorspace to another frame by frame)
(Or if just the colorspace metadata inside the compress prores frame need
to be fix,  a bsf can be write to edit frame colorspace properties for
prores frame)

Another way can be to add an option to the prores encoder, to take
colorspace information from CodecContext or from Frame.


But if other people think your way is better,
i will change my patch for prores_aw, in order to use the same way to set
colorspace for each prores frame.

P.S. : Seems like png at least also use AVFrame information instead of
AVCodecContext

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


Re: [FFmpeg-devel] [PATCH V2 1/2] lavf/vc1test: fix vc1test can't probe some RCV file.

2018-10-13 Thread myp...@gmail.com
On Sat, Oct 13, 2018 at 4:51 PM Jerome Borsboom
 wrote:
>
> > On Sat, Oct 13, 2018 at 12:55 AM mypopy at gmail.com  
> > wrote:
> >>
> >> On Fri, Oct 12, 2018 at 10:35 PM Carl Eugen Hoyos 
> > wrote:
> >> >
> >> > 2018-10-12 15:41 GMT+02:00, Jun Zhao :
> >> > > case 1:
> >> > > use the hexdump -C SMM0005.rcv get:
> >> > >  size  skip (size - 4)
> >> > >   ||
> >> > >   VV
> >> > >   18 00 00 c5 05 00 00 00  4d f1 0a 11 00 e0 01 00
> >> > > 0010  00 d0 02 00 00 0c 00 00  00 88 13 00 00 c0 65 52
> >> > >  ^
> >> > >|
> >> > >size + 16
> >> > > case 2:
> >> > > same the command for SMM0015.rcv get:
> >> > > size
> >> > >   |
> >> > >   V
> >> > >   19 00 00 c5 04 00 00 00  41 f3 80 01 40 02 00 00
> >> > > 0010  d0 02 00 00 0c 00 00 00  00 00 00 10 00 00 00 00
> >> > >   ^
> >> > > |
> >> > >  size + 16
> >> > >
> >> > > There are different the RCV file format for VC-1, vc1test
> >> > > just handle the case 2 now, this fix will support the case 1.
> >> >
> >> > Both with and without your patch, I get identical output from
> >> > FFmpeg's decoder for both SSM0015.rcv and SMM0005.rcv.
> >> > What exactly is your patch supposed to change?
> >> >
> >> > $ md5sum SMM0005.rcv
> >> > abd0fa5ec90d44f7b4865c6930d65ff2  SMM0005.rcv
> >> > $ md5sum SSM0015.rcv
> >> > 21a0281f83b7f2e99a048b180dd3347f  SSM0015.rcv
> >>
> >> In my test clips, I get md5 like this
> >> $ md5sum SMM0005.rcv
> >> 39eb225dbfafacea3e3737deba789530  SMM0005.rcv
> >> $ md5sum SMM0015.rcv
> >> 78e45e50079e143e69f69d677c37ac3b  SMM0015.rcv
> > RCV format have a different version, you can google the rcv1 rcv2 for VC-1.
> > (e,g:
> > http://www.ti.com/lit/ml/sprs363a/sprs363a.pdf), I think we use a different
> > RCV format for test clips SMM0005.rcv
>
> This has nothing to do with the version. Version is coded as the sixth
> bit in the initial byte, i.e. 0x85 = version 1, 0xc5 = version 2.
>
> VC-1(2006) is quite clear in Annex L that the second dword should be a
> 0x0004. The reference decoder, however, is more lenient and gives
> more insight. The 0x0004, and the 0x000c in the seventh dword,
> seem to be meant as a length indicator for the STRUCT_C and the
> STRUCT_B, respectively.
>
> This may be a leftover from older versions. I think it won't hurt to
> follow the reference decoder here and interpret these dwords as length
> indicators. The patch could be adjusted to do this for the 0x000c as
> well.
>
I agree with your, I think I get a older VC-1 test clip in this case.
>
> Regards,
> Jerome
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel


Re: [FFmpeg-devel] Fixing rotation metadata override

2018-10-13 Thread Carl Eugen Hoyos
2018-10-13 8:31 GMT+02:00, Gilles :

> here is a fix for issue: https://trac.ffmpeg.org/ticket/4560

This ticket was fixed years ago and the issue is not
reproducible with current FFmpeg git head.

> Background: since FFmpeg 3.3, it is not possible to force
> the rotation metadata to 0, when video is being converted.
> It only work in -c:v copy mode.

Sounds like ticket #6370.

Carl Eugen
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel


[FFmpeg-devel] [PATCH]lavf/mxfenc: Remove a write-only variable

2018-10-13 Thread Carl Eugen Hoyos
Hi!

Attached patch fixes a warning, I wonder if the value is actually
supposed to use somewhere...

Please comment, Carl Eugen
From ee679d874aeacc027edcd370464bd7ea7fd7ae7d Mon Sep 17 00:00:00 2001
From: Carl Eugen Hoyos 
Date: Sat, 13 Oct 2018 13:10:29 +0200
Subject: [PATCH] lavf/mxfenc: Remove a write-only variable.

Fixes the following warning:
libavformat/mxfenc.c:2125:22: warning: variable 'frame_size' set but not used
---
 libavformat/mxfenc.c |7 +--
 1 file changed, 1 insertion(+), 6 deletions(-)

diff --git a/libavformat/mxfenc.c b/libavformat/mxfenc.c
index f6acf80..a2f68dd 100644
--- a/libavformat/mxfenc.c
+++ b/libavformat/mxfenc.c
@@ -2122,7 +2122,7 @@ static int mxf_parse_dv_frame(AVFormatContext *s, AVStream *st, AVPacket *pkt)
 MXFContext *mxf = s->priv_data;
 MXFStreamContext *sc = st->priv_data;
 uint8_t *vs_pack, *vsc_pack;
-int ul_index, frame_size, stype, pal;
+int ul_index, stype, pal;
 const AVDVProfile *profile;
 
 if (mxf->header_written)
@@ -2153,7 +2153,6 @@ static int mxf_parse_dv_frame(AVFormatContext *s, AVStream *st, AVPacket *pkt)
 switch (stype) {
 case 0x18: // DV100 720p
 ul_index = INDEX_DV100_720_50 + pal;
-frame_size = pal ? 288000 : 24;
 if (sc->interlaced) {
 av_log(s, AV_LOG_ERROR, "source marked as interlaced but codec profile is progressive\n");
 sc->interlaced = 0;
@@ -2161,20 +2160,16 @@ static int mxf_parse_dv_frame(AVFormatContext *s, AVStream *st, AVPacket *pkt)
 break;
 case 0x14: // DV100 1080i
 ul_index = INDEX_DV100_1080_50 + pal;
-frame_size = pal ? 576000 : 48;
 break;
 case 0x04: // DV50
 ul_index = INDEX_DV50_525_60 + pal;
-frame_size = pal ? 288000 : 24;
 break;
 default: // DV25
 if (profile && profile->pix_fmt == AV_PIX_FMT_YUV420P && pal) {
 ul_index = INDEX_DV25_525_60_IEC + pal;
-frame_size = pal ? 144000 : 12;
 break;
 }
 ul_index = INDEX_DV25_525_60 + pal;
-frame_size = pal ? 144000 : 12;
 }
 
 sc->index = ul_index;
-- 
1.7.10.4

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


Re: [FFmpeg-devel] [PATCH v2] lavfi/vf_colorconstancy: add weighted_greyedge

2018-10-13 Thread Mina



On 10/01/2018 06:09 PM, Mina wrote:

Hi,

  This patch was part of GSoC Color Constancy filter. It introduces an 
improved color constancy filter(weighted_greyedge) based on the 
already pushed greyedge. I'm sending it again after updating it 
against latest version of master.


V2 changes:
- fixed some spelling mistakes in filters.texi
- fixed some text format error in filters.texi


Regards,
Mina Sami



A gentle ping.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel


Re: [FFmpeg-devel] [PATCH V2 1/2] lavf/vc1test: fix vc1test can't probe some RCV file.

2018-10-13 Thread Jerome Borsboom
> On Sat, Oct 13, 2018 at 12:55 AM mypopy at gmail.com  
> wrote:
>>
>> On Fri, Oct 12, 2018 at 10:35 PM Carl Eugen Hoyos 
> wrote:
>> >
>> > 2018-10-12 15:41 GMT+02:00, Jun Zhao :
>> > > case 1:
>> > > use the hexdump -C SMM0005.rcv get:
>> > >  size  skip (size - 4)
>> > >   ||
>> > >   VV
>> > >   18 00 00 c5 05 00 00 00  4d f1 0a 11 00 e0 01 00
>> > > 0010  00 d0 02 00 00 0c 00 00  00 88 13 00 00 c0 65 52
>> > >  ^
>> > >|
>> > >size + 16
>> > > case 2:
>> > > same the command for SMM0015.rcv get:
>> > > size
>> > >   |
>> > >   V
>> > >   19 00 00 c5 04 00 00 00  41 f3 80 01 40 02 00 00
>> > > 0010  d0 02 00 00 0c 00 00 00  00 00 00 10 00 00 00 00
>> > >   ^
>> > > |
>> > >  size + 16
>> > >
>> > > There are different the RCV file format for VC-1, vc1test
>> > > just handle the case 2 now, this fix will support the case 1.
>> >
>> > Both with and without your patch, I get identical output from
>> > FFmpeg's decoder for both SSM0015.rcv and SMM0005.rcv.
>> > What exactly is your patch supposed to change?
>> >
>> > $ md5sum SMM0005.rcv
>> > abd0fa5ec90d44f7b4865c6930d65ff2  SMM0005.rcv
>> > $ md5sum SSM0015.rcv
>> > 21a0281f83b7f2e99a048b180dd3347f  SSM0015.rcv
>>
>> In my test clips, I get md5 like this
>> $ md5sum SMM0005.rcv
>> 39eb225dbfafacea3e3737deba789530  SMM0005.rcv
>> $ md5sum SMM0015.rcv
>> 78e45e50079e143e69f69d677c37ac3b  SMM0015.rcv
> RCV format have a different version, you can google the rcv1 rcv2 for VC-1.
> (e,g:
> http://www.ti.com/lit/ml/sprs363a/sprs363a.pdf), I think we use a different
> RCV format for test clips SMM0005.rcv

This has nothing to do with the version. Version is coded as the sixth
bit in the initial byte, i.e. 0x85 = version 1, 0xc5 = version 2.

VC-1(2006) is quite clear in Annex L that the second dword should be a
0x0004. The reference decoder, however, is more lenient and gives
more insight. The 0x0004, and the 0x000c in the seventh dword,
seem to be meant as a length indicator for the STRUCT_C and the
STRUCT_B, respectively.

This may be a leftover from older versions. I think it won't hurt to
follow the reference decoder here and interpret these dwords as length
indicators. The patch could be adjusted to do this for the 0x000c as
well.


Regards,
Jerome
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel


[FFmpeg-devel] [PATCH V2] lavfi/vf_scale_vaapi: add scaling mode setting support.

2018-10-13 Thread Jun Zhao
before this change, scale_vaapi hard coding the scaling mode, add a
new option "mode" to setting the scaling mode, it can be use to change
scaling algorithm for performance/quality trade off.

Signed-off-by: Jun Zhao 
---
 libavfilter/vf_scale_vaapi.c |   33 ++---
 1 files changed, 30 insertions(+), 3 deletions(-)

diff --git a/libavfilter/vf_scale_vaapi.c b/libavfilter/vf_scale_vaapi.c
index d6529d5..ad222e6 100644
--- a/libavfilter/vf_scale_vaapi.c
+++ b/libavfilter/vf_scale_vaapi.c
@@ -35,10 +35,26 @@ typedef struct ScaleVAAPIContext {
 
 char *output_format_string;
 
+int   mode;
+
 char *w_expr;  // width expression string
 char *h_expr;  // height expression string
 } ScaleVAAPIContext;
 
+static const char *scale_vaapi_mode_name(int mode)
+{
+switch (mode) {
+#define D(name) case VA_FILTER_SCALING_ ## name: return #name
+D(DEFAULT);
+D(FAST);
+D(HQ);
+#undef D
+default:
+return "Invalid";
+}
+}
+
+
 static int scale_vaapi_config_output(AVFilterLink *outlink)
 {
 AVFilterLink *inlink = outlink->src->inputs[0];
@@ -70,6 +86,7 @@ static int scale_vaapi_filter_frame(AVFilterLink *inlink, 
AVFrame *input_frame)
 AVFilterContext *avctx   = inlink->dst;
 AVFilterLink *outlink= avctx->outputs[0];
 VAAPIVPPContext *vpp_ctx = avctx->priv;
+ScaleVAAPIContext *ctx   = avctx->priv;
 AVFrame *output_frame= NULL;
 VASurfaceID input_surface, output_surface;
 VAProcPipelineParameterBuffer params;
@@ -119,7 +136,7 @@ static int scale_vaapi_filter_frame(AVFilterLink *inlink, 
AVFrame *input_frame)
 params.output_color_standard = params.surface_color_standard;
 
 params.pipeline_flags = 0;
-params.filter_flags = VA_FILTER_SCALING_HQ;
+params.filter_flags |= ctx->mode;
 
 err = ff_vaapi_vpp_render_picture(avctx, ¶ms, output_surface);
 if (err < 0)
@@ -131,9 +148,10 @@ static int scale_vaapi_filter_frame(AVFilterLink *inlink, 
AVFrame *input_frame)
 
 av_frame_free(&input_frame);
 
-av_log(avctx, AV_LOG_DEBUG, "Filter output: %s, %ux%u (%"PRId64").\n",
+av_log(avctx, AV_LOG_DEBUG, "Filter output: %s, %ux%u (%"PRId64"), mode: 
%s.\n",
av_get_pix_fmt_name(output_frame->format),
-   output_frame->width, output_frame->height, output_frame->pts);
+   output_frame->width, output_frame->height, output_frame->pts,
+   scale_vaapi_mode_name(ctx->mode));
 
 return ff_filter_frame(outlink, output_frame);
 
@@ -174,6 +192,15 @@ static const AVOption scale_vaapi_options[] = {
   OFFSET(h_expr), AV_OPT_TYPE_STRING, {.str = "ih"}, .flags = FLAGS },
 { "format", "Output video format (software format of hardware frames)",
   OFFSET(output_format_string), AV_OPT_TYPE_STRING, .flags = FLAGS },
+{ "mode", "Scaling mode",
+  OFFSET(mode), AV_OPT_TYPE_INT, { .i64 = VA_FILTER_SCALING_HQ },
+  0, VA_FILTER_SCALING_NL_ANAMORPHIC, FLAGS, "mode" },
+{ "default", "Use the default (depend on the driver) scaling algorithm",
+  0, AV_OPT_TYPE_CONST, { .i64 = VA_FILTER_SCALING_DEFAULT }, 0, 0, FLAGS, 
"mode" },
+{ "fast", "Use fast scaling algorithm",
+  0, AV_OPT_TYPE_CONST, { .i64 = VA_FILTER_SCALING_FAST }, 0, 0, FLAGS, 
"mode" },
+{ "hq", "Use high quality scaling algorithm",
+  0, AV_OPT_TYPE_CONST, { .i64 = VA_FILTER_SCALING_HQ }, 0, 0, FLAGS,  
"mode" },
 { NULL },
 };
 
-- 
1.7.1

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