Re: [libav-devel] [PATCH 2/2 V3] libavfilter/vf_vpp: Add common filters of the qsv vpp

2017-09-11 Thread Maxym Dmytrychenko 
seems to be fine,
if no other objections will commit shortly

On Wed, Aug 30, 2017 at 3:41 PM, Luca Barbato  wrote:

> On 24/08/2017 04:16, Huang, Zhengxu wrote:
>
>> ---
>> Changes from v2:
>> * Modify the configure file and fix some resources release issues as per
>> Anton's review .
>> * Modify the comments style.
>>---
>> ---
>> Changes from v1:
>> * Add the "deps/select" related to the vpp_qsv in the configure file as
>> per Maxym's review .
>>---
>>
>>
>> ___
>> libav-devel mailing list
>> libav-devel@libav.org
>> https://lists.libav.org/mailman/listinfo/libav-devel
>>
>>
> Maxym, is it fine for you?
>
> lu
> ___
> libav-devel mailing list
> libav-devel@libav.org
> https://lists.libav.org/mailman/listinfo/libav-devel
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel

Re: [libav-devel] [PATCH 11/11] vaapi_mpeg2: Convert to use coded bitstream infrastructure

2017-09-11 Thread Luca Barbato 

On 10/09/2017 01:09, Mark Thompson wrote:

---
  configure   |   2 +-
  libavcodec/vaapi_encode_mpeg2.c | 638 ++--
  2 files changed, 424 insertions(+), 216 deletions(-)



Seems ok.

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

Re: [libav-devel] [PATCH 10/11] mpeg12: Move finding the best frame rate to common code

2017-09-11 Thread Luca Barbato 

On 10/09/2017 01:09, Mark Thompson wrote:

Previously in the mpeg2_metadata filter.  Also adds a test.
---
  libavcodec/Makefile|  1 +
  libavcodec/mpeg12.h|  4 ++
  libavcodec/mpeg12framerate.c   | 64 
  libavcodec/mpeg2_metadata_bsf.c| 58 +++--
  libavcodec/tests/mpeg12framerate.c | 87 ++
  tests/fate/libavcodec.mak  |  5 +++
  6 files changed, 166 insertions(+), 53 deletions(-)
  create mode 100644 libavcodec/tests/mpeg12framerate.c



Ok.

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

Re: [libav-devel] [PATCH 09/11] cbs: Add some read/write tests

2017-09-11 Thread Luca Barbato 

On 10/09/2017 01:09, Mark Thompson wrote:

Use the appropriate metadata filter for each codec - in the absence of any
options to modify the stream, the output bitstream should be identical to
the input (though the output file may differ in padding).

All tests use conformance bitstreams, the MPEG-2 streams are newly added
from the conformance test streams

---
Exact files to add to the samples are at 
, or can be found at the 
link above.

They probably want to separately have an MPEG-2 decode test as well.



OK.

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

Re: [libav-devel] [PATCH 08/11] cbs_mpeg2: Add support for picture display extension

2017-09-11 Thread Luca Barbato 

On 10/09/2017 01:09, Mark Thompson wrote:

---
Many of the conformance test files have it.


  libavcodec/cbs_mpeg2.h |  8 +++
  libavcodec/cbs_mpeg2_syntax_template.c | 44 ++
  2 files changed, 52 insertions(+)

diff --git a/libavcodec/cbs_mpeg2.h b/libavcodec/cbs_mpeg2.h
index 32c4d4e2b..0b6cb998d 100644
--- a/libavcodec/cbs_mpeg2.h
+++ b/libavcodec/cbs_mpeg2.h
@@ -160,6 +160,11 @@ typedef struct MPEG2RawQuantMatrixExtension {
  uint8_t chroma_non_intra_quantiser_matrix[64];
  } MPEG2RawQuantMatrixExtension;
  
+typedef struct MPEG2RawPictureDisplayExtension {

+uint16_t frame_centre_horizontal_offset[3];
+uint16_t frame_centre_vertical_offset[3];
+} MPEG2RawPictureDisplayExtension;
+
  typedef struct MPEG2RawExtensionData {
  uint8_t extension_start_code;
  uint8_t extension_start_code_identifier;
@@ -169,6 +174,7 @@ typedef struct MPEG2RawExtensionData {
  MPEG2RawSequenceDisplayExtension sequence_display;
  MPEG2RawQuantMatrixExtension quant_matrix;
  MPEG2RawPictureCodingExtension picture_coding;
+MPEG2RawPictureDisplayExtension picture_display;
  } data;
  } MPEG2RawExtensionData;
  
@@ -206,6 +212,8 @@ typedef struct CodedBitstreamMPEG2Context {

  uint16_t vertical_size;
  uint8_t scalable;
  uint8_t scalable_mode;
+uint8_t progressive_sequence;
+uint8_t number_of_frame_centre_offsets;
  
  // Write buffer.

  uint8_t *write_buffer;
diff --git a/libavcodec/cbs_mpeg2_syntax_template.c 
b/libavcodec/cbs_mpeg2_syntax_template.c
index b6dd42d2e..4aa1eb3c0 100644
--- a/libavcodec/cbs_mpeg2_syntax_template.c
+++ b/libavcodec/cbs_mpeg2_syntax_template.c
@@ -101,6 +101,7 @@ static int FUNC(sequence_extension)(CodedBitstreamContext 
*ctx, RWContext *rw,
  current->horizontal_size_extension << 12;
  mpeg2->vertical_size = (mpeg2->vertical_size & 0xfff) |
  current->vertical_size_extension << 12;
+mpeg2->progressive_sequence = current->progressive_sequence;
  
  ui(12, bit_rate_extension);

  marker_bit();
@@ -183,6 +184,7 @@ static int FUNC(picture_header)(CodedBitstreamContext *ctx, 
RWContext *rw,
  static int FUNC(picture_coding_extension)(CodedBitstreamContext *ctx, 
RWContext *rw,
MPEG2RawPictureCodingExtension 
*current)
  {
+CodedBitstreamMPEG2Context *mpeg2 = ctx->priv_data;
  int err;
  
  HEADER("Picture Coding Extension");

@@ -204,6 +206,27 @@ static int 
FUNC(picture_coding_extension)(CodedBitstreamContext *ctx, RWContext
  ui(1, chroma_420_type);
  ui(1, progressive_frame);
  
+if (mpeg2->progressive_sequence) {

+if (current->repeat_first_field) {
+if (current->top_field_first)
+mpeg2->number_of_frame_centre_offsets = 3;
+else
+mpeg2->number_of_frame_centre_offsets = 2;
+} else {
+mpeg2->number_of_frame_centre_offsets = 1;
+}
+} else {
+if (current->picture_structure == 1 || // Top field.
+current->picture_structure == 2) { // Bottom field.
+mpeg2->number_of_frame_centre_offsets = 1;
+} else {
+if (current->repeat_first_field)
+mpeg2->number_of_frame_centre_offsets = 3;
+else
+mpeg2->number_of_frame_centre_offsets = 2;
+}
+}
+
  ui(1, composite_display_flag);
  if (current->composite_display_flag) {
  ui(1, v_axis);
@@ -250,6 +273,24 @@ static int 
FUNC(quant_matrix_extension)(CodedBitstreamContext *ctx, RWContext *r
  return 0;
  }
  
+static int FUNC(picture_display_extension)(CodedBitstreamContext *ctx, RWContext *rw,

+   MPEG2RawPictureDisplayExtension 
*current)
+{
+CodedBitstreamMPEG2Context *mpeg2 = ctx->priv_data;
+int err, i;
+
+HEADER("Picture Display Extension");
+
+for (i = 0; i < mpeg2->number_of_frame_centre_offsets; i++) {
+ui(16, frame_centre_horizontal_offset[i]);
+marker_bit();
+ui(16, frame_centre_vertical_offset[i]);
+marker_bit();
+}
+
+return 0;
+}
+
  static int FUNC(extension_data)(CodedBitstreamContext *ctx, RWContext *rw,
  MPEG2RawExtensionData *current)
  {
@@ -270,6 +311,9 @@ static int FUNC(extension_data)(CodedBitstreamContext *ctx, 
RWContext *rw,
  case 3:
  return FUNC(quant_matrix_extension)
  (ctx, rw, >data.quant_matrix);
+case 7:
+return FUNC(picture_display_extension)
+(ctx, rw, >data.picture_display);
  case 8:
  return FUNC(picture_coding_extension)
  (ctx, rw, >data.picture_coding);



Looks fine.
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel

Re: [libav-devel] [PATCH 07/11] cbs_h265: Fix ranges of prediction weight offsets

2017-09-11 Thread Luca Barbato 

On 10/09/2017 01:09, Mark Thompson wrote:

The bracketing was wrong - '-' binds before '<<'.  This would
previously incorrectly reject the streams in the WP_A and WP_B
conformance tests.
---
  libavcodec/cbs_h265_syntax_template.c | 12 ++--
  1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/libavcodec/cbs_h265_syntax_template.c 
b/libavcodec/cbs_h265_syntax_template.c
index 8564220d5..a194887d7 100644
--- a/libavcodec/cbs_h265_syntax_template.c
+++ b/libavcodec/cbs_h265_syntax_template.c
@@ -1133,7 +1133,7 @@ static int FUNC(pred_weight_table)(CodedBitstreamContext 
*ctx, RWContext *rw,
  se(delta_luma_weight_l0[i], -128, +127);
  se(luma_offset_l0[i],
 -(1 << (sps->bit_depth_luma_minus8 + 8 - 1)),
-   +(1 << (sps->bit_depth_luma_minus8 + 8 - 1) - 1));
+   ((1 << (sps->bit_depth_luma_minus8 + 8 - 1)) - 1));
  } else {
  infer(delta_luma_weight_l0[i], 0);
  infer(luma_offset_l0[i],   0);
@@ -1143,7 +1143,7 @@ static int FUNC(pred_weight_table)(CodedBitstreamContext 
*ctx, RWContext *rw,
  se(delta_chroma_weight_l0[i][j], -128, +127);
  se(chroma_offset_l0[i][j],
 -(4 << (sps->bit_depth_chroma_minus8 + 8 - 1)),
-   +(4 << (sps->bit_depth_chroma_minus8 + 8 - 1) - 1));
+   ((4 << (sps->bit_depth_chroma_minus8 + 8 - 1)) - 1));
  }
  } else {
  for (j = 0; j < 2; j++) {
@@ -1173,8 +1173,8 @@ static int FUNC(pred_weight_table)(CodedBitstreamContext 
*ctx, RWContext *rw,
  if (current->luma_weight_l1_flag[i]) {
  se(delta_luma_weight_l1[i], -128, +127);
  se(luma_offset_l1[i],
-   - 1 << (sps->bit_depth_luma_minus8 + 8 - 1),
-   + 1 << (sps->bit_depth_luma_minus8 + 8 - 1) - 1);
+   -(1 << (sps->bit_depth_luma_minus8 + 8 - 1)),
+   ((1 << (sps->bit_depth_luma_minus8 + 8 - 1)) - 1));
  } else {
  infer(delta_luma_weight_l1[i], 0);
  infer(luma_offset_l1[i],   0);
@@ -1183,8 +1183,8 @@ static int FUNC(pred_weight_table)(CodedBitstreamContext 
*ctx, RWContext *rw,
  for (j = 0; j < 2; j++) {
  se(delta_chroma_weight_l1[i][j], -128, +127);
  se(chroma_offset_l1[i][j],
-   - 4 << (sps->bit_depth_chroma_minus8 + 8 - 1),
-   + 4 << (sps->bit_depth_chroma_minus8 + 8 - 1) - 1);
+   -(4 << (sps->bit_depth_chroma_minus8 + 8 - 1)),
+   ((4 << (sps->bit_depth_chroma_minus8 + 8 - 1)) - 1));
  }
  } else {
  for (j = 0; j < 2; j++) {



Seems fine.
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel

Re: [libav-devel] [PATCH 06/11] cbs_h265: Fix reading of unknown parameter set extension data

2017-09-11 Thread Luca Barbato 

On 10/09/2017 01:09, Mark Thompson wrote:

---
  libavcodec/cbs_h265_syntax_template.c | 3 ++-
  1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/libavcodec/cbs_h265_syntax_template.c 
b/libavcodec/cbs_h265_syntax_template.c
index 40fdaf8a9..8564220d5 100644
--- a/libavcodec/cbs_h265_syntax_template.c
+++ b/libavcodec/cbs_h265_syntax_template.c
@@ -67,7 +67,8 @@ static int FUNC(extension_data)(CodedBitstreamContext *ctx, 
RWContext *rw,
  BitstreamContext start;
  uint8_t bit;
  start = *rw;
-for (k = 0; cbs_h2645_read_more_rbsp_data(rw); k++);
+for (k = 0; cbs_h2645_read_more_rbsp_data(rw); k++)
+bitstream_skip(rw, 1);
  current->bit_length = k;
  if (k > 0) {
  *rw = start;



Ok.
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel

Re: [libav-devel] [PATCH 05/11] vaapi_h264: Fix CPB/DPB delays

2017-09-11 Thread Luca Barbato 

On 10/09/2017 01:09, Mark Thompson wrote:

This should be ticks, not time_scale steps - it was wrong for all
framerates not a multiple of 1/2.
---
Apparently I only encode things with framerate a multiple of 1/2.  The
CBS writer catches this immediately for NTSC video - the values are out
of range when multiplied by 1001.


  libavcodec/vaapi_encode_h264.c | 6 ++
  1 file changed, 2 insertions(+), 4 deletions(-)

diff --git a/libavcodec/vaapi_encode_h264.c b/libavcodec/vaapi_encode_h264.c
index 271644ebb..1288249be 100644
--- a/libavcodec/vaapi_encode_h264.c
+++ b/libavcodec/vaapi_encode_h264.c
@@ -612,10 +612,8 @@ static int 
vaapi_encode_h264_init_picture_params(AVCodecContext *avctx,
  if (opt->sei & SEI_TIMING) {
  memset(>pic_timing, 0, sizeof(priv->pic_timing));
  
-priv->pic_timing.cpb_removal_delay =

-2 * sps->vui.num_units_in_tick * priv->cpb_delay;
-priv->pic_timing.dpb_output_delay =
-2 * sps->vui.num_units_in_tick * priv->dpb_delay;
+priv->pic_timing.cpb_removal_delay = 2 * priv->cpb_delay;
+priv->pic_timing.dpb_output_delay  = 2 * priv->dpb_delay;
  
  priv->sei_needed = 1;

  }



Ok.
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel

Re: [libav-devel] [PATCH 04/11] Revert "vaapi_h265: Reduce the amount of padding in the stream"

2017-09-11 Thread Luca Barbato 

On 10/09/2017 01:09, Mark Thompson wrote:

This reverts commit a14a12ca137bf1526452b97bedfc9f7b301d4e04.

The CTU size is always 32x32; the surface size is what actually sets
the desired property, and it is already correct.
---
  libavcodec/vaapi_encode_h265.c | 7 ++-
  1 file changed, 2 insertions(+), 5 deletions(-)

diff --git a/libavcodec/vaapi_encode_h265.c b/libavcodec/vaapi_encode_h265.c
index 165b6ffde..477065e2c 100644
--- a/libavcodec/vaapi_encode_h265.c
+++ b/libavcodec/vaapi_encode_h265.c
@@ -815,11 +815,8 @@ static av_cold int 
vaapi_encode_h265_configure(AVCodecContext *avctx)
  if (err < 0)
  return err;
  
-// This is an Intel driver constraint.  Despite MinCbSizeY being 8,

-// we are still required to encode at 16-pixel alignment and then
-// crop back (so 1080 lines is still encoded as 1088 + cropping).
-priv->ctu_width = FFALIGN(ctx->surface_width,  16) / 16;
-priv->ctu_height= FFALIGN(ctx->surface_height, 16) / 16;
+priv->ctu_width = FFALIGN(ctx->surface_width,  32) / 32;
+priv->ctu_height= FFALIGN(ctx->surface_height, 32) / 32;
  
  av_log(avctx, AV_LOG_VERBOSE, "Input %ux%u -> Surface %ux%u -> CTU %ux%u.\n",

 avctx->width, avctx->height, ctx->surface_width,



Probably ok.
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel

Re: [libav-devel] [PATCH 03/11] h264_metadata: Fix double-free

2017-09-11 Thread Luca Barbato 

On 10/09/2017 01:09, Mark Thompson wrote:

Whether the udu string should be freed depends on whether the SEI it
gets added to was created internally by cbs or externally by the bsf.
The current code frees it twice in the former case.
---
  libavcodec/h264_metadata_bsf.c | 10 +-
  1 file changed, 9 insertions(+), 1 deletion(-)

diff --git a/libavcodec/h264_metadata_bsf.c b/libavcodec/h264_metadata_bsf.c
index 9bf96b397..1afa5014b 100644
--- a/libavcodec/h264_metadata_bsf.c
+++ b/libavcodec/h264_metadata_bsf.c
@@ -293,7 +293,7 @@ static int h264_metadata_filter(AVBSFContext *bsf, AVPacket 
*out)
  H264RawSEI *sei;
  H264RawSEIPayload *payload;
  H264RawSEIUserDataUnregistered *udu;
-int sei_pos;
+int sei_pos, sei_new;
  
  for (i = 0; i < au->nb_units; i++) {

  if (au->units[i].type == H264_NAL_SEI ||
@@ -305,8 +305,10 @@ static int h264_metadata_filter(AVBSFContext *bsf, 
AVPacket *out)
  
  if (sei_pos < au->nb_units &&

  au->units[sei_pos].type == H264_NAL_SEI) {
+sei_new = 0;
  sei = au->units[sei_pos].content;
  } else {
+sei_new = 1;
  sei = >sei_nal;
  memset(sei, 0, sizeof(*sei));
  
@@ -354,6 +356,12 @@ static int h264_metadata_filter(AVBSFContext *bsf, AVPacket *out)
  
  payload->payload_size = 16 + udu->data_length;
  
+if (!sei_new) {

+// This will be freed by the existing internal
+// reference in fragment_uninit().
+sei_udu_string = NULL;
+}
+
  } else {
  invalid_user_data:
  av_log(bsf, AV_LOG_ERROR, "Invalid user data: "



Sure
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel

Re: [libav-devel] [PATCH] qsv: Load the hw hevc plugin by default on Linux

2017-09-11 Thread Maxym Dmytrychenko 
should be so, Luca

On Fri, Sep 8, 2017 at 6:26 AM, Luca Barbato  wrote:

> On 07/09/2017 22:14, Mark Thompson wrote:
>
>> In principle I'm very much in favour, except last time I looked at
>> this there
>> was> ber/080499.html>
>> (and earlier thread).
>>
>> Are you able to test it on Broadwell?  (Or with an older Media SDK
>> version?  Do we care about that?)
>>
>
> On Linux there is only the hw plugin and it gracefully fails (or so I
> remember, Maxym do you confirm? I do not have a pre-broadwell handy due hd
> failure...).
>
> On windows nothing changes since I have that thread in mind :)
>
> lu
> ___
> libav-devel mailing list
> libav-devel@libav.org
> https://lists.libav.org/mailman/listinfo/libav-devel
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel