[libav-devel] VideoLAN Dev Days 2017 Registration

2017-08-07 Thread Jean-Baptiste Kempf
Hello fellow libav geeks and geekettes!

Once again the time for VDD is approaching, and we would like to invite
you to this year's edition, to be held in Paris.

https://vdd.videolan.org/

This technical conference about open source multimedia, will see
developers from VLC, x26*, libbluray, libav, FFmpeg, DVBlast,
PulseAudio, KDE, Gnome, Xiph, handbrake and other projects gather to
discuss about open source development of multimedia projects.

This is a developer conference, so topics will be very technical.

You can find all the information you need on https://vdd.videolan.org/


The registration is open, and you can do so at
https://goo.gl/forms/YJ0IakCQ7WLyUYgr1

Please register as soon as possible, as it will help us organize the
conference.


Please note that the event will be held under the VideoLAN CoC:
https://wiki.videolan.org/Code_of_Conduct/


As usual, VideoLAN will pay for travel, food and hosting costs, for
the active people of the open source community.

If you are working for a company using multimedia open source software,
you are, of course, welcome too. Please know that we are looking for
sponsorships, for this event, though.

If you were sponsored last years, you are sponsored this year too.
If you don't know if you're likely to get sponsorship, please mail us.
If you could buy your flights ASAP, please do so. If you don't know if
the price of your flight is correct, please ask us.
Sponsoring will be granted only to people who register quickly enough.

As the previous years, we'll do an event on the Friday 22. It will
either be a Theme Park (Disney again?) or a custom adventure, followed
by the usual beers or other drinks.
This is of course, optional. (but recommended)

Finally, I'd like to do a call for conferences, to present on Saturday
morning, as the previous years.

With my kindest regards,

-- 
Jean-Baptiste Kempf
___
vlc-devel mailing list
To unsubscribe or modify your subscription options:
https://mailman.videolan.org/listinfo/vlc-devel
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel

Re: [libav-devel] [PATCH 10/22] lavc: Add h264_redundant_pps bitstream filter

2017-08-07 Thread Anton Khirnov
Quoting Mark Thompson (2017-07-29 23:16:33)
> This applies a specific fixup to some Bluray streams which contain
> redundant PPSs modifying irrelevant parameters of the stream which
> confuse other transformations which require correct extradata.
> 
> A new single global PPS is created, and all of the redundant PPSs
> within the stream are removed.
> ---

Seems no changes here, so still ok

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

Re: [libav-devel] [PATCH 09/22] lavc: Add h264_metadata bitstream filter

2017-08-07 Thread Anton Khirnov
Quoting Mark Thompson (2017-07-29 23:16:32)
> This is able to modify some header metadata found in the SPS/VUI,
> and can also add/remove AUDs and insert user data in SEI NAL units.
> ---
> * Adds cropping parameters.
> * SEI user data insert code improved as suggested by Jun Zhao.
> 
> 
>  doc/bitstream_filters.texi |  57 +
>  libavcodec/Makefile|   2 +
>  libavcodec/bitstream_filters.c |   1 +
>  libavcodec/h264_metadata_bsf.c | 490 
> +
>  4 files changed, 550 insertions(+)
>  create mode 100644 libavcodec/h264_metadata_bsf.c
> 
> diff --git a/doc/bitstream_filters.texi b/doc/bitstream_filters.texi
> index af14b67ad..34f0af922 100644
> --- a/doc/bitstream_filters.texi
> +++ b/doc/bitstream_filters.texi
> @@ -39,6 +39,63 @@ When this option is enabled, the long-term headers are 
> removed from the
>  bitstream after extraction.
>  @end table
>  
> +@section h264_metadata
> +
> +Modify metadata embedded in an H.264 stream.
> +
> +@table @option
> +@item aud
> +Insert or remove AUD NAL units in all access units of the stream.
> +
> +@table @samp
> +@item insert
> +@item remove
> +@end table
> +
> +@item sample_aspect_ratio
> +Set the sample aspect ratio in the stream in the VUI parameters.
> +
> +@item video_format
> +@item video_full_range_flag
> +Set the video format in the stream (see H.264 section E.2.1 and
> +table E-2).
> +
> +@item colour_primaries
> +@item transfer_characteristics
> +@item matrix_coefficients
> +Set the colour description in the stream (see H.264 section E.2.1
> +and tables E-3, E-4 and E-5).
> +
> +@item chroma_sample_loc_type
> +Set the chroma sample location in the stream (see H.264 section
> +E.2.1 and figure E-1).
> +
> +@item frame_rate
> +@item fixed_frame_rate_flag
> +Set the frame rate in the VUI parameters (num_units_in_tick /
> +time_scale).  Note that this is likely to be overridden by container
> +parameters when the stream is in a container.
> +
> +@item crop_left
> +@item crop_right
> +@item crop_top
> +@item crop_bottom
> +Set the frame cropping offsets in the SPS.  These values will replace
> +the current ones if the stream is already cropped.
> +
> +The units of these fields are dependent on the chroma subsampling
> +and whether the stream is interlaced (see H.264 section 7.4.2.1.1).

It would be more user-friendly to have crop_* set the values in pixels,
with validity checking and all that, and perhaps in addition crop_*_raw
that set the raw bitstream values. Or maybe just rename those to _raw if
you don't feel like implementing this right now.

> +static int h264_metadata_filter(AVBSFContext *bsf, AVPacket *out)
> +{
> +H264MetadataContext *ctx = bsf->priv_data;
> +AVPacket *in = NULL;
> +CodedBitstreamFragment *au = >access_unit;
> +int err, i, j, has_sps;
> +char *sei_udu_string = NULL;
> +
> +err = ff_bsf_get_packet(bsf, );
> +if (err < 0)
> +goto fail;
> +
> +err = ff_cbs_read_packet(>cbc, au, in);
> +if (err < 0) {
> +av_log(bsf, AV_LOG_ERROR, "Failed to read packet.\n");
> +goto fail;
> +}
> +
> +if (au->nb_units == 0) {
> +av_log(bsf, AV_LOG_ERROR, "No NAL units in packet.\n");
> +err = AVERROR_INVALIDDATA;
> +goto fail;
> +}
> +
> +// If an AUD is present, it must be the first NAL unit.
> +if (au->units[0].type == H264_NAL_AUD) {
> +if (ctx->aud == REMOVE)
> +ff_cbs_delete_unit(>cbc, au, 0);
> +} else {
> +if (ctx->aud == INSERT) {
> +static const int primary_pic_type_table[] = {
> +0x084, // 2, 7
> +0x0a5, // 0, 2, 5, 7
> +0x0e7, // 0, 1, 2, 5, 6, 7
> +0x210, // 4, 9
> +0x318, // 3, 4, 8, 9
> +0x294, // 2, 4, 7, 9
> +0x3bd, // 0, 2, 3, 4, 5, 7, 8, 9
> +0x3ff, // 0, 1, 2, 3, 4, 5, 6, 7, 8, 9
> +};
> +int primary_pic_type_mask = 0xff;
> +H264RawAUD *aud = >aud_nal;
> +
> +for (i = 0; i < au->nb_units; i++) {
> +if (au->units[i].type == H264_NAL_SLICE ||
> +au->units[i].type == H264_NAL_IDR_SLICE) {
> +H264RawSlice *slice = au->units[i].content;
> +for (j = 0; j < FF_ARRAY_ELEMS(primary_pic_type_table); 
> j++) {
> + if (!(primary_pic_type_table[j] &
> +   (1 << slice->header.slice_type)))
> + primary_pic_type_mask &= ~(1 << j);
> +}
> +}
> +}
> +for (j = 0; j < FF_ARRAY_ELEMS(primary_pic_type_table); j++)
> +if (primary_pic_type_mask & (1 << j))
> +break;
> +if (j >= FF_ARRAY_ELEMS(primary_pic_type_table)) {
> +av_log(bsf, AV_LOG_ERROR, "No usable primary_pic_type: "
> +   "invalid 

Re: [libav-devel] [PATCH 1/2] libavfilter/overlay_qsv: Add QSV overlay vpp filter

2017-08-07 Thread wm4
On Mon, 31 Jul 2017 09:25:08 +0800
"Huang, Zhengxu"  wrote:

> 

Wasn't the plan to use slightly more portable APIs like OpenCL instead
for such things?
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel

Re: [libav-devel] [PATCH 08/22] lavc: Add trace_headers bitstream filter

2017-08-07 Thread Anton Khirnov
Quoting Mark Thompson (2017-07-29 23:16:31)
> +static int trace_headers(AVBSFContext *bsf, AVPacket *out)
> +{
> +TraceHeadersContext *ctx = bsf->priv_data;
> +CodedBitstreamFragment au;
> +AVPacket *in;
> +char tmp[256] = { 0 };
> +int err;
> +
> +err = ff_bsf_get_packet(bsf, );
> +if (err < 0)
> +return err;
> +
> +if (in->flags & AV_PKT_FLAG_KEY)
> +av_strlcat(tmp, ", key frame", sizeof(tmp));
> +if (in->flags & AV_PKT_FLAG_CORRUPT)
> +av_strlcat(tmp, ", corrupt", sizeof(tmp));
> +
> +if (in->pts != AV_NOPTS_VALUE)
> +av_strlcatf(tmp, sizeof(tmp), ", pts %"PRId64, in->pts);

since you're going all out here, might as well print 'nopts' for
AV_NOPTS_VALUE

Otherwise looks ok.

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

Re: [libav-devel] [PATCH 06/22] lavc: Add coded bitstream read/write support for H.265

2017-08-07 Thread Anton Khirnov
Quoting Mark Thompson (2017-07-29 23:16:29)
> ---
> * NAL unit header extracted to a separate structure.
> * VPS no longer required (for patch 18).
> * Inferred prediction weights fixed.
> 
> 
>  libavcodec/cbs.c |1 +
>  libavcodec/cbs_h2645.c   |  410 +++-
>  libavcodec/cbs_h265.h|  537 +++
>  libavcodec/cbs_h265_syntax.c | 1502 
> ++
>  libavcodec/cbs_internal.h|1 +
>  5 files changed, 2448 insertions(+), 3 deletions(-)
>  create mode 100644 libavcodec/cbs_h265.h
>  create mode 100644 libavcodec/cbs_h265_syntax.c

Ok

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

Re: [libav-devel] [PATCH 05/22] lavc: Add coded bitstream read/write support for H.264

2017-08-07 Thread Anton Khirnov
Quoting Mark Thompson (2017-07-29 23:16:28)
> ---
>  libavcodec/cbs.c |1 +
>  libavcodec/cbs_h264.h|  427 +++
>  libavcodec/cbs_h2645.c   |  800 +++
>  libavcodec/cbs_h2645.h   |   43 ++
>  libavcodec/cbs_h264_syntax.c | 1230 
> ++
>  libavcodec/cbs_internal.h|3 +
>  6 files changed, 2504 insertions(+)
>  create mode 100644 libavcodec/cbs_h264.h
>  create mode 100644 libavcodec/cbs_h2645.c
>  create mode 100644 libavcodec/cbs_h2645.h
>  create mode 100644 libavcodec/cbs_h264_syntax.c

ok

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

Re: [libav-devel] [PATCH 04/22] lavc: Add coded bitstream read/write API

2017-08-07 Thread Anton Khirnov
Quoting Mark Thompson (2017-07-29 23:16:27)
> ---
>  libavcodec/cbs.c  | 656 
> ++
>  libavcodec/cbs.h  | 274 +++
>  libavcodec/cbs_internal.h |  99 +++
>  3 files changed, 1029 insertions(+)
>  create mode 100644 libavcodec/cbs.c
>  create mode 100644 libavcodec/cbs.h
>  create mode 100644 libavcodec/cbs_internal.h
> 

This one looks unchanged, so still ok

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

Re: [libav-devel] [PATCH 10/10] RFC: generic hwaccel everywhere

2017-08-07 Thread wm4
On Sat,  5 Aug 2017 23:53:11 +0100
Mark Thompson  wrote:

> ---
> This is several patches squashed together to invite thoughts.
> 
> The idea here is that we add a new array of possible hardware configurations 
> to codec definitions, expressed as a hardware device type and the matching 
> pixel format.  We can then use that to set up hwaccels without any additional 
> knowledge at all, creating the appropriate device at startup and then 
> matching the format in get_format in order to use it.
> 
> This is implemented here in lavc with the H.264 decoder and then used in 
> avconv.  There is quite a bit of churn in avconv hardware setup as the choice 
> of device all moves around, but it is hopefully a bit clearer now (and less 
> likely to try to give devices to things not needing them).  "-hwaccel auto" 
> is reimplemented completely as using the first device from the codec config 
> list which can be instantiated.
> 
> 
>  avtools/avconv.c |  57 +
>  avtools/avconv.h |   9 +-
>  avtools/avconv_hw.c  | 233 
> ++-
>  avtools/avconv_opt.c |  41 -
>  libavcodec/avcodec.h |  23 +
>  libavcodec/h264dec.c |  18 
>  6 files changed, 254 insertions(+), 127 deletions(-)
> 
> diff --git a/avtools/avconv.c b/avtools/avconv.c
> index 4e3ffecde..c5b440e08 100644
> --- a/avtools/avconv.c
> +++ b/avtools/avconv.c
> @@ -1631,15 +1631,6 @@ static void print_sdp(void)
>  av_freep();
>  }
>  
> -static const HWAccel *get_hwaccel(enum AVPixelFormat pix_fmt)
> -{
> -int i;
> -for (i = 0; hwaccels[i].name; i++)
> -if (hwaccels[i].pix_fmt == pix_fmt)
> -return [i];
> -return NULL;
> -}
> -
>  static enum AVPixelFormat get_format(AVCodecContext *s, const enum 
> AVPixelFormat *pix_fmts)
>  {
>  InputStream *ist = s->opaque;
> @@ -1647,17 +1638,50 @@ static enum AVPixelFormat get_format(AVCodecContext 
> *s, const enum AVPixelFormat
>  int ret;
>  
>  for (p = pix_fmts; *p != -1; p++) {
> -const AVPixFmtDescriptor *desc = av_pix_fmt_desc_get(*p);
> -const HWAccel *hwaccel;
> +const AVPixFmtDescriptor *desc  = av_pix_fmt_desc_get(*p);
> +const HWAccel *hwaccel  = NULL;
> +const AVCodecHWConfig *hwconfig = NULL;
> +int i;
>  
>  if (!(desc->flags & AV_PIX_FMT_FLAG_HWACCEL))
>  break;
>  
> -hwaccel = get_hwaccel(*p);
> -if (!hwaccel ||
> -(ist->active_hwaccel_id && ist->active_hwaccel_id != 
> hwaccel->id) ||
> -(ist->hwaccel_id != HWACCEL_AUTO && ist->hwaccel_id != 
> hwaccel->id))
> -continue;
> +if (ist->hwaccel_id == HWACCEL_GENERIC && s->codec->hw_configs) {
> +for (i = 0;; i++) {
> +if (s->codec->hw_configs[i].device_type == 
> AV_HWDEVICE_TYPE_NONE)
> +break;
> +if (s->codec->hw_configs[i].pix_fmt == *p) {
> +hwconfig = >codec->hw_configs[i];
> +break;
> +}
> +}
> +}
> +if (hwconfig) {
> +if (hwconfig->device_type != ist->hwaccel_device_type) {
> +// Different hwaccel offered, ignore.
> +continue;
> +}
> +hwaccel = [0];
> +}
> +if (!hwaccel) {
> +int i;
> +hwaccel = NULL;
> +for (i = 1; hwaccels[i].name; i++) {
> +if (hwaccels[i].pix_fmt == *p) {
> +hwaccel = [i];
> +break;
> +}
> +}
> +if (!hwaccel) {
> +// No hwaccel supporting this pixfmt.
> +continue;
> +}
> +if (hwaccel->id != ist->hwaccel_id &&
> +hwaccel->id != HWACCEL_AUTO) {
> +// Does not match requested hwaccel.
> +continue;
> +}
> +}
>  
>  ret = hwaccel->init(s);
>  if (ret < 0) {
> @@ -1677,7 +1701,6 @@ static enum AVPixelFormat get_format(AVCodecContext *s, 
> const enum AVPixelFormat
>  return AV_PIX_FMT_NONE;
>  }
>  
> -ist->active_hwaccel_id = hwaccel->id;
>  ist->hwaccel_pix_fmt   = *p;
>  break;
>  }
> diff --git a/avtools/avconv.h b/avtools/avconv.h
> index b5843fbc0..0d24c71a7 100644
> --- a/avtools/avconv.h
> +++ b/avtools/avconv.h
> @@ -52,13 +52,9 @@
>  enum HWAccelID {
>  HWACCEL_NONE = 0,
>  HWACCEL_AUTO,
> -HWACCEL_VDPAU,
> -HWACCEL_DXVA2,
> +HWACCEL_GENERIC,
>  HWACCEL_VDA,
>  HWACCEL_QSV,
> -HWACCEL_VAAPI,
> -HWACCEL_D3D11VA,
> -HWACCEL_CUVID,
>  };
>  
>  typedef struct HWAccel {
> @@ -66,7 +62,6 @@ typedef struct HWAccel {
>  int (*init)(AVCodecContext *s);
>  enum HWAccelID id;
>  enum AVPixelFormat pix_fmt;
> -enum AVHWDeviceType device_type;
>  } HWAccel;
>  

Re: [libav-devel] [PATCH 06/10] lavfi: Add support for modifying hardware frame pool sizes

2017-08-07 Thread wm4
On Sat,  5 Aug 2017 23:53:07 +0100
Mark Thompson  wrote:

> AVFilterContext.extra_hw_frames functions identically to the field of
> the same name in AVCodecContext.
> ---
> Implemented in such a way that an init_hw_frames callback could be added here 
> as well, if anyone had a use-case for it.
> 
> 
>  doc/APIchanges |  3 +++
>  libavfilter/avfilter.c | 23 +++
>  libavfilter/avfilter.h | 13 +
>  libavfilter/internal.h | 16 
>  4 files changed, 55 insertions(+)
> 
> diff --git a/doc/APIchanges b/doc/APIchanges
> index c111d08ad..5b8143561 100644
> --- a/doc/APIchanges
> +++ b/doc/APIchanges
> @@ -13,6 +13,9 @@ libavutil: 2017-03-23
>  
>  API changes, most recent first:
>  
> +2017-xx-xx - xxx - lavfi 7.x+1.0 - avfilter.h
> +  Add AVFilterContext.extra_hw_frames.
> +
>  2017-xx-xx - xxx - lavc 58.x+1.0 - avcodec.h
>Add AVCodecContext.init_hw_frames and AVCodecContext.extra_hw_frames.
>  
> diff --git a/libavfilter/avfilter.c b/libavfilter/avfilter.c
> index 83c1a7c20..1161f4771 100644
> --- a/libavfilter/avfilter.c
> +++ b/libavfilter/avfilter.c
> @@ -368,6 +368,8 @@ static const AVOption avfilter_options[] = {
>  { "thread_type", "Allowed thread types", OFFSET(thread_type), 
> AV_OPT_TYPE_FLAGS,
>  { .i64 = AVFILTER_THREAD_SLICE }, 0, INT_MAX, FLAGS, "thread_type" },
>  { "slice", NULL, 0, AV_OPT_TYPE_CONST, { .i64 = 
> AVFILTER_THREAD_SLICE }, .unit = "thread_type" },
> +{ "extra_hw_frames", "Number of extra hardware frames to allocate for 
> the user",
> +OFFSET(extra_hw_frames), AV_OPT_TYPE_INT, { .i64 = -1 }, -1, 
> INT_MAX, FLAGS },
>  { NULL },
>  };
>  
> @@ -707,3 +709,24 @@ const AVClass *avfilter_get_class(void)
>  {
>  return _class;
>  }
> +
> +int ff_filter_init_hw_frames(AVFilterContext *avctx, AVFilterLink *link,
> + int default_pool_size)
> +{
> +AVHWFramesContext *frames;
> +
> +// Must already be set by caller.
> +av_assert0(link->hw_frames_ctx);
> +
> +frames = (AVHWFramesContext*)link->hw_frames_ctx->data;
> +
> +if (frames->initial_pool_size == 0) {
> +// Dynamically allocation is necessarily supported.
> +} else if (avctx->extra_hw_frames >= 0) {
> +frames->initial_pool_size += avctx->extra_hw_frames;
> +} else {
> +frames->initial_pool_size = default_pool_size;
> +}
> +
> +return 0;
> +}
> diff --git a/libavfilter/avfilter.h b/libavfilter/avfilter.h
> index 6df69dbbb..c8f861076 100644
> --- a/libavfilter/avfilter.h
> +++ b/libavfilter/avfilter.h
> @@ -311,6 +311,19 @@ struct AVFilterContext {
>   * hardware context information.
>   */
>  AVBufferRef *hw_device_ctx;
> +
> +/**
> + * Sets the number of extra hardware frames which the filter will
> + * allocate on its output links for use in following filters or by
> + * the caller.
> + *
> + * Some hardware filters require all frames that they will use for
> + * output to be defined in advance before filtering starts.  For such
> + * filters, any hardware frame pools used for output must therefore be
> + * of fixed size.  The extra frames set here are on top of any number
> + * that the filter needs internally in order to operate normally.
> + */
> +int extra_hw_frames;
>  };
>  
>  /**
> diff --git a/libavfilter/internal.h b/libavfilter/internal.h
> index a377f9b2b..d17f917c6 100644
> --- a/libavfilter/internal.h
> +++ b/libavfilter/internal.h
> @@ -226,4 +226,20 @@ void ff_filter_graph_remove_filter(AVFilterGraph *graph, 
> AVFilterContext *filter
>   */
>  #define FF_FILTER_FLAG_HWFRAME_AWARE (1 << 0)
>  
> +/**
> + * Perform any additional setup required for hardware frames.
> + *
> + * link->hw_frames_ctx must be set before calling this function.
> + * Inside link->hw_frames_ctx, the fields format, sw_format, width and
> + * height must be set.  If dynamically allocated pools are not supported,
> + * then initial_pool_size must also be set, to the minimum hardware frame
> + * pool size necessary for decode (taking into account reference frames
> + * and delay as appropriate).  If default_pool_size is nonzero, then it
> + * will be used as the pool size if no other modification takes place
> + * (this can be used to preserve compatibility).
> + */
> +int ff_filter_init_hw_frames(AVFilterContext *avctx, AVFilterLink *link,
> + int default_pool_size);
> +
> +
>  #endif /* AVFILTER_INTERNAL_H */

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

Re: [libav-devel] [PATCH 01/10] lavc: Add support for external hardware frame pool initialisation

2017-08-07 Thread wm4
On Sat,  5 Aug 2017 23:53:02 +0100
Mark Thompson  wrote:

> This can be used to refine the parameters of lavc-created hardware frames
> contexts - this is useful for APIs which require some use information to
> to be supplied at create time, such as DXVA2 and D3D11VA.  (Suggested by
> wm4 ).
> 
> Also adds a field extra_hw_frames, which supports simple cases where the
> only modification to the default parameters required is to increase the
> size of a fixed-size pool.
> ---
> As discussed quite a while ago.
> 
> 
>  doc/APIchanges |  3 +++
>  libavcodec/avcodec.h   | 36 
>  libavcodec/decode.c| 24 
>  libavcodec/internal.h  | 17 +
>  libavcodec/options_table.h |  1 +
>  5 files changed, 81 insertions(+)
> 
> diff --git a/doc/APIchanges b/doc/APIchanges
> index 463247f48..c111d08ad 100644
> --- a/doc/APIchanges
> +++ b/doc/APIchanges
> @@ -13,6 +13,9 @@ libavutil: 2017-03-23
>  
>  API changes, most recent first:
>  
> +2017-xx-xx - xxx - lavc 58.x+1.0 - avcodec.h
> +  Add AVCodecContext.init_hw_frames and AVCodecContext.extra_hw_frames.
> +
>  2017-xx-xx - xxx - lavu 56.4.0 - imgutils.h
>Add av_image_fill_black().
>  
> diff --git a/libavcodec/avcodec.h b/libavcodec/avcodec.h
> index 162f1abe4..847b7f139 100644
> --- a/libavcodec/avcodec.h
> +++ b/libavcodec/avcodec.h
> @@ -2725,6 +2725,42 @@ typedef struct AVCodecContext {
>   * AVCodecContext.get_format callback)
>   */
>  int hwaccel_flags;
> +
> +/**
> + * Video decoding only.  If set by the user, this will be called when
> + * new hardware frames need to be allocated following a get_format()
> + * callback which indicated that hardware decoding should be used but
> + * did not set s->hw_frames_ctx.
> + *
> + * When called, s->hw_frames_ctx will be allocated on the device in
> + * s->hw_device_ctx and have basic parameters set (required pool size,
> + * frame dimensions and surface format).  The user can then further
> + * refine the parameters as required for their use-case - for example,
> + * by setting API-specific values in AVHWFramesContext.hwctx, or by
> + * increasing the size of allocated frames to meet some external
> + * constraint.  Do not call av_hwframe_ctx_init() from this callback -
> + * it will be called later by lavc.
> + *
> + * This function should normally return zero.  If it encounters some
> + * error (e.g. if the user knows that frames of the requested form will
> + * not be usable), it must return a negative error code and decoder
> + * initialisation will then fail, returning control to the user.
> + */
> +int (*init_hw_frames)(struct AVCodecContext *s);
> +
> +/**
> + * Video decoding only.  Sets the number of extra hardware frames which
> + * the decoder will allocate for use by the caller.  This is only used
> + * if hw_device_ctx is set.
> + *
> + * Some hardware decoders require all frames that they will use for
> + * output to be defined in advance before decoding starts.  For such
> + * decoders, the hardware frame pool must therefore be of a fixed size.
> + * The extra frames set here are on top of any number that the decoder
> + * needs internally in order to operate normally (for example, frames
> + * used as reference pictures).
> + */
> +int extra_hw_frames;
>  } AVCodecContext;
>  
>  /**
> diff --git a/libavcodec/decode.c b/libavcodec/decode.c
> index c76ee6696..6d6088eaa 100644
> --- a/libavcodec/decode.c
> +++ b/libavcodec/decode.c
> @@ -767,6 +767,30 @@ int ff_get_format(AVCodecContext *avctx, const enum 
> AVPixelFormat *fmt)
>  return ret;
>  }
>  
> +int ff_init_hw_frames(AVCodecContext *avctx)
> +{
> +AVHWFramesContext *frames;
> +int err;
> +
> +// Must already be set by caller.
> +av_assert0(avctx->hw_frames_ctx);
> +
> +frames = (AVHWFramesContext*)avctx->hw_frames_ctx->data;
> +
> +if (avctx->init_hw_frames) {
> +err = avctx->init_hw_frames(avctx);
> +if (err < 0)
> +return err;
> +} else if (frames->initial_pool_size == 0) {
> +// Dynamically allocation is necessarily supported.
> +} else {
> +if (avctx->extra_hw_frames >= 0)
> +frames->initial_pool_size += avctx->extra_hw_frames;
> +}
> +
> +return 0;
> +}
> +
>  static int update_frame_pool(AVCodecContext *avctx, AVFrame *frame)
>  {
>  FramePool *pool = avctx->internal->pool;
> diff --git a/libavcodec/internal.h b/libavcodec/internal.h
> index 403fb4a09..023d94285 100644
> --- a/libavcodec/internal.h
> +++ b/libavcodec/internal.h
> @@ -276,6 +276,23 @@ int ff_side_data_update_matrix_encoding(AVFrame *frame,
>  int ff_get_format(AVCodecContext *avctx, const enum AVPixelFormat *fmt);
>  
>  /**
> + * Perform any additional setup 

Re: [libav-devel] [PATCH 1/2 V4] libavfilter/overlay_qsv: Add QSV overlay vpp filter

2017-08-07 Thread Anton Khirnov
Quoting Huang, Zhengxu (2017-08-04 04:05:28)
>diff --git a/configure b/configure
>index 4510100..e6ea18a 100755
>--- a/configure
>+++ b/configure
>@@ -1786,6 +1786,7 @@ CONFIG_EXTRA="
> qsv
> qsvdec
> qsvenc
>+qsvvpp
> rangecoder
> riffdec
> riffenc
>@@ -2528,6 +2529,8 @@ hqdn3d_filter_deps="gpl"
> interlace_filter_deps="gpl"
> movie_filter_deps="avcodec avformat"
> ocv_filter_deps="libopencv"
>+overlay_qsv_filter_deps="libmfx"
>+overlay_qsv_filter_select="qsvvpp"
> resample_filter_deps="avresample"
> scale_filter_deps="swscale"
> scale_qsv_filter_deps="libmfx"
>diff --git a/libavfilter/Makefile b/libavfilter/Makefile
>index 348ad92..8d9ed6a 100644
>--- a/libavfilter/Makefile
>+++ b/libavfilter/Makefile
>@@ -75,6 +75,7 @@ OBJS-$(CONFIG_NOFORMAT_FILTER)   += vf_format.o
> OBJS-$(CONFIG_NULL_FILTER)   += vf_null.o
> OBJS-$(CONFIG_OCV_FILTER)+= vf_libopencv.o
> OBJS-$(CONFIG_OVERLAY_FILTER)+= vf_overlay.o
>+OBJS-$(CONFIG_OVERLAY_QSV_FILTER)+= qsvvpp.o vf_overlay_qsv.o

Since you're adding a 'qsvvpp' subsystem to configure, the proper thing to do
here is start a new block for subsystems in the Makefile (as in
libavcodec/Makefile) with
OBJS-$(CONFIG_QSVVPP) += qsvvpp.o
Then none of the filters depend on qsvvpp.o directly, since that gets selected
through configure.

> OBJS-$(CONFIG_PAD_FILTER)+= vf_pad.o
> OBJS-$(CONFIG_PIXDESCTEST_FILTER)+= vf_pixdesctest.o
> OBJS-$(CONFIG_SCALE_FILTER)  += vf_scale.o
>@@ -104,5 +105,7 @@ OBJS-$(CONFIG_NULLSRC_FILTER)+= 
>vsrc_nullsrc.o
> OBJS-$(CONFIG_RGBTESTSRC_FILTER) += vsrc_testsrc.o
> OBJS-$(CONFIG_TESTSRC_FILTER)+= vsrc_testsrc.o
> 
>+SKIPHEADERS-$(CONFIG_QSV)+= qsvvpp.h

Shouldn't this be CONFIG_QSVVPP?

>diff --git a/libavfilter/qsvvpp.c b/libavfilter/qsvvpp.c
>new file mode 100644
>index 000..74574bb
>--- /dev/null
>+++ b/libavfilter/qsvvpp.c
>@@ -0,0 +1,699 @@
>+/*
>+ * This file is part of Libav.
>+ *
>+ * Libav is free software; you can redistribute it and/or
>+ * modify it under the terms of the GNU Lesser General Public
>+ * License as published by the Free Software Foundation; either
>+ * version 2.1 of the License, or (at your option) any later version.
>+ *
>+ * Libav is distributed in the hope that it will be useful,
>+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
>+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
>+ * Lesser General Public License for more details.
>+ *
>+ * You should have received a copy of the GNU Lesser General Public
>+ * License along with Libav; if not, write to the Free Software
>+ * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 
>USA
>+ */
>+/**
>+ * @file
>+ * Intel Quick Sync Video VPP base function
>+ */
>+
>+#include "libavutil/common.h"
>+#include "libavutil/mathematics.h"
>+#include "libavutil/hwcontext.h"
>+#include "libavutil/hwcontext_qsv.h"
>+#include "libavutil/time.h"
>+#include "libavutil/pixdesc.h"
>+#include "internal.h"
>+#include "qsvvpp.h"
>+#include "video.h"
>+
>+typedef struct QSVFrame {
>+AVFrame  *frame;
>+mfxFrameSurface1 *surface;
>+mfxFrameSurface1  surface_internal;  ///< for system memory
>+struct QSVFrame  *next;
>+} QSVFrame;
>+
>+/* abstract struct for all QSV filters */
>+struct FFQSVVPPContext {

There is no need to add the 'FF' prefix to internal structs. They are not
visible in the compiled objects as a part of the ABI, so there's no risk of
conflicts. And since the name is already rather long and unreadable it's better
to not make it even longer.

>+/* fill the surface info */
>+static int fill_frameinfo_by_link(mfxFrameInfo *frameinfo, AVFilterLink *link)
>+{
>+enum AVPixelFormatpix_fmt;
>+AVHWFramesContext*frames_ctx;
>+const AVPixFmtDescriptor *desc;
>+
>+if (link->format == AV_PIX_FMT_QSV) {
>+if (!link->hw_frames_ctx)
>+return AVERROR(EINVAL);
>+
>+frames_ctx = (AVHWFramesContext *)link->hw_frames_ctx->data;
>+pix_fmt = frames_ctx->sw_format;
>+} else
>+pix_fmt = link->format;
>+
>+desc = av_pix_fmt_desc_get(pix_fmt);
>+if (!desc)
>+return AVERROR_BUG;
>+
>+frameinfo->CropX  = 0;
>+frameinfo->CropY  = 0;
>+frameinfo->CropW  = link->w;
>+frameinfo->CropH  = link->h;
>+frameinfo->Width  = FFALIGN(link->w, 32);
>+frameinfo->Height = FFALIGN(link->h, 32);

This looks dangerous. There is no guarantee that the dimensions are specifically
aligned to 32. For QSV format frames you have access to the mfxFrameInfo struct
in the AVQSVFramesContext.
For system memory frames you need to check that the input frames are
sufficiently aligned.

>+/* create the QSV session */
>+static int init_vpp_session(AVFilterContext *avctx,