[FFmpeg-devel] [PATCH] avcodec/mips: [loongson] optimize put_hevc_pel_bi_pixels_8 with mmi.

[Shiyou Yin]

Optimize put_hevc_pel_bi_pixels_8 with mmi in the case width=8/16/24/32/48/64.
This optimization improved HEVC decoding performance 2%(1.77x to 1.81x, tested 
on loongson 3A3000).
---
 libavcodec/mips/Makefile|   1 +
 libavcodec/mips/hevcdsp_init_mips.c |  23 ++
 libavcodec/mips/hevcdsp_mips.h  |  19 +
 libavcodec/mips/hevcdsp_mmi.c   | 135 
 4 files changed, 178 insertions(+)
 create mode 100644 libavcodec/mips/hevcdsp_mmi.c

diff --git a/libavcodec/mips/Makefile b/libavcodec/mips/Makefile
index 3571207..3029872 100644
--- a/libavcodec/mips/Makefile
+++ b/libavcodec/mips/Makefile
@@ -86,3 +86,4 @@ MMI-OBJS-$(CONFIG_VP8_DECODER)+= mips/vp8dsp_mmi.o
 MMI-OBJS-$(CONFIG_HPELDSP)+= mips/hpeldsp_mmi.o
 MMI-OBJS-$(CONFIG_VC1_DECODER)+= mips/vc1dsp_mmi.o
 MMI-OBJS-$(CONFIG_WMV2DSP)+= mips/wmv2dsp_mmi.o
+MMI-OBJS-$(CONFIG_HEVC_DECODER)   += mips/hevcdsp_mmi.o
diff --git a/libavcodec/mips/hevcdsp_init_mips.c 
b/libavcodec/mips/hevcdsp_init_mips.c
index 776d13e..41c9001 100644
--- a/libavcodec/mips/hevcdsp_init_mips.c
+++ b/libavcodec/mips/hevcdsp_init_mips.c
@@ -20,6 +20,26 @@
 
 #include "libavcodec/mips/hevcdsp_mips.h"
 
+#if HAVE_MMI
+static av_cold void hevc_dsp_init_mmi(HEVCDSPContext *c,
+  const int bit_depth)
+{
+if (8 == bit_depth) {
+c->put_hevc_qpel_bi[3][0][0] = ff_hevc_put_hevc_pel_bi_pixels8_8_mmi;
+c->put_hevc_qpel_bi[5][0][0] = ff_hevc_put_hevc_pel_bi_pixels16_8_mmi;
+c->put_hevc_qpel_bi[6][0][0] = ff_hevc_put_hevc_pel_bi_pixels24_8_mmi;
+c->put_hevc_qpel_bi[7][0][0] = ff_hevc_put_hevc_pel_bi_pixels32_8_mmi;
+c->put_hevc_qpel_bi[8][0][0] = ff_hevc_put_hevc_pel_bi_pixels48_8_mmi;
+c->put_hevc_qpel_bi[9][0][0] = ff_hevc_put_hevc_pel_bi_pixels64_8_mmi;
+
+c->put_hevc_epel_bi[3][0][0] = ff_hevc_put_hevc_pel_bi_pixels8_8_mmi;
+c->put_hevc_epel_bi[5][0][0] = ff_hevc_put_hevc_pel_bi_pixels16_8_mmi;
+c->put_hevc_epel_bi[6][0][0] = ff_hevc_put_hevc_pel_bi_pixels24_8_mmi;
+c->put_hevc_epel_bi[7][0][0] = ff_hevc_put_hevc_pel_bi_pixels32_8_mmi;
+}
+}
+#endif // #if HAVE_MMI
+
 #if HAVE_MSA
 static av_cold void hevc_dsp_init_msa(HEVCDSPContext *c,
   const int bit_depth)
@@ -448,6 +468,9 @@ static av_cold void hevc_dsp_init_msa(HEVCDSPContext *c,
 
 void ff_hevc_dsp_init_mips(HEVCDSPContext *c, const int bit_depth)
 {
+#if HAVE_MMI
+hevc_dsp_init_mmi(c, bit_depth);
+#endif  // #if HAVE_MMI
 #if HAVE_MSA
 hevc_dsp_init_msa(c, bit_depth);
 #endif  // #if HAVE_MSA
diff --git a/libavcodec/mips/hevcdsp_mips.h b/libavcodec/mips/hevcdsp_mips.h
index 1573d1c..ff9401c 100644
--- a/libavcodec/mips/hevcdsp_mips.h
+++ b/libavcodec/mips/hevcdsp_mips.h
@@ -479,4 +479,23 @@ void ff_hevc_addblk_32x32_msa(uint8_t *dst, int16_t 
*pi16Coeffs,
   ptrdiff_t stride);
 void ff_hevc_idct_luma_4x4_msa(int16_t *pi16Coeffs);
 
+/* Loongson optimization */
+#define L_BI_MC(PEL, DIR, WIDTH, TYPE) 
\
+void ff_hevc_put_hevc_##PEL##_bi_##DIR##WIDTH##_8_##TYPE(uint8_t *dst,   \
+ptrdiff_t dst_stride,  
\
+uint8_t *src,  
\
+ptrdiff_t src_stride,  
\
+int16_t *src_16bit,
\
+int height,
\
+intptr_t mx,   
\
+intptr_t my,   
\
+int width)
+
+L_BI_MC(pel, pixels, 8, mmi);
+L_BI_MC(pel, pixels, 16, mmi);
+L_BI_MC(pel, pixels, 24, mmi);
+L_BI_MC(pel, pixels, 32, mmi);
+L_BI_MC(pel, pixels, 48, mmi);
+L_BI_MC(pel, pixels, 64, mmi);
+#undef L_BI_MC
 #endif  // #ifndef AVCODEC_MIPS_HEVCDSP_MIPS_H
diff --git a/libavcodec/mips/hevcdsp_mmi.c b/libavcodec/mips/hevcdsp_mmi.c
new file mode 100644
index 000..e9403c5
--- /dev/null
+++ b/libavcodec/mips/hevcdsp_mmi.c
@@ -0,0 +1,135 @@
+/*
+ * Copyright (c) 2019 Shiyou Yin (yinshiyou...@loongson.cn)
+ *
+ * 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 

Re: [FFmpeg-devel] [PATCH] avcodec/proresdec2: only set avctx->color* when values are specified

[Neil Birkbeck]

On Thu, Jan 17, 2019 at 7:43 PM Neil Birkbeck 
wrote:

> This allows preservation of color values set from the container,
> while still letting the bitstream take precedent when its values
> are specified to some actual value (e.g., not *UNSPECIFIED).
>
> Signed-off-by: Neil Birkbeck 
> ---
>  libavcodec/proresdec2.c | 9 ++---
>  1 file changed, 6 insertions(+), 3 deletions(-)
>
> diff --git a/libavcodec/proresdec2.c b/libavcodec/proresdec2.c
> index 6209c229c9..662ca7d48b 100644
> --- a/libavcodec/proresdec2.c
> +++ b/libavcodec/proresdec2.c
> @@ -262,9 +262,12 @@ static int decode_frame_header(ProresContext *ctx,
> const uint8_t *buf,
>  }
>  }
>
> -avctx->color_primaries = buf[14];
> -avctx->color_trc   = buf[15];
> -avctx->colorspace  = buf[16];
> +if (buf[14] != AVCOL_PRI_UNSPECIFIED)
> +avctx->color_primaries = buf[14];
> +if (buf[15] != AVCOL_TRC_UNSPECIFIED)
> +avctx->color_trc   = buf[15];
> +if (buf[16] != AVCOL_SPC_UNSPECIFIED)
> +avctx->colorspace  = buf[16];
>  avctx->color_range = AVCOL_RANGE_MPEG;
>
>  ptr   = buf + 20;
> --
> 2.20.1.321.g9e740568ce-goog
>
>
To add a bit more context. The patch is a fix for the case when prores
bitstream code points are explicitly set to unspecified and are overriding
what may have been in the container (unlike h264/h265 where such values can
behind the color_description flag, these fields always must be present in
the prores header). Of course, ideally these should be the same.

We noticed this inconsistency on some HDR content, as prior to
https://github.com/FFmpeg/FFmpeg/commit/81d78fe13bc1fd94845c002f3439fe44d9e9e0d9
the color information in the prores bitstream (which may have been
unspecified) was simply ignored.

In practice, I guess some workflows may not have known about the new code
points and put unspecified in the bitstream (or worse where some headers
will contain non-HDR code points).

The patch seemed like a situation where we could resolve the inconsistency
in favor of the container (given my understanding, and from what I see in
the code, I'm assuming the codec is typically given preference). But I'm
interested in hearing ffmpeg-devel's opinions on whether this is most
consistent (actually, for the HDR files that I've seen, the container is
correct--although I'm sure there are cases where the opposite is true).

I guess the most closely related discussion about codecs overriding these
types of values is here
https://patchwork.ffmpeg.org/patch/11279/
but this case seemed a bit different.

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

[FFmpeg-devel] [PATCH] avcodec/proresdec2: only set avctx->color* when values are specified

[Neil Birkbeck]

This allows preservation of color values set from the container,
while still letting the bitstream take precedent when its values
are specified to some actual value (e.g., not *UNSPECIFIED).

Signed-off-by: Neil Birkbeck 
---
 libavcodec/proresdec2.c | 9 ++---
 1 file changed, 6 insertions(+), 3 deletions(-)

diff --git a/libavcodec/proresdec2.c b/libavcodec/proresdec2.c
index 6209c229c9..662ca7d48b 100644
--- a/libavcodec/proresdec2.c
+++ b/libavcodec/proresdec2.c
@@ -262,9 +262,12 @@ static int decode_frame_header(ProresContext *ctx, const 
uint8_t *buf,
 }
 }
 
-avctx->color_primaries = buf[14];
-avctx->color_trc   = buf[15];
-avctx->colorspace  = buf[16];
+if (buf[14] != AVCOL_PRI_UNSPECIFIED)
+avctx->color_primaries = buf[14];
+if (buf[15] != AVCOL_TRC_UNSPECIFIED)
+avctx->color_trc   = buf[15];
+if (buf[16] != AVCOL_SPC_UNSPECIFIED)
+avctx->colorspace  = buf[16];
 avctx->color_range = AVCOL_RANGE_MPEG;
 
 ptr   = buf + 20;
-- 
2.20.1.321.g9e740568ce-goog

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

Re: [FFmpeg-devel] [PATCH] avcodec/rscc: Avoid returning frames that have nearly no undamaged pixels in them

[Michael Niedermayer]

On Wed, Jan 16, 2019 at 09:05:18PM -0500, Vittorio Giovara wrote:
> On Wed, Jan 16, 2019 at 7:44 PM Michael Niedermayer 
> wrote:
> 
> > Fixes: Timeout
> > Fixes:
> > 12192/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_RSCC_fuzzer-6279038004363264
> >
> > Before:
> > clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_RSCC_fuzzer-6279038004363264
> > in 15423 ms
> > After:
> > clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_RSCC_fuzzer-6279038004363264
> > in 190 ms
> >
> > Found-by: continuous fuzzing process
> > https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
> > Signed-off-by
> > :
> > Michael Niedermayer 
> > ---
> >  libavcodec/rscc.c | 7 ++-
> >  1 file changed, 6 insertions(+), 1 deletion(-)
> >
> > diff --git a/libavcodec/rscc.c b/libavcodec/rscc.c
> > index 7921f149ed..fa066afd7f 100644
> > --- a/libavcodec/rscc.c
> > +++ b/libavcodec/rscc.c
> > @@ -64,6 +64,7 @@ typedef struct RsccContext {
> >  /* zlib interaction */
> >  uint8_t *inflated_buf;
> >  uLongf inflated_size;
> > +int valid_pixels
> >  } RsccContext;
> >
> >  static av_cold int rscc_init(AVCodecContext *avctx)
> > @@ -348,7 +349,11 @@ static int rscc_decode_frame(AVCodecContext *avctx,
> > void *data,
> >  memcpy (frame->data[1], ctx->palette, AVPALETTE_SIZE);
> >  }
> >
> > -*got_frame = 1;
> > +// We only return a picture when more than 5% is undameged, this
> > avoids copying nearly broken frames around
> > +if (ctx->valid_pixels < ctx->inflated_size)
> > +ctx->valid_pixels += pixel_size;
> > +if (ctx->valid_pixels >= ctx->inflated_size/20)
> >
> 
> this feels arbitrary and hackish, for very little gain, IMO

Would you be ok with rejecting RSCC files without a keyframe ?
or more precissely all frames before a keyframe and thus if there is
no keyframe the whole file
(that would be a superset of what this patch rejects)

I suggested that arbitrary check above as it would allow decoding more data
in case of a damaged or lost keyframe

The gain these changes have is they increase the cost for an
attacker in a DOS attack. (they also improve the efficiency of the fuzzer but
thats secondary)
As is you can have a file with huge resolution where each frame only encodes
1 pixel in about a dozen bytes per frame. That transforms a very low cost of
network bandwidth from an attacker to a rather large computational cost on
anything processing such file.
Requiring more than 1 valid pixels in a billion or Requiring a valid keyframe
would increase the cost for an attacker.

Also do you see a cleaner way to achive this as the author of this
decoder ?

Thanks

[...]

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

"I am not trying to be anyone's saviour, I'm trying to think about the
 future and not be sad" - Elon Musk



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

Re: [FFmpeg-devel] [PATCH V8 2/2] avcodec/libx264: add support for ROI-based encoding

[Derek Buitenhuis]

On 16/01/2019 12:39, Derek Buitenhuis wrote:
> On 16/01/2019 00:41, Guo, Yejun wrote:
>> this patch set asks for pushing if no more concerns, thanks.
> 
> I support this.
> 
> If nobody raises any concerns in the next 24-48 hrs, I'll go ahead.
> 
> Thank you for sticking with it through the bikeshedding.

Pushed.

- Derek

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

Re: [FFmpeg-devel] [PATCH] avcodec/rscc: Avoid returning frames that have nearly no undamaged pixels in them

[Derek Buitenhuis]

On 17/01/2019 03:06, Carl Eugen Hoyos wrote:
> You mean searching for security issues makes no sense?

This isn't a security and it isn't a fix. It's a completely
arbitrary statistic to make an arbitrary program happy.

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

Re: [FFmpeg-devel] [PATCH V8 1/2] avutil: add ROI (Region Of Interest) data struct and bump version

[Derek Buitenhuis]

On 10/01/2019 08:53, Guo, Yejun wrote:
> ---
>  doc/APIchanges  |  3 +++
>  libavutil/frame.c   |  1 +
>  libavutil/frame.h   | 35 +++
>  libavutil/version.h |  2 +-
>  4 files changed, 40 insertions(+), 1 deletion(-)

Pushed, as stated.

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

Re: [FFmpeg-devel] [PATCH 2/3] flvdec: Mark the demuxer as allowing discontinuous timestamps

[Derek Buitenhuis]

On 15/01/2019 21:24, Michael Niedermayer wrote:
> Heres a better patch which may work with seeking as long as there are only
> 2 files concatenated
> 
> i think completely discarding the parts after the concatenation would cause
> user complaints and they would have a point, if the data is in there we
> should be able to recover it for muxing it in a better file at least

No strong opinion. You can push.

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

Re: [FFmpeg-devel] [PATCH 1/2] tools/target_dec_fate.sh: print some statistics

[Michael Niedermayer]

On Tue, Jan 15, 2019 at 11:41:22PM +0100, Carl Eugen Hoyos wrote:
> 2019-01-15 23:36 GMT+01:00, Michael Niedermayer :
> > On Fri, Jan 04, 2019 at 08:29:36PM +0100, Michael Niedermayer wrote:
> >> On Sat, Dec 29, 2018 at 10:47:16AM +0100, Moritz Barsnick wrote:
> >> > On Sat, Dec 29, 2018 at 02:35:18 +0100, Michael Niedermayer wrote:
> >> > > +CACHED=$((CACHED+1))
> >> >
> >> > I believe this is the sort of math that won't work on old, non-POSIX
> >> > Bourne shells. (I'm thinking Solaris /bin/sh here.) In case that
> >> > even matters.
> >>
> >> which platform without a posix /bin/sh supports the libfuzz stuff ?
> >
> > ping, is there any suggestion for improving this patch ?
> > or are all concerns resolved ?
> 
> I believe adding more things that will not work on sunos is not
> ideal.
> But if there is no other way solving the issues that this patch
> fixes, sunos is of course no show-stopper.

how can i test easily that a change work with such a non posix shell ?


[...]

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Republics decline into democracies and democracies degenerate into
despotisms. -- Aristotle


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

Re: [FFmpeg-devel] [PATCH] avfilter/extractplanes: add support for 12-bit YUVA formats

[Carl Eugen Hoyos]

2019-01-17 10:47 GMT+01:00, Gyan :
> Fixes alpha extraction for sample at
>
> https://08488297638989341201.googlegroups.com/attach/85d30cd6b8095/Circle%20Ink%20Bleed_10.mov

This is a textfile afaict.

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

Re: [FFmpeg-devel] [PATCH] avfilter/vf_paletteuse: don't constantly free and realloc internal frames

[James Almer]

On 1/17/2019 12:51 PM, Clément Bœsch wrote:
> On Tue, Jan 15, 2019 at 01:14:34AM -0300, James Almer wrote:
>> Signed-off-by: James Almer 
>> ---
>>  libavfilter/vf_paletteuse.c | 16 ++--
>>  1 file changed, 10 insertions(+), 6 deletions(-)
>>
>> diff --git a/libavfilter/vf_paletteuse.c b/libavfilter/vf_paletteuse.c
>> index 5966f10685..289c663e8e 100644
>> --- a/libavfilter/vf_paletteuse.c
>> +++ b/libavfilter/vf_paletteuse.c
>> @@ -814,7 +814,7 @@ static void set_processing_window(enum diff_mode 
>> diff_mode,
>>  int width  = cur_src->width;
>>  int height = cur_src->height;
>>  
>> -if (prv_src && diff_mode == DIFF_MODE_RECTANGLE) {
>> +if (prv_src->data[0] && diff_mode == DIFF_MODE_RECTANGLE) {
>>  int y;
>>  int x_end = cur_src->width  - 1,
>>  y_end = cur_src->height - 1;
>> @@ -911,11 +911,10 @@ static int apply_palette(AVFilterLink *inlink, AVFrame 
>> *in, AVFrame **outf)
>>  
>>  set_processing_window(s->diff_mode, s->last_in, in,
>>s->last_out, out, , , , );
>> -av_frame_free(>last_in);
>> -av_frame_free(>last_out);
>> -s->last_in  = av_frame_clone(in);
>> -s->last_out = av_frame_clone(out);
>> -if (!s->last_in || !s->last_out ||
>> +av_frame_unref(s->last_in);
>> +av_frame_unref(s->last_out);
>> +if (av_frame_ref(s->last_in, in) < 0 ||
>> +av_frame_ref(s->last_out, out) < 0 ||
>>  av_frame_make_writable(s->last_in) < 0) {
>>  av_frame_free();
>>  av_frame_free();
>> @@ -1086,6 +1085,11 @@ static av_cold int init(AVFilterContext *ctx)
>>  {
>>  PaletteUseContext *s = ctx->priv;
>>  
>> +s->last_in  = av_frame_alloc();
>> +s->last_out = av_frame_alloc();
>> +if (!s->last_in || !s->last_out)
>> +return AVERROR(ENOMEM);
>> +
>>  s->set_frame = set_frame_lut[s->color_search_method][s->dither];
>>  
>>  if (s->dither == DITHERING_BAYER) {
> 
> LGTM, thanks

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

Re: [FFmpeg-devel] [PATCH] avfilter/vf_paletteuse: don't constantly free and realloc internal frames

[Clément Bœsch]

On Tue, Jan 15, 2019 at 01:14:34AM -0300, James Almer wrote:
> Signed-off-by: James Almer 
> ---
>  libavfilter/vf_paletteuse.c | 16 ++--
>  1 file changed, 10 insertions(+), 6 deletions(-)
> 
> diff --git a/libavfilter/vf_paletteuse.c b/libavfilter/vf_paletteuse.c
> index 5966f10685..289c663e8e 100644
> --- a/libavfilter/vf_paletteuse.c
> +++ b/libavfilter/vf_paletteuse.c
> @@ -814,7 +814,7 @@ static void set_processing_window(enum diff_mode 
> diff_mode,
>  int width  = cur_src->width;
>  int height = cur_src->height;
>  
> -if (prv_src && diff_mode == DIFF_MODE_RECTANGLE) {
> +if (prv_src->data[0] && diff_mode == DIFF_MODE_RECTANGLE) {
>  int y;
>  int x_end = cur_src->width  - 1,
>  y_end = cur_src->height - 1;
> @@ -911,11 +911,10 @@ static int apply_palette(AVFilterLink *inlink, AVFrame 
> *in, AVFrame **outf)
>  
>  set_processing_window(s->diff_mode, s->last_in, in,
>s->last_out, out, , , , );
> -av_frame_free(>last_in);
> -av_frame_free(>last_out);
> -s->last_in  = av_frame_clone(in);
> -s->last_out = av_frame_clone(out);
> -if (!s->last_in || !s->last_out ||
> +av_frame_unref(s->last_in);
> +av_frame_unref(s->last_out);
> +if (av_frame_ref(s->last_in, in) < 0 ||
> +av_frame_ref(s->last_out, out) < 0 ||
>  av_frame_make_writable(s->last_in) < 0) {
>  av_frame_free();
>  av_frame_free();
> @@ -1086,6 +1085,11 @@ static av_cold int init(AVFilterContext *ctx)
>  {
>  PaletteUseContext *s = ctx->priv;
>  
> +s->last_in  = av_frame_alloc();
> +s->last_out = av_frame_alloc();
> +if (!s->last_in || !s->last_out)
> +return AVERROR(ENOMEM);
> +
>  s->set_frame = set_frame_lut[s->color_search_method][s->dither];
>  
>  if (s->dither == DITHERING_BAYER) {

LGTM, thanks

-- 
Clément B.


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

Re: [FFmpeg-devel] [PATCH v3] Improved the performance of 1 decode + N filter graphs and adaptive bitrate.

[Michael Niedermayer]

On Wed, Jan 16, 2019 at 04:17:07PM -0500, Shaofei Wang wrote:
> With new option "-abr_pipeline"
> It enabled multiple filter graph concurrency, which bring obove about
> 4%~20% improvement in some 1:N scenarios by CPU or GPU acceleration
> 
> Below are some test cases and comparison as reference.
> (Hardware platform: Intel(R) Core(TM) i7-6700 CPU @ 3.40GHz)
> (Software: Intel iHD driver - 16.9.00100, CentOS 7)
> 
> For 1:N transcode by GPU acceleration with vaapi:
> ./ffmpeg -vaapi_device /dev/dri/renderD128 -hwaccel vaapi \
> -hwaccel_output_format vaapi \
> -i ~/Videos/1920x1080p_30.00_x264_qp28.h264 \
> -vf "scale_vaapi=1280:720" -c:v h264_vaapi -f null /dev/null \
> -vf "scale_vaapi=720:480" -c:v h264_vaapi -f null /dev/null \
> -abr_pipeline
> 
> test results:
> 2 encoders 5 encoders 10 encoders
> Improved   6.1%6.9%   5.5%
> 
> For 1:N transcode by GPU acceleration with QSV:
> ./ffmpeg -hwaccel qsv -c:v h264_qsv \
> -i ~/Videos/1920x1080p_30.00_x264_qp28.h264 \
> -vf "scale_qsv=1280:720:format=nv12" -c:v h264_qsv -f null /dev/null \
> -vf "scale_qsv=720:480:format=nv12" -c:v h264_qsv -f null /dev/null
> 
> test results:
> 2 encoders  5 encoders 10 encoders
> Improved   6%   4% 15%
> 
> For Intel GPU acceleration case, 1 decode to N scaling, by QSV:
> ./ffmpeg -hwaccel qsv -c:v h264_qsv \
> -i ~/Videos/1920x1080p_30.00_x264_qp28.h264 \
> -vf "scale_qsv=1280:720:format=nv12,hwdownload" -pix_fmt nv12 -f null 
> /dev/null \
> -vf "scale_qsv=720:480:format=nv12,hwdownload" -pix_fmt nv12 -f null 
> /dev/null
> 
> test results:
> 2 scale  5 scale   10 scale
> Improved   12% 21%21%
> 
> For CPU only 1 decode to N scaling:
> ./ffmpeg -i ~/Videos/1920x1080p_30.00_x264_qp28.h264 \
> -vf "scale=1280:720" -pix_fmt nv12 -f null /dev/null \
> -vf "scale=720:480" -pix_fmt nv12 -f null /dev/null \
> -abr_pipeline
> 
> test results:
> 2 scale  5 scale   10 scale
> Improved   25%107%   148%
> 
> Signed-off-by: Wang, Shaofei 
> Reviewed-by: Zhao, Jun 
> ---
>  fftools/ffmpeg.c| 228 
> 
>  fftools/ffmpeg.h|  15 
>  fftools/ffmpeg_filter.c |   4 +
>  fftools/ffmpeg_opt.c|   6 +-
>  4 files changed, 237 insertions(+), 16 deletions(-)

Looking at this i see alot of duplicated code and alot of ifdefs

if i look at one of the duplicated functions i see:

@@ -1,10 +1,11 @@
-static int reap_filters(int flush)
+static int pipeline_reap_filters(int flush, InputFilter * ifilter)
 {
 AVFrame *filtered_frame = NULL;
 int i;
 
-/* Reap all buffers present in the buffer sinks */
 for (i = 0; i < nb_output_streams; i++) {
+if (ifilter == output_streams[i]->filter->graph->inputs[0]) break;
+}
 OutputStream *ost = output_streams[i];
 OutputFile*of = output_files[ost->file_index];
 AVFilterContext *filter;
@@ -12,7 +13,7 @@
 int ret = 0;
 
 if (!ost->filter || !ost->filter->graph->graph)
-continue;
+return 0;
 filter = ost->filter->filter;
 
 if (!ost->initialized) {
@@ -25,9 +26,8 @@
 }
 }
 
-if (!ost->filtered_frame && !(ost->filtered_frame = av_frame_alloc())) 
{
+if (!ost->filtered_frame && !(ost->filtered_frame = av_frame_alloc()))
 return AVERROR(ENOMEM);
-}
 filtered_frame = ost->filtered_frame;
 
 while (1) {
@@ -97,7 +97,6 @@
 
 av_frame_unref(filtered_frame);
 }
-}
 
 return 0;
 }
\ No newline at end of file


This is basically the same just copy and pasted 2 lines changed, one
unrelated cosmetic change and code calling it outside under ifdef

This is not ok

also IIRC nicolas knows this part of the codebase best so it probably
makes sense when he comments. But as far as my oppionion
goes, i would prefer to avoid duplicate codepathes or ifdefs.
They have alot of disadvantages making maintaince harder
also making testing harder as only one of several alternative pathes
would be tested in each individual test, ...

So what i really would like to see is this being done in a cleaner
way. Preferably one codepath when possible, and best results by default 
no need to manually enable the fast path.

Also the question of scalability should be considered. Not saying
that requires any change but it should be given a thought what
happens if there are 1000 or 1 output and if the change makes sense
for such cases too.

thanks

[...]
-- 
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: PGP signature
___
ffmpeg-devel mailing list

Re: [FFmpeg-devel] [PATCH] palettegen: Fill with last color, not black

[Michael Niedermayer]

On Thu, Jan 17, 2019 at 09:44:47AM +0100, Clément Bœsch wrote:
> On Wed, Jan 16, 2019 at 01:40:20PM +0100, Tomas Härdin wrote:
> > Hi
> > 
> > I was helping the fine folks at peppercarrot.com with web video
> > nonsense, and I notice palettegen outputs more colors than it should
> > due to padding the generated palette with pure black.
> > 
> > Compare this (ffmpeg version 3.2.12-1~deb9u1):
> > http://www.härdin.se/files/peppercarrot_gif/output-blackspecks-64.gif
> > with this (282a471 with this patch applied):
> > http://www.härdin.se/files/peppercarrot_gif/output-fixed-64.gif
> > 
> > The attached patch fixes this by padding with the last color instead of
> > black.
> > 
> > /Tomas
> 
> > From 3a01f62fdcc95cc7afaf5aa6e439b8742cce43bc Mon Sep 17 00:00:00 2001
> > From: =?UTF-8?q?Tomas=20H=C3=A4rdin?= 
> > Date: Wed, 16 Jan 2019 13:07:48 +0100
> > Subject: [PATCH] palettegen: Fill with last color, not black
> > 
> > If we fill with black then the generated palette will have one color more
> > than what the user requested. This also resulted in unwanted black specks in
> > the output of paletteuse, especially when generating small palettes.
> > ---
> >  libavfilter/vf_palettegen.c | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> > 
> > diff --git a/libavfilter/vf_palettegen.c b/libavfilter/vf_palettegen.c
> > index 5ff73e6b2b..44323782d2 100644
> > --- a/libavfilter/vf_palettegen.c
> > +++ b/libavfilter/vf_palettegen.c
> > @@ -245,7 +245,7 @@ static void write_palette(AVFilterContext *ctx, AVFrame 
> > *out)
> >  av_log(ctx, AV_LOG_WARNING, "Dupped color: 
> > %08"PRIX32"\n", pal[x]);
> >  last_color = pal[x];
> >  } else {
> > -pal[x] = 0xff00; // pad with black
> > +pal[x] = last_color; // pad with last color
> >  }
> >  }
> >  pal += pal_linesize;
> 
> Code LGTM, thanks
> 

> No FATE change?

--- ./tests/ref/fate/filter-palettegen-22019-01-15 01:24:17.53094 
+0100
+++ tests/data/fate/filter-palettegen-2 2019-01-17 11:13:21.077198948 +0100
@@ -3,4 +3,4 @@
 #codec_id 0: rawvideo
 #dimensions 0: 16x16
 #sar 0: 1/1
-0,  0,  0,1, 1024, 0x906ff5aa
+0,  0,  0,1, 1024, 0x23e072c8
Test filter-palettegen-2 failed. Look at 
tests/data/fate/filter-palettegen-2.err for details.
make: *** [fate-filter-palettegen-2] Error 1

[...]


-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

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


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

Re: [FFmpeg-devel] [PATCH 3/4] lavf/tls_openssl: on 1.1 or later, verify the server's hostname

[Nicolas George]

Rodger Combs (12019-01-17):
> What kind of misconfiguration are you referring to? The actual

A server with a certificate on a different name.

> verification is still gated behind the tls_verify option; if that's
> set to 0, this won't actually do anything.

Ok, that is good. Thanks for clarifying.

Regards,

-- 
  Nicolas George


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

[FFmpeg-devel] [PATCH] avfilter/extractplanes: add support for 12-bit YUVA formats

[Gyan]

Fixes alpha extraction for sample at

https://08488297638989341201.googlegroups.com/attach/85d30cd6b8095/Circle%20Ink%20Bleed_10.mov

as seen in

    ffplay -i in -vf alphaextract

Gyan
From 122f500e09b2741f3865da5c3f612ee04dcd7e21 Mon Sep 17 00:00:00 2001
From: Gyan Doshi 
Date: Thu, 17 Jan 2019 15:01:11 +0530
Subject: [PATCH] avfilter/extractplanes: add support for 12-bit YUVA formats

At present, 16-bit auto-scaled format results in incorrect alpha
extraction.
---
 libavfilter/vf_extractplanes.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/libavfilter/vf_extractplanes.c b/libavfilter/vf_extractplanes.c
index f9171572ed..739c2420cb 100644
--- a/libavfilter/vf_extractplanes.c
+++ b/libavfilter/vf_extractplanes.c
@@ -99,6 +99,8 @@ AVFILTER_DEFINE_CLASS(extractplanes);
 AV_PIX_FMT_YUV422P12##suf, \
 AV_PIX_FMT_YUV444P12##suf, \
 AV_PIX_FMT_YUV440P12##suf, \
+AV_PIX_FMT_YUVA422P12##suf,\
+AV_PIX_FMT_YUVA444P12##suf,\
 AV_PIX_FMT_GBRP10##suf, AV_PIX_FMT_GBRAP10##suf,   \
 AV_PIX_FMT_GBRP12##suf, AV_PIX_FMT_GBRAP12##suf,   \
 AV_PIX_FMT_YUV420P9##suf,  \
-- 
2.19.2___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 3/4] lavf/tls_openssl: on 1.1 or later, verify the server's hostname

[Rodger Combs]

> On Jan 17, 2019, at 03:09, Nicolas George  wrote:
> 
> Signed PGP part
> Rodger Combs (12019-01-17):
>> ---
>> libavformat/tls_openssl.c | 22 ++
>> 1 file changed, 18 insertions(+), 4 deletions(-)
>> 
>> diff --git a/libavformat/tls_openssl.c b/libavformat/tls_openssl.c
>> index 493f43e610..bdc4985bad 100644
>> --- a/libavformat/tls_openssl.c
>> +++ b/libavformat/tls_openssl.c
>> @@ -35,6 +35,7 @@
>> #include 
>> #include 
>> #include 
>> +#include 
>> 
>> static int openssl_init;
>> 
>> @@ -269,8 +270,6 @@ static int tls_open(URLContext *h, const char *uri, int 
>> flags, AVDictionary **op
>> ret = AVERROR(EIO);
>> goto fail;
>> }
>> -// Note, this doesn't check that the peer certificate actually matches
>> -// the requested hostname.
>> if (c->verify)
>> SSL_CTX_set_verify(p->ctx, 
>> SSL_VERIFY_PEER|SSL_VERIFY_FAIL_IF_NO_PEER_CERT, NULL);
>> p->ssl = SSL_new(p->ctx);
>> @@ -294,8 +293,23 @@ static int tls_open(URLContext *h, const char *uri, int 
>> flags, AVDictionary **op
>> bio->ptr = c->tcp;
>> #endif
>> SSL_set_bio(p->ssl, bio, bio);
>> -if (!c->listen && !c->numerichost)
>> -SSL_set_tlsext_host_name(p->ssl, c->host);
> 
>> +if (!c->listen && !c->numerichost) {
>> +#if OPENSSL_VERSION_NUMBER >= 0x101fL
>> +X509_VERIFY_PARAM *param = SSL_get0_param(p->ssl);
>> +X509_VERIFY_PARAM_set_hostflags(param, 
>> X509_CHECK_FLAG_NO_PARTIAL_WILDCARDS);
>> +#endif
>> +if (
>> +#if OPENSSL_VERSION_NUMBER >= 0x101fL
>> +// Note, if on OpenSSL prior to 1.1.0, we won't check that
>> +// the peer certificate actually matches the requested hostname.
>> +!X509_VERIFY_PARAM_set1_host(param, c->host, 0) ||
>> +#endif
>> +!SSL_set_tlsext_host_name(p->ssl, c->host)) {
>> +av_log(h, AV_LOG_ERROR, "%s\n", 
>> ERR_error_string(ERR_get_error(), NULL));
>> +ret = AVERROR(EIO);
>> +goto fail;
>> +}
>> +}
> 
> I think AVERROR(EIO) is not the best choice. EPROTO would seem obvious,
> but not supported on windows. Otherwise EPERM.
> 
> More importantly: with this change, users will no longer be able to
> access misconfigured servers. An option to let them bypass the test
> would be necessary.

What kind of misconfiguration are you referring to? The actual verification is 
still gated behind the tls_verify option; if that's set to 0, this won't 
actually do anything. (Well, it'll result in OpenSSL potentially generating a 
different error code internally, and then discarding it because we didn't 
enable verification).

> 
>> ret = c->listen ? SSL_accept(p->ssl) : SSL_connect(p->ssl);
>> if (ret == 0) {
>> av_log(h, AV_LOG_ERROR, "Unable to negotiate TLS/SSL session\n");
> 
> Regards,
> 
> --
>  Nicolas George
> 
> 



signature.asc
Description: Message signed with OpenPGP
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH] avformat/dashenc: Added documentation for $ext$ identifier in filenames

[Karthick J]

---
 doc/muxers.texi | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/doc/muxers.texi b/doc/muxers.texi
index 4ed46a2220..d2d985f1ac 100644
--- a/doc/muxers.texi
+++ b/doc/muxers.texi
@@ -216,6 +216,8 @@ It creates a MPD manifest file and segment files for each 
stream.
 The segment filename might contain pre-defined identifiers used with 
SegmentTemplate
 as defined in section 5.3.9.4.4 of the standard. Available identifiers are 
"$RepresentationID$",
 "$Number$", "$Bandwidth$" and "$Time$".
+In addition to the standard identifiers, an ffmpeg-specific "$ext$" identifier 
is also supported.
+When specified ffmpeg will replace $ext$ in the file name with muxing format's 
extensions such as mp4, webm etc.,
 
 @example
 ffmpeg -re -i  -map 0 -map 0 -c:a libfdk_aac -c:v libx264
-- 
2.17.1 (Apple Git-112)

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

[FFmpeg-devel] unsubscribe

[Agatha Hu]

---
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.
---
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] avcodec/rscc: Avoid returning frames that have nearly no undamaged pixels in them

[Paul B Mahol]

On 1/17/19, Michael Niedermayer  wrote:
> Fixes: Timeout
> Fixes:
> 12192/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_RSCC_fuzzer-6279038004363264
>
> Before:
> clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_RSCC_fuzzer-6279038004363264
> in 15423 ms
> After:
> clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_RSCC_fuzzer-6279038004363264
> in 190 ms
>
> Found-by: continuous fuzzing process
> https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
> Signed-off-by: Michael Niedermayer 
> ---
>  libavcodec/rscc.c | 7 ++-
>  1 file changed, 6 insertions(+), 1 deletion(-)
>
> diff --git a/libavcodec/rscc.c b/libavcodec/rscc.c
> index 7921f149ed..fa066afd7f 100644
> --- a/libavcodec/rscc.c
> +++ b/libavcodec/rscc.c
> @@ -64,6 +64,7 @@ typedef struct RsccContext {
>  /* zlib interaction */
>  uint8_t *inflated_buf;
>  uLongf inflated_size;
> +int valid_pixels
>  } RsccContext;
>
>  static av_cold int rscc_init(AVCodecContext *avctx)
> @@ -348,7 +349,11 @@ static int rscc_decode_frame(AVCodecContext *avctx,
> void *data,
>  memcpy (frame->data[1], ctx->palette, AVPALETTE_SIZE);
>  }
>
> -*got_frame = 1;
> +// We only return a picture when more than 5% is undameged, this avoids
> copying nearly broken frames around
> +if (ctx->valid_pixels < ctx->inflated_size)
> +ctx->valid_pixels += pixel_size;
> +if (ctx->valid_pixels >= ctx->inflated_size/20)
> +*got_frame = 1;
>
>  ret = avpkt->size;
>  end:
> --
> 2.20.1
>
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>

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

Re: [FFmpeg-devel] [PATCH 1/4] lavf/tls_openssl: silence warning on OpenSSL 1.1 and later

[Nicolas George]

Rodger Combs (12019-01-17):
> CRYPTO_get_locking_callback is a macro returning NULL on 1.1 and
> later. This triggers -Wtautological-pointer-compare ("comparison of
> function 'openssl_lock' equal to a null pointer is always false"),
> which suggests "prefix with the address-of operator to silence this
> warning", so I did that. We could alternately wrap this code in an
> OpenSSL version check, but this seemed easier.

Urgh. Somebody is to blame for that ugliness, but certainly not you. If
it gets in, I suggest you add a comment to explain that.

But this is worrying: elsewhere in the code,
CRYPTO_get_locking_callback() is tested and an array is mallocated if it
is null: that looks like a leak.

I think part of that code needs to be changed to test the array itself
instead of the callbacks.

Regards,

-- 
  Nicolas George


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

Re: [FFmpeg-devel] [PATCH 1/4] lavf/tls_openssl: silence warning on OpenSSL 1.1 and later

[Rodger Combs]

> On Jan 17, 2019, at 03:12, Nicolas George  wrote:
> 
> Signed PGP part
> Rodger Combs (12019-01-17):
>> ---
>> libavformat/tls_openssl.c | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>> 
>> diff --git a/libavformat/tls_openssl.c b/libavformat/tls_openssl.c
>> index 7ae71bdaf3..faa5b8636e 100644
>> --- a/libavformat/tls_openssl.c
>> +++ b/libavformat/tls_openssl.c
>> @@ -102,7 +102,7 @@ void ff_openssl_deinit(void)
>> openssl_init--;
>> if (!openssl_init) {
>> #if HAVE_THREADS
> 
>> -if (CRYPTO_get_locking_callback() == openssl_lock) {
>> +if (CRYPTO_get_locking_callback() == _lock) {
> 
> Using the & operator on a function seems strange. What warnings is it
> supposed to fix, and why?

CRYPTO_get_locking_callback is a macro returning NULL on 1.1 and later. This 
triggers -Wtautological-pointer-compare ("comparison of function 'openssl_lock' 
equal to a null pointer is always false"), which suggests "prefix with the 
address-of operator to silence this warning", so I did that. We could 
alternately wrap this code in an OpenSSL version check, but this seemed easier.

> 
>> int i;
>> CRYPTO_set_locking_callback(NULL);
>> for (i = 0; i < CRYPTO_num_locks(); i++)
> 
> Regards,
> 
> --
>  Nicolas George
> 
> 



signature.asc
Description: Message signed with OpenPGP
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 1/4] lavf/tls_openssl: silence warning on OpenSSL 1.1 and later

[Nicolas George]

Rodger Combs (12019-01-17):
> ---
>  libavformat/tls_openssl.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/libavformat/tls_openssl.c b/libavformat/tls_openssl.c
> index 7ae71bdaf3..faa5b8636e 100644
> --- a/libavformat/tls_openssl.c
> +++ b/libavformat/tls_openssl.c
> @@ -102,7 +102,7 @@ void ff_openssl_deinit(void)
>  openssl_init--;
>  if (!openssl_init) {
>  #if HAVE_THREADS

> -if (CRYPTO_get_locking_callback() == openssl_lock) {
> +if (CRYPTO_get_locking_callback() == _lock) {

Using the & operator on a function seems strange. What warnings is it
supposed to fix, and why?

>  int i;
>  CRYPTO_set_locking_callback(NULL);
>  for (i = 0; i < CRYPTO_num_locks(); i++)

Regards,

-- 
  Nicolas George


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

Re: [FFmpeg-devel] [PATCH 3/4] lavf/tls_openssl: on 1.1 or later, verify the server's hostname

[Nicolas George]

Rodger Combs (12019-01-17):
> ---
>  libavformat/tls_openssl.c | 22 ++
>  1 file changed, 18 insertions(+), 4 deletions(-)
> 
> diff --git a/libavformat/tls_openssl.c b/libavformat/tls_openssl.c
> index 493f43e610..bdc4985bad 100644
> --- a/libavformat/tls_openssl.c
> +++ b/libavformat/tls_openssl.c
> @@ -35,6 +35,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  
>  static int openssl_init;
>  
> @@ -269,8 +270,6 @@ static int tls_open(URLContext *h, const char *uri, int 
> flags, AVDictionary **op
>  ret = AVERROR(EIO);
>  goto fail;
>  }
> -// Note, this doesn't check that the peer certificate actually matches
> -// the requested hostname.
>  if (c->verify)
>  SSL_CTX_set_verify(p->ctx, 
> SSL_VERIFY_PEER|SSL_VERIFY_FAIL_IF_NO_PEER_CERT, NULL);
>  p->ssl = SSL_new(p->ctx);
> @@ -294,8 +293,23 @@ static int tls_open(URLContext *h, const char *uri, int 
> flags, AVDictionary **op
>  bio->ptr = c->tcp;
>  #endif
>  SSL_set_bio(p->ssl, bio, bio);
> -if (!c->listen && !c->numerichost)
> -SSL_set_tlsext_host_name(p->ssl, c->host);

> +if (!c->listen && !c->numerichost) {
> +#if OPENSSL_VERSION_NUMBER >= 0x101fL
> +X509_VERIFY_PARAM *param = SSL_get0_param(p->ssl);
> +X509_VERIFY_PARAM_set_hostflags(param, 
> X509_CHECK_FLAG_NO_PARTIAL_WILDCARDS);
> +#endif
> +if (
> +#if OPENSSL_VERSION_NUMBER >= 0x101fL
> +// Note, if on OpenSSL prior to 1.1.0, we won't check that
> +// the peer certificate actually matches the requested hostname.
> +!X509_VERIFY_PARAM_set1_host(param, c->host, 0) ||
> +#endif
> +!SSL_set_tlsext_host_name(p->ssl, c->host)) {
> +av_log(h, AV_LOG_ERROR, "%s\n", 
> ERR_error_string(ERR_get_error(), NULL));
> +ret = AVERROR(EIO);
> +goto fail;
> +}
> +}

I think AVERROR(EIO) is not the best choice. EPROTO would seem obvious,
but not supported on windows. Otherwise EPERM.

More importantly: with this change, users will no longer be able to
access misconfigured servers. An option to let them bypass the test
would be necessary.

>  ret = c->listen ? SSL_accept(p->ssl) : SSL_connect(p->ssl);
>  if (ret == 0) {
>  av_log(h, AV_LOG_ERROR, "Unable to negotiate TLS/SSL session\n");

Regards,

-- 
  Nicolas George


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

[FFmpeg-devel] [PATCH v2] avformat/dashenc: Format xs:datetime in millisecond precision

[Karthick J]

For low latency streaming even milliseconds matter!
---
 libavformat/dashenc.c | 15 ---
 1 file changed, 12 insertions(+), 3 deletions(-)

diff --git a/libavformat/dashenc.c b/libavformat/dashenc.c
index cfd0f601d4..9c90cf17e5 100644
--- a/libavformat/dashenc.c
+++ b/libavformat/dashenc.c
@@ -32,6 +32,7 @@
 #include "libavutil/mathematics.h"
 #include "libavutil/opt.h"
 #include "libavutil/rational.h"
+#include "libavutil/time.h"
 #include "libavutil/time_internal.h"
 
 #include "avc.h"
@@ -668,12 +669,20 @@ static void write_time(AVIOContext *out, int64_t time)
 
 static void format_date_now(char *buf, int size)
 {
-time_t t = time(NULL);
 struct tm *ptm, tmbuf;
-ptm = gmtime_r(, );
+int64_t time_us = av_gettime();
+int64_t time_ms = time_us / 1000;
+const time_t time_s = time_ms / 1000;
+int millisec = time_ms - (time_s * 1000);
+ptm = gmtime_r(_s, );
 if (ptm) {
-if (!strftime(buf, size, "%Y-%m-%dT%H:%M:%SZ", ptm))
+int len;
+if (!strftime(buf, size, "%Y-%m-%dT%H:%M:%S", ptm)) {
 buf[0] = '\0';
+return;
+}
+len = strlen(buf);
+snprintf(buf + len, size - len, ".%03dZ", millisec);
 }
 }
 
-- 
2.17.1 (Apple Git-112)

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

[FFmpeg-devel] [PATCH 1/4] lavf/tls_openssl: silence warning on OpenSSL 1.1 and later

[Rodger Combs]

---
 libavformat/tls_openssl.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/libavformat/tls_openssl.c b/libavformat/tls_openssl.c
index 7ae71bdaf3..faa5b8636e 100644
--- a/libavformat/tls_openssl.c
+++ b/libavformat/tls_openssl.c
@@ -102,7 +102,7 @@ void ff_openssl_deinit(void)
 openssl_init--;
 if (!openssl_init) {
 #if HAVE_THREADS
-if (CRYPTO_get_locking_callback() == openssl_lock) {
+if (CRYPTO_get_locking_callback() == _lock) {
 int i;
 CRYPTO_set_locking_callback(NULL);
 for (i = 0; i < CRYPTO_num_locks(); i++)
-- 
2.19.1

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

[FFmpeg-devel] [PATCH 2/4] lavf/tls_openssl: if no CA path is set, use the system default

[Rodger Combs]

This is consistent with the other TLS wrappers
---
 libavformat/tls_openssl.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/libavformat/tls_openssl.c b/libavformat/tls_openssl.c
index faa5b8636e..493f43e610 100644
--- a/libavformat/tls_openssl.c
+++ b/libavformat/tls_openssl.c
@@ -253,6 +253,9 @@ static int tls_open(URLContext *h, const char *uri, int 
flags, AVDictionary **op
 if (c->ca_file) {
 if (!SSL_CTX_load_verify_locations(p->ctx, c->ca_file, NULL))
 av_log(h, AV_LOG_ERROR, "SSL_CTX_load_verify_locations %s\n", 
ERR_error_string(ERR_get_error(), NULL));
+} else {
+if (!SSL_CTX_set_default_verify_paths(p->ctx))
+av_log(h, AV_LOG_ERROR, "SSL_CTX_set_default_verify_paths %s\n", 
ERR_error_string(ERR_get_error(), NULL));
 }
 if (c->cert_file && !SSL_CTX_use_certificate_chain_file(p->ctx, 
c->cert_file)) {
 av_log(h, AV_LOG_ERROR, "Unable to load cert file %s: %s\n",
-- 
2.19.1

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

[FFmpeg-devel] [PATCH 4/4] lavf/tls: enable server verification by default when not on mbedtls

[Rodger Combs]

All other TLS wrappers now have a mechanism to load a system trust store
by default, without setting the cafile option. For Secure Transport and
Secure Channel, it's the OS. For OpenSSL and libtls, it's a path set at
compile-time. For GNUTLS, it's either a path set at compile-time, or the
OS trust store (if on macOS, iOS, or Windows). It's possible to configure
OpenSSL, GNUTLS, and libtls without a working trust store, but these are
broken configurations and I don't have a problem with requiring users with
that kind of install to either fix it, or explicitly opt in to insecure
behavior. mbedtls doesn't have a default trust store (it's assumed that the
application will provide one), so it continues to require the user to pass
in a path and enable verification manually.
---
 libavformat/tls.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/libavformat/tls.h b/libavformat/tls.h
index beb19d6d55..988085173e 100644
--- a/libavformat/tls.h
+++ b/libavformat/tls.h
@@ -45,7 +45,7 @@ typedef struct TLSShared {
 #define TLS_COMMON_OPTIONS(pstruct, options_field) \
 {"ca_file","Certificate Authority database file", offsetof(pstruct, 
options_field . ca_file),   AV_OPT_TYPE_STRING, .flags = TLS_OPTFL }, \
 {"cafile", "Certificate Authority database file", offsetof(pstruct, 
options_field . ca_file),   AV_OPT_TYPE_STRING, .flags = TLS_OPTFL }, \
-{"tls_verify", "Verify the peer certificate", offsetof(pstruct, 
options_field . verify),AV_OPT_TYPE_INT, { .i64 = 0 }, 0, 1, .flags = 
TLS_OPTFL }, \
+{"tls_verify", "Verify the peer certificate", offsetof(pstruct, 
options_field . verify),AV_OPT_TYPE_INT, { .i64 = !CONFIG_MBEDTLS }, 0, 1, 
.flags = TLS_OPTFL }, \
 {"cert_file",  "Certificate file",offsetof(pstruct, 
options_field . cert_file), AV_OPT_TYPE_STRING, .flags = TLS_OPTFL }, \
 {"key_file",   "Private key file",offsetof(pstruct, 
options_field . key_file),  AV_OPT_TYPE_STRING, .flags = TLS_OPTFL }, \
 {"listen", "Listen for incoming connections", offsetof(pstruct, 
options_field . listen),AV_OPT_TYPE_INT, { .i64 = 0 }, 0, 1, .flags = 
TLS_OPTFL }, \
-- 
2.19.1

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

[FFmpeg-devel] [PATCH 3/4] lavf/tls_openssl: on 1.1 or later, verify the server's hostname

[Rodger Combs]

---
 libavformat/tls_openssl.c | 22 ++
 1 file changed, 18 insertions(+), 4 deletions(-)

diff --git a/libavformat/tls_openssl.c b/libavformat/tls_openssl.c
index 493f43e610..bdc4985bad 100644
--- a/libavformat/tls_openssl.c
+++ b/libavformat/tls_openssl.c
@@ -35,6 +35,7 @@
 #include 
 #include 
 #include 
+#include 
 
 static int openssl_init;
 
@@ -269,8 +270,6 @@ static int tls_open(URLContext *h, const char *uri, int 
flags, AVDictionary **op
 ret = AVERROR(EIO);
 goto fail;
 }
-// Note, this doesn't check that the peer certificate actually matches
-// the requested hostname.
 if (c->verify)
 SSL_CTX_set_verify(p->ctx, 
SSL_VERIFY_PEER|SSL_VERIFY_FAIL_IF_NO_PEER_CERT, NULL);
 p->ssl = SSL_new(p->ctx);
@@ -294,8 +293,23 @@ static int tls_open(URLContext *h, const char *uri, int 
flags, AVDictionary **op
 bio->ptr = c->tcp;
 #endif
 SSL_set_bio(p->ssl, bio, bio);
-if (!c->listen && !c->numerichost)
-SSL_set_tlsext_host_name(p->ssl, c->host);
+if (!c->listen && !c->numerichost) {
+#if OPENSSL_VERSION_NUMBER >= 0x101fL
+X509_VERIFY_PARAM *param = SSL_get0_param(p->ssl);
+X509_VERIFY_PARAM_set_hostflags(param, 
X509_CHECK_FLAG_NO_PARTIAL_WILDCARDS);
+#endif
+if (
+#if OPENSSL_VERSION_NUMBER >= 0x101fL
+// Note, if on OpenSSL prior to 1.1.0, we won't check that
+// the peer certificate actually matches the requested hostname.
+!X509_VERIFY_PARAM_set1_host(param, c->host, 0) ||
+#endif
+!SSL_set_tlsext_host_name(p->ssl, c->host)) {
+av_log(h, AV_LOG_ERROR, "%s\n", ERR_error_string(ERR_get_error(), 
NULL));
+ret = AVERROR(EIO);
+goto fail;
+}
+}
 ret = c->listen ? SSL_accept(p->ssl) : SSL_connect(p->ssl);
 if (ret == 0) {
 av_log(h, AV_LOG_ERROR, "Unable to negotiate TLS/SSL session\n");
-- 
2.19.1

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

[FFmpeg-devel] [PATCH] avformat/dashenc: Format xs:datetime in millisecond precision

[Karthick J]

For low latency streaming even milliseconds matter!
---
 libavformat/dashenc.c | 13 ++---
 1 file changed, 10 insertions(+), 3 deletions(-)

diff --git a/libavformat/dashenc.c b/libavformat/dashenc.c
index cfd0f601d4..912c1cf11d 100644
--- a/libavformat/dashenc.c
+++ b/libavformat/dashenc.c
@@ -32,6 +32,7 @@
 #include "libavutil/mathematics.h"
 #include "libavutil/opt.h"
 #include "libavutil/rational.h"
+#include "libavutil/time.h"
 #include "libavutil/time_internal.h"
 
 #include "avc.h"
@@ -668,12 +669,18 @@ static void write_time(AVIOContext *out, int64_t time)
 
 static void format_date_now(char *buf, int size)
 {
-time_t t = time(NULL);
 struct tm *ptm, tmbuf;
-ptm = gmtime_r(, );
+int64_t time_us = av_gettime();
+int64_t time_ms = time_us / 1000;
+const time_t time_s = time_ms / 1000;
+int millisec = time_ms - (time_s * 1000);
+ptm = gmtime_r(_s, );
 if (ptm) {
-if (!strftime(buf, size, "%Y-%m-%dT%H:%M:%SZ", ptm))
+int len;
+if (!strftime(buf, size, "%Y-%m-%dT%H:%M:%S", ptm))
 buf[0] = '\0';
+len = strlen(buf);
+snprintf(buf + len, size - len, ".%03dZ", millisec);
 }
 }
 
-- 
2.17.1 (Apple Git-112)

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

Re: [FFmpeg-devel] [PATCH] palettegen: Fill with last color, not black

[Clément Bœsch]

On Wed, Jan 16, 2019 at 01:40:20PM +0100, Tomas Härdin wrote:
> Hi
> 
> I was helping the fine folks at peppercarrot.com with web video
> nonsense, and I notice palettegen outputs more colors than it should
> due to padding the generated palette with pure black.
> 
> Compare this (ffmpeg version 3.2.12-1~deb9u1):
> http://www.härdin.se/files/peppercarrot_gif/output-blackspecks-64.gif
> with this (282a471 with this patch applied):
> http://www.härdin.se/files/peppercarrot_gif/output-fixed-64.gif
> 
> The attached patch fixes this by padding with the last color instead of
> black.
> 
> /Tomas

> From 3a01f62fdcc95cc7afaf5aa6e439b8742cce43bc Mon Sep 17 00:00:00 2001
> From: =?UTF-8?q?Tomas=20H=C3=A4rdin?= 
> Date: Wed, 16 Jan 2019 13:07:48 +0100
> Subject: [PATCH] palettegen: Fill with last color, not black
> 
> If we fill with black then the generated palette will have one color more
> than what the user requested. This also resulted in unwanted black specks in
> the output of paletteuse, especially when generating small palettes.
> ---
>  libavfilter/vf_palettegen.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/libavfilter/vf_palettegen.c b/libavfilter/vf_palettegen.c
> index 5ff73e6b2b..44323782d2 100644
> --- a/libavfilter/vf_palettegen.c
> +++ b/libavfilter/vf_palettegen.c
> @@ -245,7 +245,7 @@ static void write_palette(AVFilterContext *ctx, AVFrame 
> *out)
>  av_log(ctx, AV_LOG_WARNING, "Dupped color: 
> %08"PRIX32"\n", pal[x]);
>  last_color = pal[x];
>  } else {
> -pal[x] = 0xff00; // pad with black
> +pal[x] = last_color; // pad with last color
>  }
>  }
>  pal += pal_linesize;

Code LGTM, thanks

No FATE change?

Regards,

-- 
Clément B.


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