[FFmpeg-devel] [PATCH V3] examples/hw_decode: Add a HWAccel decoding example.

[Jun Zhao]

V3: re-work to support the other hwaccels, just test with vaapi, 
dxva2|d3d11va|videotoolbox might work as well.
V2: re-work with new hw decoding API.
From bd8cbd5c16be3001b950f0c4ae3548909a396bc6 Mon Sep 17 00:00:00 2001
From: Jun Zhao 
Date: Thu, 20 Jul 2017 00:58:56 -0400
Subject: [PATCH V3] examples/hw_decode: Add a HWAccel decoding example.

Add a HWAccel decoding example.

Just test with vaapi, dxva2|d3d11va|videotoolbox might work as well.

Signed-off-by: Liu, Kaixuan 
Signed-off-by: Jun Zhao 
---
 doc/examples/hw_decode.c | 246 +++
 1 file changed, 246 insertions(+)
 create mode 100644 doc/examples/hw_decode.c

diff --git a/doc/examples/hw_decode.c b/doc/examples/hw_decode.c
new file mode 100644
index 00..4070a60cba
--- /dev/null
+++ b/doc/examples/hw_decode.c
@@ -0,0 +1,246 @@
+/*
+ * Copyright (c) 2017 Jun Zhao
+ * Copyright (c) 2017 Kaixuan Liu
+ *
+ * HW Acceleration API (video decoding) decode sample
+ *
+ * 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
+ */
+
+/**
+ * @file
+ * HW-Accelerated decoding example.
+ *
+ * @example hw_decode.c
+ * This example shows how to do HW-accelerated decoding with output
+ * frames from the HW video surfaces.
+ */
+
+#include 
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+static AVBufferRef *hw_device_ctx = NULL;
+static enum AVPixelFormat hw_pix_fmt;
+FILE *output_file = NULL;
+
+static enum AVPixelFormat hw_pix_fmts[] = {
+[AV_HWDEVICE_TYPE_CUDA] = AV_PIX_FMT_CUDA,
+[AV_HWDEVICE_TYPE_DXVA2]= AV_PIX_FMT_DXVA2_VLD,
+[AV_HWDEVICE_TYPE_D3D11VA]  = AV_PIX_FMT_D3D11VA_VLD,
+[AV_HWDEVICE_TYPE_QSV]  = AV_PIX_FMT_QSV,
+[AV_HWDEVICE_TYPE_VAAPI]= AV_PIX_FMT_VAAPI,
+[AV_HWDEVICE_TYPE_VDPAU]= AV_PIX_FMT_VDPAU,
+[AV_HWDEVICE_TYPE_VIDEOTOOLBOX] = AV_PIX_FMT_VIDEOTOOLBOX,
+};
+
+static enum AVPixelFormat find_fmt_by_hw_type(const enum AVHWDeviceType type)
+{
+if (type >= 0 && type < FF_ARRAY_ELEMS(hw_pix_fmts))
+return hw_pix_fmts[type];
+else
+return AV_PIX_FMT_NONE;
+}
+
+static int hw_decoder_init(AVCodecContext *ctx, const enum AVHWDeviceType type)
+{
+int err = 0;
+
+if ((err = av_hwdevice_ctx_create(_device_ctx, type,
+  NULL, NULL, 0)) < 0) {
+fprintf(stderr, "Failed to create specified HW device.\n");
+return err;
+}
+ctx->hw_device_ctx = av_buffer_ref(hw_device_ctx);
+
+return err;
+}
+
+static enum AVPixelFormat get_hw_format(AVCodecContext *ctx,
+const enum AVPixelFormat *pix_fmts)
+{
+const enum AVPixelFormat *p;
+
+for (p = pix_fmts; *p != -1; p++) {
+if (*p == hw_pix_fmt)
+return *p;
+}
+
+fprintf(stderr, "Failed to get HW surface format.\n");
+return AV_PIX_FMT_NONE;
+}
+
+static int decode_write(AVCodecContext *avctx, AVPacket *packet)
+{
+AVFrame *frame = NULL, *sw_frame = NULL;
+AVFrame *tmp_frame = NULL;
+uint8_t *buffer = NULL;
+int size;
+int ret = 0;
+
+ret = avcodec_send_packet(avctx, packet);
+if (ret < 0) {
+fprintf(stderr, "Error during decoding\n");
+return ret;
+}
+
+while (ret >= 0) {
+if (!(frame = av_frame_alloc()) || !(sw_frame = av_frame_alloc()))
+return AVERROR(ENOMEM);
+
+ret = avcodec_receive_frame(avctx, frame);
+if (ret == AVERROR(EAGAIN) || ret == AVERROR_EOF)
+break;
+else if (ret < 0) {
+fprintf(stderr, "Error while decoding\n");
+goto fail;
+}
+
+if (frame->format == hw_pix_fmt) {
+/* retrieve data from GPU to CPU */
+if ((ret = av_hwframe_transfer_data(sw_frame, frame, 0)) < 0) {
+fprintf(stderr, "Error transferring the data to system 
memory\n");
+goto fail;
+}
+tmp_frame = sw_frame;
+} else
+tmp_frame = frame;
+
+size = av_image_get_buffer_size(tmp_frame->format, tmp_frame->width,
+tmp_frame->height, 1);
+buffer = 

Re: [FFmpeg-devel] [mov] Fix trampling of ctts during seeks when sidx support is enabled.

[Dale Curtis]

I found some samples with ctts and trun boxes, so I've updated the patch to
handle these cases since I don't know how common they are in the wild and
it's an easy fix. I'll send a followup patch if this one is accepted to
remove support for > 1 count ctts entries.

- dale

On Wed, Jul 19, 2017 at 7:30 PM, Dale Curtis 
wrote:

> Thanks will take a look. Is this test not part of fate? make fate passed
> for me. The attached patch fixes this; the issue was that the index entries
> are 1 to 1 with ctts values. When samples are added without ctts entries
> we'd just initialize a single ctts entry with a count of 5. This left a gap
> in the ctts table; the fix is to use only 1-count entries when this case is
> hit.
>
> Note: This made me realize the presence of a ctts box and a trun box with
> ctts samples has always been broken. If the ctts box comes second it'll
> wipe the trun's generated table, but if the trun box comes after the ctts
> box it will try to insert samples at incorrect positions. Prior to my patch
> they would be looked up at incorrect positions, so there shouldn't be any
> new bad behavior here.
>
> - dale
>
> On Wed, Jul 19, 2017 at 3:28 PM, Michael Niedermayer <
> mich...@niedermayer.cc> wrote:
>
>> On Tue, Jul 18, 2017 at 11:49:26AM -0700, Dale Curtis wrote:
>> > Updated patch that fixes other ctts modification code to use the new
>> > ctts_allocated_size value; I've verified this passes fate.
>> >
>> > - dale
>> >
>> > On Tue, Jul 18, 2017 at 9:53 AM, Dale Curtis 
>> > wrote:
>> >
>> > > Resending as it's own message per contribution rules. I've also
>> attached
>> > > the patch in case the formatting gets trashed.
>> > >
>> > > When sidx box support is enabled, the code will skip reading all
>> > > trun boxes (each containing ctts entries for samples inthat box).
>> > >
>> > > If seeks are attempted before all ctts values are known, the old
>> > > code would dump ctts entries into the wrong location. These are
>> > > then used to compute pts values which leads to out of order and
>> > > incorrectly timestamped packets.
>> > >
>> > > This patch fixes ctts processing by always using the index returned
>> > > by av_add_index_entry() as the ctts_data index. When the index gains
>> > > new entries old values are reshuffled as appropriate.
>> > >
>> > > This approach makes sense since the mov demuxer is already relying
>> > > on the mapping of AVIndex entries to samples for correct demuxing.
>> > >
>> > > Notes for future improvement:
>> > > Probably there are other boxes (stts, stsc, etc) that are impacted
>> > > by this issue... this patch only attempts to fix ctts since it
>> > > completely breaks packet timestamping.
>> > >
>> > > This patch continues using an array for the ctts data, which is not
>> > > the most ideal given the rearrangement that needs to happen (via
>> > > memmove as new entries are read in). Ideally AVIndex and the ctts
>> > > data would be set-type structures so addition is always worst case
>> > > O(lg(n)) instead of the O(n^2) that exists now; this slowdown is
>> > > noticeable during seeks.
>> > >
>> > > Additionally since ctts samples from trun boxes always have a count
>> > > of 1, there's probably an opportunity to avoid the post-seek fixup
>> > > that iterates O(n) over all samples with an O(1) when no non-1 count
>> > > samples are present.
>> > >
>> > > Signed-off-by: Dale Curtis 
>> > > ---
>> > >  libavformat/isom.h |  1 +
>> > >  libavformat/mov.c  | 46 ++
>> +---
>> > >  2 files changed, 32 insertions(+), 15 deletions(-)
>> > >
>> > > diff --git a/libavformat/isom.h b/libavformat/isom.h
>> > > index ff009b0896..fdd98c28f5 100644
>> > > --- a/libavformat/isom.h
>> > > +++ b/libavformat/isom.h
>> > > @@ -137,6 +137,7 @@ typedef struct MOVStreamContext {
>> > >  unsigned int stts_count;
>> > >  MOVStts *stts_data;
>> > >  unsigned int ctts_count;
>> > > +unsigned int ctts_allocated_size;
>> > >  MOVStts *ctts_data;
>> > >  unsigned int stsc_count;
>> > >  MOVStsc *stsc_data;
>> > > diff --git a/libavformat/mov.c b/libavformat/mov.c
>> > > index 63f84be782..412290b435 100644
>> > > --- a/libavformat/mov.c
>> > > +++ b/libavformat/mov.c
>> > > @@ -4297,11 +4297,6 @@ static int mov_read_trun(MOVContext *c,
>> AVIOContext
>> > > *pb, MOVAtom atom)
>> > >  }
>> > >  if ((uint64_t)entries+sc->ctts_count >=
>> > > UINT_MAX/sizeof(*sc->ctts_data))
>> > >  return AVERROR_INVALIDDATA;
>> > > -if ((err = av_reallocp_array(>ctts_data, entries +
>> > > sc->ctts_count,
>> > > - sizeof(*sc->ctts_data))) < 0) {
>> > > -sc->ctts_count = 0;
>> > > -return err;
>> > > -}
>> > >  if (flags & MOV_TRUN_DATA_OFFSET)data_offset=
>> > > avio_rb32(pb);
>> > >  if (flags & MOV_TRUN_FIRST_SAMPLE_FLAGS) first_sample_flags =
>> > > avio_rb32(pb);
>> > >  

Re: [FFmpeg-devel] [mov] Fix trampling of ctts during seeks when sidx support is enabled.

[Dale Curtis]

Thanks will take a look. Is this test not part of fate? make fate passed
for me. The attached patch fixes this; the issue was that the index entries
are 1 to 1 with ctts values. When samples are added without ctts entries
we'd just initialize a single ctts entry with a count of 5. This left a gap
in the ctts table; the fix is to use only 1-count entries when this case is
hit.

Note: This made me realize the presence of a ctts box and a trun box with
ctts samples has always been broken. If the ctts box comes second it'll
wipe the trun's generated table, but if the trun box comes after the ctts
box it will try to insert samples at incorrect positions. Prior to my patch
they would be looked up at incorrect positions, so there shouldn't be any
new bad behavior here.

- dale

On Wed, Jul 19, 2017 at 3:28 PM, Michael Niedermayer  wrote:

> On Tue, Jul 18, 2017 at 11:49:26AM -0700, Dale Curtis wrote:
> > Updated patch that fixes other ctts modification code to use the new
> > ctts_allocated_size value; I've verified this passes fate.
> >
> > - dale
> >
> > On Tue, Jul 18, 2017 at 9:53 AM, Dale Curtis 
> > wrote:
> >
> > > Resending as it's own message per contribution rules. I've also
> attached
> > > the patch in case the formatting gets trashed.
> > >
> > > When sidx box support is enabled, the code will skip reading all
> > > trun boxes (each containing ctts entries for samples inthat box).
> > >
> > > If seeks are attempted before all ctts values are known, the old
> > > code would dump ctts entries into the wrong location. These are
> > > then used to compute pts values which leads to out of order and
> > > incorrectly timestamped packets.
> > >
> > > This patch fixes ctts processing by always using the index returned
> > > by av_add_index_entry() as the ctts_data index. When the index gains
> > > new entries old values are reshuffled as appropriate.
> > >
> > > This approach makes sense since the mov demuxer is already relying
> > > on the mapping of AVIndex entries to samples for correct demuxing.
> > >
> > > Notes for future improvement:
> > > Probably there are other boxes (stts, stsc, etc) that are impacted
> > > by this issue... this patch only attempts to fix ctts since it
> > > completely breaks packet timestamping.
> > >
> > > This patch continues using an array for the ctts data, which is not
> > > the most ideal given the rearrangement that needs to happen (via
> > > memmove as new entries are read in). Ideally AVIndex and the ctts
> > > data would be set-type structures so addition is always worst case
> > > O(lg(n)) instead of the O(n^2) that exists now; this slowdown is
> > > noticeable during seeks.
> > >
> > > Additionally since ctts samples from trun boxes always have a count
> > > of 1, there's probably an opportunity to avoid the post-seek fixup
> > > that iterates O(n) over all samples with an O(1) when no non-1 count
> > > samples are present.
> > >
> > > Signed-off-by: Dale Curtis 
> > > ---
> > >  libavformat/isom.h |  1 +
> > >  libavformat/mov.c  | 46 ++
> +---
> > >  2 files changed, 32 insertions(+), 15 deletions(-)
> > >
> > > diff --git a/libavformat/isom.h b/libavformat/isom.h
> > > index ff009b0896..fdd98c28f5 100644
> > > --- a/libavformat/isom.h
> > > +++ b/libavformat/isom.h
> > > @@ -137,6 +137,7 @@ typedef struct MOVStreamContext {
> > >  unsigned int stts_count;
> > >  MOVStts *stts_data;
> > >  unsigned int ctts_count;
> > > +unsigned int ctts_allocated_size;
> > >  MOVStts *ctts_data;
> > >  unsigned int stsc_count;
> > >  MOVStsc *stsc_data;
> > > diff --git a/libavformat/mov.c b/libavformat/mov.c
> > > index 63f84be782..412290b435 100644
> > > --- a/libavformat/mov.c
> > > +++ b/libavformat/mov.c
> > > @@ -4297,11 +4297,6 @@ static int mov_read_trun(MOVContext *c,
> AVIOContext
> > > *pb, MOVAtom atom)
> > >  }
> > >  if ((uint64_t)entries+sc->ctts_count >=
> > > UINT_MAX/sizeof(*sc->ctts_data))
> > >  return AVERROR_INVALIDDATA;
> > > -if ((err = av_reallocp_array(>ctts_data, entries +
> > > sc->ctts_count,
> > > - sizeof(*sc->ctts_data))) < 0) {
> > > -sc->ctts_count = 0;
> > > -return err;
> > > -}
> > >  if (flags & MOV_TRUN_DATA_OFFSET)data_offset=
> > > avio_rb32(pb);
> > >  if (flags & MOV_TRUN_FIRST_SAMPLE_FLAGS) first_sample_flags =
> > > avio_rb32(pb);
> > >  dts= sc->track_end - sc->time_offset;
> > > @@ -4312,26 +4307,28 @@ static int mov_read_trun(MOVContext *c,
> > > AVIOContext *pb, MOVAtom atom)
> > >  unsigned sample_size = frag->size;
> > >  int sample_flags = i ? frag->flags : first_sample_flags;
> > >  unsigned sample_duration = frag->duration;
> > > +unsigned ctts_duration = 0;
> > >  int keyframe = 0;
> > > +int ctts_index = 0;
> > > +int 

[FFmpeg-devel] [PATCH] vf_drawtext: support to set word spacing while drawing text. ./ffmpeg -i input -vf drawtext="word_spacing=10:textfile=1.txt:fontfile=demo.ttf" -f flv 1.flv could set word spacin

[efren yang]

Signed-off-by: efren yang 
---
 libavfilter/vf_drawtext.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/libavfilter/vf_drawtext.c b/libavfilter/vf_drawtext.c
index f6151443bb..137ae5891e 100644
--- a/libavfilter/vf_drawtext.c
+++ b/libavfilter/vf_drawtext.c
@@ -162,6 +162,7 @@ typedef struct DrawTextContext {
 unsigned int default_fontsize;  ///< default font size to use
 
 int line_spacing;   ///< lines spacing in pixels
+int word_spacing;   ///< word spacing in pixels
 short int draw_box; ///< draw box around text - true or false
 int boxborderw; ///< box border width
 int use_kerning;///< font kerning is used - true/false
@@ -214,6 +215,7 @@ static const AVOption drawtext_options[]= {
 {"box", "set box",  OFFSET(draw_box),   
AV_OPT_TYPE_BOOL,   {.i64=0}, 0,1   , FLAGS},
 {"boxborderw",  "set box border width", OFFSET(boxborderw), 
AV_OPT_TYPE_INT,{.i64=0}, INT_MIN,  INT_MAX , FLAGS},
 {"line_spacing",  "set line spacing in pixels", OFFSET(line_spacing),   
AV_OPT_TYPE_INT,{.i64=0}, INT_MIN,  INT_MAX,FLAGS},
+{"word_spacing",  "set word spacing in pixels", OFFSET(word_spacing),   
AV_OPT_TYPE_INT,{ .i64 = 0 }, INT_MIN,  INT_MAX,FLAGS },
 {"fontsize","set font size",OFFSET(fontsize_expr),  
AV_OPT_TYPE_STRING, {.str=NULL},  CHAR_MIN, CHAR_MAX , FLAGS},
 {"x",   "set x expression", OFFSET(x_expr), 
AV_OPT_TYPE_STRING, {.str="0"},   CHAR_MIN, CHAR_MAX, FLAGS},
 {"y",   "set y expression", OFFSET(y_expr), 
AV_OPT_TYPE_STRING, {.str="0"},   CHAR_MIN, CHAR_MAX, FLAGS},
@@ -1374,6 +1376,7 @@ static int draw_text(AVFilterContext *ctx, AVFrame *frame,
 s->positions[i].y = y - glyph->bitmap_top + y_max;
 if (code == '\t') x  = (x / s->tabsize + 1)*s->tabsize;
 else  x += glyph->advance;
+x += s->word_spacing;
 }
 
 max_text_line_w = FFMAX(x, max_text_line_w);
-- 
2.13.0.windows.1



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

[FFmpeg-devel] [PATCH] support set words' space

[efren yang]

0001-support-set-words-space.patch
Description: Binary data
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] Webp support

[Lou Logan]

On Tue, Jul 18, 2017, at 04:00 AM, GT Wang wrote:
> Hello dev,
> 
> ffmpeg not support webp right ?

FFmpeg natively supports WebP decoding, demuxing, and muxing. FFmpeg can
also encode  WebP if configured with --enable-libwebp.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] Webp support

[GT Wang]

Hello dev,

ffmpeg not support webp right ?

In the future, ffmpeg will support this format ?

Thanks.
-- 
GT Wang
Email：ili...@gmail.com
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [mov] Fix trampling of ctts during seeks when sidx support is enabled.

[Michael Niedermayer]

On Tue, Jul 18, 2017 at 11:49:26AM -0700, Dale Curtis wrote:
> Updated patch that fixes other ctts modification code to use the new
> ctts_allocated_size value; I've verified this passes fate.
> 
> - dale
> 
> On Tue, Jul 18, 2017 at 9:53 AM, Dale Curtis 
> wrote:
> 
> > Resending as it's own message per contribution rules. I've also attached
> > the patch in case the formatting gets trashed.
> >
> > When sidx box support is enabled, the code will skip reading all
> > trun boxes (each containing ctts entries for samples inthat box).
> >
> > If seeks are attempted before all ctts values are known, the old
> > code would dump ctts entries into the wrong location. These are
> > then used to compute pts values which leads to out of order and
> > incorrectly timestamped packets.
> >
> > This patch fixes ctts processing by always using the index returned
> > by av_add_index_entry() as the ctts_data index. When the index gains
> > new entries old values are reshuffled as appropriate.
> >
> > This approach makes sense since the mov demuxer is already relying
> > on the mapping of AVIndex entries to samples for correct demuxing.
> >
> > Notes for future improvement:
> > Probably there are other boxes (stts, stsc, etc) that are impacted
> > by this issue... this patch only attempts to fix ctts since it
> > completely breaks packet timestamping.
> >
> > This patch continues using an array for the ctts data, which is not
> > the most ideal given the rearrangement that needs to happen (via
> > memmove as new entries are read in). Ideally AVIndex and the ctts
> > data would be set-type structures so addition is always worst case
> > O(lg(n)) instead of the O(n^2) that exists now; this slowdown is
> > noticeable during seeks.
> >
> > Additionally since ctts samples from trun boxes always have a count
> > of 1, there's probably an opportunity to avoid the post-seek fixup
> > that iterates O(n) over all samples with an O(1) when no non-1 count
> > samples are present.
> >
> > Signed-off-by: Dale Curtis 
> > ---
> >  libavformat/isom.h |  1 +
> >  libavformat/mov.c  | 46 +++---
> >  2 files changed, 32 insertions(+), 15 deletions(-)
> >
> > diff --git a/libavformat/isom.h b/libavformat/isom.h
> > index ff009b0896..fdd98c28f5 100644
> > --- a/libavformat/isom.h
> > +++ b/libavformat/isom.h
> > @@ -137,6 +137,7 @@ typedef struct MOVStreamContext {
> >  unsigned int stts_count;
> >  MOVStts *stts_data;
> >  unsigned int ctts_count;
> > +unsigned int ctts_allocated_size;
> >  MOVStts *ctts_data;
> >  unsigned int stsc_count;
> >  MOVStsc *stsc_data;
> > diff --git a/libavformat/mov.c b/libavformat/mov.c
> > index 63f84be782..412290b435 100644
> > --- a/libavformat/mov.c
> > +++ b/libavformat/mov.c
> > @@ -4297,11 +4297,6 @@ static int mov_read_trun(MOVContext *c, AVIOContext
> > *pb, MOVAtom atom)
> >  }
> >  if ((uint64_t)entries+sc->ctts_count >=
> > UINT_MAX/sizeof(*sc->ctts_data))
> >  return AVERROR_INVALIDDATA;
> > -if ((err = av_reallocp_array(>ctts_data, entries +
> > sc->ctts_count,
> > - sizeof(*sc->ctts_data))) < 0) {
> > -sc->ctts_count = 0;
> > -return err;
> > -}
> >  if (flags & MOV_TRUN_DATA_OFFSET)data_offset=
> > avio_rb32(pb);
> >  if (flags & MOV_TRUN_FIRST_SAMPLE_FLAGS) first_sample_flags =
> > avio_rb32(pb);
> >  dts= sc->track_end - sc->time_offset;
> > @@ -4312,26 +4307,28 @@ static int mov_read_trun(MOVContext *c,
> > AVIOContext *pb, MOVAtom atom)
> >  unsigned sample_size = frag->size;
> >  int sample_flags = i ? frag->flags : first_sample_flags;
> >  unsigned sample_duration = frag->duration;
> > +unsigned ctts_duration = 0;
> >  int keyframe = 0;
> > +int ctts_index = 0;
> > +int old_nb_index_entries = st->nb_index_entries;
> >
> >  if (flags & MOV_TRUN_SAMPLE_DURATION) sample_duration =
> > avio_rb32(pb);
> >  if (flags & MOV_TRUN_SAMPLE_SIZE) sample_size =
> > avio_rb32(pb);
> >  if (flags & MOV_TRUN_SAMPLE_FLAGS)sample_flags=
> > avio_rb32(pb);
> > -sc->ctts_data[sc->ctts_count].count = 1;
> > -sc->ctts_data[sc->ctts_count].duration = (flags &
> > MOV_TRUN_SAMPLE_CTS) ?
> > -  avio_rb32(pb) : 0;
> > -mov_update_dts_shift(sc, sc->ctts_data[sc->ctts_count].duration);
> > +if (flags & MOV_TRUN_SAMPLE_CTS)  ctts_duration   =
> > avio_rb32(pb);
> > +
> > +mov_update_dts_shift(sc, ctts_duration);
> >  if (frag->time != AV_NOPTS_VALUE) {
> >  if (c->use_mfra_for == FF_MOV_FLAG_MFRA_PTS) {
> >  int64_t pts = frag->time;
> >  av_log(c->fc, AV_LOG_DEBUG, "found frag time %"PRId64
> >  " sc->dts_shift %d ctts.duration %d"
> > 

Re: [FFmpeg-devel] [PATCHv2 1/2] avdevice/decklink_dec: add support for decoding teletext from 10bit ancillary data

[Reimar Döffinger]

On 19.07.2017, at 18:48, Marton Balint  wrote:

> 
> On Wed, 19 Jul 2017, John Warburton wrote:
> 
>> On Tue, Jul 18, 2017 at 6:10 PM, Marton Balint  wrote:
>>> On Sat, 8 Jul 2017, Marton Balint wrote:
>>> 
 This also add supports for 4K DeckLink cards because they always output the
 ancillary data in 10-bit.
 
 v2:
 - only try teletext decoding for 576i PAL mode
 - some comments as requested by Aaron Levinson
 
 Signed-off-by: Marton Balint 
>>> 
>>> Applied the series, thanks for all the comments.
>> 
>> Since this patch was applied, the mingw-w64 compiler, gcc version
>> 6.4.1, fails to link shared library avdevice-57.dll, giving the
>> following error. It is as if the const uint8_t ff_reverse[256] that is
>> found in libavutil/reverse.c somehow isn't being discovered by the
>> linker. I'm afraid my knowledge beyond this point is zero.
>> 
>> libavdevice/decklink_dec.o:decklink_dec.cpp:(.rdata$.refptr.ff_reverse[.refptr.ff_reverse]+0x0):
>> undefined reference to `ff_reverse'
>> collect2: error: ld returned 1 exit status
>> ffbuild/library.mak:101: recipe for target 'libavdevice/avdevice-57.dll' 
>> failed
>> make: *** [libavdevice/avdevice-57.dll] Error 1
>> Build failure. Please see error messages above.
> 
> Hmmm. Does adding ff_reverse to the exported symbols in libavutil/libavutil.v 
> fix the problem? Or maybe simply renaming every instance of ff_reverse in the 
> codebase to avpriv_reverse?

Variables/arrays cannot be reliably exported from dynamic libraries and doing 
so should be avoided.
Even on Linux that leads to "fun" things like copy relocations you really don't 
want.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] Add FITS Demuxer

[Reimar Döffinger]

On 19.07.2017, at 12:03, Nicolas George  wrote:
> What I do insist on, is this:
> 
> Look at the find_size() function in this patch:
> https://ffmpeg.org/pipermail/ffmpeg-devel/2017-July/213076.html
> 
> Then look at the fits_read_header() in this patch:
> https://ffmpeg.org/pipermail/ffmpeg-devel/2017-July/213061.html
> 
> They are the same. One works on an AVIOContext using read operations,
> the other works on a buffer using pointer arithmetic, but the logic is
> the same. And it is not a trivial logic, here, we are talking about
> dozens of lines of code.

Ok, I think it is possible to use the same code for those, for example by doing 
this:
- in the demuxer (or parser, but that is harder because you cannot just read 
what you need but have to deal with the data as it is provided), get data until 
the end of the header.
The end of the header detection would be somewhat duplicated, but should be 
fairly trivial.
- Then use a function that takes such a buffer and returns a AVDictionary with 
name/value pairs. The decoder and demuxer can then each decide what they want 
to do with them.

There is one issue at least though: for files with very large meta-data/header 
this would almost double memory usage in the demuxer due to having copies in 
the dictionary.
There is also to me the issue, while both parse the same things, what these 
functions do is not at all the same semantically, at least currently.
The demuxer only parses a select few keywords with well-known format and as a 
result can e.g, use sscanf directly (not that I like using sscanf personally).
The decoder one builts a metadata dictionary and thus needs a lot of 
special-case handling like proper parsing, handling possibly new keywords, 
deciding what to do with garbage (instead of just skipping), handling escaping 
for the values, ...
Personally if it was my job to get this in, I would start by simplifying at 
least one of those functions while making sure to have proper bounds checking 
and error handling to see where the complexity really lies and how complex the 
problem actually is compared to how the first try solution looks.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] Add FITS Demuxer

[Reimar Döffinger]

On 19.07.2017, at 12:03, Nicolas George  wrote:

> Le decadi 30 messidor, an CCXXV, Rostislav Pehlivanov a écrit :
> 
>> I think the image2 demuxer shouldn't handle this type of junk/useless data
>> filtering and would rather see a separate demuxer like the current patch
>> which deals with crap.
> 
> I am somewhat confused by your statement, because in my mind, this is
> exactly the purpose and task of the image2(pipe) demuxers.
> 
> The image2pipe demuxer reads the input stream, calls a parser to find in
> it the size of the images and returns them as individual packets. Note
> that the parsers are not part of the image2(pipe) demuxers, they are
> separate entities of their own, each specific to one image format.
> 
> I do not know what the image2pipe demuxer would be good for, if not for
> that. Or did I miss something?

I am a bit unclear on the details, but my memory:
Well, they work better (only?) if the images are completely independent.
I am not sure this is entirely the case here, for example the first image would 
have a different header it looks like from the muxer patch.
There is also the question: how would the encoding work?
Because if encoding will be using a muxer, having things symmetric by having a 
demuxer is an advantage.

> Good design and maintenance require a single implementation.

I don't think we have the right frameworks for that. Other cases like the MPEG 
video format parsers and decoders also duplicate that kind of code.
There might be some ways though, I am mostly thinking of an iterative function 
that is called with a pointer to each 80 byte header buffer and updates a state 
structure with the info it extracts from there. Would still get messy if the 
decoder needs quite different data than the demuxer.
I have not yet checked how similar these functions actually are.

> I think the best and simplest way of achieving that is to have both the
> parser and the decoder call the same function. And I think the simplest
> way of implementing it is to make a parser and rely on image2pipe.

Parsers work best when parsing requires very limited context.
My impression is that there is no fixed maximum header size, which can easily 
make things really painful in a parser.

Also considering the complexity: I suspect that the header parsing can be 
simplified a good bit, and maybe some common helper functions extracted.
I wouldn't insist on avoiding code duplication when trying to share it might 
actually result in more complicated code. But it probably needs some thinking 
to figure out what makes sense.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH] Add tonemap filter

[Vittorio Giovara]

Based off mpv automatic tonemapping capabilities.

Signed-off-by: Vittorio Giovara 
---
Fixed documentation build.
Vittorio

 doc/filters.texi | 106 
 libavfilter/Makefile |   1 +
 libavfilter/allfilters.c |   1 +
 libavfilter/vf_tonemap.c | 310 +++
 4 files changed, 418 insertions(+)
 create mode 100644 libavfilter/vf_tonemap.c

diff --git a/doc/filters.texi b/doc/filters.texi
index 930ca4cfab..f1a9d3ab93 100644
--- a/doc/filters.texi
+++ b/doc/filters.texi
@@ -14295,6 +14295,111 @@ Vertical low-pass filtering can only be enabled for 
@option{mode}
 
 @end table
 
+@section tonemap
+Tone map colors from different dynamic ranges.
+
+This filter expects data in single precision floating point, as it needs to
+operate on (and can output) out-of-range values. Another filter, such as
+@ref{zscale}, is needed to convert the resulting frame to a usable format.
+
+The tonemapping algorithms implemented only work on linear light, so input
+data should be linearized beforehand (and possibly correctly tagged).
+
+@example
+ffmpeg -i INPUT -vf 
zscale=transfer=linear,tonemap=clip,zscale=transfer=bt709,format=yuv420p OUTPUT
+@end example
+
+@subsection Options
+The filter accepts the following options.
+
+@table @option
+@item tonemap
+Set the tone map algorithm to use.
+
+Possible values are:
+@table @var
+@item none
+Do not apply any tone map, only desaturate overbright pixels.
+
+@item clip
+Hard-clip any out-of-range values. Use it for perfect color accuracy for
+in-range values, while distorting out-of-range values.
+
+@item linear
+Stretch the entire reference gamut to a linear multiple of the display.
+
+@item gamma
+Fit a logarithmic transfer between the tone curves.
+
+@item reinhard
+Preserve overall image brightness with a simple curve, using nonlinear
+contrast, which results in flattening details and degrading color accuracy.
+
+@item hable
+Peserve both dark and bright details better than @var{reinhard}, at the cost
+of slightly darkening everything. Use it when detail preservation is more
+important than color and brightness accuracy.
+
+@item mobius
+Smoothly map out-of-range values, while retaining contrast and colors for
+in-range material as much as possible. Use it when color accuracy is more
+important than detail preservation.
+@end table
+
+Default is none.
+
+@item param
+Tune the tone mapping algorithm.
+
+This affects the following algorithms:
+@table @var
+@item none
+Ignored.
+
+@item linear
+Specifies the scale factor to use while stretching.
+Default to 1.0.
+
+@item gamma
+Specifies the exponent of the function.
+Default to 1.8.
+
+@item clip
+Specify an extra linear coefficient to multiply into the signal before 
clipping.
+Default to 1.0.
+
+@item reinhard
+Specify the local contrast coefficient at the display peak.
+Default to 0.5, which means that in-gamut values will be about half as bright
+as when clipping.
+
+@item hable
+Ignored.
+
+@item mobius
+Specify the transition point from linear to mobius transform. Every value
+below this point is guaranteed to be mapped 1:1. The higher the value, the
+more accurate the result will be, at the cost of losing bright details.
+Default to 0.3, which due to the steep initial slope still preserves in-range
+colors fairly accurately.
+@end table
+
+@item desat
+Apply desaturation for highlights that exceed this level of brightness. The
+higher the parameter, the more color information will be preserved. This
+setting helps prevent unnaturally blown-out colors for super-highlights, by
+(smoothly) turning into white instead. This makes images feel more natural,
+at the cost of reducing information about out-of-range colors.
+
+The default of 2.0 is somewhat conservative and will mostly just apply to
+skies or directly sunlit surfaces. A setting of 0.0 disables this option.
+
+@item peak
+Override signal/nominal/reference peak with this value. Useful when the
+embedded peak information in display metadata is not reliable or when tone
+mapping from a lower range to a higher range.
+@end table
+
 @section transpose
 
 Transpose rows with columns in the input video and optionally flip it.
@@ -15458,6 +15563,7 @@ 
zoompan=z='min(max(zoom,pzoom)+0.0015,1.5)':d=1:x='iw/2-(iw/zoom/2)':y='ih/2-(ih
 @end example
 @end itemize
 
+@anchor{zscale}
 @section zscale
 Scale (resize) the input video, using the z.lib library:
 https://github.com/sekrit-twc/zimg.
diff --git a/libavfilter/Makefile b/libavfilter/Makefile
index f023a0d5d6..0ada5d77b5 100644
--- a/libavfilter/Makefile
+++ b/libavfilter/Makefile
@@ -310,6 +310,7 @@ OBJS-$(CONFIG_THRESHOLD_FILTER)  += 
vf_threshold.o
 OBJS-$(CONFIG_THUMBNAIL_FILTER)  += vf_thumbnail.o
 OBJS-$(CONFIG_TILE_FILTER)   += vf_tile.o
 OBJS-$(CONFIG_TINTERLACE_FILTER) += vf_tinterlace.o
+OBJS-$(CONFIG_TONEMAP_FILTER)+= vf_tonemap.o
 

[FFmpeg-devel] [PATCH] avcodec/dca: remove GetBitContext usage from avpriv_dca_parse_core_frame_header()

[James Almer]

This prevents potential ABI issues with GetBitContext.

Signed-off-by: James Almer 
---
 libavcodec/dca.c| 12 +++-
 libavcodec/dca.h|  7 +--
 libavcodec/dca_core.c   |  2 +-
 libavcodec/dca_parser.c |  4 +---
 libavformat/dtsdec.c|  4 +---
 5 files changed, 19 insertions(+), 10 deletions(-)

diff --git a/libavcodec/dca.c b/libavcodec/dca.c
index 39f8f3d81c..307b21471e 100644
--- a/libavcodec/dca.c
+++ b/libavcodec/dca.c
@@ -88,7 +88,7 @@ int avpriv_dca_convert_bitstream(const uint8_t *src, int 
src_size, uint8_t *dst,
 }
 }
 
-int avpriv_dca_parse_core_frame_header(GetBitContext *gb, DCACoreFrameHeader 
*h)
+int ff_dca_parse_core_frame_header(DCACoreFrameHeader *h, GetBitContext *gb)
 {
 if (get_bits_long(gb, 32) != DCA_SYNCWORD_CORE_BE)
 return DCA_PARSE_ERROR_SYNC_WORD;
@@ -145,3 +145,13 @@ int avpriv_dca_parse_core_frame_header(GetBitContext *gb, 
DCACoreFrameHeader *h)
 h->dn_code = get_bits(gb, 4);
 return 0;
 }
+
+int avpriv_dca_parse_core_frame_header(DCACoreFrameHeader *h, uint8_t *buf, 
int size)
+{
+GetBitContext gb;
+
+if (init_get_bits8(, buf, size) < 0)
+return DCA_PARSE_ERROR_INVALIDDATA;
+
+return ff_dca_parse_core_frame_header(h, );
+}
diff --git a/libavcodec/dca.h b/libavcodec/dca.h
index cf6204e554..172c965b3b 100644
--- a/libavcodec/dca.h
+++ b/libavcodec/dca.h
@@ -45,7 +45,8 @@ enum DCAParseError {
 DCA_PARSE_ERROR_SAMPLE_RATE = -6,
 DCA_PARSE_ERROR_RESERVED_BIT= -7,
 DCA_PARSE_ERROR_LFE_FLAG= -8,
-DCA_PARSE_ERROR_PCM_RES = -9
+DCA_PARSE_ERROR_PCM_RES = -9,
+DCA_PARSE_ERROR_INVALIDDATA = -10,
 };
 
 typedef struct DCACoreFrameHeader {
@@ -212,6 +213,8 @@ int avpriv_dca_convert_bitstream(const uint8_t *src, int 
src_size, uint8_t *dst,
  * Parse and validate core frame header
  * @return 0 on success, negative DCA_PARSE_ERROR_ code on failure
  */
-int avpriv_dca_parse_core_frame_header(GetBitContext *gb, DCACoreFrameHeader 
*h);
+int avpriv_dca_parse_core_frame_header(DCACoreFrameHeader *h, uint8_t *buf, 
int size);
+
+int ff_dca_parse_core_frame_header(DCACoreFrameHeader *h, GetBitContext *gb);
 
 #endif /* AVCODEC_DCA_H */
diff --git a/libavcodec/dca_core.c b/libavcodec/dca_core.c
index 3add9f812b..6cb1f30a3c 100644
--- a/libavcodec/dca_core.c
+++ b/libavcodec/dca_core.c
@@ -82,7 +82,7 @@ static void get_array(GetBitContext *s, int32_t *array, int 
size, int n)
 static int parse_frame_header(DCACoreDecoder *s)
 {
 DCACoreFrameHeader h = { 0 };
-int err = avpriv_dca_parse_core_frame_header(>gb, );
+int err = ff_dca_parse_core_frame_header(, >gb);
 
 if (err < 0) {
 switch (err) {
diff --git a/libavcodec/dca_parser.c b/libavcodec/dca_parser.c
index 7e99b16bf0..11ddb8f188 100644
--- a/libavcodec/dca_parser.c
+++ b/libavcodec/dca_parser.c
@@ -263,9 +263,7 @@ static int dca_parse_params(DCAParseContext *pc1, const 
uint8_t *buf,
 if ((ret = avpriv_dca_convert_bitstream(buf, DCA_CORE_FRAME_HEADER_SIZE,
 hdr, DCA_CORE_FRAME_HEADER_SIZE)) 
< 0)
 return ret;
-if ((ret = init_get_bits8(, hdr, ret)) < 0)
-return ret;
-if (avpriv_dca_parse_core_frame_header(, ) < 0)
+if (avpriv_dca_parse_core_frame_header(, hdr, ret) < 0)
 return AVERROR_INVALIDDATA;
 
 *duration = h.npcmblocks * DCA_PCMBLOCK_SAMPLES;
diff --git a/libavformat/dtsdec.c b/libavformat/dtsdec.c
index 6e0048f9bc..a3e52cd596 100644
--- a/libavformat/dtsdec.c
+++ b/libavformat/dtsdec.c
@@ -101,9 +101,7 @@ static int dts_probe(AVProbeData *p)
 if ((ret = avpriv_dca_convert_bitstream(buf - 2, 
DCA_CORE_FRAME_HEADER_SIZE,
 hdr, 
DCA_CORE_FRAME_HEADER_SIZE)) < 0)
 continue;
-if (init_get_bits8(, hdr, ret) < 0)
-continue;
-if (avpriv_dca_parse_core_frame_header(, ) < 0)
+if (avpriv_dca_parse_core_frame_header(, hdr, ret) < 0)
 continue;
 
 marker += 4 * h.sr_code;
-- 
2.13.3

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

[FFmpeg-devel] [PATCH] libavdevice: fix ff_reverse shared build breakage with decklink_dec

[Marton Balint]

Similar to libavcodec, duplicate ff_reverse table in case of a shared build.

Signed-off-by: Marton Balint 
---
 libavdevice/Makefile  | 1 +
 libavdevice/reverse.c | 1 +
 2 files changed, 2 insertions(+)
 create mode 100644 libavdevice/reverse.c

diff --git a/libavdevice/Makefile b/libavdevice/Makefile
index c055d6718d..384a8966b5 100644
--- a/libavdevice/Makefile
+++ b/libavdevice/Makefile
@@ -40,6 +40,7 @@ OBJS-$(CONFIG_PULSE_OUTDEV)  += pulse_audio_enc.o 
\
 pulse_audio_common.o
 OBJS-$(CONFIG_QTKIT_INDEV)   += qtkit.o
 OBJS-$(CONFIG_SDL2_OUTDEV)   += sdl2.o
+OBJS-$(CONFIG_SHARED)+= reverse.o
 OBJS-$(CONFIG_SNDIO_INDEV)   += sndio_dec.o sndio.o
 OBJS-$(CONFIG_SNDIO_OUTDEV)  += sndio_enc.o sndio.o
 OBJS-$(CONFIG_V4L2_INDEV)+= v4l2.o v4l2-common.o timefilter.o
diff --git a/libavdevice/reverse.c b/libavdevice/reverse.c
new file mode 100644
index 00..440badaf34
--- /dev/null
+++ b/libavdevice/reverse.c
@@ -0,0 +1 @@
+#include "libavutil/reverse.c"
-- 
2.12.3

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

Re: [FFmpeg-devel] [PATCH] avcodec/dca: remove GetBitContext usage from avpriv_dca_parse_core_frame_header()

[Michael Niedermayer]

On Wed, Jul 19, 2017 at 01:57:21AM -0300, James Almer wrote:
> This prevents ABI issues with GetBitContext.
> 
> Signed-off-by: James Almer 
> ---
>  libavcodec/dca.c| 15 ++-
>  libavcodec/dca.h|  7 +--
>  libavcodec/dca_core.c   |  2 +-
>  libavcodec/dca_parser.c |  4 +---
>  libavformat/dtsdec.c|  4 +---
>  5 files changed, 22 insertions(+), 10 deletions(-)

Breasks tickets//1747/dts.wav

http://trac.ffmpeg.org/raw-attachment/ticket/1747/dts.wav

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

Many that live deserve death. And some that die deserve life. Can you give
it to them? Then do not be too eager to deal out death in judgement. For
even the very wise cannot see all ends. -- Gandalf


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

[FFmpeg-devel] [PATCH] fate: add vf_overlay test for main source with alpha channel

[Peter Große]

Signed-off-by: Peter Große 
---
Updated version of the test.

I was able to reproduce your checksums only after removing

  --disable-optimizations --disable-mmx --disable-stripping

from my configure command. I thought optimizations should have no
impact on the result?!

 tests/fate/filter-video.mak  |  5 +
 tests/ref/fate/filter-overlay-main-alpha | 15 +++
 2 files changed, 20 insertions(+)
 create mode 100644 tests/ref/fate/filter-overlay-main-alpha

diff --git a/tests/fate/filter-video.mak b/tests/fate/filter-video.mak
index 53fc7a6528..b30d5b7b7c 100644
--- a/tests/fate/filter-video.mak
+++ b/tests/fate/filter-video.mak
@@ -351,6 +351,11 @@ FATE_FILTER_SAMPLES-$(call ALLYES, MATROSKA_DEMUXER 
OVERLAY_FILTER H264_DECODER
 fate-filter-overlay-dvdsub-2397: tests/data/filtergraphs/overlay-dvdsub-2397
 fate-filter-overlay-dvdsub-2397: CMD = framecrc -flags bitexact -i 
$(TARGET_SAMPLES)/filter/242_4.mkv -filter_complex_script 
$(TARGET_PATH)/tests/data/filtergraphs/overlay-dvdsub-2397 -c:a copy
 
+FATE_FILTER_SAMPLES-$(call ALLYES, MXF_DEMUXER OVERLAY_FILTER DNXHD_DECODER 
PNG_DECODER) += fate-filter-overlay-main-alpha
+fate-filter-overlay-main-alpha: SRC = $(TARGET_SAMPLES)/mxf/track_01_v02.mxf
+fate-filter-overlay-main-alpha: OVERLAY = $(TARGET_SAMPLES)/png1/lena-rgba.png
+fate-filter-overlay-main-alpha: CMD = framecrc -flags bitexact -i $(SRC) 
-filter_complex "movie='$(OVERLAY)'[logo];[v:0][logo]overlay" -an
+
 FATE_FILTER_HQX-$(call ALLYES, IMAGE2_DEMUXER PNG_DECODER HQX_FILTER) = 
fate-filter-hq2x fate-filter-hq3x fate-filter-hq4x
 FATE_FILTER_SAMPLES-yes += $(FATE_FILTER_HQX-yes)
 fate-filter-hq2x: CMD = framecrc -i $(TARGET_SAMPLES)/filter/pixelart%d.png 
-vf hqx=2 -pix_fmt bgra
diff --git a/tests/ref/fate/filter-overlay-main-alpha 
b/tests/ref/fate/filter-overlay-main-alpha
new file mode 100644
index 00..95bb59ea13
--- /dev/null
+++ b/tests/ref/fate/filter-overlay-main-alpha
@@ -0,0 +1,15 @@
+#tb 0: 1001/24000
+#media_type 0: video
+#codec_id 0: rawvideo
+#dimensions 0: 1280x720
+#sar 0: 1/1
+0,  0,  0,1,  2304000, 0x49ef8134
+0,  1,  1,1,  2304000, 0x49ef8134
+0,  2,  2,1,  2304000, 0x49ef8134
+0,  3,  3,1,  2304000, 0x49ef8134
+0,  4,  4,1,  2304000, 0x49ef8134
+0,  5,  5,1,  2304000, 0x49ef8134
+0,  6,  6,1,  2304000, 0x49ef8134
+0,  7,  7,1,  2304000, 0x49ef8134
+0,  8,  8,1,  2304000, 0x49ef8134
+0,  9,  9,1,  2304000, 0x49ef8134
-- 
2.13.0

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

Re: [FFmpeg-devel] tsan warning about a data race in libavcodec/h264_direct.c

[Ronald S. Bultje]

Hi Wan-Teh,

On Wed, Jul 19, 2017 at 2:31 PM, Wan-Teh Chang  wrote:

> Hi Ronald,
>
> Thank you for the reply.
>
> On Wed, Jul 19, 2017 at 8:56 AM, Ronald S. Bultje 
> wrote:
> > Hi,
> >
> > On Wed, Jul 19, 2017 at 12:26 AM, Wan-Teh Chang <
> > wtc-at-google@ffmpeg.org> wrote:
> >
> >> WARNING: ThreadSanitizer: data race (pid=116081)
> >>   Read of size 4 at 0x7b720118 by thread T3 (mutexes: write M2239):
> >> #0 pred_temp_direct_motion ffmpeg/libavcodec/h264_direct.c:505:9
> >> (ffmpeg+0x1159c60)
> >>
> > [..]
> >
> >>   Previous write of size 4 at 0x7b720118 by thread T1 (mutexes:
> >> write M2234):
> >> #0 ff_h264_decode_mb_cabac ffmpeg/libavcodec/h264_cabac.c:2386:31
> >> (ffmpeg+0x1475e0a)
> >
> > I believe this is temporal motion vector prediction (so MV from frame 1
> is
> > used as a MV predictor in frame 2). The easy solution here is to wait for
> > the frame to have completed reconstruction of that block (which fills in
> > that mb_type) before accessing the predictor.
>
> In libavcodec/h264_direct.c, there is already an
> await_reference_mb_row() call before the read of
> sl->ref_list[1][0].parent->mb_type[mb_xy] at line 505:
>
> 487 static void pred_temp_direct_motion(const H264Context *const h,
> H264SliceContext *sl,
> 488 int *mb_type)
> 489 {
> ...
> 501
> 502 await_reference_mb_row(h, >ref_list[1][0],
> 503sl->mb_y + !!IS_INTERLACED(*mb_type));
> 504
> 505 if (IS_INTERLACED(sl->ref_list[1][0].parent->mb_type[mb_xy]))
> { // AFL/AFR/FR/FL -> AFL/FL
>
> This seems like the wait you suggested, but I guess it is not?


Yes, but clearly it's not doing the correct thing. :-). The ""fun"" in
these type of issues is to figure out why not. ;-).

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

Re: [FFmpeg-devel] tsan warning about a data race in libavcodec/h264_direct.c

[Wan-Teh Chang]

Hi Ronald,

Thank you for the reply.

On Wed, Jul 19, 2017 at 8:56 AM, Ronald S. Bultje  wrote:
> Hi,
>
> On Wed, Jul 19, 2017 at 12:26 AM, Wan-Teh Chang <
> wtc-at-google@ffmpeg.org> wrote:
>
>> WARNING: ThreadSanitizer: data race (pid=116081)
>>   Read of size 4 at 0x7b720118 by thread T3 (mutexes: write M2239):
>> #0 pred_temp_direct_motion ffmpeg/libavcodec/h264_direct.c:505:9
>> (ffmpeg+0x1159c60)
>>
> [..]
>
>>   Previous write of size 4 at 0x7b720118 by thread T1 (mutexes:
>> write M2234):
>> #0 ff_h264_decode_mb_cabac ffmpeg/libavcodec/h264_cabac.c:2386:31
>> (ffmpeg+0x1475e0a)
>
> I believe this is temporal motion vector prediction (so MV from frame 1 is
> used as a MV predictor in frame 2). The easy solution here is to wait for
> the frame to have completed reconstruction of that block (which fills in
> that mb_type) before accessing the predictor.

In libavcodec/h264_direct.c, there is already an
await_reference_mb_row() call before the read of
sl->ref_list[1][0].parent->mb_type[mb_xy] at line 505:

487 static void pred_temp_direct_motion(const H264Context *const h,
H264SliceContext *sl,
488 int *mb_type)
489 {
...
501
502 await_reference_mb_row(h, >ref_list[1][0],
503sl->mb_y + !!IS_INTERLACED(*mb_type));
504
505 if (IS_INTERLACED(sl->ref_list[1][0].parent->mb_type[mb_xy]))
{ // AFL/AFR/FR/FL -> AFL/FL

This seems like the wait you suggested, but I guess it is not?

I also found that there is a similar tsan warning about a data race
between libavcodec/h264_direct.c and libavcodec/h264_cavlc.c:

WARNING: ThreadSanitizer: data race (pid=115630)
  Read of size 4 at 0x7b730118 by thread T2 (mutexes: write M2283):
#0 pred_temp_direct_motion ffmpeg/libavcodec/h264_direct.c:505:9
(ffmpeg+0x1159c60)
#1 ff_h264_pred_direct_motion ffmpeg/libavcodec/h264_direct.c:727
(ffmpeg+0x1159c60)
#2 ff_h264_decode_mb_cavlc ffmpeg/libavcodec/h264_cavlc.c:856:17
(ffmpeg+0x11520b2)
#3 decode_slice ffmpeg/libavcodec/h264_slice.c:2641:19 (ffmpeg+0x11936ea)
#4 ff_h264_execute_decode_slices
ffmpeg/libavcodec/h264_slice.c:2748:15 (ffmpeg+0x1192377)
#5 decode_nal_units ffmpeg/libavcodec/h264dec.c:716:27 (ffmpeg+0x792022)
#6 h264_decode_frame ffmpeg/libavcodec/h264dec.c:1006 (ffmpeg+0x792022)
#7 frame_worker_thread ffmpeg/libavcodec/pthread_frame.c:201:21
(ffmpeg+0xae56cc)

  Previous write of size 4 at 0x7b730118 by thread T4 (mutexes:
write M2289):
#0 ff_h264_decode_mb_cavlc ffmpeg/libavcodec/h264_cavlc.c:1095:31
(ffmpeg+0x114f2be)
#1 decode_slice ffmpeg/libavcodec/h264_slice.c:2641:19 (ffmpeg+0x11936ea)
#2 ff_h264_execute_decode_slices
ffmpeg/libavcodec/h264_slice.c:2748:15 (ffmpeg+0x1192377)
#3 decode_nal_units ffmpeg/libavcodec/h264dec.c:716:27 (ffmpeg+0x792022)
#4 h264_decode_frame ffmpeg/libavcodec/h264dec.c:1006 (ffmpeg+0x792022)
#5 frame_worker_thread ffmpeg/libavcodec/pthread_frame.c:201:21
(ffmpeg+0xae56cc)

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

Re: [FFmpeg-devel] [PATCH] fate: add vf_overlay test for main source with alpha channel

[Michael Niedermayer]

On Tue, Jul 18, 2017 at 05:03:52PM +0200, Peter Große wrote:
> Signed-off-by: Peter Große 
> ---
>  tests/fate/filter-video.mak  |  5 +
>  tests/ref/fate/filter-overlay-main-alpha | 15 +++
>  2 files changed, 20 insertions(+)
>  create mode 100644 tests/ref/fate/filter-overlay-main-alpha
> 
> diff --git a/tests/fate/filter-video.mak b/tests/fate/filter-video.mak
> index 9186593c10..cbfee449b6 100644
> --- a/tests/fate/filter-video.mak
> +++ b/tests/fate/filter-video.mak
> @@ -341,6 +341,11 @@ FATE_FILTER_SAMPLES-$(call ALLYES, MATROSKA_DEMUXER 
> OVERLAY_FILTER H264_DECODER
>  fate-filter-overlay-dvdsub-2397: tests/data/filtergraphs/overlay-dvdsub-2397
>  fate-filter-overlay-dvdsub-2397: CMD = framecrc -flags bitexact -i 
> $(TARGET_SAMPLES)/filter/242_4.mkv -filter_complex_script 
> $(TARGET_PATH)/tests/data/filtergraphs/overlay-dvdsub-2397 -c:a copy
>  
> +FATE_FILTER_SAMPLES-$(call ALLYES, MXF_DEMUXER OVERLAY_FILTER DNXHD_DECODER 
> PNG_DECODER) += fate-filter-overlay-main-alpha
> +fate-filter-overlay-main-alpha: SRC = $(TARGET_SAMPLES)/mxf/track_01_v02.mxf
> +fate-filter-overlay-main-alpha: OVERLAY = 
> $(TARGET_SAMPLES)/png1/lena-rgba.png
> +fate-filter-overlay-main-alpha: CMD = framecrc -flags bitexact -i $(SRC) 
> -filter_complex "movie='$(OVERLAY)'[logo];[v:0][logo]overlay" -an
> +
>  FATE_FILTER_HQX-$(call ALLYES, IMAGE2_DEMUXER PNG_DECODER HQX_FILTER) = 
> fate-filter-hq2x fate-filter-hq3x fate-filter-hq4x
>  FATE_FILTER_SAMPLES-yes += $(FATE_FILTER_HQX-yes)
>  fate-filter-hq2x: CMD = framecrc -i $(TARGET_SAMPLES)/filter/pixelart%d.png 
> -vf hqx=2 -pix_fmt bgra
> diff --git a/tests/ref/fate/filter-overlay-main-alpha 
> b/tests/ref/fate/filter-overlay-main-alpha
> new file mode 100644
> index 00..5e5cdfd0d2
> --- /dev/null
> +++ b/tests/ref/fate/filter-overlay-main-alpha
> @@ -0,0 +1,15 @@
> +#tb 0: 1001/24000
> +#media_type 0: video
> +#codec_id 0: rawvideo
> +#dimensions 0: 1280x720
> +#sar 0: 1/1
> +0,  0,  0,1,  2304000, 0x72b48234
> +0,  1,  1,1,  2304000, 0x72b48234
> +0,  2,  2,1,  2304000, 0x72b48234
> +0,  3,  3,1,  2304000, 0x72b48234
> +0,  4,  4,1,  2304000, 0x72b48234
> +0,  5,  5,1,  2304000, 0x72b48234
> +0,  6,  6,1,  2304000, 0x72b48234
> +0,  7,  7,1,  2304000, 0x72b48234
> +0,  8,  8,1,  2304000, 0x72b48234
> +0,  9,  9,1,  2304000, 0x72b48234


this seems not to pass, neither with nor without the other patch

--- ./tests/ref/fate/filter-overlay-main-alpha  2017-07-19 19:31:05.178270723 
+0200
+++ tests/data/fate/filter-overlay-main-alpha   2017-07-19 19:31:33.174271056 
+0200
@@ -3,13 +3,13 @@
 #codec_id 0: rawvideo
 #dimensions 0: 1280x720
 #sar 0: 1/1
-0,  0,  0,1,  2304000, 0x72b48234
-0,  1,  1,1,  2304000, 0x72b48234
-0,  2,  2,1,  2304000, 0x72b48234
-0,  3,  3,1,  2304000, 0x72b48234
-0,  4,  4,1,  2304000, 0x72b48234
-0,  5,  5,1,  2304000, 0x72b48234
-0,  6,  6,1,  2304000, 0x72b48234
-0,  7,  7,1,  2304000, 0x72b48234
-0,  8,  8,1,  2304000, 0x72b48234
-0,  9,  9,1,  2304000, 0x72b48234
+0,  0,  0,1,  2304000, 0xac94c6e0
+0,  1,  1,1,  2304000, 0xac94c6e0
+0,  2,  2,1,  2304000, 0xac94c6e0
+0,  3,  3,1,  2304000, 0xac94c6e0
+0,  4,  4,1,  2304000, 0xac94c6e0
+0,  5,  5,1,  2304000, 0xac94c6e0
+0,  6,  6,1,  2304000, 0xac94c6e0
+0,  7,  7,1,  2304000, 0xac94c6e0
+0,  8,  8,1,  2304000, 0xac94c6e0
+0,  9,  9,1,  2304000, 0xac94c6e0
Test filter-overlay-main-alpha failed. Look at 
tests/data/fate/filter-overlay-main-alpha.err for details.
make: *** [fate-filter-overlay-main-alpha] Error 1

--- ./tests/ref/fate/filter-overlay-main-alpha  2017-07-19 19:31:05.178270723 
+0200
+++ tests/data/fate/filter-overlay-main-alpha   2017-07-19 19:32:34.762271791 
+0200
@@ -3,13 +3,13 @@
 #codec_id 0: rawvideo
 #dimensions 0: 1280x720
 #sar 0: 1/1
-0,  0,  0,1,  2304000, 0x72b48234
-0,  1,  1,1,  2304000, 0x72b48234
-0,  2,  2,1,  2304000, 0x72b48234
-0,  3,  3,1,  2304000, 0x72b48234
-0,  4,  4,1,  2304000, 0x72b48234
-0,  5,  5,1,  2304000, 0x72b48234
-0,  6,  6,1,  2304000, 0x72b48234
-0,  7,  7,1,  2304000, 0x72b48234
-0,  8, 

Re: [FFmpeg-devel] [PATCH] Add tonemap filter

[Michael Niedermayer]

On Tue, Jul 18, 2017 at 09:33:46PM +0200, Vittorio Giovara wrote:
> Based off mpv automatic tonemapping capabilities.
> 
> Signed-off-by: Vittorio Giovara 
> ---
> Updated following an off-list review.
> Vittorio
> 
>  doc/filters.texi | 104 
>  libavfilter/Makefile |   1 +
>  libavfilter/allfilters.c |   1 +
>  libavfilter/vf_tonemap.c | 309 
> +++
>  4 files changed, 415 insertions(+)
>  create mode 100644 libavfilter/vf_tonemap.c

breaks build:

ffmpeg/doc/filters.texi:14483: @section seen before @end table
ffmpeg/doc/filters.texi:14384: @ref reference to nonexistent node `zscale'
ffmpeg/doc/filters.texi:14420: @ref reference to nonexistent node `reinhard'
make: *** [doc/ffprobe-all.html] Error 1
make: *** Waiting for unfinished jobs
ffmpeg/doc/filters.texi:14483: @section seen before @end table
ffmpeg/doc/filters.texi:14384: @ref reference to nonexistent node `zscale'
ffmpeg/doc/filters.texi:14420: @ref reference to nonexistent node `reinhard'
make: *** [doc/ffmpeg-all.html] Error 1

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

Dictatorship naturally arises out of democracy, and the most aggravated
form of tyranny and slavery out of the most extreme liberty. -- Plato


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

Re: [FFmpeg-devel] [PATCHv2 1/2] avdevice/decklink_dec: add support for decoding teletext from 10bit ancillary data

[Marton Balint]

On Wed, 19 Jul 2017, John Warburton wrote:


On Tue, Jul 18, 2017 at 6:10 PM, Marton Balint  wrote:

On Sat, 8 Jul 2017, Marton Balint wrote:


This also add supports for 4K DeckLink cards because they always output the
ancillary data in 10-bit.

v2:
- only try teletext decoding for 576i PAL mode
- some comments as requested by Aaron Levinson

Signed-off-by: Marton Balint 


Applied the series, thanks for all the comments.


Since this patch was applied, the mingw-w64 compiler, gcc version
6.4.1, fails to link shared library avdevice-57.dll, giving the
following error. It is as if the const uint8_t ff_reverse[256] that is
found in libavutil/reverse.c somehow isn't being discovered by the
linker. I'm afraid my knowledge beyond this point is zero.

libavdevice/decklink_dec.o:decklink_dec.cpp:(.rdata$.refptr.ff_reverse[.refptr.ff_reverse]+0x0):
undefined reference to `ff_reverse'
collect2: error: ld returned 1 exit status
ffbuild/library.mak:101: recipe for target 'libavdevice/avdevice-57.dll' failed
make: *** [libavdevice/avdevice-57.dll] Error 1
Build failure. Please see error messages above.


Hmmm. Does adding ff_reverse to the exported symbols in 
libavutil/libavutil.v fix the problem? Or maybe simply renaming 
every instance of ff_reverse in the codebase to avpriv_reverse?


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

Re: [FFmpeg-devel] tsan warning about a data race in libavcodec/h264_direct.c

[Ronald S. Bultje]

Hi,

On Wed, Jul 19, 2017 at 12:26 AM, Wan-Teh Chang <
wtc-at-google@ffmpeg.org> wrote:

> WARNING: ThreadSanitizer: data race (pid=116081)
>   Read of size 4 at 0x7b720118 by thread T3 (mutexes: write M2239):
> #0 pred_temp_direct_motion ffmpeg/libavcodec/h264_direct.c:505:9
> (ffmpeg+0x1159c60)
>
[..]

>   Previous write of size 4 at 0x7b720118 by thread T1 (mutexes:
> write M2234):
> #0 ff_h264_decode_mb_cabac ffmpeg/libavcodec/h264_cabac.c:2386:31
> (ffmpeg+0x1475e0a)


I believe this is temporal motion vector prediction (so MV from frame 1 is
used as a MV predictor in frame 2). The easy solution here is to wait for
the frame to have completed reconstruction of that block (which fills in
that mb_type) before accessing the predictor.

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

Re: [FFmpeg-devel] [PATCH] hwupload_cuda : Add 10/16 bit format support

[Michael Niedermayer]

On Tue, Jul 18, 2017 at 10:34:20AM +, Yogender Gupta wrote:
> Added 10/16bit formats to hwupload_cuda.
> 
> Thanks,
> Yogender
> 
> ---
> This email message is for the sole use of the intended recipient(s) and may 
> contain
> confidential information.  Any unauthorized review, use, disclosure or 
> distribution
> is prohibited.  If you are not the intended recipient, please contact the 
> sender by
> reply email and destroy all copies of the original message.
> ---

>  vf_hwupload_cuda.c |2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 49188f1bd1da5d94a1236c4da55a2609e7906f36  
> 0001-hwupload_cuda-Add-10-16-bit-format-support.patch
> From 0c780f59188edcef25a43aa6e6f375b51b87c22b Mon Sep 17 00:00:00 2001
> From: Yogender Gupta 
> Date: Tue, 18 Jul 2017 16:01:02 +0530
> Subject: [PATCH] hwupload_cuda : Add 10/16 bit format support
> 
> ---
>  libavfilter/vf_hwupload_cuda.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/libavfilter/vf_hwupload_cuda.c b/libavfilter/vf_hwupload_cuda.c
> index ef98233..fe872d8 100644
> --- a/libavfilter/vf_hwupload_cuda.c
> +++ b/libavfilter/vf_hwupload_cuda.c
> @@ -58,7 +58,7 @@ static int cudaupload_query_formats(AVFilterContext *ctx)
>  
>  static const enum AVPixelFormat input_pix_fmts[] = {
>  AV_PIX_FMT_NV12, AV_PIX_FMT_YUV420P, AV_PIX_FMT_YUV444P,
> -AV_PIX_FMT_NONE,
> +AV_PIX_FMT_P010, AV_PIX_FMT_P016, AV_PIX_FMT_YUV444P16, 
> AV_PIX_FMT_NONE,

I suggest to keep AV_PIX_FMT_NONE, on the last line alone
that way patches adding formats at the end dont need to change it

[...]

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

"You are 36 times more likely to die in a bathtub than at the hands of a
terrorist. Also, you are 2.5 times more likely to become a president and
2 times more likely to become an astronaut, than to die in a terrorist
attack." -- Thoughty2



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

Re: [FFmpeg-devel] [PATCH] Add FITS Demuxer

[Paul B Mahol]

On 7/19/17, Nicolas George  wrote:
> Le primidi 1er thermidor, an CCXXV, Paul B Mahol a ecrit :
>> If you had ever write parser, you would know that this above is giberish.
>
> Please enlighten us.

Are there more than one Nicolas here?

Anyway the input can be of any size so one would need to hold complete
state of parsing.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] fate: add tests for psnr and ssim filter

[Tobias Rapp]

On 19.07.2017 17:06, Nicolas George wrote:

Le primidi 1er thermidor, an CCXXV, Tobias Rapp a écrit :

Indeed they are remainders from previous edits. It seems that stripping any
whitespace within the filter string is enough to ensure that it is passed as
one argument token to ffmpeg. So fixed locally.


I suppose you left the quotes, otherwise the semicolon separates
commands and the brackets are globbing patterns.


Indeed, see attached patch for reference (WIP as it still contains the 
CPUFLAGS work-around).



+   -f null /dev/null

BTW: Is it OK to redirect output to "/dev/null" here or does this introduce
an unwanted platform dependency (i.e. blocks FATE from running on
MSYS/Windows)?


With -f null, you can put anything you want there. I usually put -, but
that is just a convenience to be able to change it to "-f fmt - | cmd".


OK.

Regards,
Tobias
>From 430a2c8cfb455cbd11af119987fffa0919f71cc5 Mon Sep 17 00:00:00 2001
From: Tobias Rapp 
Date: Tue, 11 Jul 2017 12:38:06 +0200
Subject: [PATCH] fate: add tests for psnr and ssim filter

Signed-off-by: Tobias Rapp 
---
 tests/fate/filter-video.mak   | 16 +
 tests/ref/fate/filter-refcmp-psnr-rgb | 45 +++
 tests/ref/fate/filter-refcmp-psnr-yuv | 45 +++
 tests/ref/fate/filter-refcmp-ssim-rgb | 30 +++
 tests/ref/fate/filter-refcmp-ssim-yuv | 30 +++
 5 files changed, 166 insertions(+)
 create mode 100644 tests/ref/fate/filter-refcmp-psnr-rgb
 create mode 100644 tests/ref/fate/filter-refcmp-psnr-yuv
 create mode 100644 tests/ref/fate/filter-refcmp-ssim-rgb
 create mode 100644 tests/ref/fate/filter-refcmp-ssim-yuv

diff --git a/tests/fate/filter-video.mak b/tests/fate/filter-video.mak
index 53fc7a6..515fdb2 100644
--- a/tests/fate/filter-video.mak
+++ b/tests/fate/filter-video.mak
@@ -698,6 +698,22 @@ FATE_FILTER_SAMPLES-$(call ALLYES, MOV_DEMUXER H264_DECODER AAC_FIXED_DECODER PC
 fate-filter-meta-4560-rotate0: tests/data/file4560-override2rotate0.mov
 fate-filter-meta-4560-rotate0: CMD = framecrc -flags +bitexact -c:a aac_fixed -i $(TARGET_PATH)/tests/data/file4560-override2rotate0.mov
 
+fate-filter-refcmp%: CMD = ffmpeg -flags +bitexact -sws_flags +accurate_rnd+bitexact -fflags +bitexact \
+	-lavfi "testsrc2=size=300x200:rate=1:duration=5,format=$(PIXFMT),split[ref][tmp];[tmp]avgblur=4[enc];[enc][ref]$(REFCMP),metadata=print:file=-" \
+	-f null /dev/null
+
+FATE_FILTER_SAMPLES-$(call ALLYES, FFMPEG LAVFI_INDEV AVGBLUR_FILTER PSNR_FILTER METADATA_FILTER) += fate-filter-refcmp-psnr-rgb fate-filter-refcmp-psnr-yuv
+fate-filter-refcmp-psnr%: REFCMP = psnr
+fate-filter-refcmp-psnr-rgb: PIXFMT = rgb24
+fate-filter-refcmp-psnr-yuv: PIXFMT = yuv422p
+
+FATE_FILTER_SAMPLES-$(call ALLYES, FFMPEG LAVFI_INDEV AVGBLUR_FILTER SSIM_FILTER METADATA_FILTER) += fate-filter-refcmp-ssim-rgb fate-filter-refcmp-ssim-yuv
+fate-filter-refcmp-ssim%: REFCMP = ssim
+# FIXME: override CPUFLAGS to avoid failure on x86 (issue #6519)
+fate-filter-refcmp-ssim%: CPUFLAGS = 0
+fate-filter-refcmp-ssim-rgb: PIXFMT = rgb24
+fate-filter-refcmp-ssim-yuv: PIXFMT = yuv422p
+
 FATE_SAMPLES_FFPROBE += $(FATE_METADATA_FILTER-yes)
 FATE_SAMPLES_FFMPEG += $(FATE_FILTER_SAMPLES-yes)
 FATE_FFMPEG += $(FATE_FILTER-yes)
diff --git a/tests/ref/fate/filter-refcmp-psnr-rgb b/tests/ref/fate/filter-refcmp-psnr-rgb
new file mode 100644
index 000..7d413f4
--- /dev/null
+++ b/tests/ref/fate/filter-refcmp-psnr-rgb
@@ -0,0 +1,45 @@
+frame:0pts:0   pts_time:0  
+lavfi.psnr.mse.r=1381.80
+lavfi.psnr.psnr.r=16.73
+lavfi.psnr.mse.g=896.00
+lavfi.psnr.psnr.g=18.61
+lavfi.psnr.mse.b=277.38
+lavfi.psnr.psnr.b=23.70
+lavfi.psnr.mse_avg=851.73
+lavfi.psnr.psnr_avg=18.83
+frame:1pts:1   pts_time:1  
+lavfi.psnr.mse.r=1380.37
+lavfi.psnr.psnr.r=16.73
+lavfi.psnr.mse.g=975.91
+lavfi.psnr.psnr.g=18.24
+lavfi.psnr.mse.b=435.72
+lavfi.psnr.psnr.b=21.74
+lavfi.psnr.mse_avg=930.67
+lavfi.psnr.psnr_avg=18.44
+frame:2pts:2   pts_time:2  
+lavfi.psnr.mse.r=1403.20
+lavfi.psnr.psnr.r=16.66
+lavfi.psnr.mse.g=954.05
+lavfi.psnr.psnr.g=18.34
+lavfi.psnr.mse.b=494.22
+lavfi.psnr.psnr.b=21.19
+lavfi.psnr.mse_avg=950.49
+lavfi.psnr.psnr_avg=18.35
+frame:3pts:3   pts_time:3  
+lavfi.psnr.mse.r=1452.80
+lavfi.psnr.psnr.r=16.51
+lavfi.psnr.mse.g=1001.02
+lavfi.psnr.psnr.g=18.13
+lavfi.psnr.mse.b=557.39
+lavfi.psnr.psnr.b=20.67
+lavfi.psnr.mse_avg=1003.74
+lavfi.psnr.psnr_avg=18.11
+frame:4pts:4   pts_time:4  
+lavfi.psnr.mse.r=1401.25
+lavfi.psnr.psnr.r=16.67
+lavfi.psnr.mse.g=1009.80
+lavfi.psnr.psnr.g=18.09
+lavfi.psnr.mse.b=602.42
+lavfi.psnr.psnr.b=20.33
+lavfi.psnr.mse_avg=1004.49
+lavfi.psnr.psnr_avg=18.11
diff --git a/tests/ref/fate/filter-refcmp-psnr-yuv b/tests/ref/fate/filter-refcmp-psnr-yuv
new file mode 100644
index 000..942542a
--- /dev/null
+++ b/tests/ref/fate/filter-refcmp-psnr-yuv
@@ 

Re: [FFmpeg-devel] [PATCH] fate: add tests for psnr and ssim filter

[Nicolas George]

Le primidi 1er thermidor, an CCXXV, Tobias Rapp a écrit :
> Indeed they are remainders from previous edits. It seems that stripping any
> whitespace within the filter string is enough to ensure that it is passed as
> one argument token to ffmpeg. So fixed locally.

I suppose you left the quotes, otherwise the semicolon separates
commands and the brackets are globbing patterns.

> >>+   -f null /dev/null
> BTW: Is it OK to redirect output to "/dev/null" here or does this introduce
> an unwanted platform dependency (i.e. blocks FATE from running on
> MSYS/Windows)?

With -f null, you can put anything you want there. I usually put -, but
that is just a convenience to be able to change it to "-f fmt - | cmd".

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] fate: add tests for psnr and ssim filter

[Tobias Rapp]

On 19.07.2017 14:24, Nicolas George wrote:

Hi. Thanks for the patch. Here are comments unrelated to the issues of
asm failure.

Le primidi 1er thermidor, an CCXXV, Tobias Rapp a écrit :

Signed-off-by: Tobias Rapp 
---
 tests/fate/filter-video.mak   | 17 +
 tests/ref/fate/filter-refcmp-psnr-rgb | 45 +++
 tests/ref/fate/filter-refcmp-psnr-yuv | 45 +++
 tests/ref/fate/filter-refcmp-ssim-rgb | 30 +++
 tests/ref/fate/filter-refcmp-ssim-yuv | 30 +++
 5 files changed, 167 insertions(+)
 create mode 100644 tests/ref/fate/filter-refcmp-psnr-rgb
 create mode 100644 tests/ref/fate/filter-refcmp-psnr-yuv
 create mode 100644 tests/ref/fate/filter-refcmp-ssim-rgb
 create mode 100644 tests/ref/fate/filter-refcmp-ssim-yuv

diff --git a/tests/fate/filter-video.mak b/tests/fate/filter-video.mak
index 53fc7a6..581297f 100644
--- a/tests/fate/filter-video.mak
+++ b/tests/fate/filter-video.mak
@@ -698,6 +698,23 @@ FATE_FILTER_SAMPLES-$(call ALLYES, MOV_DEMUXER 
H264_DECODER AAC_FIXED_DECODER PC
 fate-filter-meta-4560-rotate0: tests/data/file4560-override2rotate0.mov
 fate-filter-meta-4560-rotate0: CMD = framecrc -flags +bitexact -c:a aac_fixed 
-i $(TARGET_PATH)/tests/data/file4560-override2rotate0.mov

+fate-filter-refcmp%: CMD = ffmpeg -flags +bitexact -sws_flags 
+accurate_rnd+bitexact -fflags +bitexact \



+   -f lavfi -i "testsrc=size=300x200:rate=1:duration=5" \
+   -filter:v 
"format=$(PIXFMT),split[ref][tmp]\;[tmp]avgblur=4[enc]\;[enc][ref]$(REFCMP),metadata=print:file=-"
 \


-lavfi "testsrc=...,format=,...", with "-lavfi" instead of "-f lavfi -i"
and a single graph.

Also, better use testsrc2, it is faster and with testrc, the yuv422p
test will invoke scale.


Changed locally.


Last, I think the backslashes before the semicolons are suspicious.


Indeed they are remainders from previous edits. It seems that stripping 
any whitespace within the filter string is enough to ensure that it is 
passed as one argument token to ffmpeg. So fixed locally.



+   -f null /dev/null


BTW: Is it OK to redirect output to "/dev/null" here or does this 
introduce an unwanted platform dependency (i.e. blocks FATE from running 
on MSYS/Windows)?



+
+FATE_FILTER_SAMPLES-$(call ALLYES, FFMPEG LAVFI_INDEV AVGBLUR_FILTER 
PSNR_FILTER METADATA_FILTER) += fate-filter-refcmp-psnr-rgb 
fate-filter-refcmp-psnr-yuv
+fate-filter-refcmp-psnr%: REFCMP = psnr
+fate-filter-refcmp-psnr-rgb: PIXFMT = rgb24
+fate-filter-refcmp-psnr-yuv: PIXFMT = yuv422p
+
+FATE_FILTER_SAMPLES-$(call ALLYES, FFMPEG LAVFI_INDEV AVGBLUR_FILTER 
SSIM_FILTER METADATA_FILTER) += fate-filter-refcmp-ssim-rgb 
fate-filter-refcmp-ssim-yuv
+fate-filter-refcmp-ssim%: REFCMP = ssim
+# FIXME: override CPUFLAGS to avoid failure on x86 (issue #6519)
+fate-filter-refcmp-ssim%: CPUFLAGS = 0
+fate-filter-refcmp-ssim-rgb: PIXFMT = rgb24
+fate-filter-refcmp-ssim-yuv: PIXFMT = yuv422p
+
 FATE_SAMPLES_FFPROBE += $(FATE_METADATA_FILTER-yes)
 FATE_SAMPLES_FFMPEG += $(FATE_FILTER_SAMPLES-yes)
 FATE_FFMPEG += $(FATE_FILTER-yes)




Thanks for review,
Tobias

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

[FFmpeg-devel] [PATCH] avfilter: Add blue and violet noise generation filters

[george]

From: George Boyle 

For the blue and violet noise, I took the pink and brown noise
respectively and subtracted the offsets instead of adding them. When I
eyeball the frequency spectrum of the resulting outputs it looks correct
to me, i.e. the blue graph appears to be a mirror image of the pink, and
the same can be said of the violet and the brown. I did not do anything
else to confirm the correctness.
---
 doc/filters.texi |  4 +--
 libavfilter/asrc_anoisesrc.c | 72 +---
 2 files changed, 57 insertions(+), 19 deletions(-)

diff --git a/doc/filters.texi b/doc/filters.texi
index 2708fdb1df..dd88636bb9 100644
--- a/doc/filters.texi
+++ b/doc/filters.texi
@@ -4471,8 +4471,8 @@ Specify the duration of the generated audio stream. Not 
specifying this option
 results in noise with an infinite length.
 
 @item color, colour, c
-Specify the color of noise. Available noise colors are white, pink, and brown.
-Default color is white.
+Specify the color of noise. Available noise colors are white, pink, brown,
+blue and violet. Default color is white.
 
 @item seed, s
 Specify a value used to seed the PRNG.
diff --git a/libavfilter/asrc_anoisesrc.c b/libavfilter/asrc_anoisesrc.c
index be0d5ab6a5..c3d99b3166 100644
--- a/libavfilter/asrc_anoisesrc.c
+++ b/libavfilter/asrc_anoisesrc.c
@@ -41,24 +41,35 @@ typedef struct ANoiseSrcContext {
 AVLFG c;
 } ANoiseSrcContext;
 
+enum NoiseMode {
+NM_WHITE,
+NM_PINK,
+NM_BROWN,
+NM_BLUE,
+NM_VIOLET,
+NM_NB
+};
+
 #define OFFSET(x) offsetof(ANoiseSrcContext, x)
 #define FLAGS AV_OPT_FLAG_AUDIO_PARAM|AV_OPT_FLAG_FILTERING_PARAM
 
 static const AVOption anoisesrc_options[] = {
-{ "sample_rate",  "set sample rate",  OFFSET(sample_rate),  
AV_OPT_TYPE_INT,   {.i64 = 48000},  15,  INT_MAX,FLAGS },
-{ "r","set sample rate",  OFFSET(sample_rate),  
AV_OPT_TYPE_INT,   {.i64 = 48000},  15,  INT_MAX,FLAGS },
-{ "amplitude","set amplitude",OFFSET(amplitude),
AV_OPT_TYPE_DOUBLE,{.dbl = 1.}, 0.,  1., FLAGS },
-{ "a","set amplitude",OFFSET(amplitude),
AV_OPT_TYPE_DOUBLE,{.dbl = 1.}, 0.,  1., FLAGS },
-{ "duration", "set duration", OFFSET(duration), 
AV_OPT_TYPE_DURATION,  {.i64 =  0},  0,  INT64_MAX,  FLAGS },
-{ "d","set duration", OFFSET(duration), 
AV_OPT_TYPE_DURATION,  {.i64 =  0},  0,  INT64_MAX,  FLAGS },
-{ "color","set noise color",  OFFSET(color),
AV_OPT_TYPE_INT,   {.i64 =  1},  0,  2,  FLAGS, "color" },
-{ "colour",   "set noise color",  OFFSET(color),
AV_OPT_TYPE_INT,   {.i64 =  1},  0,  2,  FLAGS, "color" },
-{ "c","set noise color",  OFFSET(color),
AV_OPT_TYPE_INT,   {.i64 =  0},  0,  2,  FLAGS, "color" },
-{ "white",0,  0,
AV_OPT_TYPE_CONST, {.i64 =  0},  0,  0,  FLAGS, "color" },
-{ "pink", 0,  0,
AV_OPT_TYPE_CONST, {.i64 =  1},  0,  0,  FLAGS, "color" },
-{ "brown",0,  0,
AV_OPT_TYPE_CONST, {.i64 =  2},  0,  0,  FLAGS, "color" },
-{ "seed", "set random seed",  OFFSET(seed), 
AV_OPT_TYPE_INT64, {.i64 = -1}, -1,  UINT_MAX,   FLAGS },
-{ "s","set random seed",  OFFSET(seed), 
AV_OPT_TYPE_INT64, {.i64 = -1}, -1,  UINT_MAX,   FLAGS },
+{ "sample_rate",  "set sample rate",  OFFSET(sample_rate),  
AV_OPT_TYPE_INT,   {.i64 = 48000}, 15,  INT_MAX,FLAGS },
+{ "r","set sample rate",  OFFSET(sample_rate),  
AV_OPT_TYPE_INT,   {.i64 = 48000}, 15,  INT_MAX,FLAGS },
+{ "amplitude","set amplitude",OFFSET(amplitude),
AV_OPT_TYPE_DOUBLE,{.dbl = 1.},0.,  1., FLAGS },
+{ "a","set amplitude",OFFSET(amplitude),
AV_OPT_TYPE_DOUBLE,{.dbl = 1.},0.,  1., FLAGS },
+{ "duration", "set duration", OFFSET(duration), 
AV_OPT_TYPE_DURATION,  {.i64 =  0}, 0,  INT64_MAX,  FLAGS },
+{ "d","set duration", OFFSET(duration), 
AV_OPT_TYPE_DURATION,  {.i64 =  0}, 0,  INT64_MAX,  FLAGS },
+{ "color","set noise color",  OFFSET(color),
AV_OPT_TYPE_INT,   {.i64 =  1}, 0,  NM_NB - 1,  FLAGS, "color" },
+{ "colour",   "set noise color",  OFFSET(color),
AV_OPT_TYPE_INT,   {.i64 =  1}, 0,  NM_NB - 1,  FLAGS, "color" },
+{ "c","set noise color",  OFFSET(color),
AV_OPT_TYPE_INT,   {.i64 =  0}, 0,  NM_NB - 1,  FLAGS, "color" },
+{ "white",0,  0,
AV_OPT_TYPE_CONST, {.i64 = NM_WHITE},   0,  0,  

Re: [FFmpeg-devel] [PATCH] avfilter: Add blue and violet noise generation filters

[George Boyle]

On Wed, Jul 19, 2017 at 1:39 PM, Moritz Barsnick  wrote:

> On Wed, Jul 19, 2017 at 07:59:33 +0200, geo...@spotify.com wrote:
> > For the blue and violet noise, I took the pink and brown noise
> > respectively and subtracted the offsets instead of adding them. When I
>
> Cool.
>
> > -{ "color","set noise color",  OFFSET(color),
> AV_OPT_TYPE_INT,   {.i64 =  1},  0,  2,  FLAGS, "color" },
> > -{ "colour",   "set noise color",  OFFSET(color),
> AV_OPT_TYPE_INT,   {.i64 =  1},  0,  2,  FLAGS, "color" },
> > -{ "c","set noise color",  OFFSET(color),
> AV_OPT_TYPE_INT,   {.i64 =  0},  0,  2,  FLAGS, "color" },
> > +{ "color","set noise color",  OFFSET(color),
> AV_OPT_TYPE_INT,   {.i64 =  1},  0,  4,  FLAGS, "color" },
> > +{ "colour",   "set noise color",  OFFSET(color),
> AV_OPT_TYPE_INT,   {.i64 =  1},  0,  4,  FLAGS, "color" },
> > +{ "c","set noise color",  OFFSET(color),
> AV_OPT_TYPE_INT,   {.i64 =  0},  0,  4,  FLAGS, "color" },
>
> At this point, it's probably worth adding an enum.
>
> enum NoiseMode {
> NM_WHITE,
> NM_PINK,
> [...]
> NM_NB
> };
>
> and setting the option's max to "NM_NB-1" instead of "4".
>
> >  switch (s->color) {
> > -case 0: s->filter = white_filter; break;
> > -case 1: s->filter = pink_filter;  break;
> > -case 2: s->filter = brown_filter; break;
> > +case 0: s->filter = white_filter;  break;
> > +case 1: s->filter = pink_filter;   break;
> > +case 2: s->filter = brown_filter;  break;
> > +case 3: s->filter = blue_filter;   break;
> > +case 4: s->filter = violet_filter; break;
>
> And use the enums here.
>
> Just a suggestion...
>
>
Thanks for the comments. New patch on the way...
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] fate: add tests for psnr and ssim filter

[Nicolas George]

Hi. Thanks for the patch. Here are comments unrelated to the issues of
asm failure.

Le primidi 1er thermidor, an CCXXV, Tobias Rapp a écrit :
> Signed-off-by: Tobias Rapp 
> ---
>  tests/fate/filter-video.mak   | 17 +
>  tests/ref/fate/filter-refcmp-psnr-rgb | 45 
> +++
>  tests/ref/fate/filter-refcmp-psnr-yuv | 45 
> +++
>  tests/ref/fate/filter-refcmp-ssim-rgb | 30 +++
>  tests/ref/fate/filter-refcmp-ssim-yuv | 30 +++
>  5 files changed, 167 insertions(+)
>  create mode 100644 tests/ref/fate/filter-refcmp-psnr-rgb
>  create mode 100644 tests/ref/fate/filter-refcmp-psnr-yuv
>  create mode 100644 tests/ref/fate/filter-refcmp-ssim-rgb
>  create mode 100644 tests/ref/fate/filter-refcmp-ssim-yuv
> 
> diff --git a/tests/fate/filter-video.mak b/tests/fate/filter-video.mak
> index 53fc7a6..581297f 100644
> --- a/tests/fate/filter-video.mak
> +++ b/tests/fate/filter-video.mak
> @@ -698,6 +698,23 @@ FATE_FILTER_SAMPLES-$(call ALLYES, MOV_DEMUXER 
> H264_DECODER AAC_FIXED_DECODER PC
>  fate-filter-meta-4560-rotate0: tests/data/file4560-override2rotate0.mov
>  fate-filter-meta-4560-rotate0: CMD = framecrc -flags +bitexact -c:a 
> aac_fixed -i $(TARGET_PATH)/tests/data/file4560-override2rotate0.mov
>  
> +fate-filter-refcmp%: CMD = ffmpeg -flags +bitexact -sws_flags 
> +accurate_rnd+bitexact -fflags +bitexact \

> + -f lavfi -i "testsrc=size=300x200:rate=1:duration=5" \
> + -filter:v 
> "format=$(PIXFMT),split[ref][tmp]\;[tmp]avgblur=4[enc]\;[enc][ref]$(REFCMP),metadata=print:file=-"
>  \

-lavfi "testsrc=...,format=,...", with "-lavfi" instead of "-f lavfi -i"
and a single graph.

Also, better use testsrc2, it is faster and with testrc, the yuv422p
test will invoke scale.

Last, I think the backslashes before the semicolons are suspicious.

> + -f null /dev/null
> +
> +FATE_FILTER_SAMPLES-$(call ALLYES, FFMPEG LAVFI_INDEV AVGBLUR_FILTER 
> PSNR_FILTER METADATA_FILTER) += fate-filter-refcmp-psnr-rgb 
> fate-filter-refcmp-psnr-yuv
> +fate-filter-refcmp-psnr%: REFCMP = psnr
> +fate-filter-refcmp-psnr-rgb: PIXFMT = rgb24
> +fate-filter-refcmp-psnr-yuv: PIXFMT = yuv422p
> +
> +FATE_FILTER_SAMPLES-$(call ALLYES, FFMPEG LAVFI_INDEV AVGBLUR_FILTER 
> SSIM_FILTER METADATA_FILTER) += fate-filter-refcmp-ssim-rgb 
> fate-filter-refcmp-ssim-yuv
> +fate-filter-refcmp-ssim%: REFCMP = ssim
> +# FIXME: override CPUFLAGS to avoid failure on x86 (issue #6519)
> +fate-filter-refcmp-ssim%: CPUFLAGS = 0
> +fate-filter-refcmp-ssim-rgb: PIXFMT = rgb24
> +fate-filter-refcmp-ssim-yuv: PIXFMT = yuv422p
> +
>  FATE_SAMPLES_FFPROBE += $(FATE_METADATA_FILTER-yes)
>  FATE_SAMPLES_FFMPEG += $(FATE_FILTER_SAMPLES-yes)
>  FATE_FFMPEG += $(FATE_FILTER-yes)

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] Add FITS Demuxer

[Nicolas George]

Le primidi 1er thermidor, an CCXXV, Paul B Mahol a écrit :
> If you had ever write parser, you would know that this above is giberish.

Please enlighten us.

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 v2 1/2] avcodec: add Dolby E decoder

[Moritz Barsnick]

On Sat, Jul 01, 2017 at 17:03:46 +0300, foo86 wrote:
> +static av_cold void init_tables(void)
> +{
> +int i, j;
> +
> +for (i = 1; i < 17; i++)
> +mantissa_tab1[i][0] = 1.0 / (1 << i - 1);
> +
> +for (i = 2; i < 16; i++) {
> +mantissa_tab1[i][1] = 1.0  / ((1 << i) - 1);
> +mantissa_tab1[i][2] = 0.5  / ((1 << i) - 1);
> +mantissa_tab1[i][3] = 0.25 / ((1 << i) - 1);
> +}
> +
> +mantissa_tab1[i][1] = 0.5   / (1 << 15);
> +mantissa_tab1[i][2] = 0.75  / (1 << 15);
> +mantissa_tab1[i][3] = 0.875 / (1 << 15);
> +
> +for (i = 1; i < 17; i++) {
> +mantissa_tab2[i][1] = mantissa_tab1[i][0] * 0.5;
> +mantissa_tab2[i][2] = mantissa_tab1[i][0] * 0.75;
> +mantissa_tab2[i][3] = mantissa_tab1[i][0] * 0.875;
> +for (j = 1; j < 4; j++)
> +mantissa_tab3[i][j] = 1.0 / (1 << i) + 1.0 / (1 << j) - 1.0 / (1 
> << i + j);
> +}
> +
> +mantissa_tab3[1][3] = 0.6875;
> +
> +for (i = 0; i < 25; i++) {
> +exponent_tab[i * 2] = 1.0   / (1 << i);
> +exponent_tab[i * 2 + 1] = M_SQRT1_2 / (1 << i);
> +}

The literal numerical constants used in the quoted section should
probably get 'f' suffixes, to force single precision operations. (Not
that it matters much in the init code.)

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

Re: [FFmpeg-devel] [PATCH] fate: add tests for psnr and ssim filter

[Tobias Rapp]

On 19.07.2017 12:45, Ronald S. Bultje wrote:

Hi,

On Wed, Jul 19, 2017 at 6:38 AM, Paul B Mahol  wrote:


On 7/19/17, Ronald S. Bultje  wrote:

Hi Tobias,

On Wed, Jul 19, 2017 at 5:40 AM, Tobias Rapp 

wrote:



+# FIXME: override CPUFLAGS to avoid failure on x86 (issue #6519)




This is unacceptable hack.



I'm assuming this is because of floating point rounding differences. Is

it

possible to use a test similar to the floating-point codec tests that
allows slight offs? The differences are usually miniscule, right?

Ideally,

the x86 SIMD would be tested also.


No, filter's asm code, overreads buffer, causing crash.



Oh... That's bad, I'll try to fix that...


That would be great as my assembler knowledge isn't that good. There are 
some Valgrind logs and my other findings available at 
https://trac.ffmpeg.org/ticket/6519 .


Regards,
Tobias

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

Re: [FFmpeg-devel] [PATCH] avfilter: Add blue and violet noise generation filters

[Paul B Mahol]

On 7/19/17, geo...@spotify.com  wrote:
> From: George Boyle 
>
> For the blue and violet noise, I took the pink and brown noise
> respectively and subtracted the offsets instead of adding them. When I
> eyeball the frequency spectrum of the resulting outputs it looks correct
> to me, i.e. the blue graph appears to be a mirror image of the pink, and
> the same can be said of the violet and the brown. I did not do anything
> else to confirm the correctness.
> ---
>  doc/filters.texi |  4 ++--
>  libavfilter/asrc_anoisesrc.c | 41 +++--
>  2 files changed, 37 insertions(+), 8 deletions(-)
>

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

Re: [FFmpeg-devel] [PATCH] fate: add tests for psnr and ssim filter

[Ronald S. Bultje]

Hi,

On Wed, Jul 19, 2017 at 6:38 AM, Paul B Mahol  wrote:

> On 7/19/17, Ronald S. Bultje  wrote:
> > Hi Tobias,
> >
> > On Wed, Jul 19, 2017 at 5:40 AM, Tobias Rapp 
> wrote:
> >
> >> +# FIXME: override CPUFLAGS to avoid failure on x86 (issue #6519)
> >
>
> This is unacceptable hack.
>
> >
> > I'm assuming this is because of floating point rounding differences. Is
> it
> > possible to use a test similar to the floating-point codec tests that
> > allows slight offs? The differences are usually miniscule, right?
> Ideally,
> > the x86 SIMD would be tested also.
>
> No, filter's asm code, overreads buffer, causing crash.


Oh... That's bad, I'll try to fix that...

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

Re: [FFmpeg-devel] [PATCH 1/2] libavfilter/scale: More descriptive in/ref/out logging

[Ronald S. Bultje]

Hi Kevin,

On Wed, Jul 19, 2017 at 2:01 AM, Kevin Mark  wrote:

> Hello all,
>
> Just wondering if anyone had any thoughts on the grepability issue,
> which I believe is the only potential issue/breaking change with this
> patch.


You wrote something like:

"ffmpeg [...] scale2ref=0:0 [...] -v verbose - 2>&1 >/dev/null | grep -oP
'regex'

Where regex is: [..]"

But my grep (Mac) has no -P option... I'd encourage you to keep things
simple and use a non-\n delimiter between the lines so non-GNU grep can
continue to be used for this also...

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

Re: [FFmpeg-devel] [PATCH] fate: add tests for psnr and ssim filter

[Paul B Mahol]

On 7/19/17, Ronald S. Bultje  wrote:
> Hi Tobias,
>
> On Wed, Jul 19, 2017 at 5:40 AM, Tobias Rapp  wrote:
>
>> +# FIXME: override CPUFLAGS to avoid failure on x86 (issue #6519)
>

This is unacceptable hack.

>
> I'm assuming this is because of floating point rounding differences. Is it
> possible to use a test similar to the floating-point codec tests that
> allows slight offs? The differences are usually miniscule, right? Ideally,
> the x86 SIMD would be tested also.

No, filter's asm code, overreads buffer, causing crash.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] fate: add tests for psnr and ssim filter

[Ronald S. Bultje]

Hi Tobias,

On Wed, Jul 19, 2017 at 5:40 AM, Tobias Rapp  wrote:

> +# FIXME: override CPUFLAGS to avoid failure on x86 (issue #6519)


I'm assuming this is because of floating point rounding differences. Is it
possible to use a test similar to the floating-point codec tests that
allows slight offs? The differences are usually miniscule, right? Ideally,
the x86 SIMD would be tested also.

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

Re: [FFmpeg-devel] [PATCH] Add FITS Demuxer

[Paul B Mahol]

On 7/19/17, Nicolas George  wrote:
> Le decadi 30 messidor, an CCXXV, Rostislav Pehlivanov a ecrit :
>> Its a crappy format, no reason to blame anyone else but the format.
>> We have plenty of crappy formats which have no clear separation between
>> packets so demuxers have to give not-entirely-demuxed packets to the
>> decoder which also has to skip past junk. Its both wrong and its not,
>> because it isn't defined anywhere and the packets packed in the file were
>> never meant to go anywhere but the format they were packed in.
>
> I mostly agree, but I would say that exactly the same applies to many
> image formats, especially old ones, including some amongst GIF, Sun
> Raster, XPM / XBM, XFace, Targa, etc.
>
> Do you disagree?
>
>> I think the image2 demuxer shouldn't handle this type of junk/useless
>> data
>> filtering and would rather see a separate demuxer like the current patch
>> which deals with crap.
>
> I am somewhat confused by your statement, because in my mind, this is
> exactly the purpose and task of the image2(pipe) demuxers.
>
> The image2pipe demuxer reads the input stream, calls a parser to find in
> it the size of the images and returns them as individual packets. Note
> that the parsers are not part of the image2(pipe) demuxers, they are
> separate entities of their own, each specific to one image format.
>
> I do not know what the image2pipe demuxer would be good for, if not for
> that. Or did I miss something?
>
> Still, I do not insist that it is done with the image2(pipe) demuxer. It
> only seems the best solution according to what was said about the format
> until now.
>
> What I do insist on, is this:
>
> Look at the find_size() function in this patch:
> https://ffmpeg.org/pipermail/ffmpeg-devel/2017-July/213076.html
>
> Then look at the fits_read_header() in this patch:
> https://ffmpeg.org/pipermail/ffmpeg-devel/2017-July/213061.html
>
> They are the same. One works on an AVIOContext using read operations,
> the other works on a buffer using pointer arithmetic, but the logic is
> the same. And it is not a trivial logic, here, we are talking about
> dozens of lines of code.
>
> This is not good design, this is not good for maintenance: if a bug
> needs fixing, it will need fixing consistently in both implementations;
> if a feature is added, it will require the same.
>
> Good design and maintenance require a single implementation.
>
> This is especially true for an obscure format like FITS, where
> maintenance workforce is scarce.
>
> And this is especially true for a GSoC project, where the student is
> supposed to be learning good practices.
>
> I think the best and simplest way of achieving that is to have both the
> parser and the decoder call the same function. And I think the simplest
> way of implementing it is to make a parser and rely on image2pipe.
>
> Because with minimal changes to fits_read_header(), the parser would
> look just slightly more complex than that:
>
> static int fitsparse(AVCodecParserContext *s, AVCodecContext *avctx,
>   const uint8_t **poutbuf, int *poutbuf_size,
>   const uint8_t *buf, int buf_size)
> {
> fits_read_header(buf, buf_size, );
> return size;
> }

If you had ever write parser, you would know that this above is giberish.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] Add FITS Demuxer

[Nicolas George]

Le primidi 1er thermidor, an CCXXV, Paul B Mahol a écrit :
> Except when those standards need to be applied to your work.

Yet another ad-hominem attack.

-- 
  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] Add FITS Demuxer

[Paul B Mahol]

On 7/19/17, Nicolas George  wrote:
> Le decadi 30 messidor, an CCXXV, Rostislav Pehlivanov a ecrit :
>> Its a crappy format, no reason to blame anyone else but the format.
>> We have plenty of crappy formats which have no clear separation between
>> packets so demuxers have to give not-entirely-demuxed packets to the
>> decoder which also has to skip past junk. Its both wrong and its not,
>> because it isn't defined anywhere and the packets packed in the file were
>> never meant to go anywhere but the format they were packed in.
>
> I mostly agree, but I would say that exactly the same applies to many
> image formats, especially old ones, including some amongst GIF, Sun
> Raster, XPM / XBM, XFace, Targa, etc.
>
> Do you disagree?
>
>> I think the image2 demuxer shouldn't handle this type of junk/useless
>> data
>> filtering and would rather see a separate demuxer like the current patch
>> which deals with crap.
>
> I am somewhat confused by your statement, because in my mind, this is
> exactly the purpose and task of the image2(pipe) demuxers.
>
> The image2pipe demuxer reads the input stream, calls a parser to find in
> it the size of the images and returns them as individual packets. Note
> that the parsers are not part of the image2(pipe) demuxers, they are
> separate entities of their own, each specific to one image format.
>
> I do not know what the image2pipe demuxer would be good for, if not for
> that. Or did I miss something?
>
> Still, I do not insist that it is done with the image2(pipe) demuxer. It
> only seems the best solution according to what was said about the format
> until now.
>
> What I do insist on, is this:
>
> Look at the find_size() function in this patch:
> https://ffmpeg.org/pipermail/ffmpeg-devel/2017-July/213076.html
>
> Then look at the fits_read_header() in this patch:
> https://ffmpeg.org/pipermail/ffmpeg-devel/2017-July/213061.html
>
> They are the same. One works on an AVIOContext using read operations,
> the other works on a buffer using pointer arithmetic, but the logic is
> the same. And it is not a trivial logic, here, we are talking about
> dozens of lines of code.
>
> This is not good design, this is not good for maintenance: if a bug
> needs fixing, it will need fixing consistently in both implementations;
> if a feature is added, it will require the same.
>
> Good design and maintenance require a single implementation.
>
> This is especially true for an obscure format like FITS, where
> maintenance workforce is scarce.
>
> And this is especially true for a GSoC project, where the student is
> supposed to be learning good practices.
>
> I think the best and simplest way of achieving that is to have both the
> parser and the decoder call the same function. And I think the simplest
> way of implementing it is to make a parser and rely on image2pipe.
>
> Because with minimal changes to fits_read_header(), the parser would
> look just slightly more complex than that:
>
> static int fitsparse(AVCodecParserContext *s, AVCodecContext *avctx,
>   const uint8_t **poutbuf, int *poutbuf_size,
>   const uint8_t *buf, int buf_size)
> {
> fits_read_header(buf, buf_size, );
> return size;
> }
>
> So as it stands now, I will oppose any patch that duplicates the
> header-reading logic, and I think anybody should do the same, since it
> is everybody's responsibility to uphold the high standards of code
> quality in our project.

Except when those standards need to be applied to your work.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] Add FITS Demuxer

[Nicolas George]

Le decadi 30 messidor, an CCXXV, Rostislav Pehlivanov a écrit :
> Its a crappy format, no reason to blame anyone else but the format.
> We have plenty of crappy formats which have no clear separation between
> packets so demuxers have to give not-entirely-demuxed packets to the
> decoder which also has to skip past junk. Its both wrong and its not,
> because it isn't defined anywhere and the packets packed in the file were
> never meant to go anywhere but the format they were packed in.

I mostly agree, but I would say that exactly the same applies to many
image formats, especially old ones, including some amongst GIF, Sun
Raster, XPM / XBM, XFace, Targa, etc.

Do you disagree?

> I think the image2 demuxer shouldn't handle this type of junk/useless data
> filtering and would rather see a separate demuxer like the current patch
> which deals with crap.

I am somewhat confused by your statement, because in my mind, this is
exactly the purpose and task of the image2(pipe) demuxers.

The image2pipe demuxer reads the input stream, calls a parser to find in
it the size of the images and returns them as individual packets. Note
that the parsers are not part of the image2(pipe) demuxers, they are
separate entities of their own, each specific to one image format.

I do not know what the image2pipe demuxer would be good for, if not for
that. Or did I miss something?

Still, I do not insist that it is done with the image2(pipe) demuxer. It
only seems the best solution according to what was said about the format
until now.

What I do insist on, is this:

Look at the find_size() function in this patch:
https://ffmpeg.org/pipermail/ffmpeg-devel/2017-July/213076.html

Then look at the fits_read_header() in this patch:
https://ffmpeg.org/pipermail/ffmpeg-devel/2017-July/213061.html

They are the same. One works on an AVIOContext using read operations,
the other works on a buffer using pointer arithmetic, but the logic is
the same. And it is not a trivial logic, here, we are talking about
dozens of lines of code.

This is not good design, this is not good for maintenance: if a bug
needs fixing, it will need fixing consistently in both implementations;
if a feature is added, it will require the same.

Good design and maintenance require a single implementation.

This is especially true for an obscure format like FITS, where
maintenance workforce is scarce.

And this is especially true for a GSoC project, where the student is
supposed to be learning good practices.

I think the best and simplest way of achieving that is to have both the
parser and the decoder call the same function. And I think the simplest
way of implementing it is to make a parser and rely on image2pipe.

Because with minimal changes to fits_read_header(), the parser would
look just slightly more complex than that:

static int fitsparse(AVCodecParserContext *s, AVCodecContext *avctx,
  const uint8_t **poutbuf, int *poutbuf_size,
  const uint8_t *buf, int buf_size)
{
fits_read_header(buf, buf_size, );
return size;
}

So as it stands now, I will oppose any patch that duplicates the
header-reading logic, and I think anybody should do the same, since it
is everybody's responsibility to uphold the high standards of code
quality in our project.

Regards,

-- 
  Nicolas George


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

[FFmpeg-devel] [PATCH] fate: add tests for psnr and ssim filter

[Tobias Rapp]

Signed-off-by: Tobias Rapp 
---
 tests/fate/filter-video.mak   | 17 +
 tests/ref/fate/filter-refcmp-psnr-rgb | 45 +++
 tests/ref/fate/filter-refcmp-psnr-yuv | 45 +++
 tests/ref/fate/filter-refcmp-ssim-rgb | 30 +++
 tests/ref/fate/filter-refcmp-ssim-yuv | 30 +++
 5 files changed, 167 insertions(+)
 create mode 100644 tests/ref/fate/filter-refcmp-psnr-rgb
 create mode 100644 tests/ref/fate/filter-refcmp-psnr-yuv
 create mode 100644 tests/ref/fate/filter-refcmp-ssim-rgb
 create mode 100644 tests/ref/fate/filter-refcmp-ssim-yuv

diff --git a/tests/fate/filter-video.mak b/tests/fate/filter-video.mak
index 53fc7a6..581297f 100644
--- a/tests/fate/filter-video.mak
+++ b/tests/fate/filter-video.mak
@@ -698,6 +698,23 @@ FATE_FILTER_SAMPLES-$(call ALLYES, MOV_DEMUXER 
H264_DECODER AAC_FIXED_DECODER PC
 fate-filter-meta-4560-rotate0: tests/data/file4560-override2rotate0.mov
 fate-filter-meta-4560-rotate0: CMD = framecrc -flags +bitexact -c:a aac_fixed 
-i $(TARGET_PATH)/tests/data/file4560-override2rotate0.mov
 
+fate-filter-refcmp%: CMD = ffmpeg -flags +bitexact -sws_flags 
+accurate_rnd+bitexact -fflags +bitexact \
+   -f lavfi -i "testsrc=size=300x200:rate=1:duration=5" \
+   -filter:v 
"format=$(PIXFMT),split[ref][tmp]\;[tmp]avgblur=4[enc]\;[enc][ref]$(REFCMP),metadata=print:file=-"
 \
+   -f null /dev/null
+
+FATE_FILTER_SAMPLES-$(call ALLYES, FFMPEG LAVFI_INDEV AVGBLUR_FILTER 
PSNR_FILTER METADATA_FILTER) += fate-filter-refcmp-psnr-rgb 
fate-filter-refcmp-psnr-yuv
+fate-filter-refcmp-psnr%: REFCMP = psnr
+fate-filter-refcmp-psnr-rgb: PIXFMT = rgb24
+fate-filter-refcmp-psnr-yuv: PIXFMT = yuv422p
+
+FATE_FILTER_SAMPLES-$(call ALLYES, FFMPEG LAVFI_INDEV AVGBLUR_FILTER 
SSIM_FILTER METADATA_FILTER) += fate-filter-refcmp-ssim-rgb 
fate-filter-refcmp-ssim-yuv
+fate-filter-refcmp-ssim%: REFCMP = ssim
+# FIXME: override CPUFLAGS to avoid failure on x86 (issue #6519)
+fate-filter-refcmp-ssim%: CPUFLAGS = 0
+fate-filter-refcmp-ssim-rgb: PIXFMT = rgb24
+fate-filter-refcmp-ssim-yuv: PIXFMT = yuv422p
+
 FATE_SAMPLES_FFPROBE += $(FATE_METADATA_FILTER-yes)
 FATE_SAMPLES_FFMPEG += $(FATE_FILTER_SAMPLES-yes)
 FATE_FFMPEG += $(FATE_FILTER-yes)
diff --git a/tests/ref/fate/filter-refcmp-psnr-rgb 
b/tests/ref/fate/filter-refcmp-psnr-rgb
new file mode 100644
index 000..367226c
--- /dev/null
+++ b/tests/ref/fate/filter-refcmp-psnr-rgb
@@ -0,0 +1,45 @@
+frame:0pts:0   pts_time:0  
+lavfi.psnr.mse.r=1678.35
+lavfi.psnr.psnr.r=15.88
+lavfi.psnr.mse.g=1118.72
+lavfi.psnr.psnr.g=17.64
+lavfi.psnr.mse.b=946.38
+lavfi.psnr.psnr.b=18.37
+lavfi.psnr.mse_avg=1247.82
+lavfi.psnr.psnr_avg=17.17
+frame:1pts:1   pts_time:1  
+lavfi.psnr.mse.r=1589.83
+lavfi.psnr.psnr.r=16.12
+lavfi.psnr.mse.g=1076.14
+lavfi.psnr.psnr.g=17.81
+lavfi.psnr.mse.b=733.06
+lavfi.psnr.psnr.b=19.48
+lavfi.psnr.mse_avg=1133.01
+lavfi.psnr.psnr_avg=17.59
+frame:2pts:2   pts_time:2  
+lavfi.psnr.mse.r=1603.11
+lavfi.psnr.psnr.r=16.08
+lavfi.psnr.mse.g=1064.91
+lavfi.psnr.psnr.g=17.86
+lavfi.psnr.mse.b=719.50
+lavfi.psnr.psnr.b=19.56
+lavfi.psnr.mse_avg=1129.17
+lavfi.psnr.psnr_avg=17.60
+frame:3pts:3   pts_time:3  
+lavfi.psnr.mse.r=1640.67
+lavfi.psnr.psnr.r=15.98
+lavfi.psnr.mse.g=1040.98
+lavfi.psnr.psnr.g=17.96
+lavfi.psnr.mse.b=717.82
+lavfi.psnr.psnr.b=19.57
+lavfi.psnr.mse_avg=1133.16
+lavfi.psnr.psnr_avg=17.59
+frame:4pts:4   pts_time:4  
+lavfi.psnr.mse.r=1691.15
+lavfi.psnr.psnr.r=15.85
+lavfi.psnr.mse.g=962.75
+lavfi.psnr.psnr.g=18.30
+lavfi.psnr.mse.b=775.03
+lavfi.psnr.psnr.b=19.24
+lavfi.psnr.mse_avg=1142.98
+lavfi.psnr.psnr_avg=17.55
diff --git a/tests/ref/fate/filter-refcmp-psnr-yuv 
b/tests/ref/fate/filter-refcmp-psnr-yuv
new file mode 100644
index 000..916580f
--- /dev/null
+++ b/tests/ref/fate/filter-refcmp-psnr-yuv
@@ -0,0 +1,45 @@
+frame:0pts:0   pts_time:0  
+lavfi.psnr.mse.y=434.61
+lavfi.psnr.psnr.y=21.75
+lavfi.psnr.mse.u=392.27
+lavfi.psnr.psnr.u=22.19
+lavfi.psnr.mse.v=679.26
+lavfi.psnr.psnr.v=19.81
+lavfi.psnr.mse_avg=485.19
+lavfi.psnr.psnr_avg=21.27
+frame:1pts:1   pts_time:1  
+lavfi.psnr.mse.y=386.12
+lavfi.psnr.psnr.y=22.26
+lavfi.psnr.mse.u=355.19
+lavfi.psnr.psnr.u=22.63
+lavfi.psnr.mse.v=683.13
+lavfi.psnr.psnr.v=19.79
+lavfi.psnr.mse_avg=452.64
+lavfi.psnr.psnr_avg=21.57
+frame:2pts:2   pts_time:2  
+lavfi.psnr.mse.y=407.59
+lavfi.psnr.psnr.y=22.03
+lavfi.psnr.mse.u=307.40
+lavfi.psnr.psnr.u=23.25
+lavfi.psnr.mse.v=680.56
+lavfi.psnr.psnr.v=19.80
+lavfi.psnr.mse_avg=450.78
+lavfi.psnr.psnr_avg=21.59
+frame:3pts:3   pts_time:3  
+lavfi.psnr.mse.y=420.90
+lavfi.psnr.psnr.y=21.89
+lavfi.psnr.mse.u=295.22
+lavfi.psnr.psnr.u=23.43
+lavfi.psnr.mse.v=676.06
+lavfi.psnr.psnr.v=19.83
+lavfi.psnr.mse_avg=453.27
+lavfi.psnr.psnr_avg=21.57
+frame:4pts:4   pts_time:4 

Re: [FFmpeg-devel] [PATCH 1/3 v2] avutil: merge slice threading implementation from avcodec and avfilter

[Muhammad Faiz]

On Tue, Jul 18, 2017 at 2:14 PM, Muhammad Faiz  wrote:
> On Wed, Jul 12, 2017 at 8:44 PM, Muhammad Faiz  wrote:
>> Rework it to improve performance. Now mutex is not shared by workers,
>> instead each worker has its own mutex and condition variable. This
>> reduces lock contention between workers. Also use atomic variable for
>> counter.
>>
>> The interface also allows execute to run special function on main
>> thread, requested by Ronald.
>>
>> Signed-off-by: Muhammad Faiz 
>> ---
>>  libavutil/Makefile  |   1 +
>>  libavutil/slicethread.c | 259 
>> 
>>  libavutil/slicethread.h |  52 ++
>>  3 files changed, 312 insertions(+)
>>  create mode 100644 libavutil/slicethread.c
>>  create mode 100644 libavutil/slicethread.h
>>
>
> I'm going to push the patchset tomorrow.
>
> Thank's

Applied, also update libavutil version.

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

Re: [FFmpeg-devel] [PATCHv2 1/2] avdevice/decklink_dec: add support for decoding teletext from 10bit ancillary data

[John Warburton]

On Tue, Jul 18, 2017 at 6:10 PM, Marton Balint  wrote:
> On Sat, 8 Jul 2017, Marton Balint wrote:
>
>> This also add supports for 4K DeckLink cards because they always output the
>> ancillary data in 10-bit.
>>
>> v2:
>> - only try teletext decoding for 576i PAL mode
>> - some comments as requested by Aaron Levinson
>>
>> Signed-off-by: Marton Balint 
>
> Applied the series, thanks for all the comments.

Since this patch was applied, the mingw-w64 compiler, gcc version
6.4.1, fails to link shared library avdevice-57.dll, giving the
following error. It is as if the const uint8_t ff_reverse[256] that is
found in libavutil/reverse.c somehow isn't being discovered by the
linker. I'm afraid my knowledge beyond this point is zero.

libavdevice/decklink_dec.o:decklink_dec.cpp:(.rdata$.refptr.ff_reverse[.refptr.ff_reverse]+0x0):
undefined reference to `ff_reverse'
collect2: error: ld returned 1 exit status
ffbuild/library.mak:101: recipe for target 'libavdevice/avdevice-57.dll' failed
make: *** [libavdevice/avdevice-57.dll] Error 1
Build failure. Please see error messages above.

Kind regards,
John Warburton
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] libavformat/fifo: Fix initialization of underlying AVFormatContext

[Jan Sebechlebsky]

On 07/13/2017 01:15 PM, Jan Sebechlebsky wrote:


I'll apply the patch in a few days with modified commit message.

Jan

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

Re: [FFmpeg-devel] [PATCH v2 1/2] avcodec: add Dolby E decoder

[Paul B Mahol]

On 7/1/17, foo86  wrote:
> ---
>  configure   |   1 +
>  doc/general.texi|   1 +
>  libavcodec/Makefile |   1 +
>  libavcodec/allcodecs.c  |   1 +
>  libavcodec/avcodec.h|   1 +
>  libavcodec/codec_desc.c |   7 +
>  libavcodec/dolby_e.c| 707
> ++
>  libavcodec/dolby_e.h| 733
> 
>  libavcodec/version.h|   4 +-
>  9 files changed, 1454 insertions(+), 2 deletions(-)
>  create mode 100644 libavcodec/dolby_e.c
>  create mode 100644 libavcodec/dolby_e.h
>

I gonna apply this soon.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 1/2] libavfilter/scale: More descriptive in/ref/out logging

[Kevin Mark]

Hello all,

Just wondering if anyone had any thoughts on the grepability issue,
which I believe is the only potential issue/breaking change with this
patch.

Thanks,
Kevin

On Sun, Jun 11, 2017 at 9:59 PM, Kevin Mark  wrote:
> Hi Michael,
>
> Hoping to get your thoughts on the grepability issue (wrt my previous
> email). If it needs to be on a single line there's no reason the new format
> cannot be changed to do so (removing the \n and adding a separator, really).
> However I'm a big fan of it as-is (for both scale and scale2ref) and I can't
> find a case of my own where the regex I proposed would be troublesome.
>
> Thanks,
> Kevin
>
> On Tue, Jun 6, 2017 at 4:17 PM Kevin Mark  wrote:
>>
>> On Tue, Jun 6, 2017 at 11:49 AM, Michael Niedermayer
>>  wrote:
>> > yes but its much harder to grep for as its not a single line anymore
>>
>> I agree that it's not going to be as pretty a regular expression to
>> grep through, as there is 33% more data, but it should still be doable
>> without too much effort. How important is it that we maintain "API"
>> compatibility on verbose CLI output?
>>
>> ffmpeg [...] scale2ref=0:0 [...] -v verbose - 2>&1 >/dev/null | grep -oP
>> 'regex'
>>
>> Where regex is:
>>
>> (in|out|ref) +w:(\d+) h:(\d+) fmt:(\w+) sar:(\d+)\/(\d+)(?:
>> flags:0x[[:xdigit:]]+)?
>>
>> Assuming GNU grep 2.25+, you'll get:
>>
>> in  w:320 h:240 fmt:rgb24 sar:1/1
>> ref w:640 h:360 fmt:rgb24 sar:1/1
>> out w:640 h:360 fmt:rgb24 sar:3/4 flags:0x2
>>
>> It also works with BSD grep 2.5.1-FreeBSD included in macOS if you use
>> the -E option instead of -P. These would be considered three separate
>> matches so if you're using a good regex engine it'd be pretty easy to
>> loop over each match, check the first group to determine if it's in,
>> ref, or out and act accordingly on the rest of the captured data. You
>> could also, if you wanted, assume that the first line is in and the
>> second line is out if you only have two matches (or lines even) and if
>> you have three matches/lines the first is in, second is ref, third is
>> out. If you needed it to work with less sophisticated engines it
>> shouldn't be too hard to dumb down the regex above.
>>
>> Live-ish example: https://regex101.com/r/wvHLpa/1
>>
>> Is there a special property that makes single lines much easier to
>> grep? Something specific to bash? I wouldn't think bash would have any
>> problems looping over this by line.
>>
>> Thanks,
>> Kevin
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH] avfilter: Add blue and violet noise generation filters

[george]

From: George Boyle 

For the blue and violet noise, I took the pink and brown noise
respectively and subtracted the offsets instead of adding them. When I
eyeball the frequency spectrum of the resulting outputs it looks correct
to me, i.e. the blue graph appears to be a mirror image of the pink, and
the same can be said of the violet and the brown. I did not do anything
else to confirm the correctness.
---
 doc/filters.texi |  4 ++--
 libavfilter/asrc_anoisesrc.c | 41 +++--
 2 files changed, 37 insertions(+), 8 deletions(-)

diff --git a/doc/filters.texi b/doc/filters.texi
index 2708fdb1df..dd88636bb9 100644
--- a/doc/filters.texi
+++ b/doc/filters.texi
@@ -4471,8 +4471,8 @@ Specify the duration of the generated audio stream. Not 
specifying this option
 results in noise with an infinite length.
 
 @item color, colour, c
-Specify the color of noise. Available noise colors are white, pink, and brown.
-Default color is white.
+Specify the color of noise. Available noise colors are white, pink, brown,
+blue and violet. Default color is white.
 
 @item seed, s
 Specify a value used to seed the PRNG.
diff --git a/libavfilter/asrc_anoisesrc.c b/libavfilter/asrc_anoisesrc.c
index be0d5ab6a5..b60fdfe331 100644
--- a/libavfilter/asrc_anoisesrc.c
+++ b/libavfilter/asrc_anoisesrc.c
@@ -51,12 +51,14 @@ static const AVOption anoisesrc_options[] = {
 { "a","set amplitude",OFFSET(amplitude),
AV_OPT_TYPE_DOUBLE,{.dbl = 1.}, 0.,  1., FLAGS },
 { "duration", "set duration", OFFSET(duration), 
AV_OPT_TYPE_DURATION,  {.i64 =  0},  0,  INT64_MAX,  FLAGS },
 { "d","set duration", OFFSET(duration), 
AV_OPT_TYPE_DURATION,  {.i64 =  0},  0,  INT64_MAX,  FLAGS },
-{ "color","set noise color",  OFFSET(color),
AV_OPT_TYPE_INT,   {.i64 =  1},  0,  2,  FLAGS, "color" },
-{ "colour",   "set noise color",  OFFSET(color),
AV_OPT_TYPE_INT,   {.i64 =  1},  0,  2,  FLAGS, "color" },
-{ "c","set noise color",  OFFSET(color),
AV_OPT_TYPE_INT,   {.i64 =  0},  0,  2,  FLAGS, "color" },
+{ "color","set noise color",  OFFSET(color),
AV_OPT_TYPE_INT,   {.i64 =  1},  0,  4,  FLAGS, "color" },
+{ "colour",   "set noise color",  OFFSET(color),
AV_OPT_TYPE_INT,   {.i64 =  1},  0,  4,  FLAGS, "color" },
+{ "c","set noise color",  OFFSET(color),
AV_OPT_TYPE_INT,   {.i64 =  0},  0,  4,  FLAGS, "color" },
 { "white",0,  0,
AV_OPT_TYPE_CONST, {.i64 =  0},  0,  0,  FLAGS, "color" },
 { "pink", 0,  0,
AV_OPT_TYPE_CONST, {.i64 =  1},  0,  0,  FLAGS, "color" },
 { "brown",0,  0,
AV_OPT_TYPE_CONST, {.i64 =  2},  0,  0,  FLAGS, "color" },
+{ "blue", 0,  0,
AV_OPT_TYPE_CONST, {.i64 =  3},  0,  0,  FLAGS, "color" },
+{ "violet",   0,  0,
AV_OPT_TYPE_CONST, {.i64 =  4},  0,  0,  FLAGS, "color" },
 { "seed", "set random seed",  OFFSET(seed), 
AV_OPT_TYPE_INT64, {.i64 = -1}, -1,  UINT_MAX,   FLAGS },
 { "s","set random seed",  OFFSET(seed), 
AV_OPT_TYPE_INT64, {.i64 = -1}, -1,  UINT_MAX,   FLAGS },
 { "nb_samples",   "set the number of samples per requested frame", 
OFFSET(nb_samples), AV_OPT_TYPE_INT, {.i64 = 1024}, 1, INT_MAX, FLAGS },
@@ -121,6 +123,22 @@ static double pink_filter(double white, double *buf)
 return pink * 0.11;
 }
 
+static double blue_filter(double white, double *buf)
+{
+double blue;
+
+/* Same as pink_filter but subtract the offsets rather than add */
+buf[0] = 0.0555179 * white - 0.99886 * buf[0];
+buf[1] = 0.0750759 * white - 0.99332 * buf[1];
+buf[2] = 0.1538520 * white - 0.96900 * buf[2];
+buf[3] = 0.3104856 * white - 0.86650 * buf[3];
+buf[4] = 0.5329522 * white - 0.55000 * buf[4];
+buf[5] = -0.016898 * white + 0.76160 * buf[5];
+blue = buf[0] + buf[1] + buf[2] + buf[3] + buf[4] + buf[5] + buf[6] + 
white * 0.5362;
+buf[6] = white * 0.115926;
+return blue * 0.11;
+}
+
 static double brown_filter(double white, double *buf)
 {
 double brown;
@@ -130,6 +148,15 @@ static double brown_filter(double white, double *buf)
 return brown * 3.5;
 }
 
+static double violet_filter(double white, double *buf)
+{
+double violet;
+
+violet = ((0.02 * white) - buf[0]) / 1.02;
+buf[0] = violet;
+return violet * 3.5;
+}
+
 static av_cold int config_props(AVFilterLink *outlink)
 {
 AVFilterContext *ctx = outlink->src;
@@ -144,9 +171,11 @@ static