Re: [FFmpeg-devel] [PATCH] ffmpeg options: Enable trailing ? for map_channel

[Kv Pham]

Ah sorry about that. I forgot about the tabs.
Will correct and add update to doc.
Thanks


Le 24 août 2017 2:32 AM, "Michael Niedermayer"  a
écrit :

> On Wed, Aug 23, 2017 at 06:48:14PM +0200, pkv.stream wrote:
> > Hello,
> >
> > the following patch allows one to add a trailing ? to -map_channel
> > as in -map option.
> >
> > E.g: -map_channel 0.0.2? so that if the channel does not exist, the
> > command does not stop.
> >
> > This is similar to what one can do with -map.
> >
> > Thanks for any input.
> >
> >
>
> >  ffmpeg_opt.c |   24 
> >  1 file changed, 20 insertions(+), 4 deletions(-)
> > 28689933986d73050286e700752ace032df6dc1b  0001-ffmpeg-options-Enable-
> trailing-for-map_channel.patch
> > From 07959dfe79816d03c30b8027f45b41d60078b3fa Mon Sep 17 00:00:00 2001
> > From: pkviet 
> > Date: Tue, 22 Aug 2017 11:30:45 +0200
> > Subject: [PATCH] ffmpeg options: Enable trailing ? for map_channel
> >
> > The -map option allows for a trailing ? so that an error is not thrown if
> > the input stream does not exist.
> > This capability is extended to the map_channel option.
> > This allows a ffmpeg command not to break if an input channel does not
> > exist, which can be of use (for instance, scripts processing audio
> > channels with sources having unset number of audio channels).
> > ---
> >  ffmpeg_opt.c | 24 
> >  1 file changed, 20 insertions(+), 4 deletions(-)
>
> the patch contains tabs (cannot be pushed to git master)
> and this is missing an update to the documentation
>
> [...]
>
> --
> Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
>
> Elect your leaders based on what they did after the last election, not
> based on what they say before an election.
>
>
> ___
> 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] avfilter: Add vmaf filter

[Ashish Pratap Singh]

On Aug 24, 2017 05:13, "Michael Niedermayer"  wrote:

On Thu, Aug 24, 2017 at 12:58:53AM +0530, Ashish Pratap Singh wrote:
> From: Ashish Singh 
>
> Hi, this is vmaf filter. It fuses the scores of previous metrics adm,
motion and vif
> using svm algorithm. It's different from libvmaf filter because it has a
very little
> external dependency (only one svm model file).
> Currently it supports only one model which can be extended later for
other models.
> I have added the model file inside libavfilter/data/ so that it can run
successfully.
> There is still a bit of work left to do like changing each filter from
float
> to integer. It's in progress along with SIMD optimizations.
>
> Signed-off-by: Ashish Singh 
> ---
>  Changelog  |   1 +
>  doc/filters.texi   |  38 ++
>  libavfilter/Makefile   |   1 +
>  libavfilter/allfilters.c   |   1 +
>  libavfilter/data/vmaf_v0.6.1.pkl.model | 218 
>  libavfilter/vf_vmaf.c  | 945
+
>  libavfilter/vmaf.h | 138 +
>  7 files changed, 1342 insertions(+)
>  create mode 100644 libavfilter/data/vmaf_v0.6.1.pkl.model
>  create mode 100644 libavfilter/vf_vmaf.c
>  create mode 100644 libavfilter/vmaf.h

fails to build

CC  libavfilter/vf_vmaf.o
libavfilter/vf_vmaf.c:36:17: fatal error: adm.h: No such file or directory
 #include "adm.h"
 ^
compilation terminated.
make: *** [libavfilter/vf_vmaf.o] Error 1
make: Target `all' not remade because of errors.




[...]


Hi, it requires adm, vmafmotion and vif filters (earlier patches) to be
applied first.

--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

What does censorship reveal? It reveals fear. -- Julian Assange

___
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 V6] lavfi/scale_vaapi: add denoise/sharpness support.

[Jun Zhao]

ping?

On 2017/8/4 15:25, Jun Zhao wrote:
> V6 : - Re-work with current scale_vaapi and double check i965 have fix the 
> sharpness issue.
>https://bugs.freedesktop.org/show_bug.cgi?id=96988
> v5 : - fix the commit message as review(Mark Thompson and Moritz Barsnick)
>  - change the magic filter numbers 8 with VAProcFilterCount
>  - check multiple filters because multiple filters aren't supported in
>the driver now
> v4 : - fix sharpless typo(sharpless -> sharpness)
>  - when don't support denoise/sharpness, report the error and return
>  - fix denoise/sharpness params buffer leak in error handle
> v3 : fix sharpless mapping issue
> v2 : fix filter support flag check logic issue

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

[FFmpeg-devel] [V5 2/4] lavc/vaapi_encode: Add max slices number query.

[Jun Zhao]

From 4cac77cf990e91fececaf3dc5bffe606fcdae17c Mon Sep 17 00:00:00 2001
From: Jun Zhao 
Date: Tue, 1 Aug 2017 04:16:30 -0400
Subject: [V5 2/4] lavc/vaapi_encode: Add max slices number query.

Add max slices number query.

Signed-off-by: Jun Zhao 
---
 libavcodec/vaapi_encode.c | 4 
 libavcodec/vaapi_encode.h | 4 
 2 files changed, 8 insertions(+)

diff --git a/libavcodec/vaapi_encode.c b/libavcodec/vaapi_encode.c
index f49e0e3b91..011aedd9d9 100644
--- a/libavcodec/vaapi_encode.c
+++ b/libavcodec/vaapi_encode.c
@@ -971,6 +971,7 @@ static av_cold int 
vaapi_encode_config_attributes(AVCodecContext *avctx)
 { VAConfigAttribRTFormat },
 { VAConfigAttribRateControl  },
 { VAConfigAttribEncMaxRefFrames  },
+{ VAConfigAttribEncMaxSlices },
 { VAConfigAttribEncPackedHeaders },
 };
 
@@ -1101,6 +1102,9 @@ static av_cold int 
vaapi_encode_config_attributes(AVCodecContext *avctx)
 }
 }
 break;
+case VAConfigAttribEncMaxSlices:
+ctx->max_slices = attr[i].value;
+break;
 case VAConfigAttribEncPackedHeaders:
 if (ctx->va_packed_headers & ~attr[i].value) {
 // This isn't fatal, but packed headers are always
diff --git a/libavcodec/vaapi_encode.h b/libavcodec/vaapi_encode.h
index 364b5b8028..dafbbf5045 100644
--- a/libavcodec/vaapi_encode.h
+++ b/libavcodec/vaapi_encode.h
@@ -164,6 +164,10 @@ typedef struct VAAPIEncodeContext {
 } quality_params;
 #endif
 
+// Supported max-slices number per frame. (0 means driver cannot
+// support max mutil-slices query)
+int max_slices;
+
 // Per-sequence parameter structure (VAEncSequenceParameterBuffer*).
 void   *codec_sequence_params;
 
-- 
2.11.0

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

[FFmpeg-devel] [V5 3/4] lavc/vaapi_encode_h264: respect "slices" option in h264 vaapi encoder

[Jun Zhao]

From 8795c55762da131ae29554290c1c352eab092580 Mon Sep 17 00:00:00 2001
From: Jun Zhao 
Date: Tue, 1 Aug 2017 23:05:44 -0400
Subject: [V5 3/4] lavc/vaapi_encode_h264: respect "slices" option in h264
 vaapi encoder

Enable multi-slice support in AVC/H.264 vaapi encoder.

Signed-off-by: Wang, Yi A 
Signed-off-by: Jun Zhao 
---
 libavcodec/vaapi_encode_h264.c | 32 +++-
 1 file changed, 27 insertions(+), 5 deletions(-)

diff --git a/libavcodec/vaapi_encode_h264.c b/libavcodec/vaapi_encode_h264.c
index 90c7f7e3cc..4a9531bb13 100644
--- a/libavcodec/vaapi_encode_h264.c
+++ b/libavcodec/vaapi_encode_h264.c
@@ -141,6 +141,8 @@ typedef struct VAAPIEncodeH264Context {
 int mb_width;
 int mb_height;
 
+int last_mb_index;
+
 int fixed_qp_idr;
 int fixed_qp_p;
 int fixed_qp_b;
@@ -953,6 +955,7 @@ static int 
vaapi_encode_h264_init_picture_params(AVCodecContext *avctx,
 VAEncPictureParameterBufferH264  *vpic = pic->codec_picture_params;
 VAAPIEncodeH264Context   *priv = ctx->priv_data;
 int i;
+int slices;
 
 if (pic->type == PICTURE_TYPE_IDR) {
 av_assert0(pic->display_order == pic->encode_order);
@@ -998,7 +1001,19 @@ static int 
vaapi_encode_h264_init_picture_params(AVCodecContext *avctx,
 vpic->pic_fields.bits.idr_pic_flag = (pic->type == PICTURE_TYPE_IDR);
 vpic->pic_fields.bits.reference_pic_flag = (pic->type != PICTURE_TYPE_B);
 
-pic->nb_slices = 1;
+slices = 1;
+if (ctx->max_slices) {
+if (avctx->slices <= ctx->max_slices) {
+slices = avctx->slices;
+} else {
+av_log(avctx, AV_LOG_ERROR, "The max slices number per frame "
+   "cannot more than %d.\n", ctx->max_slices);
+return AVERROR_INVALIDDATA;
+}
+}
+pic->nb_slices = slices;
+
+priv->last_mb_index = 0;
 
 return 0;
 }
@@ -1048,14 +1063,17 @@ static int 
vaapi_encode_h264_init_slice_params(AVCodecContext *avctx,
 av_assert0(0 && "invalid picture type");
 }
 
-// Only one slice per frame.
-vslice->macroblock_address = 0;
-vslice->num_macroblocks = priv->mb_width * priv->mb_height;
+vslice->macroblock_address = priv->last_mb_index;
+vslice->num_macroblocks =
+((slice->index + 1) * priv->mb_width * priv->mb_height) / 
pic->nb_slices - priv->last_mb_index;
+priv->last_mb_index += vslice->num_macroblocks;
 
 vslice->macroblock_info = VA_INVALID_ID;
 
 vslice->pic_parameter_set_id = vpic->pic_parameter_set_id;
-vslice->idr_pic_id = priv->idr_pic_count++;
+vslice->idr_pic_id = priv->idr_pic_count;
+if (priv->last_mb_index == priv->mb_width * priv->mb_height)
+priv->idr_pic_count++;
 
 vslice->pic_order_cnt_lsb = (pic->display_order - priv->last_idr_frame) &
 ((1 << (4 + vseq->seq_fields.bits.log2_max_pic_order_cnt_lsb_minus4)) 
- 1);
@@ -1140,6 +1158,10 @@ static av_cold int 
vaapi_encode_h264_configure(AVCodecContext *avctx)
 if (avctx->compression_level == FF_COMPRESSION_DEFAULT)
 avctx->compression_level = opt->quality;
 
+if (!ctx->max_slices && avctx->slices > 0)
+av_log(avctx, AV_LOG_WARNING, "The encode slice option is not "
+   "supported with the driver.\n");
+
 return 0;
 }
 
-- 
2.11.0

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

[FFmpeg-devel] [V5 1/4] lavc/vaapi_encode: Change the slice/parameter buffers to dynamic alloc.

[Jun Zhao]

V5: - In h265_vaapi encoder, when setting slice number > max slice number
  supported by driver, report error and return. Same as h264_vaapi.
    - Clean the logic when setting first_slice_segment_in_pic_flags  
V4: - Change the array malloc function.
    - Clean the pointless condition check when free the memory.

V3: - Making pic->slices be VAAPIEncodeSlice* instead of
VAAPIEncodeSlice**. - Fix resource (vaBuffer) lead when realloc
pic->param_buffers fail. - Adjust max_slices location in
VAAPIEncodeContext. - Re-work distributing the macro-blocks for
multi-slices function. V2: - Change the slice/parameter buffers to
dynamic alloc and split the mutil-slice support for AVC/HEVC.


From a1078385915d53ec94559ed897eb253e537d1f65 Mon Sep 17 00:00:00 2001
From: Jun Zhao 
Date: Mon, 31 Jul 2017 22:46:23 -0400
Subject: [V5 1/4] lavc/vaapi_encode: Change the slice/parameter buffers to
 dynamic alloc.

Change the slice/parameter buffers to be allocated dynamically.

Signed-off-by: Wang, Yi A 
Signed-off-by: Jun Zhao 
---
 libavcodec/vaapi_encode.c | 44 
 libavcodec/vaapi_encode.h |  6 ++
 2 files changed, 34 insertions(+), 16 deletions(-)

diff --git a/libavcodec/vaapi_encode.c b/libavcodec/vaapi_encode.c
index 22114bedbe..f49e0e3b91 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);
+}
+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);
+}
+pic->param_buffers = tmp;
 
 vas = vaCreateBuffer(ctx->hwctx->display, ctx->va_context,
  type, len, 1, data, );
@@ -313,15 +323,14 @@ static int vaapi_encode_issue(AVCodecContext *avctx,
 }
 }
 
-av_assert0(pic->nb_slices <= MAX_PICTURE_SLICES);
+pic->slices = av_mallocz_array(pic->nb_slices, sizeof(*pic->slices));
+if (!pic->slices) {
+err = AVERROR(ENOMEM);
+goto fail;
+}
 for (i = 0; i < pic->nb_slices; i++) {
-slice = av_mallocz(sizeof(*slice));
-if (!slice) {
-err = AVERROR(ENOMEM);
-goto fail;
-}
+slice = >slices[i];
 slice->index = i;
-pic->slices[i] = slice;
 
 if (ctx->codec->slice_params_size > 0) {
 slice->codec_slice_params = 
av_mallocz(ctx->codec->slice_params_size);
@@ -425,8 +434,16 @@ fail_with_picture:
 fail:
 for(i = 0; i < pic->nb_param_buffers; i++)
 vaDestroyBuffer(ctx->hwctx->display, pic->param_buffers[i]);
+for (i = 0; i < pic->nb_slices; i++) {
+if (pic->slices) {
+av_freep(>slices[i].priv_data);
+av_freep(>slices[i].codec_slice_params);
+}
+}
 fail_at_end:
 av_freep(>codec_picture_params);
+av_freep(>param_buffers);
+av_freep(>slices);
 av_frame_free(>recon_image);
 av_buffer_unref(>output_buffer_ref);
 pic->output_buffer = VA_INVALID_ID;
@@ -535,15 +552,18 @@ static int vaapi_encode_free(AVCodecContext *avctx,
 vaapi_encode_discard(avctx, pic);
 
 for (i = 0; i < pic->nb_slices; i++) {
-av_freep(>slices[i]->priv_data);
-av_freep(>slices[i]->codec_slice_params);
-av_freep(>slices[i]);
+if (pic->slices) {
+av_freep(>slices[i].priv_data);
+av_freep(>slices[i].codec_slice_params);
+}
 }
 av_freep(>codec_picture_params);
 
 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);
 
diff --git a/libavcodec/vaapi_encode.h b/libavcodec/vaapi_encode.h
index 3bf0cc87c7..364b5b8028 100644
--- a/libavcodec/vaapi_encode.h
+++ b/libavcodec/vaapi_encode.h
@@ -35,8 +35,6 @@ enum {
 MAX_CONFIG_ATTRIBUTES  = 4,
 MAX_GLOBAL_PARAMS  = 4,
 

[FFmpeg-devel] [V5 4/4] lavc/vaapi_encode_h265: respect "slices" option in h265 vaapi encoder

[Jun Zhao]

From 9baf5d8b4b2a6119a8406bb52a05d4a1b67f9a3e Mon Sep 17 00:00:00 2001
From: Jun Zhao 
Date: Tue, 1 Aug 2017 23:07:34 -0400
Subject: [V5 4/4] lavc/vaapi_encode_h265: respect "slices" option in h265
 vaapi encoder

Enable multi-slice support in AVC/H.265 vaapi encoder.

Signed-off-by: Wang, Yi A 
Signed-off-by: Jun Zhao 
---
 libavcodec/vaapi_encode_h265.c | 34 --
 1 file changed, 28 insertions(+), 6 deletions(-)

diff --git a/libavcodec/vaapi_encode_h265.c b/libavcodec/vaapi_encode_h265.c
index cf6b9388d1..a845b58094 100644
--- a/libavcodec/vaapi_encode_h265.c
+++ b/libavcodec/vaapi_encode_h265.c
@@ -176,6 +176,8 @@ typedef struct VAAPIEncodeH265Context {
 unsigned int ctu_width;
 unsigned int ctu_height;
 
+int last_ctu_index;
+
 int fixed_qp_idr;
 int fixed_qp_p;
 int fixed_qp_b;
@@ -962,6 +964,7 @@ static int 
vaapi_encode_h265_init_picture_params(AVCodecContext *avctx,
 VAEncPictureParameterBufferHEVC *vpic = pic->codec_picture_params;
 VAAPIEncodeH265Context  *priv = ctx->priv_data;
 int i;
+int slices;
 
 if (pic->type == PICTURE_TYPE_IDR) {
 av_assert0(pic->display_order == pic->encode_order);
@@ -1024,7 +1027,19 @@ static int 
vaapi_encode_h265_init_picture_params(AVCodecContext *avctx,
 av_assert0(0 && "invalid picture type");
 }
 
-pic->nb_slices = 1;
+slices = 1;
+if (ctx->max_slices) {
+if (avctx->slices <= ctx->max_slices) {
+slices = avctx->slices;
+} else {
+av_log(avctx, AV_LOG_ERROR, "The max slices number per frame "
+   "cannot more than %d.\n", ctx->max_slices);
+return AVERROR_INVALIDDATA;
+}
+}
+pic->nb_slices = slices;
+
+priv->last_ctu_index = 0;
 
 return 0;
 }
@@ -1047,9 +1062,10 @@ static int 
vaapi_encode_h265_init_slice_params(AVCodecContext *avctx,
 pslice = slice->priv_data;
 mslice = >misc_slice_params;
 
-// Currently we only support one slice per frame.
-vslice->slice_segment_address = 0;
-vslice->num_ctu_in_slice = priv->ctu_width * priv->ctu_height;
+vslice->slice_segment_address = priv->last_ctu_index;
+vslice->num_ctu_in_slice =
+((slice->index + 1) * priv->ctu_width * priv->ctu_height) / 
pic->nb_slices - priv->last_ctu_index;
+priv->last_ctu_index += vslice->num_ctu_in_slice;
 
 switch (pic->type) {
 case PICTURE_TYPE_IDR:
@@ -1103,9 +1119,11 @@ static int 
vaapi_encode_h265_init_slice_params(AVCodecContext *avctx,
 else
 vslice->slice_qp_delta = priv->fixed_qp_idr - vpic->pic_init_qp;
 
-vslice->slice_fields.bits.last_slice_of_pic_flag = 1;
+if (priv->last_ctu_index == priv->ctu_width * priv->ctu_height)
+vslice->slice_fields.bits.last_slice_of_pic_flag = 1;
 
-mslice->first_slice_segment_in_pic_flag = 1;
+mslice->first_slice_segment_in_pic_flag =
+!!(vslice->slice_segment_address == 0);
 
 if (pic->type == PICTURE_TYPE_IDR) {
 // No reference pictures.
@@ -1198,6 +1216,10 @@ static av_cold int 
vaapi_encode_h265_configure(AVCodecContext *avctx)
 av_assert0(0 && "Invalid RC mode.");
 }
 
+if (!ctx->max_slices && avctx->slices > 0)
+av_log(avctx, AV_LOG_WARNING, "The encode slice option is not "
+   "supported with the driver.\n");
+
 return 0;
 }
 
-- 
2.11.0

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

Re: [FFmpeg-devel] [PATCH] ffmpeg options: Enable trailing ? for map_channel

[Michael Niedermayer]

On Wed, Aug 23, 2017 at 06:48:14PM +0200, pkv.stream wrote:
> Hello,
> 
> the following patch allows one to add a trailing ? to -map_channel
> as in -map option.
> 
> E.g: -map_channel 0.0.2? so that if the channel does not exist, the
> command does not stop.
> 
> This is similar to what one can do with -map.
> 
> Thanks for any input.
> 
> 

>  ffmpeg_opt.c |   24 
>  1 file changed, 20 insertions(+), 4 deletions(-)
> 28689933986d73050286e700752ace032df6dc1b  
> 0001-ffmpeg-options-Enable-trailing-for-map_channel.patch
> From 07959dfe79816d03c30b8027f45b41d60078b3fa Mon Sep 17 00:00:00 2001
> From: pkviet 
> Date: Tue, 22 Aug 2017 11:30:45 +0200
> Subject: [PATCH] ffmpeg options: Enable trailing ? for map_channel
> 
> The -map option allows for a trailing ? so that an error is not thrown if
> the input stream does not exist.
> This capability is extended to the map_channel option.
> This allows a ffmpeg command not to break if an input channel does not
> exist, which can be of use (for instance, scripts processing audio
> channels with sources having unset number of audio channels).
> ---
>  ffmpeg_opt.c | 24 
>  1 file changed, 20 insertions(+), 4 deletions(-)

the patch contains tabs (cannot be pushed to git master)
and this is missing an update to the documentation

[...]

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

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



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

Re: [FFmpeg-devel] [PATCH]lsws/rgb2rgb: Add unscaled 48 to 64bit conversion

[Michael Niedermayer]

On Wed, Aug 23, 2017 at 02:21:40PM +0200, Carl Eugen Hoyos wrote:
> Hi!
> 

> Attached patch fixes ticket #6608.

iam not sure thats the correct fix for the ticket but the patch is a
good idea none the less
thus LGTM


[...]

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

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



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

Re: [FFmpeg-devel] [PATCH] mjpeg: Add support for ICC side data

[Michael Niedermayer]

On Wed, Aug 23, 2017 at 05:12:34PM +0100, Derek Buitenhuis wrote:
> JPEGs store embedded profiles under the APP2 marker, signified
> with a "ICC_PROFILE" null-terminated string header, and can be
> split across multiple APP2 markers, out of order.
> 
> This patch currently assumes one single ICC profile for the
> whole context, i.e. a single JPEG input file. This likely does
> not work for MJPEG files with embedded ICC profiles, but I could
> not find a real, exisiting file, that had that.
> 
> Signed-off-by: Derek Buitenhuis 
> ---
>  libavcodec/mjpegdec.c | 90 
> +++
>  libavcodec/mjpegdec.h |  5 +++
>  2 files changed, 95 insertions(+)

should be ok i think

thx

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

Frequently ignored answer#1 FFmpeg bugs should be sent to our bugtracker. User
questions about the command line tools should be sent to the ffmpeg-user ML.
And questions about how to use libav* should be sent to the libav-user ML.


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

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

[Michael Niedermayer]

On Mon, Aug 07, 2017 at 12:32:16PM -0700, Dale Curtis wrote:
> On Fri, Aug 4, 2017 at 4:38 PM, Michael Niedermayer 
> wrote:
> 
> > so theres no easy way to create a smaller file then 64mb ?
> >
> 
> Ah no, I didn't realize you had a size limit; I just meant none of the
> existing clips were large enough / worked. I've truncated the clip at
> http://storage.googleapis.com/dalecurtis/buck480p30_na.mp4 to 180 seconds
> and the seek test passes and fails correctly.

file uploded

thx

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

Opposition brings concord. Out of discord comes the fairest harmony.
-- Heraclitus


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

Re: [FFmpeg-devel] [PATCH V4 4/4] lavc/vaapi_encode_h265: respect "slices" option in h265 vaapi encoder

[Jun Zhao]

On 2017/8/23 19:12, Steven Liu wrote:
> 2017-08-23 18:34 GMT+08:00 Jun Zhao :
> >From dae9051c0828f7c86417308d06f1deb0640534bc Mon Sep 17 00:00:00 2001
> From: Jun Zhao 
> Date: Tue, 1 Aug 2017 23:07:34 -0400
> Subject: [PATCH V4 4/4] lavc/vaapi_encode_h265: respect "slices" option in
>  h265 vaapi encoder
>
> Enable multi-slice support in AVC/H.265 vaapi encoder.
>
> Signed-off-by: Wang, Yi A 
> Signed-off-by: Jun Zhao 
> ---
>  libavcodec/vaapi_encode_h265.c | 36 ++--
>  1 file changed, 30 insertions(+), 6 deletions(-)
>
> diff --git a/libavcodec/vaapi_encode_h265.c b/libavcodec/vaapi_encode_h265.c
> index cf6b9388d1..e27b554a98 100644
> --- a/libavcodec/vaapi_encode_h265.c
> +++ b/libavcodec/vaapi_encode_h265.c
> @@ -176,6 +176,8 @@ typedef struct VAAPIEncodeH265Context {
>  unsigned int ctu_width;
>  unsigned int ctu_height;
>
> +int last_ctu_index;
> +
>  int fixed_qp_idr;
>  int fixed_qp_p;
>  int fixed_qp_b;
> @@ -962,6 +964,7 @@ static int
> vaapi_encode_h265_init_picture_params(AVCodecContext *avctx,
>  VAEncPictureParameterBufferHEVC *vpic = pic->codec_picture_params;
>  VAAPIEncodeH265Context  *priv = ctx->priv_data;
>  int i;
> +int slices;
>
>  if (pic->type == PICTURE_TYPE_IDR) {
>  av_assert0(pic->display_order == pic->encode_order);
> @@ -1024,7 +1027,19 @@ static int
> vaapi_encode_h265_init_picture_params(AVCodecContext *avctx,
>  av_assert0(0 && "invalid picture type");
>  }
>
> -pic->nb_slices = 1;
> +slices = 1;
> +if (ctx->max_slices) {
> +if (avctx->slices <= ctx->max_slices) {
> +slices = avctx->slices;
> +} else {
> +slices = avctx->slices;
>
>
> What about move this "slices = avctx->slices;" out of the conditional ?
I think it need to return a error in this "else" and follow h264_vaapi
enc manner.
Will re-send this patch.
>
>
> +av_log(avctx, AV_LOG_WARNING, "The max slices number per frame "
> +   "cannot more than %d.\n", slices);
> +}
> +}
> +pic->nb_slices = slices;
> +
> +priv->last_ctu_index = 0;
>
>  return 0;
>  }
> @@ -1047,9 +1062,10 @@ static int
> vaapi_encode_h265_init_slice_params(AVCodecContext *avctx,
>  pslice = slice->priv_data;
>  mslice = >misc_slice_params;
>
> -// Currently we only support one slice per frame.
> -vslice->slice_segment_address = 0;
> -vslice->num_ctu_in_slice = priv->ctu_width * priv->ctu_height;
> +vslice->slice_segment_address = priv->last_ctu_index;
> +vslice->num_ctu_in_slice =
> +((slice->index + 1) * priv->ctu_width * priv->ctu_height) /
> pic->nb_slices - priv->last_ctu_index;
> +priv->last_ctu_index += vslice->num_ctu_in_slice;
>
>  switch (pic->type) {
>  case PICTURE_TYPE_IDR:
> @@ -1103,9 +1119,13 @@ static int
> vaapi_encode_h265_init_slice_params(AVCodecContext *avctx,
>  else
>  vslice->slice_qp_delta = priv->fixed_qp_idr - vpic->pic_init_qp;
>
> -vslice->slice_fields.bits.last_slice_of_pic_flag = 1;
> +if (priv->last_ctu_index == priv->ctu_width * priv->ctu_height)
> +vslice->slice_fields.bits.last_slice_of_pic_flag = 1;
>
> -mslice->first_slice_segment_in_pic_flag = 1;
> +if (vslice->slice_segment_address == 0)
> +mslice->first_slice_segment_in_pic_flag = 1;
> +else
> +mslice->first_slice_segment_in_pic_flag = 0;
>
>
> What about:
> mslice->first_slice_segment_in_pic_flag = vslice->slice_segment_address ? 0 : 
> 1;
> ?
Ok
>
>  if (pic->type == PICTURE_TYPE_IDR) {
>  // No reference pictures.
> @@ -1198,6 +1218,10 @@ static av_cold int
> vaapi_encode_h265_configure(AVCodecContext *avctx)
>  av_assert0(0 && "Invalid RC mode.");
>  }
>
> +if (!ctx->max_slices && avctx->slices > 0)
> +av_log(avctx, AV_LOG_WARNING, "The encode slice option is not "
> +   "supported with the driver.\n");
> +
>  return 0;
>  }
>

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

Re: [FFmpeg-devel] [PATCH 1/6] avcodec/vorbisenc: Add pre-echo detection

[Tyler Jones]

On Wed, Aug 23, 2017 at 10:11:50AM +0200, Tomas Härdin wrote:
> On 2017-08-22 03:23, Tyler Jones wrote:
> > +
> > +/**
> > + * Calculate the variance of a block of samples
> > + *
> > + * @param in Array of input samples
> > + * @param length Number of input samples being analyzed
> > + * @return   The variance for the current block
> > + */
> > +static float variance(const float *in, int length, AVFloatDSPContext *fdsp)
> > +{
> > +int i;
> > +float mean = 0.0f, square_sum = 0.0f;
> > +
> > +for (i = 0; i < length; i++) {
> > +mean += in[i];
> > +}
> > +
> > +square_sum = fdsp->scalarproduct_float(in, in, length);
> > +
> > +mean /= length;
> > +return (square_sum - length * mean * mean) / (length - 1);
> > +}
> 
> Isn't this method much more numerically unstable compared to the naïve
> method? Might not matter too much when the source data is 16-bit, but
> throwing it out there anyway

This does have the possibility of being more unstable than the naive
version. However, I have not been able to find a sample file where it is
even close to influential. The epsilon constant added during comparison
between variances has a much greater impact. A quick run of the same samples
through python was able to verify this.
 
> DSP methods for computing mean and variance could be a good project for
> someone wanting to learn
> 
> /Tomas

I am unsure of how many codecs use direct calculation of statistical
values. Perhaps someone with more experience than myself could comment on
the usefulness of such methods.

I appreciate your comments,

Tyler Jones


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

Re: [FFmpeg-devel] [PATCH 2/6] avcodec/vorbisenc: Apply dynamic frame lengths

[Tyler Jones]

On Wed, Aug 23, 2017 at 10:31:58AM +0200, Tomas Härdin wrote:
> On 2017-08-22 03:23, Tyler Jones wrote:
> > +static int create_residues(vorbis_enc_context *venc)
> > +{
> > +int res, ret;
> > +vorbis_enc_residue *rc;
> > +
> > +venc->nresidues = 2;
> > +venc->residues  = av_malloc(sizeof(vorbis_enc_residue) * 
> > venc->nresidues);
> 
> av_malloc_array()? Applies to most av_malloc() in there

I can change it, but I don't feel that it helps readability in this specific
case above. As for the others that happen to show up in the diffs, I did not
want to make any unnecessary and unrelated functional changes. However, I'll
gladly to switch these cases to `av_malloc_array()` in a separate commit if
desired.

> > -// single mapping
> > -mc = >mappings[0];
> > -mc->submaps = 1;
> > -mc->mux = av_malloc(sizeof(int) * venc->channels);
> > -if (!mc->mux)
> > -return AVERROR(ENOMEM);
> > -for (i = 0; i < venc->channels; i++)
> > -mc->mux[i] = 0;
> > -mc->floor   = av_malloc(sizeof(int) * mc->submaps);
> > -mc->residue = av_malloc(sizeof(int) * mc->submaps);
> > -if (!mc->floor || !mc->residue)
> > -return AVERROR(ENOMEM);
> > -for (i = 0; i < mc->submaps; i++) {
> > -mc->floor[i]   = 0;
> > -mc->residue[i] = 0;
> > -}
> > -mc->coupling_steps = venc->channels == 2 ? 1 : 0;
> > -mc->magnitude  = av_malloc(sizeof(int) * mc->coupling_steps);
> > -mc->angle  = av_malloc(sizeof(int) * mc->coupling_steps);
> > -if (!mc->magnitude || !mc->angle)
> > -return AVERROR(ENOMEM);
> > -if (mc->coupling_steps) {
> > -mc->magnitude[0] = 0;
> > -mc->angle[0] = 1;
> > +for (map = 0; map < venc->nmappings; map++) {
> > +mc = >mappings[map];
> > +mc->submaps = 1;
> > +mc->mux = av_malloc(sizeof(int) * venc->channels);
> > +if (!mc->mux)
> > +return AVERROR(ENOMEM);
> > +for (i = 0; i < venc->channels; i++)
> > +mc->mux[i] = 0;
> > +mc->floor   = av_malloc(sizeof(int) * mc->submaps);
> > +mc->residue = av_malloc(sizeof(int) * mc->submaps);
> > +if (!mc->floor || !mc->residue)
> > +return AVERROR(ENOMEM);
> > +for (i = 0; i < mc->submaps; i++) {
> > +mc->floor[i]   = map;
> > +mc->residue[i] = map;
> > +}
> > +mc->coupling_steps = venc->channels == 2 ? 1 : 0;
> > +mc->magnitude  = av_malloc(sizeof(int) * mc->coupling_steps);
> > +mc->angle  = av_malloc(sizeof(int) * mc->coupling_steps);
> > +if (!mc->magnitude || !mc->angle)
> > +return AVERROR(ENOMEM);
> > +if (mc->coupling_steps) {
> > +mc->magnitude[0] = 0;
> > +mc->angle[0] = 1;
> > +}
> >   }
> 
> Maybe nitpicking, but it would be clearer what the changes are if you put
> the indentation change in a separate commit

No, you're right, and it's a good suggestion. I'll move the indentation to a
separate commit when enough other changes have been provided to warrant a new 
version.

> > -move_audio(venc, avctx->frame_size);
> > +if (venc->transient < 0) {
> > +move_audio(venc, avctx->frame_size);
> > -for (ch = 0; ch < venc->channels; ch++) {
> > -float *scratch = venc->scratch + 2 * ch * frame_size + frame_size;
> > +for (ch = 0; ch < venc->channels; ch++) {
> > +float *scratch = venc->scratch + 2 * ch * long_win + long_win;
> > -if (!ff_psy_vorbis_block_frame(>vpctx, scratch, ch,
> > -   frame_size, block_size))
> > -curr_win = 0;
> > +if (!ff_psy_vorbis_block_frame(>vpctx, scratch, ch,
> > +   long_win, short_win))
> > +next_win = 0;
> > +}
> >   }
> 
> Same here
> 
> /Tomas
> 

I felt that separating this small amount of lines would just clutter the git
log history, but I'll move these along with the mapping indentations.

Thanks for taking a look,

Tyler Jones


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

Re: [FFmpeg-devel] [PATCH] avfilter: Add vmaf filter

[Michael Niedermayer]

On Thu, Aug 24, 2017 at 12:58:53AM +0530, Ashish Pratap Singh wrote:
> From: Ashish Singh 
> 
> Hi, this is vmaf filter. It fuses the scores of previous metrics adm, motion 
> and vif
> using svm algorithm. It's different from libvmaf filter because it has a very 
> little
> external dependency (only one svm model file).
> Currently it supports only one model which can be extended later for other 
> models.
> I have added the model file inside libavfilter/data/ so that it can run 
> successfully.
> There is still a bit of work left to do like changing each filter from float
> to integer. It's in progress along with SIMD optimizations.
> 
> Signed-off-by: Ashish Singh 
> ---
>  Changelog  |   1 +
>  doc/filters.texi   |  38 ++
>  libavfilter/Makefile   |   1 +
>  libavfilter/allfilters.c   |   1 +
>  libavfilter/data/vmaf_v0.6.1.pkl.model | 218 
>  libavfilter/vf_vmaf.c  | 945 
> +
>  libavfilter/vmaf.h | 138 +
>  7 files changed, 1342 insertions(+)
>  create mode 100644 libavfilter/data/vmaf_v0.6.1.pkl.model
>  create mode 100644 libavfilter/vf_vmaf.c
>  create mode 100644 libavfilter/vmaf.h

fails to build

CC  libavfilter/vf_vmaf.o
libavfilter/vf_vmaf.c:36:17: fatal error: adm.h: No such file or directory
 #include "adm.h"
 ^
compilation terminated.
make: *** [libavfilter/vf_vmaf.o] Error 1
make: Target `all' not remade because of errors.




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

What does censorship reveal? It reveals fear. -- Julian Assange


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

Re: [FFmpeg-devel] [PATCH] avcodec/vp9: Add tile threading support

[Ronald S. Bultje]

Hi,

On Tue, Aug 22, 2017 at 7:59 PM, Ilia Valiakhmetov 
wrote:

> +if (s->td)
> +av_free(s->td);
> +
> +s->td = av_mallocz_array(s->s.h.tiling.tile_cols,
> sizeof(VP9TileData));


The free() leaks s->td[*].b/block_base if they were already allocated.

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

Re: [FFmpeg-devel] [PATCH 2/2] fate: add test vector aac-al04sf_48

[Michael Niedermayer]

On Tue, Aug 22, 2017 at 07:25:15PM -0700, Alex Converse wrote:
> On Tue, Aug 22, 2017 at 3:23 PM, Michael Niedermayer
>  wrote:
> > On Mon, Aug 21, 2017 at 04:22:15PM -0700, Alex Converse wrote:
> >> ---
> >>  tests/fate/aac.mak | 4 
> >>  1 file changed, 4 insertions(+)
> >
> > where can i find the files to test & upload to fate samples ?
> >
> 
> The files are part of the official conformance suite and can be found at:
> ftp://mpaudconf:adif2...@ftp.iis.fhg.de/mpeg4audio-conformance/compressedMp4/al04sf_48.mp4
> and
> ftp://mpaudconf:adif2...@ftp.iis.fhg.de/mpeg4audio-conformance/referencesWav/al04sf_48.wav

uploaded

patches tested on linux32/mingw32/64/arm/mips

thx

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

Those who are best at talking, realize last or never when they are wrong.


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

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

[Dale Curtis]

On Sat, Aug 19, 2017 at 3:50 PM, Michael Niedermayer  wrote:

> On Sun, Aug 20, 2017 at 12:48:30AM +0200, Michael Niedermayer wrote:
> > On Fri, Aug 18, 2017 at 03:57:45PM -0700, Dale Curtis wrote:
> > > Anything else here? It'd be nice to get this landed soon if no one has
> any
> > > other comments.
> >
> > it appears to not apply cleanly anymore
>
> seems caused by f4544163b27615ecfff1b42d6acdb3672ac92399.
>

Thanks rebased on ToT after chatting with Jacob to ensure my patch didn't
regress his issue.

- dale


ctts_fix_v9.patch
Description: Binary data
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] all: avoid data imports across DLL boundaries

[James Almer]

On 8/21/2017 2:51 PM, wm4 wrote:
> From: Pedro Pombeiro 
> 
> DLL data imports cause problems on Windows. They normally require
> each variable to be correctly marked with dllimport/dllexport
> declspecs. For MSVC, we define av_export to dllimport declspec. This
> is not entirely correct - depending on which sub-lib is built, they
> should be marked to dllexport instead. It happens to work with MSVC,
> because it supports exports incorrectly marked as imports. Trying to
> use this breaks on MinGW and results in linker errors.
> 
> On MinGW, not using any import/export specifiers happens to work,
> because binutils and the MinGW runtime provide "pseudo relocations",
> which manually fix these imports at load time. This does not work with
> MinGW WinRT builds: the relocations cannot be performed because this
> would require writing to the code section, which is not allowed.
> 
> Get rid of all these issues by not using data exports/imports. The
> public API is already free of them, but avpriv_ symbols make extensive
> use of them. Replace them all with getters.

Should be good i think, but it can't be applied as is until the next
major bump as it breaks ABI (Tons of avpriv_ symbols are removed).

Speaking of which, do you or anyone else want to help with applying the
bump right now instead of waiting until the merges are resumed?
Finding what deprecated APIs are two years or older, removing them and
seeing if any further changes are needed to ensure compilation after the
bump (I bet a lot will require changes since deprecations imported from
libav aren't given much attention here outside of making sure warnings
are silenced).
ABI changes, like moving fields around within a struct or into an opaque
internal struct, removing/modifying avpriv_ functions, etc, are things
that can be done during several weeks after the bump and not necessarily
as preparation for it.

Certain deprecated APIs that are two years or older could be kept in
place if removing them takes too much work at the moment, but the bump
is pretty overdue by now due to the amount of crap some structs are
currently dealing with (public vs private fields, offsets, etc).
We've had enough ABI breakages with this set of major versions so it
would be great if we can move on from it before a new release is tagged.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] libavdevice/decklink: enable 16 output channel

[pkv.stream]

Le 23/08/2017 à 10:32 PM, Matthias Hunstock a écrit :

Am 23.08.2017 um 19:28 schrieb wm4:

What channel layouts do configurations with channels 9 to 16 use?

There is no concept like stream or track in SDI. It just has 16 mono
channels without any semantics which are arbitrarily mapped to whatever
you need to transport.
you provided the right answer to wm4; I had not understood his question. 
Thanks.





@pkv.stream: HDMI 1.x does only support up to 8 channels (7.1), which
might be the reason for the missing 16. Did you test what happens when
16 audio channels are requested for HDMI out?
yes, no error thrown; every odd channel (1, 3 , 5 ...) is streamed from 
the source to the HDMI output (in my case decklink studio 4k which 
accepts 8 channel output, I am not aware of any decklink with more than 
8 channels out, anyway). The other even channels are thrown out.


As for SDI output, the 16 channels are sent without issues.



(yes, selection of decklink video output connection via ffmpeg options
is still missing).
the output is sent to all interfaces, both sdi and hdmi, at least in my 
decklink studio 4K.





Matthias
___
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

[FFmpeg-devel] [PATCH] avformat/rtpdec_h264: Fix heap-buffer-overflow

[Michael Niedermayer]

Fixes: rtp_sdp/poc.sdp

Found-by: Bingchang 
Signed-off-by: Michael Niedermayer 
---
 libavformat/rtpdec_h264.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/libavformat/rtpdec_h264.c b/libavformat/rtpdec_h264.c
index 8dd56a549e..6f8148ab6d 100644
--- a/libavformat/rtpdec_h264.c
+++ b/libavformat/rtpdec_h264.c
@@ -166,7 +166,7 @@ static int sdp_parse_fmtp_config_h264(AVFormatContext *s,
 parse_profile_level_id(s, h264_data, value);
 } else if (!strcmp(attr, "sprop-parameter-sets")) {
 int ret;
-if (value[strlen(value) - 1] == ',') {
+if (*value == 0 || value[strlen(value) - 1] == ',') {
 av_log(s, AV_LOG_WARNING, "Missing PPS in sprop-parameter-sets, 
ignoring\n");
 return 0;
 }
-- 
2.14.1

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

Re: [FFmpeg-devel] [PATCH] libavdevice/decklink: enable 16 output channel

[Matthias Hunstock]

Am 23.08.2017 um 19:28 schrieb wm4:
> What channel layouts do configurations with channels 9 to 16 use?

There is no concept like stream or track in SDI. It just has 16 mono
channels without any semantics which are arbitrarily mapped to whatever
you need to transport.


@pkv.stream: HDMI 1.x does only support up to 8 channels (7.1), which
might be the reason for the missing 16. Did you test what happens when
16 audio channels are requested for HDMI out?

(yes, selection of decklink video output connection via ffmpeg options
is still missing).


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

Re: [FFmpeg-devel] [FFmpeg-cvslog] avcodec/pngdec: Fix () placement

[Alexander Strasser]

On 2017-08-22 17:23 +, Michael Niedermayer wrote:
> ffmpeg | branch: master | Michael Niedermayer  | Tue 
> Aug 22 18:36:26 2017 +0200| [a2e444d5bb2e3115d3afcc0cca9d1506c90436a2] | 
> committer: Michael Niedermayer
> 
> avcodec/pngdec: Fix () placement
> 
> Signed-off-by: Michael Niedermayer 
> 
> > http://git.videolan.org/gitweb.cgi/ffmpeg.git/?a=commit;h=a2e444d5bb2e3115d3afcc0cca9d1506c90436a2
> ---
> 
>  libavcodec/pngdec.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/libavcodec/pngdec.c b/libavcodec/pngdec.c
> index 4fc1c5a062..dce8faf168 100644
> --- a/libavcodec/pngdec.c
> +++ b/libavcodec/pngdec.c
> @@ -858,7 +858,7 @@ static int decode_iccp_chunk(PNGDecContext *s, int 
> length, AVFrame *f)
>  
>  length = FFMAX(length - 1, 0);
>  
> -if ((ret = decode_zbuf(, s->gb.buffer, s->gb.buffer + length) < 0))
> +if ((ret = decode_zbuf(, s->gb.buffer, s->gb.buffer + length)) < 0)

IMHO another reason not to do the assignment and the comparison on the same
line inside the if-condition in C.

I mean you need the extra parens and if you are not careful enough you will 
just get it silently wrong like it was above.

Probably we found enough of such errors to discourage that style in FFmpeg?


>  return ret;
>  
>  av_bprint_finalize(, (char **));


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

[FFmpeg-devel] [PATCH] avfilter: Add vmaf filter

[Ashish Pratap Singh]

From: Ashish Singh 

Hi, this is vmaf filter. It fuses the scores of previous metrics adm, motion 
and vif
using svm algorithm. It's different from libvmaf filter because it has a very 
little
external dependency (only one svm model file).
Currently it supports only one model which can be extended later for other 
models.
I have added the model file inside libavfilter/data/ so that it can run 
successfully.
There is still a bit of work left to do like changing each filter from float
to integer. It's in progress along with SIMD optimizations.

Signed-off-by: Ashish Singh 
---
 Changelog  |   1 +
 doc/filters.texi   |  38 ++
 libavfilter/Makefile   |   1 +
 libavfilter/allfilters.c   |   1 +
 libavfilter/data/vmaf_v0.6.1.pkl.model | 218 
 libavfilter/vf_vmaf.c  | 945 +
 libavfilter/vmaf.h | 138 +
 7 files changed, 1342 insertions(+)
 create mode 100644 libavfilter/data/vmaf_v0.6.1.pkl.model
 create mode 100644 libavfilter/vf_vmaf.c
 create mode 100644 libavfilter/vmaf.h

diff --git a/Changelog b/Changelog
index 7a6987a..b33f0b2 100644
--- a/Changelog
+++ b/Changelog
@@ -33,6 +33,7 @@ version :
 - tlut2 video filter
 - floodfill video filter
 - pseudocolor video filter
+- vmaf video filter
 
 version 3.3:
 - CrystalHD decoder moved to new decode API
diff --git a/doc/filters.texi b/doc/filters.texi
index 3b5a38f..2396d96 100644
--- a/doc/filters.texi
+++ b/doc/filters.texi
@@ -15375,6 +15375,44 @@ vignette='PI/4+random(1)*PI/50':eval=frame
 
 @end itemize
 
+@section vmaf
+
+Obtain the VMAF (Video Multi-Method Assessment Fusion)
+score between two input videos.
+
+Both video inputs must have the same resolution and pixel format.
+
+The obtained VMAF score is printed through the logging system.
+
+If no model path is specified it uses the default model: 
@code{vmaf_v0.6.1.pkl}.
+
+The filter has following options:
+
+@table @option
+@item model_path
+Set the model path which is to be used for SVM.
+Default value: @code{"vmaf_v0.6.1.pkl.model"}
+
+@item enable_transform
+Enables transform for computing vmaf.
+
+@item pool
+Set the pool method to be used for computing vmaf (mean, min or harmonic mean).
+@end table
+
+On the below examples the input file @file{main.mpg} being processed is
+compared with the reference file @file{ref.mpg}.
+
+For example:
+@example
+ffmpeg -i main.mpg -i ref.mpg -lavfi vmaf -f null -
+@end example
+
+Example with options:
+@example
+ffmpeg -i main.mpg -i ref.mpg -lavfi vmaf="pool=min" -f null -
+@end example
+
 @section vstack
 Stack input videos vertically.
 
diff --git a/libavfilter/Makefile b/libavfilter/Makefile
index 1d92dc1..068b29f 100644
--- a/libavfilter/Makefile
+++ b/libavfilter/Makefile
@@ -327,6 +327,7 @@ OBJS-$(CONFIG_VFLIP_FILTER)  += vf_vflip.o
 OBJS-$(CONFIG_VIDSTABDETECT_FILTER)  += vidstabutils.o 
vf_vidstabdetect.o
 OBJS-$(CONFIG_VIDSTABTRANSFORM_FILTER)   += vidstabutils.o 
vf_vidstabtransform.o
 OBJS-$(CONFIG_VIGNETTE_FILTER)   += vf_vignette.o
+OBJS-$(CONFIG_VMAF_FILTER)   += vf_vmaf.o dualinput.o 
framesync.o
 OBJS-$(CONFIG_VSTACK_FILTER) += vf_stack.o framesync2.o
 OBJS-$(CONFIG_W3FDIF_FILTER) += vf_w3fdif.o
 OBJS-$(CONFIG_WAVEFORM_FILTER)   += vf_waveform.o
diff --git a/libavfilter/allfilters.c b/libavfilter/allfilters.c
index 8b9b9a4..39c3265 100644
--- a/libavfilter/allfilters.c
+++ b/libavfilter/allfilters.c
@@ -338,6 +338,7 @@ static void register_all(void)
 REGISTER_FILTER(VIDSTABDETECT,  vidstabdetect,  vf);
 REGISTER_FILTER(VIDSTABTRANSFORM, vidstabtransform, vf);
 REGISTER_FILTER(VIGNETTE,   vignette,   vf);
+REGISTER_FILTER(VMAF,   vmaf,   vf);
 REGISTER_FILTER(VSTACK, vstack, vf);
 REGISTER_FILTER(W3FDIF, w3fdif, vf);
 REGISTER_FILTER(WAVEFORM,   waveform,   vf);
diff --git a/libavfilter/data/vmaf_v0.6.1.pkl.model 
b/libavfilter/data/vmaf_v0.6.1.pkl.model
new file mode 100644
index 000..fe157df
--- /dev/null
+++ b/libavfilter/data/vmaf_v0.6.1.pkl.model
@@ -0,0 +1,218 @@
+svm_type nu_svr
+kernel_type rbf
+gamma 0.04
+nr_class 2
+total_sv 211
+rho -1.33133
+SV
+-4 1:0.65734273 2:0.34681232 3:0.09377 4:0.60913934 5:0.69117362 
6:0.73495824 
+4 1:0.8727433 2:0.49612229 3:0.59146724 4:0.78105663 5:0.84916292 6:0.8882561 
+4 1:0.89890005 2:0.49612229 3:0.66823667 4:0.86050887 5:0.90873162 
6:0.93335071 
+4 1:0.20371751 2:0.49612229 3:0.10534315 4:-1.110223e-16 6:2.220446e-16 
+4 1:0.33913836 2:0.49612229 3:0.14024497 4:0.074708413 5:0.10231651 
6:0.1259153 
+4 1:0.66426757 2:0.49612229 3:0.35268026 4:0.4805681 5:0.59603341 6:0.67408692 
+4 1:0.59561632 2:0.49612229 3:0.27561601 4:0.33977371 5:0.4325213 6:0.50244952 
+4 1:0.50821444 2:0.49612229 3:0.20276685 

Re: [FFmpeg-devel] [PATCH] libavdevice/decklink: enable 16 output channel

[Kieran Kunhya]

On Wed, 23 Aug 2017, 18:28 wm4  wrote:

> On Wed, 23 Aug 2017 18:51:45 +0200
> "pkv.stream"  wrote:
>
> > Hello
> >
> > the following patch extends number of output channel for decklink
> > devices to 16. Previously it was limited to 2 or 8 audio channels.
> >
> > Thanks for any comments.
> >
> >
>

Could be anything in theory. More often than not, stereo pairs of
languages, or clean audio.

Kieran

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

Re: [FFmpeg-devel] [PATCH] libavdevice/decklink: enable 16 output channel

[pkv.stream]

Le 23/08/2017 à 7:28 PM, wm4 a écrit :

On Wed, 23 Aug 2017 18:51:45 +0200
"pkv.stream"  wrote:


Hello

the following patch extends number of output channel for decklink
devices to 16. Previously it was limited to 2 or 8 audio channels.

Thanks for any comments.



What channel layouts do configurations with channels 9 to 16 use?
___

for 16 channels, that's hexadecagonal channel layout.
There aren't any in between 8 and 16 declared in libavutil.
One goes from octagonal 8.0 and the various 7.1 straight to 16.0 = 
hexadecagonal

Intermediate layouts might be interesting for ambisonics of various orders.

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

Re: [FFmpeg-devel] [PATCH] libavdevice/decklink: enable 16 output channel

[wm4]

On Wed, 23 Aug 2017 18:51:45 +0200
"pkv.stream"  wrote:

> Hello
> 
> the following patch extends number of output channel for decklink 
> devices to 16. Previously it was limited to 2 or 8 audio channels.
> 
> Thanks for any comments.
> 
> 

What channel layouts do configurations with channels 9 to 16 use?
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH] libavdevice/decklink: enable 16 output channel

[pkv.stream]

Hello

the following patch extends number of output channel for decklink 
devices to 16. Previously it was limited to 2 or 8 audio channels.


Thanks for any comments.


From 681e389e4946e079d7db5892f98a82a5b75ad297 Mon Sep 17 00:00:00 2001
From: pkviet 
Date: Sun, 2 Jul 2017 23:50:56 +0200
Subject: [PATCH] libavdevice/decklink: enable 16 output channel

Decklink devices can output 2, 8 or 16 audio channels along video.
The code was limited to 2 or 8 channels. The commit enables 16 audio
channels (relevant for SDI outputs).
---
 libavdevice/decklink_enc.cpp | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/libavdevice/decklink_enc.cpp b/libavdevice/decklink_enc.cpp
index be01bcd..25ce7d0 100644
--- a/libavdevice/decklink_enc.cpp
+++ b/libavdevice/decklink_enc.cpp
@@ -172,9 +172,9 @@ static int decklink_setup_audio(AVFormatContext *avctx, 
AVStream *st)
" Only 48kHz is supported.\n");
 return -1;
 }
-if (c->channels != 2 && c->channels != 8) {
+if (c->channels != 2 && c->channels != 8 && c->channels != 16) {
 av_log(avctx, AV_LOG_ERROR, "Unsupported number of channels!"
-   " Only stereo and 7.1 are supported.\n");
+   " Only 2, 8 or 16 channels are supported.\n");
 return -1;
 }
 if (ctx->dlo->EnableAudioOutput(bmdAudioSampleRate48kHz,
-- 
2.10.1.windows.1

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

[FFmpeg-devel] [PATCH] ffmpeg options: Enable trailing ? for map_channel

[pkv.stream]

Hello,

the following patch allows one to add a trailing ? to -map_channel as in 
-map option.


E.g: -map_channel 0.0.2? so that if the channel does not exist, the 
command does not stop.


This is similar to what one can do with -map.

Thanks for any input.


From 07959dfe79816d03c30b8027f45b41d60078b3fa Mon Sep 17 00:00:00 2001
From: pkviet 
Date: Tue, 22 Aug 2017 11:30:45 +0200
Subject: [PATCH] ffmpeg options: Enable trailing ? for map_channel

The -map option allows for a trailing ? so that an error is not thrown if
the input stream does not exist.
This capability is extended to the map_channel option.
This allows a ffmpeg command not to break if an input channel does not
exist, which can be of use (for instance, scripts processing audio
channels with sources having unset number of audio channels).
---
 ffmpeg_opt.c | 24 
 1 file changed, 20 insertions(+), 4 deletions(-)

diff --git a/ffmpeg_opt.c b/ffmpeg_opt.c
index 1c4a11e..6b3912f 100644
--- a/ffmpeg_opt.c
+++ b/ffmpeg_opt.c
@@ -405,7 +405,12 @@ static int opt_map_channel(void *optctx, const char *opt, 
const char *arg)
 int n;
 AVStream *st;
 AudioChannelMap *m;
-
+   char *allow_unused;
+   char *mapchan;
+   mapchan = av_strdup(arg);
+   if (!mapchan)
+return AVERROR(ENOMEM);
+   
 GROW_ARRAY(o->audio_channel_maps, o->nb_audio_channel_maps);
 m = >audio_channel_maps[o->nb_audio_channel_maps - 1];
 
@@ -450,10 +455,21 @@ static int opt_map_channel(void *optctx, const char *opt, 
const char *arg)
m->file_idx, m->stream_idx);
 exit_program(1);
 }
+   /* allow trailing ? to map_channel */
+   if (allow_unused = strchr(mapchan, '?'))
+   *allow_unused = 0;
 if (m->channel_idx < 0 || m->channel_idx >= st->codecpar->channels) {
-av_log(NULL, AV_LOG_FATAL, "mapchan: invalid audio channel 
#%d.%d.%d\n",
-   m->file_idx, m->stream_idx, m->channel_idx);
-exit_program(1);
+   if (allow_unused) {
+   av_log(NULL, AV_LOG_VERBOSE, "mapchan: invalid audio 
channel #%d.%d.%d\n",
+   m->file_idx, m->stream_idx, m->channel_idx);
+   }
+   else {
+   av_log(NULL, AV_LOG_FATAL, "mapchan: invalid audio 
channel #%d.%d.%d\n"
+   "To ignore this, add a trailing '?' to the 
map_channel.\n",
+   m->file_idx, m->stream_idx, m->channel_idx);
+   exit_program(1);
+   }
+
 }
 return 0;
 }
-- 
2.10.1.windows.1

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

[FFmpeg-devel] [PATCH] mjpeg: Add support for ICC side data

[Derek Buitenhuis]

JPEGs store embedded profiles under the APP2 marker, signified
with a "ICC_PROFILE" null-terminated string header, and can be
split across multiple APP2 markers, out of order.

This patch currently assumes one single ICC profile for the
whole context, i.e. a single JPEG input file. This likely does
not work for MJPEG files with embedded ICC profiles, but I could
not find a real, exisiting file, that had that.

Signed-off-by: Derek Buitenhuis 
---
 libavcodec/mjpegdec.c | 90 +++
 libavcodec/mjpegdec.h |  5 +++
 2 files changed, 95 insertions(+)

diff --git a/libavcodec/mjpegdec.c b/libavcodec/mjpegdec.c
index 387ceadf..8be5e01 100644
--- a/libavcodec/mjpegdec.c
+++ b/libavcodec/mjpegdec.c
@@ -1901,6 +1901,67 @@ static int mjpeg_decode_app(MJpegDecodeContext *s)
 }
 }
 
+if (s->start_code == APP2 && id == AV_RB32("ICC_") && len >= 10) {
+int id2;
+unsigned seqno;
+unsigned nummarkers;
+
+id   = get_bits_long(>gb, 32);
+id2  = get_bits_long(>gb, 24);
+len -= 7;
+if (id != AV_RB32("PROF") || id2 != AV_RB24("ILE")) {
+av_log(s->avctx, AV_LOG_WARNING, "Invalid ICC_PROFILE header in 
APP2\n");
+goto out;
+}
+
+skip_bits(>gb, 8);
+seqno  = get_bits(>gb, 8);
+len   -= 2;
+if (seqno == 0) {
+av_log(s->avctx, AV_LOG_WARNING, "Invalid sequence number in 
APP2\n");
+goto out;
+}
+
+nummarkers  = get_bits(>gb, 8);
+len-= 1;
+if (nummarkers == 0) {
+av_log(s->avctx, AV_LOG_WARNING, "Invalid number of markers coded 
in APP2\n");
+goto out;
+} else if (s->iccnum != 0 && nummarkers != s->iccnum) {
+av_log(s->avctx, AV_LOG_WARNING, "Mistmatch in coded number of ICC 
markers between markers\n");
+goto out;
+} else if (seqno > nummarkers) {
+av_log(s->avctx, AV_LOG_WARNING, "Mismatching sequence number and 
coded number of ICC markers\n");
+goto out;
+}
+
+/* Allocate if this is the first APP2 we've seen. */
+if (s->iccnum == 0) {
+s->iccdata = av_mallocz(nummarkers * sizeof(*(s->iccdata)));
+s->iccdatalens = av_mallocz(nummarkers * 
sizeof(*(s->iccdatalens)));
+if (!s->iccdata || !s->iccdatalens) {
+av_log(s->avctx, AV_LOG_ERROR, "Could not allocate ICC data 
arrays\n");
+return AVERROR(ENOMEM);
+}
+s->iccnum = nummarkers;
+}
+
+s->iccdatalens[seqno - 1]  = len;
+s->iccdata[seqno - 1]  = av_malloc(len);
+if (!s->iccdata[seqno - 1]) {
+av_log(s->avctx, AV_LOG_ERROR, "Could not allocate ICC data 
buffer\n");
+return AVERROR(ENOMEM);
+}
+
+memcpy(s->iccdata[seqno - 1], align_get_bits(>gb), len);
+skip_bits(>gb, len << 3);
+len = 0;
+s->iccread++;
+
+if (s->iccread > s->iccnum)
+av_log(s->avctx, AV_LOG_WARNING, "Read more ICC markers than are 
supposed to be coded\n");
+}
+
 out:
 /* slow but needed for extreme adobe jpegs */
 if (len < 0)
@@ -2509,6 +2570,29 @@ the_end:
 av_freep(>stereo3d);
 }
 
+if (s->iccnum != 0 && s->iccnum == s->iccread) {
+AVFrameSideData *sd;
+size_t offset = 0;
+int total_size = 0;
+int i;
+
+/* Sum size of all parts. */
+for (i = 0; i < s->iccnum; i++)
+total_size += s->iccdatalens[i];
+
+sd = av_frame_new_side_data(data, AV_FRAME_DATA_ICC_PROFILE, 
total_size);
+if (!sd) {
+av_log(s->avctx, AV_LOG_ERROR, "Could not allocate frame side 
data\n");
+return AVERROR(ENOMEM);
+}
+
+/* Reassemble the parts, which are now in-order. */
+for (i = 0; i < s->iccnum; i++) {
+memcpy(sd->data + offset, s->iccdata[i], s->iccdatalens[i]);
+offset += s->iccdatalens[i];
+}
+}
+
 av_dict_copy(&((AVFrame *) data)->metadata, s->exif_metadata, 0);
 av_dict_free(>exif_metadata);
 
@@ -2548,6 +2632,12 @@ av_cold int ff_mjpeg_decode_end(AVCodecContext *avctx)
 av_freep(>last_nnz[i]);
 }
 av_dict_free(>exif_metadata);
+
+if (s->iccdata)
+for (i = 0; i < s->iccnum; i++)
+av_freep(>iccdata[i]);
+av_freep(>iccdata);
+av_freep(>iccdatalens);
 return 0;
 }
 
diff --git a/libavcodec/mjpegdec.h b/libavcodec/mjpegdec.h
index 024cedc..2bc69fa 100644
--- a/libavcodec/mjpegdec.h
+++ b/libavcodec/mjpegdec.h
@@ -130,6 +130,11 @@ typedef struct MJpegDecodeContext {
 AVStereo3D *stereo3d; ///!< stereoscopic information (cached, since it is 
read before frame allocation)
 
 const AVPixFmtDescriptor *pix_desc;
+
+uint8_t **iccdata;
+int *iccdatalens;
+int iccnum;
+int iccread;
 } 

Re: [FFmpeg-devel] [PATCH] avcodec/vp9: Add tile threading support

[Ronald S. Bultje]

Hi,

now for review of the vp9-specific bits.

On Tue, Aug 22, 2017 at 7:59 PM, Ilia Valiakhmetov 
wrote:

> +lflvl_len*sizeof(*s->lflvl) + 16 *
> sizeof(*s->above_mv_ctx)));
>

lflvl_len * sizeof (space).


> -// these will be re-allocated a little later
> -av_freep(>b_base);
> -av_freep(>block_base);
>

I don't think you can remove that. I understand that td may or may not be
allocated here, so you probably need an if or so, but its critically
important that we re-allocate these upon a size change, so this behaviour
probably needs to stay in.


>  } else {
> -s->b_base = av_malloc(sizeof(VP9Block));
> -s->block_base = av_mallocz((64 * 64 + 2 * chroma_blocks) *
> bytesperpixel * sizeof(int16_t) +
> -   16 * 16 + 2 * chroma_eobs);
> -if (!s->b_base || !s->block_base)
> -return AVERROR(ENOMEM);
> -s->uvblock_base[0] = s->block_base + 64 * 64 * bytesperpixel;
> -s->uvblock_base[1] = s->uvblock_base[0] + chroma_blocks *
> bytesperpixel;
> -s->eob_base = (uint8_t *) (s->uvblock_base[1] + chroma_blocks *
> bytesperpixel);
> -s->uveob_base[0] = s->eob_base + 16 * 16;
> -s->uveob_base[1] = s->uveob_base[0] + chroma_eobs;
> +for (i = 1; i < s->s.h.tiling.tile_cols; i++) {
> +if (s->td[i].b_base && s->td[i].block_base) {
> +av_free(s->td[i].b_base);
> +av_free(s->td[i].block_base);
> +}
> +}
> +for (i = 0; i < s->s.h.tiling.tile_cols; i++) {
> +s->td[i].b_base = av_malloc(sizeof(VP9Block));
> +s->td[i].block_base = av_mallocz((64 * 64 + 2 *
> chroma_blocks) * bytesperpixel * sizeof(int16_t) +
> +   16 * 16 + 2 * chroma_eobs);
> +if (!s->td[i].b_base || !s->td[i].block_base)
> +return AVERROR(ENOMEM);
> +s->td[i].uvblock_base[0] = s->td[i].block_base + 64 * 64 *
> bytesperpixel;
> +s->td[i].uvblock_base[1] = s->td[i].uvblock_base[0] +
> chroma_blocks * bytesperpixel;
> +s->td[i].eob_base = (uint8_t *) (s->td[i].uvblock_base[1] +
> chroma_blocks * bytesperpixel);
> +s->td[i].uveob_base[0] = s->td[i].eob_base + 16 * 16;
> +s->td[i].uveob_base[1] = s->td[i].uveob_base[0] + chroma_eobs;
> +}
>

This makes the non-threaded decoder use a lot more memory, I'm not sure
that's a good idea, it's certainly not required, since I believe the
codepath of non-threaded is shared with frame-mt, so it only uses s->td[0].
Can we allocate less memory here if there's no frame-threading at all?


> +static int decode_tiles(AVCodecContext *avctx)
> +{
> +VP9Context *s = avctx->priv_data;
> +VP9TileData *td = >td[0];
> +int row, col, tile_row, tile_col;
> +int bytesperpixel;
> +int tile_row_start, tile_row_end, tile_col_start, tile_col_end;
> +AVFrame *f;
> +ptrdiff_t yoff, uvoff, ls_y, ls_uv;
> +
> +f = s->s.frames[CUR_FRAME].tf.f;
> +ls_y = f->linesize[0];
> +ls_uv =f->linesize[1];
> +bytesperpixel = s->bytesperpixel;
> +
> +yoff = uvoff = 0;
> +for (tile_row = 0; tile_row < s->s.h.tiling.tile_rows; tile_row++) {
> +set_tile_offset(_row_start, _row_end,
> +tile_row, s->s.h.tiling.log2_tile_rows,
> s->sb_rows);
> +
> +for (row = tile_row_start; row < tile_row_end;
> + row += 8, yoff += ls_y * 64, uvoff += ls_uv * 64 >> s->ss_v)
> {
> +VP9Filter *lflvl_ptr = s->lflvl;
> +ptrdiff_t yoff2 = yoff, uvoff2 = uvoff;
> +
> +for (tile_col = 0; tile_col < s->s.h.tiling.tile_cols;
> tile_col++) {
> +set_tile_offset(_col_start, _col_end,
> +tile_col, s->s.h.tiling.log2_tile_cols,
> s->sb_cols);
> +td->tile_col_start = tile_col_start;
> +if (s->pass != 2) {
> +memset(td->left_partition_ctx, 0, 8);
> +memset(td->left_skip_ctx, 0, 8);
> +if (s->s.h.keyframe || s->s.h.intraonly) {
> +memset(td->left_mode_ctx, DC_PRED, 16);
> +} else {
> +memset(td->left_mode_ctx, NEARESTMV, 8);
> +}
> +memset(td->left_y_nnz_ctx, 0, 16);
> +memset(td->left_uv_nnz_ctx, 0, 32);
> +memset(td->left_segpred_ctx, 0, 8);
> +
> +memcpy(>c, >td[tile_col].c_b[tile_row],
> sizeof(td->c));
> +}
> +
> +for (col = tile_col_start;
> + col < tile_col_end;
> + col += 8, yoff2 += 64 * bytesperpixel,
> + uvoff2 += 64 * bytesperpixel >> s->ss_h,
> lflvl_ptr++) {
> +// FIXME integrate with lf code (i.e. zero after each
> + 

Re: [FFmpeg-devel] [PATCH] avcodec/vp9: Add tile threading support

[Ronald S. Bultje]

Hi,

I would also recommend to split out the changes to add the mainfunc-aware
slice threading implementation (execute3) into pthread_slice.c into its own
patch, that way others can review that without being obstructed by the vp9
bits.

On Tue, Aug 22, 2017 at 7:59 PM, Ilia Valiakhmetov 
wrote:

> -avpriv_slicethread_execute(c->thread, job_count, 0);
> +if (c->m_func)
> +avpriv_slicethread_execute(c->thread, job_count, 1);
> +else
> +avpriv_slicethread_execute(c->thread, job_count, 0);
>

avpriv_slicethread_execute(c->thread, job_count, !!c->m_func);


> -if (!c || (thread_count = avpriv_slicethread_create(>thread,
> avctx, worker_func, NULL, thread_count)) <= 1) {
> +if (!c || (thread_count = avpriv_slicethread_create(>thread,
> avctx, worker_func, main_function, thread_count)) <= 1) {
>

This also affects slice threading without main_func, doesn't it? So
shouldn't main_function being NULL or not depend on whether the slice
threading implementation requires a main func? You could, for example, add
a flag to the AVCodec.capabilities to signal that it has a main function.

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

[FFmpeg-devel] [PATCH]lsws/rgb2rgb: Add unscaled 48 to 64bit conversion

[Carl Eugen Hoyos]

Hi!

Attached patch fixes ticket #6608.

Please comment, Carl Eugen
From 4f8a1de3f216bdb2571e43dcb64a9376aa08ceae Mon Sep 17 00:00:00 2001
From: Carl Eugen Hoyos 
Date: Wed, 23 Aug 2017 14:19:14 +0200
Subject: [PATCH] lsws/rgb2rgb: Add unscale 48bit to 64bit rgb conversion.

Fixes ticket #6608.
---
 libswscale/rgb2rgb.c  |   38 ++
 libswscale/rgb2rgb.h  |4 
 libswscale/swscale_unscaled.c |   17 +
 libswscale/version.h  |2 +-
 4 files changed, 60 insertions(+), 1 deletion(-)

diff --git a/libswscale/rgb2rgb.c b/libswscale/rgb2rgb.c
index f7f8188..d122d60 100644
--- a/libswscale/rgb2rgb.c
+++ b/libswscale/rgb2rgb.c
@@ -391,3 +391,41 @@ void rgb64to48_ ## need_bswap(const uint8_t *src,   \
 
 DEFINE_RGB64TO48(nobswap, 0)
 DEFINE_RGB64TO48(bswap, 1)
+
+#define DEFINE_RGB48TOBGR64(need_bswap, swap)   \
+void rgb48tobgr64_ ## need_bswap(const uint8_t *src,\
+ uint8_t *dst, int src_size)\
+{   \
+uint16_t *d = (uint16_t *)dst;  \
+uint16_t *s = (uint16_t *)src;  \
+int i, num_pixels = src_size / 6;  \
+\
+for (i = 0; i < num_pixels; i++) {  \
+d[4 * i] = swap ? av_bswap16(s[3 * i + 2]) : s[3 * i + 2];  \
+d[4 * i + 1] = swap ? av_bswap16(s[3 * i + 1]) : s[3 * i + 1];  \
+d[4 * i + 2] = swap ? av_bswap16(s[3 * i]) : s[3 * i];  \
+d[4 * i + 3] = 0x;  \
+}   \
+}
+
+DEFINE_RGB48TOBGR64(nobswap, 0)
+DEFINE_RGB48TOBGR64(bswap, 1)
+
+#define DEFINE_RGB48TO64(need_bswap, swap)  \
+void rgb48to64_ ## need_bswap(const uint8_t *src,   \
+ uint8_t *dst, int src_size)\
+{   \
+uint16_t *d = (uint16_t *)dst;  \
+uint16_t *s = (uint16_t *)src;  \
+int i, num_pixels = src_size / 6;  \
+\
+for (i = 0; i < num_pixels; i++) {  \
+d[4 * i] = swap ? av_bswap16(s[3 * i]) : s[3 * i];  \
+d[4 * i + 1] = swap ? av_bswap16(s[3 * i + 1]) : s[3 * i + 1];  \
+d[4 * i + 2] = swap ? av_bswap16(s[3 * i + 2]) : s[3 * i + 2];  \
+d[4 * i + 3] = 0x;  \
+}   \
+}
+
+DEFINE_RGB48TO64(nobswap, 0)
+DEFINE_RGB48TO64(bswap, 1)
diff --git a/libswscale/rgb2rgb.h b/libswscale/rgb2rgb.h
index 0645404..6994839 100644
--- a/libswscale/rgb2rgb.h
+++ b/libswscale/rgb2rgb.h
@@ -59,6 +59,10 @@ void rgb48tobgr48_nobswap(const uint8_t *src, uint8_t *dst, int src_size);
 void   rgb48tobgr48_bswap(const uint8_t *src, uint8_t *dst, int src_size);
 voidrgb64to48_nobswap(const uint8_t *src, uint8_t *dst, int src_size);
 void  rgb64to48_bswap(const uint8_t *src, uint8_t *dst, int src_size);
+void rgb48tobgr64_nobswap(const uint8_t *src, uint8_t *dst, int src_size);
+void   rgb48tobgr64_bswap(const uint8_t *src, uint8_t *dst, int src_size);
+voidrgb48to64_nobswap(const uint8_t *src, uint8_t *dst, int src_size);
+void  rgb48to64_bswap(const uint8_t *src, uint8_t *dst, int src_size);
 voidrgb24to32(const uint8_t *src, uint8_t *dst, int src_size);
 voidrgb32to24(const uint8_t *src, uint8_t *dst, int src_size);
 void rgb16tobgr32(const uint8_t *src, uint8_t *dst, int src_size);
diff --git a/libswscale/swscale_unscaled.c b/libswscale/swscale_unscaled.c
index 3b1b366..ef36aec 100644
--- a/libswscale/swscale_unscaled.c
+++ b/libswscale/swscale_unscaled.c
@@ -1292,6 +1292,23 @@ static rgbConvFn findRgbConvFn(SwsContext *c)
   || CONV_IS(BGR48LE, RGB48BE)
   || CONV_IS(RGB48BE, BGR48LE)
   || CONV_IS(BGR48BE, RGB48LE)) conv = rgb48tobgr48_bswap;
+} else if (isRGB48(srcFormat) && isRGBA64(dstFormat)) {
+if  (CONV_IS(RGB48LE, BGRA64LE)
+  || CONV_IS(BGR48LE, RGBA64LE)
+  || CONV_IS(RGB48BE, BGRA64BE)
+  || CONV_IS(BGR48BE, RGBA64BE)) conv = rgb48tobgr64_nobswap;
+else if (CONV_IS(RGB48LE, BGRA64BE)
+  || CONV_IS(BGR48LE, RGBA64BE)
+  || CONV_IS(RGB48BE, BGRA64LE)
+  || CONV_IS(BGR48BE, RGBA64LE)) conv = rgb48tobgr64_bswap;
+if  

Re: [FFmpeg-devel] [PATCH V4 4/4] lavc/vaapi_encode_h265: respect "slices" option in h265 vaapi encoder

[Steven Liu]

2017-08-23 18:34 GMT+08:00 Jun Zhao :
>
>From dae9051c0828f7c86417308d06f1deb0640534bc Mon Sep 17 00:00:00 2001
From: Jun Zhao 
Date: Tue, 1 Aug 2017 23:07:34 -0400
Subject: [PATCH V4 4/4] lavc/vaapi_encode_h265: respect "slices" option in
 h265 vaapi encoder

Enable multi-slice support in AVC/H.265 vaapi encoder.

Signed-off-by: Wang, Yi A 
Signed-off-by: Jun Zhao 
---
 libavcodec/vaapi_encode_h265.c | 36 ++--
 1 file changed, 30 insertions(+), 6 deletions(-)

diff --git a/libavcodec/vaapi_encode_h265.c b/libavcodec/vaapi_encode_h265.c
index cf6b9388d1..e27b554a98 100644
--- a/libavcodec/vaapi_encode_h265.c
+++ b/libavcodec/vaapi_encode_h265.c
@@ -176,6 +176,8 @@ typedef struct VAAPIEncodeH265Context {
 unsigned int ctu_width;
 unsigned int ctu_height;

+int last_ctu_index;
+
 int fixed_qp_idr;
 int fixed_qp_p;
 int fixed_qp_b;
@@ -962,6 +964,7 @@ static int
vaapi_encode_h265_init_picture_params(AVCodecContext *avctx,
 VAEncPictureParameterBufferHEVC *vpic = pic->codec_picture_params;
 VAAPIEncodeH265Context  *priv = ctx->priv_data;
 int i;
+int slices;

 if (pic->type == PICTURE_TYPE_IDR) {
 av_assert0(pic->display_order == pic->encode_order);
@@ -1024,7 +1027,19 @@ static int
vaapi_encode_h265_init_picture_params(AVCodecContext *avctx,
 av_assert0(0 && "invalid picture type");
 }

-pic->nb_slices = 1;
+slices = 1;
+if (ctx->max_slices) {
+if (avctx->slices <= ctx->max_slices) {
+slices = avctx->slices;
+} else {
+slices = avctx->slices;


What about move this "slices = avctx->slices;" out of the conditional ?


+av_log(avctx, AV_LOG_WARNING, "The max slices number per frame "
+   "cannot more than %d.\n", slices);
+}
+}
+pic->nb_slices = slices;
+
+priv->last_ctu_index = 0;

 return 0;
 }
@@ -1047,9 +1062,10 @@ static int
vaapi_encode_h265_init_slice_params(AVCodecContext *avctx,
 pslice = slice->priv_data;
 mslice = >misc_slice_params;

-// Currently we only support one slice per frame.
-vslice->slice_segment_address = 0;
-vslice->num_ctu_in_slice = priv->ctu_width * priv->ctu_height;
+vslice->slice_segment_address = priv->last_ctu_index;
+vslice->num_ctu_in_slice =
+((slice->index + 1) * priv->ctu_width * priv->ctu_height) /
pic->nb_slices - priv->last_ctu_index;
+priv->last_ctu_index += vslice->num_ctu_in_slice;

 switch (pic->type) {
 case PICTURE_TYPE_IDR:
@@ -1103,9 +1119,13 @@ static int
vaapi_encode_h265_init_slice_params(AVCodecContext *avctx,
 else
 vslice->slice_qp_delta = priv->fixed_qp_idr - vpic->pic_init_qp;

-vslice->slice_fields.bits.last_slice_of_pic_flag = 1;
+if (priv->last_ctu_index == priv->ctu_width * priv->ctu_height)
+vslice->slice_fields.bits.last_slice_of_pic_flag = 1;

-mslice->first_slice_segment_in_pic_flag = 1;
+if (vslice->slice_segment_address == 0)
+mslice->first_slice_segment_in_pic_flag = 1;
+else
+mslice->first_slice_segment_in_pic_flag = 0;


What about:
mslice->first_slice_segment_in_pic_flag = vslice->slice_segment_address ? 0 : 1;
?

 if (pic->type == PICTURE_TYPE_IDR) {
 // No reference pictures.
@@ -1198,6 +1218,10 @@ static av_cold int
vaapi_encode_h265_configure(AVCodecContext *avctx)
 av_assert0(0 && "Invalid RC mode.");
 }

+if (!ctx->max_slices && avctx->slices > 0)
+av_log(avctx, AV_LOG_WARNING, "The encode slice option is not "
+   "supported with the driver.\n");
+
 return 0;
 }

-- 
2.11.0

> ___
> 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

[FFmpeg-devel] [PATCH V4 4/4] lavc/vaapi_encode_h265: respect "slices" option in h265 vaapi encoder

[Jun Zhao]

From dae9051c0828f7c86417308d06f1deb0640534bc Mon Sep 17 00:00:00 2001
From: Jun Zhao 
Date: Tue, 1 Aug 2017 23:07:34 -0400
Subject: [PATCH V4 4/4] lavc/vaapi_encode_h265: respect "slices" option in
 h265 vaapi encoder

Enable multi-slice support in AVC/H.265 vaapi encoder.

Signed-off-by: Wang, Yi A 
Signed-off-by: Jun Zhao 
---
 libavcodec/vaapi_encode_h265.c | 36 ++--
 1 file changed, 30 insertions(+), 6 deletions(-)

diff --git a/libavcodec/vaapi_encode_h265.c b/libavcodec/vaapi_encode_h265.c
index cf6b9388d1..e27b554a98 100644
--- a/libavcodec/vaapi_encode_h265.c
+++ b/libavcodec/vaapi_encode_h265.c
@@ -176,6 +176,8 @@ typedef struct VAAPIEncodeH265Context {
 unsigned int ctu_width;
 unsigned int ctu_height;
 
+int last_ctu_index;
+
 int fixed_qp_idr;
 int fixed_qp_p;
 int fixed_qp_b;
@@ -962,6 +964,7 @@ static int 
vaapi_encode_h265_init_picture_params(AVCodecContext *avctx,
 VAEncPictureParameterBufferHEVC *vpic = pic->codec_picture_params;
 VAAPIEncodeH265Context  *priv = ctx->priv_data;
 int i;
+int slices;
 
 if (pic->type == PICTURE_TYPE_IDR) {
 av_assert0(pic->display_order == pic->encode_order);
@@ -1024,7 +1027,19 @@ static int 
vaapi_encode_h265_init_picture_params(AVCodecContext *avctx,
 av_assert0(0 && "invalid picture type");
 }
 
-pic->nb_slices = 1;
+slices = 1;
+if (ctx->max_slices) {
+if (avctx->slices <= ctx->max_slices) {
+slices = avctx->slices;
+} else {
+slices = avctx->slices;
+av_log(avctx, AV_LOG_WARNING, "The max slices number per frame "
+   "cannot more than %d.\n", slices);
+}
+}
+pic->nb_slices = slices;
+
+priv->last_ctu_index = 0;
 
 return 0;
 }
@@ -1047,9 +1062,10 @@ static int 
vaapi_encode_h265_init_slice_params(AVCodecContext *avctx,
 pslice = slice->priv_data;
 mslice = >misc_slice_params;
 
-// Currently we only support one slice per frame.
-vslice->slice_segment_address = 0;
-vslice->num_ctu_in_slice = priv->ctu_width * priv->ctu_height;
+vslice->slice_segment_address = priv->last_ctu_index;
+vslice->num_ctu_in_slice =
+((slice->index + 1) * priv->ctu_width * priv->ctu_height) / 
pic->nb_slices - priv->last_ctu_index;
+priv->last_ctu_index += vslice->num_ctu_in_slice;
 
 switch (pic->type) {
 case PICTURE_TYPE_IDR:
@@ -1103,9 +1119,13 @@ static int 
vaapi_encode_h265_init_slice_params(AVCodecContext *avctx,
 else
 vslice->slice_qp_delta = priv->fixed_qp_idr - vpic->pic_init_qp;
 
-vslice->slice_fields.bits.last_slice_of_pic_flag = 1;
+if (priv->last_ctu_index == priv->ctu_width * priv->ctu_height)
+vslice->slice_fields.bits.last_slice_of_pic_flag = 1;
 
-mslice->first_slice_segment_in_pic_flag = 1;
+if (vslice->slice_segment_address == 0)
+mslice->first_slice_segment_in_pic_flag = 1;
+else
+mslice->first_slice_segment_in_pic_flag = 0;
 
 if (pic->type == PICTURE_TYPE_IDR) {
 // No reference pictures.
@@ -1198,6 +1218,10 @@ static av_cold int 
vaapi_encode_h265_configure(AVCodecContext *avctx)
 av_assert0(0 && "Invalid RC mode.");
 }
 
+if (!ctx->max_slices && avctx->slices > 0)
+av_log(avctx, AV_LOG_WARNING, "The encode slice option is not "
+   "supported with the driver.\n");
+
 return 0;
 }
 
-- 
2.11.0

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

[FFmpeg-devel] [PATCH V4 2/4] lavc/vaapi_encode: Add max slices number query.

[Jun Zhao]

From 4cac77cf990e91fececaf3dc5bffe606fcdae17c Mon Sep 17 00:00:00 2001
From: Jun Zhao 
Date: Tue, 1 Aug 2017 04:16:30 -0400
Subject: [PATCH V4 2/4] lavc/vaapi_encode: Add max slices number query.

Add max slices number query.

Signed-off-by: Jun Zhao 
---
 libavcodec/vaapi_encode.c | 4 
 libavcodec/vaapi_encode.h | 4 
 2 files changed, 8 insertions(+)

diff --git a/libavcodec/vaapi_encode.c b/libavcodec/vaapi_encode.c
index f49e0e3b91..011aedd9d9 100644
--- a/libavcodec/vaapi_encode.c
+++ b/libavcodec/vaapi_encode.c
@@ -971,6 +971,7 @@ static av_cold int 
vaapi_encode_config_attributes(AVCodecContext *avctx)
 { VAConfigAttribRTFormat },
 { VAConfigAttribRateControl  },
 { VAConfigAttribEncMaxRefFrames  },
+{ VAConfigAttribEncMaxSlices },
 { VAConfigAttribEncPackedHeaders },
 };
 
@@ -1101,6 +1102,9 @@ static av_cold int 
vaapi_encode_config_attributes(AVCodecContext *avctx)
 }
 }
 break;
+case VAConfigAttribEncMaxSlices:
+ctx->max_slices = attr[i].value;
+break;
 case VAConfigAttribEncPackedHeaders:
 if (ctx->va_packed_headers & ~attr[i].value) {
 // This isn't fatal, but packed headers are always
diff --git a/libavcodec/vaapi_encode.h b/libavcodec/vaapi_encode.h
index 364b5b8028..dafbbf5045 100644
--- a/libavcodec/vaapi_encode.h
+++ b/libavcodec/vaapi_encode.h
@@ -164,6 +164,10 @@ typedef struct VAAPIEncodeContext {
 } quality_params;
 #endif
 
+// Supported max-slices number per frame. (0 means driver cannot
+// support max mutil-slices query)
+int max_slices;
+
 // Per-sequence parameter structure (VAEncSequenceParameterBuffer*).
 void   *codec_sequence_params;
 
-- 
2.11.0

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

[FFmpeg-devel] [PATCH V4 3/4] lavc/vaapi_encode_h264: respect "slices" option in h264 vaapi encoder

[Jun Zhao]

From 8795c55762da131ae29554290c1c352eab092580 Mon Sep 17 00:00:00 2001
From: Jun Zhao 
Date: Tue, 1 Aug 2017 23:05:44 -0400
Subject: [PATCH V4 3/4] lavc/vaapi_encode_h264: respect "slices" option in
 h264 vaapi encoder

Enable multi-slice support in AVC/H.264 vaapi encoder.

Signed-off-by: Wang, Yi A 
Signed-off-by: Jun Zhao 
---
 libavcodec/vaapi_encode_h264.c | 32 +++-
 1 file changed, 27 insertions(+), 5 deletions(-)

diff --git a/libavcodec/vaapi_encode_h264.c b/libavcodec/vaapi_encode_h264.c
index 90c7f7e3cc..4a9531bb13 100644
--- a/libavcodec/vaapi_encode_h264.c
+++ b/libavcodec/vaapi_encode_h264.c
@@ -141,6 +141,8 @@ typedef struct VAAPIEncodeH264Context {
 int mb_width;
 int mb_height;
 
+int last_mb_index;
+
 int fixed_qp_idr;
 int fixed_qp_p;
 int fixed_qp_b;
@@ -953,6 +955,7 @@ static int 
vaapi_encode_h264_init_picture_params(AVCodecContext *avctx,
 VAEncPictureParameterBufferH264  *vpic = pic->codec_picture_params;
 VAAPIEncodeH264Context   *priv = ctx->priv_data;
 int i;
+int slices;
 
 if (pic->type == PICTURE_TYPE_IDR) {
 av_assert0(pic->display_order == pic->encode_order);
@@ -998,7 +1001,19 @@ static int 
vaapi_encode_h264_init_picture_params(AVCodecContext *avctx,
 vpic->pic_fields.bits.idr_pic_flag = (pic->type == PICTURE_TYPE_IDR);
 vpic->pic_fields.bits.reference_pic_flag = (pic->type != PICTURE_TYPE_B);
 
-pic->nb_slices = 1;
+slices = 1;
+if (ctx->max_slices) {
+if (avctx->slices <= ctx->max_slices) {
+slices = avctx->slices;
+} else {
+av_log(avctx, AV_LOG_ERROR, "The max slices number per frame "
+   "cannot more than %d.\n", ctx->max_slices);
+return AVERROR_INVALIDDATA;
+}
+}
+pic->nb_slices = slices;
+
+priv->last_mb_index = 0;
 
 return 0;
 }
@@ -1048,14 +1063,17 @@ static int 
vaapi_encode_h264_init_slice_params(AVCodecContext *avctx,
 av_assert0(0 && "invalid picture type");
 }
 
-// Only one slice per frame.
-vslice->macroblock_address = 0;
-vslice->num_macroblocks = priv->mb_width * priv->mb_height;
+vslice->macroblock_address = priv->last_mb_index;
+vslice->num_macroblocks =
+((slice->index + 1) * priv->mb_width * priv->mb_height) / 
pic->nb_slices - priv->last_mb_index;
+priv->last_mb_index += vslice->num_macroblocks;
 
 vslice->macroblock_info = VA_INVALID_ID;
 
 vslice->pic_parameter_set_id = vpic->pic_parameter_set_id;
-vslice->idr_pic_id = priv->idr_pic_count++;
+vslice->idr_pic_id = priv->idr_pic_count;
+if (priv->last_mb_index == priv->mb_width * priv->mb_height)
+priv->idr_pic_count++;
 
 vslice->pic_order_cnt_lsb = (pic->display_order - priv->last_idr_frame) &
 ((1 << (4 + vseq->seq_fields.bits.log2_max_pic_order_cnt_lsb_minus4)) 
- 1);
@@ -1140,6 +1158,10 @@ static av_cold int 
vaapi_encode_h264_configure(AVCodecContext *avctx)
 if (avctx->compression_level == FF_COMPRESSION_DEFAULT)
 avctx->compression_level = opt->quality;
 
+if (!ctx->max_slices && avctx->slices > 0)
+av_log(avctx, AV_LOG_WARNING, "The encode slice option is not "
+   "supported with the driver.\n");
+
 return 0;
 }
 
-- 
2.11.0

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

[FFmpeg-devel] [PATCH V4 1/4] lavc/vaapi_encode: Change the slice/parameter buffers to dynamic alloc.

[Jun Zhao]

V4: - Change the array malloc function.
    - Clean the pointless condition check when free the memory.
      Patch 2/4, 3/4, 4/4 same as V3. 

V3: - Making pic->slices be VAAPIEncodeSlice* instead of VAAPIEncodeSlice**.
- Fix resource (vaBuffer) lead when realloc pic->param_buffers fail.
- Adjust max_slices location in VAAPIEncodeContext.
- Re-work distributing the macro-blocks for multi-slices function.
V2: Change the slice/parameter buffers to dynamic alloc and split
the mutil-slice support for AVC/HEVC.


From a1078385915d53ec94559ed897eb253e537d1f65 Mon Sep 17 00:00:00 2001
From: Jun Zhao 
Date: Mon, 31 Jul 2017 22:46:23 -0400
Subject: [PATCH V4 1/4] lavc/vaapi_encode: Change the slice/parameter buffers
 to dynamic alloc.

Change the slice/parameter buffers to be allocated dynamically.

Signed-off-by: Wang, Yi A 
Signed-off-by: Jun Zhao 
---
 libavcodec/vaapi_encode.c | 44 
 libavcodec/vaapi_encode.h |  6 ++
 2 files changed, 34 insertions(+), 16 deletions(-)

diff --git a/libavcodec/vaapi_encode.c b/libavcodec/vaapi_encode.c
index 22114bedbe..f49e0e3b91 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);
+}
+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);
+}
+pic->param_buffers = tmp;
 
 vas = vaCreateBuffer(ctx->hwctx->display, ctx->va_context,
  type, len, 1, data, );
@@ -313,15 +323,14 @@ static int vaapi_encode_issue(AVCodecContext *avctx,
 }
 }
 
-av_assert0(pic->nb_slices <= MAX_PICTURE_SLICES);
+pic->slices = av_mallocz_array(pic->nb_slices, sizeof(*pic->slices));
+if (!pic->slices) {
+err = AVERROR(ENOMEM);
+goto fail;
+}
 for (i = 0; i < pic->nb_slices; i++) {
-slice = av_mallocz(sizeof(*slice));
-if (!slice) {
-err = AVERROR(ENOMEM);
-goto fail;
-}
+slice = >slices[i];
 slice->index = i;
-pic->slices[i] = slice;
 
 if (ctx->codec->slice_params_size > 0) {
 slice->codec_slice_params = 
av_mallocz(ctx->codec->slice_params_size);
@@ -425,8 +434,16 @@ fail_with_picture:
 fail:
 for(i = 0; i < pic->nb_param_buffers; i++)
 vaDestroyBuffer(ctx->hwctx->display, pic->param_buffers[i]);
+for (i = 0; i < pic->nb_slices; i++) {
+if (pic->slices) {
+av_freep(>slices[i].priv_data);
+av_freep(>slices[i].codec_slice_params);
+}
+}
 fail_at_end:
 av_freep(>codec_picture_params);
+av_freep(>param_buffers);
+av_freep(>slices);
 av_frame_free(>recon_image);
 av_buffer_unref(>output_buffer_ref);
 pic->output_buffer = VA_INVALID_ID;
@@ -535,15 +552,18 @@ static int vaapi_encode_free(AVCodecContext *avctx,
 vaapi_encode_discard(avctx, pic);
 
 for (i = 0; i < pic->nb_slices; i++) {
-av_freep(>slices[i]->priv_data);
-av_freep(>slices[i]->codec_slice_params);
-av_freep(>slices[i]);
+if (pic->slices) {
+av_freep(>slices[i].priv_data);
+av_freep(>slices[i].codec_slice_params);
+}
 }
 av_freep(>codec_picture_params);
 
 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);
 
diff --git a/libavcodec/vaapi_encode.h b/libavcodec/vaapi_encode.h
index 3bf0cc87c7..364b5b8028 100644
--- a/libavcodec/vaapi_encode.h
+++ b/libavcodec/vaapi_encode.h
@@ -35,8 +35,6 @@ enum {
 MAX_CONFIG_ATTRIBUTES  = 4,
 MAX_GLOBAL_PARAMS  = 4,
 MAX_PICTURE_REFERENCES = 2,
-MAX_PICTURE_SLICES = 112,
-MAX_PARAM_BUFFERS  = 128,
 MAX_REORDER_DELAY  = 16,
 

Re: [FFmpeg-devel] [PATCH] avfilter: add Audio Video Sync Test filter

[Nicolas George]

Le sextidi 6 fructidor, an CCXXV, Paul B Mahol a écrit :
> I was asked multiple times to implement this filter.

I was not referring to the advice of single users with a tunnel vision
of their own use case.

> What framework? There is only framework for video source filter which
> outputs static frames.

You are mistaken: testsrc and testsrc2 use that framework and output
variable frames.

> I could make use of sine filter code.

Exactly.

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 3/4] lavc/vaapi_encode_h264: respect "slices" option in h264 vaapi encoder

[Jun Zhao]

On 2017/8/21 1:16, Mark Thompson wrote:
> On 18/08/17 03:14, Jun Zhao wrote:
>> From 64c53df3134c0b478d212f141e6dbe4c3743b3c6 Mon Sep 17 00:00:00 2001
>> From: Jun Zhao 
>> Date: Tue, 1 Aug 2017 23:05:44 -0400
>> Subject: [PATCH V3 3/4] lavc/vaapi_encode_h264: respect "slices" option in
>>  h264 vaapi encoder
>>
>> Enable multi-slice support in AVC/H.264 vaapi encoder.
>>
>> Signed-off-by: Wang, Yi A 
>> Signed-off-by: Jun Zhao 
>> ---
>>  libavcodec/vaapi_encode_h264.c | 32 +++-
>>  1 file changed, 27 insertions(+), 5 deletions(-)
>>
>> diff --git a/libavcodec/vaapi_encode_h264.c b/libavcodec/vaapi_encode_h264.c
>> index f9fcd805a4..74d7480321 100644
>> --- a/libavcodec/vaapi_encode_h264.c
>> +++ b/libavcodec/vaapi_encode_h264.c
>> @@ -141,6 +141,8 @@ typedef struct VAAPIEncodeH264Context {
>>  int mb_width;
>>  int mb_height;
>>  
>> +int last_mb_index;
>> +
>>  int fixed_qp_idr;
>>  int fixed_qp_p;
>>  int fixed_qp_b;
>> @@ -957,6 +959,7 @@ static int 
>> vaapi_encode_h264_init_picture_params(AVCodecContext *avctx,
>>  VAEncPictureParameterBufferH264  *vpic = pic->codec_picture_params;
>>  VAAPIEncodeH264Context   *priv = ctx->priv_data;
>>  int i;
>> +int slices;
>>  
>>  if (pic->type == PICTURE_TYPE_IDR) {
>>  av_assert0(pic->display_order == pic->encode_order);
>> @@ -1002,7 +1005,19 @@ static int 
>> vaapi_encode_h264_init_picture_params(AVCodecContext *avctx,
>>  vpic->pic_fields.bits.idr_pic_flag = (pic->type == PICTURE_TYPE_IDR);
>>  vpic->pic_fields.bits.reference_pic_flag = (pic->type != 
>> PICTURE_TYPE_B);
>>  
>> -pic->nb_slices = 1;
>> +slices = 1;
>> +if (ctx->max_slices) {
>> +if (avctx->slices <= ctx->max_slices) {
>> +slices = avctx->slices;
>> +} else {
>> +av_log(avctx, AV_LOG_ERROR, "The max slices number per frame "
>> +   "cannot more than %d.\n", ctx->max_slices);
>> +return AVERROR_INVALIDDATA;
>> +}
>> +}
>> +pic->nb_slices = slices;
>> +
>> +priv->last_mb_index = 0;
>>  
>>  return 0;
>>  }
>> @@ -1052,14 +1067,17 @@ static int 
>> vaapi_encode_h264_init_slice_params(AVCodecContext *avctx,
>>  av_assert0(0 && "invalid picture type");
>>  }
>>  
>> -// Only one slice per frame.
>> -vslice->macroblock_address = 0;
>> -vslice->num_macroblocks = priv->mb_width * priv->mb_height;
>> +vslice->macroblock_address = priv->last_mb_index;
>> +vslice->num_macroblocks =
>> +((slice->index + 1) * priv->mb_width * priv->mb_height) / 
>> pic->nb_slices - priv->last_mb_index;
>> +priv->last_mb_index += vslice->num_macroblocks;
>>  
>>  vslice->macroblock_info = VA_INVALID_ID;
>>  
>>  vslice->pic_parameter_set_id = vpic->pic_parameter_set_id;
>> -vslice->idr_pic_id = priv->idr_pic_count++;
>> +vslice->idr_pic_id = priv->idr_pic_count;
>> +if (priv->last_mb_index == priv->mb_width * priv->mb_height)
>> +priv->idr_pic_count++;
>>  
>>  vslice->pic_order_cnt_lsb = (pic->display_order - priv->last_idr_frame) 
>> &
>>  ((1 << (4 + 
>> vseq->seq_fields.bits.log2_max_pic_order_cnt_lsb_minus4)) - 1);
>> @@ -1157,6 +1175,10 @@ static av_cold int 
>> vaapi_encode_h264_configure(AVCodecContext *avctx)
>>  #endif
>>  }
>>  
>> +if (!ctx->max_slices && avctx->slices > 0)
>> +av_log(avctx, AV_LOG_WARNING, "The encode slice option is not "
>> +   "supported with the driver.\n");
>> +
>>  return 0;
>>  }
>>  
>> -- 
>> 2.11.0
>>
> I guess this works, but I still think these patches need more thought about / 
> explanation of what the useful result we want actually is.
>
> As such, what is your intended use-case for this?
>
> Some uses for multiple slices that I can think of:
> 1) Optimising encode-time parallelism.
> 2) Optimising decode-time parallelism.
> 3) Imposing slice size limits for some transmission constraint (e.g. RFC 3984 
> video in non-non-interleaved mode).
> 4) Conforming to some standard which requires them (e.g. bluray at higher 
> bitrates).
> (More?)
>
> For VAAPI encode I think both (1) and (3) are irrelevant - (1) doesn't matter 
> because the hardware encoders beign targetted don't use this sort of 
> technique, while (3) is just impossible because of API constraints.  Hence we 
> can consider only (2) and (4).
I think slice structuring is a common error resiliency scheme used in
many video compression, and I've double check the vaMapBufferm(),  get
the comment for pbuf "if buffer type is VAEncCodedBufferType, pbuf points
 to link-list of VACodedBufferSegment" , so in theory it is the API can
output
 slice list (NALUs), but I think i965 don't implement this manner now.
>
> The AVCodecContext.slices option maps directly to the x264 slice_count option 
> to support (2), and I suppose also (4) - this generates slices 

Re: [FFmpeg-devel] [PATCH] avfilter: add Audio Video Sync Test filter

[Paul B Mahol]

On 8/23/17, Nicolas George  wrote:
> Le duodi 2 fructidor, an CCXXV, Paul B Mahol a écrit :
>> You completely ignored and removed other aspects of my reply.
>
> You still are being vague.
>
>> Something special, like one can control both audio and video aspect at
>> once and provide same info to output.
>
> On the usability / convenience question, we obviously disagree. I
> consider that multiplying the test source filters is a more serious
> source of annoyance and confusion for the users, but it is a matter of
> appreciation and you obviously disagree. For that kind of question the
> normal policy would be to ask for the appreciation of other people,
> especially the ones who deal with users on a regular basis, before
> committing.

I was asked multiple times to implement this filter.

>
> As for the technical issues, there are two, and the answer must be
> technical:
>
> This filter includes some amount of boilerplate code, which is a
> maintenance burden. Please make more efforts to reduce that. In this
> particular instance, I believe using the framework that Stefano designed
> for test sources would reduce the boilerplate code.

What framework? There is only framework for video source filter which
outputs static frames.

>
> This filter is not bit-exact. A test source needs very strongly to be
> bit-exact. There is in the code base all that is needed to make it so,
> and that would make it faster as well.

I could make use of sine filter code.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] avfilter: add Audio Video Sync Test filter

[Nicolas George]

Le duodi 2 fructidor, an CCXXV, Paul B Mahol a écrit :
> You completely ignored and removed other aspects of my reply.

You still are being vague.

> Something special, like one can control both audio and video aspect at
> once and provide same info to output.

On the usability / convenience question, we obviously disagree. I
consider that multiplying the test source filters is a more serious
source of annoyance and confusion for the users, but it is a matter of
appreciation and you obviously disagree. For that kind of question the
normal policy would be to ask for the appreciation of other people,
especially the ones who deal with users on a regular basis, before
committing.

As for the technical issues, there are two, and the answer must be
technical:

This filter includes some amount of boilerplate code, which is a
maintenance burden. Please make more efforts to reduce that. In this
particular instance, I believe using the framework that Stefano designed
for test sources would reduce the boilerplate code.

This filter is not bit-exact. A test source needs very strongly to be
bit-exact. There is in the code base all that is needed to make it so,
and that would make it faster as well.

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] all: avoid data imports across DLL boundaries

[wm4]

On Mon, 21 Aug 2017 19:51:56 +0200
wm4  wrote:

> From: Pedro Pombeiro 
> 
> DLL data imports cause problems on Windows. They normally require
> each variable to be correctly marked with dllimport/dllexport
> declspecs. For MSVC, we define av_export to dllimport declspec. This
> is not entirely correct - depending on which sub-lib is built, they
> should be marked to dllexport instead. It happens to work with MSVC,
> because it supports exports incorrectly marked as imports. Trying to
> use this breaks on MinGW and results in linker errors.
> 
> On MinGW, not using any import/export specifiers happens to work,
> because binutils and the MinGW runtime provide "pseudo relocations",
> which manually fix these imports at load time. This does not work with
> MinGW WinRT builds: the relocations cannot be performed because this
> would require writing to the code section, which is not allowed.
> 
> Get rid of all these issues by not using data exports/imports. The
> public API is already free of them, but avpriv_ symbols make extensive
> use of them. Replace them all with getters.
> 
> Signed-off-by: wm4 
> ---

Ping. This is a pretty big change.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 2/6] avcodec/vorbisenc: Apply dynamic frame lengths

[Tomas Härdin]

On 2017-08-22 03:23, Tyler Jones wrote:

+static int create_residues(vorbis_enc_context *venc)
+{
+int res, ret;
+vorbis_enc_residue *rc;
+
+venc->nresidues = 2;
+venc->residues  = av_malloc(sizeof(vorbis_enc_residue) * venc->nresidues);


av_malloc_array()? Applies to most av_malloc() in there



-// single mapping
-mc = >mappings[0];
-mc->submaps = 1;
-mc->mux = av_malloc(sizeof(int) * venc->channels);
-if (!mc->mux)
-return AVERROR(ENOMEM);
-for (i = 0; i < venc->channels; i++)
-mc->mux[i] = 0;
-mc->floor   = av_malloc(sizeof(int) * mc->submaps);
-mc->residue = av_malloc(sizeof(int) * mc->submaps);
-if (!mc->floor || !mc->residue)
-return AVERROR(ENOMEM);
-for (i = 0; i < mc->submaps; i++) {
-mc->floor[i]   = 0;
-mc->residue[i] = 0;
-}
-mc->coupling_steps = venc->channels == 2 ? 1 : 0;
-mc->magnitude  = av_malloc(sizeof(int) * mc->coupling_steps);
-mc->angle  = av_malloc(sizeof(int) * mc->coupling_steps);
-if (!mc->magnitude || !mc->angle)
-return AVERROR(ENOMEM);
-if (mc->coupling_steps) {
-mc->magnitude[0] = 0;
-mc->angle[0] = 1;
+for (map = 0; map < venc->nmappings; map++) {
+mc = >mappings[map];
+mc->submaps = 1;
+mc->mux = av_malloc(sizeof(int) * venc->channels);
+if (!mc->mux)
+return AVERROR(ENOMEM);
+for (i = 0; i < venc->channels; i++)
+mc->mux[i] = 0;
+mc->floor   = av_malloc(sizeof(int) * mc->submaps);
+mc->residue = av_malloc(sizeof(int) * mc->submaps);
+if (!mc->floor || !mc->residue)
+return AVERROR(ENOMEM);
+for (i = 0; i < mc->submaps; i++) {
+mc->floor[i]   = map;
+mc->residue[i] = map;
+}
+mc->coupling_steps = venc->channels == 2 ? 1 : 0;
+mc->magnitude  = av_malloc(sizeof(int) * mc->coupling_steps);
+mc->angle  = av_malloc(sizeof(int) * mc->coupling_steps);
+if (!mc->magnitude || !mc->angle)
+return AVERROR(ENOMEM);
+if (mc->coupling_steps) {
+mc->magnitude[0] = 0;
+mc->angle[0] = 1;
+}
  }


Maybe nitpicking, but it would be clearer what the changes are if you 
put the indentation change in a separate commit




-move_audio(venc, avctx->frame_size);
+if (venc->transient < 0) {
+move_audio(venc, avctx->frame_size);
  
-for (ch = 0; ch < venc->channels; ch++) {

-float *scratch = venc->scratch + 2 * ch * frame_size + frame_size;
+for (ch = 0; ch < venc->channels; ch++) {
+float *scratch = venc->scratch + 2 * ch * long_win + long_win;
  
-if (!ff_psy_vorbis_block_frame(>vpctx, scratch, ch,

-   frame_size, block_size))
-curr_win = 0;
+if (!ff_psy_vorbis_block_frame(>vpctx, scratch, ch,
+   long_win, short_win))
+next_win = 0;
+}
  }


Same here

/Tomas

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

Re: [FFmpeg-devel] [PATCH] Implement NewTek NDI support

[Maksym Veremeyenko]

22.08.2017 23:14, Maksym Veremeyenko пише:
[...]
One more thing I noticed testing, maybe you can take a look: rgba and 
rgb0 format is not working (I used the V1 SDK), only audio frames are 
received, but no apparent error is shown. On the other hand, bgr0 and 
bgra formats do work. If you can't fix it then rgba and rgb0 formats 
should be removed from the supported formats. Also please make the 
docs in sync with the format support changes, I think it now only 
mentions uyvy422.

i think it is related to:

+    /* Create receiver description */
+    recv_create_desc.color_format = NDIlib_recv_color_format_e_UYVY_RGBA;
+    recv_create_desc.bandwidth = NDIlib_recv_bandwidth_highest;
+    recv_create_desc.allow_video_fields = ctx->allow_video_fields;

i will try to check against v1 and v3 SDK...



it is not related to code above. it seems a bug in v1.

not working with v1:

ffmpeg -loop 1 -r 25 -i /usr/local/src/NDI/NDI.Image.png -vf 
"format=pix_fmts=bgr0" -f libndi_newtek -y png_bgr0
ffmpeg -loop 1 -r 25 -i /usr/local/src/NDI/NDI.Image.png -vf 
"format=pix_fmts=bgra" -f libndi_newtek -y png_bgra
ffmpeg -f lavfi -i "testsrc=size=1920x1080:rate=25" -vf 
"format=pix_fmts=rgb0" -f libndi_newtek -y testsrc_rgb0
ffmpeg -f lavfi -i "testsrc=size=1920x1080:rate=25" -vf 
"format=pix_fmts=rgba" -f libndi_newtek -y testsrc_rgba


--
Maksym Veremeyenko

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