Re: [FFmpeg-devel] [PATCH 1/1] avcodec/aacenc: Validate and log bitrate changes made during encoding

[Rostislav Pehlivanov]

On Sat, 9 Mar 2019 at 12:56, Oliver Collyer  wrote:

> Although accenc appears able to cope with dynamic bitrate changes, this
> patch makes sure that any such changes are validated in the same manner as
> the initial bitrate and also adds logging of such changes in verbose mode.
>
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> https://ffmpeg.org/mailman/listinfo/ffmpeg-devel


I think its better to leave the bitrate default bitrate setting in init,
remove the last_bit_rate variable entirely and always do limiting at the
start of the encode_frame function. Don't bother with printing out bitrate
changes, users can assume the encoder will start using it.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 1/3] avutil/attributes: add av_likely and av_unlikely

[Rostislav Pehlivanov]

On Thu, 24 Jan 2019 at 20:38, Marton Balint  wrote:

> Signed-off-by: Marton Balint 
> ---
>  doc/APIchanges | 3 +++
>  libavutil/attributes.h | 8 
>  libavutil/version.h| 2 +-
>  3 files changed, 12 insertions(+), 1 deletion(-)
>
> diff --git a/doc/APIchanges b/doc/APIchanges
> index a39a3ff2ba..38b5b980a6 100644
> --- a/doc/APIchanges
> +++ b/doc/APIchanges
> @@ -15,6 +15,9 @@ libavutil: 2017-10-21
>
>  API changes, most recent first:
>
> +2019-01-xx - xx - lavu 56.27.100 - attributes.h
> +  Add av_likely and av_unlikely
> +
>  2019-01-08 - xx - lavu 56.26.100 - frame.h
>Add AV_FRAME_DATA_REGIONS_OF_INTEREST
>
> diff --git a/libavutil/attributes.h b/libavutil/attributes.h
> index ced108aa2c..60972e5109 100644
> --- a/libavutil/attributes.h
> +++ b/libavutil/attributes.h
> @@ -164,4 +164,12 @@
>  #define av_noreturn
>  #endif
>
> +#if AV_GCC_VERSION_AT_LEAST(2,96) || defined(__clang__)
> +# define av_likely(x)  __builtin_expect(!!(x), 1)
> +# define av_unlikely(x)__builtin_expect(!!(x), 0)
> +#else
> +# define av_likely(x)  (x)
> +# define av_unlikely(x)(x)
> +#endif
> +
>  #endif /* AVUTIL_ATTRIBUTES_H */
> diff --git a/libavutil/version.h b/libavutil/version.h
> index 1fcdea95bf..12b4f9fc3a 100644
> --- a/libavutil/version.h
> +++ b/libavutil/version.h
> @@ -79,7 +79,7 @@
>   */
>
>  #define LIBAVUTIL_VERSION_MAJOR  56
> -#define LIBAVUTIL_VERSION_MINOR  26
> +#define LIBAVUTIL_VERSION_MINOR  27
>  #define LIBAVUTIL_VERSION_MICRO 100
>
>  #define LIBAVUTIL_VERSION_INT   AV_VERSION_INT(LIBAVUTIL_VERSION_MAJOR, \
> --
> 2.16.4
>
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel



NAK, NAK, NAK.
I will NAK the hell out of any patch that does that. They're completely
unnecessary, they're commonly used by complete idiots who add them thinking
their code will go faster (and it might - only on their antiquated GCC
3.1), they're religiously used by the same people and won't back down on
using them and finally they're ugly when added to every single bloody
branch and the people who maintain such code will demand they be added to
every single bloody branch for no reason other that what I've just iterated
on.
The ONLY way I'll accept them is in platform-specific files, e.g.
libavcodec/ppc/*, and even then only on non-x86 arches (which need them for
having bad compilers with primitive processors having awful branch
prediction) and even then I'd never accept their inclusioin into
system-installed headers.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] Support HDR dynamic metadata (HDR10+) in HEVC decoder.

[Rostislav Pehlivanov]

On Tue, 22 Jan 2019 at 18:01, Mohammad Izadi  wrote:

> ---
>  libavcodec/hevc_sei.c | 211 --
>  libavcodec/hevc_sei.h |   6 ++
>  libavcodec/hevcdec.c  |  22 +
>  3 files changed, 233 insertions(+), 6 deletions(-)
>
> diff --git a/libavcodec/hevc_sei.c b/libavcodec/hevc_sei.c
> index c59bd4321e..6edec9f0db 100644
> --- a/libavcodec/hevc_sei.c
> +++ b/libavcodec/hevc_sei.c
> @@ -25,6 +25,7 @@
>  #include "golomb.h"
>  #include "hevc_ps.h"
>  #include "hevc_sei.h"
> +#include "libavutil/hdr_dynamic_metadata.h"
>
>  static int decode_nal_sei_decoded_picture_hash(HEVCSEIPictureHash *s,
> GetBitContext *gb)
>  {
> @@ -206,10 +207,179 @@ static int
> decode_registered_user_data_closed_caption(HEVCSEIA53Caption *s, GetB
>  return 0;
>  }
>
> -static int decode_nal_sei_user_data_registered_itu_t_t35(HEVCSEI *s,
> GetBitContext *gb,
> +static int decode_registered_user_data_dynamic_hdr_plus(AVDynamicHDRPlus
> *s, GetBitContext *gb,
> +void *logctx, int
> size)
> +{
> +const int luminance_den = 1;
> +const int peak_luminance_den = 15;
> +const int rgb_den = 10;
> +const int fraction_pixel_den = 1000;
> +const int knee_point_den = 4095;
> +const int bezier_anchor_den = 1023;
> +const int saturation_weight_den = 8;
> +
> +int w, i, j;
> +
> +if (get_bits_left(gb) < size * 8)
> +return AVERROR_INVALIDDATA;
> +
> +if (get_bits_left(gb) < 2)
> +return AVERROR_INVALIDDATA;
> +s->num_windows = get_bits(gb, 2);
> +if (s->num_windows < 1 || s->num_windows > 3) {
> +av_log(logctx, AV_LOG_ERROR, "num_windows=%d, must be in [1,
> 3]\n",
> +   s->num_windows);
> +return AVERROR_INVALIDDATA;
> +}
> +
> +if (get_bits_left(gb) < ((19 * 8 + 1) * (s->num_windows - 1)))
> +return AVERROR_INVALIDDATA;
>

Put a newline here?


+for (w = 1; w < s->num_windows; w++) {
> +s->params[w].window_upper_left_corner_x.num = get_bits(gb, 16);
> +s->params[w].window_upper_left_corner_y.num = get_bits(gb, 16);
> +s->params[w].window_lower_right_corner_x.num = get_bits(gb, 16);
> +s->params[w].window_lower_right_corner_y.num = get_bits(gb, 16);
> +// The corners are set to absolute coordinates here. They should
> be
> +// converted to the relative coordinates (in [0, 1]) in the
> decoder.
> +s->params[w].window_upper_left_corner_x.den = 1;
> +s->params[w].window_upper_left_corner_y.den = 1;
> +s->params[w].window_lower_right_corner_x.den = 1;
> +s->params[w].window_lower_right_corner_y.den = 1;
> +
> +s->params[w].center_of_ellipse_x = get_bits(gb, 16);
> +s->params[w].center_of_ellipse_y = get_bits(gb, 16);
> +s->params[w].rotation_angle = get_bits(gb, 8);
> +s->params[w].semimajor_axis_internal_ellipse = get_bits(gb, 16);
> +s->params[w].semimajor_axis_external_ellipse = get_bits(gb, 16);
> +s->params[w].semiminor_axis_external_ellipse = get_bits(gb, 16);
> +s->params[w].overlap_process_option = get_bits(gb, 1);
> +}
> +
> +if (get_bits_left(gb) < 28)
> +return AVERROR(EINVAL);
>

And here.


+s->targeted_system_display_maximum_luminance.num = get_bits(gb, 27);
> +s->targeted_system_display_maximum_luminance.den = luminance_den;
> +s->targeted_system_display_actual_peak_luminance_flag = get_bits(gb,
> 1);
> +
> +if (s->targeted_system_display_actual_peak_luminance_flag) {
> +int rows, cols;
> +if (get_bits_left(gb) < 10)
> +return AVERROR(EINVAL);
> +rows = get_bits(gb, 5);
> +cols = get_bits(gb, 5);
> +if (((rows < 2) || (rows > 25)) || ((cols < 2) || (cols > 25))) {
> +av_log(logctx, AV_LOG_ERROR, "num_rows=%d, num_cols=%d, they
> must [2, 25] for targeted_system_display_actual_peak_luminance\n", rows,
> cols);
> +return AVERROR_INVALIDDATA;
> +}
> +s->num_rows_targeted_system_display_actual_peak_luminance = rows;
> +s->num_cols_targeted_system_display_actual_peak_luminance = cols;
> +
> +if (get_bits_left(gb) < (rows * cols * 4))
> +return AVERROR(EINVAL);
> +
> +for (i = 0; i < rows; i++) {
> +for (j = 0; j < cols; j++) {
> +
> s->targeted_system_display_actual_peak_luminance[i][j].num = get_bits(gb,
> 4);
> +
> s->targeted_system_display_actual_peak_luminance[i][j].den =
> peak_luminance_den;
> +}
> +}
> +}
>

Same.



> +for (w = 0; w < s->num_windows; w++) {
> +if (get_bits_left(gb) < (3 * 17 + 17 + 4))
> +return AVERROR(EINVAL);
> +for (i = 0; i < 3; i++) {
> +s->params[w].maxscl[i].num = get_bits(gb, 17);
> +s->params[w].maxscl[i].den = rgb_den;
> +}
> +s->params[w].average_maxrgb.num = get_bits(gb, 17);
> +s->para

Re: [FFmpeg-devel] [PATCH v2] Improved the performance of 1 decode + N filter graphs and adaptive bitrate.

[Rostislav Pehlivanov]

On Tue, 15 Jan 2019 at 11:57, Carl Eugen Hoyos  wrote:

> 2019-01-15 11:30 GMT+01:00, Rostislav Pehlivanov :
> > On Tue, 15 Jan 2019 at 09:24, Shaofei Wang 
> wrote:
>
> >> +#if HAVE_THREADS
> >> +if (!abr_pipeline) {
> >> +ret = reap_filters(1);
> >> +} else {
> >> +ret = pipeline_reap_filters(1, ifilter);
> >> +}
> >>
> >
> > Same.
>
> This hunk should have brackets, it simplifies
> debugging and future patches at very little cost.
>

No, it does not. It wastes a line.


> ___
> 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 v2] Improved the performance of 1 decode + N filter graphs and adaptive bitrate.

[Rostislav Pehlivanov]

On Tue, 15 Jan 2019 at 09:24, Shaofei Wang  wrote:

> With new option "-abr_pipeline"
> It enabled multiple filter graph concurrency, which bring obove about
> 4%~20% improvement in some 1:N scenarios by CPU or GPU acceleration
>
> Below are some test cases and comparison as reference.
> (Hardware platform: Intel(R) Core(TM) i7-6700 CPU @ 3.40GHz)
> (Software: Intel iHD driver - 16.9.00100, CentOS 7)
>
> For 1:N transcode by GPU acceleration with vaapi:
> ./ffmpeg -vaapi_device /dev/dri/renderD128 -hwaccel vaapi \
> -hwaccel_output_format vaapi \
> -i ~/Videos/1920x1080p_30.00_x264_qp28.h264 \
> -vf "scale_vaapi=1280:720" -c:v h264_vaapi -f null /dev/null \
> -vf "scale_vaapi=720:480" -c:v h264_vaapi -f null /dev/null \
> -abr_pipeline
>
> test results:
> 2 encoders 5 encoders 10 encoders
> Improved   6.1%6.9%   5.5%
>
> For 1:N transcode by GPU acceleration with QSV:
> ./ffmpeg -hwaccel qsv -c:v h264_qsv \
> -i ~/Videos/1920x1080p_30.00_x264_qp28.h264 \
> -vf "scale_qsv=1280:720:format=nv12" -c:v h264_qsv -f null /dev/null \
> -vf "scale_qsv=720:480:format=nv12" -c:v h264_qsv -f null /dev/null
>
> test results:
> 2 encoders  5 encoders 10 encoders
> Improved   6%   4% 15%
>
> For Intel GPU acceleration case, 1 decode to N scaling, by QSV:
> ./ffmpeg -hwaccel qsv -c:v h264_qsv \
> -i ~/Videos/1920x1080p_30.00_x264_qp28.h264 \
> -vf "scale_qsv=1280:720:format=nv12,hwdownload" -pix_fmt nv12 -f null
> /dev/null \
> -vf "scale_qsv=720:480:format=nv12,hwdownload" -pix_fmt nv12 -f null
> /dev/null
>
> test results:
> 2 scale  5 scale   10 scale
> Improved   12% 21%21%
>
> For CPU only 1 decode to N scaling:
> ./ffmpeg -i ~/Videos/1920x1080p_30.00_x264_qp28.h264 \
> -vf "scale=1280:720" -pix_fmt nv12 -f null /dev/null \
> -vf "scale=720:480" -pix_fmt nv12 -f null /dev/null \
> -abr_pipeline
>
> test results:
> 2 scale  5 scale   10 scale
> Improved   25%107%   148%
>
> Signed-off-by: Wang, Shaofei 
> Reviewed-by: Zhao, Jun 
> ---
>  fftools/ffmpeg.c| 238
> +---
>  fftools/ffmpeg.h|  15 +++
>  fftools/ffmpeg_filter.c |   6 ++
>  fftools/ffmpeg_opt.c|   6 +-
>  4 files changed, 251 insertions(+), 14 deletions(-)
>
> diff --git a/fftools/ffmpeg.c b/fftools/ffmpeg.c
> index 544f1a1..d608194 100644
> --- a/fftools/ffmpeg.c
> +++ b/fftools/ffmpeg.c
> @@ -1523,6 +1523,110 @@ static int reap_filters(int flush)
>  return 0;
>  }
>
> +static int pipeline_reap_filters(int flush, InputFilter * ifilter)
> +{
> +AVFrame *filtered_frame = NULL;
> +int i;
> +
> +for (i = 0; i < nb_output_streams; i++) {
> +if (ifilter == output_streams[i]->filter->graph->inputs[0]) break;
> +}
> +OutputStream *ost = output_streams[i];
> +OutputFile*of = output_files[ost->file_index];
> +AVFilterContext *filter;
> +AVCodecContext *enc = ost->enc_ctx;
> +int ret = 0;
> +
> +if (!ost->filter || !ost->filter->graph->graph)
> +return 0;
> +filter = ost->filter->filter;
> +
> +if (!ost->initialized) {
> +char error[1024] = "";
> +ret = init_output_stream(ost, error, sizeof(error));
> +if (ret < 0) {
> +av_log(NULL, AV_LOG_ERROR, "Error initializing output stream
> %d:%d -- %s\n",
> +   ost->file_index, ost->index, error);
> +exit_program(1);
> +}
> +}
> +
> +if (!ost->filtered_frame && !(ost->filtered_frame =
> av_frame_alloc())) {
> +return AVERROR(ENOMEM);
> +}
>

We never put brackets for single line statements.


> +filtered_frame = ost->filtered_frame;
> +
> +while (1) {
> +double float_pts = AV_NOPTS_VALUE; // this is identical to
> filtered_frame.pts but with higher precision
> +ret = av_buffersink_get_frame_flags(filter, filtered_frame,
> +   AV_BUFFERSINK_FLAG_NO_REQUEST);
> +if (ret < 0) {
> +if (ret != AVERROR(EAGAIN) && ret != AVERROR_EOF) {
> +av_log(NULL, AV_LOG_WARNING,
> +   "Error in av_buffersink_get_frame_flags(): %s\n",
> av_err2str(ret));
> +} else if (flush && ret == AVERROR_EOF) {
> +if (av_buffersink_get_type(filter) == AVMEDIA_TYPE_VIDEO)
> +do_video_out(of, ost, NULL, AV_NOPTS_VALUE);
> +}
> +break;
> +}
> +if (ost->finished) {
> +av_frame_unref(filtered_frame);
> +continue;
> +}
> +if (filtered_frame->pts != AV_NOPTS_VALUE) {
> +int64_t start_time = (of->start_time == AV_NOPTS_VALUE) ? 0 :
> of->start_time;
> +AVRational filter_tb = av_buffersink_get_time_base(filter);
> +AVRational tb = enc->time_base;
> +

Re: [FFmpeg-devel] [PATCH 2/2] lavf/qsvvpp: cope with MFX_ERR_MORE_DATA condition in VPP pipeline

[Rostislav Pehlivanov]

On Mon, 14 Jan 2019 at 12:40, Linjie Fu  wrote:

> Returning AVERROR(EAGAIN) when libmfx needs more data will cause the
> failure
> of requesting the next frame and lead to an infinite loop.
>
> Sleep for a while to release the resources before calling
> MFXVideoCORE_SyncOperation
> in hwupload to avoid the crash (in MCTF for example).
>
> Signed-off-by: Linjie Fu 
> ---
>  libavfilter/qsvvpp.c | 6 --
>  1 file changed, 4 insertions(+), 2 deletions(-)
>
> diff --git a/libavfilter/qsvvpp.c b/libavfilter/qsvvpp.c
> index 06efdf5089..1a10d16788 100644
> --- a/libavfilter/qsvvpp.c
> +++ b/libavfilter/qsvvpp.c
> @@ -714,8 +714,10 @@ int ff_qsvvpp_filter_frame(QSVVPPContext *s,
> AVFilterLink *inlink, AVFrame *picr
>
>  if (ret < 0 && ret != MFX_ERR_MORE_SURFACE) {
>  /* Ignore more_data error */
> -if (ret == MFX_ERR_MORE_DATA)
> -ret = AVERROR(EAGAIN);
> +if (ret == MFX_ERR_MORE_DATA) {
> +ret = MFX_ERR_NONE;
> +av_usleep(10);
> +}
>  break;
>  }
>
> --
> 2.17.1
>

This seems like its an ugly hack.

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

Re: [FFmpeg-devel] [PATCH] doc/developer: require transparency about sponshorships.

[Rostislav Pehlivanov]

On Fri, 11 Jan 2019 at 18:38, Derek Buitenhuis 
wrote:

> On 11/01/2019 18:21, Nicolas George wrote:
> > Signed-off-by: Nicolas George 
> > ---
> >  doc/developer.texi | 10 ++
> >  1 file changed, 10 insertions(+)
>
> Rather than repeat myself, I'll refer to my previous mails:
>
> * http://ffmpeg.org/pipermail/ffmpeg-devel/2019-January/238740.html
> * http://ffmpeg.org/pipermail/ffmpeg-devel/2019-January/238743.html
>
> I utterly and absolutely think no good will come from such a policy. It's
> divisive, exclusionary, inflamatory, witch-hunt-y, and privacy invading,
> among other things.
>
> I'm speechless. Words cannot describe how terrible I think such a policy is
> for current and future contributors, and I am of the opinion that adopting
> such a policy would see any work sent to FFmpeg by anyone involved in a
> company, which I may add, is a lot, utterly dry up.
>
> I've not much more to say on the matter, and I will not engage in flame
> wars after.
>
> - Derek
>
> (P.S. Just how do you intend to enforce this? How do you prove/disprove
> someone
>  has been paid in some form, directly, or indiectly? Do you just accuse
> them on
>  the list?)
>
> (P.P.S. I am aware my opinions hold little clout here nowadays, so take my
> response
>  as you will.)
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel


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

Re: [FFmpeg-devel] [PATCH]lavc/libaomenc: Support lossless encoding

[Rostislav Pehlivanov]

On Thu, 10 Jan 2019 at 20:59, Carl Eugen Hoyos  wrote:

> Hi!
>
> Attached patch fixes ticket #7600.
>
> Please comment, Carl Eugen
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel


You can already do that via -b:v 0 -crf 0, same as with libvpx, can't you?
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] Support HDR dynamic metdata (HDR10+) in HEVC decoder.

[Rostislav Pehlivanov]

On Tue, 8 Jan 2019 at 00:26, Mohammad Izadi  wrote:

> ---
>  libavcodec/hevc_sei.c | 236 --
>  libavcodec/hevc_sei.h |   6 ++
>  libavcodec/hevcdec.c  |  19 
>  3 files changed, 255 insertions(+), 6 deletions(-)
>
> diff --git a/libavcodec/hevc_sei.c b/libavcodec/hevc_sei.c
> index c59bd4321e..7e59bf0813 100644
> --- a/libavcodec/hevc_sei.c
> +++ b/libavcodec/hevc_sei.c
> @@ -25,6 +25,7 @@
>  #include "golomb.h"
>  #include "hevc_ps.h"
>  #include "hevc_sei.h"
> +#include "libavutil/hdr_dynamic_metadata.h"
>
>  static int decode_nal_sei_decoded_picture_hash(HEVCSEIPictureHash *s,
> GetBitContext *gb)
>  {
> @@ -206,10 +207,205 @@ static int
> decode_registered_user_data_closed_caption(HEVCSEIA53Caption *s, GetB
>  return 0;
>  }
>
> -static int decode_nal_sei_user_data_registered_itu_t_t35(HEVCSEI *s,
> GetBitContext *gb,
> +static int decode_registered_user_data_dynamic_hdr_plus(AVDynamicHDRPlus
> *s, GetBitContext *gb,
> +void *logctx, int
> size)
> +{
> +const int luminance_den = 1;
> +const int peak_luminance_den = 15;
> +const int rgb_den = 10;
> +const int fraction_pixel_den = 1000;
> +const int knee_point_den = 4095;
> +const int bezier_anchor_den = 1023;
> +const int saturation_weight_den = 8;
> +
> +int bits_left = size * 8;
> +int w, i, j;
> +
> +if (bits_left < 2)
> +return AVERROR_INVALIDDATA;
> +
> +s->num_windows = get_bits(gb, 2);
> +bits_left -= 2;
>

Remove bits_left. You can check how many bits you've read via
get_bits_count (just keep the start value as an offset to subtract).


+if (s->num_windows < 1 || s->num_windows > 3) {
> +av_log(logctx, AV_LOG_ERROR, "num_windows=%d, must be in [1,
> 3]\n",
> +   s->num_windows);
> +return AVERROR_INVALIDDATA;
> +}
> +
> +if (bits_left < ((19 * 8 + 1) * (s->num_windows - 1)))
> +return AVERROR(EINVAL);
> +for (w = 1; w < s->num_windows; w++) {
> +s->params[w].window_upper_left_corner_x.num = get_bits(gb, 16);
> +s->params[w].window_upper_left_corner_y.num = get_bits(gb, 16);
> +s->params[w].window_lower_right_corner_x.num = get_bits(gb, 16);
> +s->params[w].window_lower_right_corner_y.num = get_bits(gb, 16);
> +// The corners are set to absolute coordinates here. They should
> be
> +// converted to the relative coordinates (in [0, 1]) in the
> decoder.
> +s->params[w].window_upper_left_corner_x.den = 1;
> +s->params[w].window_upper_left_corner_y.den = 1;
> +s->params[w].window_lower_right_corner_x.den = 1;
> +s->params[w].window_lower_right_corner_y.den = 1;
> +
> +s->params[w].center_of_ellipse_x = get_bits(gb, 16);
> +s->params[w].center_of_ellipse_y = get_bits(gb, 16);
> +s->params[w].rotation_angle = get_bits(gb, 8);
> +s->params[w].semimajor_axis_internal_ellipse = get_bits(gb, 16);
> +s->params[w].semimajor_axis_external_ellipse = get_bits(gb, 16);
> +s->params[w].semiminor_axis_external_ellipse = get_bits(gb, 16);
> +s->params[w].overlap_process_option = get_bits(gb, 1);
> +bits_left -= 19 * 8 + 1;
> +}
> +
> +if (bits_left < 28)
> +return AVERROR(EINVAL);
> +s->targeted_system_display_maximum_luminance.num = get_bits(gb, 27);
> +s->targeted_system_display_maximum_luminance.den = luminance_den;
> +s->targeted_system_display_actual_peak_luminance_flag = get_bits(gb,
> 1);
> +bits_left -= 28;
> +
> +if (s->targeted_system_display_actual_peak_luminance_flag) {
> +int rows, cols;
> +if (bits_left < 10)
> +return AVERROR(EINVAL);
> +rows = get_bits(gb, 5);
> +cols = get_bits(gb, 5);
> +if (((rows < 2) && (rows > 25)) || ((cols < 2) && (cols > 25))) {
> +av_log(logctx, AV_LOG_ERROR, "num_rows=%d, num_cols=%d, they
> must "
> +   "be in [2, 25] for "
> +   "targeted_system_display_actual_peak_luminance\n",
> +   rows, cols);
>

Align this better, we don't have strict 80 col line rule.


+return AVERROR_INVALIDDATA;
> +}
> +s->num_rows_targeted_system_display_actual_peak_luminance = rows;
> +s->num_cols_targeted_system_display_actual_peak_luminance = cols;
> +bits_left -= 10;
> +
> +if (bits_left < (rows * cols * 4))
> +return AVERROR(EINVAL);
> +
> +for (i = 0; i < rows; i++) {
> +for (j = 0; j < cols; j++) {
> +
> s->targeted_system_display_actual_peak_luminance[i][j].num =
> +get_bits(gb, 4);
> +
> s->targeted_system_display_actual_peak_luminance[i][j].den =
> +peak_luminance_den;
>

Same, just put the assignment values on the same line.


+}
> +}
> +bits_left -= (rows * cols * 4);
> +}
>

Re: [FFmpeg-devel] [PATCH 1/2] Support HDR dynamic metdata (HDR10+) in HEVC decoder.

[Rostislav Pehlivanov]

On Fri, 4 Jan 2019 at 23:19, Mohammad Izadi  wrote:

> Thanks James.
> --
> Best,
> Mohammad
>
>
> On Fri, Jan 4, 2019 at 3:03 PM James Almer  wrote:
>
> > On 1/4/2019 7:51 PM, Rostislav Pehlivanov wrote:
> > > On Fri, 4 Jan 2019 at 21:08, James Almer  wrote:
> > >
> > >> On 1/4/2019 3:53 PM, Rostislav Pehlivanov wrote:
> > >>> On Fri, 4 Jan 2019 at 18:12, Mohammad Izadi 
> > wrote:
> > >>>
> > >>>> You mean a pointer in HEVCSEIDynamicHDRPlus, not in
> > HEVCSEIContentLight?
> > >>>> --
> > >>>> Best,
> > >>>> Mohammad
> > >>>>
> > >>>>
> > >>>> On Thu, Jan 3, 2019 at 5:08 PM Rostislav Pehlivanov <
> > >> atomnu...@gmail.com>
> > >>>> wrote:
> > >>>>
> > >>>>> On Thu, 3 Jan 2019 at 20:13, Mohammad Izadi 
> > >> wrote:
> > >>>>>
> > >>>>>>
> > >>>>>>  /**
> > >>>>>> @@ -94,6 +95,50 @@ typedef struct HEVCSEIMasteringDisplay {
> > >>>>>>  uint32_t min_luminance;
> > >>>>>>  } HEVCSEIMasteringDisplay;
> > >>>>>>
> > >>>>>> +typedef struct HEVCSEIDynamicHDRPlus{
> > >>>>>> +int present;
> > >>>>>> +uint8_t itu_t_t35_country_code;
> > >>>>>> +uint8_t application_version;
> > >>>>>> +uint8_t num_windows;
> > >>>>>> +struct {
> > >>>>>> +AVRational window_upper_left_corner_x;
> > >>>>>> +AVRational window_upper_left_corner_y;
> > >>>>>> +AVRational window_lower_right_corner_x;
> > >>>>>> +AVRational window_lower_right_corner_y;
> > >>>>>> +uint16_t center_of_ellipse_x;
> > >>>>>> +uint16_t center_of_ellipse_y;
> > >>>>>> +uint8_t rotation_angle;
> > >>>>>> +uint16_t semimajor_axis_internal_ellipse;
> > >>>>>> +uint16_t semimajor_axis_external_ellipse;
> > >>>>>> +uint16_t semiminor_axis_external_ellipse;
> > >>>>>> +uint8_t overlap_process_option;
> > >>>>>> +AVRational maxscl[3];
> > >>>>>> +AVRational average_maxrgb;
> > >>>>>> +uint8_t num_distribution_maxrgb_percentiles;
> > >>>>>> +struct {
> > >>>>>> +uint8_t percentage;
> > >>>>>> +AVRational percentile;
> > >>>>>> +} distribution_maxrgb[15];
> > >>>>>> +AVRational fraction_bright_pixels;
> > >>>>>> +uint8_t tone_mapping_flag;
> > >>>>>> +AVRational knee_point_x;
> > >>>>>> +AVRational knee_point_y;
> > >>>>>> +uint8_t num_bezier_curve_anchors;
> > >>>>>> +AVRational bezier_curve_anchors[15];
> > >>>>>> +uint8_t color_saturation_mapping_flag;
> > >>>>>> +AVRational color_saturation_weight;
> > >>>>>> +} params[3];
> > >>>>>> +AVRational targeted_system_display_maximum_luminance;
> > >>>>>> +uint8_t targeted_system_display_actual_peak_luminance_flag;
> > >>>>>> +uint8_t
> num_rows_targeted_system_display_actual_peak_luminance;
> > >>>>>> +uint8_t
> num_cols_targeted_system_display_actual_peak_luminance;
> > >>>>>> +AVRational
> > targeted_system_display_actual_peak_luminance[25][25];
> > >>>>>> +uint8_t mastering_display_actual_peak_luminance_flag;
> > >>>>>> +uint8_t num_rows_mastering_display_actual_peak_luminance;
> > >>>>>> +uint8_t num_cols_mastering_display_actual_peak_luminance;
> > >>>>>> +AVRational mastering_display_actual_peak_luminance[25][25];
> > >>>>>> +} HEVCSEIDynamicHDRPlus;
> > >>>>>> +
> > >>>>>>
> > >>>>>
> > >>>>> There's no reason to create a new struct for this 

Re: [FFmpeg-devel] [PATCH V5 1/2] avutil: add ROI (Region Of Interest) data struct and bump version

[Rostislav Pehlivanov]

On Fri, 4 Jan 2019 at 20:44, Vittorio Giovara 
wrote:

> On Fri, Jan 4, 2019 at 7:57 PM Rostislav Pehlivanov 
> wrote:
>
> > On Fri, 4 Jan 2019 at 16:28, Vittorio Giovara <
> vittorio.giov...@gmail.com>
> > wrote:
> >
> > > On Fri, Jan 4, 2019 at 2:37 PM Nicolas George  wrote:
> > >
> > > > Vittorio Giovara (12019-01-04):
> > > > > I personally disagree, what are coordinates within an AVFrame if
> not
> > > the
> > > > > length/size of an object in memory?
> > > >
> > > > That would be an argument for making AVFrame.width and AVFrame.height
> > > > size_t. But they are not, and therefore these ROI values have no
> reason
> > > > to be either. There is no point in being able to express ROI
> > coordinates
> > > > in the quadrillion when the size of the frame is bounded by much
> less.
> > > >
> > >
> > > That seems a poor argument since the code base is so old that there
> are a
> > > plethora of bad design decisions that should not dictate what choices
> are
> > > made now.
> > >
> >
> > Hence we should avoid making a new one now.
>
>
> Right, we should do things that make sense and argument them with something
> more than saying "it's confusing".
>
> Pixels shouldn't have the size_t type, it just makes things confusing.
> >
> --
> Vittorio
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel


Its illogical to have pixels be typed with a size_t, its not something
we've done before either (which makes sense), and its different size across
platforms doesn't help nor does it keep things consistent when there's no
reason for them to be different.
Its a noop type change on 32 bit arches anyway as uint32_t == size_t. Won't
break anything. And the author's having to change another field in the
struct anyway so its not like its more work.
All you've argued thus far for is that since no one said anything for a
month, and that its the author's choice, it should remain that way, and
that coordinates within an avframe are memory sizes (which they can be, but
width and height are not, they're in pixels, and I'd argue they should
remain such). I don't see the reasoning here.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 1/2] Support HDR dynamic metdata (HDR10+) in HEVC decoder.

[Rostislav Pehlivanov]

On Fri, 4 Jan 2019 at 21:08, James Almer  wrote:

> On 1/4/2019 3:53 PM, Rostislav Pehlivanov wrote:
> > On Fri, 4 Jan 2019 at 18:12, Mohammad Izadi  wrote:
> >
> >> You mean a pointer in HEVCSEIDynamicHDRPlus, not in HEVCSEIContentLight?
> >> --
> >> Best,
> >> Mohammad
> >>
> >>
> >> On Thu, Jan 3, 2019 at 5:08 PM Rostislav Pehlivanov <
> atomnu...@gmail.com>
> >> wrote:
> >>
> >>> On Thu, 3 Jan 2019 at 20:13, Mohammad Izadi 
> wrote:
> >>>
> >>>>
> >>>>  /**
> >>>> @@ -94,6 +95,50 @@ typedef struct HEVCSEIMasteringDisplay {
> >>>>  uint32_t min_luminance;
> >>>>  } HEVCSEIMasteringDisplay;
> >>>>
> >>>> +typedef struct HEVCSEIDynamicHDRPlus{
> >>>> +int present;
> >>>> +uint8_t itu_t_t35_country_code;
> >>>> +uint8_t application_version;
> >>>> +uint8_t num_windows;
> >>>> +struct {
> >>>> +AVRational window_upper_left_corner_x;
> >>>> +AVRational window_upper_left_corner_y;
> >>>> +AVRational window_lower_right_corner_x;
> >>>> +AVRational window_lower_right_corner_y;
> >>>> +uint16_t center_of_ellipse_x;
> >>>> +uint16_t center_of_ellipse_y;
> >>>> +uint8_t rotation_angle;
> >>>> +uint16_t semimajor_axis_internal_ellipse;
> >>>> +uint16_t semimajor_axis_external_ellipse;
> >>>> +uint16_t semiminor_axis_external_ellipse;
> >>>> +uint8_t overlap_process_option;
> >>>> +AVRational maxscl[3];
> >>>> +AVRational average_maxrgb;
> >>>> +uint8_t num_distribution_maxrgb_percentiles;
> >>>> +struct {
> >>>> +uint8_t percentage;
> >>>> +AVRational percentile;
> >>>> +} distribution_maxrgb[15];
> >>>> +AVRational fraction_bright_pixels;
> >>>> +uint8_t tone_mapping_flag;
> >>>> +AVRational knee_point_x;
> >>>> +AVRational knee_point_y;
> >>>> +uint8_t num_bezier_curve_anchors;
> >>>> +AVRational bezier_curve_anchors[15];
> >>>> +uint8_t color_saturation_mapping_flag;
> >>>> +AVRational color_saturation_weight;
> >>>> +} params[3];
> >>>> +AVRational targeted_system_display_maximum_luminance;
> >>>> +uint8_t targeted_system_display_actual_peak_luminance_flag;
> >>>> +uint8_t num_rows_targeted_system_display_actual_peak_luminance;
> >>>> +uint8_t num_cols_targeted_system_display_actual_peak_luminance;
> >>>> +AVRational targeted_system_display_actual_peak_luminance[25][25];
> >>>> +uint8_t mastering_display_actual_peak_luminance_flag;
> >>>> +uint8_t num_rows_mastering_display_actual_peak_luminance;
> >>>> +uint8_t num_cols_mastering_display_actual_peak_luminance;
> >>>> +AVRational mastering_display_actual_peak_luminance[25][25];
> >>>> +} HEVCSEIDynamicHDRPlus;
> >>>> +
> >>>>
> >>>
> >>> There's no reason to create a new struct for this if all you're going
> to
> >> do
> >>> is to copy it over and over to new frames.
> >>> What you can do is this: on every SEI containing this thing just
> >> allocate a
> >>> AVDynamicHDRPlus struct via av_dynamic_hdr_plus_alloc, wrap it as an
> >>> AVBufferRef via av_buffer_create, populate it, put it as a pointer in
> >>> HEVCSEIContentLight and then on every frame just add it to the frame
> via
> >>> av_frame_new_side_data_from_buf. If a new SEI is received unref your
> >>> pointer in HEVCSEIDynamicHDRPlus and repeat by allocating a new struct,
> >>> wrapping it as a buffer, populating it, etc.
> >>> I figure the only reason this wasn't done with other metadata was
> because
> >>> they were much smaller and because av_frame_new_side_data_from_buf
> didn't
> >>> exist until recently.
> >>>
> >>>
> >>> +av_log(s->avctx, AV_LOG_DEBUG, ")");
> >>>> +if (metadata->params[w].color_saturation_mapping_flag) {
> >>>> +

Re: [FFmpeg-devel] [PATCH V5 1/2] avutil: add ROI (Region Of Interest) data struct and bump version

[Rostislav Pehlivanov]

On Fri, 4 Jan 2019 at 16:28, Vittorio Giovara 
wrote:

> On Fri, Jan 4, 2019 at 2:37 PM Nicolas George  wrote:
>
> > Vittorio Giovara (12019-01-04):
> > > I personally disagree, what are coordinates within an AVFrame if not
> the
> > > length/size of an object in memory?
> >
> > That would be an argument for making AVFrame.width and AVFrame.height
> > size_t. But they are not, and therefore these ROI values have no reason
> > to be either. There is no point in being able to express ROI coordinates
> > in the quadrillion when the size of the frame is bounded by much less.
> >
>
> That seems a poor argument since the code base is so old that there are a
> plethora of bad design decisions that should not dictate what choices are
> made now.
>

Hence we should avoid making a new one now. Pixels shouldn't have the
size_t type, it just makes things confusing.
I fail to see how personal choice and silence for weeks constitute a good
argument to keep things as they are. If merged, things will have to be kept
the way they are for at least 2 years.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 1/2] Support HDR dynamic metdata (HDR10+) in HEVC decoder.

[Rostislav Pehlivanov]

On Fri, 4 Jan 2019 at 18:12, Mohammad Izadi  wrote:

> You mean a pointer in HEVCSEIDynamicHDRPlus, not in HEVCSEIContentLight?
> --
> Best,
> Mohammad
>
>
> On Thu, Jan 3, 2019 at 5:08 PM Rostislav Pehlivanov 
> wrote:
>
> > On Thu, 3 Jan 2019 at 20:13, Mohammad Izadi  wrote:
> >
> > >
> > >  /**
> > > @@ -94,6 +95,50 @@ typedef struct HEVCSEIMasteringDisplay {
> > >  uint32_t min_luminance;
> > >  } HEVCSEIMasteringDisplay;
> > >
> > > +typedef struct HEVCSEIDynamicHDRPlus{
> > > +int present;
> > > +uint8_t itu_t_t35_country_code;
> > > +uint8_t application_version;
> > > +uint8_t num_windows;
> > > +struct {
> > > +AVRational window_upper_left_corner_x;
> > > +AVRational window_upper_left_corner_y;
> > > +AVRational window_lower_right_corner_x;
> > > +AVRational window_lower_right_corner_y;
> > > +uint16_t center_of_ellipse_x;
> > > +uint16_t center_of_ellipse_y;
> > > +uint8_t rotation_angle;
> > > +uint16_t semimajor_axis_internal_ellipse;
> > > +uint16_t semimajor_axis_external_ellipse;
> > > +uint16_t semiminor_axis_external_ellipse;
> > > +uint8_t overlap_process_option;
> > > +AVRational maxscl[3];
> > > +AVRational average_maxrgb;
> > > +uint8_t num_distribution_maxrgb_percentiles;
> > > +struct {
> > > +uint8_t percentage;
> > > +AVRational percentile;
> > > +} distribution_maxrgb[15];
> > > +AVRational fraction_bright_pixels;
> > > +uint8_t tone_mapping_flag;
> > > +AVRational knee_point_x;
> > > +AVRational knee_point_y;
> > > +uint8_t num_bezier_curve_anchors;
> > > +AVRational bezier_curve_anchors[15];
> > > +uint8_t color_saturation_mapping_flag;
> > > +AVRational color_saturation_weight;
> > > +} params[3];
> > > +AVRational targeted_system_display_maximum_luminance;
> > > +uint8_t targeted_system_display_actual_peak_luminance_flag;
> > > +uint8_t num_rows_targeted_system_display_actual_peak_luminance;
> > > +uint8_t num_cols_targeted_system_display_actual_peak_luminance;
> > > +AVRational targeted_system_display_actual_peak_luminance[25][25];
> > > +uint8_t mastering_display_actual_peak_luminance_flag;
> > > +uint8_t num_rows_mastering_display_actual_peak_luminance;
> > > +uint8_t num_cols_mastering_display_actual_peak_luminance;
> > > +AVRational mastering_display_actual_peak_luminance[25][25];
> > > +} HEVCSEIDynamicHDRPlus;
> > > +
> > >
> >
> > There's no reason to create a new struct for this if all you're going to
> do
> > is to copy it over and over to new frames.
> > What you can do is this: on every SEI containing this thing just
> allocate a
> > AVDynamicHDRPlus struct via av_dynamic_hdr_plus_alloc, wrap it as an
> > AVBufferRef via av_buffer_create, populate it, put it as a pointer in
> > HEVCSEIContentLight and then on every frame just add it to the frame via
> > av_frame_new_side_data_from_buf. If a new SEI is received unref your
> > pointer in HEVCSEIDynamicHDRPlus and repeat by allocating a new struct,
> > wrapping it as a buffer, populating it, etc.
> > I figure the only reason this wasn't done with other metadata was because
> > they were much smaller and because av_frame_new_side_data_from_buf didn't
> > exist until recently.
> >
> >
> > +av_log(s->avctx, AV_LOG_DEBUG, ")");
> > > +if (metadata->params[w].color_saturation_mapping_flag) {
> > > +av_log(s->avctx, AV_LOG_DEBUG,
> > > +   " color_saturation_weight=%5.4f",
> > > +
> > >  av_q2d(metadata->params[w].color_saturation_weight));
> > > +}
> > > +av_log(s->avctx, AV_LOG_DEBUG, "}\n");
> > > +}
> > > +av_log(s->avctx, AV_LOG_DEBUG,
> > > +   "} End of HDR10+ (SMPTE 2094-40)\n");
> > > +}
> > >
> >
> > Don't spam stuff like than in the debug log, especially not on every
> single
> > frame. Tools exist to print side data so just don't.
> > ___
> > 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


No, I mean in HEVCSEIContentLight. Like I said, HEVCSEIDynamicHDRPlus
shouldn't exist.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH V5 1/2] avutil: add ROI (Region Of Interest) data struct and bump version

[Rostislav Pehlivanov]

On Fri, 4 Jan 2019 at 14:02, Nicolas George  wrote:

> Rostislav Pehlivanov (12019-01-04):
> > Which are in pixels, not bytes.
>
> And plain int, not uint32_t.
>
> > This is an encoder-only interface for now. For vp9 the denum would be 255
> > for example. They would warn on out of range qdelta.
> > I still don't get why this can't be an int.
>
> "For now" is the key. This is a new API, we should try to think of the
> likely future uses, not just what we have in mind right now.
>
> So: very likely use of ROI: -vf facedetect.
>
> Since the filter will not know the specifics of the encoder, it needs to
> be able to express things (and have default value) in an
> encoder-agnostic way.
>

Hence an AVRational is appropriate as you can have fractions between 0 and
1, the encoder can adjust it and it'll be agnostic.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH V5 1/2] avutil: add ROI (Region Of Interest) data struct and bump version

[Rostislav Pehlivanov]

On Fri, 4 Jan 2019 at 11:22, Nicolas George  wrote:

> Rostislav Pehlivanov (12019-01-04):
> > > +typedef struct AVRegionOfInterest {
> > > +size_t self_size;
> > > +size_t top;
> > > +size_t bottom;
> > > +size_t left;
> > > +size_t right;
> > I'd still much rather have uints with fixed sizes than these platform
> > dependent types.
>
> Guo, Yejun said:
>
> >> I usually choose 'size_t' for the meanings with length/size.
>
> But that is a mistake. size_t is for length/size of objects in memory,
> not any length/size.
>
> These numbers, unless I am mistaken, are coordinates within an AVFrame.
> In that case, the only correct type is the same as AVFrame.width and
> AVFrame.height.
>

Which are in pixels, not bytes.



>
> > Use an AVRational with a denum set to the max quantizer
>
> Can you explain "set to the max quantizer"? For decoders it makes sense,
> but what should the encoders do? Return EINVAL? Scale?
>

This is an encoder-only interface for now. For vp9 the denum would be 255
for example. They would warn on out of range qdelta.
I still don't get why this can't be an int.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH V5 1/2] avutil: add ROI (Region Of Interest) data struct and bump version

[Rostislav Pehlivanov]

On Thu, 3 Jan 2019 at 08:41, Guo, Yejun  wrote:

> The encoders such as libx264 support different QPs offset for different
> MBs,
> it makes possible for ROI-based encoding. It makes sense to add support
> within ffmpeg to generate/accept ROI infos and pass into encoders.
>
> Typical usage: After AVFrame is decoded, a ffmpeg filter or user's code
> generates ROI info for that frame, and the encoder finally does the
> ROI-based encoding.
>
> The ROI info is maintained as side data of AVFrame.
>
> Signed-off-by: Guo, Yejun 
> ---
>  libavutil/frame.c   |  1 +
>  libavutil/frame.h   | 29 +
>  libavutil/version.h |  2 +-
>  3 files changed, 31 insertions(+), 1 deletion(-)
>
> diff --git a/libavutil/frame.c b/libavutil/frame.c
> index 34a6210..dcf1fc3 100644
> --- a/libavutil/frame.c
> +++ b/libavutil/frame.c
> @@ -841,6 +841,7 @@ const char *av_frame_side_data_name(enum
> AVFrameSideDataType type)
>  case AV_FRAME_DATA_QP_TABLE_DATA:   return "QP table
> data";
>  #endif
>  case AV_FRAME_DATA_DYNAMIC_HDR_PLUS: return "HDR Dynamic Metadata
> SMPTE2094-40 (HDR10+)";
> +case AV_FRAME_DATA_REGIONS_OF_INTEREST: return "Regions Of Interest";
>  }
>  return NULL;
>  }
> diff --git a/libavutil/frame.h b/libavutil/frame.h
> index 582ac47..7887391 100644
> --- a/libavutil/frame.h
> +++ b/libavutil/frame.h
> @@ -173,6 +173,12 @@ enum AVFrameSideDataType {
>   * volume transform - application 4 of SMPTE 2094-40:2016 standard.
>   */
>  AV_FRAME_DATA_DYNAMIC_HDR_PLUS,
> +
> +/**
> + * Regions Of Interest, the data is an array of AVRegionOfInterest
> type, the number of
> + * array element is implied by AVFrameSideData.size /
> AVRegionOfInterest.self_size.
> + */
> +AV_FRAME_DATA_REGIONS_OF_INTEREST,
>  };
>
>  enum AVActiveFormatDescription {
> @@ -201,6 +207,29 @@ typedef struct AVFrameSideData {
>  } AVFrameSideData;
>
>  /**
> + * Structure to hold Region Of Interest.
> + *
> + * self_size specifies the size of this data structure. This value
> + * should be set to sizeof(AVRegionOfInterest).
> + *
> + * Number of pixels to discard from the top/bottom/left/right border of
> + * the frame to obtain the region of interest of the frame.
> + * They are encoder dependent and will be extended internally
> + * if the codec requires an alignment.
> + * If the regions overlap, the last value in the list will be used.
> + *
> + * qoffset is quant offset, it is encoder dependent.
> + */
> +typedef struct AVRegionOfInterest {
> +size_t self_size;
> +size_t top;
> +size_t bottom;
> +size_t left;
> +size_t right;
>

I'd still much rather have uints with fixed sizes than these platform
dependent types.


+float qoffset;
>

Use an AVRational with a denum set to the max quantizer, that'll make it
encoder independent and give you better precision.
We also generally don't have floats in the API.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 1/2] Support HDR dynamic metdata (HDR10+) in HEVC decoder.

[Rostislav Pehlivanov]

On Thu, 3 Jan 2019 at 20:13, Mohammad Izadi  wrote:

>
>  /**
> @@ -94,6 +95,50 @@ typedef struct HEVCSEIMasteringDisplay {
>  uint32_t min_luminance;
>  } HEVCSEIMasteringDisplay;
>
> +typedef struct HEVCSEIDynamicHDRPlus{
> +int present;
> +uint8_t itu_t_t35_country_code;
> +uint8_t application_version;
> +uint8_t num_windows;
> +struct {
> +AVRational window_upper_left_corner_x;
> +AVRational window_upper_left_corner_y;
> +AVRational window_lower_right_corner_x;
> +AVRational window_lower_right_corner_y;
> +uint16_t center_of_ellipse_x;
> +uint16_t center_of_ellipse_y;
> +uint8_t rotation_angle;
> +uint16_t semimajor_axis_internal_ellipse;
> +uint16_t semimajor_axis_external_ellipse;
> +uint16_t semiminor_axis_external_ellipse;
> +uint8_t overlap_process_option;
> +AVRational maxscl[3];
> +AVRational average_maxrgb;
> +uint8_t num_distribution_maxrgb_percentiles;
> +struct {
> +uint8_t percentage;
> +AVRational percentile;
> +} distribution_maxrgb[15];
> +AVRational fraction_bright_pixels;
> +uint8_t tone_mapping_flag;
> +AVRational knee_point_x;
> +AVRational knee_point_y;
> +uint8_t num_bezier_curve_anchors;
> +AVRational bezier_curve_anchors[15];
> +uint8_t color_saturation_mapping_flag;
> +AVRational color_saturation_weight;
> +} params[3];
> +AVRational targeted_system_display_maximum_luminance;
> +uint8_t targeted_system_display_actual_peak_luminance_flag;
> +uint8_t num_rows_targeted_system_display_actual_peak_luminance;
> +uint8_t num_cols_targeted_system_display_actual_peak_luminance;
> +AVRational targeted_system_display_actual_peak_luminance[25][25];
> +uint8_t mastering_display_actual_peak_luminance_flag;
> +uint8_t num_rows_mastering_display_actual_peak_luminance;
> +uint8_t num_cols_mastering_display_actual_peak_luminance;
> +AVRational mastering_display_actual_peak_luminance[25][25];
> +} HEVCSEIDynamicHDRPlus;
> +
>

There's no reason to create a new struct for this if all you're going to do
is to copy it over and over to new frames.
What you can do is this: on every SEI containing this thing just allocate a
AVDynamicHDRPlus struct via av_dynamic_hdr_plus_alloc, wrap it as an
AVBufferRef via av_buffer_create, populate it, put it as a pointer in
HEVCSEIContentLight and then on every frame just add it to the frame via
av_frame_new_side_data_from_buf. If a new SEI is received unref your
pointer in HEVCSEIDynamicHDRPlus and repeat by allocating a new struct,
wrapping it as a buffer, populating it, etc.
I figure the only reason this wasn't done with other metadata was because
they were much smaller and because av_frame_new_side_data_from_buf didn't
exist until recently.


+av_log(s->avctx, AV_LOG_DEBUG, ")");
> +if (metadata->params[w].color_saturation_mapping_flag) {
> +av_log(s->avctx, AV_LOG_DEBUG,
> +   " color_saturation_weight=%5.4f",
> +
>  av_q2d(metadata->params[w].color_saturation_weight));
> +}
> +av_log(s->avctx, AV_LOG_DEBUG, "}\n");
> +}
> +av_log(s->avctx, AV_LOG_DEBUG,
> +   "} End of HDR10+ (SMPTE 2094-40)\n");
> +}
>

Don't spam stuff like than in the debug log, especially not on every single
frame. Tools exist to print side data so just don't.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 1/2] avcodec: add HCOM decoder

[Rostislav Pehlivanov]

On Wed, 2 Jan 2019 at 19:02, Paul B Mahol  wrote:

> Signed-off-by: Paul B Mahol 
> ---
>  libavcodec/Makefile |   1 +
>  libavcodec/allcodecs.c  |   1 +
>  libavcodec/avcodec.h|   1 +
>  libavcodec/codec_desc.c |   7 ++
>  libavcodec/hcom.c   | 137 
>  5 files changed, 147 insertions(+)
>  create mode 100644 libavcodec/hcom.c
>
> diff --git a/libavcodec/Makefile b/libavcodec/Makefile
> index 99799ceed2..bf746c143d 100644
> --- a/libavcodec/Makefile
> +++ b/libavcodec/Makefile
> @@ -362,6 +362,7 @@ OBJS-$(CONFIG_H264_V4L2M2M_DECODER)+=
> v4l2_m2m_dec.o
>  OBJS-$(CONFIG_H264_V4L2M2M_ENCODER)+= v4l2_m2m_enc.o
>  OBJS-$(CONFIG_HAP_DECODER) += hapdec.o hap.o
>  OBJS-$(CONFIG_HAP_ENCODER) += hapenc.o hap.o
> +OBJS-$(CONFIG_HCOM_DECODER)+= hcom.o
>  OBJS-$(CONFIG_HEVC_DECODER)+= hevcdec.o hevc_mvs.o \
>hevc_cabac.o hevc_refs.o
> hevcpred.o\
>hevcdsp.o hevc_filter.o
> hevc_data.o
> diff --git a/libavcodec/allcodecs.c b/libavcodec/allcodecs.c
> index 4755af71b2..fe0376e27e 100644
> --- a/libavcodec/allcodecs.c
> +++ b/libavcodec/allcodecs.c
> @@ -424,6 +424,7 @@ extern AVCodec ff_g723_1_decoder;
>  extern AVCodec ff_g729_decoder;
>  extern AVCodec ff_gsm_decoder;
>  extern AVCodec ff_gsm_ms_decoder;
> +extern AVCodec ff_hcom_decoder;
>  extern AVCodec ff_iac_decoder;
>  extern AVCodec ff_ilbc_decoder;
>  extern AVCodec ff_imc_decoder;
> diff --git a/libavcodec/avcodec.h b/libavcodec/avcodec.h
> index 92567ec6d0..e92d7accf4 100644
> --- a/libavcodec/avcodec.h
> +++ b/libavcodec/avcodec.h
> @@ -646,6 +646,7 @@ enum AVCodecID {
>  AV_CODEC_ID_APTX_HD,
>  AV_CODEC_ID_SBC,
>  AV_CODEC_ID_ATRAC9,
> +AV_CODEC_ID_HCOM,
>
>  /* subtitle codecs */
>  AV_CODEC_ID_FIRST_SUBTITLE = 0x17000,  ///< A dummy ID
> pointing at the start of subtitle codecs.
> diff --git a/libavcodec/codec_desc.c b/libavcodec/codec_desc.c
> index 2363a53283..10a639101c 100644
> --- a/libavcodec/codec_desc.c
> +++ b/libavcodec/codec_desc.c
> @@ -2943,6 +2943,13 @@ static const AVCodecDescriptor codec_descriptors[]
> = {
>  .long_name = NULL_IF_CONFIG_SMALL("ATRAC9 (Adaptive TRansform
> Acoustic Coding 9)"),
>  .props = AV_CODEC_PROP_LOSSY,
>  },
> +{
> +.id= AV_CODEC_ID_HCOM,
> +.type  = AVMEDIA_TYPE_AUDIO,
> +.name  = "hcom",
> +.long_name = NULL_IF_CONFIG_SMALL("HCOM Audio"),
> +.props = AV_CODEC_PROP_LOSSY,
> +},
>
>  /* subtitle codecs */
>  {
> diff --git a/libavcodec/hcom.c b/libavcodec/hcom.c
> new file mode 100644
> index 00..e516d20a94
> --- /dev/null
> +++ b/libavcodec/hcom.c
> @@ -0,0 +1,137 @@
> +/*
> + * HCOM audio decoder
> + *
> + * This file is part of FFmpeg.
> + *
> + * FFmpeg is free software; you can redistribute it and/or
> + * modify it under the terms of the GNU Lesser General Public
> + * License as published by the Free Software Foundation; either
> + * version 2.1 of the License, or (at your option) any later version.
> + *
> + * FFmpeg is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
> + * Lesser General Public License for more details.
> + *
> + * You should have received a copy of the GNU Lesser General Public
> + * License along with FFmpeg; if not, write to the Free Software
> + * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA
> 02110-1301 USA
> + */
> +
> +#include "libavutil/intreadwrite.h"
> +
> +#include "avcodec.h"
> +#include "bytestream.h"
> +#include "internal.h"
> +
> +typedef struct HEntry {
> +int16_t l, r;
> +} HEntry;
> +
> +typedef struct HCOMContext {
> +AVCodecContext *avctx;
> +
> +uint8_t first_sample;
> +uint8_t sample;
> +int dict_entries;
> +int dict_entry;
> +int delta_compression;
> +
> +HEntry *dict;
> +} HCOMContext;
> +
> +static av_cold int hcom_init(AVCodecContext *avctx)
> +{
> +HCOMContext *s = avctx->priv_data;
> +
> +if (avctx->channels != 1) {
> +av_log(avctx, AV_LOG_ERROR, "invalid number of channels\n");
> +return AVERROR_INVALIDDATA;
> +}
>

You can just set avctx->channels = 1 and the layout to mono, its a decoder.


+
> +if (avctx->extradata_size <= 7)
> +return AVERROR_INVALIDDATA;
> +s->dict_entries = AV_RB16(avctx->extradata);
> +if (avctx->extradata_size < s->dict_entries * 4 + 7)
> +return AVERROR_INVALIDDATA;
> +s->delta_compression = AV_RB32(avctx->extradata + 2);
> +s->sample = s->first_sample = avctx->extradata[avctx->extradata_size
> - 1];
> +
> +s->dict = av_calloc(s->dict_entries, sizeof(*s->dict));
> +if (!s->dict)
> +return AVERROR(ENOMEM);
> +for (int i = 0; i < s->di

Re: [FFmpeg-devel] [PATCH]lavc/opus_rc: Case a const pointer to uint8_t *

[Rostislav Pehlivanov]

On Mon, 17 Dec 2018 at 01:47, Carl Eugen Hoyos  wrote:

> Hi!
>
> The Opus struct RawBitsContext is used in both the decoder and the encoder.
> The fact that *position is const avoids warnings in the decoder where
> it points into the bitstream. The encoder writes into the same
> pointer, attached cast silences the warning on targets where AV_WB32()
> does not internally cast the qualifier away.
>
> It is also possible to use a union if anybody prefers this:
> diff --git a/libavcodec/opus_rc.h b/libavcodec/opus_rc.h
> index 627f832..baad4ce 100644
> --- a/libavcodec/opus_rc.h
> +++ b/libavcodec/opus_rc.h
> @@ -37,9 +37,19 @@ typedef struct RawBitsContext {
>  uint32_t cacheval;
>  } RawBitsContext;
>
> +typedef struct RawBitsEncContext {
> +uint8_t *position;
> +uint32_t bytes;
> +uint32_t cachelen;
> +uint32_t cacheval;
> +} RawBitsEncContext;
> +
>  typedef struct OpusRangeCoder {
>  GetBitContext gb;
> -RawBitsContext rb;
> +union {
> +RawBitsContext rb;
> +RawBitsEncContext rbe;
> +};
>  uint32_t range;
>  uint32_t value;
>  uint32_t total_bits;
>
> and use rbe in ff_opus_rc_put_raw().
>
> Please comment, Carl Eugen
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel


NAK, we don't do anyonymous unions. To silence the warning the const can be
just removed, but I've never seen a single warning on platforms I've tried.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] lavc/opusenc: add frame_alloc and frame_count check to quit encode

[Rostislav Pehlivanov]

On Thu, 29 Nov 2018 at 09:14, Linjie Fu  wrote:

> Add frame_alloc and frame_count check in opus_encode_frame to avoid
> the infinite loop issue.
>
> Fix #7578.
>
> Signed-off-by: Linjie Fu 
> ---
>  libavcodec/opusenc.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/libavcodec/opusenc.c b/libavcodec/opusenc.c
> index 578785f4b4..7146968fc8 100644
> --- a/libavcodec/opusenc.c
> +++ b/libavcodec/opusenc.c
> @@ -543,7 +543,7 @@ static int opus_encode_frame(AVCodecContext *avctx,
> AVPacket *avpkt,
>  ff_bufqueue_add(avctx, &s->bufqueue, av_frame_clone(frame));
>  } else {
>  ff_opus_psy_signal_eof(&s->psyctx);
> -if (!s->afq.remaining_samples)
> +if (!s->afq.remaining_samples || (!s->afq.frame_alloc &&
> !s->afq.frame_count))
>  return 0; /* We've been flushed and there's nothing left to
> encode */
>  }
>
> --
> 2.17.1
>
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel


I don't think that's the correct way to do this, maybe it would be better
to check if the remaning samples are above the initial_padding amount or
decreasing the first frame's duration by the initial_padding amount to make
the count correct.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH] [RFC] channel_layout: add support for ambisonics

[Rostislav Pehlivanov]

This is an RFC to add support for tagging channel layouts as ambisonics
in a backward-compatible way.
For now ambisonics up to third order are supported.
The functions have been updated to support and propagate the
AV_CH_LAYOUT_AMBISONICS flag.
This is messy but does not require a new API for layouts. Perhaps the
new proposed API might be a better solution, comments are welcome.
---
 doc/APIchanges |  4 ++
 libavutil/channel_layout.c | 85 +-
 libavutil/channel_layout.h | 19 -
 libavutil/version.h|  4 +-
 4 files changed, 72 insertions(+), 40 deletions(-)

diff --git a/doc/APIchanges b/doc/APIchanges
index db1879e6e2..88e2d0764b 100644
--- a/doc/APIchanges
+++ b/doc/APIchanges
@@ -15,6 +15,10 @@ libavutil: 2017-10-21
 
 API changes, most recent first:
 
+2018-xx-xx - xx - lavu 56.25.100 - channel_layout.h
+  Add AV_CH_LAYOUT_AMBISONICS, AV_CH_LAYOUT_AMBISONICS_1ST,
+  AV_CH_LAYOUT_AMBISONICS_2ND and AV_CH_LAYOUT_AMBISONICS_3RD.
+
  8< - FFmpeg 4.1 was cut here  8< -
 
 2018-10-27 - 718044dc19 - lavu 56.21.100 - pixdesc.h
diff --git a/libavutil/channel_layout.c b/libavutil/channel_layout.c
index 3bd5ee29b7..30297138fe 100644
--- a/libavutil/channel_layout.c
+++ b/libavutil/channel_layout.c
@@ -33,42 +33,45 @@
 
 struct channel_name {
 const char *name;
+const char *ambisonics_name;
 const char *description;
+const char *ambisonics_description;
 };
 
 static const struct channel_name channel_names[] = {
- [0] = { "FL","front left"},
- [1] = { "FR","front right"   },
- [2] = { "FC","front center"  },
- [3] = { "LFE",   "low frequency" },
- [4] = { "BL","back left" },
- [5] = { "BR","back right"},
- [6] = { "FLC",   "front left-of-center"  },
- [7] = { "FRC",   "front right-of-center" },
- [8] = { "BC","back center"   },
- [9] = { "SL","side left" },
-[10] = { "SR","side right"},
-[11] = { "TC","top center"},
-[12] = { "TFL",   "top front left"},
-[13] = { "TFC",   "top front center"  },
-[14] = { "TFR",   "top front right"   },
-[15] = { "TBL",   "top back left" },
-[16] = { "TBC",   "top back center"   },
-[17] = { "TBR",   "top back right"},
-[29] = { "DL","downmix left"  },
-[30] = { "DR","downmix right" },
-[31] = { "WL","wide left" },
-[32] = { "WR","wide right"},
-[33] = { "SDL",   "surround direct left"  },
-[34] = { "SDR",   "surround direct right" },
-[35] = { "LFE2",  "low frequency 2"   },
+ [0] = { "FL",   "1",  "front left","ambisonics component 1"  
},
+ [1] = { "FR",   "2",  "front right",   "ambisonics component 2"  
},
+ [2] = { "FC",   "0",  "front center",  "ambisonics component 0"  
},
+ [3] = { "LFE",  "3",  "low frequency", "ambisonics component 3"  
},
+ [4] = { "BL",   "4",  "back left", "ambisonics component 4"  
},
+ [5] = { "BR",   "5",  "back right","ambisonics component 5"  
},
+ [6] = { "FLC",  "6",  "front left-of-center",  "ambisonics component 6"  
},
+ [7] = { "FRC",  "7",  "front right-of-center", "ambisonics component 7"  
},
+ [8] = { "BC",   "8",  "back center",   "ambisonics component 8"  
},
+ [9] = { "SL",   "9",  "side left", "ambisonics component 9"  
},
+[10] = { "SR",   "10", "side right","ambisonics component 10" 
},
+[11] = { "TC",   "11", "top center","ambisonics component 11" 
},
+[12] = { "TFL",  "12", "top front left","ambisonics component 12" 
},
+[13] = { "TFC",  "13", "top front center",  "ambisonics component 13" 
},
+[14] = { "TFR",  "14", "top front right",   "ambisonics component 14" 
},
+[15] = { "TBL",  "15", "top back left", "ambisonics component 15" 
},
+[16] = { "TBC",  NULL, "top back center",   NULL  
},
+[17] = { "TBR",  NULL, "top back right",NULL  
},
+[29] = { "DL",   NULL, "downmix left",  NULL  
},
+[30] = { "DR",   NULL, "downmix right", NULL  
},
+[31] = { "WL",   NULL, "wide left", NULL  
},
+[32] = { "WR",   NULL, "wide right",NULL  
},
+[33] = { "SDL",  NULL, "surround direct left",  NULL  
},
+[34] = { "SDR",  NULL, "surround direct right", NULL  
},
+[35] = { "LFE2", NULL, "low frequency 2",   NULL  
},
 };
 
-static const char *

Re: [FFmpeg-devel] [PATCH] avcodec/libopusenc: allow encoding channel mapping 2

[Rostislav Pehlivanov]

On Wed, 28 Nov 2018 at 20:35, Michael Niedermayer 
wrote:

> On Tue, Nov 27, 2018 at 06:13:54PM +0800, Felicia Lim wrote:
> > Friendly ping. Please let me know if there are any changes I should make
> to
> > this patch?
>
> will apply, seems noone else cares about it ...
>
> thanks
>
> [...]
> --
> Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
>
> Rewriting code that is poorly written but fully understood is good.
> Rewriting code that one doesnt understand is a sign that one is less smart
> then the original author, trying to rewrite it will not make it better.
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>

Reverted.
I did describe what has to be done to properly support ambisonics as to
make this patch work properly. I know it works for Google's usecase but I'm
against "by-chance" ambisonics where you rely on a specific channel layout
and a specific encoder encoding them with a specific setting.
We still have bits leftover for channel layout and I'd agree to add an
extra bit to indicate the particular layout carries ambisonics, with the
number of channels indicating the order. This wouldn't need extensive
channel layout API replacements and would still be sufficient to implement
both encoding and decoding of such audio.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] avcodec/libopusenc: allow encoding channel mapping 2

[Rostislav Pehlivanov]

On Fri, 27 Jul 2018 at 20:44, Felicia Lim 
wrote:

> ---
>  libavcodec/libopusenc.c | 22 ++
>  1 file changed, 22 insertions(+)
>
> diff --git a/libavcodec/libopusenc.c b/libavcodec/libopusenc.c
> index 4ae81b0bb2..6b450ec317 100644
> --- a/libavcodec/libopusenc.c
> +++ b/libavcodec/libopusenc.c
> @@ -27,6 +27,7 @@
>  #include "bytestream.h"
>  #include "internal.h"
>  #include "libopus.h"
> +#include "mathops.h"
>  #include "vorbis.h"
>  #include "audio_frame_queue.h"
>
> @@ -200,6 +201,21 @@ static int libopus_check_vorbis_layout(AVCodecContext
> *avctx, int mapping_family
>  return 0;
>  }
>
> +static int libopus_check_ambisonics_channels(AVCodecContext *avctx) {
> +int channels = avctx->channels;
> +int ambisonic_order = ff_sqrt(channels) - 1;
> +if (channels != ((ambisonic_order + 1) * (ambisonic_order + 1)) &&
> +channels != ((ambisonic_order + 1) * (ambisonic_order + 1) + 2)) {
> +av_log(avctx, AV_LOG_ERROR,
> +   "Ambisonics coding is only specified for channel counts"
> +   " which can be written as (n + 1)^2 or (n + 1)^2 + 2"
> +   " for nonnegative integer n\n");
> +return AVERROR_INVALIDDATA;
> +}
> +
> +return 0;
> +}
> +
>  static int libopus_validate_layout_and_get_channel_map(
>  AVCodecContext *avctx,
>  int mapping_family,
> @@ -231,6 +247,12 @@ static int
> libopus_validate_layout_and_get_channel_map(
>  channel_map =
> ff_vorbis_channel_layout_offsets[avctx->channels - 1];
>  }
>  break;
> +case 2:
> +ret = libopus_check_max_channels(avctx, 227);
> +if (ret == 0) {
> +ret = libopus_check_ambisonics_channels(avctx);
> +}
> +break;
>  case 255:
>  ret = libopus_check_max_channels(avctx, 254);
>  break;
> --
> 2.18.0.345.g5c9ce644c3-goog
>
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel



I did not OK the patch at all and none of the requests I made were met.
This has to be reverted.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [RFC] VDD FFmpeg session and community survey

[Rostislav Pehlivanov]

On Thu, 22 Nov 2018 at 19:02, Thilo Borgmann  wrote:

>
> Please note that this survey is _not_ meant to be a vote about the
> proposal. It is to
> determine if we should actually have a refinement/vote on instantiating
> such a
> community committee - depending on the community's point of view.
>

Spamming (which this would certainly be a textbook definition of) every
subscriber ever (including those who forgot) is unacceptable.


+Further on it is to impose any sanctions related to violations of the code of
> +conduct only if these incidents are brought up to its attention from directly
> +involved parties of such an incident.
>
> Violations should be limited to publicly logged IRC channels or the ML.
Otherwise without proof this will end up as a "but they said" situation.

++ at subheading 
Committee members
> +
> +The community committee consists of three elected individuals. Committee 
> members are
> +elected for a period of one year and are automatically removed from the 
> committee after
> +that period. Reelection of committee members for the following period is 
> possible.
>
> Three members is far too low and would be prone to bias. 5 or 7 would be
better.


> +
> +If for any reason a current member of the committee wishes to leave the 
> committee, the
> +whole committee is to be reelected. No former committee members having left 
> the committee
> +on their own wish can be a candidate for the successor committee.
>
> That last sentence is random.

+The vote has to implement a direct, free, equal and secret election.
> +The results are to be publicly available.
> +The election should be completed not later than the end of the ongoing 
> period.
> +Any community member can call on itself or any other person to be a 
> candidate for an election.
>
> What if a majority of the committee is biased and bans everyone they
disagree with to take over the project? They certainly could.
What if the committee's decision is something the majority of the
developers disagree with?

This is why I'm against formalizing such prodecures. They're too inflexible
and absolute, and end up being abused or overused (like videolan's weekly
temporary bannings I've heard of).
Furthermore why do you bring this up now at all? We haven't had accidents
of this nature in quite some time. In fact the last time it was the ML
admin's random incorrect decision to block a discussion which ended up
being a problem that everyone disagreed with. And that was 11 months ago.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH V2] libavfilter/vaapi: enable vaapi rotation feature via call Intel iHD driver

[Rostislav Pehlivanov]

On Fri, 26 Oct 2018 at 04:10, Zhou, Zachary  wrote:

>
>
> > -Original Message-
> > From: ffmpeg-devel [mailto:ffmpeg-devel-boun...@ffmpeg.org] On Behalf Of
> > sean darcy
> > Sent: Thursday, October 25, 2018 11:51 PM
> > To: ffmpeg-devel@ffmpeg.org
> > Subject: Re: [FFmpeg-devel] [PATCH V2] libavfilter/vaapi: enable vaapi
> > rotation feature via call Intel iHD driver
> >
> > On 10/25/18 2:52 AM, Zachary Zhou wrote:
> > > It supports clockwise rotation by 0/90/180/270 degrees defined in
> > > va/va_vpp.h, tested following command line on SKL platform
> > >
> > > dir=0 for 0   degree
> > > dir=1 for 90  degree
> > > dir=2 for 180 degree
> > > dir=3 for 270 degree
> > >
> > > ffmpeg -hwaccel vaapi -vaapi_device /dev/dri/renderD128
> > > -hwaccel_output_format vaapi -i input.264 -vf "rotation_vaapi=dir=1"
> > > -c:v h264_vaapi output.h264
> > >
> > > Signed-off-by: Zachary Zhou 
> > > ---
> > >   configure |   3 +
> > >   libavfilter/Makefile  |   1 +
> > >   libavfilter/allfilters.c  |   1 +
> > >   libavfilter/vaapi_vpp.h   |   1 +
> > >   libavfilter/vf_rotate_vaapi.c | 252
> ++
> > >   5 files changed, 258 insertions(+)
> > >   create mode 100644 libavfilter/vf_rotate_vaapi.c
> > >
> > > diff --git a/configure b/configure
> > > index 85d5dd5962..33aced3d78 100755
> > > --- a/configure
> > > +++ b/configure
> > > @@ -6390,6 +6390,9 @@ if enabled vaapi; then
> > >   fi
> > >
> > >   check_cpp_condition vaapi_1 "va/va.h" "VA_CHECK_VERSION(1, 0, 0)"
> > > +if ! check_struct "va/va.h" "struct _VAProcPipelineCaps"
> rotation_flags;
> > then
> > > +disable rotation_vaapi_filter
> > > +fi
> > >   fi
> > >
> > >   if enabled_all opencl libdrm ; then
> > > diff --git a/libavfilter/Makefile b/libavfilter/Makefile index
> > > 108a2f87d7..534650364a 100644
> > > --- a/libavfilter/Makefile
> > > +++ b/libavfilter/Makefile
> > > @@ -349,6 +349,7 @@ OBJS-$(CONFIG_SETRANGE_FILTER)   +=
> > vf_setparams.o
> > >   OBJS-$(CONFIG_SETSAR_FILTER) += vf_aspect.o
> > >   OBJS-$(CONFIG_SETTB_FILTER)  += settb.o
> > >   OBJS-$(CONFIG_SHARPNESS_VAAPI_FILTER)+= vf_misc_vaapi.o
> > vaapi_vpp.o
> > > +OBJS-$(CONFIG_ROTATION_VAAPI_FILTER) += vf_rotate_vaapi.o
> > vaapi_vpp.o
> > >   OBJS-$(CONFIG_SHOWINFO_FILTER)   += vf_showinfo.o
> > >   OBJS-$(CONFIG_SHOWPALETTE_FILTER)+= vf_showpalette.o
> > >   OBJS-$(CONFIG_SHUFFLEFRAMES_FILTER)  += vf_shuffleframes.o
> > > diff --git a/libavfilter/allfilters.c b/libavfilter/allfilters.c index
> > > 557590850b..4b90a7f440 100644
> > > --- a/libavfilter/allfilters.c
> > > +++ b/libavfilter/allfilters.c
> > > @@ -333,6 +333,7 @@ extern AVFilter ff_vf_setrange;
> > >   extern AVFilter ff_vf_setsar;
> > >   extern AVFilter ff_vf_settb;
> > >   extern AVFilter ff_vf_sharpness_vaapi;
> > > +extern AVFilter ff_vf_rotation_vaapi;
> > >   extern AVFilter ff_vf_showinfo;
> > >   extern AVFilter ff_vf_showpalette;
> > >   extern AVFilter ff_vf_shuffleframes; diff --git
> > > a/libavfilter/vaapi_vpp.h b/libavfilter/vaapi_vpp.h index
> > > 0bc31018d4..cfe19b689f 100644
> > > --- a/libavfilter/vaapi_vpp.h
> > > +++ b/libavfilter/vaapi_vpp.h
> > > @@ -44,6 +44,7 @@ typedef struct VAAPIVPPContext {
> > >   int output_width;   // computed width
> > >   int output_height;  // computed height
> > >
> > > +int rotation_state;
> > >   VABufferID filter_buffers[VAProcFilterCount];
> > >   intnb_filter_buffers;
> > >
> > > diff --git a/libavfilter/vf_rotate_vaapi.c
> > > b/libavfilter/vf_rotate_vaapi.c new file mode 100644 index
> > > 00..34c270e9c7
> > > --- /dev/null
> > > +++ b/libavfilter/vf_rotate_vaapi.c
> > > @@ -0,0 +1,252 @@
> > > +/*
> > > + * This file is part of FFmpeg.
> > > + *
> > > + * FFmpeg is free software; you can redistribute it and/or
> > > + * modify it under the terms of the GNU Lesser General Public
> > > + * License as published by the Free Software Foundation; either
> > > + * version 2.1 of the License, or (at your option) any later version.
> > > + *
> > > + * FFmpeg is distributed in the hope that it will be useful,
> > > + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> > > + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> > GNU
> > > + * Lesser General Public License for more details.
> > > + *
> > > + * You should have received a copy of the GNU Lesser General Public
> > > + * License along with FFmpeg; if not, write to the Free Software
> > > + * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA
> > > +02110-1301 USA  */ #include 
> > > +
> > > +#include "libavutil/avassert.h"
> > > +#include "libavutil/mem.h"
> > > +#include "libavutil/opt.h"
> > > +#include "libavutil/pixdesc.h"
> > > +
> > > +#include "avfilter.h"
> > > +#include "formats.h"
> > > +#include "internal.h"
> > > +#include "vaapi_vp

Re: [FFmpeg-devel] [PATCH v3] avcodec: libdav1d AV1 decoder wrapper.

[Rostislav Pehlivanov]

On Sat, 20 Oct 2018 at 00:50, James Almer  wrote:

> Originally written by Ronald S. Bultje, with fixes, optimizations and
> improvements by James Almer.
>
> Signed-off-by: James Almer 
> ---
> Updated to work with libdav1d git head.
>
>  configure  |   4 +
>  libavcodec/Makefile|   1 +
>  libavcodec/allcodecs.c |   1 +
>  libavcodec/libdav1d.c  | 271 +
>  4 files changed, 277 insertions(+)
>  create mode 100644 libavcodec/libdav1d.c
>

There hasn't even been a 0.1 release yet, and there won't be one that soon.
As far as I know the promise is for that to be out by the 30th next month.
Also I'm still against this making it into the next release.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] avcodec/wmaprodec: improve WMAPRO/XMA gapless output

[Rostislav Pehlivanov]

On Wed, 10 Oct 2018 at 00:15,  wrote:

> From: bnnm 
>
> Improves trac issue #6722. Fixes truncated WMAPRO/XMA output due to delay
> samples and partially applies bitstream gapless info.
>
> This can be tested with files encoding a small nb_samples (like 400),
> which couldn't output anything due to missing delay at the end.
>
> Applying end_skip and partial delay samples would require some extra
> changes, so files are slightly bigger than what should be.
>

> Signed-off-by: bnnm 
> ---
>  libavcodec/wmaprodec.c | 100
> -
>  tests/fate/wma.mak |   1 +
>  2 files changed, 74 insertions(+), 27 deletions(-)
>
> diff --git a/libavcodec/wmaprodec.c b/libavcodec/wmaprodec.c
> index 9439bfa771..e18e2e438f 100644
> --- a/libavcodec/wmaprodec.c
> +++ b/libavcodec/wmaprodec.c
> @@ -216,9 +216,9 @@ typedef struct WMAProDecodeCtx {
>  GetBitContextgb;///< bitstream reader
> context
>  int  buf_bit_size;  ///< buffer size in
> bits
>  uint8_t  drc_gain;  ///< gain for the DRC
> tool
> -int8_t   skip_frame;///< skip output step
>  int8_t   parsed_all_subframes;  ///< all subframes
> decoded?
>  uint8_t  skip_packets;  ///< packets to skip
> to find next packet in a stream (XMA1/2)
> +int8_t   eof_done;  ///< set when EOF
> reached and extra subframe is written (XMA1/2)
>

>  /* subframe/block decode state */
>  int16_t  subframe_len;  ///< current subframe
> length
> @@ -379,12 +379,6 @@ static av_cold int decode_init(WMAProDecodeCtx *s,
> AVCodecContext *avctx, int nu
>  return AVERROR_PATCHWELCOME;
>  }
>
> -/** frame info */
> -if (avctx->codec_id != AV_CODEC_ID_WMAPRO)
> -s->skip_frame = 0;
> -else
> -s->skip_frame = 1; /* skip first frame */
> -
>  s->packet_loss = 1;
>  s->len_prefix  = (s->decode_flags & 0x40);
>
> @@ -1450,21 +1444,38 @@ static int decode_frame(WMAProDecodeCtx *s,
> AVFrame *frame, int *got_frame_ptr)
>  ff_dlog(s->avctx, "drc_gain %i\n", s->drc_gain);
>  }
>
> -/** no idea what these are for, might be the number of samples
> -that need to be skipped at the beginning or end of a stream */
> +/** read encoder delay/padding (gapless) info */
>  if (get_bits1(gb)) {
> -int av_unused skip;
> +int start_skip, end_skip;
> +
>
> -/** usually true for the first frame */
> +/** usually true for the first frame and equal to 1 frame */
>

Usually true? See below.


 if (get_bits1(gb)) {
> -skip = get_bits(gb, av_log2(s->samples_per_frame * 2));
> -ff_dlog(s->avctx, "start skip: %i\n", skip);
> +start_skip = get_bits(gb, av_log2(s->samples_per_frame * 2));
> +start_skip = FFMIN(start_skip, s->samples_per_frame);
> +
> +/* must add for XMA to respect starting skip_samples */
> +s->avctx->internal->skip_samples += start_skip;
>

No, you need to set this during init.
You should also set avctx->delay to the same value.



>  }
>
> -/** sometimes true for the last frame */
> +/** usually true for the last frame and less than 1 frame */


Usually true? Decoders aren't usually true, they're always true.


 if (get_bits1(gb)) {
>
-skip = get_bits(gb, av_log2(s->samples_per_frame * 2));
> -ff_dlog(s->avctx, "end skip: %i\n", skip);
> +end_skip = get_bits(gb, av_log2(s->samples_per_frame * 2));
> +end_skip = FFMIN(end_skip, s->samples_per_frame);
> +
> +//TODO fix end_skip (also needs changes in XMA multistream's
> handling)
> +/* for XMA/WMAPRO end_skip may span last frame + final delay
> samples,
> + * so we'd need some counter to (possibly) skip some in this
> frame and
> + * rest after last frame (buf_size 0), so final samples would
> be:
> + * samples_per_frame + delay_samples - start_skip - end_skip
> + * (files with 1 packet are possible so both skips are
> considered).
> + *
> + * WMAPRO 5.1 in XWMA does't do this and audio is padded
> instead,
> + * and min packets is 2 (assumes only 1/2ch need it). */
> +
> +if (s->avctx->codec_id == AV_CODEC_ID_WMAPRO &&
> s->nb_channels > 2) {
> +frame->nb_samples = s->samples_per_frame - end_skip;
> +}
>

No, this is wrong. Codecs don't need to do this manually, this is done by
libavcodec/decode.c, based on the packet's AV_PKT_DATA_SKIP_SAMPLES side
data.


 }
>
>  }
> @@ -1500,13 +1511,9 @@ static int decode_frame(WMAProDecodeCtx *s, AVFrame
> *frame, int *got_frame_ptr)
> s->samples_per_frame * sizeof(*s->channel[i].out) >> 1);
>  }
>

Re: [FFmpeg-devel] [PATCH] lavf/utils: change truncating packet log to a warning

[Rostislav Pehlivanov]

On Sun, 30 Sep 2018 at 06:08, Rostislav Pehlivanov 
wrote:

> Some scene files do this intentionally for the sake of having a nice
> checksum.
> ---
>  libavformat/utils.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/libavformat/utils.c b/libavformat/utils.c
> index c973a7e0c5..924b99f6d4 100644
> --- a/libavformat/utils.c
> +++ b/libavformat/utils.c
> @@ -257,7 +257,7 @@ int ffio_limit(AVIOContext *s, int size)
>  }
>
>  if (s->maxsize>= 0 && remaining+1 < size) {
> -av_log(NULL, remaining ? AV_LOG_ERROR : AV_LOG_DEBUG,
> "Truncating packet of size %d to %"PRId64"\n", size, remaining+1);
> +av_log(NULL, remaining ? AV_LOG_WARNING : AV_LOG_DEBUG,
> "Truncating packet of size %d to %"PRId64"\n", size, remaining+1);
>  size = remaining+1;
>  }
>  }
> --
> 2.19.0
>
>
Ping?
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH] lavf/utils: change truncating packet log to a warning

[Rostislav Pehlivanov]

Some scene files do this intentionally for the sake of having a nice checksum.
---
 libavformat/utils.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/libavformat/utils.c b/libavformat/utils.c
index c973a7e0c5..924b99f6d4 100644
--- a/libavformat/utils.c
+++ b/libavformat/utils.c
@@ -257,7 +257,7 @@ int ffio_limit(AVIOContext *s, int size)
 }
 
 if (s->maxsize>= 0 && remaining+1 < size) {
-av_log(NULL, remaining ? AV_LOG_ERROR : AV_LOG_DEBUG, "Truncating 
packet of size %d to %"PRId64"\n", size, remaining+1);
+av_log(NULL, remaining ? AV_LOG_WARNING : AV_LOG_DEBUG, 
"Truncating packet of size %d to %"PRId64"\n", size, remaining+1);
 size = remaining+1;
 }
 }
-- 
2.19.0

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

Re: [FFmpeg-devel] [PATCH] avcodec: libdav1d AV1 decoder wrapper

[Rostislav Pehlivanov]

On Sat, 29 Sep 2018 at 15:19, James Almer  wrote:

> On 9/29/2018 10:14 AM, Hendrik Leppkes wrote:
> > On Sat, Sep 29, 2018 at 3:02 PM Devin Heitmueller
> >  wrote:
> >>
> >> On Sat, Sep 29, 2018 at 6:04 AM Rostislav Pehlivanov
> >>  wrote:
> >>> I'd much rather go with the original intent which was to merge the
> decoder
> >>> into lavc.
> >>
> >> Ronald can correct me if I'm wrong, but I suspect a key goal behind
> >> the decoder was to have a standalone library which could be shared
> >> across a variety of projects (both open and closed source).  Merging
> >> it in directly will create a maintenance headache as the two source
> >> trees diverge.  It also makes unit testing more difficult, since
> >> Ronald/VideoLAN can write unit tests for the library (which will
> >> presumably be consumed by a number of projects/products) and be
> >> confident that those same unit tests apply to the version that is used
> >> by ffmpeg.
> >>
> >> I don't think having libx264/libx265 out of tree hasn't been a
> >> nightmare for anyone.  I don't think this case would be any different.
> >>
> >
> > Decoders and encoders are quite a different type of beast. For one
> > decoders are ultimately "finished" at some point, where the number of
> > changes drastically reduces over time, and decoding is the bread and
> > butter of avcodec, which would give immediate av1 support to hundreds
> > if not thousands of applications out there, without any further
> > developer intervention.
>
> I'm guessing LGPL is a deterrent for some potential users VideoLAN
> wanted for this decoder, hence the 2-Clause BSD license in libdav1d.
>

On the other hand the 2-Clause BSD is a deterrent for me to write some
assembly and just generally pour work on it.


> Additionally, I can already name an important key area where not
> > having an internal decoder will be a nightmare: hardware decoding.
> > Our hardware decoding framework heavily relies on having a decoder
> > that does all the header parsing, frame management, and whatnot, and
> > the hardware acceleration hooks just by-pass the actual slice decoding
> > then. If we don't have an internal decoder, we would have to either
> > build half decoder just to hook up hwaccel, or dav1d would have to
> > give us extremely detailed bitstream information and slice-level
> > bitstream hooks, which I don't think is very practical either.
> >
> > A new mainstream codec without hardware acceleration support is not
> > going to make it, no matter how fast you make the decoder.
>
> Yeah, this is one of the main reasons to have it as an internal decoder.
> But considering actual hardware capable of decoding AV1 will not come
> out until like late 2019 at the earliest, there's time for libdav1d to
> mature before porting it becomes a must.
>

Considering the code style and some parts of the internal API are quite
close I reckon the wrapper won't survive for more than a few months, and
will definitely be gone by January.
I'd agree to the wrapper if it didn't make it to 4.1, since it won't be in
4.2. No point in adding a non-default decoder that users may need to
specify (not sure how precedence works with both libaomdec and libdav1id).
Especially knowing how long cargo cult command lines and API usage lasts.


At some point it will be "complete" and development pretty much halted,
> much like vp9 currently is (not counting some missing assembly), so the
> argument about extra maintenance of separate codebases will not apply
> anymore.
>

Given the license difference, the preference of everyone involved with it
for LGPL (its only BSD and a separate library because money) I think
chances are people/companies will sooner abandon it to work on their fork
than use the base version as-is (or in case of companies contribute).
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] avcodec: libdav1d AV1 decoder wrapper

[Rostislav Pehlivanov]

On Fri, 28 Sep 2018 at 22:51, James Almer  wrote:

> From: Ronald S. Bultje 
>
> Originally written by Ronald S. Bultje, with fixes, optimizations and
> improvements by James Almer.
>
> Signed-off-by: James Almer 
>

I'd much rather go with the original intent which was to merge the decoder
into lavc.
We already have libaomdec which is fast-ish but works as a stop-gap
solution until we do that.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH V1 1/3] lavu: Add alpha blending API based on row.

[Rostislav Pehlivanov]

On 25 September 2018 at 16:27, Jun Zhao  wrote:

> Add alpha blending API based on row, support global alpha blending/
> per-pixel blending, and add SSSE3/AVX2 optimizations of the functions.
>
> Signed-off-by: Jun Zhao 
> ---
>  libavutil/Makefile |2 +
>  libavutil/blend.c  |  101 
>  libavutil/blend.h  |   47 ++
>  libavutil/x86/Makefile |3 +-
>  libavutil/x86/blend.h  |   32 
>  libavutil/x86/blend_init.c |  369 ++
> ++
>  6 files changed, 553 insertions(+), 1 deletions(-)
>  create mode 100644 libavutil/blend.c
>  create mode 100644 libavutil/blend.h
>  create mode 100644 libavutil/x86/blend.h
>  create mode 100644 libavutil/x86/blend_init.c
>
> diff --git a/libavutil/Makefile b/libavutil/Makefile
> index 9ed24cf..f1c06e4 100644
> --- a/libavutil/Makefile
> +++ b/libavutil/Makefile
> @@ -10,6 +10,7 @@ HEADERS = adler32.h
>\
>avstring.h\
>avutil.h  \
>base64.h  \
> +  blend.h   \
>blowfish.h\
>bprint.h  \
>bswap.h   \
> @@ -95,6 +96,7 @@ OBJS = adler32.o
> \
> audio_fifo.o \
> avstring.o   \
> base64.o \
> +   blend.o  \
> blowfish.o   \
> bprint.o \
> buffer.o \
> diff --git a/libavutil/blend.c b/libavutil/blend.c
> new file mode 100644
> index 000..e28efa0
> --- /dev/null
> +++ b/libavutil/blend.c
> @@ -0,0 +1,101 @@
> +/*
> + * This file is part of FFmpeg.
> + *
> + * FFmpeg is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License as published by
> + * the Free Software Foundation; either version 2 of the License, or
> + * (at your option) any later version.
> + *
> + * FFmpeg is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
> + * GNU General Public License for more details.
> + *
> + * You should have received a copy of the GNU General Public License along
> + * with FFmpeg; if not, write to the Free Software Foundation, Inc.,
> + * 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA.
> + */
> +
> +#include "libavutil/attributes.h"
> +#include "libavutil/cpu.h"
> +#include "libavutil/mem.h"
> +#include "libavutil/x86/asm.h"
> +#include "libavutil/blend.h"
> +
> +#include "libavutil/x86/blend.h"
> +
> +static void ff_global_blend_row_c(const uint8_t *src0,
> +  const uint8_t *src1,
> +  const uint8_t *alpha, /* XXX: only use
> alpha[0] */
> +  uint8_t *dst,
> +  int width)
> +{
> +int x;
> +for (x = 0; x < width - 1; x += 2) {
> +dst[0] = (src0[0] * alpha[0] + src1[0] * (255 - alpha[0]) + 255)
> >> 8;
> +dst[1] = (src0[1] * alpha[0] + src1[1] * (255 - alpha[0]) + 255)
> >> 8;
> +src0 += 2;
> +src1 += 2;
> +dst  += 2;
> +}
> +if (width & 1) {
> +dst[0] = (src0[0] * alpha[0] + src1[0] * (255 - alpha[0]) + 255)
> >> 8;
> +}
> +}
> +
> +void av_global_blend_row(const uint8_t *src0,
> + const uint8_t *src1,
> + const uint8_t *alpha,
> + uint8_t *dst,
> + int width)
> +{
> +blend_row blend_row_fn = NULL;
> +
> +#if ARCH_X86
> +blend_row_fn = ff_blend_row_init_x86(1);
> +#endif
> +
> +if (!blend_row_fn)
> +blend_row_fn = ff_global_blend_row_c;
> +
> +blend_row_fn(src0, src1, alpha, dst, width);
> +}
> +
> +static void ff_per_pixel_blend_row_c(const uint8_t *src0,
> + const uint8_t *src1,
> + const uint8_t *alpha,
> + uint8_t *dst,
> + int width)
> +{
> +int x;
> +for (x = 0; x < width - 1; x += 2) {
> +dst[0] = (src0[0] * alpha[0] + src1[0] * (255 - alpha[0]) + 255)
> >> 8;
> +dst[1] = (src0[1] * alpha[0] + src1[1] * (255 - alpha[0]) + 255)

Re: [FFmpeg-devel] [PATCH] avcodec/scpr: add version 3 support

[Rostislav Pehlivanov]

On 4 September 2018 at 18:53, Paul B Mahol  wrote:

> Signed-off-by: Paul B Mahol 
> ---
>  libavcodec/scpr.c | 1842 ++---
>  1 file changed, 1558 insertions(+), 284 deletions(-)
>
> diff --git a/libavcodec/scpr.c b/libavcodec/scpr.c
> index ee6bf21b71..4cd9e33d71 100644
> --- a/libavcodec/scpr.c
> +++ b/libavcodec/scpr.c
> @@ -24,47 +24,1538 @@
>  #include 
>  #include 
>
> +#include "libavutil/qsort.h"
> +
>  #include "avcodec.h"
>  #include "bytestream.h"
>  #include "internal.h"
>
> -#define TOP  0x0100
> -#define BOT0x01
> +#define TOP  0x0100
> +#define BOT0x01
>
+
>

I think the range coder is too big so you should put it in another file.


+typedef struct RangeCoder {
> +unsigned   code;
> +unsigned   range;
> +unsigned   code1;
> +} RangeCoder;
> +
> +typedef struct PixelModel {
> +unsignedfreq[256];
> +unsignedlookup[16];
> +unsignedtotal_freq;
> +} PixelModel;
>

You should really specify how many bits the models need rather than leaving
them as random unsigned.



> +
> +typedef struct PixelModel3 {
> +uint8_ttype;
> +uint8_tlength;
> +uint8_tmaxpos;
> +uint8_tfshift;
> +uint16_t   size;
> +uint32_t   cntsum;
> +uint8_tsymbols[256];
> +uint16_t   freqs[256];
> +uint16_t   freqs1[256];
> +uint16_t   cnts[256];
> +uint8_tdectab[32];
> +} PixelModel3;
> +
> +typedef struct FillModel3 {
> +uint32_t   cntsum;
> +uint16_t   freqs[2][5];
> +uint16_t   cnts[5];
> +uint8_tdectab[32];
> +} FillModel3;
> +
> +typedef struct OpModel3 {
> +uint32_t   cntsum;
> +uint16_t   freqs[2][6];
> +uint16_t   cnts[6];
> +uint8_tdectab[32];
> +} OpModel3;
> +
> +typedef struct RunModel3 {
> +uint32_t   cntsum;
> +uint16_t   freqs[2][256];
> +uint16_t   cnts[256];
> +uint8_tdectab[32];
> +} RunModel3;
> +
> +typedef struct SxyModel3 {
> +uint32_t   cntsum;
> +uint16_t   freqs[2][16];
> +uint16_t   cnts[16];
> +uint8_tdectab[32];
> +} SxyModel3;
> +
> +typedef struct MVModel3 {
> +uint32_t   cntsum;
> +uint16_t   freqs[2][512];
> +uint16_t   cnts[512];
> +uint8_tdectab[32];
> +} MVModel3;
> +
> +typedef struct SCPRContext {
> +int version;
> +AVFrame*last_frame;
> +AVFrame*current_frame;
> +GetByteContext  gb;
> +RangeCoder  rc;
> +PixelModel  pixel_model[3][4096];
> +unsignedop_model[6][7];
> +unsignedrun_model[6][257];
> +unsignedrange_model[257];
> +unsignedcount_model[257];
> +unsignedfill_model[6];
> +unsignedsxy_model[4][17];
> +unsignedmv_model[2][513];
> +unsignednbx, nby;
> +unsignednbcount;
> +unsigned   *blocks;
> +unsignedcbits;
> +int cxshift;
> +
> +PixelModel3 pixel_model3[3][4096];
> +RunModel3   run_model3[6];
> +RunModel3   range_model3;
> +RunModel3   count_model3;
> +FillModel3  fill_model3;
> +SxyModel3   sxy_model3[4];
> +MVModel3mv_model3[2];
> +OpModel3op_model3[6];
> +
> +int   (*get_freq)(RangeCoder *rc, unsigned total_freq,
> unsigned *freq);
> +int   (*decode)(GetByteContext *gb, RangeCoder *rc, unsigned
> cumFreq, unsigned freq, unsigned total_freq);
> +} SCPRContext;
> +
> +static void renew_table3(unsigned nsym, uint32_t *cntsum,
> + uint16_t *freqs, uint16_t *freqs1,
> + uint16_t *cnts, uint8_t *dectab)
> +{
> +unsigned a = 0, b = 4096 / nsym, c = b - (b >> 1);
> +
> +*cntsum = c * nsym;
> +
> +for (int d = 0; d < nsym; d++) {
> +freqs[d] = b;
> +freqs1[d] = a;
> +cnts[d] = c;
> +for (int q = a + 128 - 1 >> 7, f = (a + b - 1 >> 7) + 1; q < f;
> q++) {
> +dectab[q] = d;
> +}
>

That's a weird loop, but you don't need brackets here.


+
> +a += b;
> +}
> +}
> +
> +static void reinit_tables3(SCPRContext * s)
> +{
> +for (int i = 0; i < 3; i++) {
> +for (int j = 0; j < 4096; j++) {
> +PixelModel3 *m = &s->pixel_model3[i][j];
> +m->type = 0;
> +}
> +}
> +
> +for (int i = 0; i < 6; i++) {
> +renew_table3(256, &s->run_model3[i].cntsum,
> + s->run_model3[i].freqs[0], s->run_model3[i].freqs[1],
> + s->run_model3[i].cnts, s->run_model3[i].dectab);
> +}
> +
> +renew_table3(256, &s->range_model3.cntsum,
> + s->range_model3.freqs[0], s->range_model3.freqs[1],
> + s->range_model3.cnts, s->range_model3.dectab);
> +
> +renew_table3(5, &s->fill_model3.cntsum,
> + s->fill_model3.freqs[0], s->fill_model3.freqs[1],
> + s->fill_model3.cnts, s->fill_model3.dec

Re: [FFmpeg-devel] [PATCH] aacenc: remove unsupported PCE mappings

[Rostislav Pehlivanov]

On 28 August 2018 at 22:29, Rostislav Pehlivanov 
wrote:

> Turns out those ones make the decoder unable to accurately determine the
> layout, hence making some API users' guess, and sometimes those are correct
> (ffmpeg.c), but most often (especially with side channels) they're wrong.
> The removed ones need to be investigated into as to why the decoder rejects
> them.
>
> Signed-off-by: Rostislav Pehlivanov 
> ---
>  libavcodec/aacenc.h | 177 
>  1 file changed, 177 deletions(-)
>

CCing pkv, if you have the time can you go over what's happening?
Its a bit suspicious that 5.1, 6.1, 7.1, etc. don't use TYPE_LFE but rather
just an SCE (there's a difference in coding).
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH] aacenc: remove unsupported PCE mappings

[Rostislav Pehlivanov]

Turns out those ones make the decoder unable to accurately determine the
layout, hence making some API users' guess, and sometimes those are correct
(ffmpeg.c), but most often (especially with side channels) they're wrong.
The removed ones need to be investigated into as to why the decoder rejects
them.

Signed-off-by: Rostislav Pehlivanov 
---
 libavcodec/aacenc.h | 177 
 1 file changed, 177 deletions(-)

diff --git a/libavcodec/aacenc.h b/libavcodec/aacenc.h
index 5a015ca92e..74f8fcf43a 100644
--- a/libavcodec/aacenc.h
+++ b/libavcodec/aacenc.h
@@ -167,38 +167,6 @@ static const AACPCEInfo aac_pce_configs[] = {
 .config_map = { 2, TYPE_CPE, TYPE_SCE },
 .reorder_map = { 0, 1, 2 },
 },
-{
-.layout = AV_CH_LAYOUT_SURROUND,
-.num_ele = { 2, 0, 0, 0 },
-.pairing = { { 1, 0 }, },
-.index = { { 0, 0 }, },
-.config_map = { 2, TYPE_CPE, TYPE_SCE, },
-.reorder_map = { 0, 1, 2 },
-},
-{
-.layout = AV_CH_LAYOUT_3POINT1,
-.num_ele = { 2, 0, 0, 1 },
-.pairing = { { 1, 0 }, },
-.index = { { 0, 0 }, { 0 }, { 0 }, { 0 }, },
-.config_map = { 3, TYPE_CPE, TYPE_SCE, TYPE_LFE },
-.reorder_map = { 0, 1, 2, 3 },
-},
-{
-.layout = AV_CH_LAYOUT_4POINT0,
-.num_ele = { 2, 0, 1, 0 },
-.pairing = { { 1, 0 }, { 0 }, { 0 }, },
-.index = { { 0, 0 }, { 0 }, { 1 } },
-.config_map = { 3, TYPE_CPE, TYPE_SCE, TYPE_SCE },
-.reorder_map = {  0, 1, 2, 3 },
-},
-{
-.layout = AV_CH_LAYOUT_4POINT1,
-.num_ele = { 2, 1, 1, 0 },
-.pairing = { { 1, 0 }, { 0 }, { 0 }, },
-.index = { { 0, 0 }, { 1 }, { 2 }, { 0 } },
-.config_map = { 4, TYPE_CPE, TYPE_SCE, TYPE_SCE, TYPE_SCE },
-.reorder_map = { 0, 1, 2, 3, 4 },
-},
 {
 .layout = AV_CH_LAYOUT_2_2,
 .num_ele = { 1, 1, 0, 0 },
@@ -215,46 +183,6 @@ static const AACPCEInfo aac_pce_configs[] = {
 .config_map = { 2, TYPE_CPE, TYPE_CPE },
 .reorder_map = { 0, 1, 2, 3 },
 },
-{
-.layout = AV_CH_LAYOUT_5POINT0,
-.num_ele = { 2, 1, 0, 0 },
-.pairing = { { 1, 0 }, { 1 }, },
-.index = { { 0, 0 }, { 1 } },
-.config_map = { 3, TYPE_CPE, TYPE_SCE, TYPE_CPE },
-.reorder_map = { 0, 1, 2, 3, 4 },
-},
-{
-.layout = AV_CH_LAYOUT_5POINT1,
-.num_ele = { 2, 1, 1, 0 },
-.pairing = { { 1, 0 }, { 0 }, { 1 }, },
-.index = { { 0, 0 }, { 1 }, { 1 } },
-.config_map = { 4, TYPE_CPE, TYPE_SCE, TYPE_SCE, TYPE_CPE },
-.reorder_map = { 0, 1, 2, 3, 4, 5 },
-},
-{
-.layout = AV_CH_LAYOUT_5POINT0_BACK,
-.num_ele = { 2, 0, 1, 0 },
-.pairing = { { 1, 0 }, { 0 }, { 1 } },
-.index = { { 0, 0 }, { 0 }, { 1 } },
-.config_map = { 3, TYPE_CPE, TYPE_SCE, TYPE_CPE },
-.reorder_map = { 0, 1, 2, 3, 4 },
-},
-{
-.layout = AV_CH_LAYOUT_5POINT1_BACK,
-.num_ele = { 2, 1, 1, 0 },
-.pairing = { { 1, 0 }, { 0 }, { 1 }, },
-.index = { { 0, 0 }, { 1 }, { 1 } },
-.config_map = { 4, TYPE_CPE, TYPE_SCE, TYPE_SCE, TYPE_CPE },
-.reorder_map = { 0, 1, 2, 3, 4, 5 },
-},
-{
-.layout = AV_CH_LAYOUT_6POINT0,
-.num_ele = { 2, 1, 1, 0 },
-.pairing = { { 1, 0 }, { 1 }, { 0 }, },
-.index = { { 0, 0 }, { 1 }, { 1 } },
-.config_map = { 4, TYPE_CPE, TYPE_SCE, TYPE_CPE, TYPE_SCE },
-.reorder_map = { 0, 1, 2, 3, 4, 5 },
-},
 {
 .layout = AV_CH_LAYOUT_6POINT0_FRONT,
 .num_ele = { 2, 1, 0, 0 },
@@ -263,111 +191,6 @@ static const AACPCEInfo aac_pce_configs[] = {
 .config_map = { 3, TYPE_CPE, TYPE_CPE, TYPE_CPE, },
 .reorder_map = { 0, 1, 2, 3, 4, 5 },
 },
-{
-.layout = AV_CH_LAYOUT_HEXAGONAL,
-.num_ele = { 2, 0, 2, 0 },
-.pairing = { { 1, 0 },{ 0 },{ 1, 0 }, },
-.index = { { 0, 0 },{ 0 },{ 1, 1 } },
-.config_map = { 4, TYPE_CPE, TYPE_SCE, TYPE_CPE, TYPE_SCE, },
-.reorder_map = { 0, 1, 2, 3, 4, 5 },
-},
-{
-.layout = AV_CH_LAYOUT_6POINT1,
-.num_ele = { 2, 1, 2, 0 },
-.pairing = { { 1, 0 },{ 0 },{ 1, 0 }, },
-.index = { { 0, 0 },{ 1 },{ 1, 2 } },
-.config_map = { 5, TYPE_CPE, TYPE_SCE, TYPE_SCE, TYPE_CPE, TYPE_SCE },
-.reorder_map = { 0, 1, 2, 3, 4, 5, 6 },
-},
-{
-.layout = AV_CH_LAYOUT_6POINT1_BACK,
-.num_ele = { 2, 1, 2, 0 },
-.pairing = { { 1, 0 }, { 0 }, { 1, 0 }, },
-.index = { { 0, 0 }, { 1 }, { 1, 2 } },
-.config_map = { 5, TYPE_CPE, TYPE_SCE, TYPE_SCE, TYPE_CPE, TYPE_SCE },
-.reorder_map = { 0, 1, 2, 3, 4, 5, 6 },
-},
-{
-.layout = AV_CH_LAYOUT_6POINT1_FRONT,
-.num_ele = { 2, 1, 2, 0 },
-.pairing = { { 1, 0 }, { 0 }, { 1, 0 }, },
-

Re: [FFmpeg-devel] [PATCH 1/2] avcodec: add MatchWare Screen Capture Codec

[Rostislav Pehlivanov]

On Mon, 27 Aug 2018 at 19:20, Rostislav Pehlivanov 
wrote:

>
>
> On Sat, 25 Aug 2018 at 21:04, Paul B Mahol  wrote:
>
>> Signed-off-by: Paul B Mahol 
>> ---
>>  configure   |   1 +
>>  libavcodec/Makefile |   1 +
>>  libavcodec/allcodecs.c  |   1 +
>>  libavcodec/avcodec.h|   1 +
>>  libavcodec/codec_desc.c |   7 ++
>>  libavcodec/mwsc.c   | 192 
>>  libavformat/riff.c  |   1 +
>>  7 files changed, 204 insertions(+)
>>  create mode 100644 libavcodec/mwsc.c
>>
>> +static int decode_frame(AVCodecContext *avctx,
>> +void *data, int *got_frame,
>> +AVPacket *avpkt)
>> +{
>> +MWSCContext *s = avctx->priv_data;
>> +AVFrame *frame = data;
>> +uint8_t *buf = avpkt->data;
>> +int buf_size = avpkt->size;
>> +GetByteContext gb;
>> +GetByteContext gbp;
>> +PutByteContext pb;
>> +int ret;
>>
>
> Can you check that avpkt->size isn't larger than the deflate buffer you've
> allocated?
>

If zlib checks that the buffer size is smaller than what it has to unpack
don't, same as the wincam decoder.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 2/2] avcodec: add WinCAM Motion Video decoder

[Rostislav Pehlivanov]

On Sat, 25 Aug 2018 at 21:12, Paul B Mahol  wrote:

> Signed-off-by: Paul B Mahol 
> ---
>  configure   |   1 +
>  libavcodec/Makefile |   1 +
>  libavcodec/allcodecs.c  |   1 +
>  libavcodec/avcodec.h|   1 +
>  libavcodec/codec_desc.c |   7 ++
>  libavcodec/wcmv.c   | 247 
>  libavformat/riff.c  |   1 +
>  7 files changed, 259 insertions(+)
>  create mode 100644 libavcodec/wcmv.c
>
> diff --git a/configure b/configure
> index 0c1f6a79a7..469797935e 100755
> --- a/configure
> +++ b/configure
> @@ -2750,6 +2750,7 @@ vp6f_decoder_select="vp6_decoder"
>  vp7_decoder_select="h264pred videodsp vp8dsp"
>  vp8_decoder_select="h264pred videodsp vp8dsp"
>  vp9_decoder_select="videodsp vp9_parser vp9_superframe_split_bsf"
> +wcmv_decoder_deps="zlib"
>  webp_decoder_select="vp8_decoder exif"
>  wmalossless_decoder_select="llauddsp"
>  wmapro_decoder_select="mdct sinewin wma_freqs"
> diff --git a/libavcodec/Makefile b/libavcodec/Makefile
> index aee4f5431a..f8673f0121 100644
> --- a/libavcodec/Makefile
> +++ b/libavcodec/Makefile
> @@ -677,6 +677,7 @@ OBJS-$(CONFIG_VP9_V4L2M2M_DECODER) +=
> v4l2_m2m_dec.o
>  OBJS-$(CONFIG_VQA_DECODER) += vqavideo.o
>  OBJS-$(CONFIG_WAVPACK_DECODER) += wavpack.o
>  OBJS-$(CONFIG_WAVPACK_ENCODER) += wavpackenc.o
> +OBJS-$(CONFIG_WCMV_DECODER)+= wcmv.o
>  OBJS-$(CONFIG_WEBP_DECODER)+= webp.o
>  OBJS-$(CONFIG_WEBVTT_DECODER)  += webvttdec.o ass.o
>  OBJS-$(CONFIG_WEBVTT_ENCODER)  += webvttenc.o ass_split.o
> diff --git a/libavcodec/allcodecs.c b/libavcodec/allcodecs.c
> index d41868c591..42d98f9b0a 100644
> --- a/libavcodec/allcodecs.c
> +++ b/libavcodec/allcodecs.c
> @@ -338,6 +338,7 @@ extern AVCodec ff_vp9_v4l2m2m_decoder;
>  extern AVCodec ff_vqa_decoder;
>  extern AVCodec ff_bitpacked_decoder;
>  extern AVCodec ff_webp_decoder;
> +extern AVCodec ff_wcmv_decoder;
>  extern AVCodec ff_wrapped_avframe_encoder;
>  extern AVCodec ff_wrapped_avframe_decoder;
>  extern AVCodec ff_wmv1_encoder;
> diff --git a/libavcodec/avcodec.h b/libavcodec/avcodec.h
> index be41b8cf0e..b6688b7af3 100644
> --- a/libavcodec/avcodec.h
> +++ b/libavcodec/avcodec.h
> @@ -450,6 +450,7 @@ enum AVCodecID {
>  AV_CODEC_ID_IMM4,
>  AV_CODEC_ID_PROSUMER,
>  AV_CODEC_ID_MWSC,
> +AV_CODEC_ID_WCMV,
>
>  /* various PCM "codecs" */
>  AV_CODEC_ID_FIRST_AUDIO = 0x1, ///< A dummy id pointing at
> the start of audio codecs
> diff --git a/libavcodec/codec_desc.c b/libavcodec/codec_desc.c
> index 129d0f1aac..46dfe3f5e5 100644
> --- a/libavcodec/codec_desc.c
> +++ b/libavcodec/codec_desc.c
> @@ -1675,6 +1675,13 @@ static const AVCodecDescriptor codec_descriptors[]
> = {
>  .long_name = NULL_IF_CONFIG_SMALL("MatchWare Screen Capture
> Codec"),
>  .props = AV_CODEC_PROP_LOSSLESS,
>  },
> +{
> +.id= AV_CODEC_ID_WCMV,
> +.type  = AVMEDIA_TYPE_VIDEO,
> +.name  = "wcmv",
> +.long_name = NULL_IF_CONFIG_SMALL("WinCAM Motion Video"),
> +.props = AV_CODEC_PROP_LOSSLESS,
> +},
>
>  /* various PCM "codecs" */
>  {
> diff --git a/libavcodec/wcmv.c b/libavcodec/wcmv.c
> new file mode 100644
> index 00..74cb1166bb
> --- /dev/null
> +++ b/libavcodec/wcmv.c
> @@ -0,0 +1,247 @@
> +/*
> + * WinCAM Motion Video decoder
> + *
> + * Copyright (c) 2018 Paul B Mahol
> + *
> + * This file is part of FFmpeg.
> + *
> + * FFmpeg is free software; you can redistribute it and/or
> + * modify it under the terms of the GNU Lesser General Public
> + * License as published by the Free Software Foundation; either
> + * version 2.1 of the License, or (at your option) any later version.
> + *
> + * FFmpeg is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
> + * Lesser General Public License for more details.
> + *
> + * You should have received a copy of the GNU Lesser General Public
> + * License along with FFmpeg; if not, write to the Free Software
> + * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA
> 02110-1301 USA
> + */
> +
> +#include 
> +#include 
> +#include 
> +
> +#include "avcodec.h"
> +#include "bytestream.h"
> +#include "internal.h"
> +
> +#include 
> +
> +typedef struct WCMVContext {
> +z_streamzstream;
> +AVFrame*prev_frame;
> +uint8_t block_data[65536*8];
> +} WCMVContext;
> +
> +static int decode_frame(AVCodecContext *avctx,
> +void *data, int *got_frame,
> +AVPacket *avpkt)
> +{
> +WCMVContext *s = avctx->priv_data;
> +AVFrame *frame = data;
> +int skip, blocks, zret, ret, intra = 0;
> +GetByteContext gb;
> +uint8_t *dst;
> +
> +ret = inflateReset(&s->zstream);
> +if (ret != Z_OK) {
> +av_log(avctx, AV_LOG_ERRO

Re: [FFmpeg-devel] [PATCH 1/2] avcodec: add MatchWare Screen Capture Codec

[Rostislav Pehlivanov]

On Sat, 25 Aug 2018 at 21:04, Paul B Mahol  wrote:

> Signed-off-by: Paul B Mahol 
> ---
>  configure   |   1 +
>  libavcodec/Makefile |   1 +
>  libavcodec/allcodecs.c  |   1 +
>  libavcodec/avcodec.h|   1 +
>  libavcodec/codec_desc.c |   7 ++
>  libavcodec/mwsc.c   | 192 
>  libavformat/riff.c  |   1 +
>  7 files changed, 204 insertions(+)
>  create mode 100644 libavcodec/mwsc.c
>
> diff --git a/configure b/configure
> index b9c9d0b307..0c1f6a79a7 100755
> --- a/configure
> +++ b/configure
> @@ -2679,6 +2679,7 @@ msmpeg4v3_decoder_select="h263_decoder"
>  msmpeg4v3_encoder_select="h263_encoder"
>  mss2_decoder_select="mpegvideo qpeldsp vc1_decoder"
>  mts2_decoder_select="mss34dsp"
> +mwsc_decoder_deps="zlib"
>  mxpeg_decoder_select="mjpeg_decoder"
>  nellymoser_decoder_select="mdct sinewin"
>  nellymoser_encoder_select="audio_frame_queue mdct sinewin"
> diff --git a/libavcodec/Makefile b/libavcodec/Makefile
> index 9a309c348e..aee4f5431a 100644
> --- a/libavcodec/Makefile
> +++ b/libavcodec/Makefile
> @@ -482,6 +482,7 @@ OBJS-$(CONFIG_MSZH_DECODER)+= lcldec.o
>  OBJS-$(CONFIG_MTS2_DECODER)+= mss4.o
>  OBJS-$(CONFIG_MVC1_DECODER)+= mvcdec.o
>  OBJS-$(CONFIG_MVC2_DECODER)+= mvcdec.o
> +OBJS-$(CONFIG_MWSC_DECODER)+= mwsc.o
>  OBJS-$(CONFIG_MXPEG_DECODER)   += mxpegdec.o
>  OBJS-$(CONFIG_NELLYMOSER_DECODER)  += nellymoserdec.o nellymoser.o
>  OBJS-$(CONFIG_NELLYMOSER_ENCODER)  += nellymoserenc.o nellymoser.o
> diff --git a/libavcodec/allcodecs.c b/libavcodec/allcodecs.c
> index b1d1ef26c0..d41868c591 100644
> --- a/libavcodec/allcodecs.c
> +++ b/libavcodec/allcodecs.c
> @@ -212,6 +212,7 @@ extern AVCodec ff_mszh_decoder;
>  extern AVCodec ff_mts2_decoder;
>  extern AVCodec ff_mvc1_decoder;
>  extern AVCodec ff_mvc2_decoder;
> +extern AVCodec ff_mwsc_decoder;
>  extern AVCodec ff_mxpeg_decoder;
>  extern AVCodec ff_nuv_decoder;
>  extern AVCodec ff_paf_video_decoder;
> diff --git a/libavcodec/avcodec.h b/libavcodec/avcodec.h
> index 86a658a233..be41b8cf0e 100644
> --- a/libavcodec/avcodec.h
> +++ b/libavcodec/avcodec.h
> @@ -449,6 +449,7 @@ enum AVCodecID {
>  AV_CODEC_ID_FITS,
>  AV_CODEC_ID_IMM4,
>  AV_CODEC_ID_PROSUMER,
> +AV_CODEC_ID_MWSC,
>
>  /* various PCM "codecs" */
>  AV_CODEC_ID_FIRST_AUDIO = 0x1, ///< A dummy id pointing at
> the start of audio codecs
> diff --git a/libavcodec/codec_desc.c b/libavcodec/codec_desc.c
> index e611183599..129d0f1aac 100644
> --- a/libavcodec/codec_desc.c
> +++ b/libavcodec/codec_desc.c
> @@ -1668,6 +1668,13 @@ static const AVCodecDescriptor codec_descriptors[]
> = {
>  .long_name = NULL_IF_CONFIG_SMALL("Brooktree ProSumer Video"),
>  .props = AV_CODEC_PROP_INTRA_ONLY | AV_CODEC_PROP_LOSSY,
>  },
> +{
> +.id= AV_CODEC_ID_MWSC,
> +.type  = AVMEDIA_TYPE_VIDEO,
> +.name  = "mwsc",
> +.long_name = NULL_IF_CONFIG_SMALL("MatchWare Screen Capture
> Codec"),
> +.props = AV_CODEC_PROP_LOSSLESS,
> +},
>
>  /* various PCM "codecs" */
>  {
> diff --git a/libavcodec/mwsc.c b/libavcodec/mwsc.c
> new file mode 100644
> index 00..c1a5aca3c0
> --- /dev/null
> +++ b/libavcodec/mwsc.c
> @@ -0,0 +1,192 @@
> +/*
> + * MatchWare Screen Capture Codec decoder
> + *
> + * Copyright (c) 2018 Paul B Mahol
> + *
> + * This file is part of FFmpeg.
> + *
> + * FFmpeg is free software; you can redistribute it and/or
> + * modify it under the terms of the GNU Lesser General Public
> + * License as published by the Free Software Foundation; either
> + * version 2.1 of the License, or (at your option) any later version.
> + *
> + * FFmpeg is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
> + * Lesser General Public License for more details.
> + *
> + * You should have received a copy of the GNU Lesser General Public
> + * License along with FFmpeg; if not, write to the Free Software
> + * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA
> 02110-1301 USA
> + */
> +
> +#include 
> +#include 
> +#include 
> +
> +#include "avcodec.h"
> +#include "bytestream.h"
> +#include "internal.h"
> +
> +#include 
> +
> +typedef struct MWSCContext {
> +unsigned int  decomp_size;
> +uint8_t  *decomp_buf;
> +z_stream  zstream;
> +AVFrame  *prev_frame;
> +} MWSCContext;
> +
> +static int rle_uncompress(GetByteContext *gb, PutByteContext *pb,
> GetByteContext *gbp,
> +  int width, int height, int stride, int
> pb_linesize, int gbp_linesize)
> +{
> +int intra = 1, w = 0;
> +
> +bytestream2_seek_p(pb, (height - 1) * pb_linesize, SEEK_SET);
> +
> +while (bytestream2_get_bytes_left(gb) > 0) {
> +uint32_t fill

Re: [FFmpeg-devel] [PATCH] avcodec: add MatchWare Screen Capture Codec

[Rostislav Pehlivanov]

On Fri, 24 Aug 2018 at 21:07, Paul B Mahol  wrote:

> Signed-off-by: Paul B Mahol 
> ---
>  configure   |   1 +
>  libavcodec/Makefile |   1 +
>  libavcodec/allcodecs.c  |   1 +
>  libavcodec/avcodec.h|   1 +
>  libavcodec/codec_desc.c |   7 ++
>  libavcodec/mwsc.c   | 182 
>  libavformat/riff.c  |   1 +
>  7 files changed, 194 insertions(+)
>  create mode 100644 libavcodec/mwsc.c
>
> diff --git a/configure b/configure
> index b9c9d0b307..0c1f6a79a7 100755
> --- a/configure
> +++ b/configure
> @@ -2679,6 +2679,7 @@ msmpeg4v3_decoder_select="h263_decoder"
>  msmpeg4v3_encoder_select="h263_encoder"
>  mss2_decoder_select="mpegvideo qpeldsp vc1_decoder"
>  mts2_decoder_select="mss34dsp"
> +mwsc_decoder_deps="zlib"
>  mxpeg_decoder_select="mjpeg_decoder"
>  nellymoser_decoder_select="mdct sinewin"
>  nellymoser_encoder_select="audio_frame_queue mdct sinewin"
> diff --git a/libavcodec/Makefile b/libavcodec/Makefile
> index 9a309c348e..aee4f5431a 100644
> --- a/libavcodec/Makefile
> +++ b/libavcodec/Makefile
> @@ -482,6 +482,7 @@ OBJS-$(CONFIG_MSZH_DECODER)+= lcldec.o
>  OBJS-$(CONFIG_MTS2_DECODER)+= mss4.o
>  OBJS-$(CONFIG_MVC1_DECODER)+= mvcdec.o
>  OBJS-$(CONFIG_MVC2_DECODER)+= mvcdec.o
> +OBJS-$(CONFIG_MWSC_DECODER)+= mwsc.o
>  OBJS-$(CONFIG_MXPEG_DECODER)   += mxpegdec.o
>  OBJS-$(CONFIG_NELLYMOSER_DECODER)  += nellymoserdec.o nellymoser.o
>  OBJS-$(CONFIG_NELLYMOSER_ENCODER)  += nellymoserenc.o nellymoser.o
> diff --git a/libavcodec/allcodecs.c b/libavcodec/allcodecs.c
> index b1d1ef26c0..d41868c591 100644
> --- a/libavcodec/allcodecs.c
> +++ b/libavcodec/allcodecs.c
> @@ -212,6 +212,7 @@ extern AVCodec ff_mszh_decoder;
>  extern AVCodec ff_mts2_decoder;
>  extern AVCodec ff_mvc1_decoder;
>  extern AVCodec ff_mvc2_decoder;
> +extern AVCodec ff_mwsc_decoder;
>  extern AVCodec ff_mxpeg_decoder;
>  extern AVCodec ff_nuv_decoder;
>  extern AVCodec ff_paf_video_decoder;
> diff --git a/libavcodec/avcodec.h b/libavcodec/avcodec.h
> index 2a4be2ca4f..b327284449 100644
> --- a/libavcodec/avcodec.h
> +++ b/libavcodec/avcodec.h
> @@ -449,6 +449,7 @@ enum AVCodecID {
>  AV_CODEC_ID_FITS,
>  AV_CODEC_ID_IMM4,
>  AV_CODEC_ID_PROSUMER,
> +AV_CODEC_ID_MWSC,
>
>  /* various PCM "codecs" */
>  AV_CODEC_ID_FIRST_AUDIO = 0x1, ///< A dummy id pointing at
> the start of audio codecs
> diff --git a/libavcodec/codec_desc.c b/libavcodec/codec_desc.c
> index e611183599..129d0f1aac 100644
> --- a/libavcodec/codec_desc.c
> +++ b/libavcodec/codec_desc.c
> @@ -1668,6 +1668,13 @@ static const AVCodecDescriptor codec_descriptors[]
> = {
>  .long_name = NULL_IF_CONFIG_SMALL("Brooktree ProSumer Video"),
>  .props = AV_CODEC_PROP_INTRA_ONLY | AV_CODEC_PROP_LOSSY,
>  },
> +{
> +.id= AV_CODEC_ID_MWSC,
> +.type  = AVMEDIA_TYPE_VIDEO,
> +.name  = "mwsc",
> +.long_name = NULL_IF_CONFIG_SMALL("MatchWare Screen Capture
> Codec"),
> +.props = AV_CODEC_PROP_LOSSLESS,
> +},
>
>  /* various PCM "codecs" */
>  {
> diff --git a/libavcodec/mwsc.c b/libavcodec/mwsc.c
> new file mode 100644
> index 00..632d1cc30c
> --- /dev/null
> +++ b/libavcodec/mwsc.c
> @@ -0,0 +1,182 @@
> +/*
> + * MatchWare Screen Capture Codec decoder
> + *
> + * Copyright (c) 2018 Paul B Mahol
> + *
> + * This file is part of FFmpeg.
> + *
> + * FFmpeg is free software; you can redistribute it and/or
> + * modify it under the terms of the GNU Lesser General Public
> + * License as published by the Free Software Foundation; either
> + * version 2.1 of the License, or (at your option) any later version.
> + *
> + * FFmpeg is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
> + * Lesser General Public License for more details.
> + *
> + * You should have received a copy of the GNU Lesser General Public
> + * License along with FFmpeg; if not, write to the Free Software
> + * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA
> 02110-1301 USA
> + */
> +
> +#include 
> +#include 
> +#include 
> +
> +#include "avcodec.h"
> +#include "bytestream.h"
> +#include "internal.h"
> +
> +#include 
> +
> +typedef struct MWSCContext {
> +unsigned  bpp;
> +unsigned int  decomp_size;
> +uint8_t  *decomp_buf;
> +unsigned int  uncomp_size;
> +uint8_t  *uncomp_buf;
> +z_stream  zstream;
> +} MWSCContext;
> +
> +static int rle_uncompress(AVCodecContext *avctx, GetByteContext *gb,
> PutByteContext *pb, int bpp)
> +{
> +int intra = 1;
> +
> +while (bytestream2_get_bytes_left(gb) > 0) {
> +uint32_t fill = bytestream2_get_le24(gb);
> +unsigned run = bytestream2_get_byte(gb);
> +int j;
>

Re: [FFmpeg-devel] [PATCH] avcodec: add Brooktree ProSumer Video decoder

[Rostislav Pehlivanov]

On Wed, 22 Aug 2018 at 17:01, Paul B Mahol  wrote:

> Signed-off-by: Paul B Mahol 
> ---
>  libavcodec/Makefile |   1 +
>  libavcodec/allcodecs.c  |   1 +
>  libavcodec/avcodec.h|   1 +
>  libavcodec/codec_desc.c |   7 +
>  libavcodec/prosumer.c   | 405 
>  libavformat/riff.c  |   1 +
>  6 files changed, 416 insertions(+)
>  create mode 100644 libavcodec/prosumer.c
>
> diff --git a/libavcodec/Makefile b/libavcodec/Makefile
> index f0c8226283..9a309c348e 100644
> --- a/libavcodec/Makefile
> +++ b/libavcodec/Makefile
> @@ -515,6 +515,7 @@ OBJS-$(CONFIG_PRORES_DECODER)  += proresdec2.o
> proresdsp.o proresdata.o
>  OBJS-$(CONFIG_PRORES_ENCODER)  += proresenc_anatoliy.o
>  OBJS-$(CONFIG_PRORES_AW_ENCODER)   += proresenc_anatoliy.o
>  OBJS-$(CONFIG_PRORES_KS_ENCODER)   += proresenc_kostya.o proresdata.o
> +OBJS-$(CONFIG_PROSUMER_DECODER)+= prosumer.o
>  OBJS-$(CONFIG_PSD_DECODER) += psd.o
>  OBJS-$(CONFIG_PTX_DECODER) += ptx.o
>  OBJS-$(CONFIG_QCELP_DECODER)   += qcelpdec.o \
> diff --git a/libavcodec/allcodecs.c b/libavcodec/allcodecs.c
> index fd35fc1d0b..b1d1ef26c0 100644
> --- a/libavcodec/allcodecs.c
> +++ b/libavcodec/allcodecs.c
> @@ -235,6 +235,7 @@ extern AVCodec ff_prores_encoder;
>  extern AVCodec ff_prores_decoder;
>  extern AVCodec ff_prores_aw_encoder;
>  extern AVCodec ff_prores_ks_encoder;
> +extern AVCodec ff_prosumer_decoder;
>  extern AVCodec ff_psd_decoder;
>  extern AVCodec ff_ptx_decoder;
>  extern AVCodec ff_qdraw_decoder;
> diff --git a/libavcodec/avcodec.h b/libavcodec/avcodec.h
> index 31e50d5a94..2a4be2ca4f 100644
> --- a/libavcodec/avcodec.h
> +++ b/libavcodec/avcodec.h
> @@ -448,6 +448,7 @@ enum AVCodecID {
>  AV_CODEC_ID_GDV,
>  AV_CODEC_ID_FITS,
>  AV_CODEC_ID_IMM4,
> +AV_CODEC_ID_PROSUMER,
>
>  /* various PCM "codecs" */
>  AV_CODEC_ID_FIRST_AUDIO = 0x1, ///< A dummy id pointing at
> the start of audio codecs
> diff --git a/libavcodec/codec_desc.c b/libavcodec/codec_desc.c
> index af66b35d2b..e611183599 100644
> --- a/libavcodec/codec_desc.c
> +++ b/libavcodec/codec_desc.c
> @@ -1661,6 +1661,13 @@ static const AVCodecDescriptor codec_descriptors[]
> = {
>  .long_name = NULL_IF_CONFIG_SMALL("Infinity IMM4"),
>  .props = AV_CODEC_PROP_LOSSY,
>  },
> +{
> +.id= AV_CODEC_ID_PROSUMER,
> +.type  = AVMEDIA_TYPE_VIDEO,
> +.name  = "prosumer",
> +.long_name = NULL_IF_CONFIG_SMALL("Brooktree ProSumer Video"),
> +.props = AV_CODEC_PROP_INTRA_ONLY | AV_CODEC_PROP_LOSSY,
> +},
>
>  /* various PCM "codecs" */
>  {
> diff --git a/libavcodec/prosumer.c b/libavcodec/prosumer.c
> new file mode 100644
> index 00..7b9d5e7bdb
> --- /dev/null
> +++ b/libavcodec/prosumer.c
> @@ -0,0 +1,405 @@
> +/*
> + * Brooktree ProSumer Video decoder
> + * Copyright (c) 2018 Paul B Mahol
> + *
> + * This file is part of FFmpeg.
> + *
> + * FFmpeg is free software; you can redistribute it and/or
> + * modify it under the terms of the GNU Lesser General Public
> + * License as published by the Free Software Foundation; either
> + * version 2.1 of the License, or (at your option) any later version.
> + *
> + * FFmpeg is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
> + * Lesser General Public License for more details.
> + *
> + * You should have received a copy of the GNU Lesser General Public
> + * License along with FFmpeg; if not, write to the Free Software
> + * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA
> 02110-1301 USA
> + */
> +
> +#include 
> +#include 
> +#include 
> +
> +#include "libavutil/imgutils.h"
> +#include "libavutil/internal.h"
> +#include "libavutil/intreadwrite.h"
> +#include "libavutil/mem.h"
> +
> +#include "avcodec.h"
> +#include "bytestream.h"
> +#include "internal.h"
> +
> +typedef struct ProSumerContext {
> +GetByteContext gb;
> +PutByteContext pb;
> +
> +unsigned stride;
> +unsigned size;
> +unsigned lut[0x1];
>

uint32_t, see below.



> +uint8_t *table_b;
> +uint8_t *decbuffer;
> +} ProSumerContext;
> +
> +#define PAIR(high, low) (((uint64_t)(high)< +
> +static int decompress(GetByteContext *gb, int size, PutByteContext *pb,
> const unsigned *lut)
> +{
> +int i, pos, idx, cnt, fill;
> +unsigned a, b, c;
>

uint32_t, see below.


+
> +bytestream2_skip(gb, 32);
> +cnt = 4;
> +a = bytestream2_get_le32(gb);
> +idx = a >> 20;
> +b = lut[2 * idx];
> +
> +while (1) {
>

This loop looks a bit lock-prone but since you check the bytestream reader
status everywhere should be fine.



> +if (((b & 0xFF00u) != 0x8000u) || (b & 0xFFu)) {
> +if ((b & 0xFF00u) != 0x8000u) {
> +

Re: [FFmpeg-devel] [PATCH v3 38/41] vaapi_encode: Let the reconstructed frame pool be sized dynamically

[Rostislav Pehlivanov]

On Thu, 23 Aug 2018 at 00:49, Mark Thompson  wrote:

> No supported encode driver requires the pool to be fixed-size, so just
> remove this constraint.
> ---
>  libavcodec/vaapi_encode.c | 3 ---
>  1 file changed, 3 deletions(-)
>
> diff --git a/libavcodec/vaapi_encode.c b/libavcodec/vaapi_encode.c
> index d03bd1925e..e20280065c 100644
> --- a/libavcodec/vaapi_encode.c
> +++ b/libavcodec/vaapi_encode.c
> @@ -1721,9 +1721,6 @@ static av_cold int
> vaapi_encode_create_recon_frames(AVCodecContext *avctx)
>  ctx->recon_frames->sw_format = recon_format;
>  ctx->recon_frames->width = ctx->surface_width;
>  ctx->recon_frames->height= ctx->surface_height;
> -// At most three IDR/I/P frames and two runs of B frames can be in
> -// flight at any one time.
> -ctx->recon_frames->initial_pool_size = 3 + 2 * ctx->b_per_p;
>
>  err = av_hwframe_ctx_init(ctx->recon_frames_ref);
>  if (err < 0) {
> --
> 2.18.0
>
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel


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

Re: [FFmpeg-devel] [PATCH 1/2] avcodec/libopusenc: support encoding packets of sizes bigger than 60ms

[Rostislav Pehlivanov]

On Thu, 23 Aug 2018 at 23:18, James Almer  wrote:

> Packets of sizes 80ms, 100ms and 120ms can be encoded since libopus 1.2
>
> Signed-off-by: James Almer 
> ---
>  libavcodec/libopusenc.c | 20 +++-
>  1 file changed, 15 insertions(+), 5 deletions(-)
>
> diff --git a/libavcodec/libopusenc.c b/libavcodec/libopusenc.c
> index 4ae81b0bb2..7c025a66d7 100644
> --- a/libavcodec/libopusenc.c
> +++ b/libavcodec/libopusenc.c
> @@ -271,12 +271,22 @@ static av_cold int
> libopus_encode_init(AVCodecContext *avctx)
>  case 960:
>  case 1920:
>  case 2880:
> +#ifdef OPUS_FRAMESIZE_120_MS
> +case 3840:
> +case 4800:
> +case 5760:
> +#endif
>  opus->opts.packet_size =
>  avctx->frame_size  = frame_size * avctx->sample_rate / 48000;
>  break;
>  default:
>  av_log(avctx, AV_LOG_ERROR, "Invalid frame duration: %g.\n"
> -   "Frame duration must be exactly one of: 2.5, 5, 10, 20, 40
> or 60.\n",
> +   "Frame duration must be exactly one of: 2.5, 5, 10, 20, 40"
> +#ifdef OPUS_FRAMESIZE_120_MS
> +   ", 60, 80, 100 or 120.\n",
> +#else
> +   " or 60.\n",
> +#endif
> opus->opts.frame_duration);
>  return AVERROR(EINVAL);
>  }
> @@ -463,10 +473,10 @@ static int libopus_encode(AVCodecContext *avctx,
> AVPacket *avpkt,
>  memset(audio, 0, opus->opts.packet_size * sample_size);
>  }
>
> -/* Maximum packet size taken from opusenc in opus-tools. 60ms packets
> - * consist of 3 frames in one packet. The maximum frame size is 1275
> +/* Maximum packet size taken from opusenc in opus-tools. 120ms packets
> + * consist of 6 frames in one packet. The maximum frame size is 1275
>   * bytes along with the largest possible packet header of 7 bytes. */
> -if ((ret = ff_alloc_packet2(avctx, avpkt, (1275 * 3 + 7) *
> opus->stream_count, 0)) < 0)
> +if ((ret = ff_alloc_packet2(avctx, avpkt, (1275 * 6 + 7) *
> opus->stream_count, 0)) < 0)
>  return ret;
>
>  if (avctx->sample_fmt == AV_SAMPLE_FMT_FLT)
> @@ -534,7 +544,7 @@ static const AVOption libopus_options[] = {
>  { "voip",   "Favor improved speech intelligibility",   0,
> AV_OPT_TYPE_CONST, { .i64 = OPUS_APPLICATION_VOIP },0, 0,
> FLAGS, "application" },
>  { "audio",  "Favor faithfulness to the input", 0,
> AV_OPT_TYPE_CONST, { .i64 = OPUS_APPLICATION_AUDIO },   0, 0,
> FLAGS, "application" },
>  { "lowdelay",   "Restrict to only the lowest delay modes", 0,
> AV_OPT_TYPE_CONST, { .i64 = OPUS_APPLICATION_RESTRICTED_LOWDELAY }, 0, 0,
> FLAGS, "application" },
> -{ "frame_duration", "Duration of a frame in milliseconds",
> OFFSET(frame_duration), AV_OPT_TYPE_FLOAT, { .dbl = 20.0 }, 2.5, 60.0,
> FLAGS },
> +{ "frame_duration", "Duration of a frame in milliseconds",
> OFFSET(frame_duration), AV_OPT_TYPE_FLOAT, { .dbl = 20.0 }, 2.5, 120.0,
> FLAGS },
>  { "packet_loss","Expected packet loss percentage",
>  OFFSET(packet_loss),AV_OPT_TYPE_INT,   { .i64 = 0 },0,   100,
> FLAGS },
>  { "vbr","Variable bit rate mode",
> OFFSET(vbr),AV_OPT_TYPE_INT,   { .i64 = 1 },0,   2,
> FLAGS, "vbr" },
>  { "off","Use constant bit rate", 0,
> AV_OPT_TYPE_CONST, { .i64 = 0 }, 0, 0, FLAGS, "vbr" },
> --
> 2.18.0
>
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel


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

Re: [FFmpeg-devel] Register for VDD 2018 conference

[Rostislav Pehlivanov]

On Wed, 22 Aug 2018 at 20:12, Michael Niedermayer 
wrote:

> On Wed, Aug 22, 2018 at 03:14:53PM +0200, Jean-Baptiste Kempf wrote:
> > Hello fellow devs,
> >
> > VideoLAN is happy to invite you to the usual conference of the end of
> the summer:
> > VDD2018 is happening in Paris, for the 10 years of the original conf.
> >
> > As usual, this is a very technical conference focused on open source
> multimedia development.
> > We will talk about AV1, FFv1, FFv2, x264/x265, VLC, FFmpeg and other
> related technologies.
>
> what is FFv2 ?
>
> [...]
> --
> Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
>
> Observe your enemies, for they first find out your faults. -- Antisthenes
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel


I'm working on it
https://github.com/atomnuker/FFmpeg/tree/exp_ffv2_daala
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] avcodec: add IMM4 decoder

[Rostislav Pehlivanov]

On Thu, 16 Aug 2018 at 18:40, Paul B Mahol  wrote:

> On 8/16/18, Paul B Mahol  wrote:
> > Hi,
> >
> > another patch attached, please review.
> >
>
> Again.
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>

> + s->prev_frame = av_frame_alloc();
> + if (!s->prev_frame)
> + return AVERROR(ENOMEM);

No need to allocate anything. A reference to a frame is a pointer.


> + av_frame_free(&s->prev_frame);
Replace with av_frame_unref(s->prev_frame);


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

Re: [FFmpeg-devel] [PATCH] avcodec: add IMM4 decoder

[Rostislav Pehlivanov]

On Thu, 16 Aug 2018 at 21:19, Rostislav Pehlivanov 
wrote:

>
>
> On Thu, 16 Aug 2018 at 18:40, Paul B Mahol  wrote:
>
>> On 8/16/18, Paul B Mahol  wrote:
>> > Hi,
>> >
>> > another patch attached, please review.
>> >
>>
>> Again.
>> ___
>> ffmpeg-devel mailing list
>> ffmpeg-devel@ffmpeg.org
>> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>>
>
> > + s->prev_frame = av_frame_alloc();
> > + if (!s->prev_frame)
> > + return AVERROR(ENOMEM);
>
> No need to allocate anything. A reference to a frame is a pointer.
>
>
> > + av_frame_free(&s->prev_frame);
> Replace with av_frame_unref(s->prev_frame);
>
>
> Otherwise looks fine.
>

Also the decoder doesn't handle seeking correctly. You need an
AVCodec->flush() function to unref s->prev_frame and a parser too to
determine keyframes.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 6/7] libavfilter/vf_sr.c: Removes uint8 -> float and float -> uint8 conversions.

[Rostislav Pehlivanov]

On Thu, 2 Aug 2018 at 20:00, Sergey Lavrushkin  wrote:

> This patch removes conversions, declared inside the sr filter, and uses
> libswscale inside
> the filter to perform them for only Y channel of input. The sr filter
> still has uint
> formats as input, as it does not use chroma channels in models and these
> channels are
> upscaled using libswscale, float formats for input would cause unnecessary
> conversions
> during scaling for these channels.
>
> ---
>  libavfilter/vf_sr.c | 134
> +++-
>  1 file changed, 48 insertions(+), 86 deletions(-)
>
> diff --git a/libavfilter/vf_sr.c b/libavfilter/vf_sr.c
> index 944a0e28e7..5ad1baa4c0 100644
> --- a/libavfilter/vf_sr.c
> +++ b/libavfilter/vf_sr.c
> @@ -45,8 +45,8 @@ typedef struct SRContext {
>  DNNModel *model;
>  DNNData input, output;
>  int scale_factor;
> -struct SwsContext *sws_context;
> -int sws_slice_h;
> +struct SwsContext *sws_contexts[3];
> +int sws_slice_h, sws_input_linesize, sws_output_linesize;
>  } SRContext;
>
>  #define OFFSET(x) offsetof(SRContext, x)
> @@ -95,6 +95,10 @@ static av_cold int init(AVFilterContext *context)
>  return AVERROR(EIO);
>  }
>
> +sr_context->sws_contexts[0] = NULL;
> +sr_context->sws_contexts[1] = NULL;
> +sr_context->sws_contexts[2] = NULL;
> +
>  return 0;
>  }
>
> @@ -110,6 +114,7 @@ static int query_formats(AVFilterContext *context)
>  av_log(context, AV_LOG_ERROR, "could not create formats list\n");
>  return AVERROR(ENOMEM);
>  }
> +
>  return ff_set_common_formats(context, formats_list);
>  }
>
> @@ -140,21 +145,31 @@ static int config_props(AVFilterLink *inlink)
>  else{
>  outlink->h = sr_context->output.height;
>  outlink->w = sr_context->output.width;
> +sr_context->sws_contexts[1] =
> sws_getContext(sr_context->input.width, sr_context->input.height,
> AV_PIX_FMT_GRAY8,
> +
>  sr_context->input.width, sr_context->input.height, AV_PIX_FMT_GRAYF32,
> + 0, NULL, NULL, NULL);
> +sr_context->sws_input_linesize = sr_context->input.width << 2;
> +sr_context->sws_contexts[2] =
> sws_getContext(sr_context->output.width, sr_context->output.height,
> AV_PIX_FMT_GRAYF32,
> +
>  sr_context->output.width, sr_context->output.height, AV_PIX_FMT_GRAY8,
> + 0, NULL, NULL, NULL);
> +sr_context->sws_output_linesize = sr_context->output.width << 2;
> +if (!sr_context->sws_contexts[1] || !sr_context->sws_contexts[2]){
> +av_log(context, AV_LOG_ERROR, "could not create SwsContext
> for conversions\n");
> +return AVERROR(ENOMEM);
> +}
>  switch (sr_context->model_type){
>  case SRCNN:
> -sr_context->sws_context = sws_getContext(inlink->w,
> inlink->h, inlink->format,
> - outlink->w,
> outlink->h, outlink->format, SWS_BICUBIC, NULL, NULL, NULL);
> -if (!sr_context->sws_context){
> -av_log(context, AV_LOG_ERROR, "could not create
> SwsContext\n");
> +sr_context->sws_contexts[0] = sws_getContext(inlink->w,
> inlink->h, inlink->format,
> + outlink->w,
> outlink->h, outlink->format,
> + SWS_BICUBIC,
> NULL, NULL, NULL);
> +if (!sr_context->sws_contexts[0]){
> +av_log(context, AV_LOG_ERROR, "could not create
> SwsContext for scaling\n");
>  return AVERROR(ENOMEM);
>  }
>  sr_context->sws_slice_h = inlink->h;
>  break;
>  case ESPCN:
> -if (inlink->format == AV_PIX_FMT_GRAY8){
> -sr_context->sws_context = NULL;
> -}
> -else{
> +if (inlink->format != AV_PIX_FMT_GRAY8){
>  sws_src_h = sr_context->input.height;
>  sws_src_w = sr_context->input.width;
>  sws_dst_h = sr_context->output.height;
> @@ -184,13 +199,14 @@ static int config_props(AVFilterLink *inlink)
>  sws_dst_w = AV_CEIL_RSHIFT(sws_dst_w, 2);
>  break;
>  default:
> -av_log(context, AV_LOG_ERROR, "could not create
> SwsContext for input pixel format");
> +av_log(context, AV_LOG_ERROR, "could not create
> SwsContext for scaling for given input pixel format");
>  return AVERROR(EIO);
>  }
> -sr_context->sws_context = sws_getContext(sws_src_w,
> sws_src_h, AV_PIX_FMT_GRAY8,
> - sws_dst_w,
> sws_dst_h, AV_PIX_FMT_GRAY8, SWS_BICUBIC, NULL, NULL, NULL);
> -if (!sr_context->sws_context){
> -av_log(cont

Re: [FFmpeg-devel] [PATCH 7/7] libavfilter: Adds proper file descriptions to dnn_srcnn.h and dnn_espcn.h.

[Rostislav Pehlivanov]

On Thu, 2 Aug 2018 at 19:54, Sergey Lavrushkin  wrote:

> ---
>  libavfilter/dnn_espcn.h | 3 ++-
>  libavfilter/dnn_srcnn.h | 3 ++-
>  2 files changed, 4 insertions(+), 2 deletions(-)
>
> diff --git a/libavfilter/dnn_espcn.h b/libavfilter/dnn_espcn.h
> index 9344aa90fe..e0013fe1dd 100644
> --- a/libavfilter/dnn_espcn.h
> +++ b/libavfilter/dnn_espcn.h
> @@ -20,7 +20,8 @@
>
>  /**
>   * @file
> - * Default cnn weights for x2 upscaling with espcn model.
> + * This file contains CNN weights for ESPCN model (
> https://arxiv.org/abs/1609.05158),
> + * auto generated by scripts provided in the repository:
> https://github.com/HighVoltageRocknRoll/sr.git.
>   */
>
>  #ifndef AVFILTER_DNN_ESPCN_H
> diff --git a/libavfilter/dnn_srcnn.h b/libavfilter/dnn_srcnn.h
> index 4f5332ce18..8bf563bd62 100644
> --- a/libavfilter/dnn_srcnn.h
> +++ b/libavfilter/dnn_srcnn.h
> @@ -20,7 +20,8 @@
>
>  /**
>   * @file
> - * Default cnn weights for x2 upscaling with srcnn model.
> + * This file contains CNN weights for SRCNN model (
> https://arxiv.org/abs/1501.00092),
> + * auto generated by scripts provided in the repository:
> https://github.com/HighVoltageRocknRoll/sr.git.
>   */
>
>  #ifndef AVFILTER_DNN_SRCNN_H
> --
> 2.14.1
>
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>

Soo, when are you going to remove *all* the models from lavfi?
All need to be removed before we make a release.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 4/7] Adds gray floating-point pixel formats.

[Rostislav Pehlivanov]

On Sat, 11 Aug 2018 at 23:31, Sergey Lavrushkin  wrote:

> 2018-08-12 0:45 GMT+03:00 Michael Niedermayer :
>
> > On Sat, Aug 11, 2018 at 05:52:32PM +0300, Sergey Lavrushkin wrote:
> > > 2018-08-10 20:24 GMT+03:00 Michael Niedermayer  >:
> > >
> > > > On Thu, Aug 09, 2018 at 08:15:16PM +0300, Sergey Lavrushkin wrote:
> > > > > Here are updated patches with fixes. I updated conversion
> functions,
> > so
> > > > > they should
> > > > > properly work with format for different endianness.
> > > > [...]
> > > > > diff --git a/libswscale/input.c b/libswscale/input.c
> > > > > index 3fd3a5d81e..0e016d387f 100644
> > > > > --- a/libswscale/input.c
> > > > > +++ b/libswscale/input.c
> > > > > @@ -942,6 +942,30 @@ static av_always_inline void
> > > > planar_rgb16_to_uv(uint8_t *_dstU, uint8_t *_dstV,
> > > > >  }
> > > > >  #undef rdpx
> > > > >
> > > > > +static av_always_inline void grayf32ToY16_c(uint8_t *_dst, const
> > > > uint8_t *_src, const uint8_t *unused1,
> > > > > +const uint8_t
> *unused2,
> > int
> > > > width, uint32_t *unused)
> > > > > +{
> > > > > +int i;
> > > > > +const float *src = (const float *)_src;
> > > > > +uint16_t *dst= (uint16_t *)_dst;
> > > > > +
> > > > > +for (i = 0; i < width; ++i){
> > > > > +dst[i] = lrintf(65535.0f * FFMIN(FFMAX(src[i], 0.0f),
> > 1.0f));
> > > > > +}
> > > > > +}
> > > >
> > > > is it faster to clip the float before lrintf() than the integer
> > afterwards
> > > > ?
> > > >
> > >
> > > Clipping integers is faster, switched to it.
> > >
> > >
> > > > [...]
> > > > > diff --git a/libswscale/output.c b/libswscale/output.c
> > > > > index 0af2fffea4..cd408fb285 100644
> > > > > --- a/libswscale/output.c
> > > > > +++ b/libswscale/output.c
> > > > > @@ -208,6 +208,121 @@ static void yuv2p016cX_c(SwsContext *c, const
> > > > int16_t *chrFilter, int chrFilterS
> > > > >  }
> > > > >  }
> > > > >
> > > > > +static av_always_inline void
> > > > > +yuv2plane1_float_c_template(const int32_t *src, float *dest, int
> > dstW)
> > > > > +{
> > > > > +#if HAVE_BIGENDIAN
> > > > > +static const int big_endian = 1;
> > > > > +#else
> > > > > +static const int big_endian = 0;
> > > > > +#endif
> > > >
> > > > you can use HAVE_BIGENDIAN in place of big_endian
> > > > its either 0 or 1 already
> > > > or static const int big_endian = HAVE_BIGENDIAN
> > > >
> > >
> > > Ok.
> > >
> > > Here is updated patch.
> >
> > >  libswscale/input.c   |   38 +++
> > >  libswscale/output.c  |  105
> > +++
> > >  libswscale/ppc/swscale_altivec.c |1
> > >  libswscale/swscale_internal.h|9 ++
> > >  libswscale/swscale_unscaled.c|   54 +++
> > >  libswscale/utils.c   |   20 +
> > >  libswscale/x86/swscale_template.c|3
> > >  tests/ref/fate/filter-pixdesc-grayf32be  |1
> > >  tests/ref/fate/filter-pixdesc-grayf32le  |1
> > >  tests/ref/fate/filter-pixfmts-copy   |2
> > >  tests/ref/fate/filter-pixfmts-crop   |2
> > >  tests/ref/fate/filter-pixfmts-field  |2
> > >  tests/ref/fate/filter-pixfmts-fieldorder |2
> > >  tests/ref/fate/filter-pixfmts-hflip  |2
> > >  tests/ref/fate/filter-pixfmts-il |2
> > >  tests/ref/fate/filter-pixfmts-null   |2
> > >  tests/ref/fate/filter-pixfmts-scale  |2
> > >  tests/ref/fate/filter-pixfmts-transpose  |2
> > >  tests/ref/fate/filter-pixfmts-vflip  |2
> > >  19 files changed, 248 insertions(+), 4 deletions(-)
> > > db401051d0e42132f7ce76cb78de584951be704b  0005-libswscale-Adds-
> > conversions-from-to-float-gray-forma.patch
> > > From cf523bcb50537abbf6daf0eb799341d8b706d366 Mon Sep 17 00:00:00 2001
> > > From: Sergey Lavrushkin 
> > > Date: Fri, 3 Aug 2018 18:06:50 +0300
> > > Subject: [PATCH 5/9] libswscale: Adds conversions from/to float gray
> > format.
> > >
> > > ---
> > >  libswscale/input.c   |  38 +++
> > >  libswscale/output.c  | 105
> > +++
> > >  libswscale/ppc/swscale_altivec.c |   1 +
> > >  libswscale/swscale_internal.h|   9 +++
> > >  libswscale/swscale_unscaled.c|  54 +++-
> > >  libswscale/utils.c   |  20 +-
> > >  libswscale/x86/swscale_template.c|   3 +-
> > >  tests/ref/fate/filter-pixdesc-grayf32be  |   1 +
> > >  tests/ref/fate/filter-pixdesc-grayf32le  |   1 +
> > >  tests/ref/fate/filter-pixfmts-copy   |   2 +
> > >  tests/ref/fate/filter-pixfmts-crop   |   2 +
> > >  tests/ref/fate/filter-pixfmts-field  |   2 +
> > >  tests/ref/fate/filter-pixfmts-fieldorder |   2 +
> > >  tests/ref/fate/filter-pixfmts-hflip  |   2 +
> > >  tests/ref/fate/filter-pixfmts-il |   2 +
> > >  tests/ref/fate/filter-pixfmts-null   |   2 +
> > >  tests/ref/fate/f

Re: [FFmpeg-devel] [WIP][RFC][PATCH] avcodec: add IMM4 decoder

[Rostislav Pehlivanov]

On Sat, 11 Aug 2018 at 13:24, Paul B Mahol  wrote:

> Hi,
>
> Much improved and cleaned up version attached.
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel


> +INIT_VLC_SPARSE_STATIC(&cbplo_tab, 9, FF_ARRAY_ELEMS(cbplo_bits),
> +   cbplo_bits, 1, 1, cbplo_codes, 1, 1, 
> cbplo_symbols, 1, 1, 512);
> +
> +INIT_VLC_SPARSE_STATIC(&cbphi_tab, 6, FF_ARRAY_ELEMS(cbphi_bits),
> +   cbphi_bits, 1, 1, cbphi_codes, 1, 1, NULL, 0, 0, 
> 64);
> +
> +INIT_VLC_SPARSE_STATIC(&blktype_tab, 9, FF_ARRAY_ELEMS(blktype_bits),
> +   blktype_bits, 1, 1, blktype_codes, 1, 1, 
> blktype_symbols, 1, 1, 512);
> +
> +INIT_VLC_SPARSE_STATIC(&block_tab, 12, FF_ARRAY_ELEMS(block_bits),
> +   block_bits, 1, 1, block_codes, 1, 1, 
> block_symbols, 2, 2, 4096);

Don't you need to wrap this in a separate init function and call it
from ff_thread_once()? I'd prefer if you just put cbplo_tab inside the
main context, but I don't mind them being global.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 1/7] libavfilter: Adds on the fly generation of default DNN models for tensorflow backend instead of storing binary model.

[Rostislav Pehlivanov]

On 7 August 2018 at 17:32, Pedro Arthur  wrote:

> 2018-08-06 18:09 GMT-03:00 Sergey Lavrushkin :
> > Changed sprintf to snprintf.
> Patch pushed.
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>

Why are the weights changed? Sure, some have been removed, in fact a lot,
but at the end we agreed that there should be absolutely no binary weights
left in lavf, and everything should be loadable on runtime.
Is this going to be implemented with a later patchset?
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] avcodec/libopusenc: allow encoding channel mapping 2

[Rostislav Pehlivanov]

On 27 July 2018 at 20:44, Felicia Lim  wrote:

> ---
>  libavcodec/libopusenc.c | 22 ++
>  1 file changed, 22 insertions(+)
>
> diff --git a/libavcodec/libopusenc.c b/libavcodec/libopusenc.c
> index 4ae81b0bb2..6b450ec317 100644
> --- a/libavcodec/libopusenc.c
> +++ b/libavcodec/libopusenc.c
> @@ -27,6 +27,7 @@
>  #include "bytestream.h"
>  #include "internal.h"
>  #include "libopus.h"
> +#include "mathops.h"
>  #include "vorbis.h"
>  #include "audio_frame_queue.h"
>
> @@ -200,6 +201,21 @@ static int libopus_check_vorbis_layout(AVCodecContext
> *avctx, int mapping_family
>  return 0;
>  }
>
> +static int libopus_check_ambisonics_channels(AVCodecContext *avctx) {
> +int channels = avctx->channels;
> +int ambisonic_order = ff_sqrt(channels) - 1;
> +if (channels != ((ambisonic_order + 1) * (ambisonic_order + 1)) &&
> +channels != ((ambisonic_order + 1) * (ambisonic_order + 1) + 2)) {
> +av_log(avctx, AV_LOG_ERROR,
> +   "Ambisonics coding is only specified for channel counts"
> +   " which can be written as (n + 1)^2 or (n + 1)^2 + 2"
> +   " for nonnegative integer n\n");
> +return AVERROR_INVALIDDATA;
> +}
> +
> +return 0;
> +}
> +
>  static int libopus_validate_layout_and_get_channel_map(
>  AVCodecContext *avctx,
>  int mapping_family,
> @@ -231,6 +247,12 @@ static int libopus_validate_layout_and_
> get_channel_map(
>  channel_map = ff_vorbis_channel_layout_offsets[avctx->channels
> - 1];
>  }
>  break;
> +case 2:
> +ret = libopus_check_max_channels(avctx, 227);
> +if (ret == 0) {
> +ret = libopus_check_ambisonics_channels(avctx);
> +}
>

No brackets needed, also if (ret) looks better imo.

Does libopus understand channel mapping 2 as ambisonics? What about the
libopus_generic_encoder_() API? Doesn't that need to be used to encode
ambisonics, like the patch by Drew did?
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] libavfilter: temporarily remove DNN framework and vf_sr filter

[Rostislav Pehlivanov]

On 27 July 2018 at 18:12, Rostislav Pehlivanov  wrote:

>
> And the coding style is just the tip, there are dozens of things I
> disagree with, such as the custom float to 8 bit conversions, when filters
> already exist which take in floats (zscale).
>

I should probably expand on what I mean by the custom float conversion:
make the filter accept a float pixel format, such as AV_PIX_FMT_GBRPF32. We
have one, we use it in vf_tonemap and vf_zscale. Users will need to specify
a filter to convert to float first, which will match what they have to do
for vf_zscale and vf_tonemap. If you need to process YUV then add a float
YUV format, but please, don't do custom conversions in filters.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] libavfilter: temporarily remove DNN framework and vf_sr filter

[Rostislav Pehlivanov]

On 27 July 2018 at 17:48, Pedro Arthur  wrote:

> 2018-07-27 12:07 GMT-03:00 Rostislav Pehlivanov :
> > On 27 July 2018 at 15:11, James Almer  wrote:
> >
> >> On 7/27/2018 8:04 AM, Rostislav Pehlivanov wrote:
> >> > Reference - IRC and j-b's earlier email.
> >> > Coding style issues:
> >> > DNNModel* ff_dnn_load_model_native(const char* model_filename)
> >> >
> >> > We never ever do stupid things like put the asterix first. The author
> of
> >> > the patch should have known better and the patch should have been
> >> checked.
> >> > Even a glance could have told you its wrong.
> >>
> >> Tone it down. It's a style issue. New contributors don't always know
> >> things like that and we always tell them to fix it. It's the reviewer
> >> who should have pointed it out, and if they missed it then it's
> >> harmless. It's not like he used a public suffix like av_, where it can
> >> be a problem.
> >>
> >
> > It shows the code wasn't reviewed properly. These style issues are
> > propagated throughout all the DNN framework, which was many thousands of
> > lines of code and shows that not even a glimpse was spent on the actual
> > code. We don't commit such huge patches without at least some form of
> > review, even if months have passed and no one has bothered to yet.
> The style issue is my fault, I did not ensure the student were aware
> of the coding style.
> That does not mean that other aspects of the code were not properly
> reviewed, I spent a good amount of time reviewing and testing the
> code.
>
The code style issue is easily fixable, the student will already
> provide a fix, but if it is too much urgent I could fix it myself in a
> few minutes.
>

Doesn't matter how easy it is to fix, its too late, the code landed, you
pushed it and you didn't even bother to look at it. This is unacceptable,
especially for such a big patchset, and unfair to the rest of developers.
Ping the patchset, and keep pinging it until someone reviews it. Don't make
it your authority to do so especially as its new code for which no
maintainers exist.
And the coding style is just the tip, there are dozens of things I disagree
with, such as the custom float to 8 bit conversions, when filters already
exist which take in floats (zscale).


I don't see how reverting the code and asking for "proper" review,
> which no one (in almost 3 months) besides me did, will do any good.
> After reverting will you be compromised (or anyone else) to review it?
> or the code will get forgotten waiting for review until no one cares
> about it?
>

Yes, I'll review it myself.


It is not fair to propose a patch, and push it within 24h, reverting
> the student work of almost 3 months where no one has complained before
> of issues to be fixed.
>

What isn't fair is that this literal unreviewed code dump is sitting in our
repository at all, without review from any developer, but only with the
reassurance that it compiles and that it mostly does the things it should.
I don't want to keep pointing out issues upon issues with code in our
repository, a nice clean start is what's needed, which means like I said a
temporary revert. I'd rather have that than a tens of patches needed to
actually fix the whole thing, when a few well formatted emails would
suffice.


The code style issue will be addressed.
> We already provide a repo with training scripts, and it will be
> referenced in the code.
>
> Objectively, what else needs to be fixed? let me know and give the
> student at least a few days so he can provide a fix.


Remove the internal tables. All of them.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] libavfilter: temporarily remove DNN framework and vf_sr filter

[Rostislav Pehlivanov]

On 27 July 2018 at 15:11, James Almer  wrote:

> On 7/27/2018 8:04 AM, Rostislav Pehlivanov wrote:
> > Reference - IRC and j-b's earlier email.
> > Coding style issues:
> > DNNModel* ff_dnn_load_model_native(const char* model_filename)
> >
> > We never ever do stupid things like put the asterix first. The author of
> > the patch should have known better and the patch should have been
> checked.
> > Even a glance could have told you its wrong.
>
> Tone it down. It's a style issue. New contributors don't always know
> things like that and we always tell them to fix it. It's the reviewer
> who should have pointed it out, and if they missed it then it's
> harmless. It's not like he used a public suffix like av_, where it can
> be a problem.
>

It shows the code wasn't reviewed properly. These style issues are
propagated throughout all the DNN framework, which was many thousands of
lines of code and shows that not even a glimpse was spent on the actual
code. We don't commit such huge patches without at least some form of
review, even if months have passed and no one has bothered to yet.



>
> > I described them in the sentence above.
> > But I'm not willing to wait for a potential fix, and especially not for a
> > whole bunch of them rewriting everything. The whole code needs to be
> thrown
> > out and thoroughly reviewed properly, by at least yourself and one other
> > person, preferably before gsoc ends.
> > You should start coordinating with your student on how to fix everything
> > mentioned and then resend the patchsets once fixed. I'll apply the revert
> > patch tomorrow.
>
> No, you wont. Not until this has been discussed.


Yes I will, unless someone objects I still intend to. No one has yet.


I don't know what got
> to you but you're acting like someone pushed code that would get a cop
> on your doorstep. Calm down for once in your life, you're seemingly
> angry in every other email you write, and you're not helping making this
> project a friendly place at all for new and old contributors alike.
>

I didn't intend to sound such but nevertheless the facts I mentioned
remain, and I can't really think of a way to present them better.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 1/3] diracdec: add 10-bit Haar SIMD functions

[Rostislav Pehlivanov]

On 27 July 2018 at 12:47, James Darnley  wrote:

> On 2018-07-26 17:29, Rostislav Pehlivanov wrote:
> > On 26 July 2018 at 12:28, James Darnley  wrote:
> > +cglobal vertical_compose_haar_10bit, 3, 6, 4, b0, b1, w
> >> +DECLARE_REG_TMP 4,5
> >> +
> >> +mova  m2, [pd_1]
> >> +mov  r3d, wd
> >> +and   wd, ~(mmsize/4 - 1)
> >> +shl   wd, 2
> >> +add  b0q, wq
> >> +add  b1q, wq
> >> +neg   wq
> >> +
> >> +ALIGN 16
> >> +.loop_simd:
> >> +mova m0, [b0q + wq]
> >> +mova m1, [b1q + wq]
> >> +paddd m3, m1, m2
> >> +psrad m3, 1
> >> +psubd m0, m3
> >> +paddd m1, m0
> >> +mova [b0q + wq], m0
> >> +mova [b1q + wq], m1
> >> +add wq, mmsize
> >> +jl .loop_simd
> >> +
> >> +and  r3d, mmsize/4 - 1
> >> +jz .end
> >> +.loop_scalar:
> >> +mov t0d, [b0q]
> >> +mov t1d, [b1q]
> >> +mov r2d, t1d
> >> +add r2d, 1
> >> +sar r2d, 1
> >> +sub t0d, r2d
> >> +add t1d, t0d
> >> +mov [b0q], t0d
> >> +mov [b1q], t1d
> >> +
> >> +add b0q, 4
> >> +add b1q, 4
> >> +sub r3d, 1
> >> +jg .loop_scalar
> >> +
> >> +.end:
> >> +RET
> >> +
> >> +%endmacro
> >> +
> >> +%macro HAAR_HORIZONTAL 0
> >>
> > +
> >>
> >
> > Could you remove this newline from every patch? All asm I've written and
> > seen keep them without a newline. It made me think there's something in
> the
> > asm which checked the value of the macro, not that the entire function is
> > macro'd.
>
> What?  I don't understand what you mean.  Do you think I have too many
> blank lines between things?
>

Just remove the newline between the macro definition and the cglobal.


> +cglobal horizontal_compose_haar_10bit, 3, 6+ARCH_X86_64, 4, b, temp_, w,
> >> x, b2
> >> +DECLARE_REG_TMP 2,5
> >> +%if ARCH_X86_64
> >> +%define tail r6d
> >> +%else
> >> +%define tail dword wm
> >> +%endif
> >> +
> >> +mova m2, [pd_1]
> >> +xor xd, xd
> >> +shr wd, 1
> >> +mov tail, wd
> >> +lea b2q, [bq + 4*wq]
> >> +
> >> +ALIGN 16
> >> +.loop_lo:
> >> +mova m0, [bq  + 4*xq]
> >> +movu m1, [b2q + 4*xq]
> >> +paddd m1, m2
> >> +psrad m1, 1
> >> +psubd m0, m1
> >> +mova [temp_q + 4*xq], m0
> >> +add xd, mmsize/4
> >> +cmp xd, wd
> >> +jl .loop_lo
> >> +
> >> +xor xd, xd
> >> +and wd, ~(mmsize/4 - 1)
> >> +
> >> +ALIGN 16
> >> +.loop_hi:
> >> +mova m0, [temp_q + 4*xq]
> >> +movu m1, [b2q+ 4*xq]
> >> +paddd m1, m0
> >> +paddd m0, m2
> >> +paddd m1, m2
> >> +psrad m0, 1
> >> +psrad m1, 1
> >> +SBUTTERFLY dq, 0,1,3
> >> +%if cpuflag(avx2)
> >> +SBUTTERFLY dqqq, 0,1,3
> >> +%endif
> >> +mova [bq + 8*xq], m0
> >> +mova [bq + 8*xq + mmsize], m1
> >> +add xd, mmsize/4
> >> +cmp xd, wd
> >> +jl .loop_hi
> >> +
> >> +and tail, mmsize/4 - 1
> >> +jz .end
> >> +.loop_scalar:
> >> +mov t0d, [temp_q + 4*xq]
> >> +mov t1d, [b2q+ 4*xq]
> >> +add t1d, t0d
> >> +add t0d, 1
> >> +add t1d, 1
> >> +sar t0d, 1
> >> +sar t1d, 1
> >> +mov [bq + 8*xq], t0d
> >> +mov [bq + 8*xq + 4], t1d
> >> +add  xq, 1
> >> +sub tail, 1
> >> +jg .loop_scalar
> >> +
> >> +.end:
> >> +REP_RET
> >> +
> >> +%endmacro
> >> +
> >> +INIT_XMM sse2
> >> +HAAR_HORIZONTAL
> >> +HAAR_VERTICAL
> >> +
> >> +INIT_XMM avx
> >> +HAAR_HORIZONTAL
> >> +HAAR_VERTICAL
> >>
> >
> > You're not using any avx functions in that version, not u

Re: [FFmpeg-devel] [PATCH] libavfilter: temporarily remove DNN framework and vf_sr filter

[Rostislav Pehlivanov]

On 27 July 2018 at 03:04, Pedro Arthur  wrote:

> Hi,
>
> I'm surprised with this patch, there wasn't any concern raised in the
> patch review process.
>

It slipped through, and we (and you) should have known better.



> 2018-07-26 16:26 GMT-03:00 Rostislav Pehlivanov :
> > As discussed recently, the vf_sr filter and the DNN framework have an
> > issue: unreproducable weights and questionable license, as well as
> > overall unfitting coding style to the rest of the project.
> I think I'm not aware of these discussions could you provide a
> reference? I also don't understand why the coding style is unfitting
> (again no concern was raised).
>

Reference - IRC and j-b's earlier email.
Coding style issues:
DNNModel* ff_dnn_load_model_native(const char* model_filename)

We never ever do stupid things like put the asterix first. The author of
the patch should have known better and the patch should have been checked.
Even a glance could have told you its wrong.


>
> > The vf_sr filter in particular has weights embedded which weight the
> > libavfilter binary by a bit and cannot currently be reproduced.
> > There's an overall consensus that NN filters should accept external
> > weights only, as the nnedi filter currently does.
> >
> > So, temporarily remove both until the coding style issues have been
> > fixed with the framework and the filter has been modified to accept
> > external weights.
> What are these issues so we can fix them?
>

I described them in the sentence above.
But I'm not willing to wait for a potential fix, and especially not for a
whole bunch of them rewriting everything. The whole code needs to be thrown
out and thoroughly reviewed properly, by at least yourself and one other
person, preferably before gsoc ends.
You should start coordinating with your student on how to fix everything
mentioned and then resend the patchsets once fixed. I'll apply the revert
patch tomorrow.


>
> > Also, there's a discussion by the Debian folks as to whether to treat
> > pretrained NNs as non-free[0], hence its not just our project that's
> > affected by the questionable license of distributing pretrained NN
> > weights.
> >
> > Due to the weight of the patch (more than 1mb!) I've uploaded it to
> > https://0x0.st/sVEH.patch if anyone wants to test it. The change stat
> > is printed below.
> >
> > [0]: https://lwn.net/Articles/760142/
> I took the time to read the whole discussion and in my opinion it is
> flawed, except for the storage requirement, which Sergey already
> worked on a patch to reduce the stored data.
>
>
> I think before any discussion, it should be clear what is the ffmpeg
> policy on adding data, and what is considered data, and it should be
> consistent.
>
> I'll try to address the topics in the above discussion.
>
> First what is data? is it expected that all data stored should be
> easily reproducible?
>

Easily? No. Always? Absolutely.


I guess not, what is the point in storing data that is easily reproducible?
>

We do it for speed reasons. Large tables take time to generate on startup.


The entire humanity is built on previous stored knowledge, namely
> data, do we require each time one is going to use some form of
> knowledge to reproduce it? that is, proof everything one is using?
> The answer is no, the whole point in storing data is that you had once
> worked hard to proof it works and onwards just use it and believe it
> works. That does not mean it is imposible to proof everything.
>
> I think the above fits perfectly with NN weights as data.
>
> The next point is the reproducibility, one should be reasonable, it is
> hard to reproduce bit by bit of NN stored data but is totally doable
> to achieve similar results following the same training metodology
> used.
>

Very well, provide code and references to sources to reproduce please.



> Then there is the question what is open-source, once again one should
> be reasonable.
> The NN model is public available, everything is documented, the math
> machinery is also widely available and documented.
> There is also a repository containing everything one needs to train
> the NN and achieve similar results, the trainig data is public also.
> The training software is open-source, the user could also use any
> machine learning framework of their choice to perform the training
> since the model is documented, there is nothing locking one to a
> specific software or hardware.
> I can't see what is not open.
>

The process to replicate the weights. Provide script(s) and references to
sources.


Does we impose all requiriments imposed for NN weights on all other
> data stored in ffmpeg?

[FFmpeg-devel] [PATCH] libavfilter: temporarily remove DNN framework and vf_sr filter

[Rostislav Pehlivanov]

As discussed recently, the vf_sr filter and the DNN framework have an
issue: unreproducable weights and questionable license, as well as
overall unfitting coding style to the rest of the project.

The vf_sr filter in particular has weights embedded which weight the
libavfilter binary by a bit and cannot currently be reproduced.
There's an overall consensus that NN filters should accept external
weights only, as the nnedi filter currently does.

So, temporarily remove both until the coding style issues have been
fixed with the framework and the filter has been modified to accept
external weights.

Also, there's a discussion by the Debian folks as to whether to treat
pretrained NNs as non-free[0], hence its not just our project that's
affected by the questionable license of distributing pretrained NN
weights.

Due to the weight of the patch (more than 1mb!) I've uploaded it to
https://0x0.st/sVEH.patch if anyone wants to test it. The change stat
is printed below.

[0]: https://lwn.net/Articles/760142/

Signed-off-by: Rostislav Pehlivanov 

Rostislav Pehlivanov (1):
  libavfilter: temporarily remove DNN framework and vf_sr filter

 Changelog| 1 -
 configure| 8 -
 libavfilter/Makefile | 3 -
 libavfilter/allfilters.c | 1 -
 libavfilter/dnn_backend_native.c |   495 --
 libavfilter/dnn_backend_native.h |40 -
 libavfilter/dnn_backend_tf.c |   325 -
 libavfilter/dnn_backend_tf.h |40 -
 libavfilter/dnn_espcn.h  | 12637 -
 libavfilter/dnn_interface.c  |60 -
 libavfilter/dnn_interface.h  |63 -
 libavfilter/dnn_srcnn.h  |  4957 ---
 libavfilter/vf_sr.c  |   354 -
 13 files changed, 18984 deletions(-)
 delete mode 100644 libavfilter/dnn_backend_native.c
 delete mode 100644 libavfilter/dnn_backend_native.h
 delete mode 100644 libavfilter/dnn_backend_tf.c
 delete mode 100644 libavfilter/dnn_backend_tf.h
 delete mode 100644 libavfilter/dnn_espcn.h
 delete mode 100644 libavfilter/dnn_interface.c
 delete mode 100644 libavfilter/dnn_interface.h
 delete mode 100644 libavfilter/dnn_srcnn.h
 delete mode 100644 libavfilter/vf_sr.c

-- 
2.18.0

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

Re: [FFmpeg-devel] [PATCH 1/3] diracdec: add 10-bit Haar SIMD functions

[Rostislav Pehlivanov]

On 26 July 2018 at 12:28, James Darnley  wrote:

> +
> +%macro HAAR_HORIZONTAL 0
> +
> +cglobal horizontal_compose_haar_10bit, 3, 6+ARCH_X86_64, 4, b, temp_, w,
> x, b2
> +DECLARE_REG_TMP 2,5
> +%if ARCH_X86_64
> +%define tail r6d
> +%else
> +%define tail dword wm
> +%endif
> +
>

You can remove this whole bit, the init function only gets called if
ARCH_X86_64 is true.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 1/3] diracdec: add 10-bit Haar SIMD functions

[Rostislav Pehlivanov]

On 26 July 2018 at 12:28, James Darnley  wrote:

> Speed of ffmpeg when decoding a 720p yuv422p10 file encoded with the
> relevant transform.
> C:119fps
> SSE2: 204fps
> AVX:  206fps
> AVX2: 221fps
>
> timer measurements, haar horizontal compose:
> sse2: 3.68x faster (45143 vs. 12279 decicycles) compared with C
> avx:  3.68x faster (45143 vs. 12275 decicycles) compared with C
> avx2: 5.16x faster (45143 vs.  8742 decicycles) compared with C
> haar vertical compose:
> sse2: 1.64x faster (31792 vs. 19377 decicycles) compared with C
> avx:  1.58x faster (31792 vs. 20090 decicycles) compared with C
> avx2: 1.66x faster (31792 vs. 19157 decicycles) compared with C
> ---
>  libavcodec/dirac_dwt.c|   7 +-
>  libavcodec/dirac_dwt.h|   1 +
>  libavcodec/x86/Makefile   |   6 +-
>  libavcodec/x86/dirac_dwt_10bit.asm| 160 ++
>  libavcodec/x86/dirac_dwt_init_10bit.c |  76 
>  5 files changed, 247 insertions(+), 3 deletions(-)
>  create mode 100644 libavcodec/x86/dirac_dwt_10bit.asm
>  create mode 100644 libavcodec/x86/dirac_dwt_init_10bit.c
>
> diff --git a/libavcodec/dirac_dwt.c b/libavcodec/dirac_dwt.c
> index cc08f8865a..86bee5bb9b 100644
> --- a/libavcodec/dirac_dwt.c
> +++ b/libavcodec/dirac_dwt.c
> @@ -59,8 +59,13 @@ int ff_spatial_idwt_init(DWTContext *d, DWTPlane *p,
> enum dwt_type type,
>  return AVERROR_INVALIDDATA;
>  }
>
> -if (ARCH_X86 && bit_depth == 8)
> +#if ARCH_X86
> +if (bit_depth == 8)
>  ff_spatial_idwt_init_x86(d, type);
> +else if (bit_depth == 10)
> +ff_spatial_idwt_init_10bit_x86(d, type);
> +#endif
> +
>  return 0;
>  }
>
> diff --git a/libavcodec/dirac_dwt.h b/libavcodec/dirac_dwt.h
> index 994dc21d70..1ad7b9a821 100644
> --- a/libavcodec/dirac_dwt.h
> +++ b/libavcodec/dirac_dwt.h
> @@ -88,6 +88,7 @@ enum dwt_type {
>  int ff_spatial_idwt_init(DWTContext *d, DWTPlane *p, enum dwt_type type,
>   int decomposition_count, int bit_depth);
>  void ff_spatial_idwt_init_x86(DWTContext *d, enum dwt_type type);
> +void ff_spatial_idwt_init_10bit_x86(DWTContext *d, enum dwt_type type);
>
>  void ff_spatial_idwt_slice2(DWTContext *d, int y);
>
> diff --git a/libavcodec/x86/Makefile b/libavcodec/x86/Makefile
> index 2350c8bbee..590d83c167 100644
> --- a/libavcodec/x86/Makefile
> +++ b/libavcodec/x86/Makefile
> @@ -7,7 +7,8 @@ OBJS-$(CONFIG_BLOCKDSP)+=
> x86/blockdsp_init.o
>  OBJS-$(CONFIG_BSWAPDSP)+= x86/bswapdsp_init.o
>  OBJS-$(CONFIG_DCT) += x86/dct_init.o
>  OBJS-$(CONFIG_DIRAC_DECODER)   += x86/diracdsp_init.o   \
> -  x86/dirac_dwt_init.o
> +  x86/dirac_dwt_init.o \
> +  x86/dirac_dwt_init_10bit.o
>  OBJS-$(CONFIG_FDCTDSP) += x86/fdctdsp_init.o
>  OBJS-$(CONFIG_FFT) += x86/fft_init.o
>  OBJS-$(CONFIG_FLACDSP) += x86/flacdsp_init.o
> @@ -153,7 +154,8 @@ X86ASM-OBJS-$(CONFIG_APNG_DECODER) += x86/pngdsp.o
>  X86ASM-OBJS-$(CONFIG_CAVS_DECODER) += x86/cavsidct.o
>  X86ASM-OBJS-$(CONFIG_DCA_DECODER)  += x86/dcadsp.o x86/synth_filter.o
>  X86ASM-OBJS-$(CONFIG_DIRAC_DECODER)+= x86/diracdsp.o\
> -  x86/dirac_dwt.o
> +  x86/dirac_dwt.o \
> +  x86/dirac_dwt_10bit.o
>  X86ASM-OBJS-$(CONFIG_DNXHD_ENCODER)+= x86/dnxhdenc.o
>  X86ASM-OBJS-$(CONFIG_EXR_DECODER)  += x86/exrdsp.o
>  X86ASM-OBJS-$(CONFIG_FLAC_DECODER) += x86/flacdsp.o
> diff --git a/libavcodec/x86/dirac_dwt_10bit.asm
> b/libavcodec/x86/dirac_dwt_10bit.asm
> new file mode 100644
> index 00..baea91329e
> --- /dev/null
> +++ b/libavcodec/x86/dirac_dwt_10bit.asm
> @@ -0,0 +1,160 @@
> +;**
> 
> +;* x86 optimized discrete 10-bit wavelet trasnform
> +;* Copyright (c) 2018 James Darnley
> +;*
> +;* This file is part of FFmpeg.
> +;*
> +;* FFmpeg is free software; you can redistribute it and/or
> +;* modify it under the terms of the GNU Lesser General Public
> +;* License as published by the Free Software Foundation; either
> +;* version 2.1 of the License, or (at your option) any later version.
> +;*
> +;* FFmpeg is distributed in the hope that it will be useful,
> +;* but WITHOUT ANY WARRANTY; without even the implied warranty of
> +;* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
> +;* Lesser General Public License for more details.
> +;*
> +;* You should have received a copy of the GNU Lesser General Public
> +;* License along with FFmpeg; if not, write to the Free Software
> +;* 51, Inc., Foundation Franklin Street, Fifth Floor, Boston, MA
> 02110-1301 USA
> +;*

Re: [FFmpeg-devel] [PATCH] Support for Ambisonics and OpusProjection* API.

[Rostislav Pehlivanov]

Hey,

As of now, the ambisonics API is enabled by default in libopus. We still
don't have a way to signal ambisonics yet.
We still have plenty of bits left in libavutil/channel_layout.h to signal
many orders of ambisonics but some people have had opinions against
extending that API. We could instead extend AVMatrixEncoding but I don't
think that's entirely appropriate.
What opinions do people have on this?
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH v4][GSOC] avfilter: added colorconstancy

[Rostislav Pehlivanov]

On 24 July 2018 at 17:10, Paul B Mahol  wrote:

> On 7/24/18, Rostislav Pehlivanov  wrote:
> > On 23 July 2018 at 21:36, Thilo Borgmann  wrote:
> >
> >> Am 19.07.18 um 08:26 schrieb Thilo Borgmann:
> >> >
> >> >
> >> >> Am 16.07.2018 um 13:41 schrieb Mina :
> >> >>
> >> >> Hi,
> >> >>
> >> >>   This patch introduces Grey-Edge algorithm as part of the Color
> >> Constancy Filter project in GSOC.
> >> >>
> >> >> V4 changes:
> >> >> - Fixed error in filter.texi that resulted in breaking "make
> >> doc/ffprobe-all.html"
> >> >
> >> > If there are no more comments coming in I`ll push this in a couple of
> >> days.
> >>
> >> Applied.
> >>
> >> -Thilo
> >> ___
> >> ffmpeg-devel mailing list
> >> ffmpeg-devel@ffmpeg.org
> >> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> >>
> >
> > What's the point of having an imperfect color conversion filter that
> could
> > screw up compared to a mathematically sound approach?
> > After realizing what this filter does I'm kinda against it and would
> rather
> > we not have an unmaintainable, unused color conversion filter and I think
> > if there's no reasoning behind it I'd like it reverted.
> > ___
> > ffmpeg-devel mailing list
> > ffmpeg-devel@ffmpeg.org
> > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> >
>
> This is not color conversion filter.
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>

Use whatever terminology you'd like, its still not something I'd consider
acceptable. I want to be able to reproduce the results and the NN weights
and I can't.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH v4][GSOC] avfilter: added colorconstancy

[Rostislav Pehlivanov]

On 23 July 2018 at 21:36, Thilo Borgmann  wrote:

> Am 19.07.18 um 08:26 schrieb Thilo Borgmann:
> >
> >
> >> Am 16.07.2018 um 13:41 schrieb Mina :
> >>
> >> Hi,
> >>
> >>   This patch introduces Grey-Edge algorithm as part of the Color
> Constancy Filter project in GSOC.
> >>
> >> V4 changes:
> >> - Fixed error in filter.texi that resulted in breaking "make
> doc/ffprobe-all.html"
> >
> > If there are no more comments coming in I‘ll push this in a couple of
> days.
>
> Applied.
>
> -Thilo
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>

What's the point of having an imperfect color conversion filter that could
screw up compared to a mathematically sound approach?
After realizing what this filter does I'm kinda against it and would rather
we not have an unmaintainable, unused color conversion filter and I think
if there's no reasoning behind it I'd like it reverted.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] avcodec/parser: move parsers list and related API to its own file

[Rostislav Pehlivanov]

On 21 July 2018 at 18:28, James Almer  wrote:

> And add it to the list of configurable components in Makefile, so changes
> to
> the file will be tracked and the usual warning to suggest re-running
> configure
> will be shown.
>
> Signed-off-by: James Almer 
> ---
>  Makefile |   1 +
>  configure|   2 +-
>  libavcodec/Makefile  |   1 +
>  libavcodec/parser.c  |  85 --
>  libavcodec/parsers.c | 106 +++
>  5 files changed, 109 insertions(+), 86 deletions(-)
>  create mode 100644 libavcodec/parsers.c
>
> diff --git a/Makefile b/Makefile
> index 0cd0a1d6f2..4bf1dfedcf 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -58,6 +58,7 @@ tools/target_dec_%_fuzzer$(EXESUF): $(FF_DEP_LIBS)
>  CONFIGURABLE_COMPONENTS =   \
>  $(wildcard $(FFLIBS:%=$(SRC_PATH)/lib%/all*.c)) \
>  $(SRC_PATH)/libavcodec/bitstream_filters.c  \
> +$(SRC_PATH)/libavcodec/parsers.c\
>  $(SRC_PATH)/libavformat/protocols.c \
>
>  config.h: ffbuild/.config
> diff --git a/configure b/configure
> index 534c62ed98..741f56d565 100755
> --- a/configure
> +++ b/configure
> @@ -3679,7 +3679,7 @@ CODEC_LIST="
>  $ENCODER_LIST
>  $DECODER_LIST
>  "
> -PARSER_LIST=$(find_things_extern parser AVCodecParser
> libavcodec/parser.c)
> +PARSER_LIST=$(find_things_extern parser AVCodecParser
> libavcodec/parsers.c)
>  BSF_LIST=$(find_things_extern bsf AVBitStreamFilter
> libavcodec/bitstream_filters.c)
>  HWACCEL_LIST=$(find_things_extern hwaccel AVHWAccel
> libavcodec/hwaccels.h)
>  PROTOCOL_LIST=$(find_things_extern protocol URLProtocol
> libavformat/protocols.c)
> diff --git a/libavcodec/Makefile b/libavcodec/Makefile
> index 2d4bc48dab..e62603f0dd 100644
> --- a/libavcodec/Makefile
> +++ b/libavcodec/Makefile
> @@ -44,6 +44,7 @@ OBJS = ac3_parser.o
>\
> options.o\
> mjpegenc_huffman.o   \
> parser.o \
> +   parsers.o\
> profiles.o   \
> qsv_api.o\
> raw.o\
> diff --git a/libavcodec/parser.c b/libavcodec/parser.c
> index f43b197d5e..0a994a3f30 100644
> --- a/libavcodec/parser.c
> +++ b/libavcodec/parser.c
> @@ -27,95 +27,10 @@
>  #include "libavutil/avassert.h"
>  #include "libavutil/internal.h"
>  #include "libavutil/mem.h"
> -#include "libavutil/thread.h"
>
>  #include "internal.h"
>  #include "parser.h"
>
> -/* Parsers */
> -extern AVCodecParser ff_aac_parser;
> -extern AVCodecParser ff_aac_latm_parser;
> -extern AVCodecParser ff_ac3_parser;
> -extern AVCodecParser ff_adx_parser;
> -extern AVCodecParser ff_bmp_parser;
> -extern AVCodecParser ff_cavsvideo_parser;
> -extern AVCodecParser ff_cook_parser;
> -extern AVCodecParser ff_dca_parser;
> -extern AVCodecParser ff_dirac_parser;
> -extern AVCodecParser ff_dnxhd_parser;
> -extern AVCodecParser ff_dpx_parser;
> -extern AVCodecParser ff_dvaudio_parser;
> -extern AVCodecParser ff_dvbsub_parser;
> -extern AVCodecParser ff_dvdsub_parser;
> -extern AVCodecParser ff_dvd_nav_parser;
> -extern AVCodecParser ff_flac_parser;
> -extern AVCodecParser ff_g729_parser;
> -extern AVCodecParser ff_gsm_parser;
> -extern AVCodecParser ff_h261_parser;
> -extern AVCodecParser ff_h263_parser;
> -extern AVCodecParser ff_h264_parser;
> -extern AVCodecParser ff_hevc_parser;
> -extern AVCodecParser ff_mjpeg_parser;
> -extern AVCodecParser ff_mlp_parser;
> -extern AVCodecParser ff_mpeg4video_parser;
> -extern AVCodecParser ff_mpegaudio_parser;
> -extern AVCodecParser ff_mpegvideo_parser;
> -extern AVCodecParser ff_opus_parser;
> -extern AVCodecParser ff_png_parser;
> -extern AVCodecParser ff_pnm_parser;
> -extern AVCodecParser ff_rv30_parser;
> -extern AVCodecParser ff_rv40_parser;
> -extern AVCodecParser ff_sbc_parser;
> -extern AVCodecParser ff_sipr_parser;
> -extern AVCodecParser ff_tak_parser;
> -extern AVCodecParser ff_vc1_parser;
> -extern AVCodecParser ff_vorbis_parser;
> -extern AVCodecParser ff_vp3_parser;
> -extern AVCodecParser ff_vp8_parser;
> -extern AVCodecParser ff_vp9_parser;
> -extern AVCodecParser ff_xma_parser;
> -
> -#include "libavcodec/parser_list.c"
> -
> -static AVOnce av_parser_next_init = AV_ONCE_INIT;
> -
> -static void av_parser_init_next(void)
> -{
> -AVCodecParser *prev = NULL, *p;
> -int i = 0;
> -while ((p = (AVCodecParser*)parser_list[i++])) {
> -if (prev)
> -prev->next = p;
> -prev = p;
> -}
> -}
> -
> -AVCodecParser *av_parser_next(const AVCodecParser *p)
> -{
> -ff

Re: [FFmpeg-devel] [PATCH 3/6] diracdec: add 10-bit Deslauriers-Dubuc 9, 7 (9_7) vertical high-pass function

[Rostislav Pehlivanov]

On 19 July 2018 at 16:52, James Darnley  wrote:

> On 2018-07-19 17:26, Rostislav Pehlivanov wrote:
> > On 19 July 2018 at 15:52, James Darnley  wrote:
> >
> >> int32_t *b1, int32_t *b2, int
> >>  b1[i] = COMPOSE_DIRAC53iH0(b0[i], b1[i], b2[i]);
> >>  }
> >>
> >> +static void dd97_vertical_hi_sse2(int32_t *b0, int32_t *b1, int32_t
> *b2,
> >> +  int32_t *b3, int32_t *b4, int width)
> >> +{
> >> +int i = width & ~3;
> >> +ff_dd97_vertical_hi_sse2(b0, b1, b2, b3, b4, i);
> >> +for(; i >> +b2[i] = COMPOSE_DD97iH0(b0[i], b1[i], b2[i], b3[i], b4[i]);
> >> +
> >> +}
> >>
> >
> >
> > This, along with the rest of the patchset: what's up with the hybrid
> > implementations? Couldn't you put the second part in the asm code as
> well?
> > Now there are 2 function calls instead of 1.
>
> The 8-bit code does this and I just followed it lead.  I believe this is
> done because we cannot write junk data beyond what we think is the end
> of the line because this might be one of the higher depths and the
> coeffs for the next level sit beyond the end of the line.
>
> But now it has just occurred to me that maybe you meant "why didn't you
> do the scalar operations in SIMD?", is that what you meant?  Answer is
> because it didn't occur to me at the time.  Aside from that I always
> write do-while loops in assembly because I can usually guarantee 1 run
> of the block.
>
> I can certainly look at making that change.
>
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>

Yep, I think you ought to put the scalar code in the asm.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 0/6] x86 SIMD for dirac 10-bit wavelet transforms

[Rostislav Pehlivanov]

On 19 July 2018 at 16:29, James Darnley  wrote:

> On 2018-07-19 17:23, Rostislav Pehlivanov wrote:
> >
> > Could you provide standard overall transform results using
> START/STOP_TIMER
> > rather than overall decoding speed?
> > Coefficients sizes and therefore golomb unpacking speed changes with
> > respect to the transform so potentially there could be somewhat of a
> > bottleneck on decoding before the inverse transform.
>
> Ah, you are right about that.  Should I limit the depth to 1 so that the
> functions operate on the same width all the time?  Anyway, I will get
> the timers in there.
>
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>

Yep, use depth 1 for all transforms and use the biggest slices possible.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 3/6] diracdec: add 10-bit Deslauriers-Dubuc 9, 7 (9_7) vertical high-pass function

[Rostislav Pehlivanov]

On 19 July 2018 at 15:52, James Darnley  wrote:

> Speed of ffmpeg when decoding a 720p yuv422p10 file encoded with the
> relevant transform.
> C: 84fps
> SSE2: 111fps
> AVX2: 115fps
> ---
>  libavcodec/x86/dirac_dwt_10bit.asm| 38 +++
>  libavcodec/x86/dirac_dwt_init_10bit.c | 16 +++
>  2 files changed, 54 insertions(+)
>
> diff --git a/libavcodec/x86/dirac_dwt_10bit.asm
> b/libavcodec/x86/dirac_dwt_10bit.asm
> index c00de32bfe..681de5e1df 100644
> --- a/libavcodec/x86/dirac_dwt_10bit.asm
> +++ b/libavcodec/x86/dirac_dwt_10bit.asm
> @@ -25,6 +25,7 @@ SECTION_RODATA
>
>  cextern pd_1
>  pd_2: times 4 dd 2
> +pd_8: times 4 dd 8
>
>  SECTION .text
>
> @@ -153,7 +154,44 @@ RET
>
>  %endmacro
>
> +%macro DD97_VERTICAL_HI 0
> +
> +cglobal dd97_vertical_hi, 6, 6, 8, b0, b1, b2, b3, b4, w
> +mova m7, [pd_8]
> +shl wd, 2
> +add b0q, wq
> +add b1q, wq
> +add b2q, wq
> +add b3q, wq
> +add b4q, wq
> +neg wq
> +
> +ALIGN 16
> +.loop:
> +mova m0, [b0q + wq]
> +mova m1, [b1q + wq]
> +mova m2, [b2q + wq]
> +mova m3, [b3q + wq]
> +mova m4, [b4q + wq]
> +pslld m5, m1, 3
> +pslld m6, m3, 3
> +paddd m5, m1
> +paddd m6, m3
> +psubd m5, m0
> +psubd m6, m4
> +paddd m5, m7
> +paddd m5, m6
> +psrad m5, 4
> +paddd m2, m5
> +mova [b2q + wq], m2
> +add wq, mmsize
> +jl .loop
> +RET
> +
> +%endmacro
> +
>  INIT_XMM sse2
> +DD97_VERTICAL_HI
>  HAAR_HORIZONTAL
>  HAAR_VERTICAL
>  LEGALL53_VERTICAL_HI
> diff --git a/libavcodec/x86/dirac_dwt_init_10bit.c
> b/libavcodec/x86/dirac_dwt_init_10bit.c
> index 88cf267d14..e7e7534050 100644
> --- a/libavcodec/x86/dirac_dwt_init_10bit.c
> +++ b/libavcodec/x86/dirac_dwt_init_10bit.c
> @@ -23,6 +23,8 @@
>  #include "libavutil/x86/cpu.h"
>  #include "libavcodec/dirac_dwt.h"
>
> +void ff_dd97_vertical_hi_sse2(int32_t *b0, int32_t *b1, int32_t *b2,
> int32_t *b3, int32_t *b4, int width);
> +
>  void ff_legall53_vertical_hi_sse2(int32_t *b0, int32_t *b1, int32_t *b2,
> int width);
>  void ff_legall53_vertical_lo_sse2(int32_t *b0, int32_t *b1, int32_t *b2,
> int width);
>
> @@ -110,6 +112,16 @@ static void legall53_vertical_hi_sse2(int32_t *b0,
> int32_t *b1, int32_t *b2, int
>  b1[i] = COMPOSE_DIRAC53iH0(b0[i], b1[i], b2[i]);
>  }
>
> +static void dd97_vertical_hi_sse2(int32_t *b0, int32_t *b1, int32_t *b2,
> +  int32_t *b3, int32_t *b4, int width)
> +{
> +int i = width & ~3;
> +ff_dd97_vertical_hi_sse2(b0, b1, b2, b3, b4, i);
> +for(; i +b2[i] = COMPOSE_DD97iH0(b0[i], b1[i], b2[i], b3[i], b4[i]);
> +
> +}
>


This, along with the rest of the patchset: what's up with the hybrid
implementations? Couldn't you put the second part in the asm code as well?
Now there are 2 function calls instead of 1.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 0/6] x86 SIMD for dirac 10-bit wavelet transforms

[Rostislav Pehlivanov]

On 19 July 2018 at 15:52, James Darnley  wrote:

> I tested the speed gains by using ffmpeg to decode a 720p yuv422p10 file
> encoded
> with the relevant transform.  The summary is below.
>
> Haar
> C:119fps
> SSE2: 204fps
> AVX:  206fps
> AVX2: 221fps
>
> 5_3
> C: 94fps
> SSE2: 118fps
> AVX2: 121fps
>
> 9_7
> C: 84fps
> SSE2: 111fps
> AVX2: 115fps
>
> Is the AVX worth it in Haar?  Is the AVX2 worth it in the latter two?  I
> added
> those later which is why they are separate patches.  I will squash them
> before
> pushing if I keep them.
>
> James Darnley (6):
>   diracdec: add 10-bit Haar SIMD functions
>   diracdec: add 10-bit Legall 5,3 (5_3) SIMD functions
>   diracdec: add 10-bit Deslauriers-Dubuc 9,7 (9_7) vertical high-pass
> function
>   diracdec: avx2 legall
>   diracdec: avx2 dd97
>   diracdec: increase rodata alignment for avx2
>
>  libavcodec/dirac_dwt.c|   7 +-
>  libavcodec/dirac_dwt.h|   1 +
>  libavcodec/x86/Makefile   |   6 +-
>  libavcodec/x86/dirac_dwt_10bit.asm| 209 +
>  libavcodec/x86/dirac_dwt_init_10bit.c | 210 ++
>  5 files changed, 430 insertions(+), 3 deletions(-)
>  create mode 100644 libavcodec/x86/dirac_dwt_10bit.asm
>  create mode 100644 libavcodec/x86/dirac_dwt_init_10bit.c
>
> --
> 2.17.1
>
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>

Could you provide standard overall transform results using START/STOP_TIMER
rather than overall decoding speed?
Coefficients sizes and therefore golomb unpacking speed changes with
respect to the transform so potentially there could be somewhat of a
bottleneck on decoding before the inverse transform.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 3/3] lavc: implement an ATRAC9 decoder

[Rostislav Pehlivanov]

On 3 July 2018 at 18:28, Carl Eugen Hoyos  wrote:

> 2018-07-03 17:43 GMT+02:00, Rostislav Pehlivanov :
> > On 1 July 2018 at 13:27, Carl Eugen Hoyos  wrote:
> >
> >> 2018-07-01 13:45 GMT+02:00, Rostislav Pehlivanov :
> >>
> >> > Here's the last patch which fixes the lack of timestamps. Seems
> >> > like what's done for atrac3p is enough.
> >>
> >> You should bump some version number for the new feature, I believe
> >> we have always bumped minor for new codecs, you could merge
> >> patches one and three.
> >>
> > I did bump micro but I'll change the bump to minor.
>
> My suggestion was to bump minor when adding the decoder (which
> is the only thing a library user may be interested in) but to simplify,
> just merge 1 and 3.
>
> Carl Eugen
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>

Oh, right.
Pushed after verifying the output of the decoder matches the official
binary decoder, merged 1 and 3 (with a minor bump instead of micro).
Thanks.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 3/3] lavc: implement an ATRAC9 decoder

[Rostislav Pehlivanov]

On 1 July 2018 at 13:27, Carl Eugen Hoyos  wrote:

> 2018-07-01 13:45 GMT+02:00, Rostislav Pehlivanov :
>
> > Here's the last patch which fixes the lack of timestamps. Seems
> > like what's done for atrac3p is enough.
>
> You should bump some version number for the new feature, I believe
> we have always bumped minor for new codecs, you could merge
> patches one and three.
>
> Carl Eugen
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>

I did bump micro but I'll change the bump to minor.
I'll push the latest version of this patchset tonight if there are no
objections. Finding ways to use the binary closed source atrac9 decoder
from sony is challenging so I'll leave out the fate patch for later. I have
enough confidence in the decoder being close to the binary, as the output
from the RE'd decoder matches to what this native encoder outputs.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 1/3] lavc: add ATRAC9 ID and description

[Rostislav Pehlivanov]

On 2 July 2018 at 14:21, Moritz Barsnick  wrote:

> On Sat, Jun 30, 2018 at 08:44:50 +0100, Rostislav Pehlivanov wrote:
> > ---
> >  libavcodec/avcodec.h| 1 +
> >  libavcodec/codec_desc.c | 7 +++
> >  libavcodec/version.h| 2 +-
> >  3 files changed, 9 insertions(+), 1 deletion(-)
> >
> > diff --git a/libavcodec/avcodec.h b/libavcodec/avcodec.h
> > index c90166deb6..f85af3f15d 100644
> > --- a/libavcodec/avcodec.h
> > +++ b/libavcodec/avcodec.h
> > @@ -637,6 +637,7 @@ enum AVCodecID {
> >  AV_CODEC_ID_APTX,
> >  AV_CODEC_ID_APTX_HD,
> >  AV_CODEC_ID_SBC,
> > +AV_CODEC_ID_ATRAC9,
> >
> [...]
>
> Do you need to add a note to doc/APIchanges?
>
> Cheers,
> Moritz
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>

No, in case you haven't noticed we don't advertise new flags there, that
would just spam the list with unimportant for API users entries.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH 2/2] fate: add decoder test for ATRAC9

[Rostislav Pehlivanov]

Signed-off-by: Rostislav Pehlivanov 
---
 tests/fate/atrac.mak | 13 -
 1 file changed, 12 insertions(+), 1 deletion(-)

diff --git a/tests/fate/atrac.mak b/tests/fate/atrac.mak
index acf79a539c..38a5f33150 100644
--- a/tests/fate/atrac.mak
+++ b/tests/fate/atrac.mak
@@ -33,7 +33,17 @@ fate-atrac3p-2: REF = 
$(SAMPLES)/atrac3p/sonateno14op27-2-cut.pcm
 
 FATE_ATRAC3P-$(call DEMDEC, OMA, ATRAC3P) += $(FATE_ATRAC3P)
 
-FATE_ATRAC_ALL = $(FATE_ATRAC1-yes) $(FATE_ATRAC3-yes) $(FATE_ATRAC3P-yes)
+FATE_ATRAC9 += fate-atrac9-1
+fate-atrac9-1: CMD = pcm -i $(TARGET_SAMPLES)/atrac9/sy_title01.at9
+fate-atrac9-1: REF = $(SAMPLES)/atrac9/sy_title01.at9.pcm
+
+FATE_ATRAC9 += fate-atrac9-2
+fate-atrac9-2: CMD = pcm -i 
$(TARGET_SAMPLES)/atrac9/3_br144_nb10_ib10_g04_bex1_sf1_d1.at9
+fate-atrac9-2: REF = 
$(SAMPLES)/atrac9/3_br144_nb10_ib10_g04_bex1_sf1_d1.at9.pcm
+
+FATE_ATRAC9-$(call DEMDEC, OMA, ATRAC9) += $(FATE_ATRAC9)
+
+FATE_ATRAC_ALL = $(FATE_ATRAC1-yes) $(FATE_ATRAC3-yes) $(FATE_ATRAC3P-yes) 
$(FATE_ATRAC9-yes)
 
 $(FATE_ATRAC_ALL): CMP = oneoff
 
@@ -42,3 +52,4 @@ FATE_SAMPLES_AVCONV += $(FATE_ATRAC_ALL)
 fate-atrac:   $(FATE_ATRAC_ALL)
 fate-atrac3:  $(FATE_ATRAC3-yes)
 fate-atrac3p: $(FATE_ATRAC3P-yes)
+fate-atrac9:  $(FATE_ATRAC9-yes)
-- 
2.18.0

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

[FFmpeg-devel] [PATCH 2/3] riff: add ATRAC9 guid

[Rostislav Pehlivanov]

Enables demuxing of ATRAC9 files.
---
 libavformat/riff.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/libavformat/riff.c b/libavformat/riff.c
index 89117250d4..0950415c26 100644
--- a/libavformat/riff.c
+++ b/libavformat/riff.c
@@ -586,6 +586,7 @@ const struct AVCodecTag *avformat_get_riff_audio_tags(void)
 const AVCodecGuid ff_codec_wav_guids[] = {
 { AV_CODEC_ID_AC3,  { 0x2C, 0x80, 0x6D, 0xE0, 0x46, 0xDB, 0xCF, 0x11, 
0xB4, 0xD1, 0x00, 0x80, 0x5F, 0x6C, 0xBB, 0xEA } },
 { AV_CODEC_ID_ATRAC3P,  { 0xBF, 0xAA, 0x23, 0xE9, 0x58, 0xCB, 0x71, 0x44, 
0xA1, 0x19, 0xFF, 0xFA, 0x01, 0xE4, 0xCE, 0x62 } },
+{ AV_CODEC_ID_ATRAC9,   { 0xD2, 0x42, 0xE1, 0x47, 0xBA, 0x36, 0x8D, 0x4D, 
0x88, 0xFC, 0x61, 0x65, 0x4F, 0x8C, 0x83, 0x6C } },
 { AV_CODEC_ID_EAC3, { 0xAF, 0x87, 0xFB, 0xA7, 0x02, 0x2D, 0xFB, 0x42, 
0xA4, 0xD4, 0x05, 0xCD, 0x93, 0x84, 0x3B, 0xDD } },
 { AV_CODEC_ID_MP2,  { 0x2B, 0x80, 0x6D, 0xE0, 0x46, 0xDB, 0xCF, 0x11, 
0xB4, 0xD1, 0x00, 0x80, 0x5F, 0x6C, 0xBB, 0xEA } },
 { AV_CODEC_ID_NONE }
-- 
2.18.0

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

[FFmpeg-devel] [PATCH 1/3] lavc: add ATRAC9 ID and description

[Rostislav Pehlivanov]

---
 libavcodec/avcodec.h| 1 +
 libavcodec/codec_desc.c | 7 +++
 libavcodec/version.h| 2 +-
 3 files changed, 9 insertions(+), 1 deletion(-)

diff --git a/libavcodec/avcodec.h b/libavcodec/avcodec.h
index c90166deb6..f85af3f15d 100644
--- a/libavcodec/avcodec.h
+++ b/libavcodec/avcodec.h
@@ -637,6 +637,7 @@ enum AVCodecID {
 AV_CODEC_ID_APTX,
 AV_CODEC_ID_APTX_HD,
 AV_CODEC_ID_SBC,
+AV_CODEC_ID_ATRAC9,
 
 /* subtitle codecs */
 AV_CODEC_ID_FIRST_SUBTITLE = 0x17000,  ///< A dummy ID pointing at 
the start of subtitle codecs.
diff --git a/libavcodec/codec_desc.c b/libavcodec/codec_desc.c
index 36e9a9bbc7..a126c974e1 100644
--- a/libavcodec/codec_desc.c
+++ b/libavcodec/codec_desc.c
@@ -2878,6 +2878,13 @@ static const AVCodecDescriptor codec_descriptors[] = {
 .long_name = NULL_IF_CONFIG_SMALL("SBC (low-complexity subband 
codec)"),
 .props = AV_CODEC_PROP_LOSSY,
 },
+{
+.id= AV_CODEC_ID_ATRAC9,
+.type  = AVMEDIA_TYPE_AUDIO,
+.name  = "atrac9",
+.long_name = NULL_IF_CONFIG_SMALL("ATRAC9 (Adaptive TRansform Acoustic 
Coding 9)"),
+.props = AV_CODEC_PROP_LOSSY,
+},
 
 /* subtitle codecs */
 {
diff --git a/libavcodec/version.h b/libavcodec/version.h
index 39be9d530e..9f6b0dfe24 100644
--- a/libavcodec/version.h
+++ b/libavcodec/version.h
@@ -29,7 +29,7 @@
 
 #define LIBAVCODEC_VERSION_MAJOR  58
 #define LIBAVCODEC_VERSION_MINOR  20
-#define LIBAVCODEC_VERSION_MICRO 104
+#define LIBAVCODEC_VERSION_MICRO 105
 
 #define LIBAVCODEC_VERSION_INT  AV_VERSION_INT(LIBAVCODEC_VERSION_MAJOR, \
LIBAVCODEC_VERSION_MINOR, \
-- 
2.18.0

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

Re: [FFmpeg-devel] [PATCH 2/6] lavfi: add common Vulkan filtering code

[Rostislav Pehlivanov]

On 22 June 2018 at 15:43, James Almer  wrote:

> On 6/21/2018 1:55 PM, Rostislav Pehlivanov wrote:
> > @@ -3462,12 +3465,12 @@ avcodec_select="null_bsf"
> >  avdevice_deps="avformat avcodec avutil"
> >  avdevice_suggest="libm"
> >  avfilter_deps="avutil"
> > -avfilter_suggest="libm"
> > +avfilter_suggest="libm libshaderc"
> >  avformat_deps="avcodec avutil"
> >  avformat_suggest="libm network zlib"
> >  avresample_deps="avutil"
> >  avresample_suggest="libm"
> > -avutil_suggest="clock_gettime ffnvcodec libm libdrm libmfx opencl
> user32 vaapi videotoolbox corefoundation corevideo coremedia bcrypt"
> > +avutil_suggest="clock_gettime ffnvcodec libm libdrm libmfx opencl
> vulkan user32 vaapi videotoolbox corefoundation corevideo coremedia bcrypt"
>
> Again, this change belongs in patch 1/6
>
> >  postproc_deps="avutil gpl"
> >  postproc_suggest="libm"
> >  swresample_deps="avutil"
>
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>

Sorry, forgot. Moved to the hwcontext commit locally.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH 3/6] lavfi: add a Vulkan avgblur filter

[Rostislav Pehlivanov]

Signed-off-by: Rostislav Pehlivanov 
---
 configure   |   1 +
 libavfilter/Makefile|   1 +
 libavfilter/allfilters.c|   1 +
 libavfilter/vf_avgblur_vulkan.c | 343 
 4 files changed, 346 insertions(+)
 create mode 100644 libavfilter/vf_avgblur_vulkan.c

diff --git a/configure b/configure
index 97bd4225dc..eab7c5b630 100755
--- a/configure
+++ b/configure
@@ -3313,6 +3313,7 @@ ass_filter_deps="libass"
 atempo_filter_deps="avcodec"
 atempo_filter_select="rdft"
 avgblur_opencl_filter_deps="opencl"
+avgblur_vulkan_filter_deps="vulkan libshaderc"
 azmq_filter_deps="libzmq"
 blackframe_filter_deps="gpl"
 boxblur_filter_deps="gpl"
diff --git a/libavfilter/Makefile b/libavfilter/Makefile
index 5b4be4966c..d1cab35e2e 100644
--- a/libavfilter/Makefile
+++ b/libavfilter/Makefile
@@ -150,6 +150,7 @@ OBJS-$(CONFIG_ATADENOISE_FILTER) += 
vf_atadenoise.o
 OBJS-$(CONFIG_AVGBLUR_FILTER)+= vf_avgblur.o
 OBJS-$(CONFIG_AVGBLUR_OPENCL_FILTER) += vf_avgblur_opencl.o opencl.o \
 opencl/avgblur.o
+OBJS-$(CONFIG_AVGBLUR_VULKAN_FILTER) += vf_avgblur_vulkan.o vulkan.o
 OBJS-$(CONFIG_BBOX_FILTER)   += bbox.o vf_bbox.o
 OBJS-$(CONFIG_BENCH_FILTER)  += f_bench.o
 OBJS-$(CONFIG_BITPLANENOISE_FILTER)  += vf_bitplanenoise.o
diff --git a/libavfilter/allfilters.c b/libavfilter/allfilters.c
index f2d27d2424..a05616f728 100644
--- a/libavfilter/allfilters.c
+++ b/libavfilter/allfilters.c
@@ -141,6 +141,7 @@ extern AVFilter ff_vf_ass;
 extern AVFilter ff_vf_atadenoise;
 extern AVFilter ff_vf_avgblur;
 extern AVFilter ff_vf_avgblur_opencl;
+extern AVFilter ff_vf_avgblur_vulkan;
 extern AVFilter ff_vf_bbox;
 extern AVFilter ff_vf_bench;
 extern AVFilter ff_vf_bitplanenoise;
diff --git a/libavfilter/vf_avgblur_vulkan.c b/libavfilter/vf_avgblur_vulkan.c
new file mode 100644
index 00..5b89ae0718
--- /dev/null
+++ b/libavfilter/vf_avgblur_vulkan.c
@@ -0,0 +1,343 @@
+/*
+ * This file is part of FFmpeg.
+ *
+ * FFmpeg is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public
+ * License as published by the Free Software Foundation; either
+ * version 2.1 of the License, or (at your option) any later version.
+ *
+ * FFmpeg is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+ * Lesser General Public License for more details.
+ *
+ * You should have received a copy of the GNU Lesser General Public
+ * License along with FFmpeg; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA
+ */
+
+#include "libavutil/opt.h"
+#include "vulkan.h"
+#include "internal.h"
+
+typedef struct AvgBlurVulkanContext {
+VulkanFilterContext vkctx;
+
+int initialized;
+FFVkExecContext exec;
+
+/* Shader updators, must be in the main filter struct */
+VkDescriptorImageInfo input_images[3];
+VkDescriptorImageInfo output_images[3];
+
+int size_x;
+int size_y;
+int planes;
+} AvgBlurVulkanContext;
+
+static const char blur_kernel[] = {
+C(0, #define CACHE_SIZE (ivec2(gl_WorkGroupSize) + FILTER_RADIUS*2)
)
+C(0, shared vec4 cache[AREA(CACHE_SIZE)];  
)
+C(0,   
)
+C(0, void blur_kernel(int idx, ivec2 pos)  
)
+C(0, { 
)
+C(1, ivec2 d;  
)
+C(1, const ivec2 s = CACHE_SIZE;   
)
+C(1, const ivec2 w = ivec2(gl_WorkGroupSize);  
)
+C(1, const ivec2 l = ivec2(gl_LocalInvocationID.xy);   
)
+C(1,   
)
+C(1, for (d.y = l.y; d.y < s.y; d.y += w.y) {  
)
+C(2, for (d.x = l.x; d.x < s.x; d.x += w.x) {  
)
+C(3, const ivec2 np = pos + d - l - FILTER_RADIUS; 
)
+C(3, cache[d.y*s.x + d.x] = imageLoad(input_img[idx], np); 
)
+C(2, } 
)
+C(1, } 
)
+C(0,   
)
+C(1, barrier();
)
+C(0,  

[FFmpeg-devel] [PATCH 2/6] lavfi: add common Vulkan filtering code

[Rostislav Pehlivanov]

This commit adds a common code for use in Vulkan filters. It attempts
to ease the burden of writing Vulkan image filtering to a minimum,
which is pretty much a requirement considering how verbose the API is.

It supports both compute and graphic pipelines and manages to abstract
the API to such a level there's no need to call any Vulkan functions
inside the init path of the code. Handling shader descriptors is probably
the bulk of the code, and despite the abstraction, it loses none of the
features for describing shader IO.

In order to produce linkable shaders, it depends on the libshaderc
library (and depends on the latest stable version of it). This allows
for greater performance and flexibility than static built-in shaders
and also eliminates the cumbersome process of interfacing with glslang
to compile GLSL to SPIR-V.

It's based off of the common opencl and provides similar interfaces for
filter pad init and config, with the addition that it also supports
in-place filtering.

Signed-off-by: Rostislav Pehlivanov 
---
 configure|   12 +-
 libavfilter/vulkan.c | 1192 ++
 libavfilter/vulkan.h |  223 
 3 files changed, 1425 insertions(+), 2 deletions(-)
 create mode 100644 libavfilter/vulkan.c
 create mode 100644 libavfilter/vulkan.h

diff --git a/configure b/configure
index 7623a1205a..97bd4225dc 100755
--- a/configure
+++ b/configure
@@ -252,6 +252,7 @@ External library support:
   --enable-librsvg enable SVG rasterization via librsvg [no]
   --enable-librubberband   enable rubberband needed for rubberband filter [no]
   --enable-librtmp enable RTMP[E] support via librtmp [no]
+  --enable-libshaderc  enable GLSL->SPIRV compilation via libshaderc [no]
   --enable-libshineenable fixed-point MP3 encoding via libshine [no]
   --enable-libsmbclientenable Samba protocol via libsmbclient [no]
   --enable-libsnappy   enable Snappy compression, needed for hap encoding 
[no]
@@ -1709,6 +1710,7 @@ EXTERNAL_LIBRARY_LIST="
 libpulse
 librsvg
 librtmp
+libshaderc
 libshine
 libsmbclient
 libsnappy
@@ -2228,6 +2230,7 @@ HAVE_LIST="
 opencl_dxva2
 opencl_vaapi_beignet
 opencl_vaapi_intel_media
+shaderc_opt_perf
 vulkan_drm_mod
 perl
 pod2man
@@ -3462,12 +3465,12 @@ avcodec_select="null_bsf"
 avdevice_deps="avformat avcodec avutil"
 avdevice_suggest="libm"
 avfilter_deps="avutil"
-avfilter_suggest="libm"
+avfilter_suggest="libm libshaderc"
 avformat_deps="avcodec avutil"
 avformat_suggest="libm network zlib"
 avresample_deps="avutil"
 avresample_suggest="libm"
-avutil_suggest="clock_gettime ffnvcodec libm libdrm libmfx opencl user32 vaapi 
videotoolbox corefoundation corevideo coremedia bcrypt"
+avutil_suggest="clock_gettime ffnvcodec libm libdrm libmfx opencl vulkan 
user32 vaapi videotoolbox corefoundation corevideo coremedia bcrypt"
 postproc_deps="avutil gpl"
 postproc_suggest="libm"
 swresample_deps="avutil"
@@ -6056,6 +6059,7 @@ enabled libpulse  && require_pkg_config libpulse 
libpulse pulse/pulseaud
 enabled librsvg   && require_pkg_config librsvg librsvg-2.0 
librsvg-2.0/librsvg/rsvg.h rsvg_handle_render_cairo
 enabled librtmp   && require_pkg_config librtmp librtmp librtmp/rtmp.h 
RTMP_Socket
 enabled librubberband && require_pkg_config librubberband "rubberband >= 
1.8.1" rubberband/rubberband-c.h rubberband_new -lstdc++ && append 
librubberband_extralibs "-lstdc++"
+enabled libshaderc&& require libshaderc shaderc/shaderc.h 
shaderc_compiler_initialize -lshaderc_shared
 enabled libshine  && require_pkg_config libshine shine shine/layer3.h 
shine_encode_buffer
 enabled libsmbclient  && { check_pkg_config libsmbclient smbclient 
libsmbclient.h smbc_init ||
require libsmbclient libsmbclient.h smbc_init 
-lsmbclient; }
@@ -6363,6 +6367,10 @@ enabled crystalhd && check_lib crystalhd "stdint.h 
libcrystalhd/libcrystalhd_if.
 enabled vulkan &&
 require_pkg_config vulkan "vulkan >= 1.1.73" "vulkan/vulkan.h" 
vkCreateInstance
 
+if enabled_all vulkan libshaderc ; then
+check_cc shaderc_opt_perf shaderc/shaderc.h "int t = 
shaderc_optimization_level_performance"
+fi
+
 if enabled_all vulkan libdrm ; then
 check_cpp_condition vulkan_drm_mod vulkan/vulkan.h "defined 
VK_EXT_IMAGE_DRM_FORMAT_MODIFIER_EXTENSION_NAME"
 fi
diff --git a/libavfilter/vulkan.c b/libavfilter/vulkan.c
new file mode 100644
index 00..976e846fa3
--- /dev/null
+++ b/libavfilter/vulkan.c
@@ -0,0 +1,1192 @@
+/*
+ * Vulkan utilities
+ * Copyright (c) 2018 Rostislav Pehlivanov 
+ *
+ * 

[FFmpeg-devel] [PATCH 5/6] lavfi: add a Vulkan scale filter

[Rostislav Pehlivanov]

Can convert to RGB using very fast fixed-function conversions.

Signed-off-by: Rostislav Pehlivanov 
---
 configure |   1 +
 libavfilter/Makefile  |   1 +
 libavfilter/allfilters.c  |   1 +
 libavfilter/vf_scale_vulkan.c | 395 ++
 4 files changed, 398 insertions(+)
 create mode 100644 libavfilter/vf_scale_vulkan.c

diff --git a/configure b/configure
index cd5229ef2d..d1ceb9e38d 100755
--- a/configure
+++ b/configure
@@ -3428,6 +3428,7 @@ zmq_filter_deps="libzmq"
 zoompan_filter_deps="swscale"
 zscale_filter_deps="libzimg const_nan"
 scale_vaapi_filter_deps="vaapi VAProcPipelineParameterBuffer"
+scale_vulkan_filter_deps="vulkan libshaderc"
 vpp_qsv_filter_deps="libmfx"
 vpp_qsv_filter_select="qsvvpp"
 
diff --git a/libavfilter/Makefile b/libavfilter/Makefile
index dbb7a859dd..6e2d3681ec 100644
--- a/libavfilter/Makefile
+++ b/libavfilter/Makefile
@@ -317,6 +317,7 @@ OBJS-$(CONFIG_SCALE_CUDA_FILTER) += 
vf_scale_cuda.o vf_scale_cuda.pt
 OBJS-$(CONFIG_SCALE_NPP_FILTER)  += vf_scale_npp.o scale.o
 OBJS-$(CONFIG_SCALE_QSV_FILTER)  += vf_scale_qsv.o
 OBJS-$(CONFIG_SCALE_VAAPI_FILTER)+= vf_scale_vaapi.o scale.o 
vaapi_vpp.o
+OBJS-$(CONFIG_SCALE_VULKAN_FILTER)   += vf_scale_vulkan.o scale.o 
vulkan.o
 OBJS-$(CONFIG_SCALE2REF_FILTER)  += vf_scale.o scale.o
 OBJS-$(CONFIG_SELECT_FILTER) += f_select.o
 OBJS-$(CONFIG_SELECTIVECOLOR_FILTER) += vf_selectivecolor.o
diff --git a/libavfilter/allfilters.c b/libavfilter/allfilters.c
index 5848ad9b4f..ee58cc9eee 100644
--- a/libavfilter/allfilters.c
+++ b/libavfilter/allfilters.c
@@ -306,6 +306,7 @@ extern AVFilter ff_vf_scale_cuda;
 extern AVFilter ff_vf_scale_npp;
 extern AVFilter ff_vf_scale_qsv;
 extern AVFilter ff_vf_scale_vaapi;
+extern AVFilter ff_vf_scale_vulkan;
 extern AVFilter ff_vf_scale2ref;
 extern AVFilter ff_vf_select;
 extern AVFilter ff_vf_selectivecolor;
diff --git a/libavfilter/vf_scale_vulkan.c b/libavfilter/vf_scale_vulkan.c
new file mode 100644
index 00..4a5647072d
--- /dev/null
+++ b/libavfilter/vf_scale_vulkan.c
@@ -0,0 +1,395 @@
+/*
+ * This file is part of FFmpeg.
+ *
+ * FFmpeg is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public
+ * License as published by the Free Software Foundation; either
+ * version 2.1 of the License, or (at your option) any later version.
+ *
+ * FFmpeg is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+ * Lesser General Public License for more details.
+ *
+ * You should have received a copy of the GNU Lesser General Public
+ * License along with FFmpeg; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA
+ */
+
+#include "libavutil/opt.h"
+#include "vulkan.h"
+#include "scale.h"
+#include "internal.h"
+
+enum ScalerFunc {
+F_BILINEAR = 0,
+F_NEAREST,
+
+F_NB,
+};
+
+typedef struct ScaleVulkanContext {
+VulkanFilterContext vkctx;
+
+int conv;
+int initialized;
+FFVkExecContext exec;
+const VulkanSampler *sampler;
+
+/* Shader updators, must be in the main filter struct */
+VkDescriptorImageInfo input_images[3];
+VkDescriptorImageInfo output_images[3];
+
+enum ScalerFunc scaler;
+char *output_format_string;
+char *w_expr;
+char *h_expr;
+} ScaleVulkanContext;
+
+static const char scale_bilinear[] = {
+C(0, void scale_bilinear(int idx, ivec2 pos)   
)
+C(0, { 
)
+C(1, const vec2 npos = (vec2(pos) + 0.5f) / 
imageSize(output_img[idx]);)
+C(1, imageStore(output_img[idx], pos, texture(input_img[idx], npos));  
)
+C(0, } 
)
+};
+
+static av_cold int init_filter(AVFilterContext *ctx, AVFrame *in)
+{
+int err;
+VkFilter sampler_mode;
+ScaleVulkanContext *s = ctx->priv;
+
+switch (s->scaler) {
+case F_NEAREST:
+sampler_mode = VK_FILTER_NEAREST;
+break;
+case F_BILINEAR:
+sampler_mode = VK_FILTER_LINEAR;
+break;
+};
+
+/* Create a sampler */
+s->sampler = ff_vk_init_sampler(ctx, s->conv ? in : NULL, 0, sampler_mode);
+if (!s->sampler)
+return AVERROR_EXTERNAL;
+
+{ /* Create the shader */
+SPIRVShader *shd = ff_vk_init_shader(ctx, "scale_compute",
+ VK_SHADER_STAGE_COMPUTE_BIT);
+ff_vk_set_compute_shader_sizes(ctx, shd, (int [3]){ 16, 16, 1 });
+
+VulkanDescriptorSetBinding desc_i[2] 

[FFmpeg-devel] [PATCH 0/6] Vulkan hwcontext and filtering

[Rostislav Pehlivanov]

Fixed bugs, added Vaapi back and forth mapping, dropped host memory mapping
until it gets fixed.

Rostislav Pehlivanov (6):
  lavu: add a Vulkan hwcontext
  lavfi: add common Vulkan filtering code
  lavfi: add a Vulkan avgblur filter
  lavfi: add a Vulkan chromatic aberration filter
  lavfi: add a Vulkan scale filter
  lavfi: add a Vulkan overlay filter

 configure   |   26 +-
 doc/APIchanges  |4 +
 libavfilter/Makefile|4 +
 libavfilter/allfilters.c|4 +
 libavfilter/vf_avgblur_vulkan.c |  343 +++
 libavfilter/vf_chromaticaberration_vulkan.c |  342 +++
 libavfilter/vf_overlay_vulkan.c |  461 
 libavfilter/vf_scale_vulkan.c   |  395 
 libavfilter/vulkan.c| 1192 ++
 libavfilter/vulkan.h|  223 ++
 libavutil/Makefile  |3 +
 libavutil/hwcontext.c   |4 +
 libavutil/hwcontext.h   |1 +
 libavutil/hwcontext_internal.h  |1 +
 libavutil/hwcontext_vulkan.c| 2225 +++
 libavutil/hwcontext_vulkan.h|  133 ++
 libavutil/pixdesc.c |4 +
 libavutil/pixfmt.h  |4 +
 libavutil/version.h |4 +-
 19 files changed, 5369 insertions(+), 4 deletions(-)
 create mode 100644 libavfilter/vf_avgblur_vulkan.c
 create mode 100644 libavfilter/vf_chromaticaberration_vulkan.c
 create mode 100644 libavfilter/vf_overlay_vulkan.c
 create mode 100644 libavfilter/vf_scale_vulkan.c
 create mode 100644 libavfilter/vulkan.c
 create mode 100644 libavfilter/vulkan.h
 create mode 100644 libavutil/hwcontext_vulkan.c
 create mode 100644 libavutil/hwcontext_vulkan.h

-- 
2.18.0.rc2.346.g013aa6912e

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

[FFmpeg-devel] [PATCH 6/6] lavfi: add a Vulkan overlay filter

[Rostislav Pehlivanov]

Could be done in-plane with the main image but framesync segfaults.

Signed-off-by: Rostislav Pehlivanov 
---
 configure   |   1 +
 libavfilter/Makefile|   1 +
 libavfilter/allfilters.c|   1 +
 libavfilter/vf_overlay_vulkan.c | 461 
 4 files changed, 464 insertions(+)
 create mode 100644 libavfilter/vf_overlay_vulkan.c

diff --git a/configure b/configure
index d1ceb9e38d..2edd4e36aa 100755
--- a/configure
+++ b/configure
@@ -3370,6 +3370,7 @@ ocr_filter_deps="libtesseract"
 ocv_filter_deps="libopencv"
 openclsrc_filter_deps="opencl"
 overlay_opencl_filter_deps="opencl"
+overlay_vulkan_filter_deps="vulkan libshaderc"
 overlay_qsv_filter_deps="libmfx"
 overlay_qsv_filter_select="qsvvpp"
 owdenoise_filter_deps="gpl"
diff --git a/libavfilter/Makefile b/libavfilter/Makefile
index 6e2d3681ec..c51add5cb4 100644
--- a/libavfilter/Makefile
+++ b/libavfilter/Makefile
@@ -280,6 +280,7 @@ OBJS-$(CONFIG_OSCILLOSCOPE_FILTER)   += 
vf_datascope.o
 OBJS-$(CONFIG_OVERLAY_FILTER)+= vf_overlay.o framesync.o
 OBJS-$(CONFIG_OVERLAY_OPENCL_FILTER) += vf_overlay_opencl.o opencl.o \
 opencl/overlay.o framesync.o
+OBJS-$(CONFIG_OVERLAY_VULKAN_FILTER) += vf_overlay_vulkan.o
 OBJS-$(CONFIG_OVERLAY_QSV_FILTER)+= vf_overlay_qsv.o framesync.o
 OBJS-$(CONFIG_OWDENOISE_FILTER)  += vf_owdenoise.o
 OBJS-$(CONFIG_PAD_FILTER)+= vf_pad.o
diff --git a/libavfilter/allfilters.c b/libavfilter/allfilters.c
index ee58cc9eee..7c9ff0ab41 100644
--- a/libavfilter/allfilters.c
+++ b/libavfilter/allfilters.c
@@ -269,6 +269,7 @@ extern AVFilter ff_vf_ocv;
 extern AVFilter ff_vf_oscilloscope;
 extern AVFilter ff_vf_overlay;
 extern AVFilter ff_vf_overlay_opencl;
+extern AVFilter ff_vf_overlay_vulkan;
 extern AVFilter ff_vf_overlay_qsv;
 extern AVFilter ff_vf_owdenoise;
 extern AVFilter ff_vf_pad;
diff --git a/libavfilter/vf_overlay_vulkan.c b/libavfilter/vf_overlay_vulkan.c
new file mode 100644
index 00..a7d8cc3cf2
--- /dev/null
+++ b/libavfilter/vf_overlay_vulkan.c
@@ -0,0 +1,461 @@
+/*
+ * This file is part of FFmpeg.
+ *
+ * FFmpeg is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public
+ * License as published by the Free Software Foundation; either
+ * version 2.1 of the License, or (at your option) any later version.
+ *
+ * FFmpeg is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+ * Lesser General Public License for more details.
+ *
+ * You should have received a copy of the GNU Lesser General Public
+ * License along with FFmpeg; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA
+ */
+
+#include "libavutil/opt.h"
+#include "vulkan.h"
+#include "internal.h"
+#include "framesync.h"
+
+typedef struct OverlayVulkanContext {
+VulkanFilterContext vkctx;
+
+int initialized;
+FFVkExecContext exec;
+FFFrameSync fs;
+FFVkBuffer params_buf;
+
+/* Shader updators, must be in the main filter struct */
+VkDescriptorImageInfo main_images[3];
+VkDescriptorImageInfo overlay_images[3];
+VkDescriptorImageInfo output_images[3];
+VkDescriptorBufferInfo params_desc;
+
+int overlay_x;
+int overlay_y;
+} OverlayVulkanContext;
+
+static const char overlay_noalpha[] = {
+C(0, void overlay_noalpha(int i, ivec2 pos)
)
+C(0, { 
)
+C(1, ivec2 overlay_size = imageSize(overlay_img[i]);   
)
+C(1, if ((o_offset[i].x <= pos.x) && (o_offset[i].y <= pos.y) &&
+ (pos.x < (o_offset[i].x + overlay_size.x)) &&
+ (pos.y < (o_offset[i].y + overlay_size.y))) { 
)
+C(2, vec4 res = imageLoad(overlay_img[i], pos - o_offset[i]);  
)
+C(2, imageStore(output_img[i], pos, res);  
)
+C(1, } else {  
)
+C(2, vec4 res = imageLoad(main_img[i], pos);   
)
+C(2, imageStore(output_img[i], pos, res);  
)
+C(1, } 
)
+C(0, } 
)
+};
+
+static av_cold int init_filter(AVFilterContext *ctx)
+{
+int err;
+OverlayVulkanContext *s = ctx->priv;
+
+{ /* Create t

[FFmpeg-devel] [PATCH 4/6] lavfi: add a Vulkan chromatic aberration filter

[Rostislav Pehlivanov]

It tries to do something similar to it with YUV images, but RGB images
are done properly.

Signed-off-by: Rostislav Pehlivanov 
---
 configure   |   1 +
 libavfilter/Makefile|   1 +
 libavfilter/allfilters.c|   1 +
 libavfilter/vf_chromaticaberration_vulkan.c | 342 
 4 files changed, 345 insertions(+)
 create mode 100644 libavfilter/vf_chromaticaberration_vulkan.c

diff --git a/configure b/configure
index eab7c5b630..cd5229ef2d 100755
--- a/configure
+++ b/configure
@@ -3318,6 +3318,7 @@ azmq_filter_deps="libzmq"
 blackframe_filter_deps="gpl"
 boxblur_filter_deps="gpl"
 bs2b_filter_deps="libbs2b"
+chromaticaberration_vulkan_filter_deps="vulkan libshaderc"
 colormatrix_filter_deps="gpl"
 convolution_opencl_filter_deps="opencl"
 convolve_filter_deps="avcodec"
diff --git a/libavfilter/Makefile b/libavfilter/Makefile
index d1cab35e2e..dbb7a859dd 100644
--- a/libavfilter/Makefile
+++ b/libavfilter/Makefile
@@ -160,6 +160,7 @@ OBJS-$(CONFIG_BLEND_FILTER)  += vf_blend.o 
framesync.o
 OBJS-$(CONFIG_BOXBLUR_FILTER)+= vf_boxblur.o
 OBJS-$(CONFIG_BWDIF_FILTER)  += vf_bwdif.o
 OBJS-$(CONFIG_CHROMAKEY_FILTER)  += vf_chromakey.o
+OBJS-$(CONFIG_CHROMATICABERRATION_VULKAN_FILTER) += 
vf_chromaticaberration_vulkan.o vulkan.o
 OBJS-$(CONFIG_CIESCOPE_FILTER)   += vf_ciescope.o
 OBJS-$(CONFIG_CODECVIEW_FILTER)  += vf_codecview.o
 OBJS-$(CONFIG_COLORBALANCE_FILTER)   += vf_colorbalance.o
diff --git a/libavfilter/allfilters.c b/libavfilter/allfilters.c
index a05616f728..5848ad9b4f 100644
--- a/libavfilter/allfilters.c
+++ b/libavfilter/allfilters.c
@@ -151,6 +151,7 @@ extern AVFilter ff_vf_blend;
 extern AVFilter ff_vf_boxblur;
 extern AVFilter ff_vf_bwdif;
 extern AVFilter ff_vf_chromakey;
+extern AVFilter ff_vf_chromaticaberration_vulkan;
 extern AVFilter ff_vf_ciescope;
 extern AVFilter ff_vf_codecview;
 extern AVFilter ff_vf_colorbalance;
diff --git a/libavfilter/vf_chromaticaberration_vulkan.c 
b/libavfilter/vf_chromaticaberration_vulkan.c
new file mode 100644
index 00..1d1aeb95a0
--- /dev/null
+++ b/libavfilter/vf_chromaticaberration_vulkan.c
@@ -0,0 +1,342 @@
+/*
+ * This file is part of FFmpeg.
+ *
+ * FFmpeg is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public
+ * License as published by the Free Software Foundation; either
+ * version 2.1 of the License, or (at your option) any later version.
+ *
+ * FFmpeg is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+ * Lesser General Public License for more details.
+ *
+ * You should have received a copy of the GNU Lesser General Public
+ * License along with FFmpeg; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA
+ */
+
+#include "libavutil/opt.h"
+#include "vulkan.h"
+#include "internal.h"
+
+typedef struct ChromaticAberrationVulkanContext {
+VulkanFilterContext vkctx;
+
+int initialized;
+FFVkExecContext exec;
+
+/* Shader updators, must be in the main filter struct */
+VkDescriptorImageInfo input_images[3];
+VkDescriptorImageInfo output_images[3];
+
+float dist_x;
+float dist_y;
+} ChromaticAberrationVulkanContext;
+
+static const char distort_chroma_kernel[] = {
+C(0, void distort_rgb(ivec2 size, ivec2 pos)   
)
+C(0, { 
)
+C(1, const vec2 p = ((vec2(pos)/vec2(size)) - 0.5f)*2.0f;  
)
+C(1, const vec2 o = p * (FILTER_DIST - 1.0f);  
)
+C(0,   
)
+C(1, vec4 res; 
)
+C(1, res.r = texture(input_img[0], ((p - o)/2.0f) + 0.5f).r;   
)
+C(1, res.g = texture(input_img[0], ((p)/2.0f) + 0.5f).g;   
)
+C(1, res.b = texture(input_img[0], ((p + o)/2.0f) + 0.5f).b;   
)
+C(1, res.a = texture(input_img[0], ((p)/2.0f) + 0.5f).a;   
)
+C(1, imageStore(output_img[0], pos, res);  
)
+C(0, } 
)
+C(0,   
)
+C(0, void distort_chroma(int idx, ivec2 size, ivec2 pos)   
)
+C(0, { 
)
+C(1, vec2 p = ((vec2(pos)/vec2(size)) - 0.5f)*2.0f;
)
+C(1, 

[FFmpeg-devel] [PATCH 1/6] lavu: add a Vulkan hwcontext

[Rostislav Pehlivanov]

This commit adds a Vulkan hwcontext, currently capable of mapping DRM and
VAAPI frames but additional functionality can be added later to support
importing of D3D11 surfaces as well as exporting to various other APIs.

This context requires the newest stable version of the Vulkan API.

It makes use of every part of the Vulkan spec in order to ensure fastest
possible uploading, downloading and mapping of frames.

To be useful for non-RGB images an implementation with the YUV images
extension is needed. All current implementations support that with the
exception of AMD, though support is coming soon for Mesa.

Signed-off-by: Rostislav Pehlivanov 
---
 configure  |   10 +
 doc/APIchanges |4 +
 libavutil/Makefile |3 +
 libavutil/hwcontext.c  |4 +
 libavutil/hwcontext.h  |1 +
 libavutil/hwcontext_internal.h |1 +
 libavutil/hwcontext_vulkan.c   | 2225 
 libavutil/hwcontext_vulkan.h   |  133 ++
 libavutil/pixdesc.c|4 +
 libavutil/pixfmt.h |4 +
 libavutil/version.h|4 +-
 11 files changed, 2391 insertions(+), 2 deletions(-)
 create mode 100644 libavutil/hwcontext_vulkan.c
 create mode 100644 libavutil/hwcontext_vulkan.h

diff --git a/configure b/configure
index 473be31d7f..7623a1205a 100755
--- a/configure
+++ b/configure
@@ -302,6 +302,7 @@ External library support:
   --enable-opengl  enable OpenGL rendering [no]
   --enable-openssl enable openssl, needed for https support
if gnutls, libtls or mbedtls is not used [no]
+  --enable-vulkan  enable Vulkan code [no]
   --disable-sndio  disable sndio support [autodetect]
   --disable-schannel   disable SChannel SSP, needed for TLS support on
Windows if openssl and gnutls are not used 
[autodetect]
@@ -1770,6 +1771,7 @@ HWACCEL_LIBRARY_LIST="
 mmal
 omx
 opencl
+vulkan
 "
 
 DOCUMENT_LIST="
@@ -2226,6 +2228,7 @@ HAVE_LIST="
 opencl_dxva2
 opencl_vaapi_beignet
 opencl_vaapi_intel_media
+vulkan_drm_mod
 perl
 pod2man
 texi2html
@@ -6357,6 +6360,13 @@ enabled vdpau &&
 
 enabled crystalhd && check_lib crystalhd "stdint.h 
libcrystalhd/libcrystalhd_if.h" DtsCrystalHDVersion -lcrystalhd
 
+enabled vulkan &&
+require_pkg_config vulkan "vulkan >= 1.1.73" "vulkan/vulkan.h" 
vkCreateInstance
+
+if enabled_all vulkan libdrm ; then
+check_cpp_condition vulkan_drm_mod vulkan/vulkan.h "defined 
VK_EXT_IMAGE_DRM_FORMAT_MODIFIER_EXTENSION_NAME"
+fi
+
 if enabled x86; then
 case $target_os in
 mingw32*|mingw64*|win32|win64|linux|cygwin*)
diff --git a/doc/APIchanges b/doc/APIchanges
index efe15ba4e0..b2684eb442 100644
--- a/doc/APIchanges
+++ b/doc/APIchanges
@@ -15,6 +15,10 @@ libavutil: 2017-10-21
 
 API changes, most recent first:
 
+2018-04-xx - xx - lavu 56.19.100 - hwcontext.h
+  Add AV_PIX_FMT_VULKAN
+  Add AV_HWDEVICE_TYPE_VULKAN and implementation.
+
 2018-05-xx - xx - lavf 58.15.100 - avformat.h
   Add pmt_version field to AVProgram
 
diff --git a/libavutil/Makefile b/libavutil/Makefile
index d0632f16a6..9fb32bc5e2 100644
--- a/libavutil/Makefile
+++ b/libavutil/Makefile
@@ -42,6 +42,7 @@ HEADERS = adler32.h   
  \
   hwcontext_vaapi.h \
   hwcontext_videotoolbox.h  \
   hwcontext_vdpau.h \
+  hwcontext_vulkan.h\
   imgutils.h\
   intfloat.h\
   intreadwrite.h\
@@ -168,6 +169,7 @@ OBJS-$(CONFIG_QSV)  += hwcontext_qsv.o
 OBJS-$(CONFIG_VAAPI)+= hwcontext_vaapi.o
 OBJS-$(CONFIG_VIDEOTOOLBOX) += hwcontext_videotoolbox.o
 OBJS-$(CONFIG_VDPAU)+= hwcontext_vdpau.o
+OBJS-$(CONFIG_VULKAN)   += hwcontext_vulkan.o
 
 OBJS += $(COMPAT_OBJS:%=../compat/%)
 
@@ -183,6 +185,7 @@ SKIPHEADERS-$(CONFIG_OPENCL)   += hwcontext_opencl.h
 SKIPHEADERS-$(CONFIG_VAAPI)+= hwcontext_vaapi.h
 SKIPHEADERS-$(CONFIG_VIDEOTOOLBOX) += hwcontext_videotoolbox.h
 SKIPHEADERS-$(CONFIG_VDPAU)+= hwcontext_vdpau.h
+SKIPHEADERS-$(CONFIG_VULKAN)   += hwcontext_vulkan.h
 
 TESTPROGS = adler32 \
 aes \
diff --git a/libavutil/hwcontext.c b/libavutil/hwcontext.c
index f1e404ab20..ee2216c7c1 100644
--- a/libavutil/hwcontext.c
++

Re: [FFmpeg-devel] [PATCH v2 1/8] hwcontext_internal: add ff_hwframe_map_replace

[Rostislav Pehlivanov]

On 22 April 2018 at 17:47, Rostislav Pehlivanov  wrote:

> Used to fix unmapping when no direct interop exists between APIs.
>
> Signed-off-by: Rostislav Pehlivanov 
> ---
>  libavutil/hwcontext.c  | 7 +++
>  libavutil/hwcontext_internal.h | 5 +
>  2 files changed, 12 insertions(+)
>
> diff --git a/libavutil/hwcontext.c b/libavutil/hwcontext.c
> index 70c556ecac..f9ce2f5b13 100644
> --- a/libavutil/hwcontext.c
> +++ b/libavutil/hwcontext.c
> @@ -871,3 +871,10 @@ fail:
>  av_buffer_unref(&dst_ref);
>  return ret;
>  }
> +
> +int ff_hwframe_map_replace(AVFrame *dst, const AVFrame *src)
> +{
> +HWMapDescriptor *hwmap = (HWMapDescriptor*)dst->buf[0]->data;
> +av_frame_unref(hwmap->source);
> +return av_frame_ref(hwmap->source, src);
> +}
> diff --git a/libavutil/hwcontext_internal.h b/libavutil/hwcontext_
> internal.h
> index 332062ddaa..77dc47ddd6 100644
> --- a/libavutil/hwcontext_internal.h
> +++ b/libavutil/hwcontext_internal.h
> @@ -156,6 +156,11 @@ int ff_hwframe_map_create(AVBufferRef *hwframe_ref,
>  HWMapDescriptor *hwmap),
>void *priv);
>
> +/**
> + * Replace the current hwmap of dst with the one from src, used for
> indirect
> + * mappings like VAAPI->(DRM)->OpenCL/Vulkan where a direct interop is
> missing
> + */
> +int ff_hwframe_map_replace(AVFrame *dst, const AVFrame *src);
>
>  extern const HWContextType ff_hwcontext_type_cuda;
>  extern const HWContextType ff_hwcontext_type_d3d11va;
> --
> 2.17.0
>
>
Pushed
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 1/4] lavu/frame: add mb_types side data

[Rostislav Pehlivanov]

On 17 June 2018 at 05:21, Ramiro Polla  wrote:

> ---
>  libavcodec/avcodec.h   |  4 
>  libavcodec/mpegutils.c | 20 
>  libavcodec/options_table.h |  1 +
>  libavutil/frame.c  |  1 +
>  libavutil/frame.h  |  9 +
>  5 files changed, 35 insertions(+)
>
> diff --git a/libavcodec/avcodec.h b/libavcodec/avcodec.h
> index c90166deb6..7fe4fc9347 100644
> --- a/libavcodec/avcodec.h
> +++ b/libavcodec/avcodec.h
> @@ -929,6 +929,10 @@ typedef struct RcOverride{
>   */
>  #define AV_CODEC_FLAG2_SHOW_ALL   (1 << 22)
>  /**
> + * Export macroblock types through frame side data
> + */
> +#define AV_CODEC_FLAG2_EXPORT_MB_TYPES (1 << 27)
> +/**
>   * Export motion vectors through frame side data
>   */
>  #define AV_CODEC_FLAG2_EXPORT_MVS (1 << 28)
> diff --git a/libavcodec/mpegutils.c b/libavcodec/mpegutils.c
> index 3f94540616..0fbe5f8c9d 100644
> --- a/libavcodec/mpegutils.c
> +++ b/libavcodec/mpegutils.c
> @@ -188,6 +188,26 @@ void ff_print_debug_info2(AVCodecContext *avctx,
> AVFrame *pict, uint8_t *mbskip_
>  av_freep(&mvs);
>  }
>
> +if ((avctx->flags2 & AV_CODEC_FLAG2_EXPORT_MB_TYPES) &&
> mbtype_table) {
> +int size = (2 + mb_height * mb_width) * sizeof(uint32_t);
> +int mb_x, mb_y;
> +
> +AVFrameSideData *sd;
> +uint32_t *out;
> +
> +sd = av_frame_new_side_data(pict, AV_FRAME_DATA_MB_TYPES, size);
> +if (!sd)
> +return;
> +
> +out = (uint32_t *) sd->data;
> +*out++ = mb_height;
> +*out++ = mb_width;
> +
> +for (mb_y = 0; mb_y < mb_height; mb_y++)
> +for (mb_x = 0; mb_x < mb_width; mb_x++)
> +*out++ = mbtype_table[mb_x + mb_y * mb_stride];
> +}
> +
>  /* TODO: export all the following to make them accessible for users
> (and filters) */
>  if (avctx->hwaccel || !mbtype_table)
>  return;
> diff --git a/libavcodec/options_table.h b/libavcodec/options_table.h
> index 099261e168..25c84de321 100644
> --- a/libavcodec/options_table.h
> +++ b/libavcodec/options_table.h
> @@ -76,6 +76,7 @@ static const AVOption avcodec_options[] = {
>  {"export_mvs", "export motion vectors through frame side data", 0,
> AV_OPT_TYPE_CONST, {.i64 = AV_CODEC_FLAG2_EXPORT_MVS}, INT_MIN, INT_MAX,
> V|D, "flags2"},
>  {"skip_manual", "do not skip samples and export skip information as frame
> side data", 0, AV_OPT_TYPE_CONST, {.i64 = AV_CODEC_FLAG2_SKIP_MANUAL},
> INT_MIN, INT_MAX, V|D, "flags2"},
>  {"ass_ro_flush_noop", "do not reset ASS ReadOrder field on flush", 0,
> AV_OPT_TYPE_CONST, {.i64 = AV_CODEC_FLAG2_RO_FLUSH_NOOP}, INT_MIN, INT_MAX,
> S|D, "flags2"},
> +{"export_mb_types", "export macroblock types through frame side data", 0,
> AV_OPT_TYPE_CONST, {.i64 = AV_CODEC_FLAG2_EXPORT_MB_TYPES}, INT_MIN,
> INT_MAX, V|D, "flags2"},
>  {"time_base", NULL, OFFSET(time_base), AV_OPT_TYPE_RATIONAL, {.dbl = 0},
> 0, INT_MAX},
>  {"g", "set the group of picture (GOP) size", OFFSET(gop_size),
> AV_OPT_TYPE_INT, {.i64 = 12 }, INT_MIN, INT_MAX, V|E},
>  {"ar", "set audio sampling rate (in Hz)", OFFSET(sample_rate),
> AV_OPT_TYPE_INT, {.i64 = DEFAULT }, 0, INT_MAX, A|D|E},
> diff --git a/libavutil/frame.c b/libavutil/frame.c
> index deb9b6f334..577d4f6e6d 100644
> --- a/libavutil/frame.c
> +++ b/libavutil/frame.c
> @@ -834,6 +834,7 @@ const char *av_frame_side_data_name(enum
> AVFrameSideDataType type)
>  case AV_FRAME_DATA_ICC_PROFILE: return "ICC profile";
>  case AV_FRAME_DATA_QP_TABLE_PROPERTIES: return "QP table
> properties";
>  case AV_FRAME_DATA_QP_TABLE_DATA:   return "QP table
> data";
> +case AV_FRAME_DATA_MB_TYPES:return "Macroblock
> types";
>  }
>  return NULL;
>  }
> diff --git a/libavutil/frame.h b/libavutil/frame.h
> index 9d57d6ce66..ce1231b03b 100644
> --- a/libavutil/frame.h
> +++ b/libavutil/frame.h
> @@ -158,6 +158,15 @@ enum AVFrameSideDataType {
>   */
>  AV_FRAME_DATA_QP_TABLE_DATA,
>  #endif
> +
> +/**
> + * Macroblock types exported by some codecs (on demand through the
> + * export_mb_types flag set in the libavcodec AVCodecContext flags2
> option).
> + * The data is composed by a header consisting of uint32_t mb_height
> and
> + * uint32_t mb_width, followed by a uint32_t
> mb_types[mb_height][mb_width]
> + * array.
> + */
> +AV_FRAME_DATA_MB_TYPES,
>  };
>
>  enum AVActiveFormatDescription {
> --
> 2.11.0
>
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>

NAK

I'd really rather have a json or xml output which would be codec
independent rather than this codec specific format. Which could then be fed
into an analyzer (like the AV1 analyzer). We discussed this before.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/m

Re: [FFmpeg-devel] [RFC] New build system

[Rostislav Pehlivanov]

On 14 June 2018 at 19:56, Nicolas George  wrote:

> Josh de Kock (2018-06-14):
> > As such, I'd like to propose adopting a new build system to FFmpeg,
> namely
> > Meson[1].
>
> I am very strongly against this.
>
> I loathe make and all it has to do with it, but really, for a project
> like this, it is the only viable option. The principles of make are
> already known by almost all potential Libre software developers, those
> in the project and those not yet.
>
>
No, it isn't. Maybe if you took a moment to look at the proposed branches
you'd notice NONE Of them remove ./configure. In fact that's precisely the
plan - to leave and still support the script for the forseeable future.
Hence your predjudice is unjustified. This simply adds support for a faster
build system to those who wish to use it.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 5/6] avcodec/avcodec.h: add AV_CODEC_ID_TIMED_TEXT_MARKUP

[Rostislav Pehlivanov]

On 31 May 2018 at 01:05, Marton Balint  wrote:

> Signed-off-by: Marton Balint 
> ---
>  libavcodec/avcodec.h| 1 +
>  libavcodec/codec_desc.c | 8 
>  libavcodec/version.h| 2 +-
>  3 files changed, 10 insertions(+), 1 deletion(-)
>
> diff --git a/libavcodec/avcodec.h b/libavcodec/avcodec.h
> index fb0c6fae70..91ccef538e 100644
> --- a/libavcodec/avcodec.h
> +++ b/libavcodec/avcodec.h
> @@ -665,6 +665,7 @@ enum AVCodecID {
>  AV_CODEC_ID_PJS,
>  AV_CODEC_ID_ASS,
>  AV_CODEC_ID_HDMV_TEXT_SUBTITLE,
> +AV_CODEC_ID_TIMED_TEXT_MARKUP,
>
>  /* other specific kind of codecs (generally used for attachments) */
>  AV_CODEC_ID_FIRST_UNKNOWN = 0x18000,   ///< A dummy ID
> pointing at the start of various fake codecs.
> diff --git a/libavcodec/codec_desc.c b/libavcodec/codec_desc.c
> index 79552a910d..9d38e63284 100644
> --- a/libavcodec/codec_desc.c
> +++ b/libavcodec/codec_desc.c
> @@ -3047,6 +3047,14 @@ static const AVCodecDescriptor codec_descriptors[]
> = {
>  .long_name = NULL_IF_CONFIG_SMALL("HDMV Text subtitle"),
>  .props = AV_CODEC_PROP_TEXT_SUB,
>  },
> +{
> +.id= AV_CODEC_ID_TIMED_TEXT_MARKUP,
> +.type  = AVMEDIA_TYPE_SUBTITLE,
> +.name  = "ttml",
> +.long_name = NULL_IF_CONFIG_SMALL("Timed Text Markup Language"),
> +.props = AV_CODEC_PROP_TEXT_SUB,
> +},
> +
>
>  /* other kind of codecs and pseudo-codecs */
>  {
> diff --git a/libavcodec/version.h b/libavcodec/version.h
> index f65346a1ac..5a70093eaa 100644
> --- a/libavcodec/version.h
> +++ b/libavcodec/version.h
> @@ -29,7 +29,7 @@
>
>  #define LIBAVCODEC_VERSION_MAJOR  58
>  #define LIBAVCODEC_VERSION_MINOR  19
> -#define LIBAVCODEC_VERSION_MICRO 104
> +#define LIBAVCODEC_VERSION_MICRO 105
>
>  #define LIBAVCODEC_VERSION_INT  AV_VERSION_INT(LIBAVCODEC_VERSION_MAJOR,
> \
> LIBAVCODEC_VERSION_MINOR, \
> --
> 2.16.3
>
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>

I'd prefer AV_CODEC_ID_TTML, TTML is how pretty much everyone refers to it
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH v6 1/3] avcodec: add flags for packets with top/bottom field

[Rostislav Pehlivanov]

On 23 May 2018 at 20:49, wm4  wrote:

> On Wed, 23 May 2018 20:25:34 +0100
> Rostislav Pehlivanov  wrote:
>
> > On 23 May 2018 at 20:01, wm4  wrote:
> >
> > > On Wed, 23 May 2018 14:29:38 -0400 (EDT)
> > > Patrick Keroulas  wrote:
> > >
> > > > - Original Message -
> > > > > From: "wm4" 
> > > > > To: ffmpeg-devel@ffmpeg.org
> > > > > Sent: Wednesday, May 23, 2018 12:02:45 PM
> > > > > Subject: Re: [FFmpeg-devel] [PATCH v6 1/3] avcodec: add flags for
> > > packets with top/bottom field
> > > >
> > > > > On Wed, 23 May 2018 16:46:17 +0100
> > > > > Rostislav Pehlivanov  wrote:
> > > > >
> > > > >> On 23 May 2018 at 16:18, wm4  wrote:
> > > > >>
> > > > >> > On Tue, 22 May 2018 17:19:35 -0400 (EDT)
> > > > >> > Patrick Keroulas  wrote:
> > > > >> >
> > > > >> > > - Original Message -
> > > > >> > > > From: "Rostislav Pehlivanov" 
> > > > >> > > > To: "FFmpeg development discussions and patches" <
> > > > >> > ffmpeg-devel@ffmpeg.org>
> > > > >> > > > Sent: Friday, May 18, 2018 5:28:42 PM
> > > > >> > > > Subject: Re: [FFmpeg-devel] [PATCH v6 1/3] avcodec: add
> flags
> > > for
> > > > >> > packets with top/bottom field
> > > > >> > >
> > > > >> > > > On 18 May 2018 at 22:17, wm4 
> wrote:
> > > > >> > >
> > > > >> > >
> > > > >> > >
> > > > >> > > > > But I think a new side data type would be much saner. We
> > > could even
> > > > >> > > > > just make it something generic, like
> AV_PKT_DATA_ANCILLARY or
> > > > >> > > > > something. It's apparently just packet data which
> somehow
> > > couldn't go
> > > > >> > > > > into the packet data.
> > > > >> > >
> > > > >> > >
> > > > >> > > > I agree, a generic ancillary side data type sounds better.
> It
> > > would
> > > > >> > have to
> > > > >> > > > be handled the same way as mastering metadata (e.g. to
> allocate
> > > it
> > > > >> > you'd
> > > > >> > > > need to use a separate function), since the size of the
> data
> > > struct
> > > > >> > can't
> > > > >> > > > be part of the API if we intend to add fields later.
> > > > >> > > > Patrick, if you're okay with that you should submit a
> patch
> > > which bases
> > > > >> > > > such side data on libavutil/mastering_display_metadata.h/.c
>
> > > > >> > >
> > > > >> > > No problem for transmitting field flags through side data.
> But
> > > the given
> > > > >> > > example (libavutil/mastering_display_metadata.h/.c)
> attaches
> > > data to
> > > > >> > > AVFrame, not AVPacket, so I'm not sure where to place this
> > > separate
> > > > >> > > allocator function. Do you recommend to create a new
> > > > >> > > libavcodec/ancillary.c/h utility?
> > > > >> >
> > > > >> > The example you mentioned exists for AVPacket too (it's just
> not
> > > easy
> > > > >> > to see how it can end up in AVPacket, because no demuxer does
> that
> > > > >> > directly).
> > > > >> >
> > > > >> > Anyway, ancillary side data would just be an untyped byte
> array, so
> > > I
> > > > >> > don't think it needs any helpers. Just an addition to the
> packet
> > > side
> > > > >> > data enum (I think it's somewhere in avcodec.h).
> > > > >> > ___
> > > > >> > ffmpeg-devel mailing list
> > > > >> > ffmpeg-devel@ffmpeg.org
> > > > >> > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> > > > >> >
> > > > >>
> > > > >> I'd rather have

Re: [FFmpeg-devel] [PATCH v6 1/3] avcodec: add flags for packets with top/bottom field

[Rostislav Pehlivanov]

On 23 May 2018 at 20:01, wm4  wrote:

> On Wed, 23 May 2018 14:29:38 -0400 (EDT)
> Patrick Keroulas  wrote:
>
> > - Original Message -
> > > From: "wm4" 
> > > To: ffmpeg-devel@ffmpeg.org
> > > Sent: Wednesday, May 23, 2018 12:02:45 PM
> > > Subject: Re: [FFmpeg-devel] [PATCH v6 1/3] avcodec: add flags for
> packets with top/bottom field
> >
> > > On Wed, 23 May 2018 16:46:17 +0100
> > > Rostislav Pehlivanov  wrote:
> > >
> > >> On 23 May 2018 at 16:18, wm4  wrote:
> > >>
> > >> > On Tue, 22 May 2018 17:19:35 -0400 (EDT)
> > >> > Patrick Keroulas  wrote:
> > >> >
> > >> > > - Original Message -
> > >> > > > From: "Rostislav Pehlivanov" 
> > >> > > > To: "FFmpeg development discussions and patches" <
> > >> > ffmpeg-devel@ffmpeg.org>
> > >> > > > Sent: Friday, May 18, 2018 5:28:42 PM
> > >> > > > Subject: Re: [FFmpeg-devel] [PATCH v6 1/3] avcodec: add flags
> for
> > >> > packets with top/bottom field
> > >> > >
> > >> > > > On 18 May 2018 at 22:17, wm4  wrote:
> > >> > >
> > >> > >
> > >> > >
> > >> > > > > But I think a new side data type would be much saner. We
> could even
> > >> > > > > just make it something generic, like AV_PKT_DATA_ANCILLARY or
> > >> > > > > something. It's apparently just packet data which somehow
> couldn't go
> > >> > > > > into the packet data.
> > >> > >
> > >> > >
> > >> > > > I agree, a generic ancillary side data type sounds better. It
> would
> > >> > have to
> > >> > > > be handled the same way as mastering metadata (e.g. to allocate
> it
> > >> > you'd
> > >> > > > need to use a separate function), since the size of the data
> struct
> > >> > can't
> > >> > > > be part of the API if we intend to add fields later.
> > >> > > > Patrick, if you're okay with that you should submit a patch
> which bases
> > >> > > > such side data on libavutil/mastering_display_metadata.h/.c
> > >> > >
> > >> > > No problem for transmitting field flags through side data. But
> the given
> > >> > > example (libavutil/mastering_display_metadata.h/.c) attaches
> data to
> > >> > > AVFrame, not AVPacket, so I'm not sure where to place this
> separate
> > >> > > allocator function. Do you recommend to create a new
> > >> > > libavcodec/ancillary.c/h utility?
> > >> >
> > >> > The example you mentioned exists for AVPacket too (it's just not
> easy
> > >> > to see how it can end up in AVPacket, because no demuxer does that
> > >> > directly).
> > >> >
> > >> > Anyway, ancillary side data would just be an untyped byte array, so
> I
> > >> > don't think it needs any helpers. Just an addition to the packet
> side
> > >> > data enum (I think it's somewhere in avcodec.h).
> > >> > ___
> > >> > ffmpeg-devel mailing list
> > >> > ffmpeg-devel@ffmpeg.org
> > >> > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> > >> >
> > >>
> > >> I'd rather have it as a well defined typed array rather than a bunch
> of
> > >> bytes. Otherwise we'd start sending unknown side data info and users
> > >> wouldn't know what to do with it.
> > >
> > > Unless you're adding some meta object system for describing arbitrary
> > > types at runtime I don't know how you'd do that.
> >
> > Is that ok if I simply define a basic struct to hold the field?
> >
> > Any suggestion on where to insert the definition of this data and the
> > accessors in lavc? In a new source file?
>
> If you make it a struct, then make a new file in libavutil, with
> at least a helper to get the struct size (this is for ABI reasons, so
> we can extend the struct later). But then this side data would need a
> specific name, not a generic one like "ancillary".
>
> The display mastering thing is valid for both packets and frames, which
> might be confusing. The thing you add is needed for packets only.
>
> I'd prefer the "ancillary" name and making it just a flat byte array
> instead of a struct and something specific. The former would be like
> extradata, just per packet.
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>

A flat array would be useless and very codec specific (e.g. if you throw
that side data at one codec it would act in a different way than another
codec), a struct is the way to go here. I don't mind adding another untyped
data if there was a reason, but what we're trying to solve here is very
well defined - determine the field of each packet.

Patrick, like I said, use libavutil/mastering_display_metadata.c/h as a
template.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH v6 1/3] avcodec: add flags for packets with top/bottom field

[Rostislav Pehlivanov]

On 23 May 2018 at 16:18, wm4  wrote:

> On Tue, 22 May 2018 17:19:35 -0400 (EDT)
> Patrick Keroulas  wrote:
>
> > - Original Message -
> > > From: "Rostislav Pehlivanov" 
> > > To: "FFmpeg development discussions and patches" <
> ffmpeg-devel@ffmpeg.org>
> > > Sent: Friday, May 18, 2018 5:28:42 PM
> > > Subject: Re: [FFmpeg-devel] [PATCH v6 1/3] avcodec: add flags for
> packets with top/bottom field
> >
> > > On 18 May 2018 at 22:17, wm4  wrote:
> >
> >
> >
> > > > But I think a new side data type would be much saner. We could even
> > > > just make it something generic, like AV_PKT_DATA_ANCILLARY or
> > > > something. It's apparently just packet data which somehow couldn't go
> > > > into the packet data.
> >
> >
> > > I agree, a generic ancillary side data type sounds better. It would
> have to
> > > be handled the same way as mastering metadata (e.g. to allocate it
> you'd
> > > need to use a separate function), since the size of the data struct
> can't
> > > be part of the API if we intend to add fields later.
> > > Patrick, if you're okay with that you should submit a patch which bases
> > > such side data on libavutil/mastering_display_metadata.h/.c
> >
> > No problem for transmitting field flags through side data. But the given
> > example (libavutil/mastering_display_metadata.h/.c) attaches data to
> > AVFrame, not AVPacket, so I'm not sure where to place this separate
> > allocator function. Do you recommend to create a new
> > libavcodec/ancillary.c/h utility?
>
> The example you mentioned exists for AVPacket too (it's just not easy
> to see how it can end up in AVPacket, because no demuxer does that
> directly).
>
> Anyway, ancillary side data would just be an untyped byte array, so I
> don't think it needs any helpers. Just an addition to the packet side
> data enum (I think it's somewhere in avcodec.h).
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>

I'd rather have it as a well defined typed array rather than a bunch of
bytes. Otherwise we'd start sending unknown side data info and users
wouldn't know what to do with it.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH v4 4/8] lavfi: add common Vulkan filtering code

[Rostislav Pehlivanov]

This commit adds a common code for use in Vulkan filters. It attempts
to ease the burden of writing Vulkan image filtering to a minimum,
which is pretty much a requirement considering how verbose the API is.

It supports both compute and graphic pipelines and manages to abstract
the API to such a level there's no need to call any Vulkan functions
inside the init path of the code. Handling shader descriptors is probably
the bulk of the code, and despite the abstraction, it loses none of the
features for describing shader IO.

In order to produce linkable shaders, it depends on the libshaderc
library (and depends on the latest stable version of it). This allows
for greater performance and flexibility than static built-in shaders
and also eliminates the cumbersome process of interfacing with glslang
to compile GLSL to SPIR-V.

It's based off of the common opencl and provides similar interfaces for
filter pad init and config, with the addition that it also supports
in-place filtering.

Signed-off-by: Rostislav Pehlivanov 
---
 configure|   12 +-
 libavfilter/vulkan.c | 1190 ++
 libavfilter/vulkan.h |  223 
 3 files changed, 1423 insertions(+), 2 deletions(-)
 create mode 100644 libavfilter/vulkan.c
 create mode 100644 libavfilter/vulkan.h

diff --git a/configure b/configure
index 5f4407b753..abcfe32625 100755
--- a/configure
+++ b/configure
@@ -252,6 +252,7 @@ External library support:
   --enable-librsvg enable SVG rasterization via librsvg [no]
   --enable-librubberband   enable rubberband needed for rubberband filter [no]
   --enable-librtmp enable RTMP[E] support via librtmp [no]
+  --enable-libshaderc  enable GLSL->SPIRV compilation via libshaderc [no]
   --enable-libshineenable fixed-point MP3 encoding via libshine [no]
   --enable-libsmbclientenable Samba protocol via libsmbclient [no]
   --enable-libsnappy   enable Snappy compression, needed for hap encoding 
[no]
@@ -1707,6 +1708,7 @@ EXTERNAL_LIBRARY_LIST="
 libpulse
 librsvg
 librtmp
+libshaderc
 libshine
 libsmbclient
 libsnappy
@@ -2225,6 +2227,7 @@ HAVE_LIST="
 opencl_dxva2
 opencl_vaapi_beignet
 opencl_vaapi_intel_media
+shaderc_opt_perf
 vulkan_drm_mod
 perl
 pod2man
@@ -3456,12 +3459,12 @@ avcodec_select="null_bsf"
 avdevice_deps="avformat avcodec avutil"
 avdevice_suggest="libm"
 avfilter_deps="avutil"
-avfilter_suggest="libm"
+avfilter_suggest="libm libshaderc"
 avformat_deps="avcodec avutil"
 avformat_suggest="libm network zlib"
 avresample_deps="avutil"
 avresample_suggest="libm"
-avutil_suggest="clock_gettime ffnvcodec libm libdrm libmfx opencl user32 vaapi 
videotoolbox corefoundation corevideo coremedia bcrypt"
+avutil_suggest="clock_gettime ffnvcodec libm libdrm libmfx opencl vulkan 
user32 vaapi videotoolbox corefoundation corevideo coremedia bcrypt"
 postproc_deps="avutil gpl"
 postproc_suggest="libm"
 swresample_deps="avutil"
@@ -6050,6 +6053,7 @@ enabled libpulse  && require_pkg_config libpulse 
libpulse pulse/pulseaud
 enabled librsvg   && require_pkg_config librsvg librsvg-2.0 
librsvg-2.0/librsvg/rsvg.h rsvg_handle_render_cairo
 enabled librtmp   && require_pkg_config librtmp librtmp librtmp/rtmp.h 
RTMP_Socket
 enabled librubberband && require_pkg_config librubberband "rubberband >= 
1.8.1" rubberband/rubberband-c.h rubberband_new -lstdc++ && append 
librubberband_extralibs "-lstdc++"
+enabled libshaderc&& require libshaderc shaderc/shaderc.h 
shaderc_compiler_initialize -lshaderc_shared
 enabled libshine  && require_pkg_config libshine shine shine/layer3.h 
shine_encode_buffer
 enabled libsmbclient  && { check_pkg_config libsmbclient smbclient 
libsmbclient.h smbc_init ||
require libsmbclient libsmbclient.h smbc_init 
-lsmbclient; }
@@ -6355,6 +6359,10 @@ enabled crystalhd && check_lib crystalhd "stdint.h 
libcrystalhd/libcrystalhd_if.
 enabled vulkan &&
 require_pkg_config vulkan "vulkan >= 1.1.73" "vulkan/vulkan.h" 
vkCreateInstance
 
+if enabled_all vulkan libshaderc ; then
+check_cc shaderc_opt_perf shaderc/shaderc.h "int t = 
shaderc_optimization_level_performance"
+fi
+
 if enabled_all vulkan libdrm ; then
 check_cpp_condition vulkan_drm_mod vulkan/vulkan.h "defined 
VK_EXT_IMAGE_DRM_FORMAT_MODIFIER_EXTENSION_NAME"
 fi
diff --git a/libavfilter/vulkan.c b/libavfilter/vulkan.c
new file mode 100644
index 00..7954c6f665
--- /dev/null
+++ b/libavfilter/vulkan.c
@@ -0,0 +1,1190 @@
+/*
+ * Vulkan utilities
+ * Copyright (c) 2018 Rostislav Pehlivanov 
+ *
+ * 

[FFmpeg-devel] [PATCH v3 7/8] lavfi: add a Vulkan scale filter

[Rostislav Pehlivanov]

Can convert to RGB using very fast fixed-function conversions.

Signed-off-by: Rostislav Pehlivanov 
---
 configure |   1 +
 libavfilter/Makefile  |   1 +
 libavfilter/allfilters.c  |   1 +
 libavfilter/vf_scale_vulkan.c | 395 ++
 4 files changed, 398 insertions(+)
 create mode 100644 libavfilter/vf_scale_vulkan.c

diff --git a/configure b/configure
index eb81cc1ed5..3b29cd123a 100755
--- a/configure
+++ b/configure
@@ -3422,6 +3422,7 @@ zmq_filter_deps="libzmq"
 zoompan_filter_deps="swscale"
 zscale_filter_deps="libzimg const_nan"
 scale_vaapi_filter_deps="vaapi VAProcPipelineParameterBuffer"
+scale_vulkan_filter_deps="vulkan libshaderc"
 vpp_qsv_filter_deps="libmfx"
 vpp_qsv_filter_select="qsvvpp"
 
diff --git a/libavfilter/Makefile b/libavfilter/Makefile
index 976955959c..e8c5438c78 100644
--- a/libavfilter/Makefile
+++ b/libavfilter/Makefile
@@ -313,6 +313,7 @@ OBJS-$(CONFIG_SCALE_CUDA_FILTER) += 
vf_scale_cuda.o vf_scale_cuda.pt
 OBJS-$(CONFIG_SCALE_NPP_FILTER)  += vf_scale_npp.o scale.o
 OBJS-$(CONFIG_SCALE_QSV_FILTER)  += vf_scale_qsv.o
 OBJS-$(CONFIG_SCALE_VAAPI_FILTER)+= vf_scale_vaapi.o scale.o 
vaapi_vpp.o
+OBJS-$(CONFIG_SCALE_VULKAN_FILTER)   += vf_scale_vulkan.o scale.o 
vulkan.o
 OBJS-$(CONFIG_SCALE2REF_FILTER)  += vf_scale.o scale.o
 OBJS-$(CONFIG_SELECT_FILTER) += f_select.o
 OBJS-$(CONFIG_SELECTIVECOLOR_FILTER) += vf_selectivecolor.o
diff --git a/libavfilter/allfilters.c b/libavfilter/allfilters.c
index 7be81e4706..f9dce32f4d 100644
--- a/libavfilter/allfilters.c
+++ b/libavfilter/allfilters.c
@@ -304,6 +304,7 @@ extern AVFilter ff_vf_scale_cuda;
 extern AVFilter ff_vf_scale_npp;
 extern AVFilter ff_vf_scale_qsv;
 extern AVFilter ff_vf_scale_vaapi;
+extern AVFilter ff_vf_scale_vulkan;
 extern AVFilter ff_vf_scale2ref;
 extern AVFilter ff_vf_select;
 extern AVFilter ff_vf_selectivecolor;
diff --git a/libavfilter/vf_scale_vulkan.c b/libavfilter/vf_scale_vulkan.c
new file mode 100644
index 00..4a5647072d
--- /dev/null
+++ b/libavfilter/vf_scale_vulkan.c
@@ -0,0 +1,395 @@
+/*
+ * This file is part of FFmpeg.
+ *
+ * FFmpeg is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public
+ * License as published by the Free Software Foundation; either
+ * version 2.1 of the License, or (at your option) any later version.
+ *
+ * FFmpeg is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+ * Lesser General Public License for more details.
+ *
+ * You should have received a copy of the GNU Lesser General Public
+ * License along with FFmpeg; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA
+ */
+
+#include "libavutil/opt.h"
+#include "vulkan.h"
+#include "scale.h"
+#include "internal.h"
+
+enum ScalerFunc {
+F_BILINEAR = 0,
+F_NEAREST,
+
+F_NB,
+};
+
+typedef struct ScaleVulkanContext {
+VulkanFilterContext vkctx;
+
+int conv;
+int initialized;
+FFVkExecContext exec;
+const VulkanSampler *sampler;
+
+/* Shader updators, must be in the main filter struct */
+VkDescriptorImageInfo input_images[3];
+VkDescriptorImageInfo output_images[3];
+
+enum ScalerFunc scaler;
+char *output_format_string;
+char *w_expr;
+char *h_expr;
+} ScaleVulkanContext;
+
+static const char scale_bilinear[] = {
+C(0, void scale_bilinear(int idx, ivec2 pos)   
)
+C(0, { 
)
+C(1, const vec2 npos = (vec2(pos) + 0.5f) / 
imageSize(output_img[idx]);)
+C(1, imageStore(output_img[idx], pos, texture(input_img[idx], npos));  
)
+C(0, } 
)
+};
+
+static av_cold int init_filter(AVFilterContext *ctx, AVFrame *in)
+{
+int err;
+VkFilter sampler_mode;
+ScaleVulkanContext *s = ctx->priv;
+
+switch (s->scaler) {
+case F_NEAREST:
+sampler_mode = VK_FILTER_NEAREST;
+break;
+case F_BILINEAR:
+sampler_mode = VK_FILTER_LINEAR;
+break;
+};
+
+/* Create a sampler */
+s->sampler = ff_vk_init_sampler(ctx, s->conv ? in : NULL, 0, sampler_mode);
+if (!s->sampler)
+return AVERROR_EXTERNAL;
+
+{ /* Create the shader */
+SPIRVShader *shd = ff_vk_init_shader(ctx, "scale_compute",
+ VK_SHADER_STAGE_COMPUTE_BIT);
+ff_vk_set_compute_shader_sizes(ctx, shd, (int [3]){ 16, 16, 1 });
+
+VulkanDescriptorSetBinding desc_i[2] 

[FFmpeg-devel] [PATCH v3 8/8] lavfi: add a Vulkan overlay filter

[Rostislav Pehlivanov]

Could be done in-plane with the main image but framesync segfaults.

Signed-off-by: Rostislav Pehlivanov 
---
 configure   |   1 +
 libavfilter/Makefile|   1 +
 libavfilter/allfilters.c|   1 +
 libavfilter/vf_overlay_vulkan.c | 461 
 4 files changed, 464 insertions(+)
 create mode 100644 libavfilter/vf_overlay_vulkan.c

diff --git a/configure b/configure
index 3b29cd123a..8806a8 100755
--- a/configure
+++ b/configure
@@ -3365,6 +3365,7 @@ ocr_filter_deps="libtesseract"
 ocv_filter_deps="libopencv"
 openclsrc_filter_deps="opencl"
 overlay_opencl_filter_deps="opencl"
+overlay_vulkan_filter_deps="vulkan libshaderc"
 overlay_qsv_filter_deps="libmfx"
 overlay_qsv_filter_select="qsvvpp"
 owdenoise_filter_deps="gpl"
diff --git a/libavfilter/Makefile b/libavfilter/Makefile
index e8c5438c78..bfbd679a44 100644
--- a/libavfilter/Makefile
+++ b/libavfilter/Makefile
@@ -276,6 +276,7 @@ OBJS-$(CONFIG_OSCILLOSCOPE_FILTER)   += 
vf_datascope.o
 OBJS-$(CONFIG_OVERLAY_FILTER)+= vf_overlay.o framesync.o
 OBJS-$(CONFIG_OVERLAY_OPENCL_FILTER) += vf_overlay_opencl.o opencl.o \
 opencl/overlay.o framesync.o
+OBJS-$(CONFIG_OVERLAY_VULKAN_FILTER) += vf_overlay_vulkan.o
 OBJS-$(CONFIG_OVERLAY_QSV_FILTER)+= vf_overlay_qsv.o framesync.o
 OBJS-$(CONFIG_OWDENOISE_FILTER)  += vf_owdenoise.o
 OBJS-$(CONFIG_PAD_FILTER)+= vf_pad.o
diff --git a/libavfilter/allfilters.c b/libavfilter/allfilters.c
index f9dce32f4d..85383f234a 100644
--- a/libavfilter/allfilters.c
+++ b/libavfilter/allfilters.c
@@ -267,6 +267,7 @@ extern AVFilter ff_vf_ocv;
 extern AVFilter ff_vf_oscilloscope;
 extern AVFilter ff_vf_overlay;
 extern AVFilter ff_vf_overlay_opencl;
+extern AVFilter ff_vf_overlay_vulkan;
 extern AVFilter ff_vf_overlay_qsv;
 extern AVFilter ff_vf_owdenoise;
 extern AVFilter ff_vf_pad;
diff --git a/libavfilter/vf_overlay_vulkan.c b/libavfilter/vf_overlay_vulkan.c
new file mode 100644
index 00..a7d8cc3cf2
--- /dev/null
+++ b/libavfilter/vf_overlay_vulkan.c
@@ -0,0 +1,461 @@
+/*
+ * This file is part of FFmpeg.
+ *
+ * FFmpeg is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public
+ * License as published by the Free Software Foundation; either
+ * version 2.1 of the License, or (at your option) any later version.
+ *
+ * FFmpeg is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+ * Lesser General Public License for more details.
+ *
+ * You should have received a copy of the GNU Lesser General Public
+ * License along with FFmpeg; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA
+ */
+
+#include "libavutil/opt.h"
+#include "vulkan.h"
+#include "internal.h"
+#include "framesync.h"
+
+typedef struct OverlayVulkanContext {
+VulkanFilterContext vkctx;
+
+int initialized;
+FFVkExecContext exec;
+FFFrameSync fs;
+FFVkBuffer params_buf;
+
+/* Shader updators, must be in the main filter struct */
+VkDescriptorImageInfo main_images[3];
+VkDescriptorImageInfo overlay_images[3];
+VkDescriptorImageInfo output_images[3];
+VkDescriptorBufferInfo params_desc;
+
+int overlay_x;
+int overlay_y;
+} OverlayVulkanContext;
+
+static const char overlay_noalpha[] = {
+C(0, void overlay_noalpha(int i, ivec2 pos)
)
+C(0, { 
)
+C(1, ivec2 overlay_size = imageSize(overlay_img[i]);   
)
+C(1, if ((o_offset[i].x <= pos.x) && (o_offset[i].y <= pos.y) &&
+ (pos.x < (o_offset[i].x + overlay_size.x)) &&
+ (pos.y < (o_offset[i].y + overlay_size.y))) { 
)
+C(2, vec4 res = imageLoad(overlay_img[i], pos - o_offset[i]);  
)
+C(2, imageStore(output_img[i], pos, res);  
)
+C(1, } else {  
)
+C(2, vec4 res = imageLoad(main_img[i], pos);   
)
+C(2, imageStore(output_img[i], pos, res);  
)
+C(1, } 
)
+C(0, } 
)
+};
+
+static av_cold int init_filter(AVFilterContext *ctx)
+{
+int err;
+OverlayVulkanContext *s = ctx->priv;
+
+{ /* Create t

[FFmpeg-devel] [PATCH v3 4/8] lavfi: add common Vulkan filtering code

[Rostislav Pehlivanov]

This commit adds a common code for use in Vulkan filters. It attempts
to ease the burden of writing Vulkan image filtering to a minimum,
which is pretty much a requirement considering how verbose the API is.

It supports both compute and graphic pipelines and manages to abstract
the API to such a level there's no need to call any Vulkan functions
inside the init path of the code. Handling shader descriptors is probably
the bulk of the code, and despite the abstraction, it loses none of the
features for describing shader IO.

In order to produce linkable shaders, it depends on the libshaderc
library (and depends on the latest stable version of it). This allows
for greater performance and flexibility than static built-in shaders
and also eliminates the cumbersome process of interfacing with glslang
to compile GLSL to SPIR-V.

It's based off of the common opencl and provides similar interfaces for
filter pad init and config, with the addition that it also supports
in-place filtering.

Signed-off-by: Rostislav Pehlivanov 
---
 configure|   10 +-
 libavfilter/vulkan.c | 1186 ++
 libavfilter/vulkan.h |  223 
 3 files changed, 1418 insertions(+), 1 deletion(-)
 create mode 100644 libavfilter/vulkan.c
 create mode 100644 libavfilter/vulkan.h

diff --git a/configure b/configure
index 5f4407b753..52c1e7a6e8 100755
--- a/configure
+++ b/configure
@@ -252,6 +252,7 @@ External library support:
   --enable-librsvg enable SVG rasterization via librsvg [no]
   --enable-librubberband   enable rubberband needed for rubberband filter [no]
   --enable-librtmp enable RTMP[E] support via librtmp [no]
+  --enable-libshaderc  enable GLSL->SPIRV compilation via libshaderc [no]
   --enable-libshineenable fixed-point MP3 encoding via libshine [no]
   --enable-libsmbclientenable Samba protocol via libsmbclient [no]
   --enable-libsnappy   enable Snappy compression, needed for hap encoding 
[no]
@@ -1707,6 +1708,7 @@ EXTERNAL_LIBRARY_LIST="
 libpulse
 librsvg
 librtmp
+libshaderc
 libshine
 libsmbclient
 libsnappy
@@ -2225,6 +2227,7 @@ HAVE_LIST="
 opencl_dxva2
 opencl_vaapi_beignet
 opencl_vaapi_intel_media
+shaderc_opt_perf
 vulkan_drm_mod
 perl
 pod2man
@@ -3461,7 +3464,7 @@ avformat_deps="avcodec avutil"
 avformat_suggest="libm network zlib"
 avresample_deps="avutil"
 avresample_suggest="libm"
-avutil_suggest="clock_gettime ffnvcodec libm libdrm libmfx opencl user32 vaapi 
videotoolbox corefoundation corevideo coremedia bcrypt"
+avutil_suggest="clock_gettime ffnvcodec libm libdrm libmfx opencl vulkan 
libshaderc user32 vaapi videotoolbox corefoundation corevideo coremedia bcrypt"
 postproc_deps="avutil gpl"
 postproc_suggest="libm"
 swresample_deps="avutil"
@@ -6050,6 +6053,7 @@ enabled libpulse  && require_pkg_config libpulse 
libpulse pulse/pulseaud
 enabled librsvg   && require_pkg_config librsvg librsvg-2.0 
librsvg-2.0/librsvg/rsvg.h rsvg_handle_render_cairo
 enabled librtmp   && require_pkg_config librtmp librtmp librtmp/rtmp.h 
RTMP_Socket
 enabled librubberband && require_pkg_config librubberband "rubberband >= 
1.8.1" rubberband/rubberband-c.h rubberband_new -lstdc++ && append 
librubberband_extralibs "-lstdc++"
+enabled libshaderc&& require libshaderc shaderc/shaderc.h 
shaderc_compiler_initialize -lshaderc_shared
 enabled libshine  && require_pkg_config libshine shine shine/layer3.h 
shine_encode_buffer
 enabled libsmbclient  && { check_pkg_config libsmbclient smbclient 
libsmbclient.h smbc_init ||
require libsmbclient libsmbclient.h smbc_init 
-lsmbclient; }
@@ -6355,6 +6359,10 @@ enabled crystalhd && check_lib crystalhd "stdint.h 
libcrystalhd/libcrystalhd_if.
 enabled vulkan &&
 require_pkg_config vulkan "vulkan >= 1.1.73" "vulkan/vulkan.h" 
vkCreateInstance
 
+if enabled_all vulkan libshaderc ; then
+check_cc shaderc_opt_perf shaderc/shaderc.h "int t = 
shaderc_optimization_level_performance"
+fi
+
 if enabled_all vulkan libdrm ; then
 check_cpp_condition vulkan_drm_mod vulkan/vulkan.h "defined 
VK_EXT_IMAGE_DRM_FORMAT_MODIFIER_EXTENSION_NAME"
 fi
diff --git a/libavfilter/vulkan.c b/libavfilter/vulkan.c
new file mode 100644
index 00..1df3b7a1f2
--- /dev/null
+++ b/libavfilter/vulkan.c
@@ -0,0 +1,1186 @@
+/*
+ * Vulkan utilities
+ * Copyright (c) 2018 Rostislav Pehlivanov 
+ *
+ * This file is part of FFmpeg.
+ *
+ * FFmpeg is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public
+ * License as published by the Free Software Foundation; either
+ * versi

[FFmpeg-devel] [PATCH v3 6/8] lavfi: add a Vulkan chromatic aberration filter

[Rostislav Pehlivanov]

It tries to do something similar to it with YUV images, but RGB images
are done properly.

Signed-off-by: Rostislav Pehlivanov 
---
 configure   |   1 +
 libavfilter/Makefile|   1 +
 libavfilter/allfilters.c|   1 +
 libavfilter/vf_chromaticaberration_vulkan.c | 342 
 4 files changed, 345 insertions(+)
 create mode 100644 libavfilter/vf_chromaticaberration_vulkan.c

diff --git a/configure b/configure
index c34a48b2bc..eb81cc1ed5 100755
--- a/configure
+++ b/configure
@@ -3313,6 +3313,7 @@ azmq_filter_deps="libzmq"
 blackframe_filter_deps="gpl"
 boxblur_filter_deps="gpl"
 bs2b_filter_deps="libbs2b"
+chromaticaberration_vulkan_filter_deps="vulkan libshaderc"
 colormatrix_filter_deps="gpl"
 convolution_opencl_filter_deps="opencl"
 convolve_filter_deps="avcodec"
diff --git a/libavfilter/Makefile b/libavfilter/Makefile
index fd8cf8c13c..976955959c 100644
--- a/libavfilter/Makefile
+++ b/libavfilter/Makefile
@@ -156,6 +156,7 @@ OBJS-$(CONFIG_BLEND_FILTER)  += vf_blend.o 
framesync.o
 OBJS-$(CONFIG_BOXBLUR_FILTER)+= vf_boxblur.o
 OBJS-$(CONFIG_BWDIF_FILTER)  += vf_bwdif.o
 OBJS-$(CONFIG_CHROMAKEY_FILTER)  += vf_chromakey.o
+OBJS-$(CONFIG_CHROMATICABERRATION_VULKAN_FILTER) += 
vf_chromaticaberration_vulkan.o vulkan.o
 OBJS-$(CONFIG_CIESCOPE_FILTER)   += vf_ciescope.o
 OBJS-$(CONFIG_CODECVIEW_FILTER)  += vf_codecview.o
 OBJS-$(CONFIG_COLORBALANCE_FILTER)   += vf_colorbalance.o
diff --git a/libavfilter/allfilters.c b/libavfilter/allfilters.c
index c53cb2154e..7be81e4706 100644
--- a/libavfilter/allfilters.c
+++ b/libavfilter/allfilters.c
@@ -149,6 +149,7 @@ extern AVFilter ff_vf_blend;
 extern AVFilter ff_vf_boxblur;
 extern AVFilter ff_vf_bwdif;
 extern AVFilter ff_vf_chromakey;
+extern AVFilter ff_vf_chromaticaberration_vulkan;
 extern AVFilter ff_vf_ciescope;
 extern AVFilter ff_vf_codecview;
 extern AVFilter ff_vf_colorbalance;
diff --git a/libavfilter/vf_chromaticaberration_vulkan.c 
b/libavfilter/vf_chromaticaberration_vulkan.c
new file mode 100644
index 00..1d1aeb95a0
--- /dev/null
+++ b/libavfilter/vf_chromaticaberration_vulkan.c
@@ -0,0 +1,342 @@
+/*
+ * This file is part of FFmpeg.
+ *
+ * FFmpeg is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public
+ * License as published by the Free Software Foundation; either
+ * version 2.1 of the License, or (at your option) any later version.
+ *
+ * FFmpeg is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+ * Lesser General Public License for more details.
+ *
+ * You should have received a copy of the GNU Lesser General Public
+ * License along with FFmpeg; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA
+ */
+
+#include "libavutil/opt.h"
+#include "vulkan.h"
+#include "internal.h"
+
+typedef struct ChromaticAberrationVulkanContext {
+VulkanFilterContext vkctx;
+
+int initialized;
+FFVkExecContext exec;
+
+/* Shader updators, must be in the main filter struct */
+VkDescriptorImageInfo input_images[3];
+VkDescriptorImageInfo output_images[3];
+
+float dist_x;
+float dist_y;
+} ChromaticAberrationVulkanContext;
+
+static const char distort_chroma_kernel[] = {
+C(0, void distort_rgb(ivec2 size, ivec2 pos)   
)
+C(0, { 
)
+C(1, const vec2 p = ((vec2(pos)/vec2(size)) - 0.5f)*2.0f;  
)
+C(1, const vec2 o = p * (FILTER_DIST - 1.0f);  
)
+C(0,   
)
+C(1, vec4 res; 
)
+C(1, res.r = texture(input_img[0], ((p - o)/2.0f) + 0.5f).r;   
)
+C(1, res.g = texture(input_img[0], ((p)/2.0f) + 0.5f).g;   
)
+C(1, res.b = texture(input_img[0], ((p + o)/2.0f) + 0.5f).b;   
)
+C(1, res.a = texture(input_img[0], ((p)/2.0f) + 0.5f).a;   
)
+C(1, imageStore(output_img[0], pos, res);  
)
+C(0, } 
)
+C(0,   
)
+C(0, void distort_chroma(int idx, ivec2 size, ivec2 pos)   
)
+C(0, { 
)
+C(1, vec2 p = ((vec2(pos)/vec2(size)) - 0.5f)*2.0f;
)
+C(1, 

[FFmpeg-devel] [PATCH v3 5/8] lavfi: add a Vulkan avgblur filter

[Rostislav Pehlivanov]

Signed-off-by: Rostislav Pehlivanov 
---
 configure   |   1 +
 libavfilter/Makefile|   1 +
 libavfilter/allfilters.c|   1 +
 libavfilter/vf_avgblur_vulkan.c | 343 
 4 files changed, 346 insertions(+)
 create mode 100644 libavfilter/vf_avgblur_vulkan.c

diff --git a/configure b/configure
index 52c1e7a6e8..c34a48b2bc 100755
--- a/configure
+++ b/configure
@@ -3308,6 +3308,7 @@ ass_filter_deps="libass"
 atempo_filter_deps="avcodec"
 atempo_filter_select="rdft"
 avgblur_opencl_filter_deps="opencl"
+avgblur_vulkan_filter_deps="vulkan libshaderc"
 azmq_filter_deps="libzmq"
 blackframe_filter_deps="gpl"
 boxblur_filter_deps="gpl"
diff --git a/libavfilter/Makefile b/libavfilter/Makefile
index c68ef05fdc..fd8cf8c13c 100644
--- a/libavfilter/Makefile
+++ b/libavfilter/Makefile
@@ -146,6 +146,7 @@ OBJS-$(CONFIG_ATADENOISE_FILTER) += 
vf_atadenoise.o
 OBJS-$(CONFIG_AVGBLUR_FILTER)+= vf_avgblur.o
 OBJS-$(CONFIG_AVGBLUR_OPENCL_FILTER) += vf_avgblur_opencl.o opencl.o \
 opencl/avgblur.o
+OBJS-$(CONFIG_AVGBLUR_VULKAN_FILTER) += vf_avgblur_vulkan.o vulkan.o
 OBJS-$(CONFIG_BBOX_FILTER)   += bbox.o vf_bbox.o
 OBJS-$(CONFIG_BENCH_FILTER)  += f_bench.o
 OBJS-$(CONFIG_BITPLANENOISE_FILTER)  += vf_bitplanenoise.o
diff --git a/libavfilter/allfilters.c b/libavfilter/allfilters.c
index b44093d21b..c53cb2154e 100644
--- a/libavfilter/allfilters.c
+++ b/libavfilter/allfilters.c
@@ -139,6 +139,7 @@ extern AVFilter ff_vf_ass;
 extern AVFilter ff_vf_atadenoise;
 extern AVFilter ff_vf_avgblur;
 extern AVFilter ff_vf_avgblur_opencl;
+extern AVFilter ff_vf_avgblur_vulkan;
 extern AVFilter ff_vf_bbox;
 extern AVFilter ff_vf_bench;
 extern AVFilter ff_vf_bitplanenoise;
diff --git a/libavfilter/vf_avgblur_vulkan.c b/libavfilter/vf_avgblur_vulkan.c
new file mode 100644
index 00..5b89ae0718
--- /dev/null
+++ b/libavfilter/vf_avgblur_vulkan.c
@@ -0,0 +1,343 @@
+/*
+ * This file is part of FFmpeg.
+ *
+ * FFmpeg is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public
+ * License as published by the Free Software Foundation; either
+ * version 2.1 of the License, or (at your option) any later version.
+ *
+ * FFmpeg is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+ * Lesser General Public License for more details.
+ *
+ * You should have received a copy of the GNU Lesser General Public
+ * License along with FFmpeg; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA
+ */
+
+#include "libavutil/opt.h"
+#include "vulkan.h"
+#include "internal.h"
+
+typedef struct AvgBlurVulkanContext {
+VulkanFilterContext vkctx;
+
+int initialized;
+FFVkExecContext exec;
+
+/* Shader updators, must be in the main filter struct */
+VkDescriptorImageInfo input_images[3];
+VkDescriptorImageInfo output_images[3];
+
+int size_x;
+int size_y;
+int planes;
+} AvgBlurVulkanContext;
+
+static const char blur_kernel[] = {
+C(0, #define CACHE_SIZE (ivec2(gl_WorkGroupSize) + FILTER_RADIUS*2)
)
+C(0, shared vec4 cache[AREA(CACHE_SIZE)];  
)
+C(0,   
)
+C(0, void blur_kernel(int idx, ivec2 pos)  
)
+C(0, { 
)
+C(1, ivec2 d;  
)
+C(1, const ivec2 s = CACHE_SIZE;   
)
+C(1, const ivec2 w = ivec2(gl_WorkGroupSize);  
)
+C(1, const ivec2 l = ivec2(gl_LocalInvocationID.xy);   
)
+C(1,   
)
+C(1, for (d.y = l.y; d.y < s.y; d.y += w.y) {  
)
+C(2, for (d.x = l.x; d.x < s.x; d.x += w.x) {  
)
+C(3, const ivec2 np = pos + d - l - FILTER_RADIUS; 
)
+C(3, cache[d.y*s.x + d.x] = imageLoad(input_img[idx], np); 
)
+C(2, } 
)
+C(1, } 
)
+C(0,   
)
+C(1, barrier();
)
+C(0,  

[FFmpeg-devel] [PATCH v3 1/8] hwcontext_internal: add ff_hwframe_map_replace

[Rostislav Pehlivanov]

Used to fix unmapping when no direct interop exists between APIs.

Signed-off-by: Rostislav Pehlivanov 
---
 libavutil/hwcontext.c  | 7 +++
 libavutil/hwcontext_internal.h | 5 +
 2 files changed, 12 insertions(+)

diff --git a/libavutil/hwcontext.c b/libavutil/hwcontext.c
index 745016ed7e..f1e404ab20 100644
--- a/libavutil/hwcontext.c
+++ b/libavutil/hwcontext.c
@@ -870,3 +870,10 @@ fail:
 av_buffer_unref(&dst_ref);
 return ret;
 }
+
+int ff_hwframe_map_replace(AVFrame *dst, const AVFrame *src)
+{
+HWMapDescriptor *hwmap = (HWMapDescriptor*)dst->buf[0]->data;
+av_frame_unref(hwmap->source);
+return av_frame_ref(hwmap->source, src);
+}
diff --git a/libavutil/hwcontext_internal.h b/libavutil/hwcontext_internal.h
index 332062ddaa..77dc47ddd6 100644
--- a/libavutil/hwcontext_internal.h
+++ b/libavutil/hwcontext_internal.h
@@ -156,6 +156,11 @@ int ff_hwframe_map_create(AVBufferRef *hwframe_ref,
 HWMapDescriptor *hwmap),
   void *priv);
 
+/**
+ * Replace the current hwmap of dst with the one from src, used for indirect
+ * mappings like VAAPI->(DRM)->OpenCL/Vulkan where a direct interop is missing
+ */
+int ff_hwframe_map_replace(AVFrame *dst, const AVFrame *src);
 
 extern const HWContextType ff_hwcontext_type_cuda;
 extern const HWContextType ff_hwcontext_type_d3d11va;
-- 
2.17.0

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

[FFmpeg-devel] [PATCH v3 2/8] hwcontext_opencl: use ff_hwframe_map_replace()

[Rostislav Pehlivanov]

Signed-off-by: Rostislav Pehlivanov 
---
 libavutil/hwcontext_opencl.c | 5 +
 1 file changed, 1 insertion(+), 4 deletions(-)

diff --git a/libavutil/hwcontext_opencl.c b/libavutil/hwcontext_opencl.c
index 43b5c5ae0c..1d18da37bf 100644
--- a/libavutil/hwcontext_opencl.c
+++ b/libavutil/hwcontext_opencl.c
@@ -2171,10 +2171,7 @@ static int opencl_map_from_vaapi(AVHWFramesContext 
*dst_fc,
 if (err < 0)
 goto fail;
 
-// Adjust the map descriptor so that unmap works correctly.
-hwmap = (HWMapDescriptor*)dst->buf[0]->data;
-av_frame_unref(hwmap->source);
-err = av_frame_ref(hwmap->source, src);
+err = ff_hwframe_map_replace(dst, src);
 
 fail:
 av_frame_free(&tmp);
-- 
2.17.0

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

[FFmpeg-devel] [PATCH v3 3/8] lavu: add a Vulkan hwcontext

[Rostislav Pehlivanov]

This commit adds a Vulkan hwcontext, currently capable of mapping DRM and
VAAPI frames but additional functionality can be added later to support
importing of D3D11 surfaces as well as exporting to various other APIs.

This context requires the newest stable version of the Vulkan API,
and once the new extension for DRM surfaces makes it in will also require
it (in order to properly and fully import them).

It makes use of every part of the Vulkan spec in order to ensure fastest
possible uploading, downloading and mapping of frames. On AMD, it will
also make use of mapping host memory frames in order to upload
very efficiently and with minimal CPU to hardware.

To be useful for non-RGB images an implementation with the YUV images
extension is needed. All current implementations support that with the
exception of AMD, though support is coming soon for Mesa.

Signed-off-by: Rostislav Pehlivanov 
---
 configure  |   10 +
 doc/APIchanges |3 +
 libavutil/Makefile |3 +
 libavutil/hwcontext.c  |4 +
 libavutil/hwcontext.h  |1 +
 libavutil/hwcontext_internal.h |1 +
 libavutil/hwcontext_vulkan.c   | 2013 
 libavutil/hwcontext_vulkan.h   |  133 +++
 libavutil/pixdesc.c|4 +
 libavutil/pixfmt.h |4 +
 libavutil/version.h|4 +-
 11 files changed, 2178 insertions(+), 2 deletions(-)
 create mode 100644 libavutil/hwcontext_vulkan.c
 create mode 100644 libavutil/hwcontext_vulkan.h

diff --git a/configure b/configure
index 09ff0c55e2..5f4407b753 100755
--- a/configure
+++ b/configure
@@ -300,6 +300,7 @@ External library support:
   --enable-opengl  enable OpenGL rendering [no]
   --enable-openssl enable openssl, needed for https support
if gnutls, libtls or mbedtls is not used [no]
+  --enable-vulkan  enable Vulkan code [no]
   --disable-sndio  disable sndio support [autodetect]
   --disable-schannel   disable SChannel SSP, needed for TLS support on
Windows if openssl and gnutls are not used 
[autodetect]
@@ -1767,6 +1768,7 @@ HWACCEL_LIBRARY_LIST="
 mmal
 omx
 opencl
+vulkan
 "
 
 DOCUMENT_LIST="
@@ -2223,6 +2225,7 @@ HAVE_LIST="
 opencl_dxva2
 opencl_vaapi_beignet
 opencl_vaapi_intel_media
+vulkan_drm_mod
 perl
 pod2man
 texi2html
@@ -6349,6 +6352,13 @@ enabled vdpau &&
 
 enabled crystalhd && check_lib crystalhd "stdint.h 
libcrystalhd/libcrystalhd_if.h" DtsCrystalHDVersion -lcrystalhd
 
+enabled vulkan &&
+require_pkg_config vulkan "vulkan >= 1.1.73" "vulkan/vulkan.h" 
vkCreateInstance
+
+if enabled_all vulkan libdrm ; then
+check_cpp_condition vulkan_drm_mod vulkan/vulkan.h "defined 
VK_EXT_IMAGE_DRM_FORMAT_MODIFIER_EXTENSION_NAME"
+fi
+
 if enabled x86; then
 case $target_os in
 mingw32*|mingw64*|win32|win64|linux|cygwin*)
diff --git a/doc/APIchanges b/doc/APIchanges
index efe15ba4e0..1b37f58ca7 100644
--- a/doc/APIchanges
+++ b/doc/APIchanges
@@ -15,6 +15,9 @@ libavutil: 2017-10-21
 
 API changes, most recent first:
 
+2018-04-xx - xx - lavu 56.19.100 - hwcontext.h
+  Add AV_HWDEVICE_TYPE_VULKAN and implementation.
+
 2018-05-xx - xx - lavf 58.15.100 - avformat.h
   Add pmt_version field to AVProgram
 
diff --git a/libavutil/Makefile b/libavutil/Makefile
index d0632f16a6..9fb32bc5e2 100644
--- a/libavutil/Makefile
+++ b/libavutil/Makefile
@@ -42,6 +42,7 @@ HEADERS = adler32.h   
  \
   hwcontext_vaapi.h \
   hwcontext_videotoolbox.h  \
   hwcontext_vdpau.h \
+  hwcontext_vulkan.h\
   imgutils.h\
   intfloat.h\
   intreadwrite.h\
@@ -168,6 +169,7 @@ OBJS-$(CONFIG_QSV)  += hwcontext_qsv.o
 OBJS-$(CONFIG_VAAPI)+= hwcontext_vaapi.o
 OBJS-$(CONFIG_VIDEOTOOLBOX) += hwcontext_videotoolbox.o
 OBJS-$(CONFIG_VDPAU)+= hwcontext_vdpau.o
+OBJS-$(CONFIG_VULKAN)   += hwcontext_vulkan.o
 
 OBJS += $(COMPAT_OBJS:%=../compat/%)
 
@@ -183,6 +185,7 @@ SKIPHEADERS-$(CONFIG_OPENCL)   += hwcontext_opencl.h
 SKIPHEADERS-$(CONFIG_VAAPI)+= hwcontext_vaapi.h
 SKIPHEADERS-$(CONFIG_VIDEOTOOLBOX) += hwcontext_videotoolbox.h
 SKIPHEADERS-$(CONFIG_VDPAU)+= hwcontext_vdpau.h
+SKIPHEADERS-$(CONFIG_VULKAN)   += hwcontext_vulkan.h
 
 TES

[FFmpeg-devel] [PATCH v3 0/8] Vulkan hwcontext and filtering

[Rostislav Pehlivanov]

This is pretty much finished.

Rostislav Pehlivanov (8):
  hwcontext_internal: add ff_hwframe_map_replace
  hwcontext_opencl: use ff_hwframe_map_replace()
  lavu: add a Vulkan hwcontext
  lavfi: add common Vulkan filtering code
  lavfi: add a Vulkan avgblur filter
  lavfi: add a Vulkan chromatic aberration filter
  lavfi: add a Vulkan scale filter
  lavfi: add a Vulkan overlay filter

 configure   |   24 +-
 doc/APIchanges  |3 +
 libavfilter/Makefile|4 +
 libavfilter/allfilters.c|4 +
 libavfilter/vf_avgblur_vulkan.c |  343 
 libavfilter/vf_chromaticaberration_vulkan.c |  342 
 libavfilter/vf_overlay_vulkan.c |  461 +
 libavfilter/vf_scale_vulkan.c   |  395 
 libavfilter/vulkan.c| 1186 +++
 libavfilter/vulkan.h|  223 ++
 libavutil/Makefile  |3 +
 libavutil/hwcontext.c   |   11 +
 libavutil/hwcontext.h   |1 +
 libavutil/hwcontext_internal.h  |6 +
 libavutil/hwcontext_opencl.c|5 +-
 libavutil/hwcontext_vulkan.c| 2013 +++
 libavutil/hwcontext_vulkan.h|  133 ++
 libavutil/pixdesc.c |4 +
 libavutil/pixfmt.h  |4 +
 libavutil/version.h |4 +-
 20 files changed, 5162 insertions(+), 7 deletions(-)
 create mode 100644 libavfilter/vf_avgblur_vulkan.c
 create mode 100644 libavfilter/vf_chromaticaberration_vulkan.c
 create mode 100644 libavfilter/vf_overlay_vulkan.c
 create mode 100644 libavfilter/vf_scale_vulkan.c
 create mode 100644 libavfilter/vulkan.c
 create mode 100644 libavfilter/vulkan.h
 create mode 100644 libavutil/hwcontext_vulkan.c
 create mode 100644 libavutil/hwcontext_vulkan.h

-- 
2.17.0

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

Re: [FFmpeg-devel] [PATCH] avcodec/avformat: Add Camera Motion Metadata support

[Rostislav Pehlivanov]

On 21 May 2018 at 19:52, Erik Ackermann  wrote:

> Spec: https://developers.google.com/streetview/publish/camm-spec
>
> The Lenovo Mirage camera launched recently and outputs this metadata track
> in its videos.
>
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
>
This should be outputted as side data rather than as a separate stream, if
possible, even if the demuxer needs hacks.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel