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

[Michael Niedermayer]

On Fri, May 11, 2018 at 04:03:07PM +0200, Paul B Mahol wrote:
> Signed-off-by: Paul B Mahol 
> ---
>  libavfilter/Makefile |1 +
>  libavfilter/allfilters.c |1 +
>  libavfilter/vf_bm3d.c| 1002 
> ++
>  3 files changed, 1004 insertions(+)
>  create mode 100644 libavfilter/vf_bm3d.c
[...]
> +static void block_matching_multi(BM3DContext *s, const uint8_t *ref, int 
> ref_linesize, int y, int x,
> + int exclude_cur_pos, int plane)
> +{
> +const int width = s->planewidth[plane];
> +const int height = s->planeheight[plane];
> +const int block_size = s->block_size;
> +const int step = s->bm_step;
> +const int range = s->bm_range / step * step;
> +int l = search_boundary(0, range, step, 0, y, x);
> +int r = search_boundary(width - block_size, range, step, 0, y, x);
> +int t = search_boundary(0, range, step, 1, y, x);
> +int b = search_boundary(height - block_size, range, step, 1, y, x);
> +int j, i, index = 0;
> +
> +PosCode search_pos[((r - l) / step + 1) * ((b - t) / step + 1)];

fails to build here:

src/libavfilter/vf_bm3d.c: In function ‘block_matching_multi’:
src/libavfilter/vf_bm3d.c:308:5: error: variable length array ‘search_pos’ is 
used [-Werror=vla]
 PosCode search_pos[((r - l) / step + 1) * ((b - t) / step + 1)];
 ^


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

Does the universe only have a finite lifespan? No, its going to go on
forever, its just that you wont like living in it. -- Hiranya Peiri


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

Re: [FFmpeg-devel] [PATCH 10/13] avformat/mxfenc: Set color siting to 0 for D10-MXF

[Michael Niedermayer]

On Tue, May 08, 2018 at 07:41:33PM +0200, Michael Niedermayer wrote:
> On Tue, May 08, 2018 at 12:55:18PM +0200, Tomas Härdin wrote:
> > mån 2018-05-07 klockan 12:38 +0200 skrev Michael Niedermayer:
> > > > Signed-off-by: Michael Niedermayer 
> > > ---
> > >  libavformat/mxfenc.c  |   1 +
> > >  .../ref/fate/concat-demuxer-extended-lavf-mxf |   2 +-
> > >  .../fate/concat-demuxer-extended-lavf-mxf_d10 |   2 +-
> > >  .../ref/fate/concat-demuxer-simple1-lavf-mxf  | 242 +-
> > >  .../fate/concat-demuxer-simple1-lavf-mxf_d10  | 140 +-
> > >  tests/ref/seek/lavf-mxf   |  44 ++--
> > >  tests/ref/seek/lavf-mxf_d10   |  54 ++--
> > >  tests/ref/seek/lavf-mxf_dv25  |  54 ++--
> > >  tests/ref/seek/lavf-mxf_dvcpro50  |  54 ++--
> > >  tests/ref/seek/lavf-mxf_opatom|  54 ++--
> > >  tests/ref/seek/lavf-mxf_opatom_audio  |  54 ++--
> > >  11 files changed, 351 insertions(+), 350 deletions(-)
> > > 
> > > diff --git a/libavformat/mxfenc.c b/libavformat/mxfenc.c
> > > index f2be76cc86..adf5527534 100644
> > > --- a/libavformat/mxfenc.c
> > > +++ b/libavformat/mxfenc.c
> > > @@ -2361,6 +2361,7 @@ static int mxf_write_header(AVFormatContext *s)
> > >  mxf->edit_unit_byte_count += 
> > > klv_fill_size(mxf->edit_unit_byte_count);
> > >  
> > >  sc->signal_standard = 1;
> > > +sc->color_siting = 0;
> > >  }
> > 
> > Can't find anything in my documents that says anything about this. I
> > don't remember what D-10 is actually specified in...
> 
> SMPTE 386M (D-10) lists 4 as value to be used
> SMPTE 377-1-2009 says 
> "The definitions of 00h (coSiting) and 04h (Rec 601) are equivalent. The 
> value of 04h is deprecated. New
>  MXF encoders shall use the value of 00h instead."
> 
> I will add this to the commit message

will apply

[...]


-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

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


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

Re: [FFmpeg-devel] [PATCH] lavc/amfenc: moving amf common code (library and context) to lavu/hwcontext_amf from amfenc to be reused in other amf components

[Alexander Kravchenko]

Hi Mark, 
Thank you for your comments.
Could you see my comments and questions bellow

> -Original Message-
> From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf Of Mark 
> Thompson
> Sent: Thursday, May 10, 2018 11:43 PM
> To: ffmpeg-devel@ffmpeg.org
> Subject: Re: [FFmpeg-devel] [PATCH] lavc/amfenc: moving amf common code 
> (library and context) to lavu/hwcontext_amf from
> amfenc to be reused in other amf components
> 

> > +static AVBufferRef *amf_library_ctx = NULL;
> 
> Global mutable state in libraries is strongly discouraged.  Just loading it 
> again should be fine?
> 

Yes, loading it again could be fine.
I wanted to prevent additional call of library loading and trace 
initializations every time amf_device context is created.
User can create many instances of encoder in one process. 
Storing amf_library_ctx allows to detect when cleanup functions can be called 
(UnregisterWriter...). Of course we can never call dclose and keep library 
loaded all time.
What is your opinion?

> > +
> > +#include "frame.h"
> > +#include "AMF/core/Context.h"
> > +#include "AMF/core/Factory.h"
> > +
> > +
> > +/**
> > + * This struct is allocated as AVHWDeviceContext.hwctx  */ typedef
> > +struct AVAMFDeviceContext {
> > +AMFContext *context;
> > +AMFFactory *factory;
> 
> Do you actually need both of these?  It feels like you should be able to 
> derive the creating factory (/ library instance) from the context.
> 

AMFContext does not have pointer to AMFFactory. Now AMFFactory -> 
CreateComponent is used in encoder initialization.
May be AMFFactory is too wide interface on this level. Pointer to function like 
CreateComponent can be published in AVAMFDeviceContext instead of factory 
pointer.
or did you mean something different?

--
I have another question about publish amf library level options (Trace level, 
trace writers...). This could be in another patch if we decide this option is 
possible.
What is the best way to add such option? Can command line options be used to 
configure library? Or somehow publish this API?

Thanks,
Alexander



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

[FFmpeg-devel] [PATCH] avfilter/vf_nlmeans: add parameter to control weight of centered pixel

[Paul B Mahol]

Signed-off-by: Paul B Mahol 
---
 libavfilter/vf_nlmeans.c | 10 ++
 1 file changed, 6 insertions(+), 4 deletions(-)

diff --git a/libavfilter/vf_nlmeans.c b/libavfilter/vf_nlmeans.c
index 82e779ce85..872fa90e28 100644
--- a/libavfilter/vf_nlmeans.c
+++ b/libavfilter/vf_nlmeans.c
@@ -52,6 +52,7 @@ typedef struct NLMeansContext {
 int chroma_w, chroma_h;
 double pdiff_scale; // invert of the filtering 
parameter (sigma*10) squared
 double sigma;   // denoising strength
+float amount;   // amount of denoising
 int patch_size,patch_hsize; // patch size and half size
 int patch_size_uv, patch_hsize_uv;  // patch size and half size 
for chroma planes
 int research_size,research_hsize;   // research size and half size
@@ -76,6 +77,7 @@ static const AVOption nlmeans_options[] = {
 { "pc", "patch size for chroma planes", OFFSET(patch_size_uv), 
AV_OPT_TYPE_INT, { .i64 = 0 }, 0, 99, FLAGS },
 { "r",  "research window",   OFFSET(research_size),
AV_OPT_TYPE_INT, { .i64 = 7*2+1 }, 0, 99, FLAGS },
 { "rc", "research window for chroma planes", OFFSET(research_size_uv), 
AV_OPT_TYPE_INT, { .i64 = 0 }, 0, 99, FLAGS },
+{ "a",  "denoising amount", OFFSET(amount), AV_OPT_TYPE_FLOAT, { .dbl = 
1.0 }, 0.01,  1.0, FLAGS },
 { NULL }
 };
 
@@ -415,15 +417,15 @@ static int nlmeans_slice(AVFilterContext *ctx, void *arg, 
int jobnr, int nb_jobs
 static void weight_averages(uint8_t *dst, ptrdiff_t dst_linesize,
 const uint8_t *src, ptrdiff_t src_linesize,
 struct weighted_avg *wa, ptrdiff_t wa_linesize,
-int w, int h)
+int w, int h, float amount)
 {
 int x, y;
 
 for (y = 0; y < h; y++) {
 for (x = 0; x < w; x++) {
 // Also weight the centered pixel
-wa[x].total_weight += 1.f;
-wa[x].sum += 1.f * src[x];
+wa[x].total_weight += amount;
+wa[x].sum += amount * src[x];
 dst[x] = av_clip_uint8(wa[x].sum / wa[x].total_weight);
 }
 dst += dst_linesize;
@@ -470,7 +472,7 @@ static int nlmeans_plane(AVFilterContext *ctx, int w, int 
h, int p, int r,
 }
 
 weight_averages(dst, dst_linesize, src, src_linesize,
-s->wa, s->wa_linesize, w, h);
+s->wa, s->wa_linesize, w, h, 1.f / s->amount);
 
 return 0;
 }
-- 
2.11.0

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

Re: [FFmpeg-devel] [PATCH] Support for Ambisonics and OpusProjection* API.

[Rostislav Pehlivanov]

On 11 May 2018 at 15:55, Drew Allen 
wrote:

> Hi Rostislav et all,
>
> The IETF document has just been moved to a working group last call.
>
> Do you think it would it be possible to land this patch under an
> experimental flag?


No, libopus itself still hides the new API under an experimental flag. We
also don't do experimental flags for decoders and there's no API yet to
signal a channel layout is ambisonics.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 4/4] lavc/cbs_h2645: fix no slice data trigger the assert.

[James Almer]

On 5/11/2018 7:10 AM, Mark Thompson wrote:
> On 11/05/18 06:11, Jun Zhao wrote:
>> when the NALU data with zero, just give a warning.
>>
>> Fixes ticket #7200
>>
>> Signed-off-by: Jun Zhao 
>> ---
>>  libavcodec/cbs_h2645.c | 6 +-
>>  1 file changed, 5 insertions(+), 1 deletion(-)
>>
>> diff --git a/libavcodec/cbs_h2645.c b/libavcodec/cbs_h2645.c
>> index ab33cdb..08b060c 100644
>> --- a/libavcodec/cbs_h2645.c
>> +++ b/libavcodec/cbs_h2645.c
>> @@ -521,7 +521,11 @@ static int 
>> cbs_h2645_fragment_add_nals(CodedBitstreamContext *ctx,
>>  // Remove trailing zeroes.
>>  while (size > 0 && nal->data[size - 1] == 0)
>>  --size;
>> -av_assert0(size > 0);
>> +if (!size) {
>> +av_log(ctx->log_ctx, AV_LOG_WARNING, "No slice data - that was 
>> just the header. "
>> +   "Probably invalid unaligned padding on non-final NAL 
>> unit.\n");
>> +continue;
>> +}
>>  
>>  data = av_malloc(size + AV_INPUT_BUFFER_PADDING_SIZE);
>>  if (!data)
>>
> 
> What do we actually want the result to be here?
> 
> On IRC, James suggested:
> 
>> diff --git a/libavcodec/h2645_parse.c b/libavcodec/h2645_parse.c
>> index dbf2435677..d436d65f48 100644
>> --- a/libavcodec/h2645_parse.c
>> +++ b/libavcodec/h2645_parse.c
>> @@ -371,7 +371,7 @@ int ff_h2645_packet_split(H2645Packet *pkt, const 
>> uint8_t *buf, int length,
>>  ret = hevc_parse_nal_header(nal, logctx);
>>  else
>>  ret = h264_parse_nal_header(nal, logctx);
>> -if (ret <= 0 || nal->size <= 0) {
>> +if (ret <= 0 || nal->size <= 0 || nal->size_bits <= 0) {
>>  if (ret < 0) {
>>  av_log(logctx, AV_LOG_ERROR, "Invalid NAL unit %d, 
>> skipping.\n",
>> nal->type);
> 
> which removes it before it gets to the CBS code.
> 
> Another thing we could do is:
> 
>> diff --git a/libavcodec/cbs_h2645.c b/libavcodec/cbs_h2645.c
>> index ab33cdb69b..46cd887cdd 100644
>> --- a/libavcodec/cbs_h2645.c
>> +++ b/libavcodec/cbs_h2645.c
>> @@ -519,7 +519,7 @@ static int 
>> cbs_h2645_fragment_add_nals(CodedBitstreamContext *ctx,
>>  uint8_t *data;
>>  
>>  // Remove trailing zeroes.
>> -while (size > 0 && nal->data[size - 1] == 0)
>> +while (size > 1 && nal->data[size - 1] == 0)
>>  --size;
>>  av_assert0(size > 0);
>>  
> 
> which would make it parse as an empty NAL unit of type 0 (unspecified), and 
> therefore pass through into the output stream in the h264_metadata case.
> 
> So, what do you think?  Do you know what made your sample stream?
> 
> - Mark

Taking into account the analysis by mkver in the trac ticket, where he
found out the bitstream contains "00 00 00 01 00 00 00 01" with the
second start code being a real valid NAL, i think this should definitely
be fixed in h2645_parse. No reason to propagate a non existent NAL like
this.
We should either use my fix, or another that actually prevents nal->size
from inexplicably becoming 1 in this scenario.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] Support for Ambisonics and OpusProjection* API.

[Drew Allen]

Hi Rostislav et all,

The IETF document has just been moved to a working group last call.

Do you think it would it be possible to land this patch under an
experimental flag?

Cheers,
Drew

On Mon, Apr 23, 2018 at 12:28 PM Rostislav Pehlivanov 
wrote:

> On 23 April 2018 at 17:02, Drew Allen 
> wrote:
>
> > We have spent the past 2 years with the draft relatively unchanged aside
> > from minor edits on the draft. It is headed to a working group for
> > finalization very soon and no one has yet raised a single issue regarding
> > any proposed changes that this patch introduces. I wrote the
> > OpusProjection* API and it has been adopted in all Opus-related xiph
> master
> > branches.
> >
>
> Good to hear. I know the IETF can take an extraordinarily long amount of
> time to publish a draft and make it an RFC and wish you all the luck on
> getting it completed quickly.
>
>
> I worked closely with Jean-Marc Valin to design the API in Opus 1.3 to his
> > specification. Opus 1.3 beta already contains this new API and upon
> > release, I have 100% assurance from Jean-Marc that the OpusProjection*
> API
> > will be supported in 1.3 RC.
> >
>
> ...hidden behind a configure flag and not enabled by default. No one will
> enable it until its ready and becomes accepted, which is why it isn't
> enabled by default.
>
>
>
> > I disagree that a filter or some other layer of abstraction is necessary
> > here. OpusProjection* does not code the ambisonic channels directly.
> > Instead, they are mixed using a mixing matrix that minimizes coding
> > artifacts over the sphere. The demixing matrix on the decoder is vital in
> > order to get back the original ambisonic channels and
> OpusProjectionDecoder
> > handles this automatically.
> >
>
> Ah, okay. In which case what we need still is an API to signal the
> ambisonics order and any other metadata needed. We can't just say "here's a
> frame with a bunch of channels, based on their numer you could probably
> figure its some ambisonics" and clients shouldn't use heuristics like "this
> frame has 16 channels, its probably ambisonics". This information needs to
> be indicated properly.
>
>
> I completely disagree. The IETF draft has been stable for over a year and
> > these same changes to support the new API are already present in Opus,
> > libopusenc, opusfile and opus-tools.
>
>
> Stable != accepted. The option to enable the API is still hidden behind a
> configure flag for libopus. And it will remain like this until it becomes
> an RFC, just like the previous RFC which butc... updated the codec with
> some fixes.
>
> If libopus had the new API enabled by default I wouldn't mind this patch at
> all and would apply it, since I'd be sure it wouldn't change. But as it
> stands, both it and the signalling changes in the RFC can change at any
> time despite being stable by yourself.
>
> Also your mail client stripped the quote marks and made things confusing.
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [RFC] On behaviour of unlabelled outputs in filtergraphs.

[Nicolas George]

Gyan Doshi (2018-05-11):
> Other points noted, but I still think this should throw an error and
> exit_program. Explicit inclusions should not be mixed with implicit ones,
> given how map is described to the user.

On principle, I think I agree. But since it is already working
differently, I think printing a warning would be better. Note that once
we have a warning for some time, we can more safely change it into an
error.

Regards,

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

[FFmpeg-devel] [PATCH] avfilter: add bm3d filter

[Paul B Mahol]

Signed-off-by: Paul B Mahol 
---
 libavfilter/Makefile |1 +
 libavfilter/allfilters.c |1 +
 libavfilter/vf_bm3d.c| 1002 ++
 3 files changed, 1004 insertions(+)
 create mode 100644 libavfilter/vf_bm3d.c

diff --git a/libavfilter/Makefile b/libavfilter/Makefile
index 92f526a275..b2d6756e79 100644
--- a/libavfilter/Makefile
+++ b/libavfilter/Makefile
@@ -150,6 +150,7 @@ OBJS-$(CONFIG_BITPLANENOISE_FILTER)  += 
vf_bitplanenoise.o
 OBJS-$(CONFIG_BLACKDETECT_FILTER)+= vf_blackdetect.o
 OBJS-$(CONFIG_BLACKFRAME_FILTER) += vf_blackframe.o
 OBJS-$(CONFIG_BLEND_FILTER)  += vf_blend.o framesync.o
+OBJS-$(CONFIG_BM3D_FILTER)   += vf_bm3d.o
 OBJS-$(CONFIG_BOXBLUR_FILTER)+= vf_boxblur.o
 OBJS-$(CONFIG_BWDIF_FILTER)  += vf_bwdif.o
 OBJS-$(CONFIG_CHROMAKEY_FILTER)  += vf_chromakey.o
diff --git a/libavfilter/allfilters.c b/libavfilter/allfilters.c
index f3a76c4652..f28f6e47ee 100644
--- a/libavfilter/allfilters.c
+++ b/libavfilter/allfilters.c
@@ -143,6 +143,7 @@ extern AVFilter ff_vf_bitplanenoise;
 extern AVFilter ff_vf_blackdetect;
 extern AVFilter ff_vf_blackframe;
 extern AVFilter ff_vf_blend;
+extern AVFilter ff_vf_bm3d;
 extern AVFilter ff_vf_boxblur;
 extern AVFilter ff_vf_bwdif;
 extern AVFilter ff_vf_chromakey;
diff --git a/libavfilter/vf_bm3d.c b/libavfilter/vf_bm3d.c
new file mode 100644
index 00..61f9db17e3
--- /dev/null
+++ b/libavfilter/vf_bm3d.c
@@ -0,0 +1,1002 @@
+/*
+ * Copyright (c) 2015-2016 mawen1250
+ * Copyright (c) 2018 Paul B Mahol
+ *
+ * This file is part of FFmpeg.
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a copy
+ * of this software and associated documentation files (the "Software"), to 
deal
+ * in the Software without restriction, including without limitation the rights
+ * to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
+ * copies of the Software, and to permit persons to whom the Software is
+ * furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice shall be included in 
all
+ * copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
+ * AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING 
FROM,
+ * OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN 
THE
+ * SOFTWARE.
+ */
+
+/**
+ * @todo
+ * - non-power of 2 DCT
+ * - slice threading
+ * - opponent color space
+ * - temporal support
+ * - documentation
+ */
+
+#include 
+
+#include "libavutil/avassert.h"
+#include "libavutil/imgutils.h"
+#include "libavutil/opt.h"
+#include "libavutil/pixdesc.h"
+#include "libavcodec/avfft.h"
+#include "avfilter.h"
+#include "filters.h"
+#include "formats.h"
+#include "framesync.h"
+#include "internal.h"
+#include "video.h"
+
+enum FilterModes {
+BASIC,
+FINAL,
+NB_MODES,
+};
+
+typedef struct PosCode {
+int x, y;
+} PosCode;
+
+typedef struct PosPairCode {
+double score;
+int x, y;
+} PosPairCode;
+
+typedef struct BM3DContext {
+const AVClass *class;
+
+float sigma;
+int block_size;
+int block_step;
+int group_size;
+int bm_range;
+int bm_step;
+float th_mse;
+float hard_threshold;
+int mode;
+int ref;
+int planes;
+
+int depth;
+int max;
+int nb_planes;
+int planewidth[4];
+int planeheight[4];
+int group_bits;
+int pgroup_size;
+
+DCTContext *gdctf, *gdcti;
+DCTContext *dctf, *dcti;
+FFTSample *bufferh;
+FFTSample *bufferv;
+FFTSample *bufferz;
+FFTSample *buffer;
+FFTSample *rbufferh;
+FFTSample *rbufferv;
+FFTSample *rbufferz;
+FFTSample *rbuffer;
+float *num, *den;
+PosPairCode match_codes[256];
+int nb_match_codes;
+
+FFFrameSync fs;
+
+void (*get_block_row)(const uint8_t *srcp, int src_linesize,
+  int y, int x, int block_size, float *dst);
+double (*do_block_ssd)(struct BM3DContext *s, PosCode *pos,
+   const uint8_t *src, int src_stride,
+   int r_y, int r_x);
+void (*do_output)(struct BM3DContext *s, uint8_t *dst, int dst_linesize, 
int plane);
+void (*block_filtering)(struct BM3DContext *s, const uint8_t *src, int 
src_linesize,
+const uint8_t *ref, int ref_linesize,
+int y, int x, int plane);
+} BM3DContext;
+
+#define OFFSET(x) offsetof(BM3DContext, x)
+#define FLAGS AV_OPT_FLAG_FILTERING_PARAM|AV_OPT_FLAG_VIDEO_PARAM
+static const 

Re: [FFmpeg-devel] [PATCH 5/5] ffserver: Add basic documentation of the architecture

[Stephan Holljes]

On Fri, May 11, 2018 at 2:54 PM, Moritz Barsnick  wrote:
> On Thu, May 10, 2018 at 17:41:26 +0200, Stephan Holljes wrote:
>> +In its current for this is a HTTP live-streaming server. A media file can be
> ^ form^ an
>
>> +streamed to a number of clients with the correct media file being muxed on-
>> +the-fly for each client starting at the current position in the stream.
>
> I don't understand: What's "correct"? And what is the "current
> position"? From ffserver's point of view: The position if progressed to
> between launch and connection of client?

"correct" was probably the wrong word here. I have replaced it locally
by "a proper" instead of "the correct", although it feels unnecessary
in general. I might reword this.
The "current position" is, as you described, the position ffserver has
progressed to with reading the input since starting the program +
configurable buffering (so client's don't "stutter" during playback).
I will try to make that a bit clearer.

>
>> +The stream received by the clients is simply a HTTP response to an HTTP
> ^ an   ^ here, 
> it's correct ;-)
>
>> +is answered with a HTTP 400 error.
> ^ an

I noticed these right before going to bed last night as well, fixed.

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

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

Re: [FFmpeg-devel] [RFC] On behaviour of unlabelled outputs in filtergraphs.

[Gyan Doshi]

On 5/11/2018 3:08 PM, Nicolas George wrote:


Note that the behaviour when explicit -map options are present: when
they are, automatic selection of "best" input streams is disabled, and
it would seem logical that automatic selection of unlabelled filter
outputs would be disabled too. I would not oppose adding a warning for
that case, and even in time changing the default.


Other points noted, but I still think this should throw an error and 
exit_program. Explicit inclusions should not be mixed with implicit 
ones, given how map is described to the user.


I'll make the other changes to the docs.

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

Re: [FFmpeg-devel] [PATCH 4/5] ffserver: Implement ffserver and add Makefile

[Stephan Holljes]

On Fri, May 11, 2018 at 2:49 PM, Moritz Barsnick  wrote:
> On Thu, May 10, 2018 at 17:41:25 +0200, Stephan Holljes wrote:
>> +ffserver: segment.o publisher.o lavfhttpd.o ffserver.c
>> + cc -g -Wall $(LAV_FLAGS) -lpthread -o ffserver segment.o publisher.o 
>> lavfhttpd.o ffserver.c
> ^ $(CC) $(CFLAGS) to be more generic and allow overriding.
>
> The LDFLAGS "$(LAV_FLAGS) -lpthread" need to be at the end of the
> command for my compile/link chains to work. *shrug*
>
>> +clean:
>> + rm *.o ffserver
>
> Make this "rm -f" to silence warnings about non-existant files.

Ok

>
>> diff --git a/ffserver.c b/ffserver.c
>
> It may be me, but the whole thing doesn't work for me.
>
> With any MP4 file, I get:
>
> [AVIOContext @ 0xa3c3b40] {
> "free": 16,
> "reserved": 0,
> "wait": 0,
> "writable": 0,
> "busy": 0,
> "buffer_full": 0,
> "current_read": -1,
> "newest_write": 0,
> "oldest_write": -1
> }
> [mov,mp4,m4a,3gp,3g2,mj2 @ 0xa394580] Finding video stream.
> [matroska @ 0xb4319700] Tag mp4a incompatible with output codec id '86018' 
> ([255][0][0][0])
> [matroska @ 0xb4319700] Error occured while writing header: Invalid data 
> found when processing input
> Segmentation fault
>
> gdb, if it's of interest:
> Program received signal SIGSEGV, Segmentation fault.
> [Switching to Thread 0xb5717b90 (LWP 26045)]
> 0x08068d6d in compute_muxer_pkt_fields (s=0xb4c19240, st=0xfffe, 
> pkt=0x) at src/libavformat/mux.c:640
> 640 st->internal->priv_pts->val = pkt->dts;
>
> (ffmpeg of the same version as the libs has no issue processing the
> same file to matroska.)
>
> Using an MKV as input, it launches as such:
>
> [AVIOContext @ 0xb441e5c0] {
> "free": 16,
> "reserved": 0,
> "wait": 0,
> "writable": 0,
> "busy": 0,
> "buffer_full": 0,
> "current_read": -1,
> "newest_write": 0,
> "oldest_write": -1
> }
> [matroska,webm @ 0xa166580] Finding video stream.
> [AVIOContext @ 0xb441e5c0] Shutting down http server.
>
> "Shutting down"??? And I can't connect and play.
>
> It may just be me though. Hope this helps anyway.
>
> Moritz
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Hmm that *is* a problem. Maybe I should have used more than one file
for testing. I just tested another file and it also only worked
properly on second try. This time there was a condition I could not
reproduce the last few days:
>[matroska @ 0x55eb77169040] Application provided invalid, non monotonically 
>increasing dts to muxer in stream 0: 18894 >= 18894
I already mentioned that I'm not too sure about way I handle
timestamps. (Currently each segment has a separate dynamic array
filled with dts and pts as int64_t taken from the demuxer during
reading.)

I also tested an mp4 file and I can reproduce the error message. I'm
guessing it's "only" a metadata thing, but I know ffmpeg can mux this
without problems, so I'll investigate how to do that.

Thanks for the time, I will assemble more files for testing!
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 4/5] ffserver: Implement ffserver and add Makefile

[Moritz Barsnick]

On Fri, May 11, 2018 at 14:49:53 +0200, Moritz Barsnick wrote:
> [matroska,webm @ 0xa166580] Finding video stream.
> [AVIOContext @ 0xb441e5c0] Shutting down http server.
> 
> "Shutting down"??? And I can't connect and play.

Forget this part, my static video was too short, and I didn't realize
it gets streamed realtime, and not "served".

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

Re: [FFmpeg-devel] [PATCH 5/5] ffserver: Add basic documentation of the architecture

[Moritz Barsnick]

On Thu, May 10, 2018 at 17:41:26 +0200, Stephan Holljes wrote:
> +In its current for this is a HTTP live-streaming server. A media file can be
^ form^ an

> +streamed to a number of clients with the correct media file being muxed on-
> +the-fly for each client starting at the current position in the stream.

I don't understand: What's "correct"? And what is the "current
position"? From ffserver's point of view: The position if progressed to
between launch and connection of client?

> +The stream received by the clients is simply a HTTP response to an HTTP
^ an   ^ here, it's 
correct ;-)

> +is answered with a HTTP 400 error.
^ an

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

Re: [FFmpeg-devel] [PATCH 3/5] ffserver: Implement http interface and implementation

[Stephan Holljes]

On Fri, May 11, 2018 at 2:39 PM, Moritz Barsnick  wrote:
> On Thu, May 10, 2018 at 17:41:24 +0200, Stephan Holljes wrote:
>> +while ((handshake = avio_handshake(client_ctx)) > 0) {
>> +av_opt_get(client_ctx, "method", AV_OPT_SEARCH_CHILDREN, );
>> +av_opt_get(client_ctx, "resource", AV_OPT_SEARCH_CHILDREN, 
>> );
>
> Cast the last argument to (uint8_t **) to silence the warnings.
>
> Moritz
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Thanks! I wasn't sure about this, so fixed locally and will be part of
the next full patchset.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 4/5] ffserver: Implement ffserver and add Makefile

[Moritz Barsnick]

On Thu, May 10, 2018 at 17:41:25 +0200, Stephan Holljes wrote:
> +ffserver: segment.o publisher.o lavfhttpd.o ffserver.c
> + cc -g -Wall $(LAV_FLAGS) -lpthread -o ffserver segment.o publisher.o 
> lavfhttpd.o ffserver.c
^ $(CC) $(CFLAGS) to be more generic and allow overriding.

The LDFLAGS "$(LAV_FLAGS) -lpthread" need to be at the end of the
command for my compile/link chains to work. *shrug*

> +clean:
> + rm *.o ffserver

Make this "rm -f" to silence warnings about non-existant files.

> diff --git a/ffserver.c b/ffserver.c

It may be me, but the whole thing doesn't work for me.

With any MP4 file, I get:

[AVIOContext @ 0xa3c3b40] {
"free": 16,
"reserved": 0,
"wait": 0,
"writable": 0,
"busy": 0,
"buffer_full": 0,
"current_read": -1,
"newest_write": 0,
"oldest_write": -1
}
[mov,mp4,m4a,3gp,3g2,mj2 @ 0xa394580] Finding video stream.
[matroska @ 0xb4319700] Tag mp4a incompatible with output codec id '86018' 
([255][0][0][0])
[matroska @ 0xb4319700] Error occured while writing header: Invalid data found 
when processing input
Segmentation fault

gdb, if it's of interest:
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0xb5717b90 (LWP 26045)]
0x08068d6d in compute_muxer_pkt_fields (s=0xb4c19240, st=0xfffe, 
pkt=0x) at src/libavformat/mux.c:640
640 st->internal->priv_pts->val = pkt->dts;

(ffmpeg of the same version as the libs has no issue processing the
same file to matroska.)

Using an MKV as input, it launches as such:

[AVIOContext @ 0xb441e5c0] {
"free": 16,
"reserved": 0,
"wait": 0,
"writable": 0,
"busy": 0,
"buffer_full": 0,
"current_read": -1,
"newest_write": 0,
"oldest_write": -1
}
[matroska,webm @ 0xa166580] Finding video stream.
[AVIOContext @ 0xb441e5c0] Shutting down http server.

"Shutting down"??? And I can't connect and play.

It may just be me though. Hope this helps anyway.

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

Re: [FFmpeg-devel] [PATCH 3/5] ffserver: Implement http interface and implementation

[Moritz Barsnick]

On Thu, May 10, 2018 at 17:41:24 +0200, Stephan Holljes wrote:
> +while ((handshake = avio_handshake(client_ctx)) > 0) {
> +av_opt_get(client_ctx, "method", AV_OPT_SEARCH_CHILDREN, );
> +av_opt_get(client_ctx, "resource", AV_OPT_SEARCH_CHILDREN, 
> );

Cast the last argument to (uint8_t **) to silence the warnings.

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

Re: [FFmpeg-devel] [PATCH] qsv: Use the installed mfx include headers if possibile

[wm4]

On Fri, 11 May 2018 11:38:52 +0100
Mark Thompson  wrote:

> On 11/05/18 08:52, Haihao Xiang wrote:
> > Currently an extra copy of mfx include headers from 
> > {MSDK_INSTALL_PREFIX}/include
> > to {MSDK_INSTALL_PREFIX}/include/mfx is required when using pkg-config for
> > libmfx detection. This fix checks the installed mfx include headers first,
> > and falls back to the legacy way if that fails
> > 
> > Signed-off-by: Haihao Xiang 
> > ---
> >  configure|  3 ++-
> >  fftools/ffmpeg_qsv.c |  5 +
> >  libavcodec/qsv.c | 10 ++
> >  libavcodec/qsv.h |  4 
> >  libavcodec/qsv_internal.h|  4 
> >  libavcodec/qsvdec.c  |  4 
> >  libavcodec/qsvdec.h  |  4 
> >  libavcodec/qsvdec_h2645.c|  4 
> >  libavcodec/qsvdec_other.c|  4 
> >  libavcodec/qsvenc.c  |  5 +
> >  libavcodec/qsvenc.h  |  4 
> >  libavcodec/qsvenc_h264.c |  4 
> >  libavcodec/qsvenc_hevc.c |  4 
> >  libavcodec/qsvenc_jpeg.c |  4 
> >  libavcodec/qsvenc_mpeg2.c|  4 
> >  libavfilter/qsvvpp.h |  4 
> >  libavfilter/vf_deinterlace_qsv.c |  4 
> >  libavfilter/vf_scale_qsv.c   |  4 
> >  libavutil/hwcontext_opencl.c |  4 
> >  libavutil/hwcontext_qsv.c|  4 
> >  libavutil/hwcontext_qsv.h|  4 
> >  21 files changed, 90 insertions(+), 1 deletion(-)  
> 
> I don't think it's a good idea to put an #ifdef like this in every file.

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

Re: [FFmpeg-devel] [PATCH] qsv: Use the installed mfx include headers if possibile

[Mark Thompson]

On 11/05/18 08:52, Haihao Xiang wrote:
> Currently an extra copy of mfx include headers from 
> {MSDK_INSTALL_PREFIX}/include
> to {MSDK_INSTALL_PREFIX}/include/mfx is required when using pkg-config for
> libmfx detection. This fix checks the installed mfx include headers first,
> and falls back to the legacy way if that fails
> 
> Signed-off-by: Haihao Xiang 
> ---
>  configure|  3 ++-
>  fftools/ffmpeg_qsv.c |  5 +
>  libavcodec/qsv.c | 10 ++
>  libavcodec/qsv.h |  4 
>  libavcodec/qsv_internal.h|  4 
>  libavcodec/qsvdec.c  |  4 
>  libavcodec/qsvdec.h  |  4 
>  libavcodec/qsvdec_h2645.c|  4 
>  libavcodec/qsvdec_other.c|  4 
>  libavcodec/qsvenc.c  |  5 +
>  libavcodec/qsvenc.h  |  4 
>  libavcodec/qsvenc_h264.c |  4 
>  libavcodec/qsvenc_hevc.c |  4 
>  libavcodec/qsvenc_jpeg.c |  4 
>  libavcodec/qsvenc_mpeg2.c|  4 
>  libavfilter/qsvvpp.h |  4 
>  libavfilter/vf_deinterlace_qsv.c |  4 
>  libavfilter/vf_scale_qsv.c   |  4 
>  libavutil/hwcontext_opencl.c |  4 
>  libavutil/hwcontext_qsv.c|  4 
>  libavutil/hwcontext_qsv.h|  4 
>  21 files changed, 90 insertions(+), 1 deletion(-)

I don't think it's a good idea to put an #ifdef like this in every file.

> 
> diff --git a/configure b/configure
> index a1f13a7109..e1f72495fb 100755
> --- a/configure
> +++ b/configure
> @@ -6007,7 +6007,8 @@ enabled libkvazaar&& require_pkg_config 
> libkvazaar "kvazaar >= 0.8.1" kv
>  # Media SDK or Intel Media Server Studio, these don't come with
>  # pkg-config support.  Instead, users should make sure that the build
>  # can find the libraries and headers through other means.
> -enabled libmfx&& { check_pkg_config libmfx libmfx 
> "mfx/mfxvideo.h" MFXInit ||
> +enabled libmfx&& { { check_pkg_config libmfx libmfx "mfxvideo.h" 
> MFXInit && add_cflags -DMFX_DEFAULT_INC_PATH; } ||
> +   { check_pkg_config libmfx libmfx 
> "mfx/mfxvideo.h" MFXInit; } ||
> { require libmfx "mfx/mfxvideo.h" MFXInit 
> "-llibmfx $advapi32_extralibs" && warn "using libmfx without pkg-config"; } }
>  enabled libmodplug&& require_pkg_config libmodplug libmodplug 
> libmodplug/modplug.h ModPlug_Load
>  enabled libmp3lame&& require "libmp3lame >= 3.98.3" lame/lame.h 
> lame_set_VBR_quality -lmp3lame $libm_extralibs
So in the current code, the first test is for the open-source dispatcher 
(), which gets used everywhere that 
pkgconfig is supported, including mingw on Windows.  The second test is for 
Windows cases where you can't make make pkgconfig work.

What installs the headers directly in $PREFIX/include?  Presumably this is a 
new change - can we ask them not to do that?  (Because organising them in a 
subdirectory is I think much more sensible.)

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

Re: [FFmpeg-devel] [PATCH 3/4] lavc/h2645_parse: add h264_nal_unit_name for h264 NAL type.

[Mark Thompson]

On 11/05/18 06:11, Jun Zhao wrote:
> Signed-off-by: Jun Zhao 
> ---
>  libavcodec/h2645_parse.c | 26 --
>  1 file changed, 24 insertions(+), 2 deletions(-)
> 
> diff --git a/libavcodec/h2645_parse.c b/libavcodec/h2645_parse.c
> index 579b2c9..8d67579 100644
> --- a/libavcodec/h2645_parse.c
> +++ b/libavcodec/h2645_parse.c
> @@ -28,6 +28,7 @@
>  
>  #include "bytestream.h"
>  #include "hevc.h"
> +#include "h264.h"
>  #include "h2645_parse.h"
>  
>  int ff_h2645_extract_rbsp(const uint8_t *src, int length,
> @@ -193,6 +194,27 @@ static const char *hevc_nal_unit_name(int nal_type)
>  }
>  }
>  
> +static const char *h264_nal_unit_name(int nal_type)
> +{
> +switch(nal_type) {
> +case H264_NAL_SLICE   : return "SLICE";
> +case H264_NAL_DPA : return "DPA";
> +case H264_NAL_DPB : return "DPB";
> +case H264_NAL_DPC : return "DPC";
> +case H264_NAL_IDR_SLICE   : return "IDR_SLICE";
> +case H264_NAL_SEI : return "SEI";
> +case H264_NAL_SPS : return "SPS";
> +case H264_NAL_PPS : return "PPS";
> +case H264_NAL_AUD : return "AUD";
> +case H264_NAL_END_SEQUENCE: return "END_SEQUENCE";
> +case H264_NAL_END_STREAM  : return "END_STREAM";
> +case H264_NAL_FILLER_DATA : return "FILLER_DATA";
> +case H264_NAL_SPS_EXT : return "SPS_EXT";
> +case H264_NAL_AUXILIARY_SLICE : return "AUXILIARY_SLICE";

Unlike H.265 these names aren't defined by the standard, so I think I'd write 
them normally ("IDR slice", "End of sequence") rather than using the shouty 
enum names.  Doesn't really matter, though.

> +default : return "?";
> +}
> +}
> +
>  static int get_bit_length(H2645NAL *nal, int skip_trailing_zeros)
>  {
>  int size = nal->size;
> @@ -255,8 +277,8 @@ static int h264_parse_nal_header(H2645NAL *nal, void 
> *logctx)
>  nal->type= get_bits(gb, 5);
>  
>  av_log(logctx, AV_LOG_DEBUG,
> -   "nal_unit_type: %d, nal_ref_idc: %d\n",
> -   nal->type, nal->ref_idc);
> +   "nal_unit_type: %d(%s), nal_ref_idc: %d\n",
> +   nal->type, h264_nal_unit_name(nal->type), nal->ref_idc);
>  
>  return 1;
>  }
> 

LGTM either way.

Thanks,

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

Re: [FFmpeg-devel] [FFmpeg-devel, RFC] lavfi: add opencl tonemap filter.

[Moritz Barsnick]

On Fri, May 11, 2018 at 10:10:42 +0200, Niklas Haas wrote:
> Thinking about this logic again, I came to realize that a different
> strategy might be to check instead for a minimum threshold brightness
> difference in a critical number of different areas of the screen. This
> way, a very bright light source appearing or becoming occluded in one
> local part of the frame will not trigger a scene change, while a sudden
> change in brightness of a large part of the frame will.

Yes, when I read your previous email, that was my thought regarding
scene change detection as well. There are others already in ffmpeg, (or
perhaps I was looking at the one in the tool "motion"?), I believe.
They ideally don't just check for overall brightness change, but over
several squares / blocks and take that into consideration.

Reasoning:

- There's a quite high chance that a scene change with a totally
  different picture layout has approx. the same average brightness as
  the scene before.

- A strong change in only one or two of e.g. 100 rectangles should not
  indicate a scene change (while it might indicate motion, different
  concept there).

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

Re: [FFmpeg-devel] [PATCH 4/4] lavc/cbs_h2645: fix no slice data trigger the assert.

[Mark Thompson]

On 11/05/18 06:11, Jun Zhao wrote:
> when the NALU data with zero, just give a warning.
> 
> Fixes ticket #7200
> 
> Signed-off-by: Jun Zhao 
> ---
>  libavcodec/cbs_h2645.c | 6 +-
>  1 file changed, 5 insertions(+), 1 deletion(-)
> 
> diff --git a/libavcodec/cbs_h2645.c b/libavcodec/cbs_h2645.c
> index ab33cdb..08b060c 100644
> --- a/libavcodec/cbs_h2645.c
> +++ b/libavcodec/cbs_h2645.c
> @@ -521,7 +521,11 @@ static int 
> cbs_h2645_fragment_add_nals(CodedBitstreamContext *ctx,
>  // Remove trailing zeroes.
>  while (size > 0 && nal->data[size - 1] == 0)
>  --size;
> -av_assert0(size > 0);
> +if (!size) {
> +av_log(ctx->log_ctx, AV_LOG_WARNING, "No slice data - that was 
> just the header. "
> +   "Probably invalid unaligned padding on non-final NAL 
> unit.\n");
> +continue;
> +}
>  
>  data = av_malloc(size + AV_INPUT_BUFFER_PADDING_SIZE);
>  if (!data)
> 

What do we actually want the result to be here?

On IRC, James suggested:

> diff --git a/libavcodec/h2645_parse.c b/libavcodec/h2645_parse.c
> index dbf2435677..d436d65f48 100644
> --- a/libavcodec/h2645_parse.c
> +++ b/libavcodec/h2645_parse.c
> @@ -371,7 +371,7 @@ int ff_h2645_packet_split(H2645Packet *pkt, const uint8_t 
> *buf, int length,
>  ret = hevc_parse_nal_header(nal, logctx);
>  else
>  ret = h264_parse_nal_header(nal, logctx);
> -if (ret <= 0 || nal->size <= 0) {
> +if (ret <= 0 || nal->size <= 0 || nal->size_bits <= 0) {
>  if (ret < 0) {
>  av_log(logctx, AV_LOG_ERROR, "Invalid NAL unit %d, 
> skipping.\n",
> nal->type);

which removes it before it gets to the CBS code.

Another thing we could do is:

> diff --git a/libavcodec/cbs_h2645.c b/libavcodec/cbs_h2645.c
> index ab33cdb69b..46cd887cdd 100644
> --- a/libavcodec/cbs_h2645.c
> +++ b/libavcodec/cbs_h2645.c
> @@ -519,7 +519,7 @@ static int 
> cbs_h2645_fragment_add_nals(CodedBitstreamContext *ctx,
>  uint8_t *data;
>  
>  // Remove trailing zeroes.
> -while (size > 0 && nal->data[size - 1] == 0)
> +while (size > 1 && nal->data[size - 1] == 0)
>  --size;
>  av_assert0(size > 0);
>  

which would make it parse as an empty NAL unit of type 0 (unspecified), and 
therefore pass through into the output stream in the h264_metadata case.

So, what do you think?  Do you know what made your sample stream?

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

Re: [FFmpeg-devel] [PATCH 1/4] lavc/h2645_parse: log more HEVC NAL type.

[Mark Thompson]

On 11/05/18 06:11, Jun Zhao wrote:
> Signed-off-by: Jun Zhao 
> ---
>  libavcodec/h2645_parse.c | 16 
>  1 file changed, 16 insertions(+)
> 
> diff --git a/libavcodec/h2645_parse.c b/libavcodec/h2645_parse.c
> index dbf2435..ec25c1e 100644
> --- a/libavcodec/h2645_parse.c
> +++ b/libavcodec/h2645_parse.c
> @@ -158,12 +158,28 @@ static const char *nal_unit_name(int nal_type)
>  case HEVC_NAL_RADL_R : return "RADL_R";
>  case HEVC_NAL_RASL_N : return "RASL_N";
>  case HEVC_NAL_RASL_R : return "RASL_R";
> +case HEVC_NAL_VCL_N10: return "VCL_N10";
> +case HEVC_NAL_VCL_R11: return "VCL_R11";
> +case HEVC_NAL_VCL_N12: return "VCL_N12";
> +case HEVC_NAL_VCL_R13: return "VLC_R13";
> +case HEVC_NAL_VCL_N14: return "VCL_N14";
> +case HEVC_NAL_VCL_R15: return "VCL_R15";
>  case HEVC_NAL_BLA_W_LP   : return "BLA_W_LP";
>  case HEVC_NAL_BLA_W_RADL : return "BLA_W_RADL";
>  case HEVC_NAL_BLA_N_LP   : return "BLA_N_LP";
>  case HEVC_NAL_IDR_W_RADL : return "IDR_W_RADL";
>  case HEVC_NAL_IDR_N_LP   : return "IDR_N_LP";
>  case HEVC_NAL_CRA_NUT: return "CRA_NUT";
> +case HEVC_NAL_IRAP_VCL22 : return "IRAP_VCL22";
> +case HEVC_NAL_IRAP_VCL23 : return "IRAP_VCL23";
> +case HEVC_NAL_RSV_VCL24  : return "RSV_VCL24";
> +case HEVC_NAL_RSV_VCL25  : return "RSV_VCL25";
> +case HEVC_NAL_RSV_VCL26  : return "RSV_VCL26";
> +case HEVC_NAL_RSV_VCL27  : return "RSV_VCL27";
> +case HEVC_NAL_RSV_VCL28  : return "RSV_VCL28";
> +case HEVC_NAL_RSV_VCL29  : return "RSV_VCL29";
> +case HEVC_NAL_RSV_VCL30  : return "RSV_VCL30";
> +case HEVC_NAL_RSV_VCL31  : return "RSV_VCL31";
>  case HEVC_NAL_VPS: return "VPS";
>  case HEVC_NAL_SPS: return "SPS";
>  case HEVC_NAL_PPS: return "PPS";
> 

Given that it now covers all values 0-40, maybe turning it into a table rather 
than a switch would be nicer?

LGTM either way.

Thanks,

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

Re: [FFmpeg-devel] [RFC] On behaviour of unlabelled outputs in filtergraphs.

[Nicolas George]

Gyan Doshi (2018-05-09):
> In the open ticket 7089, I reported that (terminal) filters with unlabelled
> output pads are automatically forwarded to the first output file and ordered
> before any expressly mapped streams. There's no warning issued.
> 
> Is this behaviour intended?

Short answer: yes.

> In the section on filtergraph syntax @
> https://ffmpeg.org/ffmpeg-filters.html#Filtergraph-syntax-1,
> 
> it says,
> 
> "If an output pad is not labelled, it is linked by default to the
>  first unlabelled input pad of the next filter in the filterchain."
> 
> and
> 
> "In a complete filterchain all the unlabelled filter input and
>  output pads must be connected. A filtergraph is considered valid
>  if all the filter input and output pads of all the filterchains are
>  connected."
> 
> There's no mention of unlabelled output pads being sent to an output file.

This section is about API use. The command-line tool is built around the
API and defines its own semantic. In this particular instance, the
semantic is that unconnected inputs are connected to input streams and
unconnected outputs are connected to output streams.

> If the present behaviour does not constitute a bug I'll modify the docs.

Do not hesitate to do that.

> In the section on Stream Selection @
> https://ffmpeg.org/ffmpeg.html#Stream-selection,
> 
> it says,
> 
> "By default, ffmpeg includes only one stream of each type (video,
>  audio, subtitle) present in the input files and adds them to each
>  output file. It picks the "best" of each ... For full manual
>  control, use the -map option, which disables the defaults just
>  described."
> 
> So, in the absence of any map directives, only one stream at most of each of
> the three stream types should be included, and these should be the 'best'
> streams from among the inputs. But all unlabelled output pads are included,
> however many they are, and none of them may be the 'best' stream since the
> stream(s) being filtered may not have been selected on the same criterion.
> 
> And in the presence of the map option, by automatically including streams,
> "full manual control" is not true.

The behaviour you are observing is documented in the paragraph about the
-filter_complex option:

   Output link labels are referred to with -map. Unlabeled outputs are
   added to the first output file.

It could bear repeating at other logical places.

Note that the behaviour when explicit -map options are present: when
they are, automatic selection of "best" input streams is disabled, and
it would seem logical that automatic selection of unlabelled filter
outputs would be disabled too. I would not oppose adding a warning for
that case, and even in time changing the default.

But the case without -map is definitely intentional and need to stay,
because many people use it.

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] [FFmpeg-devel, RFC] lavfi: add opencl tonemap filter.

[Niklas Haas]

> The way my scene change detection heuristic works like this: I trigger a
> scene change (and therefore discard the frame averaging buffer) if the
> distance between the current frame average brightness and the current
> running average exceeds a threshold value, that threshold being (by
> default) 20 cd/m².
> 
> So we can divide the failures of this algorithm into two categories:
> 
> 1. False negative (scene change without resetting the buffer): This can
>only happen if there was an actual scene change but the average
>brightness change did not exceed 20 cd/m², i.e. the scenes are
>similar in brightness. I consider this a fairly harmful failure
>because that also means there's no visual discontinuity since the
>scenes are so similar to begin with.
> 
> 2. False positive (buffer got reset without a scene change). This is the
>more worrying failure of the algorithm, since it can happen in the
>middle of a scene (e.g. as the result of a bright flash of light
>on-screen), which will manifest itself as a sudden decrease in the
>total frame brightness coinciding with the new source of light. (Or
>vice versa, a sudden increase in brightness coinciding with the
>sudden absence of a light source).
> 
> The scene change threshold is a trade-off. Lowering the value decreases
> the likelihood of #1 but increases the likelihood of #2. Increasing the
> value decreases the likelihood of #2, but increases the likelihood (and
> apparent effect) of #1.
> 
> If you want to optimize or improve the algorithm, the case #2 is the one
> I would be most interested in, i.e. reducing the rate of false
> positives. This can surely be done in a smarter way, e.g. by comparing
> more than just the scene average but also other easily obtained metrics.
> 
> If you have access to low-level frame information, you could do
> something like increasing the threshold for non-keyframes significantly,
> since keyframes are likely to coincide with scene changes or cuts this
> might help the algorithm out.

Thinking about this logic again, I came to realize that a different
strategy might be to check instead for a minimum threshold brightness
difference in a critical number of different areas of the screen. This
way, a very bright light source appearing or becoming occluded in one
local part of the frame will not trigger a scene change, while a sudden
change in brightness of a large part of the frame will.

I will try it if I get the opportunity to.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 3/4] lavc/h2645_parse: add h264_nal_unit_name for h264 NAL type.

[Steven Liu]

> On May 11, 2018, at 13:11, Jun Zhao  wrote:
> 
> Signed-off-by: Jun Zhao 
> ---
> libavcodec/h2645_parse.c | 26 --
> 1 file changed, 24 insertions(+), 2 deletions(-)
> 
> diff --git a/libavcodec/h2645_parse.c b/libavcodec/h2645_parse.c
> index 579b2c9..8d67579 100644
> --- a/libavcodec/h2645_parse.c
> +++ b/libavcodec/h2645_parse.c
> @@ -28,6 +28,7 @@
> 
> #include "bytestream.h"
> #include "hevc.h"
> +#include "h264.h"
> #include "h2645_parse.h"
> 
> int ff_h2645_extract_rbsp(const uint8_t *src, int length,
> @@ -193,6 +194,27 @@ static const char *hevc_nal_unit_name(int nal_type)
> }
> }
> 
> +static const char *h264_nal_unit_name(int nal_type)
> +{
> +switch(nal_type) {
> +case H264_NAL_SLICE   : return "SLICE";
> +case H264_NAL_DPA : return "DPA";
> +case H264_NAL_DPB : return "DPB";
> +case H264_NAL_DPC : return "DPC";
> +case H264_NAL_IDR_SLICE   : return "IDR_SLICE";
> +case H264_NAL_SEI : return "SEI";
> +case H264_NAL_SPS : return "SPS";
> +case H264_NAL_PPS : return "PPS";
> +case H264_NAL_AUD : return "AUD";
> +case H264_NAL_END_SEQUENCE: return "END_SEQUENCE";
> +case H264_NAL_END_STREAM  : return "END_STREAM";
> +case H264_NAL_FILLER_DATA : return "FILLER_DATA";
> +case H264_NAL_SPS_EXT : return "SPS_EXT";
> +case H264_NAL_AUXILIARY_SLICE : return "AUXILIARY_SLICE";
> +default : return "?";
> +}
> +}
> +
> static int get_bit_length(H2645NAL *nal, int skip_trailing_zeros)
> {
> int size = nal->size;
> @@ -255,8 +277,8 @@ static int h264_parse_nal_header(H2645NAL *nal, void 
> *logctx)
> nal->type= get_bits(gb, 5);
> 
> av_log(logctx, AV_LOG_DEBUG,
> -   "nal_unit_type: %d, nal_ref_idc: %d\n",
> -   nal->type, nal->ref_idc);
> +   "nal_unit_type: %d(%s), nal_ref_idc: %d\n",
> +   nal->type, h264_nal_unit_name(nal->type), nal->ref_idc);
> 
> return 1;
> }
> -- 
> 2.7.4
> 

This patch is look good to me, print the type name is simpler than only an 
value.

Thanks
Steven





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

[FFmpeg-devel] [PATCH] qsv: Use the installed mfx include headers if possibile

[Haihao Xiang]

Currently an extra copy of mfx include headers from 
{MSDK_INSTALL_PREFIX}/include
to {MSDK_INSTALL_PREFIX}/include/mfx is required when using pkg-config for
libmfx detection. This fix checks the installed mfx include headers first,
and falls back to the legacy way if that fails

Signed-off-by: Haihao Xiang 
---
 configure|  3 ++-
 fftools/ffmpeg_qsv.c |  5 +
 libavcodec/qsv.c | 10 ++
 libavcodec/qsv.h |  4 
 libavcodec/qsv_internal.h|  4 
 libavcodec/qsvdec.c  |  4 
 libavcodec/qsvdec.h  |  4 
 libavcodec/qsvdec_h2645.c|  4 
 libavcodec/qsvdec_other.c|  4 
 libavcodec/qsvenc.c  |  5 +
 libavcodec/qsvenc.h  |  4 
 libavcodec/qsvenc_h264.c |  4 
 libavcodec/qsvenc_hevc.c |  4 
 libavcodec/qsvenc_jpeg.c |  4 
 libavcodec/qsvenc_mpeg2.c|  4 
 libavfilter/qsvvpp.h |  4 
 libavfilter/vf_deinterlace_qsv.c |  4 
 libavfilter/vf_scale_qsv.c   |  4 
 libavutil/hwcontext_opencl.c |  4 
 libavutil/hwcontext_qsv.c|  4 
 libavutil/hwcontext_qsv.h|  4 
 21 files changed, 90 insertions(+), 1 deletion(-)

diff --git a/configure b/configure
index a1f13a7109..e1f72495fb 100755
--- a/configure
+++ b/configure
@@ -6007,7 +6007,8 @@ enabled libkvazaar&& require_pkg_config 
libkvazaar "kvazaar >= 0.8.1" kv
 # Media SDK or Intel Media Server Studio, these don't come with
 # pkg-config support.  Instead, users should make sure that the build
 # can find the libraries and headers through other means.
-enabled libmfx&& { check_pkg_config libmfx libmfx "mfx/mfxvideo.h" 
MFXInit ||
+enabled libmfx&& { { check_pkg_config libmfx libmfx "mfxvideo.h" 
MFXInit && add_cflags -DMFX_DEFAULT_INC_PATH; } ||
+   { check_pkg_config libmfx libmfx 
"mfx/mfxvideo.h" MFXInit; } ||
{ require libmfx "mfx/mfxvideo.h" MFXInit 
"-llibmfx $advapi32_extralibs" && warn "using libmfx without pkg-config"; } }
 enabled libmodplug&& require_pkg_config libmodplug libmodplug 
libmodplug/modplug.h ModPlug_Load
 enabled libmp3lame&& require "libmp3lame >= 3.98.3" lame/lame.h 
lame_set_VBR_quality -lmp3lame $libm_extralibs
diff --git a/fftools/ffmpeg_qsv.c b/fftools/ffmpeg_qsv.c
index 7442750029..aa6f8d5270 100644
--- a/fftools/ffmpeg_qsv.c
+++ b/fftools/ffmpeg_qsv.c
@@ -16,7 +16,12 @@
  * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA
  */
 
+#ifdef MFX_DEFAULT_INC_PATH
+#include 
+#else
 #include 
+#endif
+
 #include 
 
 #include "libavutil/dict.h"
diff --git a/libavcodec/qsv.c b/libavcodec/qsv.c
index 45e1c25c68..88f68d6ab5 100644
--- a/libavcodec/qsv.c
+++ b/libavcodec/qsv.c
@@ -18,9 +18,15 @@
  * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA
  */
 
+#ifdef MFX_DEFAULT_INC_PATH
+#include 
+#include 
+#include 
+#else
 #include 
 #include 
 #include 
+#endif
 
 #include 
 #include 
@@ -36,8 +42,12 @@
 #include "qsv_internal.h"
 
 #if QSV_VERSION_ATLEAST(1, 12)
+#ifdef MFX_DEFAULT_INC_PATH
+#include "mfxvp8.h"
+#else
 #include "mfx/mfxvp8.h"
 #endif
+#endif
 
 int ff_qsv_codec_id_to_mfx(enum AVCodecID codec_id)
 {
diff --git a/libavcodec/qsv.h b/libavcodec/qsv.h
index b77158ec26..0116fe9422 100644
--- a/libavcodec/qsv.h
+++ b/libavcodec/qsv.h
@@ -21,7 +21,11 @@
 #ifndef AVCODEC_QSV_H
 #define AVCODEC_QSV_H
 
+#ifdef MFX_DEFAULT_INC_PATH
+#include 
+#else
 #include 
+#endif
 
 #include "libavutil/buffer.h"
 
diff --git a/libavcodec/qsv_internal.h b/libavcodec/qsv_internal.h
index 394c558883..f77ad63664 100644
--- a/libavcodec/qsv_internal.h
+++ b/libavcodec/qsv_internal.h
@@ -21,7 +21,11 @@
 #ifndef AVCODEC_QSV_INTERNAL_H
 #define AVCODEC_QSV_INTERNAL_H
 
+#ifdef MFX_DEFAULT_INC_PATH
+#include 
+#else
 #include 
+#endif
 
 #include "libavutil/frame.h"
 
diff --git a/libavcodec/qsvdec.c b/libavcodec/qsvdec.c
index 32f1fe79d7..9921158100 100644
--- a/libavcodec/qsvdec.c
+++ b/libavcodec/qsvdec.c
@@ -24,7 +24,11 @@
 #include 
 #include 
 
+#ifdef MFX_DEFAULT_INC_PATH
+#include 
+#else
 #include 
+#endif
 
 #include "libavutil/common.h"
 #include "libavutil/hwcontext.h"
diff --git a/libavcodec/qsvdec.h b/libavcodec/qsvdec.h
index 5b7b03a48b..3b4541fff1 100644
--- a/libavcodec/qsvdec.h
+++ b/libavcodec/qsvdec.h
@@ -26,7 +26,11 @@
 #include 
 #include 
 
+#ifdef MFX_DEFAULT_INC_PATH
+#include 
+#else
 #include 
+#endif
 
 #include "libavutil/fifo.h"
 #include "libavutil/frame.h"
diff --git a/libavcodec/qsvdec_h2645.c b/libavcodec/qsvdec_h2645.c
index 831252f2d7..e2b90afee9 100644
--- a/libavcodec/qsvdec_h2645.c
+++ b/libavcodec/qsvdec_h2645.c
@@ -25,7 +25,11 @@
 #include 
 #include 
 
+#ifdef MFX_DEFAULT_INC_PATH
+#include 
+#else
 #include 
+#endif
 
 #include "libavutil/common.h"
 #include 

Re: [FFmpeg-devel] [PATCH] fate: add more tests for hue video filter

[Tobias Rapp]

On 10.05.2018 23:04, Michael Niedermayer wrote:

On Wed, May 09, 2018 at 12:05:48PM +0200, Tobias Rapp wrote:

Adds tests for the hue angle and brightness filter parameters.
Renames the existing saturation parameter test for consistency.

Signed-off-by: Tobias Rapp 
---
  tests/fate/filter-video.mak | 10 --
  tests/ref/fate/filter-hue   |  1 -
  tests/ref/fate/filter-hue1  |  1 +
  tests/ref/fate/filter-hue2  |  1 +
  tests/ref/fate/filter-hue3  |  1 +
  5 files changed, 11 insertions(+), 3 deletions(-)
  delete mode 100644 tests/ref/fate/filter-hue
  create mode 100644 tests/ref/fate/filter-hue1
  create mode 100644 tests/ref/fate/filter-hue2
  create mode 100644 tests/ref/fate/filter-hue3


should be ok


Pushed, thanks for review.

Regards,
Tobias

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