date:20180307

[FFmpeg-devel] [PATCH v1 1/1] avformat/http: fix for zero window size issue when

2018-03-07 Thread rpatagar

From: Ravindra 

---
 libavformat/http.c | 13 +
 1 file changed, 13 insertions(+)

diff --git a/libavformat/http.c b/libavformat/http.c
index 344fd60..a93fa54 100644
--- a/libavformat/http.c
+++ b/libavformat/http.c
@@ -1611,6 +1611,18 @@ static int http_write(URLContext *h, const uint8_t *buf, 
int size)
 return size;
 }
 
+static int http_read_response(URLContext *h) {
+HTTPContext *s = h->priv_data;
+char buf[1024];
+int ret;
+
+/* dummy read in nonblocking mode to clear the receive buffer */
+s->hd->flags |= AVIO_FLAG_NONBLOCK;
+ret = ffurl_read(s->hd, buf, sizeof(buf));
+s->hd->flags &= ~AVIO_FLAG_NONBLOCK;
+return ret;
+}
+
 static int http_shutdown(URLContext *h, int flags)
 {
 int ret = 0;
@@ -1622,6 +1634,7 @@ static int http_shutdown(URLContext *h, int flags)
 ((flags & AVIO_FLAG_READ) && s->chunked_post && s->listen)) {
 ret = ffurl_write(s->hd, footer, sizeof(footer) - 1);
 ret = ret > 0 ? 0 : ret;
+http_read_response(h);
 s->end_chunked_post = 1;
 }
 
-- 
1.9.1

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

[FFmpeg-devel] [PATCH v2 1/1] avformat/http: fix for zero window size issue

2018-03-07 Thread rpatagar

From: Ravindra 

When http persistent conenction is enabled for streaming, TCP window size
reduces consistently and reaches zero
---
 libavformat/http.c | 13 +
 1 file changed, 13 insertions(+)

diff --git a/libavformat/http.c b/libavformat/http.c
index 344fd60..a93fa54 100644
--- a/libavformat/http.c
+++ b/libavformat/http.c
@@ -1611,6 +1611,18 @@ static int http_write(URLContext *h, const uint8_t *buf, 
int size)
 return size;
 }
 
+static int http_read_response(URLContext *h) {
+HTTPContext *s = h->priv_data;
+char buf[1024];
+int ret;
+
+/* dummy read in nonblocking mode to clear the receive buffer */
+s->hd->flags |= AVIO_FLAG_NONBLOCK;
+ret = ffurl_read(s->hd, buf, sizeof(buf));
+s->hd->flags &= ~AVIO_FLAG_NONBLOCK;
+return ret;
+}
+
 static int http_shutdown(URLContext *h, int flags)
 {
 int ret = 0;
@@ -1622,6 +1634,7 @@ static int http_shutdown(URLContext *h, int flags)
 ((flags & AVIO_FLAG_READ) && s->chunked_post && s->listen)) {
 ret = ffurl_write(s->hd, footer, sizeof(footer) - 1);
 ret = ret > 0 ? 0 : ret;
+http_read_response(h);
 s->end_chunked_post = 1;
 }
 
-- 
1.9.1

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

[FFmpeg-devel] [PATCH] avfilter: add drmeter audio filter

2018-03-07 Thread Paul B Mahol

Signed-off-by: Paul B Mahol 
---
 doc/filters.texi |  11 +++
 libavfilter/Makefile |   1 +
 libavfilter/af_drmeter.c | 233 +++
 libavfilter/allfilters.c |   1 +
 4 files changed, 246 insertions(+)
 create mode 100644 libavfilter/af_drmeter.c

diff --git a/doc/filters.texi b/doc/filters.texi
index 7151d4c748..c166aae788 100644
--- a/doc/filters.texi
+++ b/doc/filters.texi
@@ -2538,6 +2538,17 @@ Optional. It should have a value much less than 1 (e.g. 
0.05 or 0.02) and is
 used to prevent clipping.
 @end table
 
+@section drmeter
+Measure audio dynamic range.
+
+The filter accepts the following options:
+
+@table @option
+@item length
+Set window lenght in seconds used to split audio into segments of equal length.
+Default is 3 seconds.
+@end table
+
 @section dynaudnorm
 Dynamic Audio Normalizer.
 
diff --git a/libavfilter/Makefile b/libavfilter/Makefile
index 6a6083618d..fc16512e2c 100644
--- a/libavfilter/Makefile
+++ b/libavfilter/Makefile
@@ -87,6 +87,7 @@ OBJS-$(CONFIG_COMPENSATIONDELAY_FILTER)  += 
af_compensationdelay.o
 OBJS-$(CONFIG_CROSSFEED_FILTER)  += af_crossfeed.o
 OBJS-$(CONFIG_CRYSTALIZER_FILTER)+= af_crystalizer.o
 OBJS-$(CONFIG_DCSHIFT_FILTER)+= af_dcshift.o
+OBJS-$(CONFIG_DRMETER_FILTER)+= af_drmeter.o
 OBJS-$(CONFIG_DYNAUDNORM_FILTER) += af_dynaudnorm.o
 OBJS-$(CONFIG_EARWAX_FILTER) += af_earwax.o
 OBJS-$(CONFIG_EBUR128_FILTER)+= f_ebur128.o
diff --git a/libavfilter/af_drmeter.c b/libavfilter/af_drmeter.c
new file mode 100644
index 00..d088d8e08f
--- /dev/null
+++ b/libavfilter/af_drmeter.c
@@ -0,0 +1,233 @@
+/*
+ * 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 "libavutil/ffmath.h"
+#include "libavutil/opt.h"
+#include "audio.h"
+#include "avfilter.h"
+#include "internal.h"
+
+typedef struct ChannelStats {
+uint64_t nb_samples;
+uint64_t blknum;
+float peak;
+float sum;
+uint32_t peaks[10001];
+uint32_t rms[10001];
+} ChannelStats;
+
+typedef struct DRMeterContext {
+const AVClass *class;
+ChannelStats *chstats;
+int nb_channels;
+uint64_t tc_samples;
+double time_constant;
+} DRMeterContext;
+
+#define OFFSET(x) offsetof(DRMeterContext, x)
+#define FLAGS AV_OPT_FLAG_AUDIO_PARAM|AV_OPT_FLAG_FILTERING_PARAM
+
+static const AVOption drmeter_options[] = {
+{ "length", "set the window length", OFFSET(time_constant), 
AV_OPT_TYPE_DOUBLE, {.dbl=3}, .01, 10, FLAGS },
+{ NULL }
+};
+
+AVFILTER_DEFINE_CLASS(drmeter);
+
+static int query_formats(AVFilterContext *ctx)
+{
+AVFilterFormats *formats;
+AVFilterChannelLayouts *layouts;
+static const enum AVSampleFormat sample_fmts[] = {
+AV_SAMPLE_FMT_FLTP, AV_SAMPLE_FMT_FLT,
+AV_SAMPLE_FMT_NONE
+};
+int ret;
+
+layouts = ff_all_channel_counts();
+if (!layouts)
+return AVERROR(ENOMEM);
+ret = ff_set_common_channel_layouts(ctx, layouts);
+if (ret < 0)
+return 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;
+
+formats = ff_all_samplerates();
+if (!formats)
+return AVERROR(ENOMEM);
+return ff_set_common_samplerates(ctx, formats);
+}
+
+static int config_output(AVFilterLink *outlink)
+{
+DRMeterContext *s = outlink->src->priv;
+
+s->chstats = av_calloc(sizeof(*s->chstats), outlink->channels);
+if (!s->chstats)
+return AVERROR(ENOMEM);
+s->nb_channels = outlink->channels;
+s->tc_samples = s->time_constant * outlink->sample_rate + .5;
+
+return 0;
+}
+
+static void finish_block(ChannelStats *p)
+{
+int peak_bin, rms_bin;
+float peak, rms;
+
+rms = sqrt(2 * p->sum / p->nb_samples);
+peak = p->peak;
+rms_bin = av_clip(rms * 1, 0, 1);
+peak_bin = av_clip(peak * 1, 0, 1);
+p->rms[rms_bin]++;
+p->peaks[peak_bin]++;
+
+p->peak = 0;
+p->sum = 0;
+p->nb_samples = 0;
+p->blknum++;
+}
+
+static void update_stat(DRMeterContext *s, ChannelStats *p, float

Re: [FFmpeg-devel] [PATCH] libavformat/mov.c: use calculated dts offset when seeking in streams

2018-03-07 Thread Michael Niedermayer

On Mon, Mar 05, 2018 at 03:53:04PM -0800, Sasi Inguva wrote:
> This patch seems to be doing the wrong thing and breaking seek tests for us.
> 
> As far as I understand , seeking for most containers is based on "decoding
> timestamp". Unless  AV_SEEK_TO_PTS flag is specified in container, which is
> not for most containers and MOV.  So if PTS and DTS are like such,

I think most seeking in libavformat uses whatever was convenient for the 
implementation of each demuxer. Some are much more carefully implemented
than others. Iam not so sure its consistently DTS when AVFMT_SEEK_TO_PTS
is not set.

> Pts  Dts
>  0  -2   : frame0
>  1  -1   : frame1
>  2   0   : frame2
>  3   1   : frame3
> ...
> Seeking  to "0" timestamp without any flags, I should expect frame2 . But
> instead this patch will give me frame0 . The patch's intention seems to be
> seeking based on PTS (subtracting by the sc->time_offset essentially is a
> mapping from PTS to DTS) .

IMO, seeking per PTS is more usefull to end users, the user gets what he asked
for, a frame that he can display at that requested time.
The ultimate goal should be to have proper frame exact seeking or as close to
it as practically implementable.

DTS is sometimes easier to implement on our side. 
But with seeking per DTS it is a heuristic gamble on how to get a frame to
display at a specific timestamp. Its possible with seek per dts to never
get a frame displayable at the time requested.

For formats with a full index like mov/mp4 seeking per pts should be IMHO be
preferred over dts.

There are more corner cases that require mentioning, like for example that there
can be a B frame after a I frame with a pts prior to the I frame.
as in

coded order:
Pts Dts 
1  -1   I frame
0   0   B frame
3   1   P frame
2   2   B frame
It is desirable and valid to seek to the I frame at pts=1 for a seek targeting 
the B frame  at pts=0 if and only if this B frame can be displayed and 
does not depend on a frame of the prior GOP (streams generally have flags
in their headers for this specific case to be detectable)

Furthermore, if the goal is to seek to pts=5 and there is a keyframe at pts=5
and one at pts=4. And there is another stream that can only be decoded at pts=5
if demuxing starts at pts=4 then the demuxer can seek to pts=4 instead of 5.
This is especially the case for containers with subtitles where their
display may require positioning at a earlier place and then potentially
discarding packets in streams that are unneeded.

also avformat_seek_file() allows much more flexibility for the user to specify
where and how to seek. And where the av_seek_frame() API does not specify
what timestamp is used. avformat_seek_file() does specify that
"can be presented successfully" and can thus not be just DTS

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

It is what and why we do it that matters, not just one of them.

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

Re: [FFmpeg-devel] [PATCH] avcodec/mediacodec_wrapper: fix false positives in swdec blacklist

2018-03-07 Thread Matthieu Bouron

On Wed, Mar 07, 2018 at 01:35:20AM +0200, Jan Ekström wrote:
> On Wed, Mar 7, 2018 at 12:19 AM, Stefan _  wrote:
> > Hi,
> >
> > attached patch fixes an issue with the previous mediacodec patch.
> >
> 
> LGTM.
> 
> `strstr(name, "OMX.SEC") && strstr(name, ".sw.")`
> 
> ..will most likely have less false positives as OMX.SEC seems to be
> utilized for HW decoders on some Exynos SoCs.

Patch applied.

Thanks,

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

[FFmpeg-devel] [PATCH v4] avformat/pcm: decrease delay when reading PCM streams.

2018-03-07 Thread Philipp M. Scholl

 Here is the fourth version of the PCM patch with updated testcases.

 The blocksize of the PCM decoder is hard-coded. This creates
unnecessary delay when reading low-rate (<100Hz) streams. This creates
issues when multiplexing multiple streams, since other inputs are only
opened/read after a low-rate input block was completely read.

 This patch decreases the blocksize for low-rate inputs, so
approximately a block is read every 40ms. This decreases the startup
delay when multiplexing inputs with different rates.

Signed-off-by: Philipp M. Scholl 
---
 libavformat/pcm.c | 16 
 tests/ref/seek/lavf-alaw  | 42 +-
 tests/ref/seek/lavf-mulaw | 42 +-
 3 files changed, 54 insertions(+), 46 deletions(-)

diff --git a/libavformat/pcm.c b/libavformat/pcm.c
index 806f91b6b..1ea15a9e8 100644
--- a/libavformat/pcm.c
+++ b/libavformat/pcm.c
@@ -28,13 +28,21 @@
 
 int ff_pcm_read_packet(AVFormatContext *s, AVPacket *pkt)
 {
-int ret, size;
+int ret, size = INT_MAX;
+AVCodecParameters *par = s->streams[0]->codecpar;
 
-size= RAW_SAMPLES*s->streams[0]->codecpar->block_align;
-if (size <= 0)
+if (par->block_align <= 0)
 return AVERROR(EINVAL);
 
-ret= av_get_packet(s->pb, pkt, size);
+/*
+ * Compute read size to complete a read every 40ms.  Clamp to RAW_SAMPLES 
if
+ * larger. Use power of two as readsize for I/O efficiency.
+ */
+size = FFMAX(par->sample_rate/25, 1);
+size = FFMIN(size, RAW_SAMPLES) * par->block_align;
+size = 1 << ff_log2(size);
+
+ret = av_get_packet(s->pb, pkt, size);
 
 pkt->flags &= ~AV_PKT_FLAG_CORRUPT;
 pkt->stream_index = 0;
diff --git a/tests/ref/seek/lavf-alaw b/tests/ref/seek/lavf-alaw
index 4b1f8fbc0..b61e687a4 100644
--- a/tests/ref/seek/lavf-alaw
+++ b/tests/ref/seek/lavf-alaw
@@ -1,53 +1,53 @@
-ret: 0 st: 0 flags:1 dts: 0.00 pts: 0.00 pos:  0 size:  
1024
+ret: 0 st: 0 flags:1 dts: 0.00 pts: 0.00 pos:  0 size:   
512
 ret: 0 st:-1 flags:0  ts:-1.00
-ret: 0 st: 0 flags:1 dts: 0.00 pts: 0.00 pos:  0 size:  
1024
+ret: 0 st: 0 flags:1 dts: 0.00 pts: 0.00 pos:  0 size:   
512
 ret: 0 st:-1 flags:1  ts: 1.894167
-ret: 0 st: 0 flags:1 dts: 1.894150 pts: 1.894150 pos:  41766 size:  
1024
+ret: 0 st: 0 flags:1 dts: 1.894150 pts: 1.894150 pos:  41766 size:   
512
 ret: 0 st: 0 flags:0  ts: 0.788345
-ret: 0 st: 0 flags:1 dts: 0.788345 pts: 0.788345 pos:  17383 size:  
1024
+ret: 0 st: 0 flags:1 dts: 0.788345 pts: 0.788345 pos:  17383 size:   
512
 ret: 0 st: 0 flags:1  ts:-0.317506
-ret: 0 st: 0 flags:1 dts: 0.00 pts: 0.00 pos:  0 size:  
1024
+ret: 0 st: 0 flags:1 dts: 0.00 pts: 0.00 pos:  0 size:   
512
 ret: 0 st:-1 flags:0  ts: 2.576668
 ret:-EOF
 ret: 0 st:-1 flags:1  ts: 1.470835
-ret: 0 st: 0 flags:1 dts: 1.470839 pts: 1.470839 pos:  32432 size:  
1024
+ret: 0 st: 0 flags:1 dts: 1.470839 pts: 1.470839 pos:  32432 size:   
512
 ret: 0 st: 0 flags:0  ts: 0.364989
-ret: 0 st: 0 flags:1 dts: 0.364989 pts: 0.364989 pos:   8048 size:  
1024
+ret: 0 st: 0 flags:1 dts: 0.364989 pts: 0.364989 pos:   8048 size:   
512
 ret: 0 st: 0 flags:1  ts:-0.740816
-ret: 0 st: 0 flags:1 dts: 0.00 pts: 0.00 pos:  0 size:  
1024
+ret: 0 st: 0 flags:1 dts: 0.00 pts: 0.00 pos:  0 size:   
512
 ret: 0 st:-1 flags:0  ts: 2.153336
 ret:-EOF
 ret: 0 st:-1 flags:1  ts: 1.047503
-ret: 0 st: 0 flags:1 dts: 1.047483 pts: 1.047483 pos:  23097 size:  
1024
+ret: 0 st: 0 flags:1 dts: 1.047483 pts: 1.047483 pos:  23097 size:   
512
 ret: 0 st: 0 flags:0  ts:-0.058322
-ret: 0 st: 0 flags:1 dts: 0.00 pts: 0.00 pos:  0 size:  
1024
+ret: 0 st: 0 flags:1 dts: 0.00 pts: 0.00 pos:  0 size:   
512
 ret: 0 st: 0 flags:1  ts: 2.835828
 ret:-EOF
 ret: 0 st:-1 flags:0  ts: 1.730004
-ret: 0 st: 0 flags:1 dts: 1.730023 pts: 1.730023 pos:  38147 size:  
1024
+ret: 0 st: 0 flags:1 dts: 1.730023 pts: 1.730023 pos:  38147 size:   
512
 ret: 0 st:-1 flags:1  ts: 0.624171
-ret: 0 st: 0 flags:1 dts: 0.624172 pts: 0.624172 pos:  13763 size:  
1024
+ret: 0 st: 0 flags:1 dts: 0.624172 pts: 0.624172 pos:  13763 size:   
512
 ret: 0 st: 0 flags:0  ts:-0.481678
-ret: 0 st: 0 flags:1 dts: 0.00 pts: 0.00 pos:  0 size:  
1024
+ret: 0 st: 0 flags:1 dts: 0.00 pts: 0.00 pos:  0 size:   
512
 ret: 0 st: 0 flags:1  ts: 2.412517
 ret:-EOF
 ret: 0 st:-1 flags:0  ts: 1.306672
-ret: 0 st: 0 flags:1 dts: 1.306667 pts: 1.306667 pos:  28812 size:  
1024
+ret: 0 st: 0 flags:1 dts: 1.306667 pts: 1.3

Re: [FFmpeg-devel] [PATCH 2/5] CodeAi generated fix for CWE 457 Uninitialized Variable

2018-03-07 Thread Nicolas George

C0deAi (2018-03-06):
> Prevent uninitialized value 'pb[1]' being passed as an
> argument on line 143.
> 
> Signed-off-by: C0deAi 
> ---
>  libavformat/img2enc.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)

Nack. Passing NULL to avio_write() is just as wrong as passing
uninitialized. And it is not reachable anyway.

Regards,

-- 
  Nicolas George


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

Re: [FFmpeg-devel] [PATCH 1/2] avcodec/mediacodecdec: add delay_flush option

2018-03-07 Thread Matthieu Bouron

On Tue, Mar 06, 2018 at 01:15:55PM -0800, Aman Gupta wrote:
> From: Aman Gupta 
> 
> The default behavior of the mediacodec decoder before this commit
> was to delay flushes until all pending hardware frames were
> returned to the decoder. This was useful for certain types of
> applications, but was unexpected behavior for others.
> 
> The new default behavior with this commit is now to execute
> flushes immediately to invalidate all pending frames. The old
> behavior can be enabled by setting delay_flush=1.
> 
> With the new behavior, video players implementing seek can simply
> call flush on the decoder without having to worry about whether
> they have one or more mediacodec frames still buffered in their
> rendering pipeline. Previously, all these frames had to be
> explictly freed (or rendered) before the seek/flush would execute.
> 
> The new behavior matches the behavior of all other lavc decoders,
> reducing the amount of special casing required when using the
> mediacodec decoder.
> ---
>  libavcodec/mediacodec.c   |  2 +-
>  libavcodec/mediacodecdec.c| 23 +++
>  libavcodec/mediacodecdec_common.c | 11 ---
>  libavcodec/mediacodecdec_common.h |  4 
>  4 files changed, 36 insertions(+), 4 deletions(-)
> 
> diff --git a/libavcodec/mediacodec.c b/libavcodec/mediacodec.c
> index d492eefe0b..bf1b7477f1 100644
> --- a/libavcodec/mediacodec.c
> +++ b/libavcodec/mediacodec.c
> @@ -91,7 +91,7 @@ int av_mediacodec_release_buffer(AVMediaCodecBuffer 
> *buffer, int render)
>  MediaCodecDecContext *ctx = buffer->ctx;
>  int released = atomic_fetch_add(&buffer->released, 1);
>  
> -if (!released) {
> +if (!released && (ctx->delay_flush || buffer->serial == 
> atomic_load(&ctx->serial))) {
>  return ff_AMediaCodec_releaseOutputBuffer(ctx->codec, buffer->index, 
> render);
>  }
>  
> diff --git a/libavcodec/mediacodecdec.c b/libavcodec/mediacodecdec.c
> index 0fe14846c3..3582a1377d 100644
> --- a/libavcodec/mediacodecdec.c
> +++ b/libavcodec/mediacodecdec.c
> @@ -41,10 +41,14 @@
>  
>  typedef struct MediaCodecH264DecContext {
>  
> +AVClass *avclass;
> +
>  MediaCodecDecContext *ctx;
>  
>  AVPacket buffered_pkt;
>  
> +int delay_flush;
> +
>  } MediaCodecH264DecContext;
>  
>  static av_cold int mediacodec_decode_close(AVCodecContext *avctx)
> @@ -366,6 +370,8 @@ static av_cold int mediacodec_decode_init(AVCodecContext 
> *avctx)
>  goto done;
>  }
>  
> +s->ctx->delay_flush = s->delay_flush;
> +
>  if ((ret = ff_mediacodec_dec_init(avctx, s->ctx, codec_mime, format)) < 
> 0) {
>  s->ctx = NULL;
>  goto done;
> @@ -485,7 +491,24 @@ static const AVCodecHWConfigInternal 
> *mediacodec_hw_configs[] = {
>  NULL
>  };
>  
> +#define OFFSET(x) offsetof(MediaCodecH264DecContext, x)
> +#define VD AV_OPT_FLAG_VIDEO_PARAM | AV_OPT_FLAG_DECODING_PARAM
> +static const AVOption ff_mediacodec_vdec_options[] = {
> +{ "delay_flush", "Delay flush until hw output buffers are returned to 
> the decoder",
> + OFFSET(delay_flush), AV_OPT_TYPE_BOOL, {.i64 = 0}, 0, 
> 1, VD },
> +{ NULL }
> +};
> +
> +#define DECLARE_MEDIACODEC_VCLASS(short_name)   \
> +static const AVClass ff_##short_name##_mediacodec_dec_class = { \
> +.class_name = #short_name "_mediacodec",\
> +.item_name  = av_default_item_name, \
> +.option = ff_mediacodec_vdec_options,   \
> +.version= LIBAVUTIL_VERSION_INT,\
> +};
> +
>  #define DECLARE_MEDIACODEC_VDEC(short_name, full_name, codec_id, bsf)
>   \
> +DECLARE_MEDIACODEC_VCLASS(short_name)
>   \
>  AVCodec ff_##short_name##_mediacodec_decoder = { 
>   \
>  .name   = #short_name "_mediacodec", 
>   \
>  .long_name  = NULL_IF_CONFIG_SMALL(full_name " Android MediaCodec 
> decoder"),   \

The priv_class assignment is missing:

+.priv_class = &ff_##short_name##_mediacodec_dec_class, \

You will also need some kind of bump in the libavcodec library as well as
an APIChanges entry.

Other than that the patch looks good to me.

Thanks,

[...]

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

[FFmpeg-devel] [PATCH 0/7] Hardening FFV1

2018-03-07 Thread Jerome Martinez

A bunch of independent patches related to FFV1 encoder and decoder, 
fixing some issues found during development of FFV1 regression tests 
(plan is to use a part of these regression tests in FATE).


Some of the patches prevent FFmpeg to create buggy files, without fixing 
the issue.
My point of view is that I would prefer to have FATE tests before trying 
to fix these issues, in order to avoid the risk of injecting bugs when 
patching the actual issue, to be debated. Anyway, these hotfix patches 
could be discarded without preventing other patches to be merged.


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

[FFmpeg-devel] [PATCH 1/7] avcodec/ffv1dec: add missing error messages when a frame is invalid

2018-03-07 Thread Jerome Martinez


A buggy file (before the patch preventing such issue is applied):
ffmpeg -y -f lavfi -i mandelbrot=s=31x31 -vframes 1 -c ffv1 -slices 961 
a.mkv


Then with:
ffmpeg -y -f lavfi -i mandelbrot=s=31x31 -vframes 1 source.jpg
ffmpeg -y -i a.mkv a.jpg

There is no error message despite the fact the stream was not correctly 
decoded (a.jpg is not like source.jpg), but user is not informed that 
the decoding was not good.


This patch adds error message to the output when relevant.


From 04f7275bdefe56ca2ff5d175de6e392f60c31bc3 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?J=C3=A9r=C3=B4me=20Martinez?= 
Date: Wed, 7 Mar 2018 10:36:36 +0100
Subject: [PATCH 1/7] avcodec/ffv1dec: add missing error messages when a frame
 is invalid

---
 libavcodec/ffv1dec.c | 13 ++---
 1 file changed, 10 insertions(+), 3 deletions(-)

diff --git a/libavcodec/ffv1dec.c b/libavcodec/ffv1dec.c
index 3d2ee2569f..94bd60ad2b 100644
--- a/libavcodec/ffv1dec.c
+++ b/libavcodec/ffv1dec.c
@@ -296,6 +296,7 @@ static int decode_slice(AVCodecContext *c, void *arg)
 if (decode_slice_header(f, fs) < 0) {
 fs->slice_x = fs->slice_y = fs->slice_height = fs->slice_width = 0;
 fs->slice_damaged = 1;
+av_log(f->avctx, AV_LOG_ERROR, "Invalid content found while 
parsing slice header\n");
 return AVERROR_INVALIDDATA;
 }
 }
@@ -432,8 +433,10 @@ static int read_extra_header(FFV1Context *f)
 if (f->version > 2) {
 c->bytestream_end -= 4;
 f->micro_version = get_symbol(c, state, 0);
-if (f->micro_version < 0)
+if (f->micro_version < 0) {
+av_log(f->avctx, AV_LOG_ERROR, "Invalid micro_version in global 
header\n");
 return AVERROR_INVALIDDATA;
+}
 }
 f->ac = get_symbol(c, state, 0);
 
@@ -759,11 +762,15 @@ static int read_header(FFV1Context *f)
 fs->slice_width  = fs->slice_width  / f->num_h_slices - 
fs->slice_x;
 fs->slice_height = fs->slice_height / f->num_v_slices - 
fs->slice_y;
 if ((unsigned)fs->slice_width  > f->width ||
-(unsigned)fs->slice_height > f->height)
+(unsigned)fs->slice_height > f->height) {
+av_log(f->avctx, AV_LOG_ERROR, "Invalid content found while 
parsing header\n");
 return AVERROR_INVALIDDATA;
+}
 if (   (unsigned)fs->slice_x + (uint64_t)fs->slice_width  > 
f->width
-|| (unsigned)fs->slice_y + (uint64_t)fs->slice_height > 
f->height)
+|| (unsigned)fs->slice_y + (uint64_t)fs->slice_height > 
f->height) {
+av_log(f->avctx, AV_LOG_ERROR, "Invalid content found while 
parsing header\n");
 return AVERROR_INVALIDDATA;
+}
 }
 
 for (i = 0; i < f->plane_count; i++) {
-- 
2.13.3.windows.1

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

[FFmpeg-devel] [PATCH 2/7] avcodec/ffv1enc: add information message when version is changed by the encoder

2018-03-07 Thread Jerome Martinez

There is a message when coder type is forced to a value not chosen by 
user, but no message when version is forced to a value not chosen by user.
This patch adds such message for more coherency in the messages, and the 
user is informed that the command is not fully respected.


ffmpeg f lavfi -i mandelbrot=s=1920x1080 -vf format=gbrp9 -vframes 1 -c 
ffv1 -level 0 -coder 0 a.mkv


Before:
[ffv1 @ 02492CD69B40] bits_per_raw_sample > 8, forcing range coder

After:
[ffv1 @ 01A6E404A780] bits_per_raw_sample > 8, forcing version 1
[ffv1 @ 01A6E404A780] bits_per_raw_sample > 8, forcing range coder

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

[FFmpeg-devel] [PATCH 3/7] avcodec/ffv1enc: prevent encoder to create buggy streams with small frame sizes

2018-03-07 Thread Jerome Martinez

When there is 1 pixel per slice for the first half of slices, the 
encoder creates buggy slices.


Example:
ffmpeg -f lavfi -i mandelbrot=s=8x8 -vf format=yuv444p -t 1 -c ffv1 
-coder 1 -context 0 -g 1 -level 3 -slices 64 -slicecrc 1 a.mkv
ffmpeg -f lavfi -i mandelbrot=s=9x9 -vf format=yuv444p -t 1 -c ffv1 
-coder 1 -context 0 -g 1 -level 3 -slices 64 -slicecrc 1 a.mkv
ffmpeg -f lavfi -i mandelbrot=s=10x10 -vf format=yuv444p -t 1 -c ffv1 
-coder 1 -context 0 -g 1 -level 3 -slices 64 -slicecrc 1 a.mkv
ffmpeg -f lavfi -i mandelbrot=s=11x11 -vf format=yuv444p -t 1 -c ffv1 
-coder 1 -context 0 -g 1 -level 3 -slices 64 -slicecrc 1 a.mkv
ffmpeg -f lavfi -i mandelbrot=s=12x12 -vf format=yuv444p -t 1 -c ffv1 
-coder 1 -context 0 -g 1 -level 3 -slices 64 -slicecrc 1 a.mkv

then for each file:
ffmpeg -i a.mkv
[ffv1 @ 01977d8ee240] bytestream end mismatching by -1
etc

This patch is an hotfix for preventing the encoder to create such stream.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH 3/7] avcodec/ffv1enc: prevent encoder to create buggy streams with small frame sizes

2018-03-07 Thread Jerome Martinez

When there is 1 pixel per slice for the first half of slices, the 
encoder creates buggy slices.


Example:
ffmpeg -f lavfi -i mandelbrot=s=8x8 -vf format=yuv444p -t 1 -c ffv1 
-coder 1 -context 0 -g 1 -level 3 -slices 64 -slicecrc 1 a.mkv
ffmpeg -f lavfi -i mandelbrot=s=9x9 -vf format=yuv444p -t 1 -c ffv1 
-coder 1 -context 0 -g 1 -level 3 -slices 64 -slicecrc 1 a.mkv
ffmpeg -f lavfi -i mandelbrot=s=10x10 -vf format=yuv444p -t 1 -c ffv1 
-coder 1 -context 0 -g 1 -level 3 -slices 64 -slicecrc 1 a.mkv
ffmpeg -f lavfi -i mandelbrot=s=11x11 -vf format=yuv444p -t 1 -c ffv1 
-coder 1 -context 0 -g 1 -level 3 -slices 64 -slicecrc 1 a.mkv
ffmpeg -f lavfi -i mandelbrot=s=12x12 -vf format=yuv444p -t 1 -c ffv1 
-coder 1 -context 0 -g 1 -level 3 -slices 64 -slicecrc 1 a.mkv

then for each file:
ffmpeg -i a.mkv
[ffv1 @ 01977d8ee240] bytestream end mismatching by -1
etc

This patch is an hotfix for preventing the encoder to create such stream.
From 1c78e038a9fb826c70d7b609430a92d5e98ce1de Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?J=C3=A9r=C3=B4me=20Martinez?= 
Date: Wed, 7 Mar 2018 10:40:05 +0100
Subject: [PATCH 3/7] avcodec/ffv1enc: prevent encoder to create buggy streams
 with small frame sizes

The first half of slices must have more than 1 pixel else encoder does not 
correctly handle slice_x and/or slice_y
---
 libavcodec/ffv1enc.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/libavcodec/ffv1enc.c b/libavcodec/ffv1enc.c
index ac8b715b74..51aa8c2898 100644
--- a/libavcodec/ffv1enc.c
+++ b/libavcodec/ffv1enc.c
@@ -864,6 +864,10 @@ FF_ENABLE_DEPRECATION_WARNINGS
 int plane_count = 1 + 2*s->chroma_planes + s->transparency;
 int max_h_slices = AV_CEIL_RSHIFT(avctx->width , s->chroma_h_shift);
 int max_v_slices = AV_CEIL_RSHIFT(avctx->height, s->chroma_v_shift);
+while (max_h_slices && ((float)(avctx->width >> (s->chroma_h_shift))) 
/ max_h_slices <= 1.5) // Hotfix: the first half of slices must have more than 
1 pixel else encoder does not correctly handle slice_x
+max_h_slices--;
+while (max_v_slices && ((float)(avctx->height >> (s->chroma_v_shift))) 
/ max_v_slices <= 1.5) // Hotfix: the first half of slices must have more than 
1 pixel else encoder does not correctly handle slice_y
+max_v_slices--;
 s->num_v_slices = (avctx->width > 352 || avctx->height > 288 || 
!avctx->slices) ? 2 : 1;
 
 s->num_v_slices = FFMIN(s->num_v_slices, max_v_slices);
-- 
2.13.3.windows.1

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

[FFmpeg-devel] [PATCH 2/7] avcodec/ffv1enc: add information message when version is changed by the encoder

2018-03-07 Thread Jerome Martinez

There is a message when coder type is forced to a value not chosen by 
user, but no message when version is forced to a value not chosen by user.
This patch adds such message for more coherency in the messages, and the 
user is informed that the command is not fully respected.


ffmpeg f lavfi -i mandelbrot=s=1920x1080 -vf format=gbrp9 -vframes 1 -c 
ffv1 -level 0 -coder 0 a.mkv


Before:
[ffv1 @ 02492CD69B40] bits_per_raw_sample > 8, forcing range coder

After:
[ffv1 @ 01A6E404A780] bits_per_raw_sample > 8, forcing version 1
[ffv1 @ 01A6E404A780] bits_per_raw_sample > 8, forcing range coder


From 49db6049fa50976683fc651cf180ab8c7428225e Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?J=C3=A9r=C3=B4me=20Martinez?= 
Date: Wed, 7 Mar 2018 10:37:46 +0100
Subject: [PATCH 2/7] avcodec/ffv1enc: add information message when version is
 changed by the encoder

---
 libavcodec/ffv1enc.c | 8 +++-
 1 file changed, 7 insertions(+), 1 deletion(-)

diff --git a/libavcodec/ffv1enc.c b/libavcodec/ffv1enc.c
index d71d952c6d..ac8b715b74 100644
--- a/libavcodec/ffv1enc.c
+++ b/libavcodec/ffv1enc.c
@@ -509,7 +509,7 @@ static av_cold int encode_init(AVCodecContext *avctx)
 {
 FFV1Context *s = avctx->priv_data;
 const AVPixFmtDescriptor *desc = av_pix_fmt_desc_get(avctx->pix_fmt);
-int i, j, k, m, ret;
+int i, j, k, m, ret, oldversion;
 
 if ((ret = ff_ffv1_common_init(avctx)) < 0)
 return ret;
@@ -534,6 +534,7 @@ static av_cold int encode_init(AVCodecContext *avctx)
 }
 s->version = avctx->level;
 }
+oldversion = s->version;
 
 if (s->ec < 0) {
 s->ec = (s->version >= 3);
@@ -679,6 +680,11 @@ FF_ENABLE_DEPRECATION_WARNINGS
 av_assert0(s->bits_per_raw_sample >= 8);
 
 if (s->bits_per_raw_sample > 8) {
+if (oldversion >= 0 && oldversion != s->version) {
+av_log(avctx, AV_LOG_INFO,
+"bits_per_raw_sample > 8, forcing version 1\n");
+oldversion = s->version;
+}
 if (s->ac == AC_GOLOMB_RICE) {
 av_log(avctx, AV_LOG_INFO,
 "bits_per_raw_sample > 8, forcing range coder\n");
-- 
2.13.3.windows.1

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

[FFmpeg-devel] [PATCH 4/7] avcodec/ffv1enc: prevent encoder to create non-lossless streams with some chroma subsamplings

2018-03-07 Thread Jerome Martinez

When all luma samples for a chroma sample are not in the same slice, 
resulting bitstream is valid but the compression then decompression is 
not lossless.


ffmpeg -y -f lavfi -i mandelbrot=s=1925x1080 -vf format=yuv411p -vframes 
1 -c ffv1 -slices 16 a.mkv
ffmpeg -y -f lavfi -i mandelbrot=s=1925x1080 -vf format=yuv411p -vframes 
1 -f framemd5 source.md5

ffmpeg -y -i a.mkv -vframes 1 -f framemd5 a.mkv.md5
Framemd5 are not same.

For e.g. 4:1:1 and 4 horizontal slices (-slices 16), we have
1920-1921-1922-1923-1924 1926-1927-1928 1931-1932 1936 OK
1925 1929-1930 1933-1934-1935 NOK

This patch is an hotfix for preventing the encoder to create such stream.
Note that it blocks more than needed (e.g, all the listed widths above 
except multiples of 16 are blocked) as I didn't find the exact pattern 
that makes the conversion NOK, the hotfix is definitely not nice and I 
would welcome another proposal.


From 954817ec1f78396d04383a1ea19aec7739fdd7fb Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?J=C3=A9r=C3=B4me=20Martinez?= 
Date: Wed, 7 Mar 2018 10:41:10 +0100
Subject: [PATCH 4/7] avcodec/ffv1enc: prevent encoder to create non-lossless
 streams with some chroma subsamplings

Some combinations having chroma subsampling are not lossless with current code
---
 libavcodec/ffv1enc.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/libavcodec/ffv1enc.c b/libavcodec/ffv1enc.c
index 51aa8c2898..16987117d8 100644
--- a/libavcodec/ffv1enc.c
+++ b/libavcodec/ffv1enc.c
@@ -876,6 +876,10 @@ FF_ENABLE_DEPRECATION_WARNINGS
 for (s->num_h_slices = s->num_v_slices; s->num_h_slices < 
2*s->num_v_slices; s->num_h_slices++) {
 int maxw = (avctx->width  + s->num_h_slices - 1) / 
s->num_h_slices;
 int maxh = (avctx->height + s->num_v_slices - 1) / 
s->num_v_slices;
+if (s->chroma_h_shift && (avctx->width % (s->num_h_slices << 
s->chroma_h_shift))) // Hotfix: some combinations having chroma subsampling are 
not lossless with current code, e.g. width of 1919 with 422 subsampling and 2 
horizontal slices, or width of 1921 with 422 subsampling and 2 horizontal slices
+continue;
+if (s->chroma_v_shift && (avctx->height % (s->num_v_slices << 
s->chroma_v_shift))) // Hotfix: some combinations having chroma subsampling are 
not lossless with current code, e.g. width of 1919 with 422 subsampling and 2 
horizontal slices, or width of 1921 with 422 subsampling and 2 horizontal slices
+continue;
 if (s->num_h_slices > max_h_slices || s->num_v_slices > 
max_v_slices)
 continue;
 if (maxw * maxh * (int64_t)(s->bits_per_raw_sample+1) * 
plane_count > 8<<24)
-- 
2.13.3.windows.1

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

[FFmpeg-devel] [PATCH 5/7] avcodec/ffv1enc: support of 1024 slices

2018-03-07 Thread Jerome Martinez

FFV1 decoder supports up to 1024 slices but FFV1 encoder permits only 
961 (31x31) slices.

This patch permits to create 1024 (32x32) slices.
From 494115e12981a9c54bf04b63a13ef50364349de2 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?J=C3=A9r=C3=B4me=20Martinez?= 
Date: Wed, 7 Mar 2018 10:49:24 +0100
Subject: [PATCH 5/7] avcodec/ffv1enc: support of 1024 slices

Decoder already accepts 1024 slices but encoder was limited to 961 slices
---
 libavcodec/ffv1enc.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/libavcodec/ffv1enc.c b/libavcodec/ffv1enc.c
index 16987117d8..262821abab 100644
--- a/libavcodec/ffv1enc.c
+++ b/libavcodec/ffv1enc.c
@@ -872,7 +872,7 @@ FF_ENABLE_DEPRECATION_WARNINGS
 
 s->num_v_slices = FFMIN(s->num_v_slices, max_v_slices);
 
-for (; s->num_v_slices < 32; s->num_v_slices++) {
+for (; s->num_v_slices <= 32; s->num_v_slices++) {
 for (s->num_h_slices = s->num_v_slices; s->num_h_slices < 
2*s->num_v_slices; s->num_h_slices++) {
 int maxw = (avctx->width  + s->num_h_slices - 1) / 
s->num_h_slices;
 int maxh = (avctx->height + s->num_v_slices - 1) / 
s->num_v_slices;
-- 
2.13.3.windows.1

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

[FFmpeg-devel] [PATCH 6/7] avcodec/ffv1: support of more pix_fmt

2018-03-07 Thread Jerome Martinez

With some sources having specific pix_fmt (9/10/12/14 bit), the source 
is padded to 16-bit when the pix_fmt is not supported natively by the 
FFV1 encoder.
Nothing is lost ("cutting" to the source bitdepth permits to retrieve 
the exact source), but the source bitdepth is not indicated so it is not 
possible to retrieve the exact source without having the source bitdepth 
by another channel. It also makes FATE tests (framemd5 comparison) a bit 
more complicated (bitdepth reduction).


This patch adds native support of the pix_fmt being padded, so there is 
no more padding and the FFV1 bitdepth is same as source bitdepth.
From 8efae7dd23ac30a84161e3d5a46b38350703a7a8 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?J=C3=A9r=C3=B4me=20Martinez?= 
Date: Wed, 7 Mar 2018 11:19:03 +0100
Subject: [PATCH 6/7] avcodec/ffv1: support of more pix_fmt

Without direct support of such pix_fmt, content is padded to 16-bit
and it is not possible to know that the source file was with a smaller bit depth
so framemd5 is different
---
 libavcodec/ffv1dec.c | 14 +-
 libavcodec/ffv1enc.c | 15 +--
 2 files changed, 26 insertions(+), 3 deletions(-)

diff --git a/libavcodec/ffv1dec.c b/libavcodec/ffv1dec.c
index 94bd60ad2b..9f26d48b03 100644
--- a/libavcodec/ffv1dec.c
+++ b/libavcodec/ffv1dec.c
@@ -594,7 +594,10 @@ static int read_header(FFV1Context *f)
 if (!f->transparency && !f->chroma_planes) {
 if (f->avctx->bits_per_raw_sample <= 8)
 f->avctx->pix_fmt = AV_PIX_FMT_GRAY8;
-else if (f->avctx->bits_per_raw_sample == 10) {
+else if (f->avctx->bits_per_raw_sample == 9) {
+f->packed_at_lsb = 1;
+f->avctx->pix_fmt = AV_PIX_FMT_GRAY9;
+} else if (f->avctx->bits_per_raw_sample == 10) {
 f->packed_at_lsb = 1;
 f->avctx->pix_fmt = AV_PIX_FMT_GRAY10;
 } else if (f->avctx->bits_per_raw_sample == 12) {
@@ -645,6 +648,7 @@ static int read_header(FFV1Context *f)
 f->packed_at_lsb = 1;
 switch(16 * f->chroma_h_shift + f->chroma_v_shift) {
 case 0x00: f->avctx->pix_fmt = AV_PIX_FMT_YUV444P10; break;
+case 0x01: f->avctx->pix_fmt = AV_PIX_FMT_YUV440P10; break;
 case 0x10: f->avctx->pix_fmt = AV_PIX_FMT_YUV422P10; break;
 case 0x11: f->avctx->pix_fmt = AV_PIX_FMT_YUV420P10; break;
 }
@@ -659,9 +663,17 @@ static int read_header(FFV1Context *f)
 f->packed_at_lsb = 1;
 switch(16 * f->chroma_h_shift + f->chroma_v_shift) {
 case 0x00: f->avctx->pix_fmt = AV_PIX_FMT_YUV444P12; break;
+case 0x01: f->avctx->pix_fmt = AV_PIX_FMT_YUV440P12; break;
 case 0x10: f->avctx->pix_fmt = AV_PIX_FMT_YUV422P12; break;
 case 0x11: f->avctx->pix_fmt = AV_PIX_FMT_YUV420P12; break;
 }
+} else if (f->avctx->bits_per_raw_sample == 14 && !f->transparency) {
+f->packed_at_lsb = 1;
+switch(16 * f->chroma_h_shift + f->chroma_v_shift) {
+case 0x00: f->avctx->pix_fmt = AV_PIX_FMT_YUV444P14; break;
+case 0x10: f->avctx->pix_fmt = AV_PIX_FMT_YUV422P14; break;
+case 0x11: f->avctx->pix_fmt = AV_PIX_FMT_YUV420P14; break;
+}
 } else if (f->avctx->bits_per_raw_sample == 16 && !f->transparency){
 f->packed_at_lsb = 1;
 switch(16 * f->chroma_h_shift + f->chroma_v_shift) {
diff --git a/libavcodec/ffv1enc.c b/libavcodec/ffv1enc.c
index 262821abab..f0f9eaba79 100644
--- a/libavcodec/ffv1enc.c
+++ b/libavcodec/ffv1enc.c
@@ -559,6 +559,7 @@ FF_ENABLE_DEPRECATION_WARNINGS
 
 s->plane_count = 3;
 switch(avctx->pix_fmt) {
+case AV_PIX_FMT_GRAY9:
 case AV_PIX_FMT_YUV444P9:
 case AV_PIX_FMT_YUV422P9:
 case AV_PIX_FMT_YUV420P9:
@@ -569,6 +570,7 @@ FF_ENABLE_DEPRECATION_WARNINGS
 s->bits_per_raw_sample = 9;
 case AV_PIX_FMT_GRAY10:
 case AV_PIX_FMT_YUV444P10:
+case AV_PIX_FMT_YUV440P10:
 case AV_PIX_FMT_YUV420P10:
 case AV_PIX_FMT_YUV422P10:
 case AV_PIX_FMT_YUVA444P10:
@@ -578,11 +580,17 @@ FF_ENABLE_DEPRECATION_WARNINGS
 s->bits_per_raw_sample = 10;
 case AV_PIX_FMT_GRAY12:
 case AV_PIX_FMT_YUV444P12:
+case AV_PIX_FMT_YUV440P12:
 case AV_PIX_FMT_YUV420P12:
 case AV_PIX_FMT_YUV422P12:
-s->packed_at_lsb = 1;
 if (!avctx->bits_per_raw_sample && !s->bits_per_raw_sample)
 s->bits_per_raw_sample = 12;
+case AV_PIX_FMT_YUV444P14:
+case AV_PIX_FMT_YUV420P14:
+case AV_PIX_FMT_YUV422P14:
+if (!avctx->bits_per_raw_sample && !s->bits_per_raw_sample)
+s->bits_per_raw_sample = 14;
+s->packed_at_lsb = 1;
 case AV_PIX_FMT_GRAY16:
 case AV_PIX_FMT_YUV444P16:
 case AV_PIX_FMT_YUV422P16:
@@ -1343,10 +1351,13 @@ AVCodec ff_ffv1_encoder = {
 AV_PIX_FMT_GRAY16,AV_PIX_FMT_GRAY8, AV_PIX_FMT_GBRP9,

Re: [FFmpeg-devel] [PATCH]lavfi/drawutils: Do not claim to support P016

2018-03-07 Thread Michael Niedermayer

On Wed, Mar 07, 2018 at 12:41:13AM +0100, Carl Eugen Hoyos wrote:
> Hi!
> 
> Attached patch fixes fate on big-endian, I failed to fix drawutils for P016.
> 
> Please comment (or fix the underlying issue), Carl Eugen

>  libavfilter/drawutils.c   |2 +-
>  tests/ref/fate/filter-pixfmts-pad |1 -
>  2 files changed, 1 insertion(+), 2 deletions(-)
> cd8e8de7521d6f2913de7368ba028308f1070e0a  
> 0001-lavfi-drawutils-Do-not-claim-to-support-P016.patch
> From 5254acb48a67adc10e2651c6be449e11ecd8cb74 Mon Sep 17 00:00:00 2001
> From: Carl Eugen Hoyos 
> Date: Wed, 7 Mar 2018 00:36:21 +0100
> Subject: [PATCH] lavfi/drawutils: Do not claim to support P016.
> 
> Fixes fate on big-endian.
> ---
>  libavfilter/drawutils.c   |2 +-
>  tests/ref/fate/filter-pixfmts-pad |1 -
>  2 files changed, 1 insertion(+), 2 deletions(-)

LGTM unless someone is activly working on adding support for this

thx

[...]

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

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


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

[FFmpeg-devel] [PATCH 7/7] avcodec/ffv1enc: remove warning about transparency

2018-03-07 Thread Jerome Martinez

The message about the need of a recent FFmpeg version when encoding 
alpha plane is 5+ year old, not really relevant anymore.


This patch removes the message.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH 7/7] avcodec/ffv1enc: remove warning about transparency

2018-03-07 Thread Jerome Martinez

The message about the need of a recent FFmpeg version when encoding 
alpha plane is 5+ year old, not really relevant anymore.


This patch removes the message.
From 8e3bbad708b5a3a24920133c5bef0b7399375393 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?J=C3=A9r=C3=B4me=20Martinez?= 
Date: Wed, 7 Mar 2018 13:26:36 +0100
Subject: [PATCH 7/7] avcodec/ffv1enc: remove warning about transparency

---
 libavcodec/ffv1enc.c | 3 ---
 1 file changed, 3 deletions(-)

diff --git a/libavcodec/ffv1enc.c b/libavcodec/ffv1enc.c
index f0f9eaba79..c6e11a3f55 100644
--- a/libavcodec/ffv1enc.c
+++ b/libavcodec/ffv1enc.c
@@ -699,9 +699,6 @@ FF_ENABLE_DEPRECATION_WARNINGS
 s->ac = AC_RANGE_CUSTOM_TAB;
 }
 }
-if (s->transparency) {
-av_log(avctx, AV_LOG_WARNING, "Storing alpha plane, this will require 
a recent FFV1 decoder to playback!\n");
-}
 #if FF_API_PRIVATE_OPT
 FF_DISABLE_DEPRECATION_WARNINGS
 if (avctx->context_model)
-- 
2.13.3.windows.1

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

Re: [FFmpeg-devel] [PATCH] avcodec/mpeg12dec: ignore scte20 captions when a53 data is also present

2018-03-07 Thread Michael Niedermayer

On Tue, Mar 06, 2018 at 02:25:12PM -0800, Aman Gupta wrote:
> From: Aman Gupta 
> 
> Some streams include both a53 and scte20 data. Before this commit,
> the scte20 data would be used instead of the a53 data.
> 
> See https://s3.amazonaws.com/tmm1/ccaptions/scte20plusa53.ts,
> which produced garbage captions since 3f1a540204a8c187f77b3805d.
> ---
>  libavcodec/mpeg12dec.c | 5 -
>  1 file changed, 4 insertions(+), 1 deletion(-)

why does the combination produce garbage ?
why should not both be exported or it be user selectable?

also turning one off for ever seems problematic for concatenated
sequences. not every sequence would need to contain both i guess

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

The greatest way to live with honor in this world is to be what we pretend
to be. -- Socrates

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

Re: [FFmpeg-devel] [PATCH] avcodec/noise_bsf: Add keyframes option.

2018-03-07 Thread Michael Niedermayer

On Tue, Mar 06, 2018 at 12:47:15PM -0800, Josh Allmann wrote:
> ---
>  doc/bitstream_filters.texi |  5 +
>  libavcodec/noise_bsf.c | 12 
>  libavcodec/version.h   |  2 +-
>  3 files changed, 18 insertions(+), 1 deletion(-)
> 
> diff --git a/doc/bitstream_filters.texi b/doc/bitstream_filters.texi
> index cfd81fa12d..a9f17f32ec 100644
> --- a/doc/bitstream_filters.texi
> +++ b/doc/bitstream_filters.texi
> @@ -399,6 +399,11 @@ every byte is modified.
>  A numeral string, whose value is related to how often packets will be 
> dropped.
>  Therefore, values below or equal to 0 are forbidden, and the lower the more
>  frequent packets will be dropped, with 1 meaning every packet is dropped.
> +@item keyframes
> +A numeral string, whose value indicates the number of keyframe packets that
> +will be dropped from the beginning of the stream. This option will not add
> +noise to the source data. If used with stream copy, then -copyinkf should
> +be added to the output options as well.
>  @end table
>  
>  The following example applies the modification to every byte but does not 
> drop
> diff --git a/libavcodec/noise_bsf.c b/libavcodec/noise_bsf.c
> index 84b94032ad..363ea4fc71 100644
> --- a/libavcodec/noise_bsf.c
> +++ b/libavcodec/noise_bsf.c
> @@ -32,6 +32,7 @@ typedef struct NoiseContext {
>  const AVClass *class;
>  int amount;
>  int dropamount;
> +int keyframes;
>  unsigned int state;
>  } NoiseContext;
>  
> @@ -49,6 +50,13 @@ static int noise(AVBSFContext *ctx, AVPacket *out)
>  if (ret < 0)
>  return ret;
>  
> +if (s->keyframes > 0 && in->flags & AV_PKT_FLAG_KEY) {
> +  s->keyframes--;
> +  if (!s->keyframes) s->keyframes = -1;
> +  av_packet_free(&in);
> +  return AVERROR(EAGAIN);
> +}

I think keyframe should work like dropamount, that is randomly.

a non random droping could be added, maybe by the user specifying in
a list what to drop.
That would be more powerfull and flexible but probably not much harder
to implement. also keeping keyframes and dropamount behave the same
is more consistent

also the indention depth mismatches the surrounding code


[...]

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Let us carefully observe those good qualities wherein our enemies excel us
and endeavor to excel them, by avoiding what is faulty, and imitating what
is excellent in them. -- Plutarch


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

Re: [FFmpeg-devel] [PATCH] avcodec/aacdec: log configuration change details

2018-03-07 Thread Michael Niedermayer

On Tue, Mar 06, 2018 at 12:45:33PM -0800, Aman Gupta wrote:
> From: Aman Gupta 
> 
> ---
>  libavcodec/aacdec.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)

LGTM

thx

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

You can kill me, but you cannot change the truth.


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

Re: [FFmpeg-devel] [PATCH] avcodec/mpeg12dec: ignore scte20 captions when a53 data is also present

2018-03-07 Thread Devin Heitmueller

> On Mar 7, 2018, at 12:49 PM, Michael Niedermayer  
> wrote:
> 
> On Tue, Mar 06, 2018 at 02:25:12PM -0800, Aman Gupta wrote:
>> From: Aman Gupta 
>> 
>> Some streams include both a53 and scte20 data. Before this commit,
>> the scte20 data would be used instead of the a53 data.
>> 
>> See https://s3.amazonaws.com/tmm1/ccaptions/scte20plusa53.ts,
>> which produced garbage captions since 3f1a540204a8c187f77b3805d.
>> ---
>> libavcodec/mpeg12dec.c | 5 -
>> 1 file changed, 4 insertions(+), 1 deletion(-)
> 
> why does the combination produce garbage ?
> why should not both be exported or it be user selectable?

I suspect part of the issue is that the SCTE-20 data gets jammed into the 
a53_caption member.  It may make sense to have it put into it’s own field, so 
that if both are present the encoder can decide which to insert into the final 
stream.  But having both of them putting data into the same field is likely to 
produce indeterministic output.

I’ve got basically the same issue in the decklink input where both EIA-608 and 
EIA-708 VANC can arrive in the same frame, and will need to either implement a 
similar change (i.e. prefer 708 if both are present), or be prepared to add a 
new side_data type for 608 so both can be sent and the downstream can choose 
which to include in the output.

Devin

> also turning one off for ever seems problematic for concatenated
> sequences. not every sequence would need to contain both I guess

It would certainly be good if it were configurable.  I am certain there are 
users who will say “I know the X format is broken and I want to always send 
through the Y format", and that may not correspond to the heuristic implemented 
in the decoder (in this case, to always prefer 708 data over SCTE-20).

Devin

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

Re: [FFmpeg-devel] [PATCH 2/2] avformat/oggdec: Fix metadata memleak on multiple headers

2018-03-07 Thread Matthew Wolenetz

Friendly ping. I'd like to not have to land this in Chromium before upstream
 ffmpeg, but I may need to soon.

On Tue, Mar 6, 2018 at 1:56 PM, Michael Niedermayer 
wrote:

> Fixes: Chromium bug 800123
> Reported-by: Matt Wolenetz 
> Reviewed-by: Matt Wolenetz 
> Signed-off-by: Michael Niedermayer 
> ---
>  libavformat/oggdec.c | 5 -
>  1 file changed, 4 insertions(+), 1 deletion(-)
>
> diff --git a/libavformat/oggdec.c b/libavformat/oggdec.c
> index 38f60653f9..27d16a3e4e 100644
> --- a/libavformat/oggdec.c
> +++ b/libavformat/oggdec.c
> @@ -128,7 +128,10 @@ static int ogg_restore(AVFormatContext *s)
>  ogg->state = ost->next;
>
>  for (i = 0; i < ogg->nstreams; i++) {
> -av_freep(&ogg->streams[i].buf);
> +struct ogg_stream *stream = &ogg->streams[i];
> +av_freep(&stream->buf);
> +av_freep(&stream->new_metadata);
> +
>  if (i >= ost->nstreams || !ost->streams[i].private) {
>  free_stream(s, i);
>  }
> --
> 2.16.2
>
> ___
> 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] avcodec/mpeg12dec: ignore scte20 captions when a53 data is also present

2018-03-07 Thread Aman Gupta

On Wed, Mar 7, 2018 at 9:49 AM Michael Niedermayer 
wrote:

> On Tue, Mar 06, 2018 at 02:25:12PM -0800, Aman Gupta wrote:
> > From: Aman Gupta 
> >
> > Some streams include both a53 and scte20 data. Before this commit,
> > the scte20 data would be used instead of the a53 data.
> >
> > See https://s3.amazonaws.com/tmm1/ccaptions/scte20plusa53.ts,
> > which produced garbage captions since 3f1a540204a8c187f77b3805d.
> > ---
> >  libavcodec/mpeg12dec.c | 5 -
> >  1 file changed, 4 insertions(+), 1 deletion(-)
>
> why does the combination produce garbage ?

In my sample, the scte20 data by itself produces garbage captions. I'm not
sure why.

> why should not both be exported or it be user selectable?

From what I've seen in US broadcast television, scte20 is only used on
standard-def content and everything else uses normal a53.

I'm not sure how we would export both since there's only one type of side
data.

>
> also turning one off for ever seems problematic for concatenated
> sequences. not every sequence would need to contain both i guess

Yea that's theoreticaly possible, but I'd rather wait to add support until
someone actually sees it in the wild.

Before I added scte20 support a few months ago no one even noticed it was
missing. It doesn't seem to have wide spread use.

Aman

>
> [...]
> --
> Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
>
> The greatest way to live with honor in this world is to be what we pretend
> to be. -- Socrates
> ___
> 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 1/2] libavformat/oggparsevorbis: Fix memleak on multiple headers

2018-03-07 Thread Matthew Wolenetz

Friendly ping. I'd like to not have to land this in Chromium before upstream
 ffmpeg, but I may need to soon.

On Tue, Mar 6, 2018 at 1:56 PM, Michael Niedermayer 
wrote:

> Fixes: Chromium bug 800123
> Reported-by: Matt Wolenetz 
> Reviewed-by: Matt Wolenetz 
> Signed-off-by: Michael Niedermayer 
> ---
>  libavformat/oggparsevorbis.c | 4 
>  1 file changed, 4 insertions(+)
>
> diff --git a/libavformat/oggparsevorbis.c b/libavformat/oggparsevorbis.c
> index 29b1ab514e..bcfd246b8d 100644
> --- a/libavformat/oggparsevorbis.c
> +++ b/libavformat/oggparsevorbis.c
> @@ -230,6 +230,10 @@ static int fixup_vorbis_headers(AVFormatContext *as,
>
>  len = priv->len[0] + priv->len[1] + priv->len[2];
>  buf_len = len + len / 255 + 64;
> +
> +if (*buf)
> +return AVERROR_INVALIDDATA;
> +
>  ptr = *buf = av_realloc(NULL, buf_len);
>  if (!ptr)
>  return AVERROR(ENOMEM);
> --
> 2.16.2
>
> ___
> 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 2/2] avformat/mov: Fix integer overflow in mov_get_stsc_samples()

2018-03-07 Thread Matthew Wolenetz

Friendly ping. I'd like to not have to land this in Chromium before upstream
 ffmpeg, but I may need to soon.

On Tue, Mar 6, 2018 at 6:43 AM, Michael Niedermayer 
wrote:

> Fixes: runtime error: signed integer overflow: 5 * -2147483647 cannot be
> represented in type 'int'
> Fixes: Chromium bug 817338
> Reviewed-by: Matt Wolenetz 
> Reported-by: Matt Wolenetz 
> Signed-off-by: Michael Niedermayer 
> ---
>  libavformat/mov.c | 7 ---
>  1 file changed, 4 insertions(+), 3 deletions(-)
>
> diff --git a/libavformat/mov.c b/libavformat/mov.c
> index 95b9cd3f8b..7002a82787 100644
> --- a/libavformat/mov.c
> +++ b/libavformat/mov.c
> @@ -2645,7 +2645,7 @@ static inline int mov_stsc_index_valid(unsigned int
> index, unsigned int count)
>  }
>
>  /* Compute the samples value for the stsc entry at the given index. */
> -static inline int mov_get_stsc_samples(MOVStreamContext *sc, unsigned
> int index)
> +static inline int64_t mov_get_stsc_samples(MOVStreamContext *sc,
> unsigned int index)
>  {
>  int chunk_count;
>
> @@ -2654,7 +2654,7 @@ static inline int mov_get_stsc_samples(MOVStreamContext
> *sc, unsigned int index)
>  else
>  chunk_count = sc->chunk_count - (sc->stsc_data[index].first - 1);
>
> -return sc->stsc_data[index].count * chunk_count;
> +return sc->stsc_data[index].count * (int64_t)chunk_count;
>  }
>
>  static int mov_read_stps(MOVContext *c, AVIOContext *pb, MOVAtom atom)
> @@ -7189,12 +7189,13 @@ static int mov_seek_stream(AVFormatContext *s,
> AVStream *st, int64_t timestamp,
>  /* adjust stsd index */
>  time_sample = 0;
>  for (i = 0; i < sc->stsc_count; i++) {
> -int next = time_sample + mov_get_stsc_samples(sc, i);
> +int64_t next = time_sample + mov_get_stsc_samples(sc, i);
>  if (next > sc->current_sample) {
>  sc->stsc_index = i;
>  sc->stsc_sample = sc->current_sample - time_sample;
>  break;
>  }
> +av_assert0(next == (int)next);
>  time_sample = next;
>  }
>
> --
> 2.16.2
>
> ___
> 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 2/2] avformat/oggdec: Fix metadata memleak on multiple headers

2018-03-07 Thread Paul B Mahol

On 3/7/18, Matthew Wolenetz  wrote:
> Friendly ping. I'd like to not have to land this in Chromium before upstream
>  ffmpeg, but I may need to soon.
>
> On Tue, Mar 6, 2018 at 1:56 PM, Michael Niedermayer 
> wrote:
>
>> Fixes: Chromium bug 800123
>> Reported-by: Matt Wolenetz 
>> Reviewed-by: Matt Wolenetz 
>> Signed-off-by: Michael Niedermayer 
>> ---
>>  libavformat/oggdec.c | 5 -
>>  1 file changed, 4 insertions(+), 1 deletion(-)
>>
>> diff --git a/libavformat/oggdec.c b/libavformat/oggdec.c
>> index 38f60653f9..27d16a3e4e 100644
>> --- a/libavformat/oggdec.c
>> +++ b/libavformat/oggdec.c
>> @@ -128,7 +128,10 @@ static int ogg_restore(AVFormatContext *s)
>>  ogg->state = ost->next;
>>
>>  for (i = 0; i < ogg->nstreams; i++) {
>> -av_freep(&ogg->streams[i].buf);
>> +struct ogg_stream *stream = &ogg->streams[i];
>> +av_freep(&stream->buf);
>> +av_freep(&stream->new_metadata);
>> +
>>  if (i >= ost->nstreams || !ost->streams[i].private) {
>>  free_stream(s, i);
>>  }
>> --
>> 2.16.2
>>
>> ___
>> 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
>

Its already reviewed and should be applied.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] avcodec/mpeg12dec: ignore scte20 captions when a53 data is also present

2018-03-07 Thread Devin Heitmueller


> From what I've seen in US broadcast television, scte20 is only used on
> standard-def content and everything else uses normal a53.

A53 is definitely the more popular standard, and all that is approved for 
distribution in digital over the air broadcasts.  SCTE-20 would only be found 
further up the distribution chain, and perhaps in distribution to some cable 
boxes (although it’s becoming less and less common that it can be decoded since 
most of the content is encrypted nowadays).

> 
> I'm not sure how we would export both since there's only one type of side
> data.

We would have to add a new side data type, and encoders would have to be 
changed to look for both.

>> 
>> also turning one off for ever seems problematic for concatenated
>> sequences. not every sequence would need to contain both I guess

Funny enough, I spent my entire morning debugging some issues with playing 
concatenated TS streams.  If anyone thinks that’s supposed to be working today 
in ffmpeg, there’s a ton of work to be done in that area.

> 
> 
> Yea that's theoreticaly possible, but I'd rather wait to add support until
> someone actually sees it in the wild.
> 
> Before I added scte20 support a few months ago no one even noticed it was
> missing. It doesn't seem to have wide spread use.

It’s not really that nobody noticed - it’s that most people in the broadcast 
space until recently had ruled out the ability to use ffmpeg for production 
because of it’s lack of good support for ancillary data such as captions.  That 
situation is improving of course, but it’s not so much that “no one even 
noticed it was missing”.

If changing the framework to support the extra side data format isn’t viable, 
then certainly prefering A53 over SCTE-20 would be the right way to go.  I 
would make it configurable though.

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

Re: [FFmpeg-devel] [PATCH 2/2] avformat/oggdec: Fix metadata memleak on multiple headers

2018-03-07 Thread Matt Wolenetz

Friendly ping. I'd like to not have to land this in Chromium before
upstream ffmpeg, but I may need to soon.

On Tue, Mar 6, 2018 at 1:56 PM, Michael Niedermayer 
wrote:

> Fixes: Chromium bug 800123
> Reported-by: Matt Wolenetz 
> Reviewed-by: Matt Wolenetz 
> Signed-off-by: Michael Niedermayer 
> ---
>  libavformat/oggdec.c | 5 -
>  1 file changed, 4 insertions(+), 1 deletion(-)
>
> diff --git a/libavformat/oggdec.c b/libavformat/oggdec.c
> index 38f60653f9..27d16a3e4e 100644
> --- a/libavformat/oggdec.c
> +++ b/libavformat/oggdec.c
> @@ -128,7 +128,10 @@ static int ogg_restore(AVFormatContext *s)
>  ogg->state = ost->next;
>
>  for (i = 0; i < ogg->nstreams; i++) {
> -av_freep(&ogg->streams[i].buf);
> +struct ogg_stream *stream = &ogg->streams[i];
> +av_freep(&stream->buf);
> +av_freep(&stream->new_metadata);
> +
>  if (i >= ost->nstreams || !ost->streams[i].private) {
>  free_stream(s, i);
>  }
> --
> 2.16.2
>
> ___
> 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 2/2] avformat/mov: Fix integer overflow in mov_get_stsc_samples()

2018-03-07 Thread Matt Wolenetz

Friendly ping. I'd like to not have to land this in Chromium before
upstream ffmpeg, but I may need to soon.

On Tue, Mar 6, 2018 at 6:43 AM, Michael Niedermayer 
wrote:

> Fixes: runtime error: signed integer overflow: 5 * -2147483647 cannot be
> represented in type 'int'
> Fixes: Chromium bug 817338
> Reviewed-by: Matt Wolenetz 
> Reported-by: Matt Wolenetz 
> Signed-off-by: Michael Niedermayer 
> ---
>  libavformat/mov.c | 7 ---
>  1 file changed, 4 insertions(+), 3 deletions(-)
>
> diff --git a/libavformat/mov.c b/libavformat/mov.c
> index 95b9cd3f8b..7002a82787 100644
> --- a/libavformat/mov.c
> +++ b/libavformat/mov.c
> @@ -2645,7 +2645,7 @@ static inline int mov_stsc_index_valid(unsigned int
> index, unsigned int count)
>  }
>
>  /* Compute the samples value for the stsc entry at the given index. */
> -static inline int mov_get_stsc_samples(MOVStreamContext *sc, unsigned
> int index)
> +static inline int64_t mov_get_stsc_samples(MOVStreamContext *sc,
> unsigned int index)
>  {
>  int chunk_count;
>
> @@ -2654,7 +2654,7 @@ static inline int mov_get_stsc_samples(MOVStreamContext
> *sc, unsigned int index)
>  else
>  chunk_count = sc->chunk_count - (sc->stsc_data[index].first - 1);
>
> -return sc->stsc_data[index].count * chunk_count;
> +return sc->stsc_data[index].count * (int64_t)chunk_count;
>  }
>
>  static int mov_read_stps(MOVContext *c, AVIOContext *pb, MOVAtom atom)
> @@ -7189,12 +7189,13 @@ static int mov_seek_stream(AVFormatContext *s,
> AVStream *st, int64_t timestamp,
>  /* adjust stsd index */
>  time_sample = 0;
>  for (i = 0; i < sc->stsc_count; i++) {
> -int next = time_sample + mov_get_stsc_samples(sc, i);
> +int64_t next = time_sample + mov_get_stsc_samples(sc, i);
>  if (next > sc->current_sample) {
>  sc->stsc_index = i;
>  sc->stsc_sample = sc->current_sample - time_sample;
>  break;
>  }
> +av_assert0(next == (int)next);
>  time_sample = next;
>  }
>
> --
> 2.16.2
>
> ___
> 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 1/2] libavformat/oggparsevorbis: Fix memleak on multiple headers

2018-03-07 Thread Matt Wolenetz

Friendly ping. I'd like to not have to land this in Chromium before
upstream ffmpeg, but I may need to soon.

On Tue, Mar 6, 2018 at 1:56 PM, Michael Niedermayer 
wrote:

> Fixes: Chromium bug 800123
> Reported-by: Matt Wolenetz 
> Reviewed-by: Matt Wolenetz 
> Signed-off-by: Michael Niedermayer 
> ---
>  libavformat/oggparsevorbis.c | 4 
>  1 file changed, 4 insertions(+)
>
> diff --git a/libavformat/oggparsevorbis.c b/libavformat/oggparsevorbis.c
> index 29b1ab514e..bcfd246b8d 100644
> --- a/libavformat/oggparsevorbis.c
> +++ b/libavformat/oggparsevorbis.c
> @@ -230,6 +230,10 @@ static int fixup_vorbis_headers(AVFormatContext *as,
>
>  len = priv->len[0] + priv->len[1] + priv->len[2];
>  buf_len = len + len / 255 + 64;
> +
> +if (*buf)
> +return AVERROR_INVALIDDATA;
> +
>  ptr = *buf = av_realloc(NULL, buf_len);
>  if (!ptr)
>  return AVERROR(ENOMEM);
> --
> 2.16.2
>
> ___
> 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 2/2] avformat/oggdec: Fix metadata memleak on multiple headers

2018-03-07 Thread Michael Niedermayer

On Wed, Mar 07, 2018 at 10:09:58AM -0800, Matt Wolenetz wrote:
> Friendly ping. I'd like to not have to land this in Chromium before
> upstream ffmpeg, but I may need to soon.

will apply

thx

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

The misfortune of the wise is better than the prosperity of the fool.
-- Epicurus


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

Re: [FFmpeg-devel] [PATCH 1/2] libavformat/oggparsevorbis: Fix memleak on multiple headers

2018-03-07 Thread Michael Niedermayer

On Wed, Mar 07, 2018 at 10:10:09AM -0800, Matt Wolenetz wrote:
> Friendly ping. I'd like to not have to land this in Chromium before
> upstream ffmpeg, but I may need to soon.

will apply

thx

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

Those who would give up essential Liberty, to purchase a little
temporary Safety, deserve neither Liberty nor Safety -- Benjamin Franklin


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

Re: [FFmpeg-devel] [PATCH 2/2] avformat/mov: Fix integer overflow in mov_get_stsc_samples()

2018-03-07 Thread Michael Niedermayer

On Wed, Mar 07, 2018 at 10:14:09AM -0800, Matt Wolenetz wrote:
> Friendly ping. I'd like to not have to land this in Chromium before
> upstream ffmpeg, but I may need to soon.

will apply

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

it is not once nor twice but times without number that the same ideas make
their appearance in the world. -- Aristotle


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

Re: [FFmpeg-devel] [PATCH] lavc/vorbisdec: Allow avcodec_open2 to call .close

2018-03-07 Thread Michael Niedermayer

On Mon, Mar 05, 2018 at 04:43:56PM -0800, Matthew Wolenetz wrote:
> 

>  vorbisdec.c |1 +
>  1 file changed, 1 insertion(+)
> ade25a35093139e9555c2a6563e950e31c150697  
> 0001-lavc-vorbisdec-Allow-avcodec_open2-to-call-.close.patch
> From 7471c1d223b860c13793abfd93174d1557f77d6f Mon Sep 17 00:00:00 2001
> From: Matt Wolenetz 
> Date: Mon, 5 Mar 2018 15:59:18 -0800
> Subject: [PATCH] lavc/vorbisdec: Allow avcodec_open2 to call .close
> 
> If there is a decoder initialization failure detected in avcodec_open2
> after .init is called, allow graceful decoder .close to prevent leaking
> vorbis decoder allocations such as those from vorbis_parse_setup_*.
> 
> BUG=772699
> ---
>  libavcodec/vorbisdec.c | 1 +
>  1 file changed, 1 insertion(+)

will apply

thx

[...]

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Dictatorship: All citizens are under surveillance, all their steps and
actions recorded, for the politicians to enforce control.
Democracy: All politicians are under surveillance, all their steps and
actions recorded, for the citizens to enforce control.


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

Re: [FFmpeg-devel] [PATCH 5/9] sbc: implement SBC encoder (low-complexity subband codec)

2018-03-07 Thread Aurelien Jacobs

On Mon, Mar 05, 2018 at 08:46:43PM +, Rostislav Pehlivanov wrote:
> On 3 March 2018 at 16:20, Aurelien Jacobs  wrote:
> 
> > On Thu, Mar 01, 2018 at 10:46:07PM +, Rostislav Pehlivanov wrote:
> > > On 1 March 2018 at 20:45, Aurelien Jacobs  wrote
> > >
> > > >
> > > > So what I propose is to rename sbc_delay to sbc_latency (for example),
> > > > and to add a opus_latecy using AV_OPT_TYPE_DURATION that will deprecate
> > > > opus_delay. I think that's the best way forward if you care about
> > > > consistency.
> > > >
> > >
> > > Yeah, that's great as long as that patch gets accepted.
> >
> > Any other issue left ?
> > If not, I will apply this patch series in a few days.
> >
> 
> Go ahead, everything seems fine now.

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

Re: [FFmpeg-devel] [PATCH] avutil/parseutils: only accept full us duration, do not accept mss duration

2018-03-07 Thread Marton Balint




On Tue, 6 Mar 2018, Marton Balint wrote:


Accepting 'u' suffix for a time specification is neither intuitive nor
consistent (now that we don't accept m). Also there was a bug in the code
accepting an extra 's' even after 'ms'.

Signed-off-by: Marton Balint 
---
libavutil/parseutils.c | 7 +++
1 file changed, 3 insertions(+), 4 deletions(-)


Will apply this soon.

Regards,
Marton



diff --git a/libavutil/parseutils.c b/libavutil/parseutils.c
index 95274f564f..924c49d52c 100644
--- a/libavutil/parseutils.c
+++ b/libavutil/parseutils.c
@@ -693,12 +693,11 @@ int av_parse_time(int64_t *timeval, const char *timestr, 
int duration)
suffix = 1000;
microseconds /= 1000;
q += 2;
-} else if (*q == 'u') {
+} else if (q[0] == 'u' && q[1] == 's') {
suffix = 1;
microseconds = 0;
-q++;
-}
-if (*q == 's')
+q += 2;
+} else if (*q == 's')
q++;
} else {
int is_utc = *q == 'Z' || *q == 'z';
--
2.13.6

___
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] GSoC

2018-03-07 Thread Mark Thompson

On 07/03/18 03:56, Dylan Fernando wrote:
> Thanks, it works now
> 
> Would trying to implement an OpenCL version of vf_fade be a good idea for a
> qualification task, or would it be a better idea to try a different filter?

That sounds like a sensible choice to me, though if you haven't written a 
filter before you might find it helpful to write something simpler first to 
understand how it fits together (for example: vflip, which has trivial 
processing parts but still needs the surrounding boilerplate).

- Mark

(PS: be aware that top-posting is generally frowned upon on this mailing list.)


> On Wed, Mar 7, 2018 at 1:20 AM, Mark Thompson  wrote:
> 
>> On 06/03/18 12:37, Dylan Fernando wrote:
>>> Hi,
>>>
>>> I am Dylan Fernando. I am a Computer Science student from Australia. I am
>>> new to FFmpeg and I wish to apply for GSoC this year.
>>> I would like to do the Video filtering with OpenCL project and I have a
>> few
>>> questions. Would trying to implement an opencl version of vf_fade be a
>> good
>>> idea for the qualification task, or would I be better off using a
>> different
>>> filter?
>>>
>>> Also, I’m having a bit of trouble with running unsharp_opencl. I tried
>>> running:
>>> ffmpeg -hide_banner -nostats -v verbose -init_hw_device opencl=ocl:0.1
>>> -filter_hw_device ocl -i space.mpg -filter_complex unsharp_opencl
>> output.mp4
>>>
>>> but I got the error:
>>> [AVHWDeviceContext @ 0x7fdac050c700] 0.1: Apple / Intel(R) Iris(TM)
>>> Graphics 6100
>>> [mpeg @ 0x7fdac3132600] max_analyze_duration 500 reached at 5005000
>>> microseconds st:0
>>> Input #0, mpeg, from 'space.mpg':
>>>   Duration: 00:00:21.99, start: 0.387500, bitrate: 6108 kb/s
>>> Stream #0:0[0x1e0]: Video: mpeg2video (Main), 1 reference frame,
>>> yuv420p(tv, bt470bg, bottom first, left), 720x480 [SAR 8:9 DAR 4:3], 6000
>>> kb/s, 29.97 fps, 29.97 tbr, 90k tbn, 59.94 tbc
>>> Stream mapping:
>>>   Stream #0:0 (mpeg2video) -> unsharp_opencl
>>>   unsharp_opencl -> Stream #0:0 (mpeg4)
>>> Press [q] to stop, [?] for help
>>> [graph 0 input from stream 0:0 @ 0x7fdac0418800] w:720 h:480
>> pixfmt:yuv420p
>>> tb:1/9 fr:3/1001 sar:8/9 sws_param:flags=2
>>> [auto_scaler_0 @ 0x7fdac05232c0] w:iw h:ih flags:'bilinear' interl:0
>>> [Parsed_unsharp_opencl_0 @ 0x7fdac0715a80] auto-inserting filter
>>> 'auto_scaler_0' between the filter 'graph 0 input from stream 0:0' and
>> the
>>> filter 'Parsed_unsharp_opencl_0'
>>> Impossible to convert between the formats supported by the filter 'graph
>> 0
>>> input from stream 0:0' and the filter 'auto_scaler_0'
>>> Error reinitializing filters!
>>> Failed to inject frame into filter network: Function not implemented
>>> Error while processing the decoded data for stream #0:0
>>> Conversion failed!
>>>
>>> How do I correctly run unsharp_opencl? Should I be running it on a
>>> different video file?
>>
>> It's intended to be used in filter graphs where much of the activity is
>> already happening on the GPU, so the input and output are in the
>> AV_PIX_FMT_OPENCL format which contains GPU-side OpenCL images.
>>
>> If you want to use it standalone then you need hwupload and hwdownload
>> filters to move the frames between the CPU and GPU.  For your example, it
>> should work with:
>>
>> ffmpeg -init_hw_device opencl=ocl:0.1 -filter_hw_device ocl -i space.mpg
>> -filter_complex hwupload,unsharp_opencl,hwdownload output.mp4
>>
>> (There are constraints on what formats can be used and therefore suitable
>> files (or required format conversions), but I believe a normal yuv420p
>> video like this should work in all cases.)
>>
>> - Mark
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] avutil/parseutils: only accept full us duration, do not accept mss duration

2018-03-07 Thread Aurelien Jacobs

On Tue, Mar 06, 2018 at 01:02:48AM +0100, Marton Balint wrote:
> Accepting 'u' suffix for a time specification is neither intuitive nor
> consistent (now that we don't accept m).

The 'm' SI prefix is still accepted in various time options, and the 'u'
prefix is still accepted in those options even after your patch, so you
can't really argue that this patch improve consistency.
(eg. -black_min_duration 5ms is still accepted).
So this will surprise nobody that I don't like this patch.

> Also there was a bug in the code
> accepting an extra 's' even after 'ms'.

Indeed, removing support for the 'm' prefix alone introduced this bug
and that needs to be fixed.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] GSoC

2018-03-07 Thread Danil Iashchenko

*** Hi everybody! I Implemented vf_convolution_opencl filter as qualification 
task for GSoC Video filtering with OpenCL project***

Danil Iashchenko (1):
  add vf_convolution_opencl

 configure   |   1 +
 libavfilter/Makefile|   2 +
 libavfilter/allfilters.c|   1 +
 libavfilter/opencl/convolution.cl   |  80 
 libavfilter/opencl_source.h |   2 +
 libavfilter/vf_convolution_opencl.c | 374 
 6 files changed, 460 insertions(+)
 create mode 100644 libavfilter/opencl/convolution.cl
 create mode 100644 libavfilter/vf_convolution_opencl.c

-- 
2.7.4

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

[FFmpeg-devel] [PATCH] libavfilter/vf_convolution_opencl.c: add opencl version of libavfilter/convolution.c filter

2018-03-07 Thread Danil Iashchenko

---
 configure   |   1 +
 libavfilter/Makefile|   2 +
 libavfilter/allfilters.c|   1 +
 libavfilter/opencl/convolution.cl   |  80 
 libavfilter/opencl_source.h |   2 +
 libavfilter/vf_convolution_opencl.c | 374 
 6 files changed, 460 insertions(+)
 create mode 100644 libavfilter/opencl/convolution.cl
 create mode 100644 libavfilter/vf_convolution_opencl.c

diff --git a/configure b/configure
index 6916b45..7c79e20 100755
--- a/configure
+++ b/configure
@@ -3212,6 +3212,7 @@ bs2b_filter_deps="libbs2b"
 colormatrix_filter_deps="gpl"
 convolve_filter_deps="avcodec"
 convolve_filter_select="fft"
+convolution_opencl_filter_deps="opencl"
 coreimage_filter_deps="coreimage appkit"
 coreimage_filter_extralibs="-framework OpenGL"
 coreimagesrc_filter_deps="coreimage appkit"
diff --git a/libavfilter/Makefile b/libavfilter/Makefile
index 6a60836..f288f8e 100644
--- a/libavfilter/Makefile
+++ b/libavfilter/Makefile
@@ -156,6 +156,8 @@ OBJS-$(CONFIG_COLORLEVELS_FILTER)+= 
vf_colorlevels.o
 OBJS-$(CONFIG_COLORMATRIX_FILTER)+= vf_colormatrix.o
 OBJS-$(CONFIG_COLORSPACE_FILTER) += vf_colorspace.o colorspacedsp.o
 OBJS-$(CONFIG_CONVOLUTION_FILTER)+= vf_convolution.o
+OBJS-$(CONFIG_CONVOLUTION_OPENCL_FILTER) += vf_convolution_opencl.o 
opencl.o \
+opencl/convolution.o
 OBJS-$(CONFIG_CONVOLVE_FILTER)   += vf_convolve.o framesync.o
 OBJS-$(CONFIG_COPY_FILTER)   += vf_copy.o
 OBJS-$(CONFIG_COREIMAGE_FILTER)  += vf_coreimage.o
diff --git a/libavfilter/allfilters.c b/libavfilter/allfilters.c
index 9adb109..f2dc55e 100644
--- a/libavfilter/allfilters.c
+++ b/libavfilter/allfilters.c
@@ -166,6 +166,7 @@ static void register_all(void)
 REGISTER_FILTER(COLORMATRIX,colormatrix,vf);
 REGISTER_FILTER(COLORSPACE, colorspace, vf);
 REGISTER_FILTER(CONVOLUTION,convolution,vf);
+REGISTER_FILTER(CONVOLUTION_OPENCL, convolution_opencl, vf);
 REGISTER_FILTER(CONVOLVE,   convolve,   vf);
 REGISTER_FILTER(COPY,   copy,   vf);
 REGISTER_FILTER(COREIMAGE,  coreimage,  vf);
diff --git a/libavfilter/opencl/convolution.cl 
b/libavfilter/opencl/convolution.cl
new file mode 100644
index 000..5bc5839
--- /dev/null
+++ b/libavfilter/opencl/convolution.cl
@@ -0,0 +1,80 @@
+/*
+ * 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
+ */
+
+__kernel void convolution_global(__write_only image2d_t dst,
+ __read_only  image2d_t src,
+ int coef_matrix_size,
+ __constant float *coef_matrix,
+ float div,
+ float bias)
+{
+const sampler_t sampler = (CLK_NORMALIZED_COORDS_FALSE | 
CLK_FILTER_NEAREST);
+
+const int half_matrix_size = (coef_matrix_size / 2);
+int2 loc = (int2)(get_global_id(0), get_global_id(1));
+float4 convPix = (float4)(0.0f, 0.0f, 0.0f, 0.0f);
+
+for (int conv_i = -half_matrix_size; conv_i <= half_matrix_size; conv_i++) 
{
+for (int conv_j = -half_matrix_size; conv_j <= half_matrix_size; 
conv_j++) {
+float4 px = read_imagef(src, sampler, loc + (int2)(conv_j, 
conv_i));
+convPix += px * 
coef_matrix[(conv_i+1)*coef_matrix_size+(conv_j+1)];
+}
+ }
+ write_imagef(dst, loc, convPix * div + bias);
+}
+
+__kernel void convolution_local(__write_only image2d_t dst,
+ __read_only  image2d_t src,
+ int coef_matrix_size,
+ __constant float *coef_matrix,
+ float div,
+ float bias)
+{
+const sampler_t sampler = (CLK_NORMALIZED_COORDS_FALSE |
+   CLK_ADDRESS_CLAMP_TO_EDGE |
+   CLK_FILTER_NEAREST);
+
+const int block_size = 16;
+
+const int block_x = get_group_id(0) * block_size;
+const int block_y = get_group_id(1) * block_size;
+const int local_x  =  get_local_id(0);
+

Re: [FFmpeg-devel] [PATCH] avutil/parseutils: only accept full us duration, do not accept mss duration

2018-03-07 Thread Marton Balint




On Wed, 7 Mar 2018, Aurelien Jacobs wrote:


On Tue, Mar 06, 2018 at 01:02:48AM +0100, Marton Balint wrote:

Accepting 'u' suffix for a time specification is neither intuitive nor
consistent (now that we don't accept m).


The 'm' SI prefix is still accepted in various time options, and the 'u'
prefix is still accepted in those options even after your patch, so you
can't really argue that this patch improve consistency.
(eg. -black_min_duration 5ms is still accepted).
So this will surprise nobody that I don't like this patch.


This really is a cursed topic, I am not sure I follow, after the patch:

5ms is accepted
5us is accepted
5m is not accepted
5u is not accepted

You really insist on accepting '5u'? If not, then I can push the patch as 
is, right?


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

Re: [FFmpeg-devel] [PATCH] avutil/parseutils: only accept full us duration, do not accept mss duration

2018-03-07 Thread Aurelien Jacobs

On Wed, Mar 07, 2018 at 11:45:03PM +0100, Marton Balint wrote:
> 
> 
> On Wed, 7 Mar 2018, Aurelien Jacobs wrote:
> 
> > On Tue, Mar 06, 2018 at 01:02:48AM +0100, Marton Balint wrote:
> > > Accepting 'u' suffix for a time specification is neither intuitive nor
> > > consistent (now that we don't accept m).
> > 
> > The 'm' SI prefix is still accepted in various time options, and the 'u'
> > prefix is still accepted in those options even after your patch, so you
> > can't really argue that this patch improve consistency.
> > (eg. -black_min_duration 5ms is still accepted).
> > So this will surprise nobody that I don't like this patch.
> 
> This really is a cursed topic, I am not sure I follow, after the patch:
> 
> 5ms is accepted
> 5us is accepted
> 5m is not accepted
> 5u is not accepted

That is only for AV_OPT_TYPE_DURATION.
All other numeric options type still accept SI prefix without unit.
This include various time options such as black_min_duration.
So after the patch, for black_min_duration:

5m is accepted
5u is accepted

> You really insist on accepting '5u'?

I'm not insisting on this (even if I prefer it), but I'm saying that
your patch is *not* removing '5u' support at least for *some* time
options, so it is actually decreasing consistency.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] avutil/parseutils: only accept full us duration, do not accept mss duration

2018-03-07 Thread Hendrik Leppkes

On Thu, Mar 8, 2018 at 12:05 AM, Aurelien Jacobs  wrote:
> On Wed, Mar 07, 2018 at 11:45:03PM +0100, Marton Balint wrote:
>>
>>
>> On Wed, 7 Mar 2018, Aurelien Jacobs wrote:
>>
>> > On Tue, Mar 06, 2018 at 01:02:48AM +0100, Marton Balint wrote:
>> > > Accepting 'u' suffix for a time specification is neither intuitive nor
>> > > consistent (now that we don't accept m).
>> >
>> > The 'm' SI prefix is still accepted in various time options, and the 'u'
>> > prefix is still accepted in those options even after your patch, so you
>> > can't really argue that this patch improve consistency.
>> > (eg. -black_min_duration 5ms is still accepted).
>> > So this will surprise nobody that I don't like this patch.
>>
>> This really is a cursed topic, I am not sure I follow, after the patch:
>>
>> 5ms is accepted
>> 5us is accepted
>> 5m is not accepted
>> 5u is not accepted
>
> That is only for AV_OPT_TYPE_DURATION.
> All other numeric options type still accept SI prefix without unit.
> This include various time options such as black_min_duration.
> So after the patch, for black_min_duration:
>
> 5m is accepted
> 5u is accepted
>

Because those use AV_OPT_TYPE_DOUBLE, a generic type without any
possiblity of a unit.
Ideally those should all be transitioned to AV_OPT_TYPE_DURATION if
they refer to a time for consistency, and not the actual time-type
bend to reflect some generic type. Why would we have the duration type
if its just a copy of the double type anyway?

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

Re: [FFmpeg-devel] [PATCH] avcodec/noise_bsf: Add keyframes option.

2018-03-07 Thread Josh Allmann

On 7 March 2018 at 18:03, Michael Niedermayer  wrote:
> On Tue, Mar 06, 2018 at 12:47:15PM -0800, Josh Allmann wrote:
>> ---
>>  doc/bitstream_filters.texi |  5 +
>>  libavcodec/noise_bsf.c | 12 
>>  libavcodec/version.h   |  2 +-
>>  3 files changed, 18 insertions(+), 1 deletion(-)
>>
>> diff --git a/doc/bitstream_filters.texi b/doc/bitstream_filters.texi
>> index cfd81fa12d..a9f17f32ec 100644
>> --- a/doc/bitstream_filters.texi
>> +++ b/doc/bitstream_filters.texi
>> @@ -399,6 +399,11 @@ every byte is modified.
>>  A numeral string, whose value is related to how often packets will be 
>> dropped.
>>  Therefore, values below or equal to 0 are forbidden, and the lower the more
>>  frequent packets will be dropped, with 1 meaning every packet is dropped.
>> +@item keyframes
>> +A numeral string, whose value indicates the number of keyframe packets that
>> +will be dropped from the beginning of the stream. This option will not add
>> +noise to the source data. If used with stream copy, then -copyinkf should
>> +be added to the output options as well.
>>  @end table
>>
>>  The following example applies the modification to every byte but does not 
>> drop
>> diff --git a/libavcodec/noise_bsf.c b/libavcodec/noise_bsf.c
>> index 84b94032ad..363ea4fc71 100644
>> --- a/libavcodec/noise_bsf.c
>> +++ b/libavcodec/noise_bsf.c
>> @@ -32,6 +32,7 @@ typedef struct NoiseContext {
>>  const AVClass *class;
>>  int amount;
>>  int dropamount;
>> +int keyframes;
>>  unsigned int state;
>>  } NoiseContext;
>>
>> @@ -49,6 +50,13 @@ static int noise(AVBSFContext *ctx, AVPacket *out)
>>  if (ret < 0)
>>  return ret;
>>
>> +if (s->keyframes > 0 && in->flags & AV_PKT_FLAG_KEY) {
>> +  s->keyframes--;
>> +  if (!s->keyframes) s->keyframes = -1;
>> +  av_packet_free(&in);
>> +  return AVERROR(EAGAIN);
>> +}
>

Thanks for the feedback.

> I think keyframe should work like dropamount, that is randomly.
>
> a non random droping could be added, maybe by the user specifying in
> a list what to drop.
> That would be more powerfull and flexible but probably not much harder

Something like this?

noise=keyframes=1,3,5,7

in order to drop the 1st, 3rd, 5th and 7th keyframes?

> also keeping keyframes and dropamount behave the same
> is more consistent
>

Do you mean more consistent with respect to the 'amount' param of added noise,
as opposed to the patch's behavior of skipping noise if the 'keyframes' param is
present?

> also the indention depth mismatches the surrounding code
>
>
> [...]
>
> --
> Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
>
> Let us carefully observe those good qualities wherein our enemies excel us
> and endeavor to excel them, by avoiding what is faulty, and imitating what
> is excellent in them. -- Plutarch
>
> ___
> 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] avcodec/noise_bsf: Add keyframes option.

2018-03-07 Thread Michael Niedermayer

On Wed, Mar 07, 2018 at 11:37:00PM +, Josh Allmann wrote:
> On 7 March 2018 at 18:03, Michael Niedermayer  wrote:
> > On Tue, Mar 06, 2018 at 12:47:15PM -0800, Josh Allmann wrote:
> >> ---
> >>  doc/bitstream_filters.texi |  5 +
> >>  libavcodec/noise_bsf.c | 12 
> >>  libavcodec/version.h   |  2 +-
> >>  3 files changed, 18 insertions(+), 1 deletion(-)
> >>
> >> diff --git a/doc/bitstream_filters.texi b/doc/bitstream_filters.texi
> >> index cfd81fa12d..a9f17f32ec 100644
> >> --- a/doc/bitstream_filters.texi
> >> +++ b/doc/bitstream_filters.texi
> >> @@ -399,6 +399,11 @@ every byte is modified.
> >>  A numeral string, whose value is related to how often packets will be 
> >> dropped.
> >>  Therefore, values below or equal to 0 are forbidden, and the lower the 
> >> more
> >>  frequent packets will be dropped, with 1 meaning every packet is dropped.
> >> +@item keyframes
> >> +A numeral string, whose value indicates the number of keyframe packets 
> >> that
> >> +will be dropped from the beginning of the stream. This option will not add
> >> +noise to the source data. If used with stream copy, then -copyinkf should
> >> +be added to the output options as well.
> >>  @end table
> >>
> >>  The following example applies the modification to every byte but does not 
> >> drop
> >> diff --git a/libavcodec/noise_bsf.c b/libavcodec/noise_bsf.c
> >> index 84b94032ad..363ea4fc71 100644
> >> --- a/libavcodec/noise_bsf.c
> >> +++ b/libavcodec/noise_bsf.c
> >> @@ -32,6 +32,7 @@ typedef struct NoiseContext {
> >>  const AVClass *class;
> >>  int amount;
> >>  int dropamount;
> >> +int keyframes;
> >>  unsigned int state;
> >>  } NoiseContext;
> >>
> >> @@ -49,6 +50,13 @@ static int noise(AVBSFContext *ctx, AVPacket *out)
> >>  if (ret < 0)
> >>  return ret;
> >>
> >> +if (s->keyframes > 0 && in->flags & AV_PKT_FLAG_KEY) {
> >> +  s->keyframes--;
> >> +  if (!s->keyframes) s->keyframes = -1;
> >> +  av_packet_free(&in);
> >> +  return AVERROR(EAGAIN);
> >> +}
> >
> 
> Thanks for the feedback.
> 

> > I think keyframe should work like dropamount, that is randomly.
> >
> > a non random droping could be added, maybe by the user specifying in
> > a list what to drop.
> > That would be more powerfull and flexible but probably not much harder
> 
> Something like this?
> 
> noise=keyframes=1,3,5,7
> 
> in order to drop the 1st, 3rd, 5th and 7th keyframes?

yes something like this


> 
> > also keeping keyframes and dropamount behave the same
> > is more consistent
> >
> 
> Do you mean more consistent with respect to the 'amount' param of added noise,
> as opposed to the patch's behavior of skipping noise if the 'keyframes' param 
> is
> present?

both. 
i meant the param but as you mention the skiping, that doesnt seem expected by a
user either so it likely would be confusing.

thx

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

It is dangerous to be right in matters on which the established authorities
are wrong. -- Voltaire


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

Re: [FFmpeg-devel] [PATCH 1/7] avcodec/ffv1dec: add missing error messages when a frame is invalid

2018-03-07 Thread Michael Niedermayer

On Wed, Mar 07, 2018 at 04:45:20PM +0100, Jerome Martinez wrote:
> A buggy file (before the patch preventing such issue is applied):
> ffmpeg -y -f lavfi -i mandelbrot=s=31x31 -vframes 1 -c ffv1 -slices 961
> a.mkv
> 
> Then with:
> ffmpeg -y -f lavfi -i mandelbrot=s=31x31 -vframes 1 source.jpg
> ffmpeg -y -i a.mkv a.jpg
> 
> There is no error message despite the fact the stream was not correctly
> decoded (a.jpg is not like source.jpg), but user is not informed that the
> decoding was not good.
> 
> This patch adds error message to the output when relevant.
> 
> 

>  ffv1dec.c |   13 ++---
>  1 file changed, 10 insertions(+), 3 deletions(-)
> 3c17506214ec584128ad4e194acee98737f987da  
> 0001-avcodec-ffv1dec-add-missing-error-messages-when-a-fr.patch
> From 04f7275bdefe56ca2ff5d175de6e392f60c31bc3 Mon Sep 17 00:00:00 2001
> From: =?UTF-8?q?J=C3=A9r=C3=B4me=20Martinez?= 
> Date: Wed, 7 Mar 2018 10:36:36 +0100
> Subject: [PATCH 1/7] avcodec/ffv1dec: add missing error messages when a frame
>  is invalid
> 
> ---
>  libavcodec/ffv1dec.c | 13 ++---
>  1 file changed, 10 insertions(+), 3 deletions(-)
> 
> diff --git a/libavcodec/ffv1dec.c b/libavcodec/ffv1dec.c
> index 3d2ee2569f..94bd60ad2b 100644
> --- a/libavcodec/ffv1dec.c
> +++ b/libavcodec/ffv1dec.c
> @@ -296,6 +296,7 @@ static int decode_slice(AVCodecContext *c, void *arg)
>  if (decode_slice_header(f, fs) < 0) {
>  fs->slice_x = fs->slice_y = fs->slice_height = fs->slice_width = 
> 0;
>  fs->slice_damaged = 1;
> +av_log(f->avctx, AV_LOG_ERROR, "Invalid content found while 
> parsing slice header\n");
>  return AVERROR_INVALIDDATA;
>  }
>  }

> @@ -432,8 +433,10 @@ static int read_extra_header(FFV1Context *f)
>  if (f->version > 2) {
>  c->bytestream_end -= 4;
>  f->micro_version = get_symbol(c, state, 0);
> -if (f->micro_version < 0)
> +if (f->micro_version < 0) {
> +av_log(f->avctx, AV_LOG_ERROR, "Invalid micro_version in global 
> header\n");

In the cases where the error is about a scalar value, that value should
be printed in the error message (unless it was alread printed elsewhere)

[...]

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

He who knows, does not speak. He who speaks, does not know. -- Lao Tsu


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

Re: [FFmpeg-devel] [PATCH 2/7] avcodec/ffv1enc: add information message when version is changed by the encoder

2018-03-07 Thread Michael Niedermayer

On Wed, Mar 07, 2018 at 04:49:24PM +0100, Jerome Martinez wrote:
> There is a message when coder type is forced to a value not chosen by user,
> but no message when version is forced to a value not chosen by user.
> This patch adds such message for more coherency in the messages, and the
> user is informed that the command is not fully respected.
> 
> ffmpeg f lavfi -i mandelbrot=s=1920x1080 -vf format=gbrp9 -vframes 1 -c ffv1
> -level 0 -coder 0 a.mkv
> 
> Before:
> [ffv1 @ 02492CD69B40] bits_per_raw_sample > 8, forcing range coder
> 
> After:
> [ffv1 @ 01A6E404A780] bits_per_raw_sample > 8, forcing version 1
> [ffv1 @ 01A6E404A780] bits_per_raw_sample > 8, forcing range coder
> 
> 

>  ffv1enc.c |8 +++-
>  1 file changed, 7 insertions(+), 1 deletion(-)
> cb1df919e21fe4d388df7de9349c5c2c46777862  
> 0002-avcodec-ffv1enc-add-information-message-when-version.patch
> From 49db6049fa50976683fc651cf180ab8c7428225e Mon Sep 17 00:00:00 2001
> From: =?UTF-8?q?J=C3=A9r=C3=B4me=20Martinez?= 
> Date: Wed, 7 Mar 2018 10:37:46 +0100
> Subject: [PATCH 2/7] avcodec/ffv1enc: add information message when version is
>  changed by the encoder
> 
> ---
>  libavcodec/ffv1enc.c | 8 +++-
>  1 file changed, 7 insertions(+), 1 deletion(-)
> 
> diff --git a/libavcodec/ffv1enc.c b/libavcodec/ffv1enc.c
> index d71d952c6d..ac8b715b74 100644
> --- a/libavcodec/ffv1enc.c
> +++ b/libavcodec/ffv1enc.c
> @@ -509,7 +509,7 @@ static av_cold int encode_init(AVCodecContext *avctx)
>  {
>  FFV1Context *s = avctx->priv_data;
>  const AVPixFmtDescriptor *desc = av_pix_fmt_desc_get(avctx->pix_fmt);
> -int i, j, k, m, ret;
> +int i, j, k, m, ret, oldversion;
>  
>  if ((ret = ff_ffv1_common_init(avctx)) < 0)
>  return ret;
> @@ -534,6 +534,7 @@ static av_cold int encode_init(AVCodecContext *avctx)
>  }
>  s->version = avctx->level;
>  }
> +oldversion = s->version;
>  
>  if (s->ec < 0) {
>  s->ec = (s->version >= 3);
> @@ -679,6 +680,11 @@ FF_ENABLE_DEPRECATION_WARNINGS
>  av_assert0(s->bits_per_raw_sample >= 8);
>  
>  if (s->bits_per_raw_sample > 8) {
> +if (oldversion >= 0 && oldversion != s->version) {
> +av_log(avctx, AV_LOG_INFO,
> +"bits_per_raw_sample > 8, forcing version 1\n");
> +oldversion = s->version;
> +}

I dont think this works consistently

The code does not seem to be limited to the case where the user has
specifified a version for example unless i miss something


[...]

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

You can kill me, but you cannot change the truth.


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

Re: [FFmpeg-devel] [PATCH] lavc/vaapi_encode: Don't return error if the underlying driver doesn't support B frame

2018-03-07 Thread Mark Thompson

On 07/03/18 07:10, Xiang, Haihao wrote:
> 
> Hi Mark,
> 
> Do you have any comment to this patch? FFmpeg-vaapi fails to use low power 
> mode
> for H.264 encoding.

I still want to clean up all of this configuration stuff, but I guess it works 
ok for now.  So, I fixed the overlong line and applied with a clearer commit 
message.

Thanks,

- Mark


>> On Wed, 2018-02-07 at 10:31 +0800, Jun Zhao wrote:
>>>
>>> On 2018/2/6 16:17, Haihao Xiang wrote:
 It is possible B frame is not supported for VAEntrypointEncSliceLP and
 the underlying driver has advertised it, so it is better to disable B
 frame instead of returning error for this case

 Signed-off-by: Haihao Xiang 
 ---
  libavcodec/vaapi_encode.c | 7 +++
  1 file changed, 3 insertions(+), 4 deletions(-)

 diff --git a/libavcodec/vaapi_encode.c b/libavcodec/vaapi_encode.c
 index 550ea47991d..e371f5761ee 100644
 --- a/libavcodec/vaapi_encode.c
 +++ b/libavcodec/vaapi_encode.c
 @@ -1094,10 +1094,9 @@ static av_cold int
 vaapi_encode_config_attributes(AVCodecContext *avctx)
  goto fail;
  }
  if (avctx->max_b_frames > 0 && ref_l1 < 1) {
 -av_log(avctx, AV_LOG_ERROR, "B frames are not "
 -   "supported (%#x).\n", attr[i].value);
 -err = AVERROR(EINVAL);
 -goto fail;
 +av_log(avctx, AV_LOG_WARNING, "B frames are not "
 +   "supported (%#x) by the underlying driver.\n",
 attr[i].value);
 +avctx->max_b_frames = 0;
>>>
>>> I think check b frames when enable low_power in vaapi_encode_xxx_init()
>>> more better.
>>
>> VAConfigAttribEncMaxRefFrames is applicable for other CODECs and non-low 
>> power
>> mode. so I think it is better to handle this case in vaapi_encoder.c
>>
>> Thanks
>> Haihao
>>
>>
  }
  }
  break;
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] avutil/parseutils: only accept full us duration, do not accept mss duration

2018-03-07 Thread Aurelien Jacobs

On Thu, Mar 08, 2018 at 12:14:00AM +0100, Hendrik Leppkes wrote:
> On Thu, Mar 8, 2018 at 12:05 AM, Aurelien Jacobs  wrote:
> > On Wed, Mar 07, 2018 at 11:45:03PM +0100, Marton Balint wrote:
> >>
> >>
> >> On Wed, 7 Mar 2018, Aurelien Jacobs wrote:
> >>
> >> > On Tue, Mar 06, 2018 at 01:02:48AM +0100, Marton Balint wrote:
> >> > > Accepting 'u' suffix for a time specification is neither intuitive nor
> >> > > consistent (now that we don't accept m).
> >> >
> >> > The 'm' SI prefix is still accepted in various time options, and the 'u'
> >> > prefix is still accepted in those options even after your patch, so you
> >> > can't really argue that this patch improve consistency.
> >> > (eg. -black_min_duration 5ms is still accepted).
> >> > So this will surprise nobody that I don't like this patch.
> >>
> >> This really is a cursed topic, I am not sure I follow, after the patch:
> >>
> >> 5ms is accepted
> >> 5us is accepted
> >> 5m is not accepted
> >> 5u is not accepted
> >
> > That is only for AV_OPT_TYPE_DURATION.
> > All other numeric options type still accept SI prefix without unit.
> > This include various time options such as black_min_duration.
> > So after the patch, for black_min_duration:
> >
> > 5m is accepted
> > 5u is accepted
> >
> 
> Because those use AV_OPT_TYPE_DOUBLE, a generic type without any
> possiblity of a unit.

Of course, I know this.

> Ideally those should all be transitioned to AV_OPT_TYPE_DURATION if
> they refer to a time for consistency,

Of course that's what we ideally want in the end.
But it is not that trivial to do. To avoid breaking ABI we can't just
replace numeric options by AV_OPT_TYPE_DURATION. For each one we need
to introduce a new option name using AV_OPT_TYPE_DURATION and deprecate
the old numeric option.

The point is, as long has this transition isn't fully done, end users
have to deal with various time related options, some of which are
AV_OPT_TYPE_DURATION and some AV_OPT_TYPE_DOUBLE or AV_OPT_TYPE_INT64...
Right now, we can use '5u' with both black_min_duration and sbc_delay.
If this patch is applied, users will have to know that
black_min_duration is AV_OPT_TYPE_DOUBLE so they must use '5u' and
that sbc_delay is AV_OPT_TYPE_DURATION so they must use '5us'.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] lavc/vaapi_encode: Don't pass VAConfigAttribEncPackedHeaders with value set to 0

2018-03-07 Thread Mark Thompson

On 07/03/18 07:07, Xiang, Haihao wrote:
> On Tue, 2018-03-06 at 14:42 +, Mark Thompson wrote:
>> On 06/03/18 06:04, Eoff, Ullysses A wrote:
 -Original Message-
 From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf Of
 Mark Thompson
 Sent: Tuesday, February 13, 2018 11:54 AM
 To: FFmpeg development discussions and patches 
 Subject: Re: [FFmpeg-devel] [PATCH] lavc/vaapi_encode: Don't pass
 VAConfigAttribEncPackedHeaders with value set to 0

 On 13/02/18 18:52, Mark Thompson wrote:
> On 13/02/18 08:24, Haihao Xiang wrote:
>> Recent Intel i965 driver commit strictly disallows application to set
>> unsupported attribute values, VA_ENC_PACKED_HEADER_NONE (0) is not
>> used
>> in Intel i965 driver, so application shouldn't pass this value to the
>> driver. On the other hand, VA_ENC_PACKED_HEADER_NONE (0) means the
>> driver doesn't support any packed header mode, so application also
>> shouldn't pass packed header to driver if a driver returns
>> VA_ENC_PACKED_HEADER_NONE (0), the driver should work without
>> VAConfigAttribEncPackedHeaders set for this case.
>>
>> In addition, VA_ATTRIB_NOT_SUPPORTED and VA_ENC_PACKED_HEADER_NONE
>> make
>> thing messy, we will deprecate VA_ENC_PACKED_HEADER_NONE in the
>> future. See https://github.com/intel/libva/issues/178 for more
>> information.
>>
>> This fixes broken vp9 encoder on Kably Lake with Intel I965 driver.
>>
>> Signed-off-by: Haihao Xiang 
>> ---
>>  libavcodec/vaapi_encode.c | 4 
>>  1 file changed, 4 insertions(+)
>>
>> diff --git a/libavcodec/vaapi_encode.c b/libavcodec/vaapi_encode.c
>> index e371f5761ee..1d30aabed40 100644
>> --- a/libavcodec/vaapi_encode.c
>> +++ b/libavcodec/vaapi_encode.c
>> @@ -,6 +,10 @@ static av_cold int
>> vaapi_encode_config_attributes(AVCodecContext *avctx)
>> ctx->va_packed_headers, attr[i].value);
>>  ctx->va_packed_headers &= attr[i].value;
>>  }
>> +
>> +if (!ctx->va_packed_headers)
>> +continue;
>> +
>>  ctx->config_attributes[ctx->nb_config_attributes++] =
>>  (VAConfigAttrib) {
>>  .type  = VAConfigAttribEncPackedHeaders,
>>
>
> This seems wrong to me: the driver has indicated that packed headers are
> supported, so the user is providing this attribute to

 indicate to the driver that they will not use any of them.  Compare the
 VP8 case, where the driver does not support them and says so -
 there we correctly don't provide the attribute (though maybe the
 commentary could be clearer on that).

 Right, I hadn't realised you had already made a change so that encoding is
 currently broken.  I've made
  to revert the
 API/ABI-breaking part of the change.

 Thanks,

 - Mark
>>>
>>> I prefer this patch over the one for intel-vaapi-driver.
>>
>> Well, the driver patch should be applied anyway to fix the API/ABI break
>> (existing libavcodec builds should continue to work on the new
>> library/driver), but it can be reverted on the next major version bump.  
>> Maybe
>> a warning (i965_log_info()) could be added to the patch to indicate to the
>> client that the usage is deprecated in libva 2 and will be removed in libva 
>> 3?
>>
> 
> Ok, I will merge your driver patch for this special case (allow 0 for
> VAConfigAttribEncPackedHeaders when calling vaCreateConfig()) to resolve this
> issue. Could you update your patch to add some warning message?

Added in .  That gets the 
VP9 encoder in FFmpeg 3.4 working again with the warning:

[AVHWDeviceContext @ 0x56220f1b0340] libva: vaCreateConfig: setting the 
EncPackedHeaders attribute to zero to indicate that no packed headers will be 
used is deprecated.

>>> The va.h documentation for VA_ENC_PACKED_HEADER_NONE
>>> says "Driver does not support any packed headers mode".
>>> Hence, it's only valid for reporting to client that packed headers
>>> are "unsupported".  Unfortunately, VA_ENC_PACKED_HEADER_NONE 
>>> is redundant/ambiguous since there is also
>>> VA_ATTRIB_NOT_SUPPORTED to relay the same information.
>>> This is why we want to deprecate VA_ENC_PACKED_HEADER_NONE
>>> in VAAPI.
>>>
>>> I don't think it's correct for clients to send
>>> VA_ENC_PACKED_HEADER_NONE attribute value to the driver
>>> when the driver reports packed headers are "supported".  It
>>> goes against VA_ENC_PACKED_HEADER_NONE's documented
>>> purpose.  AFAIK, libavcodec is the only library that does this.  It
>>> is better to just omit the attribute altogether if client does not
>>> want to use any of the "supported" packed headers.  And this
>>> patch solves that.
>>
>> I st

Re: [FFmpeg-devel] [PATCH 1/7] avcodec/ffv1dec: add missing error messages when a frame is invalid

2018-03-07 Thread Jerome Martinez


On 08/03/2018 01:17, Michael Niedermayer wrote:


In the cases where the error is about a scalar value, that value should
be printed in the error message (unless it was alread printed elsewhere)


Patch modified, showing the scalar value.
From 13db9fc4da1d0e531e516bd87d084233e231f0e7 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?J=C3=A9r=C3=B4me=20Martinez?= 
Date: Thu, 8 Mar 2018 02:40:21 +0100
Subject: [PATCH] avcodec/ffv1dec: add missing error messages when a frame is
 invalid

---
 libavcodec/ffv1dec.c | 39 +++
 1 file changed, 31 insertions(+), 8 deletions(-)

diff --git a/libavcodec/ffv1dec.c b/libavcodec/ffv1dec.c
index 3d2ee2569f..06509dae60 100644
--- a/libavcodec/ffv1dec.c
+++ b/libavcodec/ffv1dec.c
@@ -182,11 +182,22 @@ static int decode_slice_header(FFV1Context *f, 
FFV1Context *fs)
 fs->slice_y /= f->num_v_slices;
 fs->slice_width  = fs->slice_width /f->num_h_slices - fs->slice_x;
 fs->slice_height = fs->slice_height/f->num_v_slices - fs->slice_y;
-if ((unsigned)fs->slice_width > f->width || (unsigned)fs->slice_height > 
f->height)
+if ((unsigned)fs->slice_width > f->width) {
+av_log(f->avctx, AV_LOG_ERROR, "slice_width %d out of range\n", 
(unsigned)fs->slice_width);
 return -1;
-if ((unsigned)fs->slice_x + (uint64_t)fs->slice_width  > f->width
- || (unsigned)fs->slice_y + (uint64_t)fs->slice_height > f->height)
+}
+if ((unsigned)fs->slice_height > f->height) {
+av_log(f->avctx, AV_LOG_ERROR, "slice_height %d out of range\n", 
(unsigned)fs->slice_height);
+return -1;
+}
+if ((unsigned)fs->slice_x + (uint64_t)fs->slice_width  > f->width) {
+av_log(f->avctx, AV_LOG_ERROR, "slice_x+slice_width %lld out of 
range\n", (unsigned)fs->slice_x + (uint64_t)fs->slice_width, 
(unsigned)fs->slice_y);
 return -1;
+}
+if ((unsigned)fs->slice_y + (uint64_t)fs->slice_height > f->height) {
+av_log(f->avctx, AV_LOG_ERROR, "slice_y+slice_height %lld out of 
range\n", (unsigned)fs->slice_y + (uint64_t)fs->slice_height);
+return -1;
+}
 
 for (i = 0; i < f->plane_count; i++) {
 PlaneContext * const p = &fs->plane[i];
@@ -432,8 +443,10 @@ static int read_extra_header(FFV1Context *f)
 if (f->version > 2) {
 c->bytestream_end -= 4;
 f->micro_version = get_symbol(c, state, 0);
-if (f->micro_version < 0)
+if (f->micro_version < 0) {
+av_log(f->avctx, AV_LOG_ERROR, "Invalid micro_version %i in global 
header\n", f->micro_version);
 return AVERROR_INVALIDDATA;
+}
 }
 f->ac = get_symbol(c, state, 0);
 
@@ -758,12 +771,22 @@ static int read_header(FFV1Context *f)
 fs->slice_y /= f->num_v_slices;
 fs->slice_width  = fs->slice_width  / f->num_h_slices - 
fs->slice_x;
 fs->slice_height = fs->slice_height / f->num_v_slices - 
fs->slice_y;
-if ((unsigned)fs->slice_width  > f->width ||
-(unsigned)fs->slice_height > f->height)
+if ((unsigned)fs->slice_width  > f->width) {
+av_log(f->avctx, AV_LOG_ERROR, "slice_width %d out of 
range\n", (unsigned)fs->slice_width);
 return AVERROR_INVALIDDATA;
-if (   (unsigned)fs->slice_x + (uint64_t)fs->slice_width  > 
f->width
-|| (unsigned)fs->slice_y + (uint64_t)fs->slice_height > 
f->height)
+}
+if ((unsigned)fs->slice_height > f->height) {
+av_log(f->avctx, AV_LOG_ERROR, "slice_height %d out of 
range\n", (unsigned)fs->slice_height);
+return AVERROR_INVALIDDATA;
+}
+if ((unsigned)fs->slice_x + (uint64_t)fs->slice_width  > f->width) 
{
+av_log(f->avctx, AV_LOG_ERROR, "slice_x+slice_width %lld out 
of range\n", (unsigned)fs->slice_x + (uint64_t)fs->slice_width, 
(unsigned)fs->slice_y);
 return AVERROR_INVALIDDATA;
+}
+if ((unsigned)fs->slice_y + (uint64_t)fs->slice_height > 
f->height) {
+av_log(f->avctx, AV_LOG_ERROR, "slice_y+slice_height %lld out 
of range\n", (unsigned)fs->slice_y + (uint64_t)fs->slice_height);
+return AVERROR_INVALIDDATA;
+}
 }
 
 for (i = 0; i < f->plane_count; i++) {
-- 
2.13.3.windows.1

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

Re: [FFmpeg-devel] [PATCH 2/7] avcodec/ffv1enc: add information message when version is changed by the encoder

2018-03-07 Thread Jerome Martinez


On 08/03/2018 01:33, Michael Niedermayer wrote:

On Wed, Mar 07, 2018 at 04:49:24PM +0100, Jerome Martinez wrote:

There is a message when coder type is forced to a value not chosen by user,
but no message when version is forced to a value not chosen by user.
This patch adds such message for more coherency in the messages, and the
user is informed that the command is not fully respected.

ffmpeg f lavfi -i mandelbrot=s=1920x1080 -vf format=gbrp9 -vframes 1 -c ffv1
-level 0 -coder 0 a.mkv

Before:
[ffv1 @ 02492CD69B40] bits_per_raw_sample > 8, forcing range coder

After:
[ffv1 @ 01A6E404A780] bits_per_raw_sample > 8, forcing version 1
[ffv1 @ 01A6E404A780] bits_per_raw_sample > 8, forcing range coder


  ffv1enc.c |8 +++-
  1 file changed, 7 insertions(+), 1 deletion(-)
cb1df919e21fe4d388df7de9349c5c2c46777862  
0002-avcodec-ffv1enc-add-information-message-when-version.patch
 From 49db6049fa50976683fc651cf180ab8c7428225e Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?J=C3=A9r=C3=B4me=20Martinez?= 
Date: Wed, 7 Mar 2018 10:37:46 +0100
Subject: [PATCH 2/7] avcodec/ffv1enc: add information message when version is
  changed by the encoder

---
  libavcodec/ffv1enc.c | 8 +++-
  1 file changed, 7 insertions(+), 1 deletion(-)

diff --git a/libavcodec/ffv1enc.c b/libavcodec/ffv1enc.c
index d71d952c6d..ac8b715b74 100644
--- a/libavcodec/ffv1enc.c
+++ b/libavcodec/ffv1enc.c
@@ -509,7 +509,7 @@ static av_cold int encode_init(AVCodecContext *avctx)
  {
  FFV1Context *s = avctx->priv_data;
  const AVPixFmtDescriptor *desc = av_pix_fmt_desc_get(avctx->pix_fmt);
-int i, j, k, m, ret;
+int i, j, k, m, ret, oldversion;
  
  if ((ret = ff_ffv1_common_init(avctx)) < 0)

  return ret;
@@ -534,6 +534,7 @@ static av_cold int encode_init(AVCodecContext *avctx)
  }
  s->version = avctx->level;
  }
+oldversion = s->version;
  
  if (s->ec < 0) {

  s->ec = (s->version >= 3);
@@ -679,6 +680,11 @@ FF_ENABLE_DEPRECATION_WARNINGS
  av_assert0(s->bits_per_raw_sample >= 8);
  
  if (s->bits_per_raw_sample > 8) {

+if (oldversion >= 0 && oldversion != s->version) {
+av_log(avctx, AV_LOG_INFO,
+"bits_per_raw_sample > 8, forcing version 1\n");
+oldversion = s->version;
+}

I dont think this works consistently

The code does not seem to be limited to the case where the user has
specifified a version for example unless i miss something


checking range coder part, I see that currently there is actually a 
slight difference with the other AV_LOG_INFO, I don't indicate the 
message when level is not indicated, as I didn't see the value added of 
such information when level is not indicated on the command line when I 
implemented the test.


With patch proposal:

ffmpeg f lavfi -i mandelbrot=s=1920x1080 -vf format=gbrp9 -vframes 1 -c 
ffv1 a.mkv

[ffv1 @ 0232D35B9240] bits_per_raw_sample > 8, forcing range coder
(no change)

ffmpeg f lavfi -i mandelbrot=s=1920x1080 -vf format=gbrp9 -vframes 1 -c 
ffv1 -coder 0 a.mkv

[ffv1 @ 014B9B1771C0] bits_per_raw_sample > 8, forcing range coder
(no change)

ffmpeg f lavfi -i mandelbrot=s=1920x1080 -vf format=gbrp9 -vframes 1 -c 
ffv1 -level 0 a.mkv

[ffv1 @ 01BC2B881500] bits_per_raw_sample > 8, forcing version 1
[ffv1 @ 01BC2B881500] bits_per_raw_sample > 8, forcing range coder
("version 1" line added because user specified version 0, IMO encoder 
should inform user that this is not respected)


ffmpeg f lavfi -i mandelbrot=s=1920x1080 -vf format=gbrp9 -vframes 1 -c 
ffv1 -level 0 -coder 0 a.mkv

[ffv1 @ 01EAC7685180] bits_per_raw_sample > 8, forcing version 1
[ffv1 @ 01EAC7685180] bits_per_raw_sample > 8, forcing range coder
("version 1" line added because user specified version 0, IMO encoder 
should inform user that this is not respected)


Just for being clear: do you want info message also when level/version 
is *not* indicated on the command line?



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

Re: [FFmpeg-devel] [PATCH v2] checkasm/hevc_sao : add hevc_sao for checkasm

2018-03-07 Thread James Almer

On 3/7/2018 1:42 AM, Yingming Fan wrote:
> From: Yingming Fan 
> 
> ---
>  Previous patch test 8 9 and 10 bit depth, because i consult codes from 
> hevc_idct and hevc_add_res.
>  While this patch test 8 10 and 12 bit depth like what VP9 does. I will 
> submit another patch fix these issue in hevc_idct and hevc_add_res.
>  This patch also refined randomize_buffers codes compared to previous patch.
>  
>  tests/checkasm/Makefile   |   2 +-
>  tests/checkasm/checkasm.c |   1 +
>  tests/checkasm/checkasm.h |   1 +
>  tests/checkasm/hevc_sao.c | 150 
> ++
>  tests/fate/checkasm.mak   |   1 +
>  5 files changed, 154 insertions(+), 1 deletion(-)
>  create mode 100644 tests/checkasm/hevc_sao.c

Tested on mingw-64 x86 and x86_64, and ArchLinux x86_64.

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

[FFmpeg-devel] [PATCH 2/3] http: avoid out of bound accesses on broken St-Cookie headers

2018-03-07 Thread wm4

It's trivial to craft a HTTP response that will make the code for
skipping trailing whitespace access and possibly overwrite bytes outside
of the memory allocation. Why this can happen is blindingly obvious: it
accesses cstr[strlen(cstr)-1] without checking whether the string is
empty.
---
 libavformat/http.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/libavformat/http.c b/libavformat/http.c
index d7a72e7129..59f90ac603 100644
--- a/libavformat/http.c
+++ b/libavformat/http.c
@@ -750,6 +750,9 @@ static int parse_set_cookie(const char *set_cookie, 
AVDictionary **dict)
 {
 char *param, *next_param, *cstr, *back;
 
+if (!set_cookie[0])
+return 0;
+
 if (!(cstr = av_strdup(set_cookie)))
 return AVERROR(EINVAL);
 
-- 
2.16.1

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

[FFmpeg-devel] [PATCH 1/3] http: do not print a warning message for expired cookies

2018-03-07 Thread wm4

libavformat prints a warning that the cookie couldn't be parsed (see
callers of parse_cookie()). This is obviously not true - it could be
parsed, but was simply ignored. Don't return an error to avoid the
warning.
---
 libavformat/http.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/libavformat/http.c b/libavformat/http.c
index 344fd603cb..d7a72e7129 100644
--- a/libavformat/http.c
+++ b/libavformat/http.c
@@ -802,7 +802,7 @@ static int parse_cookie(HTTPContext *s, const char *p, 
AVDictionary **cookies)
 // if the cookie has already expired ignore it
 if (av_timegm(&new_tm) < av_gettime() / 100) {
 av_dict_free(&new_params);
-return -1;
+return 0;
 }
 
 // only replace an older cookie with the same name
-- 
2.16.1

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

[FFmpeg-devel] [PATCH 3/3] http: fix potentially dangerous whitespace skipping code

2018-03-07 Thread wm4

If the string consists entirely of whitespace, this could in theory
continue to write '\0' before the start of the memory allocation. In
practice, it didn't really happen: the generic HTTP header parsing code
already skips leading whitespaces, so the string is either empty, or
consists a non-whitespace. (The generic code and the cookie code
actually have different ideas about what bytes are whitespace: the
former uses av_isspace(), the latter uses WHITESPACES. Fortunately,
av_isspace() is a super set of the http.c specific WHITESPACES, so
there's probably no case where the above assumption could have been
broken.)
---
 libavformat/http.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/libavformat/http.c b/libavformat/http.c
index 59f90ac603..983034f083 100644
--- a/libavformat/http.c
+++ b/libavformat/http.c
@@ -760,6 +760,8 @@ static int parse_set_cookie(const char *set_cookie, 
AVDictionary **dict)
 back = &cstr[strlen(cstr)-1];
 while (strchr(WHITESPACES, *back)) {
 *back='\0';
+if (back == cstr)
+break;
 back--;
 }
 
-- 
2.16.1

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

Re: [FFmpeg-devel] [PATCH] lavc: Add filter_units bitstream filter

2018-03-07 Thread James Almer

On 3/6/2018 3:49 PM, Mark Thompson wrote:
> This can remove units with types in or not in a given set from a stream.
> For example, it can be used to remove all non-VCL NAL units from an H.264 or
> H.265 stream.
> ---
> On 06/03/18 17:27, Hendrik Leppkes wrote:
>> On Tue, Mar 6, 2018 at 3:51 PM, Eran Kornblau  
>> wrote:
>>> Hi all,
>>>
>>> The attached patch adds a parameter that enables the user to choose which 
>>> AVC/HEVC NAL units to include in the output.
>>> The parameter is supplied as a bitmask in order to keep things simple.
>>>
>>> A short background on why we need it - in our transcoding process, we 
>>> partition the video in chunks, the chunks are
>>> transcoded in parallel and packaged in MPEG-TS container. The transcoded TS 
>>> chunks are then concatenated and
>>> packaged in MP4. These MP4 files are later repackaged on-the-fly to various 
>>> protocols (HLS/DASH etc.) using our
>>> JIT packager.
>>> For performance reasons (can get into more detail if anyone's 
>>> interested...), when packaging the MP4 to DASH/CENC,
>>> we configure the packager to assume that each AVC frame contains exactly 
>>> one NAL unit.
>>> The problem is that the transition through MPEG-TS adds additional NAL 
>>> units (NAL AUD before each frame + SPS/PPS
>>> before each key frame), and this assumption fails.
>>> Using the attached patch we can pass '-nal_types_mask 0x3e' which will make 
>>> ffmpeg output only VCL NALs in the stream.
>>>
>>
>> Having such logic in one single muxer is not something we really like
>> around here. Next time someone needs something similar for another
>> codec, you're stuck re-implementing it.
>>
>> To achieve the same effect, Mark Thompson quickly wipped up a
>> Bitstream Filter using his CBS framework which achieves the same
>> result. He'll be sending that patch to the mailing list in a while.
> The suggested use-case would be '-bsf:v filter_units=pass_types=1-5' for 
> H.264 or '-bsf:v filter_units=pass_types=0-31' for H.265.
> 
> (Also note that filters already exist for some individual parts of this: 
> h264_metadata can remove AUDs, extract_extradata can remove parameter sets.)
> 
> - Mark
> 
> 
>  libavcodec/Makefile|   1 +
>  libavcodec/bitstream_filters.c |   1 +
>  libavcodec/filter_units_bsf.c  | 250 
> +
>  3 files changed, 252 insertions(+)
>  create mode 100644 libavcodec/filter_units_bsf.c
> 

Can you write some minimal documentation with the two above examples?

> diff --git a/libavcodec/Makefile b/libavcodec/Makefile
> index b496f0d..b99bdce 100644
> --- a/libavcodec/Makefile
> +++ b/libavcodec/Makefile
> @@ -1037,6 +1037,7 @@ OBJS-$(CONFIG_DUMP_EXTRADATA_BSF) += 
> dump_extradata_bsf.o
>  OBJS-$(CONFIG_DCA_CORE_BSF)   += dca_core_bsf.o
>  OBJS-$(CONFIG_EXTRACT_EXTRADATA_BSF)  += extract_extradata_bsf.o\
>   h2645_parse.o
> +OBJS-$(CONFIG_FILTER_UNITS_BSF)   += filter_units_bsf.o
>  OBJS-$(CONFIG_H264_METADATA_BSF)  += h264_metadata_bsf.o
>  OBJS-$(CONFIG_H264_MP4TOANNEXB_BSF)   += h264_mp4toannexb_bsf.o
>  OBJS-$(CONFIG_H264_REDUNDANT_PPS_BSF) += h264_redundant_pps_bsf.o
> diff --git a/libavcodec/bitstream_filters.c b/libavcodec/bitstream_filters.c
> index 338ef82..e1dc198 100644
> --- a/libavcodec/bitstream_filters.c
> +++ b/libavcodec/bitstream_filters.c
> @@ -29,6 +29,7 @@ extern const AVBitStreamFilter ff_chomp_bsf;
>  extern const AVBitStreamFilter ff_dump_extradata_bsf;
>  extern const AVBitStreamFilter ff_dca_core_bsf;
>  extern const AVBitStreamFilter ff_extract_extradata_bsf;
> +extern const AVBitStreamFilter ff_filter_units_bsf;
>  extern const AVBitStreamFilter ff_h264_metadata_bsf;
>  extern const AVBitStreamFilter ff_h264_mp4toannexb_bsf;
>  extern const AVBitStreamFilter ff_h264_redundant_pps_bsf;
> diff --git a/libavcodec/filter_units_bsf.c b/libavcodec/filter_units_bsf.c
> new file mode 100644
> index 000..3126f17
> --- /dev/null
> +++ b/libavcodec/filter_units_bsf.c
> @@ -0,0 +1,250 @@
> +/*
> + * 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 "libavutil/common.h"
> +#include "libavutil/opt.h"
> +
> +#include "bsf.h"
> +

[FFmpeg-devel] [PATCH] lavf/movenc: keep eac3_priv around; fixes eac3 in DASH

2018-03-07 Thread Rodger Combs

---
 libavformat/movenc.c | 1 -
 1 file changed, 1 deletion(-)

diff --git a/libavformat/movenc.c b/libavformat/movenc.c
index 5b1e66c897..fb8462ed9a 100644
--- a/libavformat/movenc.c
+++ b/libavformat/movenc.c
@@ -554,7 +554,6 @@ static int mov_write_eac3_tag(AVIOContext *pb, MOVTrack 
*track)
 
 end:
 av_packet_unref(&info->pkt);
-av_freep(&track->eac3_priv);
 
 return size;
 }
-- 
2.16.2

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

[FFmpeg-devel] [PATCH] avcodec/arm/hevcdsp_sao : add NEON optimization for sao

2018-03-07 Thread Yingming Fan

From: Meng Wang 

Signed-off-by: Meng Wang 
---
As FFmpeg hevc decoder have no SAO neon optimization, we add sao_band and 
sao_edge neon codes in this patch.
I have already submit a patch called 'checkasm/hevc_sao : add hevc_sao for 
checkasm' several days ago.
Results below was printed by hevc_sao checkasm on an armv7 device Nexus 5. 
From the results we can see: hevc_sao_band speed up ~2x, hevc_sao_edge speed up 
~4x. 
Also test FATE under armv7 device and MacOS.

hevc_sao_band_8x8_8_c: 804.9
hevc_sao_band_8x8_8_neon: 452.4
hevc_sao_band_16x16_8_c: 2638.1
hevc_sao_band_16x16_8_neon: 1169.9
hevc_sao_band_32x32_8_c: 9259.9
hevc_sao_band_32x32_8_neon: 3956.1
hevc_sao_band_48x48_8_c: 20344.6
hevc_sao_band_48x48_8_neon: 8649.6
hevc_sao_band_64x64_8_c: 35684.6
hevc_sao_band_64x64_8_neon: 15213.1
hevc_sao_edge_8x8_8_c: 1761.6
hevc_sao_edge_8x8_8_neon: 414.6
hevc_sao_edge_16x16_8_c: 6844.4
hevc_sao_edge_16x16_8_neon: 1589.9
hevc_sao_edge_32x32_8_c: 27156.4
hevc_sao_edge_32x32_8_neon: 6116.6
hevc_sao_edge_48x48_8_c: 60004.6
hevc_sao_edge_48x48_8_neon: 13686.4
hevc_sao_edge_64x64_8_c: 106708.1
hevc_sao_edge_64x64_8_neon: 24240.1

 libavcodec/arm/Makefile|   3 +-
 libavcodec/arm/hevcdsp_init_neon.c |  63 +
 libavcodec/arm/hevcdsp_sao_neon.S  | 181 +
 3 files changed, 246 insertions(+), 1 deletion(-)
 create mode 100644 libavcodec/arm/hevcdsp_sao_neon.S

diff --git a/libavcodec/arm/Makefile b/libavcodec/arm/Makefile
index 1eeac5449e..2ee913e8a8 100644
--- a/libavcodec/arm/Makefile
+++ b/libavcodec/arm/Makefile
@@ -136,7 +136,8 @@ NEON-OBJS-$(CONFIG_DCA_DECODER)+= 
arm/synth_filter_neon.o
 NEON-OBJS-$(CONFIG_HEVC_DECODER)   += arm/hevcdsp_init_neon.o   \
   arm/hevcdsp_deblock_neon.o\
   arm/hevcdsp_idct_neon.o   \
-  arm/hevcdsp_qpel_neon.o
+  arm/hevcdsp_qpel_neon.o   \
+ arm/hevcdsp_sao_neon.o
 NEON-OBJS-$(CONFIG_RV30_DECODER)   += arm/rv34dsp_neon.o
 NEON-OBJS-$(CONFIG_RV40_DECODER)   += arm/rv34dsp_neon.o\
   arm/rv40dsp_neon.o
diff --git a/libavcodec/arm/hevcdsp_init_neon.c 
b/libavcodec/arm/hevcdsp_init_neon.c
index a4628d2a93..3c480f12f8 100644
--- a/libavcodec/arm/hevcdsp_init_neon.c
+++ b/libavcodec/arm/hevcdsp_init_neon.c
@@ -21,8 +21,16 @@
 #include "libavutil/attributes.h"
 #include "libavutil/arm/cpu.h"
 #include "libavcodec/hevcdsp.h"
+#include "libavcodec/avcodec.h"
 #include "hevcdsp_arm.h"
 
+void ff_hevc_sao_band_filter_neon_8_wrapper(uint8_t *_dst, uint8_t *_src,
+  ptrdiff_t stride_dst, ptrdiff_t stride_src,
+  int16_t *sao_offset_val, int sao_left_class,
+  int width, int height);
+void ff_hevc_sao_edge_filter_neon_8_wrapper(uint8_t *_dst, uint8_t *_src, 
ptrdiff_t stride_dst, int16_t *sao_offset_val,
+  int eo, int width, int height);
+
 void ff_hevc_v_loop_filter_luma_neon(uint8_t *_pix, ptrdiff_t _stride, int 
_beta, int *_tc, uint8_t *_no_p, uint8_t *_no_q);
 void ff_hevc_h_loop_filter_luma_neon(uint8_t *_pix, ptrdiff_t _stride, int 
_beta, int *_tc, uint8_t *_no_p, uint8_t *_no_q);
 void ff_hevc_v_loop_filter_chroma_neon(uint8_t *_pix, ptrdiff_t _stride, int 
*_tc, uint8_t *_no_p, uint8_t *_no_q);
@@ -142,6 +150,51 @@ QPEL_FUNC_UW(ff_hevc_put_qpel_uw_h3v2_neon_8);
 QPEL_FUNC_UW(ff_hevc_put_qpel_uw_h3v3_neon_8);
 #undef QPEL_FUNC_UW
 
+void ff_hevc_sao_band_filter_neon_8(uint8_t *dst, uint8_t *src, ptrdiff_t 
stride_dst, ptrdiff_t stride_src, int width, int height, int16_t *offset_table);
+
+void ff_hevc_sao_band_filter_neon_8_wrapper(uint8_t *_dst, uint8_t *_src,
+  ptrdiff_t stride_dst, ptrdiff_t stride_src,
+  int16_t *sao_offset_val, int sao_left_class,
+  int width, int height) {
+uint8_t *dst = (uint8_t *)_dst;
+uint8_t *src = (uint8_t *)_src;
+int16_t offset_table[32] = {0};
+int k;
+
+stride_dst /= sizeof(uint8_t);
+stride_src /= sizeof(uint8_t);
+
+for (k = 0; k < 4; k++) {
+offset_table[(k + sao_left_class) & 31] = sao_offset_val[k + 1];
+}
+
+ff_hevc_sao_band_filter_neon_8(dst, src, stride_dst, stride_src, width, 
height, offset_table);
+}
+
+void ff_hevc_sao_edge_filter_neon_8(uint8_t *dst, uint8_t *src, ptrdiff_t 
stride_dst, ptrdiff_t stride_src, int width, int height,
+int a_stride, int b_stride, int16_t 
*sao_offset_val, uint8_t *edge_idx);
+
+void ff_hevc_sao_edge_filter_neon_8_wrapper(uint8_t *_dst, uint8_t *_src, 
ptrdiff_t stride_dst, int16_t *sao_offset_val,
+  int eo, int width, int height) {
+s

Re: [FFmpeg-devel] [PATCH] avcodec/mpeg12dec: ignore scte20 captions when a53 data is also present

2018-03-07 Thread Aman Gupta

On Wed, Mar 7, 2018 at 10:35 AM Devin Heitmueller <
dheitmuel...@ltnglobal.com> wrote:

>
> > From what I've seen in US broadcast television, scte20 is only used on
> > standard-def content and everything else uses normal a53.
>
> A53 is definitely the more popular standard, and all that is approved for
> distribution in digital over the air broadcasts.  SCTE-20 would only be
> found further up the distribution chain, and perhaps in distribution to
> some cable boxes (although it’s becoming less and less common that it can
> be decoded since most of the content is encrypted nowadays).


>
> >
> > I'm not sure how we would export both since there's only one type of side
> > data.
>
> We would have to add a new side data type, and encoders would have to be
> changed to look for both.


>
> >>
> >> also turning one off for ever seems problematic for concatenated
> >> sequences. not every sequence would need to contain both I guess
>
> Funny enough, I spent my entire morning debugging some issues with playing
> concatenated TS streams.  If anyone thinks that’s supposed to be working
> today in ffmpeg, there’s a ton of work to be done in that area.


>
> >
> >
> > Yea that's theoreticaly possible, but I'd rather wait to add support
> until
> > someone actually sees it in the wild.
> >
> > Before I added scte20 support a few months ago no one even noticed it was
> > missing. It doesn't seem to have wide spread use.
>
> It’s not really that nobody noticed - it’s that most people in the
> broadcast space until recently had ruled out the ability to use ffmpeg for
> production because of it’s lack of good support for ancillary data such as
> captions.  That situation is improving of course, but it’s not so much that
> “no one even noticed it was missing”.


>
> If changing the framework to support the extra side data format isn’t
> viable, then certainly prefering A53 over SCTE-20 would be the right way to
> go.  I would make it configurable though.


Thanks for the background on SCTE-20. I don't really know much about it.

I'm not opposed to adding new side data, but it doesn't sound like it's
worth it in this particular case. Atleast to me; if someone else wants to
pursue that approach I will happily help review and test any patches.

>
To make my patch configurable, I could change the ignore flag I added into
a new option called parse_scte20: default to "prefer a53" like I have now,
but can be set explicitly to "always" or "never". Wdyt?

Aman


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

[FFmpeg-devel] [PATCH] checkasm/hevc_idct : update test bit depth from 8 9 and 10 to 8 10 and 12

2018-03-07 Thread Yingming Fan

From: Yingming Fan 

---
 We have 8 10 and 12 SIMD codes, but previous checkasm hevc_idct only test 8 
and 10 bit depth.
 
 tests/checkasm/hevc_idct.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/tests/checkasm/hevc_idct.c b/tests/checkasm/hevc_idct.c
index eea712101d..c20111c2df 100644
--- a/tests/checkasm/hevc_idct.c
+++ b/tests/checkasm/hevc_idct.c
@@ -87,7 +87,7 @@ void checkasm_check_hevc_idct(void)
 {
 int bit_depth;
 
-for (bit_depth = 8; bit_depth <= 10; bit_depth++) {
+for (bit_depth = 8; bit_depth <= 12; bit_depth += 2) {
 HEVCDSPContext h;
 
 ff_hevc_dsp_init(&h, bit_depth);
@@ -95,7 +95,7 @@ void checkasm_check_hevc_idct(void)
 }
 report("idct_dc");
 
-for (bit_depth = 8; bit_depth <= 10; bit_depth++) {
+for (bit_depth = 8; bit_depth <= 12; bit_depth += 2) {
 HEVCDSPContext h;
 
 ff_hevc_dsp_init(&h, bit_depth);
-- 
2.14.3 (Apple Git-98)

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

64 matches

Mail list logo