[FFmpeg-devel] [PATCH] libavfilter/scale: Populate ow/oh when using 0 as w/h

[Kevin Mark]

The input width and height is known at parse time so there's no
reason ow/oh should not be usable when using 0 as the width or
height expression.

Previously in "scale=0:ow" ow would be set to "0" which works,
conveniently, as "scale=0:0" is perfectly valid input but this breaks
down when you do something like "scale=0:ow/4" which one could
reasonably expect to work as well, but does not as ow is 0 not the
real value.

This change handles the 0 case for w/h immediately so the ow/oh
variables work as expected. Consequently, the rest of the code does
not need to handle 0 input. w/h will always be > 0 or < 0.

The second explicit (int) cast ensures that ow/oh appear as integers
as a user might expect when dealing with pixel dimensions.

Signed-off-by: Kevin Mark 
---
 libavfilter/scale.c | 13 +
 1 file changed, 5 insertions(+), 8 deletions(-)

diff --git a/libavfilter/scale.c b/libavfilter/scale.c
index 03745ddcb8..eaee95fac6 100644
--- a/libavfilter/scale.c
+++ b/libavfilter/scale.c
@@ -158,19 +158,19 @@ int ff_scale_eval_dimensions(void *log_ctx,
 av_expr_parse_and_eval(, (expr = w_expr),
names, var_values,
NULL, NULL, NULL, NULL, NULL, 0, log_ctx);
-eval_w = var_values[VAR_OUT_W] = var_values[VAR_OW] = res;
+eval_w = var_values[VAR_OUT_W] = var_values[VAR_OW] = (int) res == 0 ? 
inlink->w : (int) res;
 
 if ((ret = av_expr_parse_and_eval(, (expr = h_expr),
   names, var_values,
   NULL, NULL, NULL, NULL, NULL, 0, 
log_ctx)) < 0)
 goto fail;
-eval_h = var_values[VAR_OUT_H] = var_values[VAR_OH] = res;
+eval_h = var_values[VAR_OUT_H] = var_values[VAR_OH] = (int) res == 0 ? 
inlink->h : (int) res;
 /* evaluate again the width, as it may depend on the output height */
 if ((ret = av_expr_parse_and_eval(, (expr = w_expr),
   names, var_values,
   NULL, NULL, NULL, NULL, NULL, 0, 
log_ctx)) < 0)
 goto fail;
-eval_w = res;
+eval_w = (int) res == 0 ? inlink->w : (int) res;
 
 w = eval_w;
 h = eval_h;
@@ -186,13 +186,10 @@ int ff_scale_eval_dimensions(void *log_ctx,
 factor_h = -h;
 }
 
-if (w < 0 && h < 0)
-eval_w = eval_h = 0;
-
-if (!(w = eval_w))
+if (w < 0 && h < 0) {
 w = inlink->w;
-if (!(h = eval_h))
 h = inlink->h;
+}
 
 /* Make sure that the result is divisible by the factor we determined
  * earlier. If no factor was set, it is nothing will happen as the default
-- 
2.13.1

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

Re: [FFmpeg-devel] [PATCH] libavfilter/scale: Populate ow/oh when using 0 as w/h

[Kevin Mark]

On Tue, Jun 13, 2017 at 10:04 PM, Michael Niedermayer
 wrote:
> ok, makes sense
> i agree the 2nd cast seems a good idea

Great, thanks Michael. I'll submit an updated patch with the additional cast.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 13/24] vaapi_encode: Use gop_size consistently in RC parameters

[Jun Zhao]

On 2017/6/13 6:40, Mark Thompson wrote:
> The non-H.26[45] codecs already use this form.  Since we don't
> currently generate I frames for codecs which support them separately
> to IDR, the p_per_i variable is set to infinity by default so that it
> doesn't interfere with any other calculation.  (All the code for I
> frames still exists, and it works for H.264 if set manually.)
> 
> (cherry picked from commit 6af014f4028238b4c50f1731b3369a41d65fa9c4)
> ---
>  libavcodec/vaapi_encode.c  | 3 +--
>  libavcodec/vaapi_encode_h264.c | 4 ++--
>  libavcodec/vaapi_encode_h265.c | 4 ++--
>  3 files changed, 5 insertions(+), 6 deletions(-)
> 
> diff --git a/libavcodec/vaapi_encode.c b/libavcodec/vaapi_encode.c
> index 7aaf263d25..2de5f76cab 100644
> --- a/libavcodec/vaapi_encode.c
> +++ b/libavcodec/vaapi_encode.c
> @@ -1435,8 +1435,7 @@ av_cold int ff_vaapi_encode_init(AVCodecContext *avctx)
>  ctx->output_order = - ctx->output_delay - 1;
>  
>  // Currently we never generate I frames, only IDR.
> -ctx->p_per_i = ((avctx->gop_size - 1 + avctx->max_b_frames) /
> -(avctx->max_b_frames + 1));
> +ctx->p_per_i = INT_MAX;

Why don't remove p_per_i if don't use this field?

>  ctx->b_per_p = avctx->max_b_frames;
>  
>  if (ctx->codec->sequence_params_size > 0) {
> diff --git a/libavcodec/vaapi_encode_h264.c b/libavcodec/vaapi_encode_h264.c
> index 92e29554ed..f9fcd805a4 100644
> --- a/libavcodec/vaapi_encode_h264.c
> +++ b/libavcodec/vaapi_encode_h264.c
> @@ -905,8 +905,8 @@ static int 
> vaapi_encode_h264_init_sequence_params(AVCodecContext *avctx)
>  mseq->nal_hrd_parameters_present_flag = 0;
>  }
>  
> -vseq->intra_period = ctx->p_per_i * (ctx->b_per_p + 1);
> -vseq->intra_idr_period = vseq->intra_period;
> +vseq->intra_period = avctx->gop_size;
> +vseq->intra_idr_period = avctx->gop_size;
>  vseq->ip_period= ctx->b_per_p + 1;
>  }
>  
> diff --git a/libavcodec/vaapi_encode_h265.c b/libavcodec/vaapi_encode_h265.c
> index 6e008b7b9c..1d648a6d87 100644
> --- a/libavcodec/vaapi_encode_h265.c
> +++ b/libavcodec/vaapi_encode_h265.c
> @@ -832,8 +832,8 @@ static int 
> vaapi_encode_h265_init_sequence_params(AVCodecContext *avctx)
>  vseq->vui_time_scale= avctx->time_base.den;
>  }
>  
> -vseq->intra_period = ctx->p_per_i * (ctx->b_per_p + 1);
> -vseq->intra_idr_period = vseq->intra_period;
> +vseq->intra_period = avctx->gop_size;
> +vseq->intra_idr_period = avctx->gop_size;
>  vseq->ip_period= ctx->b_per_p + 1;
>  }
>  
> 
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH V5 4/4] lavc/tests/golomb: Add unit test for set_ue_golomb_long.

[Jun Zhao]

From cde2c978d2f0d7ee799619d7cd3a54c771bab7e2 Mon Sep 17 00:00:00 2001
From: Jun Zhao 
Date: Wed, 14 Jun 2017 10:42:36 +0800
Subject: [PATCH V5 4/4] lavc/tests/golomb: Add unit test for
 set_ue_golomb_long.

Add unit test for set_ue_golomb_long.

Signed-off-by: Jun Zhao 
---
 libavcodec/tests/golomb.c | 19 +++
 1 file changed, 19 insertions(+)

diff --git a/libavcodec/tests/golomb.c b/libavcodec/tests/golomb.c
index 965367b7be..85b8a9390b 100644
--- a/libavcodec/tests/golomb.c
+++ b/libavcodec/tests/golomb.c
@@ -21,6 +21,7 @@
 #include 
 #include 
 
+#include "libavutil/internal.h"
 #include "libavutil/mem.h"
 
 #include "libavcodec/get_bits.h"
@@ -76,6 +77,24 @@ int main(void)
 }
 }
 
+#define EXTEND_L(i) ((i) << 4 | (i) & 15)
+init_put_bits(, temp, SIZE);
+for (i = 0; i < COUNT; i++)
+set_ue_golomb_long(, EXTEND_L(i));
+flush_put_bits();
+
+init_get_bits(, temp, 8 * SIZE);
+for (i = 0; i < COUNT; i++) {
+int j, s = show_bits_long(, 32);
+
+j = get_ue_golomb_long();
+if (j != EXTEND_L(i)) {
+fprintf(stderr, "get_ue_golomb_long: expected %d, got %d. "
+"bits: %8x\n", EXTEND_L(i), j, s);
+ret = 1;
+}
+}
+
 init_put_bits(, temp, SIZE);
 for (i = 0; i < COUNT; i++)
 set_se_golomb(, i - COUNT / 2);
-- 
2.11.0

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

[FFmpeg-devel] [PATCH V5 2/4] lavc/put_bits: Add put_bits64() to support up to 64 bits.

[Jun Zhao]

From 703be162119f78e1815d1f3b23afb24978ff36d7 Mon Sep 17 00:00:00 2001
From: Jun Zhao 
Date: Wed, 14 Jun 2017 10:22:10 +0800
Subject: [PATCH V5 2/4] lavc/put_bits: Add put_bits64() to support up to 64
 bits.

put_bits64() can write up to 64 bits into a bitstream.

Reviewed-by: Mark Thompson 
Reviewed-by: Michael Niedermayer 
Signed-off-by: Jun Zhao 
---
 libavcodec/put_bits.h | 35 +++
 1 file changed, 35 insertions(+)

diff --git a/libavcodec/put_bits.h b/libavcodec/put_bits.h
index 9bd45cd8ba..b85e88f28c 100644
--- a/libavcodec/put_bits.h
+++ b/libavcodec/put_bits.h
@@ -243,6 +243,41 @@ static void av_unused put_bits32(PutBitContext *s, 
uint32_t value)
 }
 
 /**
+ * Write up to 64 bits into a bitstream.
+ */
+static inline void put_bits64(PutBitContext *s, int n, uint64_t value)
+{
+av_assert2((n == 64) || (n < 64 && value < (UINT64_C(1) << n)));
+
+if (n < 32)
+put_bits(s, n, value);
+else if (n == 32)
+put_bits32(s, value);
+else if (n < 64) {
+uint32_t lo = value & 0x;
+uint32_t hi = value >> 32;
+#ifdef BITSTREAM_WRITER_LE
+put_bits32(s, lo);
+put_bits(s, n - 32, hi);
+#else
+put_bits(s, n - 32, hi);
+put_bits32(s, lo);
+#endif
+} else {
+uint32_t lo = value & 0x;
+uint32_t hi = value >> 32;
+#ifdef BITSTREAM_WRITER_LE
+put_bits32(s, lo);
+put_bits32(s, hi);
+#else
+put_bits32(s, hi);
+put_bits32(s, lo);
+#endif
+
+}
+}
+
+/**
  * Return the pointer to the byte where the bitstream writer will put
  * the next bit.
  */
-- 
2.11.0

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

[FFmpeg-devel] [PATCH V5 3/4] lavc/golobm: Add set_ue_golomb_long to support up to 2^32 -2.

[Jun Zhao]

From e4ed2cf5a0282ca8bc24bf3d6535b8b445e23341 Mon Sep 17 00:00:00 2001
From: Jun Zhao 
Date: Wed, 14 Jun 2017 10:35:20 +0800
Subject: [PATCH V5 3/4] lavc/golobm: Add set_ue_golomb_long to support up to
 2^32 -2.

add set_ue_golomb_long to support up to 2^32-2.

Reviewed-by: Mark Thompson 
Reviewed-by: Michael Niedermayer 
Signed-off-by: Jun Zhao 
---
 libavcodec/golomb.h | 15 +++
 1 file changed, 15 insertions(+)

diff --git a/libavcodec/golomb.h b/libavcodec/golomb.h
index 1e834f9327..efb1eff8aa 100644
--- a/libavcodec/golomb.h
+++ b/libavcodec/golomb.h
@@ -474,6 +474,21 @@ static inline void set_ue_golomb(PutBitContext *pb, int i)
 }
 
 /**
+ * write unsigned exp golomb code. 2^32-2 at most.
+ */
+static inline void set_ue_golomb_long(PutBitContext *pb, uint32_t i)
+{
+av_assert2(i <= (UINT32_MAX - 1));
+
+if (i < 256)
+put_bits(pb, ff_ue_golomb_len[i], i + 1);
+else {
+int e = av_log2(i + 1);
+put_bits64(pb, 2 * e + 1, i + 1);
+}
+}
+
+/**
  * write truncated unsigned exp golomb code.
  */
 static inline void set_te_golomb(PutBitContext *pb, int i, int range)
-- 
2.11.0

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

[FFmpeg-devel] [PATCH V5 1/4] lavc/golomb: add value range comment for set_ue_golomb().

[Jun Zhao]

V5: Split the patch.
V4: Fix rang check error in assert base on Mark's review
V3: Clean the code logic base on Michael's review.
V2: Add set_ue_golomb_long() to support 32bits UE golomb and update the unit 
test.
From 4600950115a215d64cf049233195cfd035ac11cb Mon Sep 17 00:00:00 2001
From: Jun Zhao 
Date: Wed, 14 Jun 2017 10:08:58 +0800
Subject: [PATCH V5 1/4] lavc/golomb: add value range comment for
 set_ue_golomb().

set_ue_golomb just support 2^16 - 2 at most, becase this function call
put_bits, and put_bits just support write up to 31 bits, when write 32
bit in put_bits, it's will overwrite the bit buffer, and the default
assert level is 0, the av_assert2(n <= 31 && value < (1U << n)) in
put_bits can not be trigger runtime.

Signed-off-by: Jun Zhao 
---
 libavcodec/golomb.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/libavcodec/golomb.h b/libavcodec/golomb.h
index 4f5514795a..1e834f9327 100644
--- a/libavcodec/golomb.h
+++ b/libavcodec/golomb.h
@@ -458,7 +458,7 @@ static inline int get_te(GetBitContext *s, int r, char 
*file, const char *func,
 #endif /* TRACE */
 
 /**
- * write unsigned exp golomb code.
+ * write unsigned exp golomb code. 2^16 - 2 at most
  */
 static inline void set_ue_golomb(PutBitContext *pb, int i)
 {
-- 
2.11.0

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

Re: [FFmpeg-devel] [PATCH] libavfilter/scale: Populate ow/oh when using 0 as w/h

[Michael Niedermayer]

On Tue, Jun 13, 2017 at 12:10:07AM -0400, Kevin Mark wrote:
> On Mon, Jun 12, 2017 at 9:42 PM, Michael Niedermayer
>  wrote:
> > why is there a cast at all ?
> 
> The cast is there because if you run this:
> 
> ffmpeg -frames:v 5 -filter_complex
> "sws_flags=+accurate_rnd+bitexact;testsrc=size=320x240
> [main];testsrc=size=640x360 [ref];[main][ref]
> scale2ref=0:print(ow/641) [main][ref];[ref] nullsink" -map "[main]"
> -flags +bitexact -fflags +bitexact -f md5 -
> 
> This works just fine without a cast for ow. 0 == 0 is true so we set
> it to 640. But for oh, the print() shows that ow/641 is 0.998440. When
> it is truncated from a double to an integer (eval_h = res) it becomes
> 0. But in our comparison, 0.998440 == 0 is false so in this case
> eval_h will be truncated to 0 which is exactly the behavior we're
> trying to correct. Adding that cast resolves the issue. 0.998440 == 0
> is false but (int) 0.998440 == 0 is true.
> 
> For the extra cast I was talking about consider this:
> 
> ffmpeg -frames:v 5 -filter_complex
> "sws_flags=+accurate_rnd+bitexact;testsrc=size=320x240
> [main];testsrc=size=640x360 [ref];[main][ref]
> scale2ref=500/6:print(print(ow)*5) [main][ref];[ref] nullsink" -map
> "[main]" -flags +bitexact -fflags +bitexact -f md5 -
> 
> That will print() 83.33 and then 416.67. A user might
> (reasonably, in my opinion) expect that the ow value (or oh) is always
> an integer. With the extra cast you'll see 83.00 and 415.00
> printed. 83.33 truncates to 83 so no (noticeable) change for ow
> but 416.67 does not truncate to 415 so this is an example of a
> place where the lack of truncation for ow/oh does change the outcome.

ok, makes sense
i agree the 2nd cast seems a good idea


> 
> I hope this clears it up. Perhaps that code should just be entirely
> refactored to be a little more clear?
> 
> Thanks,
> Kevin
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

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


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

Re: [FFmpeg-devel] [PATCH] lavc/vaapi_encode_h26[45]: respect "slices" option in h26[45] vaapi encoder.

[Jun Zhao]

On 2017/6/14 7:41, Mark Thompson wrote:
> On 07/06/17 01:53, Jun Zhao wrote:
>> From 5c88956e36e7318cf1d1b7c41a9d4108fcf9d0a5 Mon Sep 17 00:00:00 2001
>> From: Jun Zhao 
>> Date: Fri, 12 May 2017 08:30:43 +0800
>> Subject: [PATCH] lavc/vaapi_encode_h26[45]: respect "slices" in h26[45] vaapi
>>  encoder.
>>
>> Enable multi-slice support in AVC/HEVC vaapi encoder.
>>
>> Signed-off-by: Wang, Yi A 
>> Signed-off-by: Jun Zhao 
>> ---
> 
> I think this should be three patches:
> 
>>  libavcodec/vaapi_encode.c  | 36 
>>  libavcodec/vaapi_encode.h  |  9 +++--
> 
> (1) Change the slice/parameter buffers to be allocated dynamically.
> 
>>  libavcodec/vaapi_encode_h264.c | 24 ++--
> 
> (2) Respect slices option in H.264 encoder.
> 
>>  libavcodec/vaapi_encode_h265.c | 28 ++--
> 
> (3) Respect slices option in H.265 encoder.
> 
> 
> I'm not entirely sure that the first one is worth it - do you have a use-case 
> for very large numbers of slices?  Given that VAAPI lacks the ability to 
> limit slices by size (for H.323 / RTP packet limits), the other use I can 
> think of is for parallelism or related conformance requirements, both of 
> which tend to want relatively small numbers.
> 
For the first one, I don't have a user case for large number of slices, but I 
think dynamic allocate is a general solution if the driver/GPU HW change the 
max slices number support in GEN10, GEN11, ...

And I will split the patch as the comments.

> 
>>  4 files changed, 79 insertions(+), 18 deletions(-)
>>
>> diff --git a/libavcodec/vaapi_encode.c b/libavcodec/vaapi_encode.c
>> index 7e9c00f51d..14a3fba7b1 100644
>> --- a/libavcodec/vaapi_encode.c
>> +++ b/libavcodec/vaapi_encode.c
>> @@ -36,13 +36,18 @@ static int 
>> vaapi_encode_make_packed_header(AVCodecContext *avctx,
>>  VAAPIEncodeContext *ctx = avctx->priv_data;
>>  VAStatus vas;
>>  VABufferID param_buffer, data_buffer;
>> +VABufferID *tmp;
>>  VAEncPackedHeaderParameterBuffer params = {
>>  .type = type,
>>  .bit_length = bit_len,
>>  .has_emulation_bytes = 1,
>>  };
>>  
>> -av_assert0(pic->nb_param_buffers + 2 <= MAX_PARAM_BUFFERS);
>> +tmp = av_realloc_array(pic->param_buffers, sizeof(*tmp), 
>> (pic->nb_param_buffers + 2));
>> +if (!tmp) {
>> +return AVERROR(ENOMEM);
> 
> This failure case leaks the already-allocated buffers.  Unfortunately you 
> can't use av_realloc_array().
> 
>> +}
>> +pic->param_buffers = tmp;
>>  
>>  vas = vaCreateBuffer(ctx->hwctx->display, ctx->va_context,
>>   VAEncPackedHeaderParameterBufferType,
>> @@ -77,9 +82,14 @@ static int vaapi_encode_make_param_buffer(AVCodecContext 
>> *avctx,
>>  {
>>  VAAPIEncodeContext *ctx = avctx->priv_data;
>>  VAStatus vas;
>> +VABufferID *tmp;
>>  VABufferID buffer;
>>  
>> -av_assert0(pic->nb_param_buffers + 1 <= MAX_PARAM_BUFFERS);
>> +tmp = av_realloc_array(pic->param_buffers, sizeof(*tmp), 
>> (pic->nb_param_buffers + 1));
>> +if (!tmp) {
>> +return AVERROR(ENOMEM);
> 
> Same.
> 
>> +}
>> +pic->param_buffers = tmp;
>>  
>>  vas = vaCreateBuffer(ctx->hwctx->display, ctx->va_context,
>>   type, len, 1, data, );
>> @@ -122,6 +132,8 @@ static int vaapi_encode_wait(AVCodecContext *avctx,
>>  // Input is definitely finished with now.
>>  av_frame_free(>input_image);
>>  
>> +av_freep(>param_buffers);
>> +
>>  pic->encode_complete = 1;
>>  return 0;
>>  }
>> @@ -313,7 +325,10 @@ static int vaapi_encode_issue(AVCodecContext *avctx,
>>  }
>>  }
>>  
>> -av_assert0(pic->nb_slices <= MAX_PICTURE_SLICES);
>> +pic->slices = (VAAPIEncodeSlice **)av_malloc(sizeof(VAAPIEncodeSlice *) 
>> * pic->nb_slices);
>> +if (pic->slices == NULL)
>> +goto fail;
>> +
>>  for (i = 0; i < pic->nb_slices; i++) {
>>  slice = av_mallocz(sizeof(*slice));
>>  if (!slice) {
>> @@ -322,7 +337,6 @@ static int vaapi_encode_issue(AVCodecContext *avctx,
>>  }
>>  slice->index = i;
>>  pic->slices[i] = slice;
>> -
> 
> Stray change?

Will clean

> 
>>  if (ctx->codec->slice_params_size > 0) {
>>  slice->codec_slice_params = 
>> av_mallocz(ctx->codec->slice_params_size);
>>  if (!slice->codec_slice_params) {
>> @@ -427,6 +441,8 @@ fail:
>>  vaDestroyBuffer(ctx->hwctx->display, pic->param_buffers[i]);
>>  fail_at_end:
>>  av_freep(>codec_picture_params);
>> +av_freep(>param_buffers);
>> +av_freep(>slices);
>>  av_frame_free(>recon_image);
>>  return err;
>>  }
>> @@ -542,6 +558,8 @@ static int vaapi_encode_free(AVCodecContext *avctx,
>>  av_frame_free(>input_image);
>>  av_frame_free(>recon_image);
>>  
>> +av_freep(>param_buffers);
>> +av_freep(>slices);

Re: [FFmpeg-devel] [PATCH V4] lavc/golomb: Fix UE golomb overwrite issue.

[Jun Zhao]

On 2017/6/13 9:33, Michael Niedermayer wrote:
> On Fri, Jun 09, 2017 at 10:34:19AM +0800, Jun Zhao wrote:
>> V4: Fix rang check error in assert base on Mark's review
>> V3: Clean the code logic base on Michael's review.
>> V2: Add set_ue_golomb_long() to support 32bits UE golomb and update the unit 
>> test.
> 
>>  golomb.h   |   17 -
>>  put_bits.h |   35 +++
>>  tests/golomb.c |   19 +++
>>  3 files changed, 70 insertions(+), 1 deletion(-)
>> 6bed99e213506530c7a58c6bffda43607a7be37c  
>> 0001-lavc-golomb-Fix-UE-golomb-overwrite-issue.patch
>> From fa3f59e5fcb2cddcc44b0e895bfa02caa491fee5 Mon Sep 17 00:00:00 2001
>> From: Jun Zhao 
>> Date: Fri, 2 Jun 2017 15:05:49 +0800
>> Subject: [PATCH V4] lavc/golomb: Fix UE golomb overwrite issue.
>>
>> put_bits just support write up to 31 bits, when write 32 bit in
>> put_bits, it's will overwrite the bit buffer, because the default
>> assert level is 0, the av_assert2(n <= 31 && value < (1U << n))
>> in put_bits can not be trigger runtime. Add set_ue_golomb_long()
>> to support 32bits UE golomb.
>>
>> Signed-off-by: Jun Zhao 
>> ---
>>  libavcodec/golomb.h   | 17 -
>>  libavcodec/put_bits.h | 35 +++
>>  libavcodec/tests/golomb.c | 19 +++
>>  3 files changed, 70 insertions(+), 1 deletion(-)
> 
> This should be 3 patches
> 1. changes to set_ue_golomb() commet
> 2. addition of put_bits64()
> 3. addition of set_ue_golomb_long()
> 
> [...]
> 
> 

I will split the patch.

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

Re: [FFmpeg-devel] [PATCH] lavc/vaapi_encode_h26[45]: respect "slices" option in h26[45] vaapi encoder.

[Mark Thompson]

On 07/06/17 01:53, Jun Zhao wrote:
> From 5c88956e36e7318cf1d1b7c41a9d4108fcf9d0a5 Mon Sep 17 00:00:00 2001
> From: Jun Zhao 
> Date: Fri, 12 May 2017 08:30:43 +0800
> Subject: [PATCH] lavc/vaapi_encode_h26[45]: respect "slices" in h26[45] vaapi
>  encoder.
> 
> Enable multi-slice support in AVC/HEVC vaapi encoder.
> 
> Signed-off-by: Wang, Yi A 
> Signed-off-by: Jun Zhao 
> ---

I think this should be three patches:

>  libavcodec/vaapi_encode.c  | 36 
>  libavcodec/vaapi_encode.h  |  9 +++--

(1) Change the slice/parameter buffers to be allocated dynamically.

>  libavcodec/vaapi_encode_h264.c | 24 ++--

(2) Respect slices option in H.264 encoder.

>  libavcodec/vaapi_encode_h265.c | 28 ++--

(3) Respect slices option in H.265 encoder.


I'm not entirely sure that the first one is worth it - do you have a use-case 
for very large numbers of slices?  Given that VAAPI lacks the ability to limit 
slices by size (for H.323 / RTP packet limits), the other use I can think of is 
for parallelism or related conformance requirements, both of which tend to want 
relatively small numbers.


>  4 files changed, 79 insertions(+), 18 deletions(-)
> 
> diff --git a/libavcodec/vaapi_encode.c b/libavcodec/vaapi_encode.c
> index 7e9c00f51d..14a3fba7b1 100644
> --- a/libavcodec/vaapi_encode.c
> +++ b/libavcodec/vaapi_encode.c
> @@ -36,13 +36,18 @@ static int vaapi_encode_make_packed_header(AVCodecContext 
> *avctx,
>  VAAPIEncodeContext *ctx = avctx->priv_data;
>  VAStatus vas;
>  VABufferID param_buffer, data_buffer;
> +VABufferID *tmp;
>  VAEncPackedHeaderParameterBuffer params = {
>  .type = type,
>  .bit_length = bit_len,
>  .has_emulation_bytes = 1,
>  };
>  
> -av_assert0(pic->nb_param_buffers + 2 <= MAX_PARAM_BUFFERS);
> +tmp = av_realloc_array(pic->param_buffers, sizeof(*tmp), 
> (pic->nb_param_buffers + 2));
> +if (!tmp) {
> +return AVERROR(ENOMEM);

This failure case leaks the already-allocated buffers.  Unfortunately you can't 
use av_realloc_array().

> +}
> +pic->param_buffers = tmp;
>  
>  vas = vaCreateBuffer(ctx->hwctx->display, ctx->va_context,
>   VAEncPackedHeaderParameterBufferType,
> @@ -77,9 +82,14 @@ static int vaapi_encode_make_param_buffer(AVCodecContext 
> *avctx,
>  {
>  VAAPIEncodeContext *ctx = avctx->priv_data;
>  VAStatus vas;
> +VABufferID *tmp;
>  VABufferID buffer;
>  
> -av_assert0(pic->nb_param_buffers + 1 <= MAX_PARAM_BUFFERS);
> +tmp = av_realloc_array(pic->param_buffers, sizeof(*tmp), 
> (pic->nb_param_buffers + 1));
> +if (!tmp) {
> +return AVERROR(ENOMEM);

Same.

> +}
> +pic->param_buffers = tmp;
>  
>  vas = vaCreateBuffer(ctx->hwctx->display, ctx->va_context,
>   type, len, 1, data, );
> @@ -122,6 +132,8 @@ static int vaapi_encode_wait(AVCodecContext *avctx,
>  // Input is definitely finished with now.
>  av_frame_free(>input_image);
>  
> +av_freep(>param_buffers);
> +
>  pic->encode_complete = 1;
>  return 0;
>  }
> @@ -313,7 +325,10 @@ static int vaapi_encode_issue(AVCodecContext *avctx,
>  }
>  }
>  
> -av_assert0(pic->nb_slices <= MAX_PICTURE_SLICES);
> +pic->slices = (VAAPIEncodeSlice **)av_malloc(sizeof(VAAPIEncodeSlice *) 
> * pic->nb_slices);
> +if (pic->slices == NULL)
> +goto fail;
> +
>  for (i = 0; i < pic->nb_slices; i++) {
>  slice = av_mallocz(sizeof(*slice));
>  if (!slice) {
> @@ -322,7 +337,6 @@ static int vaapi_encode_issue(AVCodecContext *avctx,
>  }
>  slice->index = i;
>  pic->slices[i] = slice;
> -

Stray change?

>  if (ctx->codec->slice_params_size > 0) {
>  slice->codec_slice_params = 
> av_mallocz(ctx->codec->slice_params_size);
>  if (!slice->codec_slice_params) {
> @@ -427,6 +441,8 @@ fail:
>  vaDestroyBuffer(ctx->hwctx->display, pic->param_buffers[i]);
>  fail_at_end:
>  av_freep(>codec_picture_params);
> +av_freep(>param_buffers);
> +av_freep(>slices);
>  av_frame_free(>recon_image);
>  return err;
>  }
> @@ -542,6 +558,8 @@ static int vaapi_encode_free(AVCodecContext *avctx,
>  av_frame_free(>input_image);
>  av_frame_free(>recon_image);
>  
> +av_freep(>param_buffers);
> +av_freep(>slices);
>  // Output buffer should already be destroyed.
>  av_assert0(pic->output_buffer == VA_INVALID_ID);
>  
> @@ -949,6 +967,7 @@ static av_cold int 
> vaapi_encode_config_attributes(AVCodecContext *avctx)
>  { VAConfigAttribRTFormat },
>  { VAConfigAttribRateControl  },
>  { VAConfigAttribEncMaxRefFrames  },
> +{ VAConfigAttribEncMaxSlices },
>  { VAConfigAttribEncPackedHeaders },
>  };
>  
> @@ -1079,6 

Re: [FFmpeg-devel] Refund request for Customs fees of donations

[Michael Niedermayer]

On Thu, Feb 23, 2017 at 08:35:21PM +0100, Thilo Borgmann wrote:
> Hi,
> 
> in the aftermath of ELCE 2016 we recieved a donation of 5 displays from a 
> company. These went to Michael Niedermayer, Carl Eugen Hoyos, Ronald Bultje, 
> Clement Boesch and myself.
> 
> Unfortunately, due to lack of experience with that, I had to pay customs for 
> 4 of 5 of these displays which had to be sent to me for being the only valid 
> address in Europe the manufacturer could deliver to. I also mailed the 
> displays further on to Austria and France and payed the corresponding fees 
> for that, too. Thus I hereby ask for refunding these expenses.
> 
> The numbers are:
> 
> Customs  96,37€
> +92,29€
> +92,29€
> +91,69€
> 
> Mail+22,99€
> +33,99€
> 
> Sum 429,62€
> 
> I'll send a copy of all invoices to Stefano privately.

noone objected so LGTM

thx

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

Modern terrorism, a quick summary: Need oil, start war with country that
has oil, kill hundread thousand in war. Let country fall into chaos,
be surprised about raise of fundamantalists. Drop more bombs, kill more
people, be surprised about them taking revenge and drop even more bombs
and strip your own citizens of their rights and freedoms. to be continued


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

Re: [FFmpeg-devel] configure/libopenjpegdec.c/libopenjpegenc.c: Add support for LibOpenJPEG v2.2/git

[Reino Wijnsma]

On 13-6-2017 05:58, Michael Bradshaw  wrote:
> Are you sure you built ffmpeg using OpenJPEG v2.2? Because your patch is
> missing the openjpeg_2_2_openjpeg_h entry in HEADERS_LIST in configure, so
> you shouldn't be able to successfully build with OpenJPEG v2.2.
Whoops! In my script I'm patching 'configure' with sed
.
While turning these changes into a patch I seem to have forgotten the
HEADERS_LIST entry indeed. New patch attached.
From 70b53c1ea5a56a03cfef24d5b551b983ba2473b2 Mon Sep 17 00:00:00 2001
From: Reino17 
Date: Wed, 14 Jun 2017 00:19:12 +0200
Subject: [PATCH] Add support for LibOpenJPEG v2.2/git

---
 configure   |  4 +++-
 libavcodec/libopenjpegdec.c | 10 +++---
 libavcodec/libopenjpegenc.c | 12 
 3 files changed, 18 insertions(+), 8 deletions(-)

diff --git a/configure b/configure
index e3941f9..0190966 100755
--- a/configure
+++ b/configure
@@ -1868,6 +1868,7 @@ HEADERS_LIST="
 machine_ioctl_meteor_h
 malloc_h
 opencv2_core_core_c_h
+openjpeg_2_2_openjpeg_h
 openjpeg_2_1_openjpeg_h
 openjpeg_2_0_openjpeg_h
 openjpeg_1_5_openjpeg_h
@@ -5831,7 +5832,8 @@ enabled libopencv && { check_header 
opencv2/core/core_c.h &&
  require opencv opencv2/core/core_c.h 
cvCreateImageHeader -lopencv_core -lopencv_imgproc; } ||
require_pkg_config opencv opencv/cxcore.h 
cvCreateImageHeader; }
 enabled libopenh264   && require_pkg_config openh264 wels/codec_api.h 
WelsGetCodecVersion
-enabled libopenjpeg   && { { check_lib libopenjpeg openjpeg-2.1/openjpeg.h 
opj_version -lopenjp2 -DOPJ_STATIC && add_cppflags -DOPJ_STATIC; } ||
+enabled libopenjpeg   && { { check_lib libopenjpeg openjpeg-2.2/openjpeg.h 
opj_version -lopenjp2 -DOPJ_STATIC && add_cppflags -DOPJ_STATIC; } ||
+   { check_lib libopenjpeg openjpeg-2.1/openjpeg.h 
opj_version -lopenjp2 -DOPJ_STATIC && add_cppflags -DOPJ_STATIC; } ||
check_lib libopenjpeg openjpeg-2.1/openjpeg.h 
opj_version -lopenjp2 ||
{ check_lib libopenjpeg openjpeg-2.0/openjpeg.h 
opj_version -lopenjp2 -DOPJ_STATIC && add_cppflags -DOPJ_STATIC; } ||
{ check_lib libopenjpeg openjpeg-1.5/openjpeg.h 
opj_version -lopenjpeg -DOPJ_STATIC && add_cppflags -DOPJ_STATIC; } ||
diff --git a/libavcodec/libopenjpegdec.c b/libavcodec/libopenjpegdec.c
index ce4e2b0..5ed9ce1 100644
--- a/libavcodec/libopenjpegdec.c
+++ b/libavcodec/libopenjpegdec.c
@@ -34,7 +34,9 @@
 #include "internal.h"
 #include "thread.h"
 
-#if HAVE_OPENJPEG_2_1_OPENJPEG_H
+#if HAVE_OPENJPEG_2_2_OPENJPEG_H
+#  include 
+#elif HAVE_OPENJPEG_2_1_OPENJPEG_H
 #  include 
 #elif HAVE_OPENJPEG_2_0_OPENJPEG_H
 #  include 
@@ -44,7 +46,7 @@
 #  include 
 #endif
 
-#if HAVE_OPENJPEG_2_1_OPENJPEG_H || HAVE_OPENJPEG_2_0_OPENJPEG_H
+#if HAVE_OPENJPEG_2_2_OPENJPEG_H || HAVE_OPENJPEG_2_1_OPENJPEG_H || 
HAVE_OPENJPEG_2_0_OPENJPEG_H
 #  define OPENJPEG_MAJOR_VERSION 2
 #  define OPJ(x) OPJ_##x
 #else
@@ -429,7 +431,9 @@ static int libopenjpeg_decode_frame(AVCodecContext *avctx,
 opj_stream_set_read_function(stream, stream_read);
 opj_stream_set_skip_function(stream, stream_skip);
 opj_stream_set_seek_function(stream, stream_seek);
-#if HAVE_OPENJPEG_2_1_OPENJPEG_H
+#if HAVE_OPENJPEG_2_2_OPENJPEG_H
+opj_stream_set_user_data(stream, , NULL);
+#elif HAVE_OPENJPEG_2_1_OPENJPEG_H
 opj_stream_set_user_data(stream, , NULL);
 #elif HAVE_OPENJPEG_2_0_OPENJPEG_H
 opj_stream_set_user_data(stream, );
diff --git a/libavcodec/libopenjpegenc.c b/libavcodec/libopenjpegenc.c
index 4a12729..d3b9161 100644
--- a/libavcodec/libopenjpegenc.c
+++ b/libavcodec/libopenjpegenc.c
@@ -32,7 +32,9 @@
 #include "avcodec.h"
 #include "internal.h"
 
-#if HAVE_OPENJPEG_2_1_OPENJPEG_H
+#if HAVE_OPENJPEG_2_2_OPENJPEG_H
+#  include 
+#elif HAVE_OPENJPEG_2_1_OPENJPEG_H
 #  include 
 #elif HAVE_OPENJPEG_2_0_OPENJPEG_H
 #  include 
@@ -42,7 +44,7 @@
 #  include 
 #endif
 
-#if HAVE_OPENJPEG_2_1_OPENJPEG_H || HAVE_OPENJPEG_2_0_OPENJPEG_H
+#if HAVE_OPENJPEG_2_2_OPENJPEG_H || HAVE_OPENJPEG_2_1_OPENJPEG_H || 
HAVE_OPENJPEG_2_0_OPENJPEG_H
 #  define OPENJPEG_MAJOR_VERSION 2
 #  define OPJ(x) OPJ_##x
 #else
@@ -305,7 +307,7 @@ static av_cold int libopenjpeg_encode_init(AVCodecContext 
*avctx)
 
 opj_set_default_encoder_parameters(>enc_params);
 
-#if HAVE_OPENJPEG_2_1_OPENJPEG_H
+#if HAVE_OPENJPEG_2_2_OPENJPEG_H || HAVE_OPENJPEG_2_1_OPENJPEG_H
 switch (ctx->cinema_mode) {
 case OPJ_CINEMA2K_24:
 ctx->enc_params.rsiz = OPJ_PROFILE_CINEMA_2K;
@@ -769,7 +771,9 @@ static int libopenjpeg_encode_frame(AVCodecContext *avctx, 
AVPacket *pkt,
 opj_stream_set_write_function(stream, stream_write);
 opj_stream_set_skip_function(stream, 

Re: [FFmpeg-devel] [PATCH 06/24] ffmpeg: Enable generic hwaccel support for VAAPI

[Mark Thompson]

On 13/06/17 21:19, Michael Niedermayer wrote:
> On Mon, Jun 12, 2017 at 11:40:23PM +0100, Mark Thompson wrote:
>> (cherry picked from commit 62a1ef9f26c654a3e988aa465c4ac1d776c4c356)
>> ---
>>  Makefile   |   1 -
>>  ffmpeg.h   |   2 -
>>  ffmpeg_opt.c   |  20 -
>>  ffmpeg_vaapi.c | 233 
>> -
>>  4 files changed, 16 insertions(+), 240 deletions(-)
>>  delete mode 100644 ffmpeg_vaapi.c
>>
>> diff --git a/Makefile b/Makefile
>> index 913a890a78..26f9d93d85 100644
>> --- a/Makefile
>> +++ b/Makefile
>> @@ -34,7 +34,6 @@ $(foreach prog,$(AVBASENAMES),$(eval 
>> OBJS-$(prog)-$(CONFIG_OPENCL) += cmdutils_o
>>  OBJS-ffmpeg   += ffmpeg_opt.o ffmpeg_filter.o ffmpeg_hw.o
>>  OBJS-ffmpeg-$(CONFIG_VIDEOTOOLBOX) += ffmpeg_videotoolbox.o
>>  OBJS-ffmpeg-$(CONFIG_LIBMFX)  += ffmpeg_qsv.o
>> -OBJS-ffmpeg-$(CONFIG_VAAPI)   += ffmpeg_vaapi.o
>>  ifndef CONFIG_VIDEOTOOLBOX
>>  OBJS-ffmpeg-$(CONFIG_VDA) += ffmpeg_videotoolbox.o
>>  endif
>> diff --git a/ffmpeg.h b/ffmpeg.h
>> index 5c115cf9a3..231d362f5f 100644
>> --- a/ffmpeg.h
>> +++ b/ffmpeg.h
>> @@ -665,8 +665,6 @@ int dxva2_init(AVCodecContext *s);
>>  int vda_init(AVCodecContext *s);
>>  int videotoolbox_init(AVCodecContext *s);
>>  int qsv_init(AVCodecContext *s);
>> -int vaapi_decode_init(AVCodecContext *avctx);
>> -int vaapi_device_init(const char *device);
>>  int cuvid_init(AVCodecContext *s);
>>  
>>  HWDevice *hw_device_get_by_name(const char *name);
>> diff --git a/ffmpeg_opt.c b/ffmpeg_opt.c
>> index 6755e09e47..51671e0dd4 100644
>> --- a/ffmpeg_opt.c
>> +++ b/ffmpeg_opt.c
>> @@ -87,8 +87,8 @@ const HWAccel hwaccels[] = {
>>AV_HWDEVICE_TYPE_NONE },
>>  #endif
>>  #if CONFIG_VAAPI
>> -{ "vaapi", vaapi_decode_init, HWACCEL_VAAPI, AV_PIX_FMT_VAAPI,
>> -  AV_HWDEVICE_TYPE_NONE },
>> +{ "vaapi", hwaccel_decode_init, HWACCEL_VAAPI, AV_PIX_FMT_VAAPI,
>> +  AV_HWDEVICE_TYPE_VAAPI },
>>  #endif
>>  #if CONFIG_CUVID
>>  { "cuvid", cuvid_init, HWACCEL_CUVID, AV_PIX_FMT_CUDA,
>> @@ -462,10 +462,22 @@ static int opt_sdp_file(void *optctx, const char *opt, 
>> const char *arg)
>>  #if CONFIG_VAAPI
>>  static int opt_vaapi_device(void *optctx, const char *opt, const char *arg)
>>  {
>> +HWDevice *dev;
>> +const char *prefix = "vaapi:";
>> +char *tmp;
>>  int err;
>> -err = vaapi_device_init(arg);
> 
>> +tmp = av_malloc(strlen(prefix) + strlen(arg) + 1);
>> +if (!tmp)
>> +return AVERROR(ENOMEM);
>> +strcpy(tmp, prefix);
>> +strcat(tmp, arg);
> 
> You can simplify this with av_asprintf()

Yep, changed.  (Also a similar instance in 4/24.)

Thanks,

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

[FFmpeg-devel] [PATCH] Add missing parenthesis to show_help_default (-h) output

[Jim Jazwiecki]

---
 ffmpeg_opt.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/ffmpeg_opt.c b/ffmpeg_opt.c
index c997ea8faf..2740ef9e75 100644
--- a/ffmpeg_opt.c
+++ b/ffmpeg_opt.c
@@ -3127,7 +3127,7 @@ void show_help_default(const char *opt, const char *arg)
   OPT_EXIT, 0, 0);
 
 show_help_options(options, "Global options (affect whole program "
-  "instead of just one file:",
+  "instead of just one file):",
   0, per_file | OPT_EXIT | OPT_EXPERT, 0);
 if (show_advanced)
 show_help_options(options, "Advanced global options:", OPT_EXPERT,
-- 
2.11.0

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

Re: [FFmpeg-devel] [PATCH 04/24] hwcontext: Make it easier to work with device types

[Mark Thompson]

On 13/06/17 21:23, Michael Niedermayer wrote:
> On Mon, Jun 12, 2017 at 11:40:21PM +0100, Mark Thompson wrote:
>> Adds functions to convert to/from strings and a function to iterate
>> over all supported device types.  Also adds a new invalid type
>> AV_HWDEVICE_TYPE_NONE, which acts as a sentinel value.
>>
>> (cherry picked from commit b7487f4f3c39b4b202e1ea7bb2de13902f2dee45)
>> ---
>>  doc/APIchanges|  4 
>>  libavutil/hwcontext.c | 42 ++
>>  libavutil/hwcontext.h | 28 
>>  libavutil/version.h   |  2 +-
>>  4 files changed, 75 insertions(+), 1 deletion(-)
>>
>> diff --git a/doc/APIchanges b/doc/APIchanges
>> index a6889f3930..5b2203f2b4 100644
>> --- a/doc/APIchanges
>> +++ b/doc/APIchanges
>> @@ -15,6 +15,10 @@ libavutil: 2015-08-28
>>  
>>  API changes, most recent first:
>>  
>> +2017-06-xx - xxx - lavu 55.65.100 - hwcontext.h
>> +  Add AV_HWDEVICE_TYPE_NONE, av_hwdevice_find_type_by_name(),
>> +  av_hwdevice_get_type_name() and av_hwdevice_iterate_types().
>> +
>>  2017-06-xx - xxx - lavu 55.64.100 - hwcontext.h
>>Add av_hwdevice_ctx_create_derived().
>>  
>> diff --git a/libavutil/hwcontext.c b/libavutil/hwcontext.c
>> index 86d290d322..7f9b1d33e3 100644
>> --- a/libavutil/hwcontext.c
>> +++ b/libavutil/hwcontext.c
>> @@ -50,6 +50,48 @@ static const HWContextType *hw_table[] = {
>>  NULL,
>>  };
>>  
>> +const char *hw_type_names[] = {
> 
> was this intended to be static const ?

Yes; fixed.

Thanks,

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

Re: [FFmpeg-devel] [PATCH 00/24] Generic hardware device setup and miscellaneous related merges

[James Almer]

On 6/12/2017 7:40 PM, Mark Thompson wrote:
> This merges a set of stuff from libav to do with hardware codecs/processing.
> 
> The two most interesting features of this are:
> 
> * Generic hardware device setup.  This finishes the uniform structure for 
> hardware device setup which has been in progress for a while, finally 
> deleting several of the ffmpeg_X.c hardware specific files.  Initially this 
> is working for VAAPI and VDPAU, with partial support for QSV.  A following 
> series by wm4 (start from 
> )
>  will add DXVA2/D3D11 support as well.
> 
> * Mapping between hardware APIs.  Initially this supports VAAPI/DXVA2 and 
> QSV, OpenCL integration with those is to follow.  The main use of this at the 
> moment to to allow use of the lavc decoder via a platform hwaccel and hence 
> avoid the nastiness of the specific  *_qsv decoders (for example: "./ffmpeg_g 
> -y -hwaccel vaapi -hwaccel_output_format vaapi -i in.mp4 -an -vf 
> 'hwmap=derive_device=qsv,format=qsv' -c:v h264_qsv -b 5M -maxrate 5M 
> -look_ahead 0 out.mp4", and similarly with DXVA2).
> 
> Other oddments:
> * Support for the VAAPI driver which wraps VDPAU.
> * Field rate output for the VAAPI deinterlacer.
> * hw_device_ctx support for QSV codecs using software frames (fixes some 
> current silly failure cases when using multiple independent instances 
> together).
> * Profile mismatch option for hwaccels (primarily to allow hardware decoding 
> of H.264 constrained baseline profile streams which erroneously fail to set 
> constraint_set1_flag).
> * Documentation for the hardware frame movement filters (hwupload, 
> hwdownload, hwmap).
> 
> VP9 VAAPI encode support would be here, but is not included because it 
> depends on the vp9_raw_reorder BSF, which is only written with the bitstream 
> API rather than with get_bits.  I know that was skipped earlier, but has 
> there been any more discussion on merging that?  Would it be easiest to just 
> convert the BSF?

It will be easier to just convert the BSF to use get_bits for now.
As mentioned in the thread where the new bitstream reader was skipped,
until it's confirmed there are no considerable regressions in speed on
some modules then we're not going to merge it.
In this case it should be a simple search & replace.

BitstreamContext -> GetBitContext
bitstream_read -> get_bits (Since all of them read <= 25 bits)
bitstream_read_bit -> get_bits1
bitstream_init8 -> init_get_bits8
etc.

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

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

Re: [FFmpeg-devel] [PATCH 04/24] hwcontext: Make it easier to work with device types

[Michael Niedermayer]

On Mon, Jun 12, 2017 at 11:40:21PM +0100, Mark Thompson wrote:
> Adds functions to convert to/from strings and a function to iterate
> over all supported device types.  Also adds a new invalid type
> AV_HWDEVICE_TYPE_NONE, which acts as a sentinel value.
> 
> (cherry picked from commit b7487f4f3c39b4b202e1ea7bb2de13902f2dee45)
> ---
>  doc/APIchanges|  4 
>  libavutil/hwcontext.c | 42 ++
>  libavutil/hwcontext.h | 28 
>  libavutil/version.h   |  2 +-
>  4 files changed, 75 insertions(+), 1 deletion(-)
> 
> diff --git a/doc/APIchanges b/doc/APIchanges
> index a6889f3930..5b2203f2b4 100644
> --- a/doc/APIchanges
> +++ b/doc/APIchanges
> @@ -15,6 +15,10 @@ libavutil: 2015-08-28
>  
>  API changes, most recent first:
>  
> +2017-06-xx - xxx - lavu 55.65.100 - hwcontext.h
> +  Add AV_HWDEVICE_TYPE_NONE, av_hwdevice_find_type_by_name(),
> +  av_hwdevice_get_type_name() and av_hwdevice_iterate_types().
> +
>  2017-06-xx - xxx - lavu 55.64.100 - hwcontext.h
>Add av_hwdevice_ctx_create_derived().
>  
> diff --git a/libavutil/hwcontext.c b/libavutil/hwcontext.c
> index 86d290d322..7f9b1d33e3 100644
> --- a/libavutil/hwcontext.c
> +++ b/libavutil/hwcontext.c
> @@ -50,6 +50,48 @@ static const HWContextType *hw_table[] = {
>  NULL,
>  };
>  
> +const char *hw_type_names[] = {

was this intended to be static const ?

it lacks a prefix like av_ for a non static

[...]
-- 
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


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

Re: [FFmpeg-devel] [PATCH 06/24] ffmpeg: Enable generic hwaccel support for VAAPI

[Michael Niedermayer]

On Mon, Jun 12, 2017 at 11:40:23PM +0100, Mark Thompson wrote:
> (cherry picked from commit 62a1ef9f26c654a3e988aa465c4ac1d776c4c356)
> ---
>  Makefile   |   1 -
>  ffmpeg.h   |   2 -
>  ffmpeg_opt.c   |  20 -
>  ffmpeg_vaapi.c | 233 
> -
>  4 files changed, 16 insertions(+), 240 deletions(-)
>  delete mode 100644 ffmpeg_vaapi.c
> 
> diff --git a/Makefile b/Makefile
> index 913a890a78..26f9d93d85 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -34,7 +34,6 @@ $(foreach prog,$(AVBASENAMES),$(eval 
> OBJS-$(prog)-$(CONFIG_OPENCL) += cmdutils_o
>  OBJS-ffmpeg   += ffmpeg_opt.o ffmpeg_filter.o ffmpeg_hw.o
>  OBJS-ffmpeg-$(CONFIG_VIDEOTOOLBOX) += ffmpeg_videotoolbox.o
>  OBJS-ffmpeg-$(CONFIG_LIBMFX)  += ffmpeg_qsv.o
> -OBJS-ffmpeg-$(CONFIG_VAAPI)   += ffmpeg_vaapi.o
>  ifndef CONFIG_VIDEOTOOLBOX
>  OBJS-ffmpeg-$(CONFIG_VDA) += ffmpeg_videotoolbox.o
>  endif
> diff --git a/ffmpeg.h b/ffmpeg.h
> index 5c115cf9a3..231d362f5f 100644
> --- a/ffmpeg.h
> +++ b/ffmpeg.h
> @@ -665,8 +665,6 @@ int dxva2_init(AVCodecContext *s);
>  int vda_init(AVCodecContext *s);
>  int videotoolbox_init(AVCodecContext *s);
>  int qsv_init(AVCodecContext *s);
> -int vaapi_decode_init(AVCodecContext *avctx);
> -int vaapi_device_init(const char *device);
>  int cuvid_init(AVCodecContext *s);
>  
>  HWDevice *hw_device_get_by_name(const char *name);
> diff --git a/ffmpeg_opt.c b/ffmpeg_opt.c
> index 6755e09e47..51671e0dd4 100644
> --- a/ffmpeg_opt.c
> +++ b/ffmpeg_opt.c
> @@ -87,8 +87,8 @@ const HWAccel hwaccels[] = {
>AV_HWDEVICE_TYPE_NONE },
>  #endif
>  #if CONFIG_VAAPI
> -{ "vaapi", vaapi_decode_init, HWACCEL_VAAPI, AV_PIX_FMT_VAAPI,
> -  AV_HWDEVICE_TYPE_NONE },
> +{ "vaapi", hwaccel_decode_init, HWACCEL_VAAPI, AV_PIX_FMT_VAAPI,
> +  AV_HWDEVICE_TYPE_VAAPI },
>  #endif
>  #if CONFIG_CUVID
>  { "cuvid", cuvid_init, HWACCEL_CUVID, AV_PIX_FMT_CUDA,
> @@ -462,10 +462,22 @@ static int opt_sdp_file(void *optctx, const char *opt, 
> const char *arg)
>  #if CONFIG_VAAPI
>  static int opt_vaapi_device(void *optctx, const char *opt, const char *arg)
>  {
> +HWDevice *dev;
> +const char *prefix = "vaapi:";
> +char *tmp;
>  int err;
> -err = vaapi_device_init(arg);

> +tmp = av_malloc(strlen(prefix) + strlen(arg) + 1);
> +if (!tmp)
> +return AVERROR(ENOMEM);
> +strcpy(tmp, prefix);
> +strcat(tmp, arg);

You can simplify this with av_asprintf()

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

[FFmpeg-devel] [PATCH] hevc: Add support for alternative transfer characterics SEI

[Vittorio Giovara]

The use of this SEI is for backward compatibility in HLG HDR systems:
older devices that cannot interpret the "arib-std-b67" transfer will
get the compatible transfer (usually bt709 or bt2020) from the VUI,
while newer devices that can interpret HDR will read the SEI and use
its value instead.

Signed-off-by: Vittorio Giovara 
---
 libavcodec/hevc_sei.c | 9 +
 libavcodec/hevc_sei.h | 7 +++
 libavcodec/hevcdec.c  | 6 ++
 3 files changed, 22 insertions(+)

diff --git a/libavcodec/hevc_sei.c b/libavcodec/hevc_sei.c
index f0ad84f2f4..cd55d50212 100644
--- a/libavcodec/hevc_sei.c
+++ b/libavcodec/hevc_sei.c
@@ -265,6 +265,13 @@ static int 
decode_nal_sei_active_parameter_sets(HEVCSEIContext *s, GetBitContext
 return 0;
 }
 
+static int decode_nal_sei_alternative_transfer(HEVCSEIAlternativeTransfer *s, 
GetBitContext *gb)
+{
+s->present = 1;
+s->preferred_transfer_characteristics = get_bits(gb, 8);
+return 0;
+}
+
 static int decode_nal_sei_prefix(GetBitContext *gb, HEVCSEIContext *s, const 
HEVCParamSets *ps,
  int type, int size, void *logctx)
 {
@@ -285,6 +292,8 @@ static int decode_nal_sei_prefix(GetBitContext *gb, 
HEVCSEIContext *s, const HEV
 return decode_nal_sei_active_parameter_sets(s, gb, logctx);
 case HEVC_SEI_TYPE_USER_DATA_REGISTERED_ITU_T_T35:
 return decode_nal_sei_user_data_registered_itu_t_t35(s, gb, size);
+case HEVC_SEI_TYPE_ALTERNATIVE_TRANSFER_CHARACTERISTICS:
+return decode_nal_sei_alternative_transfer(>alternative_transfer, 
gb);
 default:
 av_log(logctx, AV_LOG_DEBUG, "Skipped PREFIX SEI %d\n", type);
 skip_bits_long(gb, 8 * size);
diff --git a/libavcodec/hevc_sei.h b/libavcodec/hevc_sei.h
index 5645e4f5de..1b57ec 100644
--- a/libavcodec/hevc_sei.h
+++ b/libavcodec/hevc_sei.h
@@ -56,6 +56,7 @@ typedef enum {
 HEVC_SEI_TYPE_REGION_REFRESH_INFO  = 134,
 HEVC_SEI_TYPE_MASTERING_DISPLAY_INFO   = 137,
 HEVC_SEI_TYPE_CONTENT_LIGHT_LEVEL_INFO = 144,
+HEVC_SEI_TYPE_ALTERNATIVE_TRANSFER_CHARACTERISTICS = 147,
 } HEVC_SEI_Type;
 
 typedef struct HEVCSEIPictureHash {
@@ -100,6 +101,11 @@ typedef struct HEVCSEIContentLight {
 uint16_t max_pic_average_light_level;
 } HEVCSEIContentLight;
 
+typedef struct HEVCSEIAlternativeTransfer {
+int present;
+int preferred_transfer_characteristics;
+} HEVCSEIAlternativeTransfer;
+
 typedef struct HEVCSEIContext {
 HEVCSEIPictureHash picture_hash;
 HEVCSEIFramePacking frame_packing;
@@ -109,6 +115,7 @@ typedef struct HEVCSEIContext {
 HEVCSEIMasteringDisplay mastering_display;
 HEVCSEIContentLight content_light;
 int active_seq_parameter_set_id;
+HEVCSEIAlternativeTransfer alternative_transfer;
 } HEVCSEIContext;
 
 struct HEVCParamSets;
diff --git a/libavcodec/hevcdec.c b/libavcodec/hevcdec.c
index 23a89345a8..167ce550f7 100644
--- a/libavcodec/hevcdec.c
+++ b/libavcodec/hevcdec.c
@@ -2684,6 +2684,12 @@ static int set_side_data(HEVCContext *s)
 s->avctx->properties |= FF_CODEC_PROPERTY_CLOSED_CAPTIONS;
 }
 
+if (s->sei.alternative_transfer.present &&
+
av_color_transfer_name(s->sei.alternative_transfer.preferred_transfer_characteristics)
 &&
+s->sei.alternative_transfer.preferred_transfer_characteristics != 
AVCOL_TRC_UNSPECIFIED) {
+s->avctx->color_trc = 
s->sei.alternative_transfer.preferred_transfer_characteristics;
+}
+
 return 0;
 }
 
-- 
2.12.0

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

Re: [FFmpeg-devel] [PATCH 07/11] avfilter/vf_signature: fix memory leaks in error cases

[Timo Rothenpieler]

Am 13.06.2017 um 00:24 schrieb Michael Niedermayer:

On Sun, Jun 11, 2017 at 04:05:49PM +0200, Timo Rothenpieler wrote:

Fixes CIDs 1403234 and 1403235
---
  libavfilter/vf_signature.c | 5 -
  1 file changed, 4 insertions(+), 1 deletion(-)


LGTM

thx


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

Re: [FFmpeg-devel] [PATCH 05/11] avformat/pcmdec: fix memory leak

[Timo Rothenpieler]

Am 11.06.2017 um 19:07 schrieb Paul B Mahol:

On 6/11/17, Timo Rothenpieler  wrote:

Fixes CID 1396267
---
  libavformat/pcmdec.c | 2 ++
  1 file changed, 2 insertions(+)

diff --git a/libavformat/pcmdec.c b/libavformat/pcmdec.c
index 3c7e8ac84b..d0ceea6fa9 100644
--- a/libavformat/pcmdec.c
+++ b/libavformat/pcmdec.c
@@ -68,6 +68,7 @@ static int pcm_read_header(AVFormatContext *s)
  av_log(s, AV_LOG_ERROR,
 "Invalid sample_rate found in mime_type \"%s\"\n",
 mime_type);
+av_freep(_type);
  return AVERROR_INVALIDDATA;
  }
  st->codecpar->sample_rate = rate;
@@ -75,6 +76,7 @@ static int pcm_read_header(AVFormatContext *s)
  st->codecpar->channels = channels;
  }
  }
+av_freep(_type);

  st->codecpar->bits_per_coded_sample =
  av_get_bits_per_sample(st->codecpar->codec_id);
--
2.13.0

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



lgtm


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

Re: [FFmpeg-devel] [PATCH 04/11] avformat/librtmp: check return value of setsockopt

[Timo Rothenpieler]

Am 12.06.2017 um 05:07 schrieb Steven Liu:

2017-06-11 22:05 GMT+08:00 Timo Rothenpieler :

Fixes CID 1396837
---
  libavformat/librtmp.c | 5 -
  1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/libavformat/librtmp.c b/libavformat/librtmp.c
index 146df660ac..f3cfa9a8e2 100644
--- a/libavformat/librtmp.c
+++ b/libavformat/librtmp.c
@@ -239,7 +239,10 @@ static int rtmp_open(URLContext *s, const char *uri, int 
flags)
  #if CONFIG_NETWORK
  if (ctx->buffer_size >= 0 && (flags & AVIO_FLAG_WRITE)) {
  int tmp = ctx->buffer_size;
-setsockopt(r->m_sb.sb_socket, SOL_SOCKET, SO_SNDBUF, , 
sizeof(tmp));
+if (setsockopt(r->m_sb.sb_socket, SOL_SOCKET, SO_SNDBUF, , 
sizeof(tmp))) {
+rc = AVERROR_EXTERNAL;
+goto fail;
+}
  }
  #endif

LGTM


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

Re: [FFmpeg-devel] [PATCH 01/11] avfilter/unsharp: fix uninitialized pointer read

[Timo Rothenpieler]

Am 13.06.2017 um 00:26 schrieb Michael Niedermayer:

On Sun, Jun 11, 2017 at 04:05:43PM +0200, Timo Rothenpieler wrote:

Fixes CID 1396855
---
  libavfilter/unsharp_opencl.c | 4 ++--
  1 file changed, 2 insertions(+), 2 deletions(-)


LGTM

thx


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

Re: [FFmpeg-devel] [PATCH 02/11] avfilter/vf_scale_npp: fix out-of-bounds reads

[Timo Rothenpieler]

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

Re: [FFmpeg-devel] [PATCH] avcodec/htmlsubtitles: drop an state

[wm4]

On Tue, 13 Jun 2017 16:30:42 +0200
Clément Bœsch  wrote:

> On Tue, Jun 13, 2017 at 03:09:54PM +0200, Michael Niedermayer wrote:
> [...]
> > -Dialogue: 0,0:00:24.50,0:00:26.50,Default,,0,0,0,,{\an4}This text should 
> > be at the\Nmiddle and horizontally at the left\N(The second position must 
> > be ignored)
> > +Dialogue: 0,0:00:24.50,0:00:26.50,Default,,0,0,0,,{\an4}This text should 
> > be at the\Nmiddle and horiz{\an6}ontally at the left\N(The second position 
> > must be ignored)  
> 
> "The second position must be ignored"
> 
> I guess that was the use case.
> 

Who says that? VSFilter? Some other software? What does libass do?

It's a VSFilter extension in SRT subtitles. FFmpeg just passes these
along to libass. If libass has different behavior, it should be fixed,
as it mostly strives to be VSFilter compatible. It makes not the
slightest sense to "fix" this here.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH v3] avfilter/vf_fps: fix duration

[Thomas Mundt]

2017-06-13 15:04 GMT+02:00 Thomas Mundt :

> 2017-06-13 15:00 GMT+02:00 Nicolas George :
>
>> Le quintidi 25 prairial, an CCXXV, Thomas Mundt a écrit :
>> > Live with the open ticket or with the modified patch?
>>
>> Either, actually, but I meant the modified patch.
>>
>
> Okay, I´ll write the patch then and send it soon.
>

Patch attached. This fixes ticket #2674. I inserted a FIXME message as a
reminder.
Please comment.

Regards,
Thomas


0001-avfilter-vf_fps-fix-duration.patch
Description: Binary data
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] hevc: Add support for alternative transfer characterics SEI

[Vittorio Giovara]

On Sun, Jun 11, 2017 at 10:19 AM, James Almer  wrote:
> On 6/9/2017 6:35 PM, Vittorio Giovara wrote:
>> Signed-off-by: Vittorio Giovara 
>> ---
>>  libavcodec/hevc_sei.c | 9 +
>>  libavcodec/hevc_sei.h | 7 +++
>>  libavcodec/hevcdec.c  | 5 +
>>  3 files changed, 21 insertions(+)
>>
>> diff --git a/libavcodec/hevc_sei.c b/libavcodec/hevc_sei.c
>> index f0ad84f2f4..cd55d50212 100644
>> --- a/libavcodec/hevc_sei.c
>> +++ b/libavcodec/hevc_sei.c
>> @@ -265,6 +265,13 @@ static int 
>> decode_nal_sei_active_parameter_sets(HEVCSEIContext *s, GetBitContext
>>  return 0;
>>  }
>>
>> +static int decode_nal_sei_alternative_transfer(HEVCSEIAlternativeTransfer 
>> *s, GetBitContext *gb)
>> +{
>> +s->present = 1;
>> +s->preferred_transfer_characteristics = get_bits(gb, 8);
>> +return 0;
>> +}
>> +
>>  static int decode_nal_sei_prefix(GetBitContext *gb, HEVCSEIContext *s, 
>> const HEVCParamSets *ps,
>>   int type, int size, void *logctx)
>>  {
>> @@ -285,6 +292,8 @@ static int decode_nal_sei_prefix(GetBitContext *gb, 
>> HEVCSEIContext *s, const HEV
>>  return decode_nal_sei_active_parameter_sets(s, gb, logctx);
>>  case HEVC_SEI_TYPE_USER_DATA_REGISTERED_ITU_T_T35:
>>  return decode_nal_sei_user_data_registered_itu_t_t35(s, gb, size);
>> +case HEVC_SEI_TYPE_ALTERNATIVE_TRANSFER_CHARACTERISTICS:
>> +return 
>> decode_nal_sei_alternative_transfer(>alternative_transfer, gb);
>>  default:
>>  av_log(logctx, AV_LOG_DEBUG, "Skipped PREFIX SEI %d\n", type);
>>  skip_bits_long(gb, 8 * size);
>> diff --git a/libavcodec/hevc_sei.h b/libavcodec/hevc_sei.h
>> index 5645e4f5de..1b57ec 100644
>> --- a/libavcodec/hevc_sei.h
>> +++ b/libavcodec/hevc_sei.h
>> @@ -56,6 +56,7 @@ typedef enum {
>>  HEVC_SEI_TYPE_REGION_REFRESH_INFO  = 134,
>>  HEVC_SEI_TYPE_MASTERING_DISPLAY_INFO   = 137,
>>  HEVC_SEI_TYPE_CONTENT_LIGHT_LEVEL_INFO = 144,
>> +HEVC_SEI_TYPE_ALTERNATIVE_TRANSFER_CHARACTERISTICS = 147,
>>  } HEVC_SEI_Type;
>>
>>  typedef struct HEVCSEIPictureHash {
>> @@ -100,6 +101,11 @@ typedef struct HEVCSEIContentLight {
>>  uint16_t max_pic_average_light_level;
>>  } HEVCSEIContentLight;
>>
>> +typedef struct HEVCSEIAlternativeTransfer {
>> +int present;
>> +int preferred_transfer_characteristics;
>> +} HEVCSEIAlternativeTransfer;
>> +
>>  typedef struct HEVCSEIContext {
>>  HEVCSEIPictureHash picture_hash;
>>  HEVCSEIFramePacking frame_packing;
>> @@ -109,6 +115,7 @@ typedef struct HEVCSEIContext {
>>  HEVCSEIMasteringDisplay mastering_display;
>>  HEVCSEIContentLight content_light;
>>  int active_seq_parameter_set_id;
>> +HEVCSEIAlternativeTransfer alternative_transfer;
>>  } HEVCSEIContext;
>>
>>  struct HEVCParamSets;
>> diff --git a/libavcodec/hevcdec.c b/libavcodec/hevcdec.c
>> index 23a89345a8..955cc703cf 100644
>> --- a/libavcodec/hevcdec.c
>> +++ b/libavcodec/hevcdec.c
>> @@ -2684,6 +2684,11 @@ static int set_side_data(HEVCContext *s)
>>  s->avctx->properties |= FF_CODEC_PROPERTY_CLOSED_CAPTIONS;
>>  }
>>
>> +if (s->sei.alternative_transfer.present &&
>> +s->sei.alternative_transfer.preferred_transfer_characteristics != 
>> AVCOL_SPC_UNSPECIFIED) {
>
> Shouldn't this be AVCOL_TRC_UNSPECIFIED?

Right, typo, thanks.

> And validate it with av_color_transfer_name() instead, like it's done in
> hevc_ps.c with the VUI value.
>
>> +s->avctx->color_trc = 
>> s->sei.alternative_transfer.preferred_transfer_characteristics;
>
> Did you make sure avctx->color_trc will not be overwritten by the VUI
> value after this? As in, what's called first, set_side_data() or
> export_stream_params()? And is it properly propagated in updates between
> thread contexts?

This is called after extradata decoding: from hevc_decode_frame(),
first hevc_decode_extradata() -> export_stream_param(), then
decode_nal_units() -> decode_nal_unit() -> hevc_frame_start() ->
set_side_data().
Regarding your second question, I suppose so, the sei check just above
modifies the global context in a similar way.

One thing I noticed is that I probably need to update the output frame
value besides the context, I'll send an updated version.
--
Vittorio
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] lavc/aarch64/simple_idct: fix idct_col4_top coefficient

[Matthieu Bouron]

On Tue, Jun 13, 2017 at 05:26:43PM +0200, Clément Bœsch wrote:
> On Tue, Jun 13, 2017 at 05:24:21PM +0200, Matthieu Bouron wrote:
> > Fixes regression introduced by 5d0b8b1ae307951310c7d9a8fa282fbca9b997cd.
> > ---
> >  libavcodec/aarch64/simple_idct_neon.S | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> > 
> > diff --git a/libavcodec/aarch64/simple_idct_neon.S 
> > b/libavcodec/aarch64/simple_idct_neon.S
> > index 92987985d2..5bd31e5be9 100644
> > --- a/libavcodec/aarch64/simple_idct_neon.S
> > +++ b/libavcodec/aarch64/simple_idct_neon.S
> > @@ -74,7 +74,7 @@ endconst
> >  .endm
> >  
> >  .macro idct_col4_top y1, y2, y3, y4, i, l
> > -smull\i v7.4S,  \y3\l, z1
> > +smull\i v7.4S,  \y3\l, z2
> >  smull\i v16.4S, \y3\l, z6
> >  smull\i v17.4S, \y2\l, z1
> >  add v19.4S, v23.4S, v7.4S
> 
> LGTM

Patch applied and backported to the 3.3 branch.

Thanks.

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

Re: [FFmpeg-devel] [PATCH] lavc/aarch64/simple_idct: fix idct_col4_top coefficient

[Clément Bœsch]

On Tue, Jun 13, 2017 at 05:24:21PM +0200, Matthieu Bouron wrote:
> Fixes regression introduced by 5d0b8b1ae307951310c7d9a8fa282fbca9b997cd.
> ---
>  libavcodec/aarch64/simple_idct_neon.S | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/libavcodec/aarch64/simple_idct_neon.S 
> b/libavcodec/aarch64/simple_idct_neon.S
> index 92987985d2..5bd31e5be9 100644
> --- a/libavcodec/aarch64/simple_idct_neon.S
> +++ b/libavcodec/aarch64/simple_idct_neon.S
> @@ -74,7 +74,7 @@ endconst
>  .endm
>  
>  .macro idct_col4_top y1, y2, y3, y4, i, l
> -smull\i v7.4S,  \y3\l, z1
> +smull\i v7.4S,  \y3\l, z2
>  smull\i v16.4S, \y3\l, z6
>  smull\i v17.4S, \y2\l, z1
>  add v19.4S, v23.4S, v7.4S

LGTM

-- 
Clément B.


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

[FFmpeg-devel] [PATCH] lavc/aarch64/simple_idct: fix idct_col4_top coefficient

[Matthieu Bouron]

Fixes regression introduced by 5d0b8b1ae307951310c7d9a8fa282fbca9b997cd.
---
 libavcodec/aarch64/simple_idct_neon.S | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/libavcodec/aarch64/simple_idct_neon.S 
b/libavcodec/aarch64/simple_idct_neon.S
index 92987985d2..5bd31e5be9 100644
--- a/libavcodec/aarch64/simple_idct_neon.S
+++ b/libavcodec/aarch64/simple_idct_neon.S
@@ -74,7 +74,7 @@ endconst
 .endm
 
 .macro idct_col4_top y1, y2, y3, y4, i, l
-smull\i v7.4S,  \y3\l, z1
+smull\i v7.4S,  \y3\l, z2
 smull\i v16.4S, \y3\l, z6
 smull\i v17.4S, \y2\l, z1
 add v19.4S, v23.4S, v7.4S
-- 
2.13.1

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

Re: [FFmpeg-devel] [PATCH] avcodec/htmlsubtitles: drop an state

[Clément Bœsch]

On Tue, Jun 13, 2017 at 03:09:54PM +0200, Michael Niedermayer wrote:
[...]
> -Dialogue: 0,0:00:24.50,0:00:26.50,Default,,0,0,0,,{\an4}This text should be 
> at the\Nmiddle and horizontally at the left\N(The second position must be 
> ignored)
> +Dialogue: 0,0:00:24.50,0:00:26.50,Default,,0,0,0,,{\an4}This text should be 
> at the\Nmiddle and horiz{\an6}ontally at the left\N(The second position must 
> be ignored)

"The second position must be ignored"

I guess that was the use case.

-- 
Clément B.


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

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

[Paul B Mahol]

On 6/13/17, Paras Chadha  wrote:
> Above mentioned changes have been done.
>
> Signed-off-by: Paras Chadha 
> ---
>  Changelog   |   1 +
>  doc/general.texi|   2 +
>  libavcodec/Makefile |   1 +
>  libavcodec/allcodecs.c  |   1 +
>  libavcodec/avcodec.h|   1 +
>  libavcodec/codec_desc.c |   8 +
>  libavcodec/fitsdec.c| 515
> 
>  libavcodec/version.h|   2 +-
>  libavformat/img2.c  |   1 +
>  9 files changed, 531 insertions(+), 1 deletion(-)
>  create mode 100644 libavcodec/fitsdec.c
>
> diff --git a/Changelog b/Changelog
> index cd91f63..db495d9 100644
> --- a/Changelog
> +++ b/Changelog
> @@ -20,6 +20,7 @@ version :
>  - sofalizer filter switched to libmysofa
>  - Gremlin Digital Video demuxer and decoder
>  - headphone audio filter
> +- FITS decoder
>
>  version 3.3:
>  - CrystalHD decoder moved to new decode API
> diff --git a/doc/general.texi b/doc/general.texi
> index 8f582d5..213e50e 100644
> --- a/doc/general.texi
> +++ b/doc/general.texi
> @@ -591,6 +591,8 @@ following image formats are supported:
>  @tab Digital Picture Exchange
>  @item EXR  @tab   @tab X
>  @tab OpenEXR
> +@item FITS @tab   @tab X
> +@tab FITS image format
>  @item JPEG @tab X @tab X
>  @tab Progressive JPEG is not supported.
>  @item JPEG 2000@tab X @tab X
> diff --git a/libavcodec/Makefile b/libavcodec/Makefile
> index 2e7f19d..2cfd1fe 100644
> --- a/libavcodec/Makefile
> +++ b/libavcodec/Makefile
> @@ -291,6 +291,7 @@ OBJS-$(CONFIG_FFV1_DECODER)+= ffv1dec.o
> ffv1.o
>  OBJS-$(CONFIG_FFV1_ENCODER)+= ffv1enc.o ffv1.o
>  OBJS-$(CONFIG_FFWAVESYNTH_DECODER) += ffwavesynth.o
>  OBJS-$(CONFIG_FIC_DECODER) += fic.o
> +OBJS-$(CONFIG_FITS_DECODER)+= fitsdec.o
>  OBJS-$(CONFIG_FLAC_DECODER)+= flacdec.o flacdata.o flac.o
>  OBJS-$(CONFIG_FLAC_ENCODER)+= flacenc.o flacdata.o flac.o
> vorbis_data.o
>  OBJS-$(CONFIG_FLASHSV_DECODER) += flashsv.o
> diff --git a/libavcodec/allcodecs.c b/libavcodec/allcodecs.c
> index 27110e1..8a89264 100644
> --- a/libavcodec/allcodecs.c
> +++ b/libavcodec/allcodecs.c
> @@ -186,6 +186,7 @@ static void register_all(void)
>  REGISTER_ENCDEC (FFV1,  ffv1);
>  REGISTER_ENCDEC (FFVHUFF,   ffvhuff);
>  REGISTER_DECODER(FIC,   fic);
> +REGISTER_DECODER(FITS,  fits);
>  REGISTER_ENCDEC (FLASHSV,   flashsv);
>  REGISTER_ENCDEC (FLASHSV2,  flashsv2);
>  REGISTER_DECODER(FLIC,  flic);
> diff --git a/libavcodec/avcodec.h b/libavcodec/avcodec.h
> index dcdcfe0..e0c1089 100644
> --- a/libavcodec/avcodec.h
> +++ b/libavcodec/avcodec.h
> @@ -447,6 +447,7 @@ enum AVCodecID {
>  AV_CODEC_ID_SRGC,
>  AV_CODEC_ID_SVG,
>  AV_CODEC_ID_GDV,
> +AV_CODEC_ID_FITS,
>
>  /* various PCM "codecs" */
>  AV_CODEC_ID_FIRST_AUDIO = 0x1, ///< A dummy id pointing at the
> start of audio codecs
> diff --git a/libavcodec/codec_desc.c b/libavcodec/codec_desc.c
> index cf1246e..0112517 100644
> --- a/libavcodec/codec_desc.c
> +++ b/libavcodec/codec_desc.c
> @@ -1464,6 +1464,14 @@ static const AVCodecDescriptor codec_descriptors[] =
> {
>   AV_CODEC_PROP_LOSSLESS,
>  },
>  {
> +.id= AV_CODEC_ID_FITS,
> +.type  = AVMEDIA_TYPE_VIDEO,
> +.name  = "fits",
> +.long_name = NULL_IF_CONFIG_SMALL("Flexible Image Transport
> System"),
> +.props = AV_CODEC_PROP_INTRA_ONLY | AV_CODEC_PROP_LOSSY |
> + AV_CODEC_PROP_LOSSLESS,
> +},
> +{
>  .id= AV_CODEC_ID_GIF,
>  .type  = AVMEDIA_TYPE_VIDEO,
>  .name  = "gif",
> diff --git a/libavcodec/fitsdec.c b/libavcodec/fitsdec.c
> new file mode 100644
> index 000..dfc4995
> --- /dev/null
> +++ b/libavcodec/fitsdec.c
> @@ -0,0 +1,515 @@
> +/*
> + * FITS image decoder
> + * Copyright (c) 2017 Paras Chadha
> + *
> + * This file is part of FFmpeg.
> + *
> + * FFmpeg is free software; you can redistribute it and/or
> + * modify it under the terms of the GNU Lesser General Public
> + * License as published by the Free Software Foundation; either
> + * version 2.1 of the License, or (at your option) any later version.
> + *
> + * FFmpeg is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
> + * Lesser General Public License for more details.
> + *
> + * You should have received a copy of the GNU Lesser General Public
> + * License along with FFmpeg; if not, write to the Free Software
> + * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301
> USA
> + */
> +
> +/**
> + * @file
> + * FITS image decoder
> + * It supports all 2-d 

[FFmpeg-devel] [PATCH] Add FITS Decoder

[Paras Chadha]

Above mentioned changes have been done.

Signed-off-by: Paras Chadha 
---
 Changelog   |   1 +
 doc/general.texi|   2 +
 libavcodec/Makefile |   1 +
 libavcodec/allcodecs.c  |   1 +
 libavcodec/avcodec.h|   1 +
 libavcodec/codec_desc.c |   8 +
 libavcodec/fitsdec.c| 515 
 libavcodec/version.h|   2 +-
 libavformat/img2.c  |   1 +
 9 files changed, 531 insertions(+), 1 deletion(-)
 create mode 100644 libavcodec/fitsdec.c

diff --git a/Changelog b/Changelog
index cd91f63..db495d9 100644
--- a/Changelog
+++ b/Changelog
@@ -20,6 +20,7 @@ version :
 - sofalizer filter switched to libmysofa
 - Gremlin Digital Video demuxer and decoder
 - headphone audio filter
+- FITS decoder

 version 3.3:
 - CrystalHD decoder moved to new decode API
diff --git a/doc/general.texi b/doc/general.texi
index 8f582d5..213e50e 100644
--- a/doc/general.texi
+++ b/doc/general.texi
@@ -591,6 +591,8 @@ following image formats are supported:
 @tab Digital Picture Exchange
 @item EXR  @tab   @tab X
 @tab OpenEXR
+@item FITS @tab   @tab X
+@tab FITS image format
 @item JPEG @tab X @tab X
 @tab Progressive JPEG is not supported.
 @item JPEG 2000@tab X @tab X
diff --git a/libavcodec/Makefile b/libavcodec/Makefile
index 2e7f19d..2cfd1fe 100644
--- a/libavcodec/Makefile
+++ b/libavcodec/Makefile
@@ -291,6 +291,7 @@ OBJS-$(CONFIG_FFV1_DECODER)+= ffv1dec.o ffv1.o
 OBJS-$(CONFIG_FFV1_ENCODER)+= ffv1enc.o ffv1.o
 OBJS-$(CONFIG_FFWAVESYNTH_DECODER) += ffwavesynth.o
 OBJS-$(CONFIG_FIC_DECODER) += fic.o
+OBJS-$(CONFIG_FITS_DECODER)+= fitsdec.o
 OBJS-$(CONFIG_FLAC_DECODER)+= flacdec.o flacdata.o flac.o
 OBJS-$(CONFIG_FLAC_ENCODER)+= flacenc.o flacdata.o flac.o 
vorbis_data.o
 OBJS-$(CONFIG_FLASHSV_DECODER) += flashsv.o
diff --git a/libavcodec/allcodecs.c b/libavcodec/allcodecs.c
index 27110e1..8a89264 100644
--- a/libavcodec/allcodecs.c
+++ b/libavcodec/allcodecs.c
@@ -186,6 +186,7 @@ static void register_all(void)
 REGISTER_ENCDEC (FFV1,  ffv1);
 REGISTER_ENCDEC (FFVHUFF,   ffvhuff);
 REGISTER_DECODER(FIC,   fic);
+REGISTER_DECODER(FITS,  fits);
 REGISTER_ENCDEC (FLASHSV,   flashsv);
 REGISTER_ENCDEC (FLASHSV2,  flashsv2);
 REGISTER_DECODER(FLIC,  flic);
diff --git a/libavcodec/avcodec.h b/libavcodec/avcodec.h
index dcdcfe0..e0c1089 100644
--- a/libavcodec/avcodec.h
+++ b/libavcodec/avcodec.h
@@ -447,6 +447,7 @@ enum AVCodecID {
 AV_CODEC_ID_SRGC,
 AV_CODEC_ID_SVG,
 AV_CODEC_ID_GDV,
+AV_CODEC_ID_FITS,

 /* various PCM "codecs" */
 AV_CODEC_ID_FIRST_AUDIO = 0x1, ///< A dummy id pointing at the 
start of audio codecs
diff --git a/libavcodec/codec_desc.c b/libavcodec/codec_desc.c
index cf1246e..0112517 100644
--- a/libavcodec/codec_desc.c
+++ b/libavcodec/codec_desc.c
@@ -1464,6 +1464,14 @@ static const AVCodecDescriptor codec_descriptors[] = {
  AV_CODEC_PROP_LOSSLESS,
 },
 {
+.id= AV_CODEC_ID_FITS,
+.type  = AVMEDIA_TYPE_VIDEO,
+.name  = "fits",
+.long_name = NULL_IF_CONFIG_SMALL("Flexible Image Transport System"),
+.props = AV_CODEC_PROP_INTRA_ONLY | AV_CODEC_PROP_LOSSY |
+ AV_CODEC_PROP_LOSSLESS,
+},
+{
 .id= AV_CODEC_ID_GIF,
 .type  = AVMEDIA_TYPE_VIDEO,
 .name  = "gif",
diff --git a/libavcodec/fitsdec.c b/libavcodec/fitsdec.c
new file mode 100644
index 000..dfc4995
--- /dev/null
+++ b/libavcodec/fitsdec.c
@@ -0,0 +1,515 @@
+/*
+ * FITS image decoder
+ * Copyright (c) 2017 Paras Chadha
+ *
+ * This file is part of FFmpeg.
+ *
+ * FFmpeg is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public
+ * License as published by the Free Software Foundation; either
+ * version 2.1 of the License, or (at your option) any later version.
+ *
+ * FFmpeg is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+ * Lesser General Public License for more details.
+ *
+ * You should have received a copy of the GNU Lesser General Public
+ * License along with FFmpeg; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA
+ */
+
+/**
+ * @file
+ * FITS image decoder
+ * It supports all 2-d images alongwith, bzero, bscale and blank keywords.
+ * RGBA images are supported as NAXIS3 = 3 or 4 i.e. Planes in RGBA order. 
Also CTYPE = 'RGB ' should be present.
+ * It currently does not support XTENSION keyword.
+ * Also to interpret data, values are linearly scaled using min-max scaling 
but not RGB images.
+ 

Re: [FFmpeg-devel] [PATCH] lavc/aarch64: add sbrdsp neon implementation

[Matthieu Bouron]

On Fri, Jun 02, 2017 at 01:59:00PM +0200, Matthieu Bouron wrote:
> ---
> 
> Hello,
> 
> The following patch adds an aarch64 neon implementation of the sbrdsp (tested
> on an Odroid-C2). It hasn't been benchmarked yet and it lacks the
> hf_apply_noise{0,1,2,3} functions (which will be added later).

New patch attached adding the missing hf_apply_noise{0,1,2,3} functions.

Here are the performance results on an Odroid-C2:

sbr_apply_noise_0_c: 1690.6
sbr_apply_noise_0_neon: 1498.4
sbr_apply_noise_1_c: 1689.4
sbr_apply_noise_1_neon: 1504.2
sbr_apply_noise_2_c: 1690.2
sbr_apply_noise_2_neon: 1498.4
sbr_apply_noise_3_c: 1694.8
sbr_apply_noise_3_neon: 1504.0
sbr_autocorrelate_c: 644.0
sbr_autocorrelate_neon: 420.0
sbr_deint_bfly_c: 1107.6
sbr_deint_bfly_neon: 291.6
sbr_deint_neg_c: 210.4
sbr_deint_neg_neon: 107.4
sbr_filt_c: 2118.2
sbr_filt_neon: 1219.5
sbr_gen_c: 6071.2
sbr_gen_neon: 3251.2
sbr_neg_odd_64_c: 70.0
sbr_neg_odd_64_neon: 64.7
sbr_post_shuffle_c: 163.0
sbr_post_shuffle_neon: 107.7
sbr_pre_shuffle_c: 120.5
sbr_pre_shuffle_neon: 110.7
sbr_sum64x5_c: 1361.6
sbr_sum64x5_neon: 435.4

-- 
Matthieu B.
>From 51d950fe739fd90217d561c84d81aed2c6ed8713 Mon Sep 17 00:00:00 2001
From: Matthieu Bouron 
Date: Tue, 23 May 2017 14:29:35 +
Subject: [PATCH] lavc/aarch64: add sbrdsp neon implementation

---
 libavcodec/aarch64/Makefile  |   2 +
 libavcodec/aarch64/sbrdsp_init_aarch64.c |  71 +++
 libavcodec/aarch64/sbrdsp_neon.S | 329 +++
 libavcodec/sbrdsp.h  |   1 +
 libavcodec/sbrdsp_template.c |   2 +
 5 files changed, 405 insertions(+)
 create mode 100644 libavcodec/aarch64/sbrdsp_init_aarch64.c
 create mode 100644 libavcodec/aarch64/sbrdsp_neon.S

diff --git a/libavcodec/aarch64/Makefile b/libavcodec/aarch64/Makefile
index 104bc67802..116c343e42 100644
--- a/libavcodec/aarch64/Makefile
+++ b/libavcodec/aarch64/Makefile
@@ -11,6 +11,7 @@ OBJS-$(CONFIG_NEON_CLOBBER_TEST)+= aarch64/neontest.o
 OBJS-$(CONFIG_VIDEODSP) += aarch64/videodsp_init.o
 
 # decoders/encoders
+OBJS-$(CONFIG_AAC_DECODER)  += aarch64/sbrdsp_init_aarch64.o
 OBJS-$(CONFIG_DCA_DECODER)  += aarch64/synth_filter_init.o
 OBJS-$(CONFIG_RV40_DECODER) += aarch64/rv40dsp_init_aarch64.o
 OBJS-$(CONFIG_VC1DSP)   += aarch64/vc1dsp_init_aarch64.o
@@ -27,6 +28,7 @@ ARMV8-OBJS-$(CONFIG_VIDEODSP)   += aarch64/videodsp.o
 # NEON optimizations
 
 # subsystems
+NEON-OBJS-$(CONFIG_AAC_DECODER) += aarch64/sbrdsp_neon.o
 NEON-OBJS-$(CONFIG_FFT) += aarch64/fft_neon.o
 NEON-OBJS-$(CONFIG_FMTCONVERT)  += aarch64/fmtconvert_neon.o
 NEON-OBJS-$(CONFIG_H264CHROMA)  += aarch64/h264cmc_neon.o
diff --git a/libavcodec/aarch64/sbrdsp_init_aarch64.c b/libavcodec/aarch64/sbrdsp_init_aarch64.c
new file mode 100644
index 00..998bdb8095
--- /dev/null
+++ b/libavcodec/aarch64/sbrdsp_init_aarch64.c
@@ -0,0 +1,71 @@
+/*
+ *
+ * This file is part of FFmpeg.
+ *
+ * FFmpeg is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public
+ * License as published by the Free Software Foundation; either
+ * version 2.1 of the License, or (at your option) any later version.
+ *
+ * FFmpeg is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+ * Lesser General Public License for more details.
+ *
+ * You should have received a copy of the GNU Lesser General Public
+ * License along with FFmpeg; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA
+ */
+
+#include "config.h"
+#include "libavutil/aarch64/cpu.h"
+#include "libavutil/attributes.h"
+#include "libavcodec/sbrdsp.h"
+
+void ff_sbr_sum64x5_neon(float *z);
+float ff_sbr_sum_square_neon(float (*x)[2], int n);
+void ff_sbr_neg_odd_64_neon(float *x);
+void ff_sbr_qmf_pre_shuffle_neon(float *z);
+void ff_sbr_qmf_post_shuffle_neon(float W[32][2], const float *z);
+void ff_sbr_qmf_deint_neg_neon(float *v, const float *src);
+void ff_sbr_qmf_deint_bfly_neon(float *v, const float *src0, const float *src1);
+void ff_sbr_hf_g_filt_neon(float (*Y)[2], const float (*X_high)[40][2],
+   const float *g_filt, int m_max, intptr_t ixh);
+void ff_sbr_hf_gen_neon(float (*X_high)[2], const float (*X_low)[2],
+const float alpha0[2], const float alpha1[2],
+float bw, int start, int end);
+void ff_sbr_autocorrelate_neon(const float x[40][2], float phi[3][2][2]);
+void ff_sbr_hf_apply_noise_0_neon(float Y[64][2], const float *s_m,
+  const float *q_filt, int noise,
+  int kx, int m_max);
+void ff_sbr_hf_apply_noise_1_neon(float Y[64][2], const 

Re: [FFmpeg-devel] [PATCH 0/6] sse2/avx functions for 8-bit simple idct

[Michael Niedermayer]

Hi

On Tue, Jun 13, 2017 at 03:07:32PM +0200, James Darnley wrote:
> On 2017-06-13 00:18, James Darnley wrote:
> > On 2017-06-12 18:57, Michael Niedermayer wrote:
> >> ./ffplay ~/videos/matrixbench_mpeg2.mpg
> >> looks pretty bad
> > 
> > If that would happen to be the FATE sample
> > mpeg2/matrixbench_mpeg2.lq1.mpg then I see that too.
> > 
> > As I said on IRC I was able to partly remedy it by moving patch 6 up.
> 
> I think this problem occurs because although I assign a function for the
> plain IDCT and set the perm_type for that, the mpeg decoder uses the
> add/put functions which the C and MMX do not want to be transposed.
> 
> Removing the perm_type assignment fixes that and the new function is not
> called.
> 
> I have no idea how patch 6 managed to change anything or whether I
> failed to test properly.

the idct through idct, idct_put and idct_add are assumed
to be the same idct using the same permutation IIRC, yes.


> 
> > Ultimately I have no idea what is going on here.  I've tested decoding
> > the sample mentioned above before my inline to external conversion of
> > the MMX.  I've done that immediately after that commit.  I've done that
> > on the current master.  I get the same result for all of those.
> > 
> > Going to my patches.  I can get the same result with -cpuflags none.
> > Surely -cpuflags mmx+mmxext would then be the same as above.
> 
> I'm still stuck on that part though.  I have no idea what's going on.
> Why is permutation an option?!  Why is it not binary?  Why can some
> functions be NULL and not others?

permutation is not binary because there are more than 2 choices, see
FF_IDCT_PERM_*


> 
> I tried setting add/put to NULL (like the high bit depth does for add)
> which makes ffmpeg segfault because it tries to call NULL.

i think add/put are not used in the high bit depth case
if they are not used and not implemeted setting the pointers
to NULL is more robust than leaving them potentially set to a lower
depth implementation


> 
> 
> 
> Why does simplemmx produce the same output for some files but not
> others?  Why can't I let simplemmx be used for simple and have it pass
> fate?  Why is it different?  Why is it not the same as C?  Why does the

i should know or remember but i dont ATM :(


> dct test program show it is the same?  Is that program good for anything?
> 
> 
> 
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Its not that you shouldnt use gotos but rather that you should write
readable code and code with gotos often but not always is less readable


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

Re: [FFmpeg-devel] [PATCH] nvenc: Make AUD optional for h264_nvenc and hevc_nvenc

[Ali KIZIL]

2017-01-05 13:29 GMT+03:00 Yogender Gupta :

> >> There is BUG in Nvidia NVENC when you use AUD for H264 with B-frames,
> it will return corrupted stream, because NVIDIA is inserting AUD type 0
> (I-frame) before B-frames instead of AUD type 7 (any-frame).
>
> Thanks for bringing this to notice. We have added a fix in the Nvidia
> driver and the newer driver releases will insert the correct AUD type.
>
> Thanks,
> Yogender
>
> 
> ---
> This email message is for the sole use of the intended recipient(s) and
> may contain
> confidential information.  Any unauthorized review, use, disclosure or
> distribution
> is prohibited.  If you are not the intended recipient, please contact the
> sender by
> reply email and destroy all copies of the original message.
> 
> ---
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>

Yogender, is new driver released for correct AUD type insertion ?
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] avcodec/htmlsubtitles: drop an state

[wm4]

On Tue, 13 Jun 2017 15:09:54 +0200
Michael Niedermayer  wrote:

> Simplifies code but changes handling of multiple an tags
> 
> Suggested-by: wm4
> Signed-off-by: Michael Niedermayer 
> ---
>  libavcodec/htmlsubtitles.c | 11 +--
>  tests/ref/fate/sub-srt |  2 +-
>  2 files changed, 6 insertions(+), 7 deletions(-)
> 
> diff --git a/libavcodec/htmlsubtitles.c b/libavcodec/htmlsubtitles.c
> index be5c9316ca..8bea867051 100644
> --- a/libavcodec/htmlsubtitles.c
> +++ b/libavcodec/htmlsubtitles.c
> @@ -53,15 +53,14 @@ static void rstrip_spaces_buf(AVBPrint *buf)
>  
>  /* skip all {\xxx} substrings except for {\an%d}
> and all microdvd like styles such as {Y:xxx} */
> -static void handle_open_brace(AVBPrint *dst, const char **inp, int *an, int 
> *closing_brace_missing)
> +static void handle_open_brace(AVBPrint *dst, const char **inp, int 
> *closing_brace_missing)
>  {
>  int len = 0;
>  const char *in = *inp;
> -
> -*an += sscanf(in, "{\\an%*1u}%n", ) >= 0 && len > 0;
> +int an = sscanf(in, "{\\an%*1u}%n", ) >= 0 && len > 0;
>  
>  if (!*closing_brace_missing) {
> -if (   (*an != 1 && in[1] == '\\')
> +if (   (!an && in[1] == '\\')
>  || (in[1] && strchr("CcFfoPSsYy", in[1]) && in[2] == ':')) {
>  char *bracep = strchr(in+2, '}');
>  if (bracep) {
> @@ -78,7 +77,7 @@ static void handle_open_brace(AVBPrint *dst, const char 
> **inp, int *an, int *clo
>  int ff_htmlmarkup_to_ass(void *log_ctx, AVBPrint *dst, const char *in)
>  {
>  char *param, buffer[128], tmp[128];
> -int len, tag_close, sptr = 1, line_start = 1, an = 0, end = 0;
> +int len, tag_close, sptr = 1, line_start = 1, end = 0;
>  SrtStack stack[16];
>  int closing_brace_missing = 0;
>  
> @@ -105,7 +104,7 @@ int ff_htmlmarkup_to_ass(void *log_ctx, AVBPrint *dst, 
> const char *in)
>  av_bprint_chars(dst, *in, 1);
>  break;
>  case '{':
> -handle_open_brace(dst, , , _brace_missing);
> +handle_open_brace(dst, , _brace_missing);
>  break;
>  case '<':
>  tag_close = in[1] == '/';
> diff --git a/tests/ref/fate/sub-srt b/tests/ref/fate/sub-srt
> index 40b20cde90..c64f46864c 100644
> --- a/tests/ref/fate/sub-srt
> +++ b/tests/ref/fate/sub-srt
> @@ -24,7 +24,7 @@ Dialogue: 
> 0,0:00:22.50,0:00:24.50,Default,,0,0,0,,Implementation is the same of
>  Dialogue: 0,0:00:22.50,0:00:24.50,Default,,0,0,0,,{\an5}This text should be 
> at the\Nmiddle and horizontally centered
>  Dialogue: 0,0:00:22.50,0:00:24.50,Default,,0,0,0,,{\an2}This text should be 
> at the\Nbottom and horizontally centered
>  Dialogue: 0,0:00:24.50,0:00:26.50,Default,,0,0,0,,This text should be at 
> the\Ntop and horizontally at the left{\an7}
> -Dialogue: 0,0:00:24.50,0:00:26.50,Default,,0,0,0,,{\an4}This text should be 
> at the\Nmiddle and horizontally at the left\N(The second position must be 
> ignored)
> +Dialogue: 0,0:00:24.50,0:00:26.50,Default,,0,0,0,,{\an4}This text should be 
> at the\Nmiddle and horiz{\an6}ontally at the left\N(The second position must 
> be ignored)
>  Dialogue: 0,0:00:24.50,0:00:26.50,Default,,0,0,0,,{\an1}This text should be 
> at the\Nbottom and horizontally at the left
>  Dialogue: 0,0:00:26.50,0:00:28.50,Default,,0,0,0,,{\an9}This text should be 
> at the\Ntop and horizontally at the right
>  Dialogue: 0,0:00:26.50,0:00:28.50,Default,,0,0,0,,{\an6}This text should be 
> at the\Nmiddle and horizontally at the right

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

Re: [FFmpeg-devel] [PATCH] avcodec/htmlsubtitles: Factor open brace handling into its own function

[Michael Niedermayer]

On Tue, Jun 13, 2017 at 01:19:56PM +0200, wm4 wrote:
> On Tue, 13 Jun 2017 00:01:04 +0200
> Michael Niedermayer  wrote:
> 
> > Suggested-by: wm4
> > Signed-off-by: Michael Niedermayer 
> > ---
> >  libavcodec/htmlsubtitles.c | 44 
> > ++--
> >  1 file changed, 26 insertions(+), 18 deletions(-)
> > 
> > diff --git a/libavcodec/htmlsubtitles.c b/libavcodec/htmlsubtitles.c
> > index 70311c66d5..be5c9316ca 100644
> > --- a/libavcodec/htmlsubtitles.c
> > +++ b/libavcodec/htmlsubtitles.c
> > @@ -51,6 +51,30 @@ static void rstrip_spaces_buf(AVBPrint *buf)
> >  buf->str[--buf->len] = 0;
> >  }
> >  
> > +/* skip all {\xxx} substrings except for {\an%d}
> > +   and all microdvd like styles such as {Y:xxx} */
> > +static void handle_open_brace(AVBPrint *dst, const char **inp, int *an, 
> > int *closing_brace_missing)
> > +{
> > +int len = 0;
> > +const char *in = *inp;
> > +
> > +*an += sscanf(in, "{\\an%*1u}%n", ) >= 0 && len > 0;
> > +
> > +if (!*closing_brace_missing) {
> > +if (   (*an != 1 && in[1] == '\\')
> > +|| (in[1] && strchr("CcFfoPSsYy", in[1]) && in[2] == ':')) {
> > +char *bracep = strchr(in+2, '}');
> > +if (bracep) {
> > +*inp = bracep;
> > +return;
> > +} else
> > +*closing_brace_missing = 1;
> > +}
> > +}
> > +
> > +av_bprint_chars(dst, *in, 1);
> > +}
> > +
> >  int ff_htmlmarkup_to_ass(void *log_ctx, AVBPrint *dst, const char *in)
> >  {
> >  char *param, buffer[128], tmp[128];
> > @@ -80,24 +104,8 @@ int ff_htmlmarkup_to_ass(void *log_ctx, AVBPrint *dst, 
> > const char *in)
> >  if (!line_start)
> >  av_bprint_chars(dst, *in, 1);
> >  break;
> > -case '{':/* skip all {\xxx} substrings except for {\an%d}
> > -and all microdvd like styles such as {Y:xxx} */
> > -len = 0;
> > -an += sscanf(in, "{\\an%*1u}%n", ) >= 0 && len > 0;
> > -
> > -if (!closing_brace_missing) {
> > -if (   (an != 1 && in[1] == '\\')
> > -|| (in[1] && strchr("CcFfoPSsYy", in[1]) && in[2] == 
> > ':')) {
> > -char *bracep = strchr(in+2, '}');
> > -if (bracep) {
> > -in = bracep;
> > -break;
> > -} else
> > -closing_brace_missing = 1;
> > -}
> > -}
> > -
> > -av_bprint_chars(dst, *in, 1);
> > +case '{':
> > +handle_open_brace(dst, , , _brace_missing);
> >  break;
> >  case '<':
> >  tag_close = in[1] == '/';
> 
> Looked at the an thing again (at the old code in git master). It makes
> no sense to me - skipping should always behave the same.
> 
> Maybe it's actually a bug, or it attempted to emit subsequent an tags
> by trying to be overly clever.
> 
> In theory, only 1 an tag is ok per line, so "{\an1}{\an2}" the second
> an tag would either do nothing, or override the first tag. Maybe
> someone thought it'd be reasonable to skip the an second tag, but I
> don't see how it matters.
> 
> It could also be an attempt to get the same behavior between libass and
> VSFitler between redundant an tags (maybe VSFilter uses the value of
> the first tag, while libass uses the second tag). Then I'd say this
> should be fixed in libass instead.
> 
> Anyway, I'd remove that extra an handling. It's a good example of
> overly complicated code that makes everything less readable for
> absolutely no reason. (Unless I'm overlooking something obvious.)

ok, ive sent a patch that does that


> 
> Rest LGTM.

will apply the 3 patches in a day or 2 unless there are more comments

thx


[...9
-- 
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


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

[FFmpeg-devel] [PATCH] avcodec/htmlsubtitles: drop an state

[Michael Niedermayer]

Simplifies code but changes handling of multiple an tags

Suggested-by: wm4
Signed-off-by: Michael Niedermayer 
---
 libavcodec/htmlsubtitles.c | 11 +--
 tests/ref/fate/sub-srt |  2 +-
 2 files changed, 6 insertions(+), 7 deletions(-)

diff --git a/libavcodec/htmlsubtitles.c b/libavcodec/htmlsubtitles.c
index be5c9316ca..8bea867051 100644
--- a/libavcodec/htmlsubtitles.c
+++ b/libavcodec/htmlsubtitles.c
@@ -53,15 +53,14 @@ static void rstrip_spaces_buf(AVBPrint *buf)
 
 /* skip all {\xxx} substrings except for {\an%d}
and all microdvd like styles such as {Y:xxx} */
-static void handle_open_brace(AVBPrint *dst, const char **inp, int *an, int 
*closing_brace_missing)
+static void handle_open_brace(AVBPrint *dst, const char **inp, int 
*closing_brace_missing)
 {
 int len = 0;
 const char *in = *inp;
-
-*an += sscanf(in, "{\\an%*1u}%n", ) >= 0 && len > 0;
+int an = sscanf(in, "{\\an%*1u}%n", ) >= 0 && len > 0;
 
 if (!*closing_brace_missing) {
-if (   (*an != 1 && in[1] == '\\')
+if (   (!an && in[1] == '\\')
 || (in[1] && strchr("CcFfoPSsYy", in[1]) && in[2] == ':')) {
 char *bracep = strchr(in+2, '}');
 if (bracep) {
@@ -78,7 +77,7 @@ static void handle_open_brace(AVBPrint *dst, const char 
**inp, int *an, int *clo
 int ff_htmlmarkup_to_ass(void *log_ctx, AVBPrint *dst, const char *in)
 {
 char *param, buffer[128], tmp[128];
-int len, tag_close, sptr = 1, line_start = 1, an = 0, end = 0;
+int len, tag_close, sptr = 1, line_start = 1, end = 0;
 SrtStack stack[16];
 int closing_brace_missing = 0;
 
@@ -105,7 +104,7 @@ int ff_htmlmarkup_to_ass(void *log_ctx, AVBPrint *dst, 
const char *in)
 av_bprint_chars(dst, *in, 1);
 break;
 case '{':
-handle_open_brace(dst, , , _brace_missing);
+handle_open_brace(dst, , _brace_missing);
 break;
 case '<':
 tag_close = in[1] == '/';
diff --git a/tests/ref/fate/sub-srt b/tests/ref/fate/sub-srt
index 40b20cde90..c64f46864c 100644
--- a/tests/ref/fate/sub-srt
+++ b/tests/ref/fate/sub-srt
@@ -24,7 +24,7 @@ Dialogue: 
0,0:00:22.50,0:00:24.50,Default,,0,0,0,,Implementation is the same of
 Dialogue: 0,0:00:22.50,0:00:24.50,Default,,0,0,0,,{\an5}This text should be at 
the\Nmiddle and horizontally centered
 Dialogue: 0,0:00:22.50,0:00:24.50,Default,,0,0,0,,{\an2}This text should be at 
the\Nbottom and horizontally centered
 Dialogue: 0,0:00:24.50,0:00:26.50,Default,,0,0,0,,This text should be at 
the\Ntop and horizontally at the left{\an7}
-Dialogue: 0,0:00:24.50,0:00:26.50,Default,,0,0,0,,{\an4}This text should be at 
the\Nmiddle and horizontally at the left\N(The second position must be ignored)
+Dialogue: 0,0:00:24.50,0:00:26.50,Default,,0,0,0,,{\an4}This text should be at 
the\Nmiddle and horiz{\an6}ontally at the left\N(The second position must be 
ignored)
 Dialogue: 0,0:00:24.50,0:00:26.50,Default,,0,0,0,,{\an1}This text should be at 
the\Nbottom and horizontally at the left
 Dialogue: 0,0:00:26.50,0:00:28.50,Default,,0,0,0,,{\an9}This text should be at 
the\Ntop and horizontally at the right
 Dialogue: 0,0:00:26.50,0:00:28.50,Default,,0,0,0,,{\an6}This text should be at 
the\Nmiddle and horizontally at the right
-- 
2.13.0

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

Re: [FFmpeg-devel] [PATCH 0/6] sse2/avx functions for 8-bit simple idct

[James Darnley]

On 2017-06-13 00:18, James Darnley wrote:
> On 2017-06-12 18:57, Michael Niedermayer wrote:
>> ./ffplay ~/videos/matrixbench_mpeg2.mpg
>> looks pretty bad
> 
> If that would happen to be the FATE sample
> mpeg2/matrixbench_mpeg2.lq1.mpg then I see that too.
> 
> As I said on IRC I was able to partly remedy it by moving patch 6 up.

I think this problem occurs because although I assign a function for the
plain IDCT and set the perm_type for that, the mpeg decoder uses the
add/put functions which the C and MMX do not want to be transposed.

Removing the perm_type assignment fixes that and the new function is not
called.

I have no idea how patch 6 managed to change anything or whether I
failed to test properly.

> Ultimately I have no idea what is going on here.  I've tested decoding
> the sample mentioned above before my inline to external conversion of
> the MMX.  I've done that immediately after that commit.  I've done that
> on the current master.  I get the same result for all of those.
> 
> Going to my patches.  I can get the same result with -cpuflags none.
> Surely -cpuflags mmx+mmxext would then be the same as above.

I'm still stuck on that part though.  I have no idea what's going on.
Why is permutation an option?!  Why is it not binary?  Why can some
functions be NULL and not others?

I tried setting add/put to NULL (like the high bit depth does for add)
which makes ffmpeg segfault because it tries to call NULL.



Why does simplemmx produce the same output for some files but not
others?  Why can't I let simplemmx be used for simple and have it pass
fate?  Why is it different?  Why is it not the same as C?  Why does the
dct test program show it is the same?  Is that program good for anything?



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

Re: [FFmpeg-devel] [PATCH v3] avfilter/vf_fps: fix duration

[Thomas Mundt]

2017-06-13 15:00 GMT+02:00 Nicolas George :

> Le quintidi 25 prairial, an CCXXV, Thomas Mundt a écrit :
> > Live with the open ticket or with the modified patch?
>
> Either, actually, but I meant the modified patch.
>

Okay, I´ll write the patch then and send it soon.

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

Re: [FFmpeg-devel] [PATCH v3] avfilter/vf_fps: fix duration

[Nicolas George]

Le quintidi 25 prairial, an CCXXV, Thomas Mundt a écrit :
> Live with the open ticket or with the modified patch?

Either, actually, but I meant the modified patch.

Regards,

-- 
  Nicolas George


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

Re: [FFmpeg-devel] [PATCH v3] avfilter/vf_fps: fix duration

[Thomas Mundt]

2017-06-13 14:46 GMT+02:00 Nicolas George :

> Le quintidi 25 prairial, an CCXXV, Thoms Mundt a écrit :
> > Since I dont see any solution or wip for this, I could modify my patch
> and
> > remove the use of pkt_duration. This would only work for constant frame
> rate
> > input, but fixes ticket #2674 which is open for 4 years now.
>
> I can live with that.
>
> Regards,
>

Live with the open ticket or with the modified patch?

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

Re: [FFmpeg-devel] [PATCH v3] avfilter/vf_fps: fix duration

[Nicolas George]

Le quintidi 25 prairial, an CCXXV, Thoms Mundt a écrit :
> Since I dont see any solution or wip for this, I could modify my patch and
> remove the use of pkt_duration. This would only work for constant frame rate
> input, but fixes ticket #2674 which is open for 4 years now.

I can live with that.

Regards,

-- 
  Nicolas George


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

Re: [FFmpeg-devel] [PATCH] lavc/mediacodecdec: switch to the new generic filtering mechanism

[Matthieu Bouron]

On Sat, Jun 10, 2017 at 01:38:20AM +0200, Matthieu Bouron wrote:
> On Fri, Jun 09, 2017 at 08:18:25PM -0300, James Almer wrote:
> > On 6/9/2017 7:53 PM, Matthieu Bouron wrote:
> > > ---
> > >  libavcodec/mediacodecdec.c | 70 
> > > --
> > >  1 file changed, 12 insertions(+), 58 deletions(-)
> > > 
> > > diff --git a/libavcodec/mediacodecdec.c b/libavcodec/mediacodecdec.c
> > > index 5bdeb6c1d7..0c77a78aa9 100644
> > > --- a/libavcodec/mediacodecdec.c
> > > +++ b/libavcodec/mediacodecdec.c
> > > @@ -41,11 +41,9 @@ typedef struct MediaCodecH264DecContext {
> > >  
> > >  MediaCodecDecContext *ctx;
> > >  
> > > -AVBSFContext *bsf;
> > > -
> > >  AVFifoBuffer *fifo;
> > >  
> > > -AVPacket filtered_pkt;
> > > +AVPacket buffered_pkt;
> > >  
> > >  } MediaCodecH264DecContext;
> > >  
> > > @@ -58,8 +56,7 @@ static av_cold int 
> > > mediacodec_decode_close(AVCodecContext *avctx)
> > >  
> > >  av_fifo_free(s->fifo);
> > >  
> > > -av_bsf_free(>bsf);
> > > -av_packet_unref(>filtered_pkt);
> > > +av_packet_unref(>buffered_pkt);
> > >  
> > >  return 0;
> > >  }
> > > @@ -312,9 +309,6 @@ static av_cold int 
> > > mediacodec_decode_init(AVCodecContext *avctx)
> > >  
> > >  const char *codec_mime = NULL;
> > >  
> > > -const char *bsf_name = NULL;
> > > -const AVBitStreamFilter *bsf = NULL;
> > > -
> > >  FFAMediaFormat *format = NULL;
> > >  MediaCodecH264DecContext *s = avctx->priv_data;
> > >  
> > > @@ -329,7 +323,6 @@ static av_cold int 
> > > mediacodec_decode_init(AVCodecContext *avctx)
> > >  #if CONFIG_H264_MEDIACODEC_DECODER
> > >  case AV_CODEC_ID_H264:
> > >  codec_mime = "video/avc";
> > > -bsf_name = "h264_mp4toannexb";
> > >  
> > >  ret = h264_set_extradata(avctx, format);
> > >  if (ret < 0)
> > > @@ -339,7 +332,6 @@ static av_cold int 
> > > mediacodec_decode_init(AVCodecContext *avctx)
> > >  #if CONFIG_HEVC_MEDIACODEC_DECODER
> > >  case AV_CODEC_ID_HEVC:
> > >  codec_mime = "video/hevc";
> > > -bsf_name = "hevc_mp4toannexb";
> > >  
> > >  ret = hevc_set_extradata(avctx, format);
> > >  if (ret < 0)
> > > @@ -410,25 +402,6 @@ static av_cold int 
> > > mediacodec_decode_init(AVCodecContext *avctx)
> > >  goto done;
> > >  }
> > >  
> > > -if (bsf_name) {
> > > -bsf = av_bsf_get_by_name(bsf_name);
> > > -if(!bsf) {
> > > -ret = AVERROR_BSF_NOT_FOUND;
> > > -goto done;
> > > -}
> > > -
> > > -if ((ret = av_bsf_alloc(bsf, >bsf))) {
> > > -goto done;
> > > -}
> > > -
> > > -if (((ret = avcodec_parameters_from_context(s->bsf->par_in, avctx)) 
> > > < 0) ||
> > > -((ret = av_bsf_init(s->bsf)) < 0)) {
> > > -  goto done;
> > > -}
> > > -}
> > > -
> > > -av_init_packet(>filtered_pkt);
> > > -
> > >  done:
> > >  if (format) {
> > >  ff_AMediaFormat_delete(format);
> > > @@ -503,10 +476,10 @@ static int mediacodec_decode_frame(AVCodecContext 
> > > *avctx, void *data,
> > >  /* process buffered data */
> > >  while (!*got_frame) {
> > >  /* prepare the input data -- convert to Annex B if needed */
> > 
> > The second part of this comment can be removed.
> 
> Fixed.
> 
> > 
> > > -if (s->filtered_pkt.size <= 0) {
> > > -AVPacket input_pkt = { 0 };
> > > +if (s->buffered_pkt.size <= 0) {
> > > +AVPacket input_pkt;
> > >  
> > > -av_packet_unref(>filtered_pkt);
> > > +av_packet_unref(>buffered_pkt);
> > >  
> > >  /* no more data */
> > >  if (av_fifo_size(s->fifo) < sizeof(AVPacket)) {
> > > @@ -514,36 +487,15 @@ static int mediacodec_decode_frame(AVCodecContext 
> > > *avctx, void *data,
> > >  ff_mediacodec_dec_decode(avctx, s->ctx, frame, 
> > > got_frame, avpkt);
> > >  }
> > >  
> > > -av_fifo_generic_read(s->fifo, _pkt, sizeof(input_pkt), 
> > > NULL);
> > > -
> > > -if (s->bsf) {
> > > -ret = av_bsf_send_packet(s->bsf, _pkt);
> > > -if (ret < 0) {
> > > -return ret;
> > > -}
> > > -
> > > -ret = av_bsf_receive_packet(s->bsf, >filtered_pkt);
> > > -if (ret == AVERROR(EAGAIN)) {
> > > -goto done;
> > > -}
> > > -} else {
> > > -av_packet_move_ref(>filtered_pkt, _pkt);
> > > -}
> > > -
> > > -/* {h264,hevc}_mp4toannexb are used here and do not require 
> > > flushing */
> > > -av_assert0(ret != AVERROR_EOF);
> > > -
> > > -if (ret < 0) {
> > > -return ret;
> > > -}
> > > +av_fifo_generic_read(s->fifo, >buffered_pkt, 
> > > sizeof(input_pkt), NULL);
> > 
> > input_pkt is unused aside from this, so why not just do
> > sizeof(s->buffered_pkt) instead and 

Re: [FFmpeg-devel] [PATCH v3] avfilter/vf_fps: fix duration

[Thoms Mundt]

/Nicolas George > schrieb am So, 2.4.2017:/



Le tridi 13 germinal, an CCXXV, Thomas Mundt a écrit :
>/I found the use of this function in f_loop.c, so I thought it´s ok. /
Well, it is a bug. I missed it when it was first committed.

>/link->current_pts always returns the pts until the current (last) frame. />/I can calculate its duration for cfr video, but not for vfr. I need 
the pts until the virtual next frame. />/At which point in the code can I get it? /

link->current_pts is updated when request_frame() returns EOF. But to
make it work, it would be necessary that the application injects the
timestamp when marking EOF, which is not yet done, but hopefully I will
have time to work on it in the next two weeks.
Since I dont see any solution or wip for this, I could modify my patch 
and remove the use of pkt_duration. This would only work for constant 
frame rate input, but fixes ticket #2674 which is open for 4 years now.


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

Re: [FFmpeg-devel] [PATCH 00/24] Generic hardware device setup and miscellaneous related merges

[wm4]

On Mon, 12 Jun 2017 23:40:17 +0100
Mark Thompson  wrote:

> This merges a set of stuff from libav to do with hardware codecs/processing.

All patches LGTM. I don't think it makes sense to delay pushing those
either.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 09/24] vf_deinterlace_vaapi: Add support for field rate output

[wm4]

On Mon, 12 Jun 2017 23:40:26 +0100
Mark Thompson  wrote:

> In order to work correctly with the i965 driver, this also fixes the
> direction of forward/backward references - forward references are
> intended to be those from the past to the current frame, not from the
> current frame to the future.

Isn't this comment kind of outdated (or missing context)? Since we
decided that's how the vpp API works.

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

Re: [FFmpeg-devel] [PATCH 01/24] hwcontext_vaapi: Try to support the VDPAU wrapper

[wm4]

On Mon, 12 Jun 2017 23:40:18 +0100
Mark Thompson  wrote:

> The driver is somewhat bitrotten (not updated for years) but is still
> usable for decoding with this change.  To support it, this adds a new
> driver quirk to indicate no support at all for surface attributes.
> 
> Based on a patch by wm4 .
> 
> (cherry picked from commit e791b915c774408fbc0ec9e7270b021899e08ccc)
> ---
>  libavutil/hwcontext_vaapi.c | 79 
> ++---
>  libavutil/hwcontext_vaapi.h |  7 
>  2 files changed, 52 insertions(+), 34 deletions(-)
> 
> diff --git a/libavutil/hwcontext_vaapi.c b/libavutil/hwcontext_vaapi.c
> index 3b50e95615..3970726d30 100644
> --- a/libavutil/hwcontext_vaapi.c
> +++ b/libavutil/hwcontext_vaapi.c
> @@ -155,7 +155,8 @@ static int vaapi_frames_get_constraints(AVHWDeviceContext 
> *hwdev,
>  unsigned int fourcc;
>  int err, i, j, attr_count, pix_fmt_count;
>  
> -if (config) {
> +if (config &&
> +!(hwctx->driver_quirks & AV_VAAPI_DRIVER_QUIRK_SURFACE_ATTRIBUTES)) {
>  attr_count = 0;
>  vas = vaQuerySurfaceAttributes(hwctx->display, config->config_id,
> 0, _count);
> @@ -273,6 +274,11 @@ static const struct {
>  "ubit",
>  AV_VAAPI_DRIVER_QUIRK_ATTRIB_MEMTYPE,
>  },
> +{
> +"VDPAU wrapper",
> +"Splitted-Desktop Systems VDPAU backend for VA-API",
> +AV_VAAPI_DRIVER_QUIRK_SURFACE_ATTRIBUTES,
> +},
>  };
>  
>  static int vaapi_device_init(AVHWDeviceContext *hwdev)
> @@ -451,43 +457,48 @@ static int vaapi_frames_init(AVHWFramesContext *hwfc)
>  }
>  
>  if (!hwfc->pool) {
> -int need_memory_type = !(hwctx->driver_quirks & 
> AV_VAAPI_DRIVER_QUIRK_ATTRIB_MEMTYPE);
> -int need_pixel_format = 1;
> -for (i = 0; i < avfc->nb_attributes; i++) {
> -if (ctx->attributes[i].type == VASurfaceAttribMemoryType)
> -need_memory_type  = 0;
> -if (ctx->attributes[i].type == VASurfaceAttribPixelFormat)
> -need_pixel_format = 0;
> -}
> -ctx->nb_attributes =
> -avfc->nb_attributes + need_memory_type + need_pixel_format;
> +if (!(hwctx->driver_quirks & 
> AV_VAAPI_DRIVER_QUIRK_SURFACE_ATTRIBUTES)) {
> +int need_memory_type = !(hwctx->driver_quirks & 
> AV_VAAPI_DRIVER_QUIRK_ATTRIB_MEMTYPE);
> +int need_pixel_format = 1;
> +for (i = 0; i < avfc->nb_attributes; i++) {
> +if (ctx->attributes[i].type == VASurfaceAttribMemoryType)
> +need_memory_type  = 0;
> +if (ctx->attributes[i].type == VASurfaceAttribPixelFormat)
> +need_pixel_format = 0;
> +}
> +ctx->nb_attributes =
> +avfc->nb_attributes + need_memory_type + need_pixel_format;
>  
> -ctx->attributes = av_malloc(ctx->nb_attributes *
> +ctx->attributes = av_malloc(ctx->nb_attributes *
>  sizeof(*ctx->attributes));
> -if (!ctx->attributes) {
> -err = AVERROR(ENOMEM);
> -goto fail;
> -}
> +if (!ctx->attributes) {
> +err = AVERROR(ENOMEM);
> +goto fail;
> +}
>  
> -for (i = 0; i < avfc->nb_attributes; i++)
> -ctx->attributes[i] = avfc->attributes[i];
> -if (need_memory_type) {
> -ctx->attributes[i++] = (VASurfaceAttrib) {
> -.type  = VASurfaceAttribMemoryType,
> -.flags = VA_SURFACE_ATTRIB_SETTABLE,
> -.value.type= VAGenericValueTypeInteger,
> -.value.value.i = VA_SURFACE_ATTRIB_MEM_TYPE_VA,
> -};
> -}
> -if (need_pixel_format) {
> -ctx->attributes[i++] = (VASurfaceAttrib) {
> -.type  = VASurfaceAttribPixelFormat,
> -.flags = VA_SURFACE_ATTRIB_SETTABLE,
> -.value.type= VAGenericValueTypeInteger,
> -.value.value.i = fourcc,
> -};
> +for (i = 0; i < avfc->nb_attributes; i++)
> +ctx->attributes[i] = avfc->attributes[i];
> +if (need_memory_type) {
> +ctx->attributes[i++] = (VASurfaceAttrib) {
> +.type  = VASurfaceAttribMemoryType,
> +.flags = VA_SURFACE_ATTRIB_SETTABLE,
> +.value.type= VAGenericValueTypeInteger,
> +.value.value.i = VA_SURFACE_ATTRIB_MEM_TYPE_VA,
> +};
> +}
> +if (need_pixel_format) {
> +ctx->attributes[i++] = (VASurfaceAttrib) {
> +.type  = VASurfaceAttribPixelFormat,
> +.flags = VA_SURFACE_ATTRIB_SETTABLE,
> + 

Re: [FFmpeg-devel] [PATCH] doc/filters: Correct scale doc regarding w/h <= 0

[Moritz Barsnick]

On Mon, Jun 12, 2017 at 01:59:05 -0400, Kevin Mark wrote:
> Signed-off-by: Kevin Mark 
> ---
>  doc/filters.texi | 39 ---
>  1 file changed, 20 insertions(+), 19 deletions(-)

Yes, this text looks much more sane and easy to understand.

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

Re: [FFmpeg-devel] [PATCH] avcodec/htmlsubtitles: Factor open brace handling into its own function

[wm4]

On Tue, 13 Jun 2017 00:01:04 +0200
Michael Niedermayer  wrote:

> Suggested-by: wm4
> Signed-off-by: Michael Niedermayer 
> ---
>  libavcodec/htmlsubtitles.c | 44 ++--
>  1 file changed, 26 insertions(+), 18 deletions(-)
> 
> diff --git a/libavcodec/htmlsubtitles.c b/libavcodec/htmlsubtitles.c
> index 70311c66d5..be5c9316ca 100644
> --- a/libavcodec/htmlsubtitles.c
> +++ b/libavcodec/htmlsubtitles.c
> @@ -51,6 +51,30 @@ static void rstrip_spaces_buf(AVBPrint *buf)
>  buf->str[--buf->len] = 0;
>  }
>  
> +/* skip all {\xxx} substrings except for {\an%d}
> +   and all microdvd like styles such as {Y:xxx} */
> +static void handle_open_brace(AVBPrint *dst, const char **inp, int *an, int 
> *closing_brace_missing)
> +{
> +int len = 0;
> +const char *in = *inp;
> +
> +*an += sscanf(in, "{\\an%*1u}%n", ) >= 0 && len > 0;
> +
> +if (!*closing_brace_missing) {
> +if (   (*an != 1 && in[1] == '\\')
> +|| (in[1] && strchr("CcFfoPSsYy", in[1]) && in[2] == ':')) {
> +char *bracep = strchr(in+2, '}');
> +if (bracep) {
> +*inp = bracep;
> +return;
> +} else
> +*closing_brace_missing = 1;
> +}
> +}
> +
> +av_bprint_chars(dst, *in, 1);
> +}
> +
>  int ff_htmlmarkup_to_ass(void *log_ctx, AVBPrint *dst, const char *in)
>  {
>  char *param, buffer[128], tmp[128];
> @@ -80,24 +104,8 @@ int ff_htmlmarkup_to_ass(void *log_ctx, AVBPrint *dst, 
> const char *in)
>  if (!line_start)
>  av_bprint_chars(dst, *in, 1);
>  break;
> -case '{':/* skip all {\xxx} substrings except for {\an%d}
> -and all microdvd like styles such as {Y:xxx} */
> -len = 0;
> -an += sscanf(in, "{\\an%*1u}%n", ) >= 0 && len > 0;
> -
> -if (!closing_brace_missing) {
> -if (   (an != 1 && in[1] == '\\')
> -|| (in[1] && strchr("CcFfoPSsYy", in[1]) && in[2] == 
> ':')) {
> -char *bracep = strchr(in+2, '}');
> -if (bracep) {
> -in = bracep;
> -break;
> -} else
> -closing_brace_missing = 1;
> -}
> -}
> -
> -av_bprint_chars(dst, *in, 1);
> +case '{':
> +handle_open_brace(dst, , , _brace_missing);
>  break;
>  case '<':
>  tag_close = in[1] == '/';

Looked at the an thing again (at the old code in git master). It makes
no sense to me - skipping should always behave the same.

Maybe it's actually a bug, or it attempted to emit subsequent an tags
by trying to be overly clever.

In theory, only 1 an tag is ok per line, so "{\an1}{\an2}" the second
an tag would either do nothing, or override the first tag. Maybe
someone thought it'd be reasonable to skip the an second tag, but I
don't see how it matters.

It could also be an attempt to get the same behavior between libass and
VSFitler between redundant an tags (maybe VSFilter uses the value of
the first tag, while libass uses the second tag). Then I'd say this
should be fixed in libass instead.

Anyway, I'd remove that extra an handling. It's a good example of
overly complicated code that makes everything less readable for
absolutely no reason. (Unless I'm overlooking something obvious.)

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

Re: [FFmpeg-devel] [PATCH] Add support for RockChip Media Process Platform

[wm4]

On Tue, 13 Jun 2017 11:17:35 +0100
Mark Thompson  wrote:

> > +vp8_rkmpp_hwaccel_deps="rkmpp"
> >  vp9_d3d11va_hwaccel_deps="d3d11va DXVA_PicParams_VP9"
> >  vp9_d3d11va_hwaccel_select="vp9_decoder"
> >  vp9_dxva2_hwaccel_deps="dxva2 DXVA_PicParams_VP9"  
> 
> Why do these hwaccels exist?  They don't appear to do anything, since you 
> only have hardware surface output anyway.

Well I guess you might have a point - as long as get_format isn't
actually involved, they're technically not needed. And we've apparently
always had hw decoders which can output both sw and hw surfaces, so
this never came up (probably).


I still think there's no harm in adding them.

> > ...
> > diff --git a/libavcodec/drmprime.h b/libavcodec/drmprime.h
> > new file mode 100644
> > index 000..44816db
> > --- /dev/null
> > +++ b/libavcodec/drmprime.h
> > @@ -0,0 +1,17 @@
> > +#ifndef AVCODEC_DRMPRIME_H
> > +#define AVCODEC_DRMPRIME_H
> > +
> > +#include 
> > +
> > +#define AV_DRMPRIME_NUM_PLANES  4   // maximum number of planes
> > +
> > +typedef struct av_drmprime {
> > +
> > +int strides[AV_DRMPRIME_NUM_PLANES];// stride in byte of the 
> > according plane
> > +int offsets[AV_DRMPRIME_NUM_PLANES];// offset from start in byte 
> > of the according plane
> > +int fds[AV_DRMPRIME_NUM_PLANES];// file descriptor for the 
> > plane, (0) if unused.
> > +uint32_t format;// FOURC_CC drm format for the 
> > image
> > +
> > +} av_drmprime;
> > +
> > +#endif // AVCODEC_DRMPRIME_H  
> 
> I'm not sure that a structure like this should be baked into the API/ABI now 
> as a generic thing.  Are you confident that it is sufficient to represent any 
> picture in a DRM object which might be used in future?  (Including things 
> like tiling modes, field splitting, other craziness that GPU makers dream up?)

This includes the DRM FourCC, which should take most craziness into
account. The RockChip decoder itself does something pretty crazy (10
bit _packed_ _planar_ format, wtf?), and it sort of fits in.

I had similar concerns, and I think I basically requested that all
standard eglCreateImageKHR() parameters for this to be included in this
struct (which was done).

It's true though that drivers could invent additional craziness as
additional EGL attributes, or by adding new DRM API calls.

It boils down to how the DRM kernel API handles these things, which I
don't know. (Not like kernel devs would write docs - they'd possibly be
forced to create something consistent!)

Longchair replied with the EGL mapping as use case, but you can also
map it as DRM framebuffer, which appears to happen around here:

https://github.com/LongChair/mpv/blob/rockchip/video/out/opengl/hwdec_drmprime_drm.c#L102

> Can you explain the cases you are using this in?  Are you intending to make 
> other components with input / output in this format?
> 
> With just this decoder in isolation, it would seem preferable to me to make a 
> structure specific to the API for now (or use the existing one - is MppFrame 
> sufficient?).  If later there are multiple implementations and need for a 
> common structure like this then it will be clearer what the requirements are. 
>  Compare VAAPI and QSV (possibly also CUDA, CUVID, VDPAU?) - they can expose 
> DRM objects, but don't currently in the ffmpeg API because any consumers 
> which want them in that form generally prefer the wrapping object including 
> the relevant metadata anyway.

So output those as MppFrames, and then map them as DRM frames? We'd
have the same issues. Also, the API would be harder to use. The
assumption is that native MppFrames are pretty useless anyway, other
than for using them with the MPP decode API.

> Also, zero is a valid file descriptor.

Technically yes, not sure if we care about that case.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

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

[Paul B Mahol]

On 6/13/17, Paras Chadha  wrote:
> Hi,
>
> Any other changes to be made to get this patch applied?
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>

Use this style instead:

switch (X) {
case 0:
then..
break;

Also for long description, use "Flexible Image Transport System"
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] Add support for RockChip Media Process Platform

[LongChair .]

Hello,

The use case for this is mostly on embedded devices that can use drm to display 
video with zerocopy.
Most devices i have played with that can use such implementation will allow to 
create a drm overlay from that drmprime information with drmModeAddFB2:

Here is a sample usage for it 
https://github.com/LongChair/mpv/blob/rockchip/video/out/opengl/hwdec_drmprime_drm.c#L103-L137

Also that allows some other egl / dmabuf implementation :
https://github.com/LongChair/mpv/blob/rockchip/video/out/opengl/hwdec_drmprime_egl.c#L162-L215

The idea behind making this a non rockchip specific hwdec was that on embedded 
devices, most maufacturers are heading towards V4L2 harwadre decoding 
implementations. from what i have seen such v4L2 decoding coudl as well make 
sue of such a format, which would allow to have only one renderer that is hwdec 
agnostic for the rendering part.

Now of course, I am not 100% sure that this would fit all the possible 
implementations, If you feel like this should be rockchip specific, then i'll 
get back to it which was the version 1 of this patch.

Lionel.

Le 13/06/2017 à 12:17, Mark Thompson a écrit :

On 13/06/17 07:21, LongChair . wrote:


From: LongChair 

This adds hardware decoding for h264 / HEVC / VP8 using MPP Rockchip API.
Will return frames holding a av_drmprime struct in buf[3} that allows drm / 
dmabuf usage.
Was tested on RK3288 (TinkerBoard) and RK3328.

Additions from patch v1
 - Change AV_PIX_FMT_RKMPP to AV_PIX_FMT_DRMPRIME as any decoder able to output 
drmprime structures could use that pixel format.
---
 Changelog  |   1 +
 configure  |  12 ++
 libavcodec/Makefile|   5 +
 libavcodec/allcodecs.c |   6 +
 libavcodec/drmprime.h  |  17 ++
 libavcodec/rkmppdec.c  | 523 +
 libavutil/pixdesc.c|   4 +
 libavutil/pixfmt.h |   5 +
 8 files changed, 573 insertions(+)
 create mode 100644 libavcodec/drmprime.h
 create mode 100644 libavcodec/rkmppdec.c

diff --git a/Changelog b/Changelog
index 3533bdc..498e433 100644
--- a/Changelog
+++ b/Changelog
@@ -52,6 +52,7 @@ version 3.3:
 - Removed asyncts filter (use af_aresample instead)
 - Intel QSV-accelerated VP8 video decoding
 - VAAPI-accelerated deinterlacing
+- Addition of Rockchip MPP harware decoding


 version 3.2:
diff --git a/configure b/configure
index 4ec8f21..883fc84 100755
--- a/configure
+++ b/configure
@@ -304,6 +304,7 @@ External library support:
   --disable-nvenc  disable Nvidia video encoding code [autodetect]
   --enable-omx enable OpenMAX IL code [no]
   --enable-omx-rpi enable OpenMAX IL code for Raspberry Pi [no]
+  --enable-rkmpp   enable Rockchip Media Process Platform code [no]
   --disable-vaapi  disable Video Acceleration API (mainly Unix/Intel) 
code [autodetect]
   --disable-vdadisable Apple Video Decode Acceleration code 
[autodetect]
   --disable-vdpau  disable Nvidia Video Decode and Presentation API 
for Unix code [autodetect]
@@ -1607,6 +1608,7 @@ HWACCEL_LIBRARY_LIST="
 libmfx
 mmal
 omx
+rkmpp
 "

 DOCUMENT_LIST="
@@ -2616,6 +2618,7 @@ h264_dxva2_hwaccel_select="h264_decoder"
 h264_mediacodec_hwaccel_deps="mediacodec"
 h264_mmal_hwaccel_deps="mmal"
 h264_qsv_hwaccel_deps="libmfx"
+h264_rkmpp_hwaccel_deps="rkmpp"
 h264_vaapi_hwaccel_deps="vaapi"
 h264_vaapi_hwaccel_select="h264_decoder"
 h264_vda_hwaccel_deps="vda"
@@ -2634,6 +2637,7 @@ hevc_mediacodec_hwaccel_deps="mediacodec"
 hevc_dxva2_hwaccel_deps="dxva2 DXVA_PicParams_HEVC"
 hevc_dxva2_hwaccel_select="hevc_decoder"
 hevc_qsv_hwaccel_deps="libmfx"
+hevc_rkmpp_hwaccel_deps="rkmpp"
 hevc_vaapi_hwaccel_deps="vaapi VAPictureParameterBufferHEVC"
 hevc_vaapi_hwaccel_select="hevc_decoder"
 hevc_vdpau_hwaccel_deps="vdpau VdpPictureInfoHEVC"
@@ -2696,6 +2700,7 @@ vp9_cuvid_hwaccel_deps="cuda cuvid"
 vp9_cuvid_hwaccel_select="vp9_cuvid_decoder"
 vp8_mediacodec_hwaccel_deps="mediacodec"
 vp8_qsv_hwaccel_deps="libmfx"
+vp8_rkmpp_hwaccel_deps="rkmpp"
 vp9_d3d11va_hwaccel_deps="d3d11va DXVA_PicParams_VP9"
 vp9_d3d11va_hwaccel_select="vp9_decoder"
 vp9_dxva2_hwaccel_deps="dxva2 DXVA_PicParams_VP9"



Why do these hwaccels exist?  They don't appear to do anything, since you only 
have hardware surface output anyway.



...
diff --git a/libavcodec/drmprime.h b/libavcodec/drmprime.h
new file mode 100644
index 000..44816db
--- /dev/null
+++ b/libavcodec/drmprime.h
@@ -0,0 +1,17 @@
+#ifndef AVCODEC_DRMPRIME_H
+#define AVCODEC_DRMPRIME_H
+
+#include 
+
+#define AV_DRMPRIME_NUM_PLANES  4   // maximum number of planes
+
+typedef struct av_drmprime {
+
+int strides[AV_DRMPRIME_NUM_PLANES];// stride in byte of the according 
plane
+int offsets[AV_DRMPRIME_NUM_PLANES];// offset from start in byte of 
the according plane
+int fds[AV_DRMPRIME_NUM_PLANES];// file descriptor for the plane, 
(0) if unused.
+

Re: [FFmpeg-devel] [PATCH] Add support for RockChip Media Process Platform

[Mark Thompson]

On 13/06/17 07:21, LongChair . wrote:
> From: LongChair 
> 
> This adds hardware decoding for h264 / HEVC / VP8 using MPP Rockchip API.
> Will return frames holding a av_drmprime struct in buf[3} that allows drm / 
> dmabuf usage.
> Was tested on RK3288 (TinkerBoard) and RK3328.
> 
> Additions from patch v1
>  - Change AV_PIX_FMT_RKMPP to AV_PIX_FMT_DRMPRIME as any decoder able to 
> output drmprime structures could use that pixel format.
> ---
>  Changelog  |   1 +
>  configure  |  12 ++
>  libavcodec/Makefile|   5 +
>  libavcodec/allcodecs.c |   6 +
>  libavcodec/drmprime.h  |  17 ++
>  libavcodec/rkmppdec.c  | 523 
> +
>  libavutil/pixdesc.c|   4 +
>  libavutil/pixfmt.h |   5 +
>  8 files changed, 573 insertions(+)
>  create mode 100644 libavcodec/drmprime.h
>  create mode 100644 libavcodec/rkmppdec.c
> 
> diff --git a/Changelog b/Changelog
> index 3533bdc..498e433 100644
> --- a/Changelog
> +++ b/Changelog
> @@ -52,6 +52,7 @@ version 3.3:
>  - Removed asyncts filter (use af_aresample instead)
>  - Intel QSV-accelerated VP8 video decoding
>  - VAAPI-accelerated deinterlacing
> +- Addition of Rockchip MPP harware decoding
>  
>  
>  version 3.2:
> diff --git a/configure b/configure
> index 4ec8f21..883fc84 100755
> --- a/configure
> +++ b/configure
> @@ -304,6 +304,7 @@ External library support:
>--disable-nvenc  disable Nvidia video encoding code [autodetect]
>--enable-omx enable OpenMAX IL code [no]
>--enable-omx-rpi enable OpenMAX IL code for Raspberry Pi [no]
> +  --enable-rkmpp   enable Rockchip Media Process Platform code [no]
>--disable-vaapi  disable Video Acceleration API (mainly 
> Unix/Intel) code [autodetect]
>--disable-vdadisable Apple Video Decode Acceleration code 
> [autodetect]
>--disable-vdpau  disable Nvidia Video Decode and Presentation API 
> for Unix code [autodetect]
> @@ -1607,6 +1608,7 @@ HWACCEL_LIBRARY_LIST="
>  libmfx
>  mmal
>  omx
> +rkmpp
>  "
>  
>  DOCUMENT_LIST="
> @@ -2616,6 +2618,7 @@ h264_dxva2_hwaccel_select="h264_decoder"
>  h264_mediacodec_hwaccel_deps="mediacodec"
>  h264_mmal_hwaccel_deps="mmal"
>  h264_qsv_hwaccel_deps="libmfx"
> +h264_rkmpp_hwaccel_deps="rkmpp"
>  h264_vaapi_hwaccel_deps="vaapi"
>  h264_vaapi_hwaccel_select="h264_decoder"
>  h264_vda_hwaccel_deps="vda"
> @@ -2634,6 +2637,7 @@ hevc_mediacodec_hwaccel_deps="mediacodec"
>  hevc_dxva2_hwaccel_deps="dxva2 DXVA_PicParams_HEVC"
>  hevc_dxva2_hwaccel_select="hevc_decoder"
>  hevc_qsv_hwaccel_deps="libmfx"
> +hevc_rkmpp_hwaccel_deps="rkmpp"
>  hevc_vaapi_hwaccel_deps="vaapi VAPictureParameterBufferHEVC"
>  hevc_vaapi_hwaccel_select="hevc_decoder"
>  hevc_vdpau_hwaccel_deps="vdpau VdpPictureInfoHEVC"
> @@ -2696,6 +2700,7 @@ vp9_cuvid_hwaccel_deps="cuda cuvid"
>  vp9_cuvid_hwaccel_select="vp9_cuvid_decoder"
>  vp8_mediacodec_hwaccel_deps="mediacodec"
>  vp8_qsv_hwaccel_deps="libmfx"
> +vp8_rkmpp_hwaccel_deps="rkmpp"
>  vp9_d3d11va_hwaccel_deps="d3d11va DXVA_PicParams_VP9"
>  vp9_d3d11va_hwaccel_select="vp9_decoder"
>  vp9_dxva2_hwaccel_deps="dxva2 DXVA_PicParams_VP9"

Why do these hwaccels exist?  They don't appear to do anything, since you only 
have hardware surface output anyway.

> ...
> diff --git a/libavcodec/drmprime.h b/libavcodec/drmprime.h
> new file mode 100644
> index 000..44816db
> --- /dev/null
> +++ b/libavcodec/drmprime.h
> @@ -0,0 +1,17 @@
> +#ifndef AVCODEC_DRMPRIME_H
> +#define AVCODEC_DRMPRIME_H
> +
> +#include 
> +
> +#define AV_DRMPRIME_NUM_PLANES  4   // maximum number of planes
> +
> +typedef struct av_drmprime {
> +
> +int strides[AV_DRMPRIME_NUM_PLANES];// stride in byte of the 
> according plane
> +int offsets[AV_DRMPRIME_NUM_PLANES];// offset from start in byte of 
> the according plane
> +int fds[AV_DRMPRIME_NUM_PLANES];// file descriptor for the 
> plane, (0) if unused.
> +uint32_t format;// FOURC_CC drm format for the 
> image
> +
> +} av_drmprime;
> +
> +#endif // AVCODEC_DRMPRIME_H

I'm not sure that a structure like this should be baked into the API/ABI now as 
a generic thing.  Are you confident that it is sufficient to represent any 
picture in a DRM object which might be used in future?  (Including things like 
tiling modes, field splitting, other craziness that GPU makers dream up?)

Can you explain the cases you are using this in?  Are you intending to make 
other components with input / output in this format?

With just this decoder in isolation, it would seem preferable to me to make a 
structure specific to the API for now (or use the existing one - is MppFrame 
sufficient?).  If later there are multiple implementations and need for a 
common structure like this then it will be clearer what the requirements are.  
Compare VAAPI and QSV (possibly also CUDA, CUVID, VDPAU?) - they can expose DRM 

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

[Paras Chadha]

Hi,

Any other changes to be made to get this patch applied?
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH] Add support for RockChip Media Process Platform

[LongChair .]

From: LongChair 

This adds hardware decoding for h264 / HEVC / VP8 using MPP Rockchip API.
Will return frames holding a av_drmprime struct in buf[3} that allows drm / 
dmabuf usage.
Was tested on RK3288 (TinkerBoard) and RK3328.

Additions from patch v1
 - Change AV_PIX_FMT_RKMPP to AV_PIX_FMT_DRMPRIME as any decoder able to output 
drmprime structures could use that pixel format.
---
 Changelog  |   1 +
 configure  |  12 ++
 libavcodec/Makefile|   5 +
 libavcodec/allcodecs.c |   6 +
 libavcodec/drmprime.h  |  17 ++
 libavcodec/rkmppdec.c  | 523 +
 libavutil/pixdesc.c|   4 +
 libavutil/pixfmt.h |   5 +
 8 files changed, 573 insertions(+)
 create mode 100644 libavcodec/drmprime.h
 create mode 100644 libavcodec/rkmppdec.c

diff --git a/Changelog b/Changelog
index 3533bdc..498e433 100644
--- a/Changelog
+++ b/Changelog
@@ -52,6 +52,7 @@ version 3.3:
 - Removed asyncts filter (use af_aresample instead)
 - Intel QSV-accelerated VP8 video decoding
 - VAAPI-accelerated deinterlacing
+- Addition of Rockchip MPP harware decoding
 
 
 version 3.2:
diff --git a/configure b/configure
index 4ec8f21..883fc84 100755
--- a/configure
+++ b/configure
@@ -304,6 +304,7 @@ External library support:
   --disable-nvenc  disable Nvidia video encoding code [autodetect]
   --enable-omx enable OpenMAX IL code [no]
   --enable-omx-rpi enable OpenMAX IL code for Raspberry Pi [no]
+  --enable-rkmpp   enable Rockchip Media Process Platform code [no]
   --disable-vaapi  disable Video Acceleration API (mainly Unix/Intel) 
code [autodetect]
   --disable-vdadisable Apple Video Decode Acceleration code 
[autodetect]
   --disable-vdpau  disable Nvidia Video Decode and Presentation API 
for Unix code [autodetect]
@@ -1607,6 +1608,7 @@ HWACCEL_LIBRARY_LIST="
 libmfx
 mmal
 omx
+rkmpp
 "
 
 DOCUMENT_LIST="
@@ -2616,6 +2618,7 @@ h264_dxva2_hwaccel_select="h264_decoder"
 h264_mediacodec_hwaccel_deps="mediacodec"
 h264_mmal_hwaccel_deps="mmal"
 h264_qsv_hwaccel_deps="libmfx"
+h264_rkmpp_hwaccel_deps="rkmpp"
 h264_vaapi_hwaccel_deps="vaapi"
 h264_vaapi_hwaccel_select="h264_decoder"
 h264_vda_hwaccel_deps="vda"
@@ -2634,6 +2637,7 @@ hevc_mediacodec_hwaccel_deps="mediacodec"
 hevc_dxva2_hwaccel_deps="dxva2 DXVA_PicParams_HEVC"
 hevc_dxva2_hwaccel_select="hevc_decoder"
 hevc_qsv_hwaccel_deps="libmfx"
+hevc_rkmpp_hwaccel_deps="rkmpp"
 hevc_vaapi_hwaccel_deps="vaapi VAPictureParameterBufferHEVC"
 hevc_vaapi_hwaccel_select="hevc_decoder"
 hevc_vdpau_hwaccel_deps="vdpau VdpPictureInfoHEVC"
@@ -2696,6 +2700,7 @@ vp9_cuvid_hwaccel_deps="cuda cuvid"
 vp9_cuvid_hwaccel_select="vp9_cuvid_decoder"
 vp8_mediacodec_hwaccel_deps="mediacodec"
 vp8_qsv_hwaccel_deps="libmfx"
+vp8_rkmpp_hwaccel_deps="rkmpp"
 vp9_d3d11va_hwaccel_deps="d3d11va DXVA_PicParams_VP9"
 vp9_d3d11va_hwaccel_select="vp9_decoder"
 vp9_dxva2_hwaccel_deps="dxva2 DXVA_PicParams_VP9"
@@ -2736,6 +2741,8 @@ h264_qsv_decoder_deps="libmfx"
 h264_qsv_decoder_select="h264_mp4toannexb_bsf h264_parser qsvdec 
h264_qsv_hwaccel"
 h264_qsv_encoder_deps="libmfx"
 h264_qsv_encoder_select="qsvenc"
+h264_rkmpp_decoder_deps="rkmpp"
+h264_rkmpp_decoder_select="h264_mp4toannexb_bsf rkmpp h264_rkmpp_hwaccel"
 h264_vaapi_encoder_deps="VAEncPictureParameterBufferH264"
 h264_vaapi_encoder_select="vaapi_encode golomb"
 h264_vda_decoder_deps="vda"
@@ -2751,6 +2758,8 @@ hevc_qsv_decoder_deps="libmfx"
 hevc_qsv_decoder_select="hevc_mp4toannexb_bsf hevc_parser qsvdec 
hevc_qsv_hwaccel"
 hevc_qsv_encoder_deps="libmfx"
 hevc_qsv_encoder_select="hevcparse qsvenc"
+hevc_rkmpp_decoder_deps="rkmpp"
+hevc_rkmpp_decoder_select="hevc_mp4toannexb_bsf rkmpp hevc_rkmpp_hwaccel"
 hevc_vaapi_encoder_deps="VAEncPictureParameterBufferHEVC"
 hevc_vaapi_encoder_select="vaapi_encode golomb"
 mjpeg_cuvid_decoder_deps="cuda cuvid"
@@ -2789,6 +2798,8 @@ vp8_cuvid_decoder_deps="cuda cuvid"
 vp8_mediacodec_decoder_deps="mediacodec"
 vp8_qsv_decoder_deps="libmfx"
 vp8_qsv_decoder_select="qsvdec vp8_qsv_hwaccel vp8_parser"
+vp8_rkmpp_decoder_deps="rkmpp"
+vp8_rkmpp_decoder_select="rkmpp vp8_rkmpp_hwaccel"
 vp8_vaapi_encoder_deps="VAEncPictureParameterBufferVP8"
 vp8_vaapi_encoder_select="vaapi_encode"
 vp9_cuvid_decoder_deps="cuda cuvid"
@@ -5917,6 +5928,7 @@ enabled mmal  && { check_lib mmal 
interface/mmal/mmal.h mmal_port_co
  check_lib mmal interface/mmal/mmal.h 
mmal_port_connect -lmmal_core -lmmal_util -lmmal_vc_client -lbcm_host; } ||
die "ERROR: mmal not found" &&
check_func_headers interface/mmal/mmal.h 
"MMAL_PARAMETER_VIDEO_MAX_NUM_CALLBACKS"; }
+enabled rkmpp && { check_lib rkmpp rockchip/rk_mpi.h mpp_create 
"-lrockchip_mpp" || die "ERROR : Rockchip MPP was not found."; }
 enabled netcdf&& require_pkg_config netcdf netcdf.h