[FFmpeg-devel] [PATCH] avfilter/vf_unsharp: Don't dereference NULL

2019-12-01 Thread Andreas Rheinhardt
The unsharp filter uses an array of arrays of uint32_t, each of which is
separately allocated. These arrays also need to freed separately; but
before doing so, one needs to check whether the array of arrays has
actually been allocated, otherwise one would dereference a NULL pointer.
This fixes #8408.

Furthermore, the array of arrays needs to be zero-initialized so that
no uninitialized pointer will be freed in case an allocation of one of
the individual arrays fails.

Signed-off-by: Andreas Rheinhardt 
---
 libavfilter/vf_unsharp.c | 10 ++
 1 file changed, 6 insertions(+), 4 deletions(-)

diff --git a/libavfilter/vf_unsharp.c b/libavfilter/vf_unsharp.c
index 95b4968d41..7b430b650d 100644
--- a/libavfilter/vf_unsharp.c
+++ b/libavfilter/vf_unsharp.c
@@ -218,7 +218,7 @@ static int init_filter_param(AVFilterContext *ctx, 
UnsharpFilterParam *fp, const
effect, effect_type, fp->msize_x, fp->msize_y, fp->amount / 
65535.0);
 
 fp->sr = av_malloc_array((MAX_MATRIX_SIZE - 1) * s->nb_threads, 
sizeof(uint32_t));
-fp->sc = av_malloc_array(2 * fp->steps_y * s->nb_threads, sizeof(uint32_t 
**));
+fp->sc = av_mallocz_array(2 * fp->steps_y * s->nb_threads, sizeof(uint32_t 
*));
 if (!fp->sr || !fp->sc)
 return AVERROR(ENOMEM);
 
@@ -258,9 +258,11 @@ static void free_filter_param(UnsharpFilterParam *fp, int 
nb_threads)
 {
 int z;
 
-for (z = 0; z < 2 * fp->steps_y * nb_threads; z++)
-av_freep(>sc[z]);
-av_freep(>sc);
+if (fp->sc) {
+for (z = 0; z < 2 * fp->steps_y * nb_threads; z++)
+av_freep(>sc[z]);
+av_freep(>sc);
+}
 av_freep(>sr);
 }
 
-- 
2.20.1

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

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

[FFmpeg-devel] [PATCH 1/3] avformat/avformat: Update av_read_frame() documentation

2019-12-01 Thread Andreas Rheinhardt
This commit updates the documentation of av_read_frame() to match its
actual behaviour in several ways:

1. On success, av_read_frame() always returns refcounted packets.
2. It can handle uninitialized packets.
3. On error, it always returns clean packets.

This will allow callers to not initialize or unref unnecessarily.

Signed-off-by: Andreas Rheinhardt 
---
 doc/APIchanges |  4 
 libavformat/avformat.h | 30 ++
 libavformat/version.h  |  2 +-
 3 files changed, 19 insertions(+), 17 deletions(-)

diff --git a/doc/APIchanges b/doc/APIchanges
index 401c65a753..831747caa5 100644
--- a/doc/APIchanges
+++ b/doc/APIchanges
@@ -15,6 +15,10 @@ libavutil: 2017-10-21
 
 API changes, most recent first:
 
+2019-12-01 - xx - lavf 58.35.101 - avformat.h
+  av_read_frame() now guarantees to handle uninitialized input packets
+  and to return refcounted packets on success.
+
 2019-11-17 - 1c23abc88f - lavu 56.36.100 - eval API
   Add av_expr_count_vars().
 
diff --git a/libavformat/avformat.h b/libavformat/avformat.h
index d4d9a3b06e..ac152609b7 100644
--- a/libavformat/avformat.h
+++ b/libavformat/avformat.h
@@ -170,14 +170,9 @@
  * information will be in AVStream.time_base units, i.e. it has to be
  * multiplied by the timebase to convert them to seconds.
  *
- * If AVPacket.buf is set on the returned packet, then the packet is
- * allocated dynamically and the user may keep it indefinitely.
- * Otherwise, if AVPacket.buf is NULL, the packet data is backed by a
- * static storage somewhere inside the demuxer and the packet is only valid
- * until the next av_read_frame() call or closing the file. If the caller
- * requires a longer lifetime, av_packet_make_refcounted() will ensure that
- * the data is reference counted, copying the data if necessary.
- * In both cases, the packet must be freed with av_packet_unref() when it is no
+ * A packet returned by av_read_frame() is always reference-counted,
+ * i.e. AVPacket.buf is set and the user may keep it indefinitely.
+ * The packet must be freed with av_packet_unref() when it is no
  * longer needed.
  *
  * @section lavf_decoding_seek Seeking
@@ -2397,13 +2392,12 @@ int av_find_best_stream(AVFormatContext *ic,
  * omit invalid data between valid frames so as to give the decoder the maximum
  * information possible for decoding.
  *
- * If pkt->buf is NULL, then the packet is valid until the next
- * av_read_frame() or until avformat_close_input(). Otherwise the packet
- * is valid indefinitely. In both cases the packet must be freed with
- * av_packet_unref when it is no longer needed. For video, the packet contains
- * exactly one frame. For audio, it contains an integer number of frames if 
each
- * frame has a known fixed size (e.g. PCM or ADPCM data). If the audio frames
- * have a variable size (e.g. MPEG audio), then it contains one frame.
+ * On success, the returned packet is reference-counted (pkt->buf is set) and
+ * valid indefinitely. The packet must be freed with av_packet_unref() when
+ * it is no longer needed. For video, the packet contains exactly one frame.
+ * For audio, it contains an integer number of frames if each frame has
+ * a known fixed size (e.g. PCM or ADPCM data). If the audio frames have
+ * a variable size (e.g. MPEG audio), then it contains one frame.
  *
  * pkt->pts, pkt->dts and pkt->duration are always set to correct
  * values in AVStream.time_base units (and guessed if the format cannot
@@ -2411,7 +2405,11 @@ int av_find_best_stream(AVFormatContext *ic,
  * has B-frames, so it is better to rely on pkt->dts if you do not
  * decompress the payload.
  *
- * @return 0 if OK, < 0 on error or end of file
+ * @return 0 if OK, < 0 on error or end of file. On error, pkt will be clean
+ * (as if it came from av_packet_alloc()).
+ *
+ * @note pkt will be initialized, so it may be uninitialized, but it must not
+ *   contain data that needs to be freed.
  */
 int av_read_frame(AVFormatContext *s, AVPacket *pkt);
 
diff --git a/libavformat/version.h b/libavformat/version.h
index bac54aed9d..213b66b45f 100644
--- a/libavformat/version.h
+++ b/libavformat/version.h
@@ -33,7 +33,7 @@
 // Also please add any ticket numbers that you believe might be affected here
 #define LIBAVFORMAT_VERSION_MAJOR  58
 #define LIBAVFORMAT_VERSION_MINOR  35
-#define LIBAVFORMAT_VERSION_MICRO 100
+#define LIBAVFORMAT_VERSION_MICRO 101
 
 #define LIBAVFORMAT_VERSION_INT AV_VERSION_INT(LIBAVFORMAT_VERSION_MAJOR, \
LIBAVFORMAT_VERSION_MINOR, \
-- 
2.20.1

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

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

[FFmpeg-devel] [PATCH 2/3] ffprobe, libavformat: Remove unnecessary initializations and reset

2019-12-01 Thread Andreas Rheinhardt
av_read_frame() can handle uninitialized input packets and it already
returns clean packets on error.

Signed-off-by: Andreas Rheinhardt 
---
 fftools/ffprobe.c| 2 --
 libavformat/hls.c| 1 -
 libavformat/mpegts.c | 2 +-
 3 files changed, 1 insertion(+), 4 deletions(-)

diff --git a/fftools/ffprobe.c b/fftools/ffprobe.c
index a95d74346d..a2956cca90 100644
--- a/fftools/ffprobe.c
+++ b/fftools/ffprobe.c
@@ -2356,8 +2356,6 @@ static int read_interval_packets(WriterContext *w, 
InputFile *ifile,
 int64_t start = -INT64_MAX, end = interval->end;
 int has_start = 0, has_end = interval->has_end && !interval->end_is_offset;
 
-av_init_packet();
-
 av_log(NULL, AV_LOG_VERBOSE, "Processing read interval ");
 log_read_interval(interval, NULL, AV_LOG_VERBOSE);
 
diff --git a/libavformat/hls.c b/libavformat/hls.c
index f60396f246..a2d01c2165 100644
--- a/libavformat/hls.c
+++ b/libavformat/hls.c
@@ -2106,7 +2106,6 @@ static int hls_read_packet(AVFormatContext *s, AVPacket 
*pkt)
 if (ret < 0) {
 if (!avio_feof(>pb) && ret != AVERROR_EOF)
 return ret;
-reset_packet(>pkt);
 break;
 } else {
 /* stream_index check prevents matching picture 
attachments etc. */
diff --git a/libavformat/mpegts.c b/libavformat/mpegts.c
index 587ed33327..864cae850d 100644
--- a/libavformat/mpegts.c
+++ b/libavformat/mpegts.c
@@ -3262,7 +3262,7 @@ static int64_t mpegts_get_dts(AVFormatContext *s, int 
stream_index,
 while(pos < pos_limit) {
 int ret;
 AVPacket pkt;
-av_init_packet();
+
 ret = av_read_frame(s, );
 if (ret < 0)
 return AV_NOPTS_VALUE;
-- 
2.20.1

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

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

[FFmpeg-devel] [PATCH 3/3] avformat/fifo, tee: Don't initialize before av_packet_ref()

2019-12-01 Thread Andreas Rheinhardt
It already initializes the packet.

Signed-off-by: Andreas Rheinhardt 
---
 libavformat/fifo.c | 1 -
 libavformat/tee.c  | 1 -
 2 files changed, 2 deletions(-)

diff --git a/libavformat/fifo.c b/libavformat/fifo.c
index b403ba717b..b9a43b2ff9 100644
--- a/libavformat/fifo.c
+++ b/libavformat/fifo.c
@@ -547,7 +547,6 @@ static int fifo_write_packet(AVFormatContext *avf, AVPacket 
*pkt)
 int ret;
 
 if (pkt) {
-av_init_packet();
 ret = av_packet_ref(,pkt);
 if (ret < 0)
 return ret;
diff --git a/libavformat/tee.c b/libavformat/tee.c
index d91993354b..d632fe2704 100644
--- a/libavformat/tee.c
+++ b/libavformat/tee.c
@@ -571,7 +571,6 @@ static int tee_write_packet(AVFormatContext *avf, AVPacket 
*pkt)
 if (s2 < 0)
 continue;
 
-memset(, 0, sizeof(AVPacket));
 if ((ret = av_packet_ref(, pkt)) < 0)
 if (!ret_all) {
 ret_all = ret;
-- 
2.20.1

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

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH] avfilter/vf_unsharp: Don't dereference NULL

2019-12-01 Thread Paul B Mahol
LGTM

On 12/1/19, Andreas Rheinhardt  wrote:
> The unsharp filter uses an array of arrays of uint32_t, each of which is
> separately allocated. These arrays also need to freed separately; but
> before doing so, one needs to check whether the array of arrays has
> actually been allocated, otherwise one would dereference a NULL pointer.
> This fixes #8408.
>
> Furthermore, the array of arrays needs to be zero-initialized so that
> no uninitialized pointer will be freed in case an allocation of one of
> the individual arrays fails.
>
> Signed-off-by: Andreas Rheinhardt 
> ---
>  libavfilter/vf_unsharp.c | 10 ++
>  1 file changed, 6 insertions(+), 4 deletions(-)
>
> diff --git a/libavfilter/vf_unsharp.c b/libavfilter/vf_unsharp.c
> index 95b4968d41..7b430b650d 100644
> --- a/libavfilter/vf_unsharp.c
> +++ b/libavfilter/vf_unsharp.c
> @@ -218,7 +218,7 @@ static int init_filter_param(AVFilterContext *ctx,
> UnsharpFilterParam *fp, const
> effect, effect_type, fp->msize_x, fp->msize_y, fp->amount /
> 65535.0);
>
>  fp->sr = av_malloc_array((MAX_MATRIX_SIZE - 1) * s->nb_threads,
> sizeof(uint32_t));
> -fp->sc = av_malloc_array(2 * fp->steps_y * s->nb_threads,
> sizeof(uint32_t **));
> +fp->sc = av_mallocz_array(2 * fp->steps_y * s->nb_threads,
> sizeof(uint32_t *));
>  if (!fp->sr || !fp->sc)
>  return AVERROR(ENOMEM);
>
> @@ -258,9 +258,11 @@ static void free_filter_param(UnsharpFilterParam *fp,
> int nb_threads)
>  {
>  int z;
>
> -for (z = 0; z < 2 * fp->steps_y * nb_threads; z++)
> -av_freep(>sc[z]);
> -av_freep(>sc);
> +if (fp->sc) {
> +for (z = 0; z < 2 * fp->steps_y * nb_threads; z++)
> +av_freep(>sc[z]);
> +av_freep(>sc);
> +}
>  av_freep(>sr);
>  }
>
> --
> 2.20.1
>
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
> To unsubscribe, visit link above, or email
> ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [aarch64] improve performance of ff_hscale_8_to_15_neon

2019-12-01 Thread Clément Bœsch
On Wed, Nov 27, 2019 at 12:30:35PM -0600, Sebastian Pop wrote:
[...]
> From 9ecaa99fab4b8bedf3884344774162636eaa5389 Mon Sep 17 00:00:00 2001
> From: Sebastian Pop 
> Date: Sun, 17 Nov 2019 14:13:13 -0600
> Subject: [PATCH] [aarch64] use FMA and increase vector factor to 4
> 
> This patch implements ff_hscale_8_to_15_neon with NEON fused multiply 
> accumulate
> and bumps the vectorization factor from 2 to 4.
> The speedup is of 34% on Graviton A1 instances based on A-72 cpus:
> 
> $ ffmpeg -nostats -f lavfi -i testsrc2=4k:d=2 -vf 
> bench=start,scale=1024x1024,bench=stop -f null -
> before: t:0.040303 avg:0.040287 max:0.040371 min:0.039214
> after:  t:0.030079 avg:0.030102 max:0.030462 min:0.030051
> 
> Tested with `make check` on aarch64-linux.
> ---
>  libswscale/aarch64/hscale.S | 102 
>  1 file changed, 68 insertions(+), 34 deletions(-)
> 
> diff --git a/libswscale/aarch64/hscale.S b/libswscale/aarch64/hscale.S
> index cc78c1901d..12ee7f09e7 100644
> --- a/libswscale/aarch64/hscale.S
> +++ b/libswscale/aarch64/hscale.S
> @@ -21,39 +21,73 @@
>  #include "libavutil/aarch64/asm.S"
>  
>  function ff_hscale_8_to_15_neon, export=1
> -add x10, x4, w6, UXTW #1// filter2 = filter 
> + filterSize*2 (x2 because int16)
> -1:  ldr w8, [x5], #4// filterPos[0]
> -ldr w9, [x5], #4// filterPos[1]
> -moviv4.4S, #0   // val sum part 1 
> (for dst[0])
> -moviv5.4S, #0   // val sum part 2 
> (for dst[1])
> -mov w7, w6  // filterSize counter
> -mov x13, x3 // srcp = src
> -2:  add x11, x13, w8, UXTW  // srcp + 
> filterPos[0]
> -add x12, x13, w9, UXTW  // srcp + 
> filterPos[1]
> -ld1 {v0.8B}, [x11]  // srcp[filterPos[0] 
> + {0..7}]
> -ld1 {v1.8B}, [x12]  // srcp[filterPos[1] 
> + {0..7}]
> -ld1 {v2.8H}, [x4],  #16 // load 8x16-bit 
> filter values, part 1
> -ld1 {v3.8H}, [x10], #16 // ditto at 
> filter+filterSize for part 2
> -uxtlv0.8H, v0.8B// unpack part 1 to 
> 16-bit
> -uxtlv1.8H, v1.8B// unpack part 2 to 
> 16-bit
> -smull   v16.4S, v0.4H, v2.4H// v16.i32{0..3} = 
> part 1 of: srcp[filterPos[0] + {0..7}] * filter[{0..7}]
> -smull   v18.4S, v1.4H, v3.4H// v18.i32{0..3} = 
> part 1 of: srcp[filterPos[1] + {0..7}] * filter[{0..7}]
> -smull2  v17.4S, v0.8H, v2.8H// v17.i32{0..3} = 
> part 2 of: srcp[filterPos[0] + {0..7}] * filter[{0..7}]
> -smull2  v19.4S, v1.8H, v3.8H// v19.i32{0..3} = 
> part 2 of: srcp[filterPos[1] + {0..7}] * filter[{0..7}]
> -addpv16.4S, v16.4S, v17.4S  // horizontal pair 
> adding of the 8x32-bit multiplied values for part 1 into 4x32-bit
> -addpv18.4S, v18.4S, v19.4S  // horizontal pair 
> adding of the 8x32-bit multiplied values for part 2 into 4x32-bit
> -add v4.4S, v4.4S, v16.4S// update val 
> accumulator for part 1
> -add v5.4S, v5.4S, v18.4S// update val 
> accumulator for part 2
> -add x13, x13, #8// srcp += 8
> -subsw7, w7, #8  // processed 
> 8/filterSize
> -b.gt2b  // inner loop if 
> filterSize not consumed completely
> -mov x4, x10 // filter = filter2
> -add x10, x10, w6, UXTW #1   // filter2 += 
> filterSize*2
> -addpv4.4S, v4.4S, v5.4S // horizontal pair 
> adding of the 8x32-bit sums into 4x32-bit
> -addpv4.4S, v4.4S, v4.4S // horizontal pair 
> adding of the 4x32-bit sums into 2x32-bit
> -sqshrn  v4.4H, v4.4S, #7// shift and clip 
> the 2x16-bit final values
> -st1 {v4.S}[0], [x1], #4 // write to 
> destination
> -subsw2, w2, #2  // dstW -= 2
> -b.gt1b  // loop until end of 
> line

> +sxtwx9, w6
> +sbfiz   x12, x6, #1, #32
> +add x14, x12, x9
> +mov x8, xzr
> +sxtwx10, w2
> +sbfiz   x11, x6, #3, #32
> +sbfiz   x13, x6, #2, #32
> +lsl x14, x14, #1

Did you get this weird dance from the 

Re: [FFmpeg-devel] [PATCH] avfilter/vf_nlmeans: add >8 bit support

2019-12-01 Thread Clément Bœsch
On Wed, Nov 20, 2019 at 10:54:42AM +0100, Paul B Mahol wrote:
> Signed-off-by: Paul B Mahol 
> ---
>  libavfilter/aarch64/vf_nlmeans_init.c |   6 +-
>  libavfilter/nlmeans_template.c| 370 ++
>  libavfilter/vf_nlmeans.c  | 539 ++
>  libavfilter/vf_nlmeans.h  |  59 ++-
>  4 files changed, 548 insertions(+), 426 deletions(-)
>  create mode 100644 libavfilter/nlmeans_template.c

On Aarch64:

In file included from src/libavfilter/aarch64/vf_nlmeans_init.c:20:
src/libavfilter/vf_nlmeans.h:52:11: error: unknown type name 'AVClass'
   52 | const AVClass *class;
  |   ^~~
In file included from src/libavfilter/aarch64/vf_nlmeans_init.c:20:
src/libavfilter/vf_nlmeans.h:74:26: error: unknown type name 'AVFilterContext'
   74 | int (*nlmeans_plane)(AVFilterContext *ctx, int w, int h, int p, int 
r,
  |  ^~~
src/libavfilter/vf_nlmeans.h:77:1: warning: no semicolon at end of struct or 
union
   77 | } NLMeansContext;
  | ^
CC  libavfilter/vf_nlmeans.o

Note: not the same issue as the one reported by Michael.

[...]
> -static av_cold int init(AVFilterContext *ctx)
> +static int config_input(AVFilterLink *inlink)
>  {
> -int i;
> +AVFilterContext *ctx = inlink->dst;
>  NLMeansContext *s = ctx->priv;
> -const double h = s->sigma * 10.;
> +const AVPixFmtDescriptor *desc = av_pix_fmt_desc_get(inlink->format);
> +double h;
> +int e;
>  

> +s->depth = desc->comp[0].depth;
> +h = s->sigma * 10. * (1 << (s->depth - 8));
>  s->pdiff_scale = 1. / (h * h);
> -s->max_meaningful_diff = log(255.) / s->pdiff_scale;
> +s->max_meaningful_diff = FFMIN(log(255.) / s->pdiff_scale, INT32_MAX / 
> 8);

I'm assuming log((1 << s->depth) - 1) / s->pdiff_scale wasn't doing the 
expected?

Can you elaborate on this FFMIN?

>  s->weight_lut = av_calloc(s->max_meaningful_diff, 
> sizeof(*s->weight_lut));
>  if (!s->weight_lut)
>  return AVERROR(ENOMEM);
> -for (i = 0; i < s->max_meaningful_diff; i++)
> +for (int i = 0; i < s->max_meaningful_diff; i++)

Could be split but...

>  s->weight_lut[i] = exp(-i * s->pdiff_scale);
>  
>  CHECK_ODD_FIELD(research_size,   "Luma research window");
> @@ -542,11 +183,75 @@ static av_cold int init(AVFilterContext *ctx)
>  s->patch_hsize   = s->patch_size   / 2;
>  s->patch_hsize_uv= s->patch_size_uv/ 2;
>  
> +e = FFMAX(s->research_hsize, s->research_hsize_uv) +
> +FFMAX(s->patch_hsize,s->patch_hsize_uv);
>  av_log(ctx, AV_LOG_INFO, "Research window: %dx%d / %dx%d, patch size: 
> %dx%d / %dx%d\n",
> s->research_size, s->research_size, s->research_size_uv, 
> s->research_size_uv,
> s->patch_size,s->patch_size,s->patch_size_uv,
> s->patch_size_uv);

You're moving a lot of code around, I believe the patch could have been split,
it's hard to follow as is.

[...]
> -void ff_nlmeans_init(NLMeansDSPContext *dsp);
> -void ff_nlmeans_init_aarch64(NLMeansDSPContext *dsp);
> +struct weighted_avg {
> +float total_weight;
> +float sum;
> +};

No point in switching to double for 9+ bits?

-- 
Clément B.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

[FFmpeg-devel] [PATCH] avformat/utils.c: allows av_read_frame to return after a timeout period.

2019-12-01 Thread ggarra13
From: Gonzalo Garramuño 

Moved the check inside and at the end of the if (pktl) as per Michael 
Niedermayer's suggestion.
This patch is based on one from Blake Senftner ( bsenftner at earthlink.net ).

The hanging in av_read_frame can be reproduced with an rtmp stream that is 
aborted midway and ffplay (for example) playing that stream.
---
 libavformat/utils.c | 5 +
 1 file changed, 5 insertions(+)

diff --git a/libavformat/utils.c b/libavformat/utils.c
index 8196442dd1..653918d5a5 100644
--- a/libavformat/utils.c
+++ b/libavformat/utils.c
@@ -1836,6 +1836,11 @@ int av_read_frame(AVFormatContext *s, AVPacket *pkt)

>internal->packet_buffer_end, pkt);
 goto return_packet;
 }
+
+if (ff_check_interrupt(>interrupt_callback)) {
+av_log(s, AV_LOG_DEBUG, "interrupted\n");
+return AVERROR_EXIT;
+}
 }
 
 ret = read_frame_internal(s, pkt);
-- 
2.17.0

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

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH] avformat/utils.c: allows av_read_frame to return after a timeout period.

2019-12-01 Thread Andreas Rheinhardt
ggarr...@gmail.com:
> From: Gonzalo Garramuño 
> 
> Moved the check inside and at the end of the if (pktl) as per Michael 
> Niedermayer's suggestion.
> This patch is based on one from Blake Senftner ( bsenftner at earthlink.net ).
> 
> The hanging in av_read_frame can be reproduced with an rtmp stream that is 
> aborted midway and ffplay (for example) playing that stream.
> ---
>  libavformat/utils.c | 5 +
>  1 file changed, 5 insertions(+)
> 
> diff --git a/libavformat/utils.c b/libavformat/utils.c
> index 8196442dd1..653918d5a5 100644
> --- a/libavformat/utils.c
> +++ b/libavformat/utils.c
> @@ -1836,6 +1836,11 @@ int av_read_frame(AVFormatContext *s, AVPacket *pkt)
> 
> >internal->packet_buffer_end, pkt);
>  goto return_packet;
>  }
> +
> +if (ff_check_interrupt(>interrupt_callback)) {
> +av_log(s, AV_LOG_DEBUG, "interrupted\n");
> +return AVERROR_EXIT;
> +}
>  }
>  
>  ret = read_frame_internal(s, pkt);
>This patch makes it possible for pkt to be still uninitialised after
the call to av_read_frame() if I am not mistaken (namely if the packet
list was initially not empty and the interrupt was triggered before
read_frame_internal() has been called). If so, this clashes with a
recently proposed patch by me
(https://ffmpeg.org/pipermail/ffmpeg-devel/2019-December/253662.html).
One could either allow av_read_frame() to return unclean packets on
error or you would have to add the necessary initializations in your
code (or you would have to make sure that your code is not triggered
before the first call to read_frame_internal()).

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

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

[FFmpeg-devel] [PATCH 1/2] lavf/libsrt: add linger parameter to libsrt

2019-12-01 Thread Jun Zhao
From: Jun Zhao 

add pkt_size parameter to libsrt, it's setting he number of seconds
that the socket waits for unsent data when closing.

Signed-off-by: Jun Zhao 
---
 doc/protocols.texi   |4 
 libavformat/libsrt.c |   13 +
 2 files changed, 17 insertions(+), 0 deletions(-)

diff --git a/doc/protocols.texi b/doc/protocols.texi
index 0e18a49..f34f246 100644
--- a/doc/protocols.texi
+++ b/doc/protocols.texi
@@ -1426,6 +1426,10 @@ the overhead transmission (retransmitted and control 
packets).
 file: Set options as for non-live transmission. See @option{messageapi}
 for further explanations
 
+@item linger=@var{seconds}
+The number of seconds that the socket waits for unsent data when closing.
+Default is -1.
+
 @end table
 
 For more information see: @url{https://github.com/Haivision/srt}.
diff --git a/libavformat/libsrt.c b/libavformat/libsrt.c
index 1c34ec5..0a748a1 100644
--- a/libavformat/libsrt.c
+++ b/libavformat/libsrt.c
@@ -84,6 +84,7 @@ typedef struct SRTContext {
 char *smoother;
 int messageapi;
 SRT_TRANSTYPE transtype;
+int linger;
 } SRTContext;
 
 #define D AV_OPT_FLAG_DECODING_PARAM
@@ -128,6 +129,7 @@ static const AVOption libsrt_options[] = {
 { "transtype",  "The transmission type for the socket",
 OFFSET(transtype),AV_OPT_TYPE_INT,  { .i64 = 
SRTT_INVALID }, SRTT_LIVE, SRTT_INVALID, .flags = D|E, "transtype" },
 { "live",   NULL, 0, AV_OPT_TYPE_CONST,  { .i64 = SRTT_LIVE }, 
INT_MIN, INT_MAX, .flags = D|E, "transtype" },
 { "file",   NULL, 0, AV_OPT_TYPE_CONST,  { .i64 = SRTT_FILE }, 
INT_MIN, INT_MAX, .flags = D|E, "transtype" },
+{ "linger", "Number of seconds that the socket waits for unsent 
data when closing", OFFSET(linger),   AV_OPT_TYPE_INT,  { .i64 = -1 
}, -1, INT_MAX,   .flags = D|E },
 { NULL }
 };
 
@@ -340,6 +342,14 @@ static int libsrt_set_options_pre(URLContext *h, int fd)
 ((h->flags & AVIO_FLAG_WRITE) && libsrt_setsockopt(h, fd, SRTO_SENDER, 
"SRTO_SENDER", , sizeof(yes)) < 0)) {
 return AVERROR(EIO);
 }
+
+if (s->linger >= 0) {
+struct linger lin;
+lin.l_linger = s->linger;
+lin.l_onoff  = lin.l_linger > 0 ? 1 : 0;
+if (libsrt_setsockopt(h, fd, SRTO_LINGER, "SRTO_LINGER", , 
sizeof(lin)) < 0)
+return AVERROR(EIO);
+}
 return 0;
 }
 
@@ -591,6 +601,9 @@ static int libsrt_open(URLContext *h, const char *uri, int 
flags)
 goto err;
 }
 }
+if (av_find_info_tag(buf, sizeof(buf), "linger", p)) {
+s->linger = strtol(buf, NULL, 10);
+}
 }
 return libsrt_setup(h, uri, flags);
 err:
-- 
1.7.1

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

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

[FFmpeg-devel] [PATCH V2 0/2] Enable other srt options.

2019-12-01 Thread Jun Zhao
V2: - correct the commit message.

Jun Zhao (2):
  lavf/libsrt: add linger parameter to libsrt
  lavf/srt: enable other encryption parameters

 doc/protocols.texi   |   20 
 libavformat/libsrt.c |   31 +++
 2 files changed, 51 insertions(+), 0 deletions(-)

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

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

[FFmpeg-devel] [PATCH V2 1/2] lavf/libsrt: add linger parameter to libsrt

2019-12-01 Thread Jun Zhao
From: Jun Zhao 

add linger parameter to libsrt, it's setting he number of seconds
that the socket waits for unsent data when closing.

Signed-off-by: Jun Zhao 
---
 doc/protocols.texi   |4 
 libavformat/libsrt.c |   13 +
 2 files changed, 17 insertions(+), 0 deletions(-)

diff --git a/doc/protocols.texi b/doc/protocols.texi
index 0e18a49..f34f246 100644
--- a/doc/protocols.texi
+++ b/doc/protocols.texi
@@ -1426,6 +1426,10 @@ the overhead transmission (retransmitted and control 
packets).
 file: Set options as for non-live transmission. See @option{messageapi}
 for further explanations
 
+@item linger=@var{seconds}
+The number of seconds that the socket waits for unsent data when closing.
+Default is -1.
+
 @end table
 
 For more information see: @url{https://github.com/Haivision/srt}.
diff --git a/libavformat/libsrt.c b/libavformat/libsrt.c
index 1c34ec5..0a748a1 100644
--- a/libavformat/libsrt.c
+++ b/libavformat/libsrt.c
@@ -84,6 +84,7 @@ typedef struct SRTContext {
 char *smoother;
 int messageapi;
 SRT_TRANSTYPE transtype;
+int linger;
 } SRTContext;
 
 #define D AV_OPT_FLAG_DECODING_PARAM
@@ -128,6 +129,7 @@ static const AVOption libsrt_options[] = {
 { "transtype",  "The transmission type for the socket",
 OFFSET(transtype),AV_OPT_TYPE_INT,  { .i64 = 
SRTT_INVALID }, SRTT_LIVE, SRTT_INVALID, .flags = D|E, "transtype" },
 { "live",   NULL, 0, AV_OPT_TYPE_CONST,  { .i64 = SRTT_LIVE }, 
INT_MIN, INT_MAX, .flags = D|E, "transtype" },
 { "file",   NULL, 0, AV_OPT_TYPE_CONST,  { .i64 = SRTT_FILE }, 
INT_MIN, INT_MAX, .flags = D|E, "transtype" },
+{ "linger", "Number of seconds that the socket waits for unsent 
data when closing", OFFSET(linger),   AV_OPT_TYPE_INT,  { .i64 = -1 
}, -1, INT_MAX,   .flags = D|E },
 { NULL }
 };
 
@@ -340,6 +342,14 @@ static int libsrt_set_options_pre(URLContext *h, int fd)
 ((h->flags & AVIO_FLAG_WRITE) && libsrt_setsockopt(h, fd, SRTO_SENDER, 
"SRTO_SENDER", , sizeof(yes)) < 0)) {
 return AVERROR(EIO);
 }
+
+if (s->linger >= 0) {
+struct linger lin;
+lin.l_linger = s->linger;
+lin.l_onoff  = lin.l_linger > 0 ? 1 : 0;
+if (libsrt_setsockopt(h, fd, SRTO_LINGER, "SRTO_LINGER", , 
sizeof(lin)) < 0)
+return AVERROR(EIO);
+}
 return 0;
 }
 
@@ -591,6 +601,9 @@ static int libsrt_open(URLContext *h, const char *uri, int 
flags)
 goto err;
 }
 }
+if (av_find_info_tag(buf, sizeof(buf), "linger", p)) {
+s->linger = strtol(buf, NULL, 10);
+}
 }
 return libsrt_setup(h, uri, flags);
 err:
-- 
1.7.1

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

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

[FFmpeg-devel] [PATCH V2 2/2] lavf/srt: enable other encryption parameters

2019-12-01 Thread Jun Zhao
From: Jun Zhao 

Enable the SRTO_ENFORCEDENCRYPTION/SRTO_KMREFRESHRATE/
SRTO_KMPREANNOUNCE for srt encryption control.

Signed-off-by: Jun Zhao 
---
 doc/protocols.texi   |   16 
 libavformat/libsrt.c |   18 ++
 2 files changed, 34 insertions(+), 0 deletions(-)

diff --git a/doc/protocols.texi b/doc/protocols.texi
index f34f246..c36e3c9 100644
--- a/doc/protocols.texi
+++ b/doc/protocols.texi
@@ -1282,6 +1282,22 @@ only if @option{pbkeylen} is non-zero. It is used on
 the receiver only if the received data is encrypted.
 The configured passphrase cannot be recovered (write-only).
 
+@item enforced_encryption=@var{1|0}
+If true, both connection parties must have the same password
+set (including empty, that is, with no encryption). If the
+password doesn't match or only one side is unencrypted,
+the connection is rejected. Default is true.
+
+@item kmrefreshrate=@var{n}
+The number of packets to be transmitted after which the
+encryption key is switched to a new key.
+
+@item kmpreannounce=@var{n}
+The interval between when a new encryption key is sent and
+when switchover occurs. This value also applies to the
+subsequent interval between when switchover occurs and
+when the old encryption key is decommissioned.
+
 @item payload_size=@var{bytes}
 Sets the maximum declared size of a packet transferred
 during the single call to the sending function in Live
diff --git a/libavformat/libsrt.c b/libavformat/libsrt.c
index 0a748a1..06f2c02 100644
--- a/libavformat/libsrt.c
+++ b/libavformat/libsrt.c
@@ -62,6 +62,9 @@ typedef struct SRTContext {
 int64_t maxbw;
 int pbkeylen;
 char *passphrase;
+int enforced_encryption;
+int kmrefreshrate;
+int kmpreannounce;
 int mss;
 int ffs;
 int ipttl;
@@ -102,6 +105,9 @@ static const AVOption libsrt_options[] = {
 { "maxbw",  "Maximum bandwidth (bytes per second) that the 
connection can use", OFFSET(maxbw),AV_OPT_TYPE_INT64,{ .i64 
= -1 }, -1, INT64_MAX, .flags = D|E },
 { "pbkeylen",   "Crypto key len in bytes {16,24,32} Default: 16 
(128-bit)", OFFSET(pbkeylen), AV_OPT_TYPE_INT,  { .i64 
= -1 }, -1, 32,.flags = D|E },
 { "passphrase", "Crypto PBKDF2 Passphrase size[0,10..64] 0:disable 
crypto", OFFSET(passphrase),   AV_OPT_TYPE_STRING,   { .str = 
NULL },  .flags = D|E },
+{ "enforced_encryption",  "Enforces that both connection parties have 
the same passphrase set ", OFFSET(enforced_encryption),AV_OPT_TYPE_INT, 
 { .i64 = -1 }, -1, 1, .flags = D|E },
+{ "kmrefreshrate", "The number of packets to be transmitted after 
which the encryption key is switched to a new key", OFFSET(kmrefreshrate),  
 AV_OPT_TYPE_INT,  { .i64 = -1 }, -1, INT_MAX,   .flags = D|E },
+{ "kmpreannounce", "The interval between when a new encryption key 
is sent and when switchover occurs", OFFSET(kmpreannounce),   
AV_OPT_TYPE_INT,  { .i64 = -1 }, -1, INT_MAX,   .flags = D|E },
 { "mss","The Maximum Segment Size",
 OFFSET(mss),  AV_OPT_TYPE_INT,  { .i64 = -1 }, 
-1, 1500,  .flags = D|E },
 { "ffs","Flight flag size (window size) (in bytes)",   
 OFFSET(ffs),  AV_OPT_TYPE_INT,  { .i64 = -1 }, 
-1, INT_MAX,   .flags = D|E },
 { "ipttl",  "IP Time To Live", 
 OFFSET(ipttl),AV_OPT_TYPE_INT,  { .i64 = -1 }, 
-1, 255,   .flags = D|E },
@@ -321,6 +327,9 @@ static int libsrt_set_options_pre(URLContext *h, int fd)
 (s->maxbw >= 0 && libsrt_setsockopt(h, fd, SRTO_MAXBW, "SRTO_MAXBW", 
>maxbw, sizeof(s->maxbw)) < 0) ||
 (s->pbkeylen >= 0 && libsrt_setsockopt(h, fd, SRTO_PBKEYLEN, 
"SRTO_PBKEYLEN", >pbkeylen, sizeof(s->pbkeylen)) < 0) ||
 (s->passphrase && libsrt_setsockopt(h, fd, SRTO_PASSPHRASE, 
"SRTO_PASSPHRASE", s->passphrase, strlen(s->passphrase)) < 0) ||
+(s->enforced_encryption >= 0 && libsrt_setsockopt(h, fd, 
SRTO_ENFORCEDENCRYPTION, "SRTO_ENFORCEDENCRYPTION", >enforced_encryption, 
sizeof(s->enforced_encryption)) < 0) ||
+(s->kmrefreshrate >= 0 && libsrt_setsockopt(h, fd, SRTO_KMREFRESHRATE, 
"SRTO_KMREFRESHRATE", >kmrefreshrate, sizeof(s->kmrefreshrate)) < 0) ||
+(s->kmpreannounce >= 0 && libsrt_setsockopt(h, fd, SRTO_KMPREANNOUNCE, 
"SRTO_KMPREANNOUNCE", >kmpreannounce, sizeof(s->kmpreannounce)) < 0) ||
 (s->mss >= 0 && libsrt_setsockopt(h, fd, SRTO_MSS, "SRTO_MMS", 
>mss, sizeof(s->mss)) < 0) ||
 (s->ffs >= 0 && libsrt_setsockopt(h, fd, SRTO_FC, "SRTO_FC", >ffs, 
sizeof(s->ffs)) < 0) ||
 (s->ipttl >= 0 && libsrt_setsockopt(h, fd, SRTO_IPTTL, "SRTO_UPTTL", 
>ipttl, sizeof(s->ipttl)) < 0) ||
@@ -506,6 +515,15 @@ static int libsrt_open(URLContext *h, const char 

[FFmpeg-devel] [PATCH 2/2] lavf/srt: enable other encryption parameters

2019-12-01 Thread Jun Zhao
From: Jun Zhao 

Enable the SRTO_ENFORCEDENCRYPTION/SRTO_KMREFRESHRATE/
SRTO_KMPREANNOUNCE for srt encryption control.

Signed-off-by: Jun Zhao 
---
 doc/protocols.texi   |   16 
 libavformat/libsrt.c |   18 ++
 2 files changed, 34 insertions(+), 0 deletions(-)

diff --git a/doc/protocols.texi b/doc/protocols.texi
index f34f246..c36e3c9 100644
--- a/doc/protocols.texi
+++ b/doc/protocols.texi
@@ -1282,6 +1282,22 @@ only if @option{pbkeylen} is non-zero. It is used on
 the receiver only if the received data is encrypted.
 The configured passphrase cannot be recovered (write-only).
 
+@item enforced_encryption=@var{1|0}
+If true, both connection parties must have the same password
+set (including empty, that is, with no encryption). If the
+password doesn't match or only one side is unencrypted,
+the connection is rejected. Default is true.
+
+@item kmrefreshrate=@var{n}
+The number of packets to be transmitted after which the
+encryption key is switched to a new key.
+
+@item kmpreannounce=@var{n}
+The interval between when a new encryption key is sent and
+when switchover occurs. This value also applies to the
+subsequent interval between when switchover occurs and
+when the old encryption key is decommissioned.
+
 @item payload_size=@var{bytes}
 Sets the maximum declared size of a packet transferred
 during the single call to the sending function in Live
diff --git a/libavformat/libsrt.c b/libavformat/libsrt.c
index 0a748a1..06f2c02 100644
--- a/libavformat/libsrt.c
+++ b/libavformat/libsrt.c
@@ -62,6 +62,9 @@ typedef struct SRTContext {
 int64_t maxbw;
 int pbkeylen;
 char *passphrase;
+int enforced_encryption;
+int kmrefreshrate;
+int kmpreannounce;
 int mss;
 int ffs;
 int ipttl;
@@ -102,6 +105,9 @@ static const AVOption libsrt_options[] = {
 { "maxbw",  "Maximum bandwidth (bytes per second) that the 
connection can use", OFFSET(maxbw),AV_OPT_TYPE_INT64,{ .i64 
= -1 }, -1, INT64_MAX, .flags = D|E },
 { "pbkeylen",   "Crypto key len in bytes {16,24,32} Default: 16 
(128-bit)", OFFSET(pbkeylen), AV_OPT_TYPE_INT,  { .i64 
= -1 }, -1, 32,.flags = D|E },
 { "passphrase", "Crypto PBKDF2 Passphrase size[0,10..64] 0:disable 
crypto", OFFSET(passphrase),   AV_OPT_TYPE_STRING,   { .str = 
NULL },  .flags = D|E },
+{ "enforced_encryption",  "Enforces that both connection parties have 
the same passphrase set ", OFFSET(enforced_encryption),AV_OPT_TYPE_INT, 
 { .i64 = -1 }, -1, 1, .flags = D|E },
+{ "kmrefreshrate", "The number of packets to be transmitted after 
which the encryption key is switched to a new key", OFFSET(kmrefreshrate),  
 AV_OPT_TYPE_INT,  { .i64 = -1 }, -1, INT_MAX,   .flags = D|E },
+{ "kmpreannounce", "The interval between when a new encryption key 
is sent and when switchover occurs", OFFSET(kmpreannounce),   
AV_OPT_TYPE_INT,  { .i64 = -1 }, -1, INT_MAX,   .flags = D|E },
 { "mss","The Maximum Segment Size",
 OFFSET(mss),  AV_OPT_TYPE_INT,  { .i64 = -1 }, 
-1, 1500,  .flags = D|E },
 { "ffs","Flight flag size (window size) (in bytes)",   
 OFFSET(ffs),  AV_OPT_TYPE_INT,  { .i64 = -1 }, 
-1, INT_MAX,   .flags = D|E },
 { "ipttl",  "IP Time To Live", 
 OFFSET(ipttl),AV_OPT_TYPE_INT,  { .i64 = -1 }, 
-1, 255,   .flags = D|E },
@@ -321,6 +327,9 @@ static int libsrt_set_options_pre(URLContext *h, int fd)
 (s->maxbw >= 0 && libsrt_setsockopt(h, fd, SRTO_MAXBW, "SRTO_MAXBW", 
>maxbw, sizeof(s->maxbw)) < 0) ||
 (s->pbkeylen >= 0 && libsrt_setsockopt(h, fd, SRTO_PBKEYLEN, 
"SRTO_PBKEYLEN", >pbkeylen, sizeof(s->pbkeylen)) < 0) ||
 (s->passphrase && libsrt_setsockopt(h, fd, SRTO_PASSPHRASE, 
"SRTO_PASSPHRASE", s->passphrase, strlen(s->passphrase)) < 0) ||
+(s->enforced_encryption >= 0 && libsrt_setsockopt(h, fd, 
SRTO_ENFORCEDENCRYPTION, "SRTO_ENFORCEDENCRYPTION", >enforced_encryption, 
sizeof(s->enforced_encryption)) < 0) ||
+(s->kmrefreshrate >= 0 && libsrt_setsockopt(h, fd, SRTO_KMREFRESHRATE, 
"SRTO_KMREFRESHRATE", >kmrefreshrate, sizeof(s->kmrefreshrate)) < 0) ||
+(s->kmpreannounce >= 0 && libsrt_setsockopt(h, fd, SRTO_KMPREANNOUNCE, 
"SRTO_KMPREANNOUNCE", >kmpreannounce, sizeof(s->kmpreannounce)) < 0) ||
 (s->mss >= 0 && libsrt_setsockopt(h, fd, SRTO_MSS, "SRTO_MMS", 
>mss, sizeof(s->mss)) < 0) ||
 (s->ffs >= 0 && libsrt_setsockopt(h, fd, SRTO_FC, "SRTO_FC", >ffs, 
sizeof(s->ffs)) < 0) ||
 (s->ipttl >= 0 && libsrt_setsockopt(h, fd, SRTO_IPTTL, "SRTO_UPTTL", 
>ipttl, sizeof(s->ipttl)) < 0) ||
@@ -506,6 +515,15 @@ static int libsrt_open(URLContext *h, const char 

[FFmpeg-devel] [PATCH v2 2/2] avformat/utils: simplify the ff_mkdir_p with SEPARATOR

2019-12-01 Thread lance . lmwang
From: Limin Wang 

Signed-off-by: Limin Wang 
---
 libavformat/utils.c | 16 ++--
 1 file changed, 10 insertions(+), 6 deletions(-)

diff --git a/libavformat/utils.c b/libavformat/utils.c
index 579e6d6..993e6d2 100644
--- a/libavformat/utils.c
+++ b/libavformat/utils.c
@@ -4843,12 +4843,17 @@ void av_url_split(char *proto, int proto_size,
 }
 }
 
+#if HAVE_DOS_PATHS
+#define SEPARATOR '\\'
+#else
+#define SEPARATOR '/'
+#endif
+
 int ff_mkdir_p(const char *path)
 {
 int ret = 0;
 char *temp = av_strdup(path);
 char *pos = temp;
-char tmp_ch = '\0';
 
 if (!path || !temp) {
 return -1;
@@ -4856,19 +4861,18 @@ int ff_mkdir_p(const char *path)
 
 if (*temp == '.')
 pos++;
-if (*temp == '/' || *temp == '\\')
+if (*temp == SEPARATOR)
 pos++;
 
 for ( ; *pos != '\0'; ++pos) {
-if (*pos == '/' || *pos == '\\') {
-tmp_ch = *pos;
+if (*pos == SEPARATOR) {
 *pos = '\0';
 ret = mkdir(temp, 0755);
-*pos = tmp_ch;
+*pos = SEPARATOR;
 }
 }
 
-if ((*(pos - 1) != '/') || (*(pos - 1) != '\\')) {
+if (*(pos - 1) != SEPARATOR) {
 ret = mkdir(temp, 0755);
 }
 
-- 
2.6.4

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

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

[FFmpeg-devel] [PATCH v2 1/2] avformat/utils: simplify the code and remove av_strncasecmp

2019-12-01 Thread lance . lmwang
From: Limin Wang 

Signed-off-by: Limin Wang 
---
 libavformat/utils.c | 7 +++
 1 file changed, 3 insertions(+), 4 deletions(-)

diff --git a/libavformat/utils.c b/libavformat/utils.c
index 8196442..579e6d6 100644
--- a/libavformat/utils.c
+++ b/libavformat/utils.c
@@ -4854,11 +4854,10 @@ int ff_mkdir_p(const char *path)
 return -1;
 }
 
-if (!av_strncasecmp(temp, "/", 1) || !av_strncasecmp(temp, "\\", 1)) {
+if (*temp == '.')
+pos++;
+if (*temp == '/' || *temp == '\\')
 pos++;
-} else if (!av_strncasecmp(temp, "./", 2) || !av_strncasecmp(temp, ".\\", 
2)) {
-pos += 2;
-}
 
 for ( ; *pos != '\0'; ++pos) {
 if (*pos == '/' || *pos == '\\') {
-- 
2.6.4

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

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH 1/7] avcodec/g729dec: Check for KELVIN && 6k4

2019-12-01 Thread Michael Niedermayer
On Sat, Nov 09, 2019 at 11:39:01PM +0100, Michael Niedermayer wrote:
> This combination would assume different block sizes throughout the code so its
> better to error out.
> 
> No testcase
> 
> Signed-off-by: Michael Niedermayer 
> ---
>  libavcodec/g729dec.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)

will apply patchset

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

If you fake or manipulate statistics in a paper in physics you will never
get a job again.
If you fake or manipulate statistics in a paper in medicin you will get
a job for life at the pharma industry.


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

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH 1/4] avcodec/vmdaudio: Check chunk counts to avoid integer overflow

2019-12-01 Thread Michael Niedermayer
On Fri, Nov 08, 2019 at 09:57:07PM +0100, Michael Niedermayer wrote:
> Fixes: signed integer overflow: 4 * 538976288 cannot be represented in type 
> 'int'
> Fixes: 
> 18622/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_VMDAUDIO_fuzzer-5092166174507008
> 
> Found-by: continuous fuzzing process 
> https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
> Signed-off-by: Michael Niedermayer 
> ---
>  libavcodec/vmdaudio.c | 3 +++
>  1 file changed, 3 insertions(+)

will apply

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

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



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

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH 5/8] avformat/mxfdec: Clear metadata_sets_count in mxf_read_close()

2019-12-01 Thread Michael Niedermayer
On Thu, Nov 07, 2019 at 06:04:04PM +0100, Michael Niedermayer wrote:
> On Wed, Nov 06, 2019 at 09:34:01PM +0100, Tomas Härdin wrote:
> > tor 2019-10-31 klockan 18:58 +0100 skrev Michael Niedermayer:
> > > This avoids problems if the function is called twice
> > > 
> > > Signed-off-by: Michael Niedermayer 
> > > ---
> > >  libavformat/mxfdec.c | 1 +
> > >  1 file changed, 1 insertion(+)
> > > 
> > > diff --git a/libavformat/mxfdec.c b/libavformat/mxfdec.c
> > > index f3b1b704f9..68a670154b 100644
> > > --- a/libavformat/mxfdec.c
> > > +++ b/libavformat/mxfdec.c
> > > @@ -3582,6 +3582,7 @@ static int mxf_read_close(AVFormatContext *s)
> > >  for (i = 0; i < mxf->metadata_sets_count; i++) {
> > >  mxf_free_metadataset(mxf->metadata_sets + i, 1);
> > >  }
> > > +mxf->metadata_sets_count = 0;
> > >  av_freep(>partitions);
> > >  av_freep(>metadata_sets);
> > >  av_freep(>aesc);
> > 
> > Looks OK, but I'd work out why close() is called twice
> 
> I dont think i saw a case where it was called twice, i just felt
> that its more robust to clear this

will apply

[...]

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Elect your leaders based on what they did after the last election, not
based on what they say before an election.



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

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH v2 3/4] FATE: add a test for lut1d and lut3d

2019-12-01 Thread Limin Wang
On Thu, Nov 14, 2019 at 10:55:30PM +0100, Michael Niedermayer wrote:
> On Thu, Nov 14, 2019 at 09:46:22PM +0800, lance.lmw...@gmail.com wrote:
> > From: Limin Wang 
> > 
> > Signed-off-by: Limin Wang 
> > ---
> > have tested with x86_64(apple darwin, linux gcc), x86_32(linux), mips
> 
> tested on mingw32/64, qemu arm/mips 

ping the patchset, thx.

> 
> [...]
> -- 
> Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
> 
> Freedom in capitalist society always remains about the same as it was in
> ancient Greek republics: Freedom for slave owners. -- Vladimir Lenin



> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> 
> To unsubscribe, visit link above, or email
> ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

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

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH] avformat/utils.c: allows av_read_frame to return after a timeout period.

2019-12-01 Thread Michael Niedermayer
On Sun, Dec 01, 2019 at 12:05:00PM +, Andreas Rheinhardt wrote:
> ggarr...@gmail.com:
> > From: Gonzalo Garramuño 
> > 
> > Moved the check inside and at the end of the if (pktl) as per Michael 
> > Niedermayer's suggestion.
> > This patch is based on one from Blake Senftner ( bsenftner at earthlink.net 
> > ).
> > 
> > The hanging in av_read_frame can be reproduced with an rtmp stream that is 
> > aborted midway and ffplay (for example) playing that stream.
> > ---
> >  libavformat/utils.c | 5 +
> >  1 file changed, 5 insertions(+)
> > 
> > diff --git a/libavformat/utils.c b/libavformat/utils.c
> > index 8196442dd1..653918d5a5 100644
> > --- a/libavformat/utils.c
> > +++ b/libavformat/utils.c
> > @@ -1836,6 +1836,11 @@ int av_read_frame(AVFormatContext *s, AVPacket *pkt)
> > 
> > >internal->packet_buffer_end, pkt);
> >  goto return_packet;
> >  }
> > +
> > +if (ff_check_interrupt(>interrupt_callback)) {
> > +av_log(s, AV_LOG_DEBUG, "interrupted\n");
> > +return AVERROR_EXIT;
> > +}
> >  }
> >  
> >  ret = read_frame_internal(s, pkt);
> >This patch makes it possible for pkt to be still uninitialised after
> the call to av_read_frame() if I am not mistaken (namely if the packet
> list was initially not empty and the interrupt was triggered before
> read_frame_internal() has been called). If so, this clashes with a
> recently proposed patch by me
> (https://ffmpeg.org/pipermail/ffmpeg-devel/2019-December/253662.html).
> One could either allow av_read_frame() to return unclean packets on
> error or you would have to add the necessary initializations in your
> code (or you would have to make sure that your code is not triggered
> before the first call to read_frame_internal()).

One could theoretically argue that it would make sense to only call the
check after the first read_frame_internal and only before each 
read_frame_internal. Sadly thats not as simple to achieve as moving
the code around, so i didnt suggest it previously

thx

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

Old school: Use the lowest level language in which you can solve the problem
conveniently.
New school: Use the highest level language in which the latest supercomputer
can solve the problem without the user falling asleep waiting.


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

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH 1/3] avformat/flac_picture: Simplify checks

2019-12-01 Thread Michael Niedermayer
On Fri, Nov 29, 2019 at 08:44:09PM +0100, Andreas Rheinhardt wrote:
> During parsing a flac picture metadata block, the mimetype is read as
> follows: Its 32b size field is read and checked for being in the range
> 1..63; afterwards, the actual mimetype-string is read into a buffer of
> size 64, where the length to read is the minimum of the length field and
> the size of the destination buffer -1. Then an assert guards that length
> is indeed < the size of the destination buffer before the string in the
> buffer is zero-terminated.
> 
> The FFMIN as well as the assert are actually redundant, as it has
> been checked that the string (even after terminating) fits into the
> buffer. In order to make this clear, reword the check "len >= 64" to
> "len >= sizeof(mimetype)" and drop the FFMIN as well as the assert.
> 
> Signed-off-by: Andreas Rheinhardt 
> ---
>  libavformat/flac_picture.c | 6 ++
>  1 file changed, 2 insertions(+), 4 deletions(-)

will apply patchset

thx

[...]
-- 
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
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH v1 3/4] avformat/rtpenc_mpegts: removed unused check of avformat_free_context

2019-12-01 Thread Liu Steven


> 在 2019年11月30日,上午2:21,Michael Niedermayer  写道:
> 
> On Fri, Nov 29, 2019 at 01:15:59PM +0800, Steven Liu wrote:
>> Signed-off-by: Steven Liu 
>> ---
>> libavformat/rtpenc_mpegts.c | 3 +--
>> 1 file changed, 1 insertion(+), 2 deletions(-)
>> 
>> diff --git a/libavformat/rtpenc_mpegts.c b/libavformat/rtpenc_mpegts.c
>> index 45ba6fffe5..7d7377db7a 100644
>> --- a/libavformat/rtpenc_mpegts.c
>> +++ b/libavformat/rtpenc_mpegts.c
>> @@ -106,8 +106,7 @@ fail:
>> av_dict_free(_ctx->metadata);
>> avformat_free_context(mpegts_ctx);
>> }
>> -if (rtp_ctx)
>> -avformat_free_context(rtp_ctx);
>> +avformat_free_context(rtp_ctx);
> 
> this and all the other if() removials LGTM
> 
All of them pushed.
> thx
> 
> [...]
> -- 
> Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
> 
> it is not once nor twice but times without number that the same ideas make
> their appearance in the world. -- Aristotle
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> 
> To unsubscribe, visit link above, or email
> ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Steven
Thanks



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

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH v2 1/2] avformat/utils: simplify the code and remove av_strncasecmp

2019-12-01 Thread Hendrik Leppkes
On Sun, Dec 1, 2019 at 3:07 PM  wrote:
>
> From: Limin Wang 
>
> Signed-off-by: Limin Wang 
> ---
>  libavformat/utils.c | 7 +++
>  1 file changed, 3 insertions(+), 4 deletions(-)
>
> diff --git a/libavformat/utils.c b/libavformat/utils.c
> index 8196442..579e6d6 100644
> --- a/libavformat/utils.c
> +++ b/libavformat/utils.c
> @@ -4854,11 +4854,10 @@ int ff_mkdir_p(const char *path)
>  return -1;
>  }
>
> -if (!av_strncasecmp(temp, "/", 1) || !av_strncasecmp(temp, "\\", 1)) {
> +if (*temp == '.')
> +pos++;
> +if (*temp == '/' || *temp == '\\')
>  pos++;
> -} else if (!av_strncasecmp(temp, "./", 2) || !av_strncasecmp(temp, 
> ".\\", 2)) {
> -pos += 2;
> -}
>

Is the change in logic intentional? It seems problematic to me to
potentially skip any dot, not just dots followed by a (back)slash.
Afterall names can start with dots.

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

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH v2 2/2] avformat/utils: simplify the ff_mkdir_p with SEPARATOR

2019-12-01 Thread Hendrik Leppkes
On Sun, Dec 1, 2019 at 3:08 PM  wrote:
>
> From: Limin Wang 
>
> Signed-off-by: Limin Wang 
> ---
>  libavformat/utils.c | 16 ++--
>  1 file changed, 10 insertions(+), 6 deletions(-)
>
> diff --git a/libavformat/utils.c b/libavformat/utils.c
> index 579e6d6..993e6d2 100644
> --- a/libavformat/utils.c
> +++ b/libavformat/utils.c
> @@ -4843,12 +4843,17 @@ void av_url_split(char *proto, int proto_size,
>  }
>  }
>
> +#if HAVE_DOS_PATHS
> +#define SEPARATOR '\\'
> +#else
> +#define SEPARATOR '/'
> +#endif
> +
>  int ff_mkdir_p(const char *path)
>  {
>  int ret = 0;
>  char *temp = av_strdup(path);
>  char *pos = temp;
> -char tmp_ch = '\0';
>
>  if (!path || !temp) {
>  return -1;
> @@ -4856,19 +4861,18 @@ int ff_mkdir_p(const char *path)
>
>  if (*temp == '.')
>  pos++;
> -if (*temp == '/' || *temp == '\\')
> +if (*temp == SEPARATOR)
>  pos++;
>
>  for ( ; *pos != '\0'; ++pos) {
> -if (*pos == '/' || *pos == '\\') {
> -tmp_ch = *pos;
> +if (*pos == SEPARATOR) {
>  *pos = '\0';
>  ret = mkdir(temp, 0755);
> -*pos = tmp_ch;
> +*pos = SEPARATOR;
>  }
>  }
>
> -if ((*(pos - 1) != '/') || (*(pos - 1) != '\\')) {
> +if (*(pos - 1) != SEPARATOR) {
>  ret = mkdir(temp, 0755);
>  }

I think there is some value to be able to specify a path with both
kinds of slashes. For example, most of everything else on Windows will
accept normal slashes, in addition to the default backslash.

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

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH 1/2] avcodec/cbs_av1: implement missing set_frame_refs() function

2019-12-01 Thread James Almer
On 11/17/2019 9:05 PM, James Almer wrote:
> On 11/17/2019 8:55 PM, James Almer wrote:
>> Defined in Section 7.8
>>
>> This finishes implementing support for frames using
>> frame_refs_short_signaling.
>>
>> Signed-off-by: James Almer 
> 
> Here's a sample using short ref signaling:
> https://code.videolan.org/videolan/dav1d-test-data/raw/master/8-bit/features/frames_refs_short_signaling.ivf
> 
> av1_metadata will complain about it, with or without this patch, until
> "avcodec/cbs_av1: keep separate reference frame state for reading and
> writing" or another solution to that issue is applied.

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

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH 2/2] Revert "avcodec/cbs_av1_syntax_template: Check ref_frame_idx before use"

2019-12-01 Thread James Almer
On 11/17/2019 8:55 PM, James Almer wrote:
> This reverts commit 8174e5c77d8a94b57b6b1bcbb90728cf8b08ab6b.
> 
> It's no longer needed after the previous commit.
> ---
>  libavcodec/cbs_av1_syntax_template.c | 7 +++
>  1 file changed, 3 insertions(+), 4 deletions(-)
> 
> diff --git a/libavcodec/cbs_av1_syntax_template.c 
> b/libavcodec/cbs_av1_syntax_template.c
> index 796897ab79..6c4816f964 100644
> --- a/libavcodec/cbs_av1_syntax_template.c
> +++ b/libavcodec/cbs_av1_syntax_template.c
> @@ -530,17 +530,16 @@ static int 
> FUNC(frame_size_with_refs)(CodedBitstreamContext *ctx, RWContext *rw,
>  for (i = 0; i < AV1_REFS_PER_FRAME; i++) {
>  flags(found_ref[i], 1, i);
>  if (current->found_ref[i]) {
> -AV1ReferenceFrameState *ref;
> +AV1ReferenceFrameState *ref =
> +>ref[current->ref_frame_idx[i]];
>  
> -if (current->ref_frame_idx[i] < 0 ||
> -!priv->ref[current->ref_frame_idx[i]].valid) {
> +if (!ref->valid) {
>  av_log(ctx->log_ctx, AV_LOG_ERROR,
> "Missing reference frame needed for frame size "
> "(ref = %d, ref_frame_idx = %d).\n",
> i, current->ref_frame_idx[i]);
>  return AVERROR_INVALIDDATA;
>  }
> -ref = >ref[current->ref_frame_idx[i]];
>  
>  priv->upscaled_width = ref->upscaled_width;
>  priv->frame_width= ref->frame_width;

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

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

[FFmpeg-devel] [PATCH v3] avfilter: Add tonemap vaapi filter for H2S

2019-12-01 Thread Xinpeng Sun
It performs HDR(High Dynamic Range) to SDR(Standard Dynamic Range) conversion
with tone-mapping. It only supports HDR10 as input temporarily.

An example command to use this filter with vaapi codecs:
FFMPEG -hwaccel vaapi -vaapi_device /dev/dri/renderD128 -hwaccel_output_format 
vaapi \
-i INPUT -vf 'tonemap_vaapi=format=p010' -c:v hevc_vaapi -profile 2 OUTPUT

Signed-off-by: Xinpeng Sun 
Signed-off-by: Zachary Zhou 
---
 configure  |   2 +
 doc/filters.texi   |  81 +++
 libavfilter/Makefile   |   1 +
 libavfilter/allfilters.c   |   1 +
 libavfilter/vf_tonemap_vaapi.c | 420 +
 5 files changed, 505 insertions(+)
 create mode 100644 libavfilter/vf_tonemap_vaapi.c

diff --git a/configure b/configure
index ca7137f341..5272fb2a57 100755
--- a/configure
+++ b/configure
@@ -3576,6 +3576,7 @@ tinterlace_filter_deps="gpl"
 tinterlace_merge_test_deps="tinterlace_filter"
 tinterlace_pad_test_deps="tinterlace_filter"
 tonemap_filter_deps="const_nan"
+tonemap_vaapi_filter_deps="vaapi 
VAProcPipelineParameterBuffer_output_hdr_metadata"
 tonemap_opencl_filter_deps="opencl const_nan"
 transpose_opencl_filter_deps="opencl"
 transpose_vaapi_filter_deps="vaapi VAProcPipelineCaps_rotation_flags"
@@ -6576,6 +6577,7 @@ if enabled vaapi; then
 
 check_type "va/va.h va/va_dec_hevc.h" "VAPictureParameterBufferHEVC"
 check_struct "va/va.h" "VADecPictureParameterBufferVP9" bit_depth
+check_struct "va/va.h va/va_vpp.h" "VAProcPipelineParameterBuffer" 
output_hdr_metadata
 check_struct "va/va.h va/va_vpp.h" "VAProcPipelineCaps" rotation_flags
 check_type "va/va.h va/va_enc_hevc.h" "VAEncPictureParameterBufferHEVC"
 check_type "va/va.h va/va_enc_jpeg.h" "VAEncPictureParameterBufferJPEG"
diff --git a/doc/filters.texi b/doc/filters.texi
index 5fdec6f015..7223ab89a3 100644
--- a/doc/filters.texi
+++ b/doc/filters.texi
@@ -20972,6 +20972,87 @@ Apply a strong blur of both luma and chroma parameters:
 
 @c man end OPENCL VIDEO FILTERS
 
+@chapter VAAPI Video Filters
+@c man begin VAAPI VIDEO FILTERS
+
+VAAPI Video filters are usually used with VAAPI decoder and VAAPI encoder. 
Below is a description of VAAPI video filters.
+
+To enable compilation of these filters you need to configure FFmpeg with
+@code{--enable-vaapi}.
+
+Running VAAPI filters requires you to initialize a hardware device and to pass 
that device to all filters in any filter graph.
+@table @option
+
+@item -hwaccel vaapi
+Specify the hardware accelerator as @var{vaapi}.
+
+@item -vaapi_device @var{driver_path}
+Specify the vaapi driver path with @var{driver_path}.
+
+@item -hwaccel_output_format @var{vaapi}
+Specify the output format of hardware accelerator as @var{vaapi}. All VAAPI 
hardware surfaces in ffmpeg are represented by the @var{vaapi} pixfmt.
+
+@end table
+
+@itemize
+@item
+Example of running tonemap_vaapi filter with default parameters on it.
+@example
+-hwaccel vaapi -vaapi_device /dev/dri/renderD128 -hwaccel_output_format vaapi 
-i INPUT -vf "tonemap_vaapi, hwdownload" OUTPUT
+@end example
+@end itemize
+
+Since VAAPI filters are not able to access frame data in arbitrary memory, so 
if you use a decoder other than VAAPI decoder before VAAPI filters, all frame 
data needs to be uploaded(@ref{hwupload}) to hardware surfaces connected to the 
appropriate device before being used. Also if you add a encoder other than 
VAAPI encoder after VAAPI filters, the hardware surfaces should be 
downloaded(@ref{hwdownload}) back to normal memory. Note that @ref{hwupload} 
will upload to a surface with the same layout as the software frame, so it may 
be necessary to add a @ref{format} filter immediately before to get the input 
into the right format and @ref{hwdownload} does not support all formats on the 
output - it may be necessary to insert an additional @ref{format} filter 
immediately following in the graph to get the output in a supported format.
+
+@section tonemap_vappi
+
+Perform HDR(High Dynamic Range) to SDR(Standard Dynamic Range) conversion with 
tone-mapping.
+It maps the dynamic range of HDR10 content to the SDR content.
+It only accepts HDR10 as input temporarily.
+
+It accepts the following parameters:
+
+@table @option
+@item format
+Specify the output pixel format.
+
+Currently supported formats are:
+@table @var
+@item p010
+@item nv12
+@end table
+
+Default is nv12.
+
+@item primaries, p
+Set the output color primaries.
+
+Default is same as input.
+
+@item transfer, t
+Set the output transfer characteristics.
+
+Default is bt709.
+
+@item matrix, m
+Set the output colorspace matrix.
+
+Default is same as input.
+
+@end table
+
+@subsection Example
+
+@itemize
+@item
+Convert HDR(HDR10) video to bt2020-transfer-characteristic p010 format
+@example
+-i INPUT -vf "hwupload,tonemap_vaapi=format=p010:t=bt2020-10,hwdownload" OUTPUT
+@end example
+@end itemize
+
+@c man end VAAPI VIDEO FILTERS
+
 @chapter Video Sources
 @c man begin VIDEO SOURCES
 
diff 

Re: [FFmpeg-devel] [PATCH] avfilter/vf_convolution: add 16-column operation for filter_column() to prepare for x86 SIMD.

2019-12-01 Thread chen
I have a little suggest on filter_column16(..) [the function]


Firstly, the function is confused with filter16_column(..)


Secondly, the function's algoritym based on row direction, it means reduced 
address calculate operators and less cache performance, cost of them may more 
than calculate cost.


For more clear, I give my toy in here, I verify my patch with cmdline in below


 ./ffmpeg -s 1280*720 -pix_fmt yuv420p -i ~/git/sister_720x1280.yuv -vf 
convolution="1 2 3 4 5 6 7 8 9:1 2 3 4 5 6 7 8 9:1 2 3 4 5 6 7 8 9:1 2 3 4 5 6 
7 8 9:1/45:1/45:1/45:1/45:1:2:3:4:column:column:column:column" -an -vframes 
2000 -benchmark -f null /dev/null


The result:
Origin version:   utime=7.359s stime=0.138s rtime=1.664s
Song version:utime=5.320s stime=0.133s rtime=1.250s
My version:   utime=2.930s stime=0.122s rtime=0.794s


ps: since the function processing up to 16-pixels each time, if we split path 
into 16 and non-16, I have got 1.934s in here.




My patch based on today head, I have also corrected Song's merge conflict.


 Patch Start 
diff --git a/libavfilter/vf_convolution.c b/libavfilter/vf_convolution.c
index 5909fea..708732a 100644
--- a/libavfilter/vf_convolution.c
+++ b/libavfilter/vf_convolution.c
@@ -521,6 +521,61 @@ static int filter_slice(AVFilterContext *ctx, void *arg, 
int jobnr, int nb_jobs)
 continue;
 }
 
+if (mode == MATRIX_COLUMN && s->filter[plane] != filter_column){
+for (y = slice_start; y < slice_end - 16; y+=16) {
+const int xoff = (y - slice_start) * bpc;
+const int yoff = radius * stride;
+for (x = 0; x < radius; x++) {
+const int xoff = (y - slice_start) * bpc;
+const int yoff = x * stride;
+
+s->setup[plane](radius, c, src, stride, x, width, y, 
height, bpc);
+s->filter[plane](dst + yoff + xoff, 1, rdiv,
+bias, matrix, c, 16, radius,
+dstride, stride);
+}
+s->setup[plane](radius, c, src, stride, radius, width, y, 
height, bpc);
+s->filter[plane](dst + yoff + xoff, sizew - 2 * radius,
+rdiv, bias, matrix, c, 16, radius,
+dstride, stride);
+for (x = sizew - radius; x < sizew; x++) {
+const int xoff = (y - slice_start) * bpc;
+const int yoff = x * stride;
+
+s->setup[plane](radius, c, src, stride, x, width, y, 
height, bpc);
+s->filter[plane](dst + yoff + xoff, 1, rdiv,
+bias, matrix, c, 16, radius,
+dstride, stride);
+}
+}
+if (y < slice_end){
+const int xoff = (y - slice_start) * bpc;
+const int yoff = radius * stride;
+for (x = 0; x < radius; x++) {
+const int xoff = (y - slice_start) * bpc;
+const int yoff = x * stride;
+
+s->setup[plane](radius, c, src, stride, x, width, y, 
height, bpc);
+s->filter[plane](dst + yoff + xoff, 1, rdiv,
+bias, matrix, c, slice_end - y, radius,
+dstride, stride);
+}
+s->setup[plane](radius, c, src, stride, radius, width, y, 
height, bpc);
+s->filter[plane](dst + yoff + xoff, sizew - 2 * radius,
+rdiv, bias, matrix, c, slice_end - y, radius,
+dstride, stride);
+for (x = sizew - radius; x < sizew; x++) {
+const int xoff = (y - slice_start) * bpc;
+const int yoff = x * stride;
+
+s->setup[plane](radius, c, src, stride, x, width, y, 
height, bpc);
+s->filter[plane](dst + yoff + xoff, 1, rdiv,
+bias, matrix, c, slice_end - y, radius,
+dstride, stride);
+}
+}
+}
+else {
 for (y = slice_start; y < slice_end; y++) {
 const int xoff = mode == MATRIX_COLUMN ? (y - slice_start) * bpc : 
radius * bpc;
 const int yoff = mode == MATRIX_COLUMN ? radius * stride : 0;
@@ -551,6 +606,7 @@ static int filter_slice(AVFilterContext *ctx, void *arg, 
int jobnr, int nb_jobs)
 dst += dstride;
 }
 }
+}
 
 return 0;
 }
diff --git a/libavfilter/x86/vf_convolution_init.c 
b/libavfilter/x86/vf_convolution_init.c
index 5143240..fcc9ae8 100644
--- a/libavfilter/x86/vf_convolution_init.c
+++ b/libavfilter/x86/vf_convolution_init.c
@@ -29,6 +29,56 @@ void ff_filter_3x3_sse4(uint8_t *dst, int width,
 

Re: [FFmpeg-devel] [PATCH] avfilter/vf_convolution: add 16-column operation for filter_column() to prepare for x86 SIMD.

2019-12-01 Thread chen
I have a little suggest on filter_column16(..) [the function]


Firstly, the function is confused with filter16_column(..)


Secondly, the function's algoritym based on row direction, it means reduced 
address calculate operators and less cache performance, cost of them may more 
than calculate cost.


For more clear, I give my toy in here, I verify my patch with cmdline in below


 ./ffmpeg -s 1280*720 -pix_fmt yuv420p -i ~/git/sister_720x1280.yuv -vf 
convolution="1 2 3 4 5 6 7 8 9:1 2 3 4 5 6 7 8 9:1 2 3 4 5 6 7 8 9:1 2 3 4 5 6 
7 8 9:1/45:1/45:1/45:1/45:1:2:3:4:column:column:column:column" -an -vframes 
2000 -benchmark -f null /dev/null


The result:
Origin version:   utime=7.359s stime=0.138s rtime=1.664s
Song version:utime=5.320s stime=0.133s rtime=1.250s
My version:   utime=2.930s stime=0.122s rtime=0.794s




My patch based on today head, I have also corrected Song's merge conflict.


 Patch Start 
diff --git a/libavfilter/vf_convolution.c b/libavfilter/vf_convolution.c
index 5909fea..708732a 100644
--- a/libavfilter/vf_convolution.c
+++ b/libavfilter/vf_convolution.c
@@ -521,6 +521,61 @@ static int filter_slice(AVFilterContext *ctx, void *arg, 
int jobnr, int nb_jobs)
 continue;
 }
 
+if (mode == MATRIX_COLUMN && s->filter[plane] != filter_column){
+for (y = slice_start; y < slice_end - 16; y+=16) {
+const int xoff = (y - slice_start) * bpc;
+const int yoff = radius * stride;
+for (x = 0; x < radius; x++) {
+const int xoff = (y - slice_start) * bpc;
+const int yoff = x * stride;
+
+s->setup[plane](radius, c, src, stride, x, width, y, 
height, bpc);
+s->filter[plane](dst + yoff + xoff, 1, rdiv,
+bias, matrix, c, 16, radius,
+dstride, stride);
+}
+s->setup[plane](radius, c, src, stride, radius, width, y, 
height, bpc);
+s->filter[plane](dst + yoff + xoff, sizew - 2 * radius,
+rdiv, bias, matrix, c, 16, radius,
+dstride, stride);
+for (x = sizew - radius; x < sizew; x++) {
+const int xoff = (y - slice_start) * bpc;
+const int yoff = x * stride;
+
+s->setup[plane](radius, c, src, stride, x, width, y, 
height, bpc);
+s->filter[plane](dst + yoff + xoff, 1, rdiv,
+bias, matrix, c, 16, radius,
+dstride, stride);
+}
+}
+if (y < slice_end){
+const int xoff = (y - slice_start) * bpc;
+const int yoff = radius * stride;
+for (x = 0; x < radius; x++) {
+const int xoff = (y - slice_start) * bpc;
+const int yoff = x * stride;
+
+s->setup[plane](radius, c, src, stride, x, width, y, 
height, bpc);
+s->filter[plane](dst + yoff + xoff, 1, rdiv,
+bias, matrix, c, slice_end - y, radius,
+dstride, stride);
+}
+s->setup[plane](radius, c, src, stride, radius, width, y, 
height, bpc);
+s->filter[plane](dst + yoff + xoff, sizew - 2 * radius,
+rdiv, bias, matrix, c, slice_end - y, radius,
+dstride, stride);
+for (x = sizew - radius; x < sizew; x++) {
+const int xoff = (y - slice_start) * bpc;
+const int yoff = x * stride;
+
+s->setup[plane](radius, c, src, stride, x, width, y, 
height, bpc);
+s->filter[plane](dst + yoff + xoff, 1, rdiv,
+bias, matrix, c, slice_end - y, radius,
+dstride, stride);
+}
+}
+}
+else {
 for (y = slice_start; y < slice_end; y++) {
 const int xoff = mode == MATRIX_COLUMN ? (y - slice_start) * bpc : 
radius * bpc;
 const int yoff = mode == MATRIX_COLUMN ? radius * stride : 0;
@@ -551,6 +606,7 @@ static int filter_slice(AVFilterContext *ctx, void *arg, 
int jobnr, int nb_jobs)
 dst += dstride;
 }
 }
+}
 
 return 0;
 }
diff --git a/libavfilter/x86/vf_convolution_init.c 
b/libavfilter/x86/vf_convolution_init.c
index 5143240..fcc9ae8 100644
--- a/libavfilter/x86/vf_convolution_init.c
+++ b/libavfilter/x86/vf_convolution_init.c
@@ -29,6 +29,56 @@ void ff_filter_3x3_sse4(uint8_t *dst, int width,
 const uint8_t *c[], int peak, int radius,
 int dstride, int stride);
 
+static void 

Re: [FFmpeg-devel] [PATCH] avfilter/vf_convolution: add 16-column operation for filter_column() to prepare for x86 SIMD.

2019-12-01 Thread 徐鋆
I'm sorry not to reply in time.

The performance of this C code is about 10% better than the existing C code.

It will have a bigger improvement after X86 SIMD optimizations.

Xu Jun

- 原始邮件 -
发件人: "Carl Eugen Hoyos" 
收件人: "FFmpeg development discussions and patches" 
发送时间: 星期四, 2019年 11 月 28日 上午 12:19:44
主题: Re: [FFmpeg-devel] [PATCH] avfilter/vf_convolution: add 16-column operation 
for filter_column() to prepare for x86 SIMD.

Am Mi., 27. Nov. 2019 um 15:56 Uhr schrieb :

> From: Xu Jun 
>
> In order to add x86 SIMD for filter_column(), I write a C function which 
> processes 16 columns at a time.

How does this perform compared to the existing C code?

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

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
-- 
敬颂钧安, 
徐鋆 
电子信息与电气工程学院 
上海交通大学 
邮箱:xuju...@sjtu.edu.cn 
地址:上海市闵行区东川路800号 

Yours sincerely, 
Xylem(Jun Xu) 
School of Electronic, Information and Electrical Engineering 
Shanghai Jiao Tong University 
Email: xuju...@sjtu.edu.cn 
No. 800, Dongchuan Road, Minhang District, Shanghai 200240, China 

宜しくお愿いたします 
徐鋆 
電子情報と電気工程学院 
上海交通大学 
メールアドレス :xuju...@sjtu.edu.cn 
住所:上海市閔行区ドンチュワンルー800号
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH] lavc/h2645_parse: Don't automatically remove nuh_layer_id > 0 packets

2019-12-01 Thread Andriy Gelman
On Mon, 02. Dec 00:07, James Almer wrote:
> On 12/1/2019 11:48 PM, Andriy Gelman wrote:
> > From: Andriy Gelman 
> > 
> > HEVC standard supports multi-layer streams (ITU-T H.265 02/2018 Annex
> > F). Each NAL unit belongs to a particular layer defined by nuh_layer_id
> > in the header.
> > 
> > Currently, all NAL units that do not belong to a base layer are
> > automatically removed in ff_h2645_packet_split(). Some data may
> > therefore be lost when future filters/decoders are designed to support
> > multi-layer streams.
> > 
> > A better approach is to forward nuh_layer_id > 0 packets and let blocks
> > down the chain decide how to process them. The condition to remove
> > packets has been moved to hevcdec and cbs bsf where such packets are
> > currently not supported.
> > ---
> >  libavcodec/cbs_h2645.c   | 3 +++
> >  libavcodec/h2645_parse.c | 7 +++
> >  libavcodec/h2645_parse.h | 5 +
> >  libavcodec/hevc_parse.c  | 2 ++
> >  libavcodec/hevc_parser.c | 2 ++
> >  libavcodec/hevcdec.c | 2 +-
> >  6 files changed, 16 insertions(+), 5 deletions(-)
> 
> Missing changes to extract_extradata_bsf.

I did look into this. My reasoning for not modifying extract_extractdata is 
because
the filter doesn't parse parameter sets and only makes them available in packet 
side
data. 

> 
> > 
> > diff --git a/libavcodec/cbs_h2645.c b/libavcodec/cbs_h2645.c
> > index 88fa0029cd6..9f89f1c5a55 100644
> > --- a/libavcodec/cbs_h2645.c
> > +++ b/libavcodec/cbs_h2645.c
> > @@ -562,6 +562,9 @@ static int 
> > cbs_h2645_fragment_add_nals(CodedBitstreamContext *ctx,
> >  
> >  for (i = 0; i < packet->nb_nals; i++) {
> >  const H2645NAL *nal = >nals[i];
> > +if (nal->nuh_layer_id > 0)
> > +continue;
> 
> CBS itself must not ignore them. Users of CBS should be able to choose
> to ignore them, same way you're doing it for h2645_parse and its users
> below.

ok, will update.

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

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH V2 1/2] lavf/libsrt: add linger parameter to libsrt

2019-12-01 Thread Andriy Gelman
On Sun, 01. Dec 21:31, Jun Zhao wrote:
> From: Jun Zhao 
> 
> add linger parameter to libsrt, it's setting he number of seconds
> that the socket waits for unsent data when closing.

minor spelling

> 
> Signed-off-by: Jun Zhao 
> ---
>  doc/protocols.texi   |4 
>  libavformat/libsrt.c |   13 +
>  2 files changed, 17 insertions(+), 0 deletions(-)
> 
> diff --git a/doc/protocols.texi b/doc/protocols.texi
> index 0e18a49..f34f246 100644
> --- a/doc/protocols.texi
> +++ b/doc/protocols.texi
> @@ -1426,6 +1426,10 @@ the overhead transmission (retransmitted and control 
> packets).
>  file: Set options as for non-live transmission. See @option{messageapi}
>  for further explanations
>  

> +@item linger=@var{seconds}
> +The number of seconds that the socket waits for unsent data when closing.
> +Default is -1.

I'd add infinite in brackets.

> +
>  @end table
>  
>  For more information see: @url{https://github.com/Haivision/srt}.
> diff --git a/libavformat/libsrt.c b/libavformat/libsrt.c
> index 1c34ec5..0a748a1 100644
> --- a/libavformat/libsrt.c
> +++ b/libavformat/libsrt.c
> @@ -84,6 +84,7 @@ typedef struct SRTContext {
>  char *smoother;
>  int messageapi;
>  SRT_TRANSTYPE transtype;
> +int linger;
>  } SRTContext;
>  
>  #define D AV_OPT_FLAG_DECODING_PARAM
> @@ -128,6 +129,7 @@ static const AVOption libsrt_options[] = {
>  { "transtype",  "The transmission type for the socket",  
>OFFSET(transtype),AV_OPT_TYPE_INT,  { .i64 = 
> SRTT_INVALID }, SRTT_LIVE, SRTT_INVALID, .flags = D|E, "transtype" },
>  { "live",   NULL, 0, AV_OPT_TYPE_CONST,  { .i64 = SRTT_LIVE }, 
> INT_MIN, INT_MAX, .flags = D|E, "transtype" },
>  { "file",   NULL, 0, AV_OPT_TYPE_CONST,  { .i64 = SRTT_FILE }, 
> INT_MIN, INT_MAX, .flags = D|E, "transtype" },
> +{ "linger", "Number of seconds that the socket waits for unsent 
> data when closing", OFFSET(linger),   AV_OPT_TYPE_INT,  { .i64 = 
> -1 }, -1, INT_MAX,   .flags = D|E },
>  { NULL }
>  };
>  

Are some other parameters (latency, rcvlatency, connect_timeout) in 
milliseconds? (It's not that clear from the docs).
If yes, it may be good to set linger to milliseconds as well.

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

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH V2 1/2] lavf/libsrt: add linger parameter to libsrt

2019-12-01 Thread myp...@gmail.com
On Mon, Dec 2, 2019 at 12:57 PM Andriy Gelman 
wrote:
>
> On Sun, 01. Dec 21:31, Jun Zhao wrote:
> > From: Jun Zhao 
> >
> > add linger parameter to libsrt, it's setting he number of seconds
> > that the socket waits for unsent data when closing.
>
> minor spelling
>
Will fix
> >
> > Signed-off-by: Jun Zhao 
> > ---
> >  doc/protocols.texi   |4 
> >  libavformat/libsrt.c |   13 +
> >  2 files changed, 17 insertions(+), 0 deletions(-)
> >
> > diff --git a/doc/protocols.texi b/doc/protocols.texi
> > index 0e18a49..f34f246 100644
> > --- a/doc/protocols.texi
> > +++ b/doc/protocols.texi
> > @@ -1426,6 +1426,10 @@ the overhead transmission (retransmitted and
control packets).
> >  file: Set options as for non-live transmission. See @option{messageapi}
> >  for further explanations
> >
>
> > +@item linger=@var{seconds}
> > +The number of seconds that the socket waits for unsent data when
closing.
> > +Default is -1.
>
> I'd add infinite in brackets.
Can't get your point, more details?
>
> > +
> >  @end table
> >
> >  For more information see: @url{https://github.com/Haivision/srt}.
> > diff --git a/libavformat/libsrt.c b/libavformat/libsrt.c
> > index 1c34ec5..0a748a1 100644
> > --- a/libavformat/libsrt.c
> > +++ b/libavformat/libsrt.c
> > @@ -84,6 +84,7 @@ typedef struct SRTContext {
> >  char *smoother;
> >  int messageapi;
> >  SRT_TRANSTYPE transtype;
> > +int linger;
> >  } SRTContext;
> >
> >  #define D AV_OPT_FLAG_DECODING_PARAM
> > @@ -128,6 +129,7 @@ static const AVOption libsrt_options[] = {
> >  { "transtype",  "The transmission type for the socket",
  OFFSET(transtype),AV_OPT_TYPE_INT,  {
.i64 = SRTT_INVALID }, SRTT_LIVE, SRTT_INVALID, .flags = D|E, "transtype" },
> >  { "live",   NULL, 0, AV_OPT_TYPE_CONST,  { .i64 =
SRTT_LIVE }, INT_MIN, INT_MAX, .flags = D|E, "transtype" },
> >  { "file",   NULL, 0, AV_OPT_TYPE_CONST,  { .i64 =
SRTT_FILE }, INT_MIN, INT_MAX, .flags = D|E, "transtype" },
> > +{ "linger", "Number of seconds that the socket waits for
unsent data when closing", OFFSET(linger),   AV_OPT_TYPE_INT,
 { .i64 = -1 }, -1, INT_MAX,   .flags = D|E },
> >  { NULL }
> >  };
> >
>
> Are some other parameters (latency, rcvlatency, connect_timeout) in
milliseconds? (It's not that clear from the docs).
> If yes, it may be good to set linger to milliseconds as well.
>
The SRT docs (https://github.com/Haivision/srt/blob/master/docs/API.md)
used the seconds,  and I think SRT borrow the option from socket SO_LINGER
(http://man7.org/linux/man-pages/man7/socket.7.html), we can keep the
similar semantics with seconds.
> --
> Andriy
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [aarch64] improve performance of ff_hscale_8_to_15_neon

2019-12-01 Thread Martin Storsjö

On Sun, 1 Dec 2019, Clément Bœsch wrote:


On Wed, Nov 27, 2019 at 12:30:35PM -0600, Sebastian Pop wrote:
[...]

From 9ecaa99fab4b8bedf3884344774162636eaa5389 Mon Sep 17 00:00:00 2001
From: Sebastian Pop 
Date: Sun, 17 Nov 2019 14:13:13 -0600
Subject: [PATCH] [aarch64] use FMA and increase vector factor to 4

This patch implements ff_hscale_8_to_15_neon with NEON fused multiply accumulate
and bumps the vectorization factor from 2 to 4.
The speedup is of 34% on Graviton A1 instances based on A-72 cpus:

$ ffmpeg -nostats -f lavfi -i testsrc2=4k:d=2 -vf 
bench=start,scale=1024x1024,bench=stop -f null -
before: t:0.040303 avg:0.040287 max:0.040371 min:0.039214
after:  t:0.030079 avg:0.030102 max:0.030462 min:0.030051

Tested with `make check` on aarch64-linux.


FWIW, I'm not certain how much this routine actually is tested by that - 
in particular, there's no checkasm test for it as far as I can see.



+add x17, x3, x18// srcp + filterPos[0]
+add x18, x3, x0 // srcp + filterPos[1]
+add x0, x3, x2  // srcp + filterPos[2]
+add x2, x3, x6  // srcp + filterPos[3]



+2:  ldr d4, [x17, x15]  // srcp[filterPos[0] + 
{0..7}]
+ldr q5, [x16]   // load 8x16-bit 
filter values, part 1
+ldr d6, [x18, x15]  // srcp[filterPos[1] + 
{0..7}]
+ldr q7, [x16, x12]  // load 8x16-bit at 
filter+filterSize


Why not use ld1 {v4.8B} etc like it was before? The use of Dn/Qn in is
very confusing here.


The ldr instruction, instead of ld1, allows you to to do a load (or store, 
similarly, for str instead of st1) with a constant/register offset, like 
[x17, x15] here, without incrementing the source register inbetween for 
each load (which can help with latency between individual load 
instructions, or can avoid extra instructions for incrementing the 
register inbetween).


That works for loading the first 1/2/4/8/16 bytes of a vector, but can't 
be used e.g. for loading a lane other than the first (e.g. ld1 {v4.s}[1]). 
But it does require using the b/h/s/d/q names for the registers instead of 
v.


I didn't check the changes here if they're essential for the optimization 
though.


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

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH] lavc/h2645_parse: Don't automatically remove nuh_layer_id > 0 packets

2019-12-01 Thread James Almer
On 12/1/2019 11:48 PM, Andriy Gelman wrote:
> From: Andriy Gelman 
> 
> HEVC standard supports multi-layer streams (ITU-T H.265 02/2018 Annex
> F). Each NAL unit belongs to a particular layer defined by nuh_layer_id
> in the header.
> 
> Currently, all NAL units that do not belong to a base layer are
> automatically removed in ff_h2645_packet_split(). Some data may
> therefore be lost when future filters/decoders are designed to support
> multi-layer streams.
> 
> A better approach is to forward nuh_layer_id > 0 packets and let blocks
> down the chain decide how to process them. The condition to remove
> packets has been moved to hevcdec and cbs bsf where such packets are
> currently not supported.
> ---
>  libavcodec/cbs_h2645.c   | 3 +++
>  libavcodec/h2645_parse.c | 7 +++
>  libavcodec/h2645_parse.h | 5 +
>  libavcodec/hevc_parse.c  | 2 ++
>  libavcodec/hevc_parser.c | 2 ++
>  libavcodec/hevcdec.c | 2 +-
>  6 files changed, 16 insertions(+), 5 deletions(-)

Missing changes to extract_extradata_bsf.

> 
> diff --git a/libavcodec/cbs_h2645.c b/libavcodec/cbs_h2645.c
> index 88fa0029cd6..9f89f1c5a55 100644
> --- a/libavcodec/cbs_h2645.c
> +++ b/libavcodec/cbs_h2645.c
> @@ -562,6 +562,9 @@ static int 
> cbs_h2645_fragment_add_nals(CodedBitstreamContext *ctx,
>  
>  for (i = 0; i < packet->nb_nals; i++) {
>  const H2645NAL *nal = >nals[i];
> +if (nal->nuh_layer_id > 0)
> +continue;

CBS itself must not ignore them. Users of CBS should be able to choose
to ignore them, same way you're doing it for h2645_parse and its users
below.

> +
>  AVBufferRef *ref;
>  size_t size = nal->size;
>  
> diff --git a/libavcodec/h2645_parse.c b/libavcodec/h2645_parse.c
> index 4808f79a67f..0f3343004f9 100644
> --- a/libavcodec/h2645_parse.c
> +++ b/libavcodec/h2645_parse.c
> @@ -292,23 +292,22 @@ static int get_bit_length(H2645NAL *nal, int 
> skip_trailing_zeros)
>  static int hevc_parse_nal_header(H2645NAL *nal, void *logctx)
>  {
>  GetBitContext *gb = >gb;
> -int nuh_layer_id;
>  
>  if (get_bits1(gb) != 0)
>  return AVERROR_INVALIDDATA;
>  
>  nal->type = get_bits(gb, 6);
>  
> -nuh_layer_id   = get_bits(gb, 6);
> +nal->nuh_layer_id = get_bits(gb, 6);
>  nal->temporal_id = get_bits(gb, 3) - 1;
>  if (nal->temporal_id < 0)
>  return AVERROR_INVALIDDATA;
>  
>  av_log(logctx, AV_LOG_DEBUG,
> "nal_unit_type: %d(%s), nuh_layer_id: %d, temporal_id: %d\n",
> -   nal->type, hevc_nal_unit_name(nal->type), nuh_layer_id, 
> nal->temporal_id);
> +   nal->type, hevc_nal_unit_name(nal->type), nal->nuh_layer_id, 
> nal->temporal_id);
>  
> -return nuh_layer_id == 0;
> +return 1;
>  }
>  
>  static int h264_parse_nal_header(H2645NAL *nal, void *logctx)
> diff --git a/libavcodec/h2645_parse.h b/libavcodec/h2645_parse.h
> index 2acf882d3da..3e47f86c53b 100644
> --- a/libavcodec/h2645_parse.h
> +++ b/libavcodec/h2645_parse.h
> @@ -56,6 +56,11 @@ typedef struct H2645NAL {
>   */
>  int temporal_id;
>  
> +/*
> + * HEVC only, identifier of layer to which nal unit belongs
> + */
> +int nuh_layer_id;
> +
>  int skipped_bytes;
>  int skipped_bytes_pos_size;
>  int *skipped_bytes_pos;
> diff --git a/libavcodec/hevc_parse.c b/libavcodec/hevc_parse.c
> index dddb293df64..29dfd479f38 100644
> --- a/libavcodec/hevc_parse.c
> +++ b/libavcodec/hevc_parse.c
> @@ -37,6 +37,8 @@ static int hevc_decode_nal_units(const uint8_t *buf, int 
> buf_size, HEVCParamSets
>  
>  for (i = 0; i < pkt.nb_nals; i++) {
>  H2645NAL *nal = [i];
> +if (nal->nuh_layer_id > 0)
> +continue;
>  
>  /* ignore everything except parameter sets and VCL NALUs */
>  switch (nal->type) {
> diff --git a/libavcodec/hevc_parser.c b/libavcodec/hevc_parser.c
> index b444b999550..a47104aea9c 100644
> --- a/libavcodec/hevc_parser.c
> +++ b/libavcodec/hevc_parser.c
> @@ -200,6 +200,8 @@ static int parse_nal_units(AVCodecParserContext *s, const 
> uint8_t *buf,
>  
>  for (i = 0; i < ctx->pkt.nb_nals; i++) {
>  H2645NAL *nal = >pkt.nals[i];
> +if (nal->nuh_layer_id > 0)
> +continue;
>  GetBitContext *gb = >gb;
>  
>  switch (nal->type) {
> diff --git a/libavcodec/hevcdec.c b/libavcodec/hevcdec.c
> index 8f1c162acee..bcd8e67944a 100644
> --- a/libavcodec/hevcdec.c
> +++ b/libavcodec/hevcdec.c
> @@ -3077,7 +3077,7 @@ static int decode_nal_units(HEVCContext *s, const 
> uint8_t *buf, int length)
>  
>  if (s->avctx->skip_frame >= AVDISCARD_ALL ||
>  (s->avctx->skip_frame >= AVDISCARD_NONREF
> -&& ff_hevc_nal_is_nonref(nal->type)))
> +&& ff_hevc_nal_is_nonref(nal->type)) || nal->nuh_layer_id > 0)
>  continue;
>  
>  ret = decode_nal_unit(s, nal);
> 

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org

[FFmpeg-devel] [PATCH] libavformat/utils: Fix code indentation

2019-12-01 Thread Linjie Fu
Introduced since 077939626eeaa0c1364065414c18ab9b3a072281.

Signed-off-by: Linjie Fu 
---
 libavformat/utils.c | 22 +++---
 1 file changed, 11 insertions(+), 11 deletions(-)

diff --git a/libavformat/utils.c b/libavformat/utils.c
index 8196442..4d18880 100644
--- a/libavformat/utils.c
+++ b/libavformat/utils.c
@@ -3776,18 +3776,18 @@ FF_ENABLE_DEPRECATION_WARNINGS
 }
 analyzed_all_streams = 0;
 if (!missing_streams || !*missing_streams)
-if (i == ic->nb_streams) {
-analyzed_all_streams = 1;
-/* NOTE: If the format has no header, then we need to read some
- * packets to get most of the streams, so we cannot stop here. */
-if (!(ic->ctx_flags & AVFMTCTX_NOHEADER)) {
-/* If we found the info for all the codecs, we can stop. */
-ret = count;
-av_log(ic, AV_LOG_DEBUG, "All info found\n");
-flush_codecs = 0;
-break;
+if (i == ic->nb_streams) {
+analyzed_all_streams = 1;
+/* NOTE: If the format has no header, then we need to read some
+ * packets to get most of the streams, so we cannot stop here. 
*/
+if (!(ic->ctx_flags & AVFMTCTX_NOHEADER)) {
+/* If we found the info for all the codecs, we can stop. */
+ret = count;
+av_log(ic, AV_LOG_DEBUG, "All info found\n");
+flush_codecs = 0;
+break;
+}
 }
-}
 /* We did not get all the codec info, but we read too much data. */
 if (read_size >= probesize) {
 ret = count;
-- 
2.7.4

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

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH] lavc/h2645_parse: Don't automatically remove nuh_layer_id > 0 packets

2019-12-01 Thread James Almer
On 12/2/2019 12:07 AM, James Almer wrote:
> On 12/1/2019 11:48 PM, Andriy Gelman wrote:
>> From: Andriy Gelman 
>>
>> HEVC standard supports multi-layer streams (ITU-T H.265 02/2018 Annex
>> F). Each NAL unit belongs to a particular layer defined by nuh_layer_id
>> in the header.
>>
>> Currently, all NAL units that do not belong to a base layer are
>> automatically removed in ff_h2645_packet_split(). Some data may
>> therefore be lost when future filters/decoders are designed to support
>> multi-layer streams.
>>
>> A better approach is to forward nuh_layer_id > 0 packets and let blocks
>> down the chain decide how to process them. The condition to remove
>> packets has been moved to hevcdec and cbs bsf where such packets are
>> currently not supported.
>> ---
>>  libavcodec/cbs_h2645.c   | 3 +++
>>  libavcodec/h2645_parse.c | 7 +++
>>  libavcodec/h2645_parse.h | 5 +
>>  libavcodec/hevc_parse.c  | 2 ++
>>  libavcodec/hevc_parser.c | 2 ++
>>  libavcodec/hevcdec.c | 2 +-
>>  6 files changed, 16 insertions(+), 5 deletions(-)
> 
> Missing changes to extract_extradata_bsf.

Actually, probably not. Skipping them there may result in lost data in
the output packet.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

[FFmpeg-devel] [PATCH] avcodec/v210dec: move the stride read after its fully initialized

2019-12-01 Thread Michael Niedermayer
Fixes: out of array read
Fixes: 
19129/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_V210_fuzzer-5068171023482880
Maybe fixes: 
19130/clusterfuzz-testcase-minimized-ffmpeg_AV_CODEC_ID_V210_fuzzer-5637264407527424

Found-by: continuous fuzzing process 
https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer 
---
 libavcodec/v210dec.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/libavcodec/v210dec.c b/libavcodec/v210dec.c
index 8483023815..044d35338b 100644
--- a/libavcodec/v210dec.c
+++ b/libavcodec/v210dec.c
@@ -153,7 +153,6 @@ static int decode_frame(AVCodecContext *avctx, void *data, 
int *got_frame,
 int aligned_width = ((avctx->width + 47) / 48) * 48;
 stride = aligned_width * 8 / 3;
 }
-td.stride = stride;
 
 if (avpkt->size < stride * avctx->height) {
 if avctx->width + 23) / 24) * 24 * 8) / 3 * avctx->height == 
avpkt->size) {
@@ -166,6 +165,7 @@ static int decode_frame(AVCodecContext *avctx, void *data, 
int *got_frame,
 return AVERROR_INVALIDDATA;
 }
 }
+td.stride = stride;
 if (   avctx->codec_tag == MKTAG('C', '2', '1', '0')
 && avpkt->size > 64
 && AV_RN32(psrc) == AV_RN32("INFO")
-- 
2.23.0

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

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH v2 1/2] avformat/utils: simplify the code and remove av_strncasecmp

2019-12-01 Thread Limin Wang
On Sun, Dec 01, 2019 at 05:32:04PM +0100, Hendrik Leppkes wrote:
> On Sun, Dec 1, 2019 at 3:07 PM  wrote:
> >
> > From: Limin Wang 
> >
> > Signed-off-by: Limin Wang 
> > ---
> >  libavformat/utils.c | 7 +++
> >  1 file changed, 3 insertions(+), 4 deletions(-)
> >
> > diff --git a/libavformat/utils.c b/libavformat/utils.c
> > index 8196442..579e6d6 100644
> > --- a/libavformat/utils.c
> > +++ b/libavformat/utils.c
> > @@ -4854,11 +4854,10 @@ int ff_mkdir_p(const char *path)
> >  return -1;
> >  }
> >
> > -if (!av_strncasecmp(temp, "/", 1) || !av_strncasecmp(temp, "\\", 1)) {
> > +if (*temp == '.')
> > +pos++;
> > +if (*temp == '/' || *temp == '\\')
> >  pos++;
> > -} else if (!av_strncasecmp(temp, "./", 2) || !av_strncasecmp(temp, 
> > ".\\", 2)) {
> > -pos += 2;
> > -}
> >
> 
> Is the change in logic intentional? It seems problematic to me to
> potentially skip any dot, not just dots followed by a (back)slash.
> Afterall names can start with dots.

Yes, you're right, I'll update the patch.


> 
> - Hendrik
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> 
> To unsubscribe, visit link above, or email
> ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH v2 2/2] avformat/utils: simplify the ff_mkdir_p with SEPARATOR

2019-12-01 Thread Limin Wang
On Sun, Dec 01, 2019 at 05:33:16PM +0100, Hendrik Leppkes wrote:
> On Sun, Dec 1, 2019 at 3:08 PM  wrote:
> >
> > From: Limin Wang 
> >
> > Signed-off-by: Limin Wang 
> > ---
> >  libavformat/utils.c | 16 ++--
> >  1 file changed, 10 insertions(+), 6 deletions(-)
> >
> > diff --git a/libavformat/utils.c b/libavformat/utils.c
> > index 579e6d6..993e6d2 100644
> > --- a/libavformat/utils.c
> > +++ b/libavformat/utils.c
> > @@ -4843,12 +4843,17 @@ void av_url_split(char *proto, int proto_size,
> >  }
> >  }
> >
> > +#if HAVE_DOS_PATHS
> > +#define SEPARATOR '\\'
> > +#else
> > +#define SEPARATOR '/'
> > +#endif
> > +
> >  int ff_mkdir_p(const char *path)
> >  {
> >  int ret = 0;
> >  char *temp = av_strdup(path);
> >  char *pos = temp;
> > -char tmp_ch = '\0';
> >
> >  if (!path || !temp) {
> >  return -1;
> > @@ -4856,19 +4861,18 @@ int ff_mkdir_p(const char *path)
> >
> >  if (*temp == '.')
> >  pos++;
> > -if (*temp == '/' || *temp == '\\')
> > +if (*temp == SEPARATOR)
> >  pos++;
> >
> >  for ( ; *pos != '\0'; ++pos) {
> > -if (*pos == '/' || *pos == '\\') {
> > -tmp_ch = *pos;
> > +if (*pos == SEPARATOR) {
> >  *pos = '\0';
> >  ret = mkdir(temp, 0755);
> > -*pos = tmp_ch;
> > +*pos = SEPARATOR;
> >  }
> >  }
> >
> > -if ((*(pos - 1) != '/') || (*(pos - 1) != '\\')) {
> > +if (*(pos - 1) != SEPARATOR) {
> >  ret = mkdir(temp, 0755);
> >  }
> 
> I think there is some value to be able to specify a path with both
> kinds of slashes. For example, most of everything else on Windows will
> accept normal slashes, in addition to the default backslash.
Hendrik, I haven't got your point yet, can you make it clear so that I
can change the patch for your case.

For example, on Linux, if the path is:
 ~/Movies/hl\\s/vs%v/manifest.m3u8

The current code will mkdir below path:
path: /Users
path: /Users/lmwang
path: /Users/lmwang/Movies
path: /Users/lmwang/Movies/hl   >>> unexpected
path: /Users/lmwang/Movies/hl\s
path: /Users/lmwang/Movies/hl\s/vs0

You can see /Users/lmwang/Movies/hl directory isn't expected directory which is 
created.

After applied the patch, it'll not create it anymore.

> 
> - Hendrik
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> 
> To unsubscribe, visit link above, or email
> ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH] avfilter/vf_convolution: add 16-column operation for filter_column() to prepare for x86 SIMD.

2019-12-01 Thread Steven Liu


> 在 2019年12月2日,10:42,徐鋆  写道:
> 
> I'm sorry not to reply in time.
> 
> The performance of this C code is about 10% better than the existing C code.
> 
> It will have a bigger improvement after X86 SIMD optimizations.

1. How to test?
1. 怎么测试的?
1. どうやってテストしたの?

2. Don’t TOP-Posting: https://en.wikipedia.org/wiki/Top-posting
2. 回邮件要在你回的那一条的下面回复,别再最上面回复,人家看不懂你是针对的哪一条
2. 返信メールは、あなたが返信した項目の下にある。一番上に返信しないと、あなたが何を狙っているのか分からない

> 
> Xu Jun
> 
> - 原始邮件 -
> 发件人: "Carl Eugen Hoyos" 
> 收件人: "FFmpeg development discussions and patches" 
> 发送时间: 星期四, 2019年 11 月 28日 上午 12:19:44
> 主题: Re: [FFmpeg-devel] [PATCH] avfilter/vf_convolution: add 16-column 
> operation for filter_column() to prepare for x86 SIMD.
> 
> Am Mi., 27. Nov. 2019 um 15:56 Uhr schrieb :
> 
>> From: Xu Jun 
>> 
>> In order to add x86 SIMD for filter_column(), I write a C function which 
>> processes 16 columns at a time.
> 
> How does this perform compared to the existing C code?
> 
> Carl Eugen
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> 
> To unsubscribe, visit link above, or email
> ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
> -- 
> 敬颂钧安, 
> 徐鋆 
> 电子信息与电气工程学院 
> 上海交通大学 
> 邮箱:xuju...@sjtu.edu.cn 
> 地址:上海市闵行区东川路800号 
> 
> Yours sincerely, 
> Xylem(Jun Xu) 
> School of Electronic, Information and Electrical Engineering 
> Shanghai Jiao Tong University 
> Email: xuju...@sjtu.edu.cn 
> No. 800, Dongchuan Road, Minhang District, Shanghai 200240, China 
> 
> 宜しくお愿いたします 
> 徐鋆 
> 電子情報と電気工程学院 
> 上海交通大学 
> メールアドレス :xuju...@sjtu.edu.cn 
> 住所:上海市閔行区ドンチュワンルー800号
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> 
> To unsubscribe, visit link above, or email
> ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Thanks
Steven





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

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

[FFmpeg-devel] [PATCH] lavc/h2645_parse: Don't automatically remove nuh_layer_id > 0 packets

2019-12-01 Thread Andriy Gelman
From: Andriy Gelman 

HEVC standard supports multi-layer streams (ITU-T H.265 02/2018 Annex
F). Each NAL unit belongs to a particular layer defined by nuh_layer_id
in the header.

Currently, all NAL units that do not belong to a base layer are
automatically removed in ff_h2645_packet_split(). Some data may
therefore be lost when future filters/decoders are designed to support
multi-layer streams.

A better approach is to forward nuh_layer_id > 0 packets and let blocks
down the chain decide how to process them. The condition to remove
packets has been moved to hevcdec and cbs bsf where such packets are
currently not supported.
---
 libavcodec/cbs_h2645.c   | 3 +++
 libavcodec/h2645_parse.c | 7 +++
 libavcodec/h2645_parse.h | 5 +
 libavcodec/hevc_parse.c  | 2 ++
 libavcodec/hevc_parser.c | 2 ++
 libavcodec/hevcdec.c | 2 +-
 6 files changed, 16 insertions(+), 5 deletions(-)

diff --git a/libavcodec/cbs_h2645.c b/libavcodec/cbs_h2645.c
index 88fa0029cd6..9f89f1c5a55 100644
--- a/libavcodec/cbs_h2645.c
+++ b/libavcodec/cbs_h2645.c
@@ -562,6 +562,9 @@ static int 
cbs_h2645_fragment_add_nals(CodedBitstreamContext *ctx,
 
 for (i = 0; i < packet->nb_nals; i++) {
 const H2645NAL *nal = >nals[i];
+if (nal->nuh_layer_id > 0)
+continue;
+
 AVBufferRef *ref;
 size_t size = nal->size;
 
diff --git a/libavcodec/h2645_parse.c b/libavcodec/h2645_parse.c
index 4808f79a67f..0f3343004f9 100644
--- a/libavcodec/h2645_parse.c
+++ b/libavcodec/h2645_parse.c
@@ -292,23 +292,22 @@ static int get_bit_length(H2645NAL *nal, int 
skip_trailing_zeros)
 static int hevc_parse_nal_header(H2645NAL *nal, void *logctx)
 {
 GetBitContext *gb = >gb;
-int nuh_layer_id;
 
 if (get_bits1(gb) != 0)
 return AVERROR_INVALIDDATA;
 
 nal->type = get_bits(gb, 6);
 
-nuh_layer_id   = get_bits(gb, 6);
+nal->nuh_layer_id = get_bits(gb, 6);
 nal->temporal_id = get_bits(gb, 3) - 1;
 if (nal->temporal_id < 0)
 return AVERROR_INVALIDDATA;
 
 av_log(logctx, AV_LOG_DEBUG,
"nal_unit_type: %d(%s), nuh_layer_id: %d, temporal_id: %d\n",
-   nal->type, hevc_nal_unit_name(nal->type), nuh_layer_id, 
nal->temporal_id);
+   nal->type, hevc_nal_unit_name(nal->type), nal->nuh_layer_id, 
nal->temporal_id);
 
-return nuh_layer_id == 0;
+return 1;
 }
 
 static int h264_parse_nal_header(H2645NAL *nal, void *logctx)
diff --git a/libavcodec/h2645_parse.h b/libavcodec/h2645_parse.h
index 2acf882d3da..3e47f86c53b 100644
--- a/libavcodec/h2645_parse.h
+++ b/libavcodec/h2645_parse.h
@@ -56,6 +56,11 @@ typedef struct H2645NAL {
  */
 int temporal_id;
 
+/*
+ * HEVC only, identifier of layer to which nal unit belongs
+ */
+int nuh_layer_id;
+
 int skipped_bytes;
 int skipped_bytes_pos_size;
 int *skipped_bytes_pos;
diff --git a/libavcodec/hevc_parse.c b/libavcodec/hevc_parse.c
index dddb293df64..29dfd479f38 100644
--- a/libavcodec/hevc_parse.c
+++ b/libavcodec/hevc_parse.c
@@ -37,6 +37,8 @@ static int hevc_decode_nal_units(const uint8_t *buf, int 
buf_size, HEVCParamSets
 
 for (i = 0; i < pkt.nb_nals; i++) {
 H2645NAL *nal = [i];
+if (nal->nuh_layer_id > 0)
+continue;
 
 /* ignore everything except parameter sets and VCL NALUs */
 switch (nal->type) {
diff --git a/libavcodec/hevc_parser.c b/libavcodec/hevc_parser.c
index b444b999550..a47104aea9c 100644
--- a/libavcodec/hevc_parser.c
+++ b/libavcodec/hevc_parser.c
@@ -200,6 +200,8 @@ static int parse_nal_units(AVCodecParserContext *s, const 
uint8_t *buf,
 
 for (i = 0; i < ctx->pkt.nb_nals; i++) {
 H2645NAL *nal = >pkt.nals[i];
+if (nal->nuh_layer_id > 0)
+continue;
 GetBitContext *gb = >gb;
 
 switch (nal->type) {
diff --git a/libavcodec/hevcdec.c b/libavcodec/hevcdec.c
index 8f1c162acee..bcd8e67944a 100644
--- a/libavcodec/hevcdec.c
+++ b/libavcodec/hevcdec.c
@@ -3077,7 +3077,7 @@ static int decode_nal_units(HEVCContext *s, const uint8_t 
*buf, int length)
 
 if (s->avctx->skip_frame >= AVDISCARD_ALL ||
 (s->avctx->skip_frame >= AVDISCARD_NONREF
-&& ff_hevc_nal_is_nonref(nal->type)))
+&& ff_hevc_nal_is_nonref(nal->type)) || nal->nuh_layer_id > 0)
 continue;
 
 ret = decode_nal_unit(s, nal);
-- 
2.24.0

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

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

[FFmpeg-devel] [PATCH V2 1/2] libswscale/x86/yuv2rgb: Change inline assembly into nasm code

2019-12-01 Thread Ting Fu
Tested using this command:
./ffmpeg -pix_fmt yuv420p -s 1920*1080 -i ArashRawYuv420.yuv \
-vcodec rawvideo -s 1920*1080 -pix_fmt rgb24 -f null /dev/null

The fps increase from 151 to 389 on my local machine.

Signed-off-by: Ting Fu 
---
 libswscale/x86/Makefile   |   1 +
 libswscale/x86/swscale.c  |  16 +-
 libswscale/x86/yuv2rgb.c  |  81 +++---
 libswscale/x86/yuv2rgb_template.c | 441 ++
 libswscale/x86/yuv_2_rgb.asm  | 270 ++
 5 files changed, 395 insertions(+), 414 deletions(-)
 create mode 100644 libswscale/x86/yuv_2_rgb.asm

diff --git a/libswscale/x86/Makefile b/libswscale/x86/Makefile
index f317d5dd9b..831d5359aa 100644
--- a/libswscale/x86/Makefile
+++ b/libswscale/x86/Makefile
@@ -12,3 +12,4 @@ X86ASM-OBJS += x86/input.o
  \
x86/output.o \
x86/scale.o  \
x86/rgb_2_rgb.o  \
+   x86/yuv_2_rgb.o  \
diff --git a/libswscale/x86/swscale.c b/libswscale/x86/swscale.c
index 0eed4f18d5..e9d474a1e8 100644
--- a/libswscale/x86/swscale.c
+++ b/libswscale/x86/swscale.c
@@ -29,6 +29,14 @@
 #include "libavutil/cpu.h"
 #include "libavutil/pixdesc.h"
 
+const DECLARE_ALIGNED(8, uint64_t, ff_dither4)[2] = {
+0x0103010301030103LL,
+0x0200020002000200LL,};
+
+const DECLARE_ALIGNED(8, uint64_t, ff_dither8)[2] = {
+0x0602060206020602LL,
+0x0004000400040004LL,};
+
 #if HAVE_INLINE_ASM
 
 #define DITHER1XBPP
@@ -38,14 +46,6 @@ DECLARE_ASM_CONST(8, uint64_t, bFC)=   
0xFCFCFCFCFCFCFCFCLL;
 DECLARE_ASM_CONST(8, uint64_t, w10)=   0x0010001000100010LL;
 DECLARE_ASM_CONST(8, uint64_t, w02)=   0x0002000200020002LL;
 
-const DECLARE_ALIGNED(8, uint64_t, ff_dither4)[2] = {
-0x0103010301030103LL,
-0x0200020002000200LL,};
-
-const DECLARE_ALIGNED(8, uint64_t, ff_dither8)[2] = {
-0x0602060206020602LL,
-0x0004000400040004LL,};
-
 DECLARE_ASM_CONST(8, uint64_t, b16Mask)=   0x001F001F001F001FLL;
 DECLARE_ASM_CONST(8, uint64_t, g16Mask)=   0x07E007E007E007E0LL;
 DECLARE_ASM_CONST(8, uint64_t, r16Mask)=   0xF800F800F800F800LL;
diff --git a/libswscale/x86/yuv2rgb.c b/libswscale/x86/yuv2rgb.c
index 5e2f77c20f..ed9b613cab 100644
--- a/libswscale/x86/yuv2rgb.c
+++ b/libswscale/x86/yuv2rgb.c
@@ -37,7 +37,7 @@
 #include "libavutil/x86/cpu.h"
 #include "libavutil/cpu.h"
 
-#if HAVE_INLINE_ASM
+#if HAVE_X86ASM
 
 #define DITHER1XBPP // only for MMX
 
@@ -50,70 +50,51 @@ DECLARE_ASM_CONST(8, uint64_t, pb_03) = 
0x0303030303030303ULL;
 DECLARE_ASM_CONST(8, uint64_t, pb_07) = 0x0707070707070707ULL;
 
 //MMX versions
-#if HAVE_MMX_INLINE && HAVE_6REGS
-#undef RENAME
+#if HAVE_MMX
 #undef COMPILE_TEMPLATE_MMXEXT
 #define COMPILE_TEMPLATE_MMXEXT 0
-#define RENAME(a) a ## _mmx
-#include "yuv2rgb_template.c"
-#endif /* HAVE_MMX_INLINE && HAVE_6REGS */
+#endif /* HAVE_MMX */
 
 // MMXEXT versions
-#if HAVE_MMXEXT_INLINE && HAVE_6REGS
-#undef RENAME
+#if HAVE_MMXEXT
 #undef COMPILE_TEMPLATE_MMXEXT
 #define COMPILE_TEMPLATE_MMXEXT 1
-#define RENAME(a) a ## _mmxext
-#include "yuv2rgb_template.c"
-#endif /* HAVE_MMXEXT_INLINE && HAVE_6REGS */
+#endif /* HAVE_MMXEXT */
 
-#endif /* HAVE_INLINE_ASM */
+#include "yuv2rgb_template.c"
 
 av_cold SwsFunc ff_yuv2rgb_init_x86(SwsContext *c)
 {
-#if HAVE_MMX_INLINE && HAVE_6REGS
 int cpu_flags = av_get_cpu_flags();
 
-#if HAVE_MMXEXT_INLINE
-if (INLINE_MMXEXT(cpu_flags)) {
-switch (c->dstFormat) {
-case AV_PIX_FMT_RGB24:
-return yuv420_rgb24_mmxext;
-case AV_PIX_FMT_BGR24:
-return yuv420_bgr24_mmxext;
-}
-}
-#endif
-
-if (INLINE_MMX(cpu_flags)) {
+if (EXTERNAL_MMX(cpu_flags) || EXTERNAL_MMXEXT(cpu_flags)) {
 switch (c->dstFormat) {
-case AV_PIX_FMT_RGB32:
-if (c->srcFormat == AV_PIX_FMT_YUVA420P) {
-#if HAVE_7REGS && CONFIG_SWSCALE_ALPHA
-return yuva420_rgb32_mmx;
+case AV_PIX_FMT_RGB32:
+if (c->srcFormat == AV_PIX_FMT_YUVA420P) {
+#if CONFIG_SWSCALE_ALPHA
+return yuva420_rgb32;
 #endif
-break;
-} else
-return yuv420_rgb32_mmx;
-case AV_PIX_FMT_BGR32:
-if (c->srcFormat == AV_PIX_FMT_YUVA420P) {
-#if HAVE_7REGS && CONFIG_SWSCALE_ALPHA
-return yuva420_bgr32_mmx;
+break;
+} else
+return yuv420_rgb32;
+case AV_PIX_FMT_BGR32:
+if (c->srcFormat == AV_PIX_FMT_YUVA420P) {
+#if CONFIG_SWSCALE_ALPHA
+return yuva420_bgr32;
 #endif
-break;
-} else
-return yuv420_bgr32_mmx;
-case AV_PIX_FMT_RGB24:
-return 

[FFmpeg-devel] [PATCH V2 2/2] libswscale/x86/yuv2rgb: add ssse3 version

2019-12-01 Thread Ting Fu
Tested using this command:
/ffmpeg -pix_fmt yuv420p -s 1920*1080 -i ArashRawYuv420.yuv \
-vcodec rawvideo -s 1920*1080 -pix_fmt rgb24 -f null /dev/null

The fps increase from 389 to 640 on my local machine.

Signed-off-by: Ting Fu 
---
 libswscale/x86/yuv2rgb.c  |   8 +-
 libswscale/x86/yuv2rgb_template.c |  58 ++-
 libswscale/x86/yuv_2_rgb.asm  | 162 +++---
 3 files changed, 209 insertions(+), 19 deletions(-)

diff --git a/libswscale/x86/yuv2rgb.c b/libswscale/x86/yuv2rgb.c
index ed9b613cab..b83dd7089a 100644
--- a/libswscale/x86/yuv2rgb.c
+++ b/libswscale/x86/yuv2rgb.c
@@ -61,13 +61,19 @@ DECLARE_ASM_CONST(8, uint64_t, pb_07) = 
0x0707070707070707ULL;
 #define COMPILE_TEMPLATE_MMXEXT 1
 #endif /* HAVE_MMXEXT */
 
+//SSSE3 versions
+#if HAVE_SSSE3
+#define COMPILE_TEMPLATE_SSSE3 1
+#endif
+
 #include "yuv2rgb_template.c"
 
 av_cold SwsFunc ff_yuv2rgb_init_x86(SwsContext *c)
 {
 int cpu_flags = av_get_cpu_flags();
 
-if (EXTERNAL_MMX(cpu_flags) || EXTERNAL_MMXEXT(cpu_flags)) {
+if (EXTERNAL_MMX(cpu_flags) || EXTERNAL_MMXEXT(cpu_flags) ||
+EXTERNAL_SSSE3(cpu_flags)) {
 switch (c->dstFormat) {
 case AV_PIX_FMT_RGB32:
 if (c->srcFormat == AV_PIX_FMT_YUVA420P) {
diff --git a/libswscale/x86/yuv2rgb_template.c 
b/libswscale/x86/yuv2rgb_template.c
index efe6356f30..fe586047f0 100644
--- a/libswscale/x86/yuv2rgb_template.c
+++ b/libswscale/x86/yuv2rgb_template.c
@@ -40,6 +40,30 @@
 const uint8_t *pv = src[2] +   (y >> vshift) * srcStride[2]; \
 x86_reg index = -h_size / 2; \
 
+extern void ff_yuv_420_rgb24_ssse3(x86_reg index, uint8_t *image, const 
uint8_t *pu_index,
+   const uint8_t *pv_index, const uint8_t 
*pointer_c_dither,
+   const uint8_t *py_2index);
+extern void ff_yuv_420_bgr24_ssse3(x86_reg index, uint8_t *image, const 
uint8_t *pu_index,
+   const uint8_t *pv_index, const uint8_t 
*pointer_c_dither,
+   const uint8_t *py_2index);
+extern void ff_yuv_420_rgb15_ssse3(x86_reg index, uint8_t *image, const 
uint8_t *pu_index,
+   const uint8_t *pv_index, const uint8_t 
*pointer_c_dither,
+   const uint8_t *py_2index);
+extern void ff_yuv_420_rgb16_ssse3(x86_reg index, uint8_t *image, const 
uint8_t *pu_index,
+   const uint8_t *pv_index, const uint8_t 
*pointer_c_dither,
+   const uint8_t *py_2index);
+extern void ff_yuv_420_rgb32_ssse3(x86_reg index, uint8_t *image, const 
uint8_t *pu_index,
+   const uint8_t *pv_index, const uint8_t 
*pointer_c_dither,
+   const uint8_t *py_2index);
+extern void ff_yuv_420_bgr32_ssse3(x86_reg index, uint8_t *image, const 
uint8_t *pu_index,
+   const uint8_t *pv_index, const uint8_t 
*pointer_c_dither,
+   const uint8_t *py_2index);
+extern void ff_yuva_420_rgb32_ssse3(x86_reg index, uint8_t *image, const 
uint8_t *pu_index,
+const uint8_t *pv_index, const uint8_t 
*pointer_c_dither,
+const uint8_t *py_2index, const uint8_t 
*pa_2index);
+extern void ff_yuva_420_bgr32_ssse3(x86_reg index, uint8_t *image, const 
uint8_t *pu_index,
+const uint8_t *pv_index, const uint8_t 
*pointer_c_dither,
+const uint8_t *py_2index, const uint8_t 
*pa_2index);
 extern void ff_yuv_420_rgb24_mmxext(x86_reg index, uint8_t *image, const 
uint8_t *pu_index,
 const uint8_t *pv_index, const uint8_t 
*pointer_c_dither,
 const uint8_t *py_2index);
@@ -84,7 +108,12 @@ static inline int yuv420_rgb15(SwsContext *c, const uint8_t 
*src[],
 c->greenDither = ff_dither8[y   & 1];
 c->redDither   = ff_dither8[(y + 1) & 1];
 #endif
+
+#if COMPILE_TEMPLATE_SSSE3
+ff_yuv_420_rgb15_ssse3(index, image, pu - index, pv - index, 
&(c->redDither), py - 2 * index);
+#else
 ff_yuv_420_rgb15_mmx(index, image, pu - index, pv - index, 
&(c->redDither), py - 2 * index);
+#endif
 }
 return srcSliceH;
 }
@@ -102,7 +131,12 @@ static inline int yuv420_rgb16(SwsContext *c, const 
uint8_t *src[],
 c->greenDither = ff_dither4[y   & 1];
 c->redDither   = ff_dither8[(y + 1) & 1];
 #endif
+
+#if COMPILE_TEMPLATE_SSSE3
+ff_yuv_420_rgb16_ssse3(index, image, pu - index, pv - index, 
&(c->redDither), py - 2 * index);
+#else
 ff_yuv_420_rgb16_mmx(index, image, pu - index, pv - index, 
&(c->redDither), py - 2 * index);
+#endif
 }
 return srcSliceH;
 }
@@ -115,7 +149,9 @@ static inline int yuv420_rgb24(SwsContext *c, const uint8_t 
*src[],
 int 

Re: [FFmpeg-devel] [PATCH 2/2] libswscale/x86/yuv2rgb: add ssse3 version

2019-12-01 Thread Fu, Ting


> -Original Message-
> From: ffmpeg-devel  On Behalf Of
> Michael Niedermayer
> Sent: Friday, November 29, 2019 04:51 AM
> To: FFmpeg development discussions and patches 
> Subject: Re: [FFmpeg-devel] [PATCH 2/2] libswscale/x86/yuv2rgb: add ssse3
> version
> 
> On Thu, Nov 28, 2019 at 02:07:08PM +0800, Ting Fu wrote:
> > Signed-off-by: Ting Fu 
> > ---
> >  libswscale/x86/yuv2rgb.c  |   5 +
> >  libswscale/x86/yuv2rgb_template.c |  58 ++-
> >  libswscale/x86/yuv_2_rgb.asm  | 163 +++---
> >  3 files changed, 208 insertions(+), 18 deletions(-)
> 
> breaks build on x86-32
> make
> X86ASMlibswscale/x86/yuv_2_rgb.o
> src/libswscale/x86/yuv_2_rgb.asm:400: error: parser: instruction expected
> src/libswscale/x86/yuv_2_rgb.asm:331: ... from macro `yuv2rgb_fn' defined
> here
> src/libswscale/x86/yuv_2_rgb.asm:400: error: parser: instruction expected
> src/libswscale/x86/yuv_2_rgb.asm:332: ... from macro `yuv2rgb_fn' defined
> here
> src/libswscale/x86/yuv_2_rgb.asm:400: error: parser: instruction expected
> src/libswscale/x86/yuv_2_rgb.asm:333: ... from macro `yuv2rgb_fn' defined
> here
> src/libswscale/x86/yuv_2_rgb.asm:401: error: label `BROADCAST' inconsistently
> redefined
> src/libswscale/x86/yuv_2_rgb.asm:331: ... from macro `yuv2rgb_fn' defined
> here
> src/libswscale/x86/yuv_2_rgb.asm:400: note: label `BROADCAST' originally
> defined here
> src/libswscale/x86/yuv_2_rgb.asm:331: ... from macro `yuv2rgb_fn' defined
> here
> src/libswscale/x86/yuv_2_rgb.asm:401: error: parser: instruction expected
> src/libswscale/x86/yuv_2_rgb.asm:331: ... from macro `yuv2rgb_fn' defined
> here
> src/libswscale/x86/yuv_2_rgb.asm:401: error: parser: instruction expected
> src/libswscale/x86/yuv_2_rgb.asm:332: ... from macro `yuv2rgb_fn' defined
> here
> src/libswscale/x86/yuv_2_rgb.asm:401: error: parser: instruction expected
> src/libswscale/x86/yuv_2_rgb.asm:333: ... from macro `yuv2rgb_fn' defined
> here
> make: *** [libswscale/x86/yuv_2_rgb.o] Error
> 

Hi Michael,

This error comes from the macro define of BROADCAST only under ARCH_X86_64.
And I have changed it into VBROADCASTSD(defined in x86util.asm) in PATCH V2.
What's more, the md5 test passed in linux32/64 and windows64.

Thank you for review.
Ting Fu

> 
> [...]
> --
> Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
> 
> I do not agree with what you have to say, but I'll defend to the death your 
> right
> to say it. -- Voltaire
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH 1/2] libswscale/x86/yuv2rgb: Change inline assembly into nasm code

2019-12-01 Thread Fu, Ting


> -Original Message-
> From: ffmpeg-devel  On Behalf Of
> Michael Niedermayer
> Sent: Friday, November 29, 2019 05:33 AM
> To: FFmpeg development discussions and patches 
> Subject: Re: [FFmpeg-devel] [PATCH 1/2] libswscale/x86/yuv2rgb: Change inline
> assembly into nasm code
> 
> On Thu, Nov 28, 2019 at 02:07:07PM +0800, Ting Fu wrote:
> > Signed-off-by: Ting Fu 
> > ---
> >  libswscale/x86/Makefile   |   1 +
> >  libswscale/x86/swscale.c  |  16 +-
> >  libswscale/x86/yuv2rgb.c  |  81 ++
> >  libswscale/x86/yuv2rgb_template.c | 441 ++
> >  libswscale/x86/yuv_2_rgb.asm  | 270 ++
> >  5 files changed, 394 insertions(+), 415 deletions(-)  create mode
> > 100644 libswscale/x86/yuv_2_rgb.asm
> 
> This changes the output, i presume that is unintentional
> 
> ./ffmpeg -cpuflags 0 -i matrixbench_mpeg2.mpg -t 1 -vf
> format=yuv420p,format=rgb565le -an -f framecrc -
> 
> 0,  0,  0,1,   829440, 0x1bd78b86
> 0,  1,  1,1,   829440, 0x85910b33
> ...
> vs.
> 0,  0,  0,1,   829440, 0x31f4a2bd
> 0,  1,  1,1,   829440, 0xf0c66218
> ...
> 
> 

Hi Michael,

This unexpected change is because of the missing verify of current SIMD support.
So, when cpuflag=0, ffmpeg used mmx code to compute as default.
I added if (EXTERNAL_XXX(cpu_flags)) to verify the SIMD in 
libswscale/x86/yuv2rgb.c.

Thank you again
Ting Fu

> 
> [...]
> --
> Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
> 
> Republics decline into democracies and democracies degenerate into
> despotisms. -- Aristotle
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH] avfilter/vf_convolution: add 16-column operation for filter_column() to prepare for x86 SIMD.

2019-12-01 Thread 徐鋆
Hi, Steven

- 原始邮件 -
发件人: "Steven Liu" 
收件人: "FFmpeg development discussions and patches" 
抄送: "Steven Liu" 
发送时间: 星期一, 2019年 12 月 02日 上午 10:44:48
主题: Re: [FFmpeg-devel] [PATCH] avfilter/vf_convolution: add 16-column operation 
for filter_column() to prepare for x86 SIMD.

> 在 2019年12月2日,10:42,徐鋆  写道:
> 
> I'm sorry not to reply in time.
> 
> The performance of this C code is about 10% better than the existing C code.
> 
> It will have a bigger improvement after X86 SIMD optimizations.

1. How to test?
1. 怎么测试的?
1. どうやってテストしたの?

I tested using this command:

./ffmpeg_g -s 1280*720 -pix_fmt yuv420p -i test.yuv -vf convolution="1 2 3 4 5 
6 7 8 9:1 2 3 4 5 6 7 8 9:1 2 3 4 5 6 7 8 9:1 2 3 4 5 6 7 8 
9:1/45:1/45:1/45:1/45:1:2:3:4:column:column:column:column" -an -vframes 2000 -f 
null /dev/null 

The FPS increases from 329 to 365 on my local machine.

2. Don’t TOP-Posting: https://en.wikipedia.org/wiki/Top-posting
2. 回邮件要在你回的那一条的下面回复,别再最上面回复,人家看不懂你是针对的哪一条
2. 返信メールは、あなたが返信した項目の下にある。一番上に返信しないと、あなたが何を狙っているのか分からない

Thank you for reminding me. I'm new here. Forgive me for not knowing the rules:)

> 
> Xu Jun
> 
> - 原始邮件 -
> 发件人: "Carl Eugen Hoyos" 
> 收件人: "FFmpeg development discussions and patches" 
> 发送时间: 星期四, 2019年 11 月 28日 上午 12:19:44
> 主题: Re: [FFmpeg-devel] [PATCH] avfilter/vf_convolution: add 16-column 
> operation for filter_column() to prepare for x86 SIMD.
> 
> Am Mi., 27. Nov. 2019 um 15:56 Uhr schrieb :
> 
>> From: Xu Jun 
>> 
>> In order to add x86 SIMD for filter_column(), I write a C function which 
>> processes 16 columns at a time.
> 
> How does this perform compared to the existing C code?
> 
> Carl Eugen
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> 
> To unsubscribe, visit link above, or email
> ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
> -- 
> 敬颂钧安, 
> 徐鋆 
> 电子信息与电气工程学院 
> 上海交通大学 
> 邮箱:xuju...@sjtu.edu.cn 
> 地址:上海市闵行区东川路800号 
> 
> Yours sincerely, 
> Xylem(Jun Xu) 
> School of Electronic, Information and Electrical Engineering 
> Shanghai Jiao Tong University 
> Email: xuju...@sjtu.edu.cn 
> No. 800, Dongchuan Road, Minhang District, Shanghai 200240, China 
> 
> 宜しくお愿いたします 
> 徐鋆 
> 電子情報と電気工程学院 
> 上海交通大学 
> メールアドレス :xuju...@sjtu.edu.cn 
> 住所:上海市閔行区ドンチュワンルー800号
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> 
> To unsubscribe, visit link above, or email
> ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Thanks
Steven





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

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
-- 
敬颂钧安, 
徐鋆 
电子信息与电气工程学院 
上海交通大学 
邮箱:xuju...@sjtu.edu.cn 
地址:上海市闵行区东川路800号 

Yours sincerely, 
Xu Jun
School of Electronic, Information and Electrical Engineering 
Shanghai Jiao Tong University 
Email: xuju...@sjtu.edu.cn 
No. 800, Dongchuan Road, Minhang District, Shanghai 200240, China 

宜しくお愿いたします 
徐鋆 
電子情報と電気工程学院 
上海交通大学 
メールアドレス :xuju...@sjtu.edu.cn 
住所:上海市閔行区ドンチュワンルー800号
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

[FFmpeg-devel] Fwd: [PATCH] avfilter/vf_convolution: add 16-column operation for filter_column() to prepare for x86 SIMD.

2019-12-01 Thread chen


> 下面是被转发的邮件:
> 
> 发件人: chen 
> 主题: [FFmpeg-devel] [PATCH] avfilter/vf_convolution: add 16-column operation 
> for filter_column() to prepare for x86 SIMD.
> 日期: 2019年12月02日 GMT+8 11:36:50
> 收件人: xuju...@sjtu.edu.cn
> 
> In this case, modify in filter_slice(…) is unnecessary because your generic 
> version of filter_column16(…).
> I suggest make a 16 aligned path in filter_column16(…) directly.
> For example
> 
> for(lengh / 16)
> {
> …
> }
> 
> for(length % 16)
> {
> …
> }
> 

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

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH v2] avfilter: Add tonemap vaapi filter for H2S

2019-12-01 Thread Sun, Xinpeng

> -Original Message-
> From: ffmpeg-devel  On Behalf Of Sun,
> Xinpeng
> Sent: Friday, November 29, 2019 3:50 PM
> To: FFmpeg development discussions and patches 
> Subject: Re: [FFmpeg-devel] [PATCH v2] avfilter: Add tonemap vaapi filter for
> H2S
> 
> 
> > -Original Message-
> > From: ffmpeg-devel  On Behalf Of
> > Song, Ruiling
> > Sent: Thursday, November 28, 2019 5:39 PM
> > To: FFmpeg development discussions and patches
> > 
> > Subject: Re: [FFmpeg-devel] [PATCH v2] avfilter: Add tonemap vaapi
> > filter for H2S
> >
> > > -Original Message-
> > > From: ffmpeg-devel  On Behalf Of
> > > Carl Eugen Hoyos
> > > Sent: Thursday, November 28, 2019 5:16 PM
> > > To: FFmpeg development discussions and patches  > > de...@ffmpeg.org>
> > > Subject: Re: [FFmpeg-devel] [PATCH v2] avfilter: Add tonemap vaapi
> > > filter for H2S
> > >
> > > Am Do., 28. Nov. 2019 um 07:56 Uhr schrieb Song, Ruiling
> > > :
> > >
> > > > > > Am 28.11.2019 um 06:37 schrieb Sun, Xinpeng
> > > :
> > > > > >
> > > > > >>>
> > > > > >>> +if (input_frame->color_trc != AVCOL_TRC_SMPTE2084) {
> > > > > >>> +av_log(avctx, AV_LOG_ERROR, "Only support HDR10 as
> > > > > >>> + input
> > > for
> > > > > vaapi tone-mapping\n");
> > > > > >>> +return AVERROR(EINVAL);
> > > > > >>
> > > > > >> Shouldn't this also accept unknown trc?
> > > > > >> (With a warning)
> > > > > >
> > > > > > Sorry if I misunderstand "unknown trc". Did you mean the trc
> > > undefined by
> > > > > ffmpeg or the trc unsupported by the driver?
> > > > >
> > > > > My question is:
> > > > > If input_frame->color_trc is AVCOL_TRC_UNSPECIFIED, will the above
> fail?
> > > > > But shouldn’t the user be able to use the filter in this case?
> > > >
> > > > I am not sure if assuming the input is using SMPTE2084 sounds more
> > > acceptable
> > > > in case of unspecified? If yes, I think we can change as you suggested.
> > >
> > > (Me neither.)
> > > A warning could be shown instead of failing.
> 
> Prompt the user that the input could only be HDR10 with a warning instead of
> failing, which sounds good and makes sense.
> I will fix it in the next version.
> 
> Thanks,
> Xinpeng
> 
> > Adding a warning sound good idea. But in order to proceed the
> > tone-mapping, a default input transfer-function need to be chosen,
> > which I think we can use
> > SMPTE2084 here.
> 
> Without any other comments on it, I will use SMPTE2084 as default input
> transfer-function if input_frame->color_trc is AVCOL_TRC_UNSPECIFIED.
> 
> >
> > Ruiling
> > >
> > > Carl Eugen
> > > ___
> > > ffmpeg-devel mailing list
> > > ffmpeg-devel@ffmpeg.org
> > > https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> > >
> > > To unsubscribe, visit link above, or email
> > > ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
> > ___
> > ffmpeg-devel mailing list
> > ffmpeg-devel@ffmpeg.org
> > https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> >
> > To unsubscribe, visit link above, or email
> > ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> 
> To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org
> with subject "unsubscribe".

Kindly ping.

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

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH] avfilter/vf_convolution: add 16-column operation for filter_column() to prepare for x86 SIMD.

2019-12-01 Thread Song, Ruiling
> -Original Message-
> From: ffmpeg-devel  On Behalf Of
> xuju...@sjtu.edu.cn
> Sent: Wednesday, November 27, 2019 10:56 PM
> To: ffmpeg-devel@ffmpeg.org
> Cc: xuju...@sjtu.edu.cn
> Subject: [FFmpeg-devel] [PATCH] avfilter/vf_convolution: add 16-column
> operation for filter_column() to prepare for x86 SIMD.
> 
> From: Xu Jun 
> 
> In order to add x86 SIMD for filter_column(), I write a C function which
> processes 16 columns at a time.
> 
> Signed-off-by: Xu Jun 
> ---
>  libavfilter/vf_convolution.c  | 56 +++
>  libavfilter/x86/vf_convolution_init.c | 23 +++
>  2 files changed, 79 insertions(+)
> 
> diff --git a/libavfilter/vf_convolution.c b/libavfilter/vf_convolution.c
> index d022f1a04a..5291415d48 100644
> --- a/libavfilter/vf_convolution.c
> +++ b/libavfilter/vf_convolution.c
> @@ -520,6 +520,61 @@ static int filter_slice(AVFilterContext *ctx, void *arg,
> int jobnr, int nb_jobs)
>  continue;
>  }
> 
> +if (mode == MATRIX_COLUMN && s->filter[plane] != filter_column){
> +for (y = slice_start; y < slice_end - 16; y+=16) {
Please take care of the coding style there should be white-space between 
variables and operators.
And also I think this piece of change make it harder to maintain, let's try to 
avoid code duplicate as much as we can.
> +const int xoff = (y - slice_start) * bpc;
> +const int yoff = radius * stride;
> +for (x = 0; x < radius; x++) {
> +const int xoff = (y - slice_start) * bpc;
> +const int yoff = x * stride;
> +
> +s->setup[plane](radius, c, src, stride, x, width, y, 
> height, bpc);
> +s->filter[plane](dst + yoff + xoff, 1, rdiv,
> +bias, matrix, c, 16, radius,
> +dstride, stride);
> +}
> +s->setup[plane](radius, c, src, stride, radius, width, y, 
> height, bpc);
> +s->filter[plane](dst + yoff + xoff, sizew - 2 * radius,
> +rdiv, bias, matrix, c, 16, radius,
> +dstride, stride);
> +for (x = sizew - radius; x < sizew; x++) {
> +const int xoff = (y - slice_start) * bpc;
> +const int yoff = x * stride;
> +
> +s->setup[plane](radius, c, src, stride, x, width, y, 
> height, bpc);
> +s->filter[plane](dst + yoff + xoff, 1, rdiv,
> +bias, matrix, c, 16, radius,
> +dstride, stride);
> +}
> +}
> +if (y < slice_end){
> +const int xoff = (y - slice_start) * bpc;
> +const int yoff = radius * stride;
> +for (x = 0; x < radius; x++) {
> +const int xoff = (y - slice_start) * bpc;
> +const int yoff = x * stride;
> +
> +s->setup[plane](radius, c, src, stride, x, width, y, 
> height, bpc);
> +s->filter[plane](dst + yoff + xoff, 1, rdiv,
> +bias, matrix, c, slice_end - y, radius,
> +dstride, stride);
> +}
> +s->setup[plane](radius, c, src, stride, radius, width, y, 
> height, bpc);
> +s->filter[plane](dst + yoff + xoff, sizew - 2 * radius,
> +rdiv, bias, matrix, c, slice_end - y, radius,
> +dstride, stride);
> +for (x = sizew - radius; x < sizew; x++) {
> +const int xoff = (y - slice_start) * bpc;
> +const int yoff = x * stride;
> +
> +s->setup[plane](radius, c, src, stride, x, width, y, 
> height, bpc);
> +s->filter[plane](dst + yoff + xoff, 1, rdiv,
> +bias, matrix, c, slice_end - y, radius,
> +dstride, stride);
> +}
> +}
> +}
> +else {
>  for (y = slice_start; y < slice_end; y++) {
>  const int xoff = mode == MATRIX_COLUMN ? (y - slice_start) * bpc 
> :
> radius * bpc;
>  const int yoff = mode == MATRIX_COLUMN ? radius * stride : 0;
> @@ -550,6 +605,7 @@ static int filter_slice(AVFilterContext *ctx, void *arg,
> int jobnr, int nb_jobs)
>  dst += dstride;
>  }
>  }
> +}
> 
>  return 0;
>  }
> diff --git a/libavfilter/x86/vf_convolution_init.c
> b/libavfilter/x86/vf_convolution_init.c
> index d1e8c90ceb..6b1c2f0e9f 100644
> --- a/libavfilter/x86/vf_convolution_init.c
> +++ b/libavfilter/x86/vf_convolution_init.c
> @@ -34,6 +34,27 @@ void ff_filter_row_sse4(uint8_t *dst, int width,
>  const uint8_t 

[FFmpeg-devel] [PATCH v3 2/2] avformat/utils: simplify the ff_mkdir_p with SEPARATOR

2019-12-01 Thread lance . lmwang
From: Limin Wang 

Please tested by below command(Mac or Linux):
./ffmpeg -i ~/Movies/input.mp4  -use_localtime 1 -use_localtime_mkdir 1 
-hls_segment_filename 'hls/t\e\s\t/%Y%m%d/file-%Y%m%d-%s.ts' ./out.m3u8
Master:
$ ls hls/
t   t\e t\e\s   t\e\s\t

After applied the patch:
$ ls hls/
t\e\s\t


Signed-off-by: Limin Wang 
---
 libavformat/utils.c | 18 +++---
 1 file changed, 11 insertions(+), 7 deletions(-)

diff --git a/libavformat/utils.c b/libavformat/utils.c
index 03a3705200..0a94515e0e 100644
--- a/libavformat/utils.c
+++ b/libavformat/utils.c
@@ -4843,32 +4843,36 @@ void av_url_split(char *proto, int proto_size,
 }
 }
 
+#if HAVE_DOS_PATHS
+#define SEPARATOR '\\'
+#else
+#define SEPARATOR '/'
+#endif
+
 int ff_mkdir_p(const char *path)
 {
 int ret = 0;
 char *temp = av_strdup(path);
 char *pos = temp;
-char tmp_ch = '\0';
 
 if (!path || !temp) {
 return -1;
 }
 
-if (*temp == '/' || *temp == '\\')
+if (*temp == SEPARATOR)
 pos++;
-else if (*temp == '.' && (*(temp+1) == '/' || *(temp+1) == '\\'))
+else if (*temp == '.' && *(temp+1) == SEPARATOR)
 pos += 2;
 
 for ( ; *pos != '\0'; ++pos) {
-if (*pos == '/' || *pos == '\\') {
-tmp_ch = *pos;
+if (*pos == SEPARATOR) {
 *pos = '\0';
 ret = mkdir(temp, 0755);
-*pos = tmp_ch;
+*pos = SEPARATOR;
 }
 }
 
-if ((*(pos - 1) != '/') || (*(pos - 1) != '\\')) {
+if (*(pos - 1) != SEPARATOR) {
 ret = mkdir(temp, 0755);
 }
 
-- 
2.21.0

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

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

[FFmpeg-devel] [PATCH v3 1/2] avformat/utils: simplify the code and remove av_strncasecmp

2019-12-01 Thread lance . lmwang
From: Limin Wang 

Signed-off-by: Limin Wang 
---
 libavformat/utils.c | 5 ++---
 1 file changed, 2 insertions(+), 3 deletions(-)

diff --git a/libavformat/utils.c b/libavformat/utils.c
index 8196442dd1..03a3705200 100644
--- a/libavformat/utils.c
+++ b/libavformat/utils.c
@@ -4854,11 +4854,10 @@ int ff_mkdir_p(const char *path)
 return -1;
 }
 
-if (!av_strncasecmp(temp, "/", 1) || !av_strncasecmp(temp, "\\", 1)) {
+if (*temp == '/' || *temp == '\\')
 pos++;
-} else if (!av_strncasecmp(temp, "./", 2) || !av_strncasecmp(temp, ".\\", 
2)) {
+else if (*temp == '.' && (*(temp+1) == '/' || *(temp+1) == '\\'))
 pos += 2;
-}
 
 for ( ; *pos != '\0'; ++pos) {
 if (*pos == '/' || *pos == '\\') {
-- 
2.21.0

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

To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".

Re: [FFmpeg-devel] [PATCH] lavc/h2645_parse: Don't automatically remove nuh_layer_id > 0 packets

2019-12-01 Thread Andreas Rheinhardt
On Mon, Dec 2, 2019 at 3:49 AM Andriy Gelman 
wrote:

> From: Andriy Gelman 
>
> HEVC standard supports multi-layer streams (ITU-T H.265 02/2018 Annex
> F). Each NAL unit belongs to a particular layer defined by nuh_layer_id
> in the header.
>
> Currently, all NAL units that do not belong to a base layer are
> automatically removed in ff_h2645_packet_split(). Some data may
> therefore be lost when future filters/decoders are designed to support
> multi-layer streams.
>
> A better approach is to forward nuh_layer_id > 0 packets and let blocks
> down the chain decide how to process them. The condition to remove
> packets has been moved to hevcdec and cbs bsf where such packets are
> currently not supported.
> ---
>  libavcodec/cbs_h2645.c   | 3 +++
>  libavcodec/h2645_parse.c | 7 +++
>  libavcodec/h2645_parse.h | 5 +
>  libavcodec/hevc_parse.c  | 2 ++
>  libavcodec/hevc_parser.c | 2 ++
>  libavcodec/hevcdec.c | 2 +-
>  6 files changed, 16 insertions(+), 5 deletions(-)
>
> diff --git a/libavcodec/cbs_h2645.c b/libavcodec/cbs_h2645.c
> index 88fa0029cd6..9f89f1c5a55 100644
> --- a/libavcodec/cbs_h2645.c
> +++ b/libavcodec/cbs_h2645.c
> @@ -562,6 +562,9 @@ static int
> cbs_h2645_fragment_add_nals(CodedBitstreamContext *ctx,
>
>  for (i = 0; i < packet->nb_nals; i++) {
>  const H2645NAL *nal = >nals[i];
> +if (nal->nuh_layer_id > 0)
> +continue;
> +
>

Mixed declaration and code. But, as James has already said: cbs should not
drop higher layers by default.


>  AVBufferRef *ref;
>  size_t size = nal->size;
>
> diff --git a/libavcodec/h2645_parse.c b/libavcodec/h2645_parse.c
> index 4808f79a67f..0f3343004f9 100644
> --- a/libavcodec/h2645_parse.c
> +++ b/libavcodec/h2645_parse.c
> @@ -292,23 +292,22 @@ static int get_bit_length(H2645NAL *nal, int
> skip_trailing_zeros)
>  static int hevc_parse_nal_header(H2645NAL *nal, void *logctx)
>  {
>  GetBitContext *gb = >gb;
> -int nuh_layer_id;
>
>  if (get_bits1(gb) != 0)
>  return AVERROR_INVALIDDATA;
>
>  nal->type = get_bits(gb, 6);
>
> -nuh_layer_id   = get_bits(gb, 6);
> +nal->nuh_layer_id = get_bits(gb, 6);
>  nal->temporal_id = get_bits(gb, 3) - 1;
>  if (nal->temporal_id < 0)
>  return AVERROR_INVALIDDATA;
>
>  av_log(logctx, AV_LOG_DEBUG,
> "nal_unit_type: %d(%s), nuh_layer_id: %d, temporal_id: %d\n",
> -   nal->type, hevc_nal_unit_name(nal->type), nuh_layer_id,
> nal->temporal_id);
> +   nal->type, hevc_nal_unit_name(nal->type), nal->nuh_layer_id,
> nal->temporal_id);
>
> -return nuh_layer_id == 0;
> +return 1;
>  }
>
>  static int h264_parse_nal_header(H2645NAL *nal, void *logctx)
> diff --git a/libavcodec/h2645_parse.h b/libavcodec/h2645_parse.h
> index 2acf882d3da..3e47f86c53b 100644
> --- a/libavcodec/h2645_parse.h
> +++ b/libavcodec/h2645_parse.h
> @@ -56,6 +56,11 @@ typedef struct H2645NAL {
>   */
>  int temporal_id;
>
> +/*
> + * HEVC only, identifier of layer to which nal unit belongs
> + */
> +int nuh_layer_id;
> +
>

You might want to add a commit on top of that to reorder the H2645NAL
entries so that the size doesn't increase.


>  int skipped_bytes;
>  int skipped_bytes_pos_size;
>  int *skipped_bytes_pos;
> diff --git a/libavcodec/hevc_parse.c b/libavcodec/hevc_parse.c
> index dddb293df64..29dfd479f38 100644
> --- a/libavcodec/hevc_parse.c
> +++ b/libavcodec/hevc_parse.c
> @@ -37,6 +37,8 @@ static int hevc_decode_nal_units(const uint8_t *buf, int
> buf_size, HEVCParamSets
>
>  for (i = 0; i < pkt.nb_nals; i++) {
>  H2645NAL *nal = [i];
> +if (nal->nuh_layer_id > 0)
> +continue;
>
>  /* ignore everything except parameter sets and VCL NALUs */
>  switch (nal->type) {
> diff --git a/libavcodec/hevc_parser.c b/libavcodec/hevc_parser.c
> index b444b999550..a47104aea9c 100644
> --- a/libavcodec/hevc_parser.c
> +++ b/libavcodec/hevc_parser.c
> @@ -200,6 +200,8 @@ static int parse_nal_units(AVCodecParserContext *s,
> const uint8_t *buf,
>
>  for (i = 0; i < ctx->pkt.nb_nals; i++) {
>  H2645NAL *nal = >pkt.nals[i];
> +if (nal->nuh_layer_id > 0)
> +continue;
>

Mixed declaration and code.


>  GetBitContext *gb = >gb;
>
>  switch (nal->type) {
> diff --git a/libavcodec/hevcdec.c b/libavcodec/hevcdec.c
> index 8f1c162acee..bcd8e67944a 100644
> --- a/libavcodec/hevcdec.c
> +++ b/libavcodec/hevcdec.c
> @@ -3077,7 +3077,7 @@ static int decode_nal_units(HEVCContext *s, const
> uint8_t *buf, int length)
>
>  if (s->avctx->skip_frame >= AVDISCARD_ALL ||
>  (s->avctx->skip_frame >= AVDISCARD_NONREF
> -&& ff_hevc_nal_is_nonref(nal->type)))
> +&& ff_hevc_nal_is_nonref(nal->type)) || nal->nuh_layer_id > 0)
>  continue;
>
>  ret = decode_nal_unit(s, nal);
> --
> 2.24.0
>
> ___
>