Re: [FFmpeg-devel] [PATCH 05/10] lavf/dashenc: don't call flush_init_segment before avformat_write_header

[Jeyapal, Karthick]

On 3/14/18 11:54 AM, Rodger Combs wrote:
> Fixes crash when muxing MKV-in-DASH
> ---
>  libavformat/dashenc.c | 10 +++---
>  1 file changed, 3 insertions(+), 7 deletions(-)
>
> diff --git a/libavformat/dashenc.c b/libavformat/dashenc.c
> index 5689aef811..63ff827583 100644
> --- a/libavformat/dashenc.c
> +++ b/libavformat/dashenc.c
> @@ -985,13 +985,6 @@ static int dash_init(AVFormatContext *s)
>  
>  av_log(s, AV_LOG_VERBOSE, "Representation %d init segment will be 
> written to: %s\n", i, filename);
>  
> -// Flush init segment
> -// except for mp4, since delay_moov is set and the init segment
> -// is then flushed after the first packets
> -if (strcmp(os->format_name, "mp4")) {
> -flush_init_segment(s, os);
> -}
> -
>  s->streams[i]->time_base = st->time_base;
>  // If the muxer wants to shift timestamps, request to have them 
> shifted
>  // already before being handed to this muxer, so we don't have 
> mismatches
> @@ -1032,6 +1025,9 @@ static int dash_write_header(AVFormatContext *s)
>  OutputStream *os = &c->streams[i];
>  if ((ret = avformat_write_header(os->ctx, NULL)) < 0)
>  return ret;
> +
> +if ((ret = flush_init_segment(s, os)) < 0)
> +return ret;
I am fine with moving this here. But you have removed the strcmp for mp4 files.
Have you analyzed the impact of this change for mp4 files. Looks like something 
might break for mp4 files.
I would be more comfortable, if the strcmp and its related comment is also 
moved here.
>  }
>  ret = write_manifest(s, 0);
>  if (!ret)



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

Re: [FFmpeg-devel] [PATCH 04/10] lavf/dashenc: remove unneeded call to dash_free

[Jeyapal, Karthick]

On 3/14/18 11:54 AM, Rodger Combs wrote:
> ---
>  libavformat/dashenc.c | 4 +---
>  1 file changed, 1 insertion(+), 3 deletions(-)
>
> diff --git a/libavformat/dashenc.c b/libavformat/dashenc.c
> index 79d63e52d4..5689aef811 100644
> --- a/libavformat/dashenc.c
> +++ b/libavformat/dashenc.c
> @@ -1030,10 +1030,8 @@ static int dash_write_header(AVFormatContext *s)
>  int i, ret;
>  for (i = 0; i < s->nb_streams; i++) {
>  OutputStream *os = &c->streams[i];
> -if ((ret = avformat_write_header(os->ctx, NULL)) < 0) {
> -dash_free(s);
> +if ((ret = avformat_write_header(os->ctx, NULL)) < 0)
>  return ret;
> -}
>  }
>  ret = write_manifest(s, 0);
>  if (!ret)

LGTM. Will push this soon.



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

Re: [FFmpeg-devel] [PATCH v2 1/1] libavformat/dashenc: Option to set timeout for socket I/O operation

[Jeyapal, Karthick]

On 3/5/18 3:07 PM, rpata...@akamai.com wrote:
> From: Ravindra 
>
> ---
>  doc/muxers.texi   | 2 ++
>  libavformat/dashenc.c | 4 
>  2 files changed, 6 insertions(+)
>
> diff --git a/doc/muxers.texi b/doc/muxers.texi
> index 3a63da7..cb75c26 100644
> --- a/doc/muxers.texi
> +++ b/doc/muxers.texi
> @@ -264,6 +264,8 @@ of the adaptation sets and a,b,c,d and e are the indices 
> of the mapped streams.
>  To map all video (or audio) streams to an AdaptationSet, "v" (or "a") can be 
> used as stream identifier instead of IDs.
>  
>  When no assignment is defined, this defaults to an AdaptationSet for each 
> stream.
> +@item -timeout @var{timeout}
> +Set timeout for socket I/O operations. Applicable only for HTTP output.
>  @end table
>  
>  @anchor{framecrc}
> diff --git a/libavformat/dashenc.c b/libavformat/dashenc.c
> index 79d63e5..9feb4f1 100644
> --- a/libavformat/dashenc.c
> +++ b/libavformat/dashenc.c
> @@ -117,6 +117,7 @@ typedef struct DASHContext {
>  AVIOContext *mpd_out;
>  AVIOContext *m3u8_out;
>  int streaming;
> +int64_t timeout;
>  } DASHContext;
>  
>  static struct codec_string {
> @@ -269,6 +270,8 @@ static void set_http_options(AVDictionary **options, 
> DASHContext *c)
>  av_dict_set(options, "user_agent", c->user_agent, 0);
>  if (c->http_persistent)
>  av_dict_set_int(options, "multiple_requests", 1, 0);
> +if (c->timeout >= 0)
> +av_dict_set_int(options, "timeout", c->timeout, 0);
>  }
>  
>  static void get_hls_playlist_name(char *playlist_name, int string_size,
> @@ -1440,6 +1443,7 @@ static const AVOption options[] = {
>  { "http_persistent", "Use persistent HTTP connections", 
> OFFSET(http_persistent), AV_OPT_TYPE_BOOL, {.i64 = 0 }, 0, 1, E },
>  { "hls_playlist", "Generate HLS playlist files(master.m3u8, 
> media_%d.m3u8)", OFFSET(hls_playlist), AV_OPT_TYPE_BOOL, { .i64 = 0 }, 0, 1, 
> E },
>  { "streaming", "Enable/Disable streaming mode of output. Each frame will 
> be moof fragment", OFFSET(streaming), AV_OPT_TYPE_BOOL, { .i64 = 0 }, 0, 1, E 
> },
> +{ "timeout", "set timeout for socket I/O operations", OFFSET(timeout), 
> AV_OPT_TYPE_DURATION, { .i64 = -1 }, -1, INT_MAX, .flags = E },
>  { NULL },
>  };
>  
Pushed



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

Re: [FFmpeg-devel] [PATCH 05/10] lavf/dashenc: don't call flush_init_segment before avformat_write_header

[Rodger Combs]

> On Mar 18, 2018, at 02:16, Jeyapal, Karthick  wrote:
> 
> 
> 
> On 3/14/18 11:54 AM, Rodger Combs wrote:
>> Fixes crash when muxing MKV-in-DASH
>> ---
>> libavformat/dashenc.c | 10 +++---
>> 1 file changed, 3 insertions(+), 7 deletions(-)
>> 
>> diff --git a/libavformat/dashenc.c b/libavformat/dashenc.c
>> index 5689aef811..63ff827583 100644
>> --- a/libavformat/dashenc.c
>> +++ b/libavformat/dashenc.c
>> @@ -985,13 +985,6 @@ static int dash_init(AVFormatContext *s)
>> 
>> av_log(s, AV_LOG_VERBOSE, "Representation %d init segment will be 
>> written to: %s\n", i, filename);
>> 
>> -// Flush init segment
>> -// except for mp4, since delay_moov is set and the init segment
>> -// is then flushed after the first packets
>> -if (strcmp(os->format_name, "mp4")) {
>> -flush_init_segment(s, os);
>> -}
>> -
>> s->streams[i]->time_base = st->time_base;
>> // If the muxer wants to shift timestamps, request to have them 
>> shifted
>> // already before being handed to this muxer, so we don't have 
>> mismatches
>> @@ -1032,6 +1025,9 @@ static int dash_write_header(AVFormatContext *s)
>> OutputStream *os = &c->streams[i];
>> if ((ret = avformat_write_header(os->ctx, NULL)) < 0)
>> return ret;
>> +
>> +if ((ret = flush_init_segment(s, os)) < 0)
>> +return ret;
> I am fine with moving this here. But you have removed the strcmp for mp4 
> files.
> Have you analyzed the impact of this change for mp4 files. Looks like 
> something might break for mp4 files.
> I would be more comfortable, if the strcmp and its related comment is also 
> moved here.

After some more testing, I think you're correct. I'll resend with it moved.

>> }
>> ret = write_manifest(s, 0);
>> if (!ret)
> 
> 
> 
> ___
> 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 v4 2/2] avformat/libopenmpt: Probe file format from file data if possible

[Jörn Heusipp]

On 03/04/2018 08:55 AM, Jörn Heusipp wrote:

On 02/21/2018 12:11 PM, Jörn Heusipp wrote:
  libavformat/libopenmpt.c | 57 


  1 file changed, 57 insertions(+)


Uhm, ping?


So, my patches have been waiting without any further comment for more 
than 2 months by now.


What should I do?

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

Re: [FFmpeg-devel] [PATCH] libavformat/movenc : Change MOV_TIMESCALE from 1000 to 600

[Mark Burton]

On 14 Mar 2018, at 23:20, Michael Niedermayer  wrote:
> for other cases 600 is less accurate
> for example input that uses timestamps in ms precission
> like flv
> but also 3/1001 will be less precisse

In the case of a Quicktime encoder, a 3/1001 frame rate encode would still 
have a Movie Header timescale of 600, but a video track timescale of 2997. 
Since ffmpeg allows us to specify the video_track_timescale, this output could 
still be achieved.

As for flv and formats that use ms precision, I’ll freely admit thats not 
something I work with so am not in a position to comment. However, would these 
formats not also have the benefit of the current flag to set 
video_track_timescale?

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

Re: [FFmpeg-devel] [PATCH v4 2/2] avformat/libopenmpt: Probe file format from file data if possible

[wm4]

On Sun, 18 Mar 2018 08:44:12 +0100
Jörn Heusipp  wrote:

> On 03/04/2018 08:55 AM, Jörn Heusipp wrote:
> > On 02/21/2018 12:11 PM, Jörn Heusipp wrote:  
> >>   libavformat/libopenmpt.c | 57 
> >> 
> >>   1 file changed, 57 insertions(+)  
> > 
> > Uhm, ping?  
> 
> So, my patches have been waiting without any further comment for more 
> than 2 months by now.
> 
> What should I do?

I assume everything that was asked for in previous patch replies before
was fixed. If nobody applies them until Tuesdays, I'll apply them if
you ping this thread again on that day.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] libavformat/movenc : Change MOV_TIMESCALE from 1000 to 600

[Mark Burton]

On 18 Mar 2018, at 07:52, Mark Burton  wrote:
> On 14 Mar 2018, at 23:20, Michael Niedermayer  > wrote:
>> for other cases 600 is less accurate
>> for example input that uses timestamps in ms precission
>> like flv
>> but also 3/1001 will be less precisse
> 
> In the case of a Quicktime encoder, a 3/1001 frame rate encode would 
> still have a Movie Header timescale of 600, but a video track timescale of 
> 2997. Since ffmpeg allows us to specify the video_track_timescale, this 
> output could still be achieved.
> 
> As for flv and formats that use ms precision, I’ll freely admit thats not 
> something I work with so am not in a position to comment. However, would 
> these formats not also have the benefit of the current flag to set 
> video_track_timescale?

Or go with 1200, which is more accurate for ms precision formats and also works 
for all major frame rates.

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

Re: [FFmpeg-devel] avfilter/vf_premultiply : use full range for RGB input

[wm4]

On Sat, 17 Mar 2018 20:46:50 +0100
Martin Vignali  wrote:

> Hello,
> 
> Patch in attach change premultiply/unpremultiply filter for RGB input
> to process it at full range
> 
> Avoid very strange result in unpremultiply mode
> 
> To test :
> ./ffmpeg -i ./fate-suite/mov/mov_alpha_premult.mov -vf
> unpremultiply=inplace=1 resStraight.png -y
> 
> ./ffmpeg -i ./fate-suite/mov/mov_alpha_premult.mov -vf
> format=gbrap16,unpremultiply=inplace=1 resStraight16.png -y

I thought all alpha in ffmpeg is "straight" (not premultiplied). Was I
lied to?
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] avfilter/vf_premultiply : use full range for RGB input

[Hendrik Leppkes]

On Sun, Mar 18, 2018 at 9:26 AM, wm4  wrote:
> On Sat, 17 Mar 2018 20:46:50 +0100
> Martin Vignali  wrote:
>
>> Hello,
>>
>> Patch in attach change premultiply/unpremultiply filter for RGB input
>> to process it at full range
>>
>> Avoid very strange result in unpremultiply mode
>>
>> To test :
>> ./ffmpeg -i ./fate-suite/mov/mov_alpha_premult.mov -vf
>> unpremultiply=inplace=1 resStraight.png -y
>>
>> ./ffmpeg -i ./fate-suite/mov/mov_alpha_premult.mov -vf
>> format=gbrap16,unpremultiply=inplace=1 resStraight16.png -y
>
> I thought all alpha in ffmpeg is "straight" (not premultiplied). Was I
> lied to?

If you pre-multiplty the alpha and then save it as a file, how it is
supposed to know that you did that? :)

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

Re: [FFmpeg-devel] avfilter/vf_premultiply : use full range for RGB input

[Paul B Mahol]

On 3/18/18, Hendrik Leppkes  wrote:
> On Sun, Mar 18, 2018 at 9:26 AM, wm4  wrote:
>> On Sat, 17 Mar 2018 20:46:50 +0100
>> Martin Vignali  wrote:
>>
>>> Hello,
>>>
>>> Patch in attach change premultiply/unpremultiply filter for RGB input
>>> to process it at full range
>>>
>>> Avoid very strange result in unpremultiply mode
>>>
>>> To test :
>>> ./ffmpeg -i ./fate-suite/mov/mov_alpha_premult.mov -vf
>>> unpremultiply=inplace=1 resStraight.png -y
>>>
>>> ./ffmpeg -i ./fate-suite/mov/mov_alpha_premult.mov -vf
>>> format=gbrap16,unpremultiply=inplace=1 resStraight16.png -y
>>
>> I thought all alpha in ffmpeg is "straight" (not premultiplied). Was I
>> lied to?
>
> If you pre-multiplty the alpha and then save it as a file, how it is
> supposed to know that you did that? :)

There must be flag, which is ignored.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] [RFC][WIP] avutil/buffer: add add a dynamnic size buffer pool API

[Michael Niedermayer]

On Sat, Mar 17, 2018 at 10:46:22PM -0300, James Almer wrote:
> On 3/17/2018 10:33 PM, Michael Niedermayer wrote:
> > On Sat, Mar 17, 2018 at 09:26:32PM -0300, James Almer wrote:
> >> On 3/17/2018 8:48 PM, Michael Niedermayer wrote:
> >>> On Fri, Mar 16, 2018 at 03:21:41PM -0300, James Almer wrote:
>  Signed-off-by: James Almer 
>  ---
>  This is a proof of concept for a dynamic size buffer pool API.
> 
>  For the purpose of easy testing and reviewing I replaced the current
>  linked list used to keep a pool of fixed size buffers with the tree
>  based pool that will be used to keep a pool of varying size buffers,
>  instead of adding a new set of functions exclusively for the new API.
>  The final committed work doesn't necessarely have to do the above, as
>  there's no real benefit using a tree when you only need a fixed size
>  buffer pool, other than simplying things.
> 
>  I'm open to suggestions about how to introduce this. Completely
>  separate set of functions and struct names? Sharing the struct and
>  init/uninit functions and only adding a new get() one like in this
>  patch?
>  Any preferences with function/struct naming, for that matter?
> 
>   libavutil/buffer.c  | 98 
>  -
>   libavutil/buffer.h  |  2 +
>   libavutil/buffer_internal.h |  6 ++-
>   3 files changed, 85 insertions(+), 21 deletions(-)
> >>>
> >>> not sure its not intended but this causes differences
> >>> in error concealment on many files
> >>
> >> Not intended by me, at least. And not sure how using a tree instead of a
> >> linked list to keep a pool of buffers could affect that. The way they
> >> are allocated or returned is not changed, and all the existing users are
> >> still only creating fixed sized buffers.
> >>
> > 
> >> Do you have an idea of what could be happening? The way the tree is
> > 
> > is always the same buffer used as before ?
> 
> Was thinking that, yes. The pool organized by the tree most assuredly
> orders the buffers in a different way than the linked list (Which i
> think is simply FIFO), so the h264 decoder or whatever is handling the
> pool here now gets a different buffer after calling av_buffer_pool_get().
> This would mean the EC code is overreading bytes, and that the buffer is
> not zeroed after being requested. The former should probably be fixed.

the problem is probably that damaged video frames leave some areas 
uninitialized. Quite possibly a consequence of some corner cases not
being supported in the EC code.
This is a bug of course if its what happens and should be fixed.

[...]

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

If you drop bombs on a foreign country and kill a hundred thousand
innocent people, expect your government to call the consequence
"unprovoked inhuman terrorist attacks" and use it to justify dropping
more bombs and killing more people. The technology changed, the idea is old.


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

Re: [FFmpeg-devel] fate/hapqa_extract : add test for hapqa_extract bsf

[Martin Vignali]

2018-03-18 0:45 GMT+01:00 James Almer :

> On 3/17/2018 5:10 PM, Martin Vignali wrote:
> > Thanks for the comments,
> >
> > New patch in attach
> >
> > Martin
>
> Should be ok.
>
> Pushed, thanks

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

Re: [FFmpeg-devel] [PATCH 1/3] http: do not print a warning message for expired cookies

[wm4]

On Thu,  8 Mar 2018 04:53:55 +0100
wm4  wrote:

> libavformat prints a warning that the cookie couldn't be parsed (see
> callers of parse_cookie()). This is obviously not true - it could be
> parsed, but was simply ignored. Don't return an error to avoid the
> warning.
> ---
>  libavformat/http.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/libavformat/http.c b/libavformat/http.c
> index 344fd603cb..d7a72e7129 100644
> --- a/libavformat/http.c
> +++ b/libavformat/http.c
> @@ -802,7 +802,7 @@ static int parse_cookie(HTTPContext *s, const char *p, 
> AVDictionary **cookies)
>  // if the cookie has already expired ignore it
>  if (av_timegm(&new_tm) < av_gettime() / 100) {
>  av_dict_free(&new_params);
> -return -1;
> +return 0;
>  }
>  
>  // only replace an older cookie with the same name

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

Re: [FFmpeg-devel] avfilter/vf_premultiply : use full range for RGB input

[Martin Vignali]

> If you pre-multiplty the alpha and then save it as a file, how it is
> supposed to know that you did that? :)
>
>
>
This is a common trouble in post-production, like some software output by
default in premult
and some in straight.

For Mov file, Adobe set an UDTA for alpha.
Never see another way to store this information.

I post a patch (in discussion avformat/mov : add support for read/write
Adobe Alpha Udta)
This patch add support for read and write this metadata.

Maybe we can add support for reading/writing this metadata in
vf_premultiply/unpremultiply filter.

Patch for unpremultiply_offset pushed.

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

Re: [FFmpeg-devel] [PATCH]avfilter/astreamslect: fixing activating in some cases

[Nicolas George]

Bodecs Bela (2018-03-17):
> with my patch it works good.

Thanks for the details. After more careful examination, I confirm my
first impression: calling ff_filter_set_ready() from the framesync
callback would be wrong. But this filter already misuses internal APIs
(for example re-calling avfilter_config_links() after init) and contains
several easily spotted bugs.

Regards,

-- 
  Nicolas George


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

Re: [FFmpeg-devel] [PATCH v2] lavu/frame: add QP side data

[wm4]

On Fri,  2 Mar 2018 12:16:37 +0100
wm4  wrote:

> This adds a way for an API user to transfer QP data and metadata without
> having to keep the reference to AVFrame, and without having to
> explicitly care about QP APIs. It might also provide a way to finally
> remove the deprecated QP related fields. In the end, the QP table should
> be handled in a very similar way to e.g. AV_FRAME_DATA_MOTION_VECTORS.
> 
> There are two side data types, because I didn't care about having to
> repack the QP data so the table and the metadata are in a single
> AVBufferRef. Otherwise it would have either required a copy on decoding
> (extra slowdown for something as obscure as the QP data), or would have
> required making intrusive changes to the codecs which support export of
> this data.
> 
> The new side data types are added under deprecation guards, because I
> don't intend to change the status of the QP export as being deprecated
> (as it was before this patch too).
> ---
>  libavutil/frame.c  | 59 
> ++
>  libavutil/frame.h  | 17 +++
>  tests/ref/fate/exif-image-embedded |  6 
>  tests/ref/fate/exif-image-jpg  | 34 +-
>  4 files changed, 96 insertions(+), 20 deletions(-)
> 
> diff --git a/libavutil/frame.c b/libavutil/frame.c
> index 0db2a2d57b..ea13cd3ed6 100644
> --- a/libavutil/frame.c
> +++ b/libavutil/frame.c
> @@ -46,8 +46,17 @@ MAKE_ACCESSORS(AVFrame, frame, enum AVColorRange, 
> color_range)
> av_get_channel_layout_nb_channels((frame)->channel_layout))
>  
>  #if FF_API_FRAME_QP
> +struct qp_properties {
> +int stride;
> +int type;
> +};
> +
>  int av_frame_set_qp_table(AVFrame *f, AVBufferRef *buf, int stride, int 
> qp_type)
>  {
> +struct qp_properties *p;
> +AVFrameSideData *sd;
> +AVBufferRef *ref;
> +
>  FF_DISABLE_DEPRECATION_WARNINGS
>  av_buffer_unref(&f->qp_table_buf);
>  
> @@ -57,20 +66,56 @@ FF_DISABLE_DEPRECATION_WARNINGS
>  f->qscale_type  = qp_type;
>  FF_ENABLE_DEPRECATION_WARNINGS
>  
> +av_frame_remove_side_data(f, AV_FRAME_DATA_QP_TABLE_PROPERTIES);
> +av_frame_remove_side_data(f, AV_FRAME_DATA_QP_TABLE_DATA);
> +
> +ref = av_buffer_ref(buf);
> +if (!av_frame_new_side_data_from_buf(f, AV_FRAME_DATA_QP_TABLE_DATA, 
> ref)) {
> +av_buffer_unref(&ref);
> +return AVERROR(ENOMEM);
> +}
> +
> +sd = av_frame_new_side_data(f, AV_FRAME_DATA_QP_TABLE_PROPERTIES,
> +sizeof(struct qp_properties));
> +if (!sd)
> +return AVERROR(ENOMEM);
> +
> +p = (struct qp_properties *)sd->data;
> +p->stride = stride;
> +p->type = qp_type;
> +
>  return 0;
>  }
>  
>  int8_t *av_frame_get_qp_table(AVFrame *f, int *stride, int *type)
>  {
> -FF_DISABLE_DEPRECATION_WARNINGS
> -*stride = f->qstride;
> -*type   = f->qscale_type;
> +AVBufferRef *buf = NULL;
>  
> -if (!f->qp_table_buf)
> -return NULL;
> +*stride = 0;
> +*type   = 0;
>  
> -return f->qp_table_buf->data;
> +FF_DISABLE_DEPRECATION_WARNINGS
> +if (f->qp_table_buf) {
> +*stride = f->qstride;
> +*type   = f->qscale_type;
> +buf = f->qp_table_buf;
>  FF_ENABLE_DEPRECATION_WARNINGS
> +} else {
> +AVFrameSideData *sd;
> +struct qp_properties *p;
> +sd = av_frame_get_side_data(f, AV_FRAME_DATA_QP_TABLE_PROPERTIES);
> +if (!sd)
> +return NULL;
> +p = (struct qp_properties *)sd->data;
> +sd = av_frame_get_side_data(f, AV_FRAME_DATA_QP_TABLE_DATA);
> +if (!sd)
> +return NULL;
> +*stride = p->stride;
> +*type   = p->type;
> +buf = sd->buf;
> +}
> +
> +return buf ? buf->data : NULL;
>  }
>  #endif
>  
> @@ -787,6 +832,8 @@ const char *av_frame_side_data_name(enum 
> AVFrameSideDataType type)
>  case AV_FRAME_DATA_CONTENT_LIGHT_LEVEL: return "Content light 
> level metadata";
>  case AV_FRAME_DATA_GOP_TIMECODE:return "GOP timecode";
>  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";
>  }
>  return NULL;
>  }
> diff --git a/libavutil/frame.h b/libavutil/frame.h
> index ddbac3156d..9d57d6ce66 100644
> --- a/libavutil/frame.h
> +++ b/libavutil/frame.h
> @@ -141,6 +141,23 @@ enum AVFrameSideDataType {
>   * metadata key entry "name".
>   */
>  AV_FRAME_DATA_ICC_PROFILE,
> +
> +#if FF_API_FRAME_QP
> +/**
> + * Implementation-specific description of the format of 
> AV_FRAME_QP_TABLE_DATA.
> + * The contents of this side data are undocumented and internal; use
> + * av_frame_set_qp_table() and av_frame_get_qp_table() to access this in 
> a
> + * meaningful way instead.
> + */
> +AV

[FFmpeg-devel] [PATCH] lavfi: Add OpenCL avgblur filter

[dylanf123]

From: drfer3 

Behaves like the existing avgblur filter, except working on OpenCL
hardware frames. Takes exactly the same options.
---
 configure   |   1 +
 libavfilter/Makefile|   2 +
 libavfilter/allfilters.c|   1 +
 libavfilter/opencl/avgblur.cl   |  60 
 libavfilter/opencl_source.h |   1 +
 libavfilter/vf_avgblur_opencl.c | 318 
 6 files changed, 383 insertions(+)
 create mode 100644 libavfilter/opencl/avgblur.cl
 create mode 100644 libavfilter/vf_avgblur_opencl.c

diff --git a/configure b/configure
index 0c5ed07a07..481d338caf 100755
--- a/configure
+++ b/configure
@@ -3202,6 +3202,7 @@ aresample_filter_deps="swresample"
 ass_filter_deps="libass"
 atempo_filter_deps="avcodec"
 atempo_filter_select="rdft"
+avgblur_opencl_filter_deps="opencl"
 azmq_filter_deps="libzmq"
 blackframe_filter_deps="gpl"
 boxblur_filter_deps="gpl"
diff --git a/libavfilter/Makefile b/libavfilter/Makefile
index fc16512e2c..1043b41d80 100644
--- a/libavfilter/Makefile
+++ b/libavfilter/Makefile
@@ -139,6 +139,8 @@ OBJS-$(CONFIG_ALPHAMERGE_FILTER) += 
vf_alphamerge.o
 OBJS-$(CONFIG_ASS_FILTER)+= vf_subtitles.o
 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_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 cc423af738..3f67e321bf 100644
--- a/libavfilter/allfilters.c
+++ b/libavfilter/allfilters.c
@@ -149,6 +149,7 @@ static void register_all(void)
 REGISTER_FILTER(ASS,ass,vf);
 REGISTER_FILTER(ATADENOISE, atadenoise, vf);
 REGISTER_FILTER(AVGBLUR,avgblur,vf);
+REGISTER_FILTER(AVGBLUR_OPENCL, avgblur_opencl, vf);
 REGISTER_FILTER(BBOX,   bbox,   vf);
 REGISTER_FILTER(BENCH,  bench,  vf);
 REGISTER_FILTER(BITPLANENOISE,  bitplanenoise,  vf);
diff --git a/libavfilter/opencl/avgblur.cl b/libavfilter/opencl/avgblur.cl
new file mode 100644
index 00..28e0c90d15
--- /dev/null
+++ b/libavfilter/opencl/avgblur.cl
@@ -0,0 +1,60 @@
+/*
+ * Copyright (c) 2018 Dylan Fernando
+ *
+ * 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
+ */
+
+
+__kernel void avgblur_horiz(__write_only image2d_t dst,
+__read_only  image2d_t src,
+int rad)
+{
+const sampler_t sampler = (CLK_NORMALIZED_COORDS_FALSE |
+   CLK_FILTER_NEAREST);
+int2 loc = (int2)(get_global_id(0), get_global_id(1));
+int2 size = (int2)(get_global_size(0), get_global_size(1));
+
+int count = 0;
+float4 acc = (float4)(0,0,0,0);
+
+for (int xx = max(0,loc.x-rad); xx < min(loc.x+rad+1,size.x); xx++) {
+count++;
+acc += read_imagef(src, sampler, (int2)(xx, loc.y));
+}
+
+write_imagef(dst, loc, acc / count);
+}
+
+__kernel void avgblur_vert(__write_only image2d_t dst,
+   __read_only  image2d_t src,
+   int radv)
+{
+const sampler_t sampler = (CLK_NORMALIZED_COORDS_FALSE |
+   CLK_FILTER_NEAREST);
+int2 loc = (int2)(get_global_id(0), get_global_id(1));
+int2 size = (int2)(get_global_size(0), get_global_size(1));
+
+int count = 0;
+float4 acc = (float4)(0,0,0,0);
+
+for (int yy = max(0,loc.y-radv); yy < min(loc.y+radv+1,size.y); yy++) {
+count++;
+acc += read_imagef(src, sampler, (int2)(loc.x, yy));
+}
+
+write_imagef(dst, loc, acc / count);
+}
diff --git a/libavfilter/opencl_source.h b/libavfilter/opencl_source.h
index 23cdfc6ac9..02bc1723b0 100644
--- a/libavfilter/opencl_source.h
+++ b/libavfilter/opencl_source.h
@@ -19,6 +19,7 @@
 #ifndef AVFILTER_OPENCL_SOURCE_H
 #define AVFILTER_OPENCL_SOURCE_H
 
+extern const char *ff_opencl_source_avgblur;
 extern const char *ff_ope

[FFmpeg-devel] [PATCH 4/4] lavc, lavd, lavf, lavfi, tests: remove several register() calls

[josh]

From: Josh de Kock 

---
 doc/examples/filter_audio.c  | 2 --
 doc/examples/filtering_audio.c   | 2 --
 doc/examples/filtering_video.c   | 2 --
 doc/examples/transcoding.c   | 2 --
 fftools/ffmpeg.c | 6 --
 fftools/ffplay.c | 7 ---
 fftools/ffprobe.c| 4 
 libavcodec/tests/utils.c | 1 -
 libavdevice/lavfi.c  | 2 --
 libavfilter/lavfutils.c  | 2 --
 libavfilter/src_movie.c  | 2 --
 libavfilter/tests/filtfmts.c | 2 --
 libavformat/tests/movenc.c   | 2 --
 libavformat/tests/seek.c | 3 ---
 tests/api/api-band-test.c| 2 --
 tests/api/api-codec-param-test.c | 2 --
 tests/api/api-flac-test.c| 2 --
 tests/api/api-h264-test.c| 2 --
 tests/api/api-seek-test.c| 2 --
 tools/aviocat.c  | 1 -
 tools/enum_options.c | 2 --
 tools/graph2dot.c| 2 --
 tools/ismindex.c | 2 --
 tools/pktdumper.c| 3 ---
 tools/probetest.c| 3 ---
 tools/seek_print.c   | 1 -
 tools/sidxindex.c| 2 --
 tools/uncoded_frame.c| 4 
 28 files changed, 69 deletions(-)

diff --git a/doc/examples/filter_audio.c b/doc/examples/filter_audio.c
index 7467c21c30..1611e3d952 100644
--- a/doc/examples/filter_audio.c
+++ b/doc/examples/filter_audio.c
@@ -289,8 +289,6 @@ int main(int argc, char *argv[])
 return 1;
 }
 
-avfilter_register_all();
-
 /* Allocate the frame we will be using to store the data. */
 frame  = av_frame_alloc();
 if (!frame) {
diff --git a/doc/examples/filtering_audio.c b/doc/examples/filtering_audio.c
index 73a00e814c..b109dbcb96 100644
--- a/doc/examples/filtering_audio.c
+++ b/doc/examples/filtering_audio.c
@@ -228,8 +228,6 @@ int main(int argc, char **argv)
 exit(1);
 }
 
-avfilter_register_all();
-
 if ((ret = open_input_file(argv[1])) < 0)
 goto end;
 if ((ret = init_filters(filter_descr)) < 0)
diff --git a/doc/examples/filtering_video.c b/doc/examples/filtering_video.c
index 01d6644620..ed4e7bbd81 100644
--- a/doc/examples/filtering_video.c
+++ b/doc/examples/filtering_video.c
@@ -222,8 +222,6 @@ int main(int argc, char **argv)
 exit(1);
 }
 
-avfilter_register_all();
-
 if ((ret = open_input_file(argv[1])) < 0)
 goto end;
 if ((ret = init_filters(filter_descr)) < 0)
diff --git a/doc/examples/transcoding.c b/doc/examples/transcoding.c
index ed1fd6411b..a83fa3a185 100644
--- a/doc/examples/transcoding.c
+++ b/doc/examples/transcoding.c
@@ -517,8 +517,6 @@ int main(int argc, char **argv)
 return 1;
 }
 
-avfilter_register_all();
-
 if ((ret = open_input_file(argv[1])) < 0)
 goto end;
 if ((ret = open_output_file(argv[2])) < 0)
diff --git a/fftools/ffmpeg.c b/fftools/ffmpeg.c
index ee7258fcd1..47236774ef 100644
--- a/fftools/ffmpeg.c
+++ b/fftools/ffmpeg.c
@@ -4803,12 +4803,6 @@ int main(int argc, char **argv)
 argv++;
 }
 
-avcodec_register_all();
-#if CONFIG_AVDEVICE
-avdevice_register_all();
-#endif
-avfilter_register_all();
-av_register_all();
 avformat_network_init();
 
 show_banner(argc, argv, options);
diff --git a/fftools/ffplay.c b/fftools/ffplay.c
index f2028d4b13..05a1e7a68d 100644
--- a/fftools/ffplay.c
+++ b/fftools/ffplay.c
@@ -3652,13 +3652,6 @@ int main(int argc, char **argv)
 parse_loglevel(argc, argv, options);
 
 /* register all codecs, demux and protocols */
-#if CONFIG_AVDEVICE
-avdevice_register_all();
-#endif
-#if CONFIG_AVFILTER
-avfilter_register_all();
-#endif
-av_register_all();
 avformat_network_init();
 
 init_opts();
diff --git a/fftools/ffprobe.c b/fftools/ffprobe.c
index a4ac6972a2..540ad9f6fe 100644
--- a/fftools/ffprobe.c
+++ b/fftools/ffprobe.c
@@ -3567,12 +3567,8 @@ int main(int argc, char **argv)
 
 options = real_options;
 parse_loglevel(argc, argv, options);
-av_register_all();
 avformat_network_init();
 init_opts();
-#if CONFIG_AVDEVICE
-avdevice_register_all();
-#endif
 
 show_banner(argc, argv, options);
 parse_options(NULL, argc, argv, options, opt_input_file);
diff --git a/libavcodec/tests/utils.c b/libavcodec/tests/utils.c
index e2891fb389..f6ba7fe66e 100644
--- a/libavcodec/tests/utils.c
+++ b/libavcodec/tests/utils.c
@@ -21,7 +21,6 @@
 int main(void){
 AVCodec *codec = NULL;
 int ret = 0;
-avcodec_register_all();
 
 while (codec = av_codec_next(codec)) {
 if (av_codec_is_encoder(codec)) {
diff --git a/libavdevice/lavfi.c b/libavdevice/lavfi.c
index 6f2ae958dc..ca8f05f3f7 100644
--- a/libavdevice/lavfi.c
+++ b/libavdevice/lavfi.c
@@ -130,8 +130,6 @@ av_cold static int lavfi_read_header(AVFormatContext *avctx)
 if (!pix_fmts)
 FAIL(AVERROR(ENOMEM));
 
-avfilter_register_all();
-
 buffersink = avfilter_get_by_name("buffersink");
 abuffersink = avfilte

[FFmpeg-devel] [PATCH 1/4] checkasm/Makefile: add EXTRALIBS-libavformat

[josh]

From: Josh de Kock 

---
 tests/checkasm/Makefile | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/tests/checkasm/Makefile b/tests/checkasm/Makefile
index 0520e264e2..ae7e810d25 100644
--- a/tests/checkasm/Makefile
+++ b/tests/checkasm/Makefile
@@ -61,7 +61,7 @@ tests/checkasm/checkasm.o: CFLAGS += -Umain
 CHECKASM := tests/checkasm/checkasm$(EXESUF)
 
 $(CHECKASM): $(CHECKASMOBJS) $(FF_STATIC_DEP_LIBS)
-   $(LD) $(LDFLAGS) $(LDEXEFLAGS) $(LD_O) $(CHECKASMOBJS) 
$(FF_STATIC_DEP_LIBS) $(EXTRALIBS-avcodec) $(EXTRALIBS-avfilter) 
$(EXTRALIBS-avutil) $(EXTRALIBS-swresample) $(EXTRALIBS)
+   $(LD) $(LDFLAGS) $(LDEXEFLAGS) $(LD_O) $(CHECKASMOBJS) 
$(FF_STATIC_DEP_LIBS) $(EXTRALIBS-avcodec) $(EXTRALIBS-avfilter) 
$(EXTRALIBS-avformat) $(EXTRALIBS-avutil) $(EXTRALIBS-swresample) $(EXTRALIBS)
 
 checkasm: $(CHECKASM)
 
-- 
2.14.3 (Apple Git-98)

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

[FFmpeg-devel] [PATCH 3/4] cmdutils: use new iteration APIs

[josh]

From: Josh de Kock 

---
 fftools/cmdutils.c | 239 +
 1 file changed, 112 insertions(+), 127 deletions(-)

diff --git a/fftools/cmdutils.c b/fftools/cmdutils.c
index 708a849f51..2da313cc0a 100644
--- a/fftools/cmdutils.c
+++ b/fftools/cmdutils.c
@@ -1250,19 +1250,11 @@ int show_license(void *optctx, const char *opt, const 
char *arg)
 return 0;
 }
 
-static int is_device(const AVClass *avclass)
-{
-if (!avclass)
-return 0;
-return AV_IS_INPUT_DEVICE(avclass->category) || 
AV_IS_OUTPUT_DEVICE(avclass->category);
-}
-
 static int show_formats_devices(void *optctx, const char *opt, const char 
*arg, int device_only, int muxdemuxers)
 {
-AVInputFormat *ifmt  = NULL;
-AVOutputFormat *ofmt = NULL;
+const AVInputFormat *ifmt  = NULL;
+const AVOutputFormat *ofmt = NULL;
 const char *last_name;
-int is_dev;
 
 printf("%s\n"
" D. = Demuxing supported\n"
@@ -1270,46 +1262,38 @@ static int show_formats_devices(void *optctx, const 
char *opt, const char *arg,
" --\n", device_only ? "Devices:" : "File formats:");
 last_name = "000";
 for (;;) {
-int decode = 0;
-int encode = 0;
+int is_ifmt = 0;
+int is_ofmt = 0;
 const char *name  = NULL;
 const char *long_name = NULL;
 
-if (muxdemuxers !=SHOW_DEMUXERS) {
-while ((ofmt = av_oformat_next(ofmt))) {
-is_dev = is_device(ofmt->priv_class);
-if (!is_dev && device_only)
-continue;
-if ((!name || strcmp(ofmt->name, name) < 0) &&
-strcmp(ofmt->name, last_name) > 0) {
-name  = ofmt->name;
-long_name = ofmt->long_name;
-encode= 1;
-}
-}
-}
-if (muxdemuxers != SHOW_MUXERS) {
-while ((ifmt = av_iformat_next(ifmt))) {
-is_dev = is_device(ifmt->priv_class);
-if (!is_dev && device_only)
-continue;
-if ((!name || strcmp(ifmt->name, name) < 0) &&
-strcmp(ifmt->name, last_name) > 0) {
-name  = ifmt->name;
-long_name = ifmt->long_name;
-encode= 0;
-}
-if (name && strcmp(ifmt->name, name) == 0)
-decode = 1;
-}
-}
+#define x(func, type, condition) do {   \
+void *i = 0;\
+if (condition) {\
+while ((type = func(&i))) { \
+if ((!name || strcmp(type->name, name) < 0) &&  \
+strcmp(type->name, last_name) > 0) {\
+name  = type->name; \
+long_name = type->long_name;\
+is_ ## type = 1;\
+}   \
+}   \
+} } while(0)
+
+x(av_muxer_iterate, ofmt, muxdemuxers != SHOW_DEMUXERS && 
!device_only);
+x(av_demuxer_iterate, ifmt, muxdemuxers != SHOW_MUXERS && 
!device_only);
+#if CONFIG_AVDEVICE
+x(av_outdev_iterate, ofmt, muxdemuxers != SHOW_DEMUXERS);
+x(av_indev_iterate, ifmt, muxdemuxers != SHOW_MUXERS);
+#endif
+#undef x
 if (!name)
 break;
 last_name = name;
 
 printf(" %s%s %-15s %s\n",
-   decode ? "D" : " ",
-   encode ? "E" : " ",
+   is_ifmt ? "D" : " ",
+   is_ofmt ? "E" : " ",
name,
 long_name ? long_name:" ");
 }
@@ -1439,15 +1423,45 @@ static char get_media_type_char(enum AVMediaType type)
 }
 }
 
-static const AVCodec *next_codec_for_id(enum AVCodecID id, const AVCodec *prev,
-int encoder)
+
+static int compare_codec(const void *a, const void *b)
+{
+const AVCodec * const *ca = a;
+const AVCodec * const *cb = b;
+
+return strcmp((*ca)->name, (*cb)->name);
+}
+
+static unsigned get_codecs_sorted(enum AVCodecID id, const AVCodec ***rcodecs, 
int encoder)
 {
-while ((prev = av_codec_next(prev))) {
-if (prev->id == id &&
-(encoder ? av_codec_is_encoder(prev) : av_codec_is_decoder(prev)))
-return prev;
+const AVCodec *codec = NULL;
+const AVCodec **codecs;
+unsigned nb_codecs = 0, i = 0;
+void *opaque = 0;
+
+while ((codec = av_codec_iterate(&opaque))) {
+if (codec->id == id &&
+(encoder ? av_codec_is_encoder(codec) : 
av_codec_is_decoder(codec)))
+nb_codecs++;
+}
+
+if (!(codecs = av_calloc(nb_codecs, sizeof(*codecs {
+

[FFmpeg-devel] [PATCH 2/4] lavfi: add new iteration API

[josh]

From: Josh de Kock 

---
 configure|  24 +-
 doc/APIchanges   |   4 +
 doc/writing_filters.txt  |   6 +-
 libavfilter/allfilters.c | 818 +--
 libavfilter/avfilter.c   |  45 ---
 libavfilter/avfilter.h   |  29 +-
 libavfilter/version.h|   3 +
 7 files changed, 477 insertions(+), 452 deletions(-)

diff --git a/configure b/configure
index f09f48c54b..245b57d7cf 100755
--- a/configure
+++ b/configure
@@ -3557,15 +3557,6 @@ for v in "$@"; do
 FFMPEG_CONFIGURATION="${FFMPEG_CONFIGURATION# } ${l}${r}"
 done
 
-find_things(){
-thing=$1
-pattern=$2
-file=$source_path/$3
-sed -n "s/^[^#]*$pattern.*([^,]*, *\([^,]*\)\(,.*\)*).*/\1_$thing/p" 
"$file"
-}
-
-FILTER_LIST=$(find_things   filter   FILTER   libavfilter/allfilters.c)
-
 find_things_extern(){
 thing=$1
 pattern=$2
@@ -3574,6 +3565,13 @@ find_things_extern(){
 sed -n "s/^[^#]*extern.*$pattern *ff_\([^ ]*\)_$thing;/\1_$out/p" "$file"
 }
 
+find_filters_extern(){
+file=$source_path/$1
+#sed -n "s/^extern AVFilter 
ff_\([avfsinkrc]\{2,5\}\)_\(\w\+\);/\2_filter/p" $file
+sed -E -n "s/^extern AVFilter 
ff_([avfsinkrc]{2,5})_([a-zA-Z0-9]+);/\2_filter/p" $file
+}
+
+FILTER_LIST=$(find_filters_extern libavfilter/allfilters.c)
 OUTDEV_LIST=$(find_things_extern muxer AVOutputFormat libavdevice/alldevices.c 
outdev)
 INDEV_LIST=$(find_things_extern demuxer AVInputFormat libavdevice/alldevices.c 
indev)
 MUXER_LIST=$(find_things_extern muxer AVOutputFormat libavformat/allformats.c)
@@ -7083,6 +7081,10 @@ echo "#endif /* AVUTIL_AVCONFIG_H */" >> $TMPH
 
 cp_if_changed $TMPH libavutil/avconfig.h
 
+full_filter_name(){
+sed -n "s/^extern AVFilter ff_\([avfsinkrc]\{2,5\}\)_$1;/\1_$1/p" 
$source_path/libavfilter/allfilters.c
+}
+
 # generate the lists of enabled components
 print_enabled_components(){
 file=$1
@@ -7093,6 +7095,9 @@ print_enabled_components(){
 for c in $*; do
 if enabled $c; then
 case $name in
+filter_list)
+c=$(full_filter_name $(remove_suffix _filter $c))
+;;
 indev_list)
 c=$(add_suffix _demuxer $(remove_suffix _indev $c))
 ;;
@@ -7107,6 +7112,7 @@ print_enabled_components(){
 cp_if_changed $TMPH $file
 }
 
+print_enabled_components libavfilter/filter_list.c AVFilter filter_list 
$FILTER_LIST
 print_enabled_components libavcodec/codec_list.c AVCodec codec_list $CODEC_LIST
 print_enabled_components libavcodec/parser_list.c AVCodecParser parser_list 
$PARSER_LIST
 print_enabled_components libavcodec/bsf_list.c AVBitStreamFilter 
bitstream_filters $BSF_LIST
diff --git a/doc/APIchanges b/doc/APIchanges
index 4c0ee7147a..27cf2514d7 100644
--- a/doc/APIchanges
+++ b/doc/APIchanges
@@ -15,6 +15,10 @@ libavutil: 2017-10-21
 
 API changes, most recent first:
 
+2018-xx-xx - xxx - lavc 7.13.100 - avcodec.h
+  Deprecate use of avfilter_register(), avfilter_register_all(),
+  avfilter_next(). Add av_filter_iterate().
+
 2018-03-18 - xxx - lavu 56.11.100 - frame.h
   Add AV_FRAME_DATA_QP_TABLE_PROPERTIES and AV_FRAME_DATA_QP_TABLE_DATA.
 
diff --git a/doc/writing_filters.txt b/doc/writing_filters.txt
index 5cd4ecd6a4..98b9c6f3d2 100644
--- a/doc/writing_filters.txt
+++ b/doc/writing_filters.txt
@@ -31,10 +31,8 @@ If everything went right, you should get a foobar.png with 
Lena edge-detected.
 That's it, your new playground is ready.
 
 Some little details about what's going on:
-libavfilter/allfilters.c:avfilter_register_all() is called at runtime to create
-a list of the available filters, but it's important to know that this file is
-also parsed by the configure script, which in turn will define variables for
-the build system and the C:
+libavfilter/allfilters.c:this file is parsed by the configure script, which in 
turn
+will define variables for the build system and the C:
 
 --- after running configure ---
 
diff --git a/libavfilter/allfilters.c b/libavfilter/allfilters.c
index cc423af738..23773aed09 100644
--- a/libavfilter/allfilters.c
+++ b/libavfilter/allfilters.c
@@ -23,409 +23,451 @@
 #include "avfilter.h"
 #include "config.h"
 
+extern AVFilter ff_af_abench;
+extern AVFilter ff_af_acompressor;
+extern AVFilter ff_af_acontrast;
+extern AVFilter ff_af_acopy;
+extern AVFilter ff_af_acrossfade;
+extern AVFilter ff_af_acrusher;
+extern AVFilter ff_af_adelay;
+extern AVFilter ff_af_aecho;
+extern AVFilter ff_af_aemphasis;
+extern AVFilter ff_af_aeval;
+extern AVFilter ff_af_afade;
+extern AVFilter ff_af_afftfilt;
+extern AVFilter ff_af_afir;
+extern AVFilter ff_af_aformat;
+extern AVFilter ff_af_agate;
+extern AVFilter ff_af_aiir;
+extern AVFilter ff_af_ainterleave;
+extern AVFilter ff_af_alimiter;
+extern AVFilter ff_af_allpass;
+extern AVFilter ff_af_aloop;
+extern AVFilter ff_af_amerge;
+extern AVFilter ff_af_ametadata;
+extern AVFilter ff_af_amix;
+extern AVFilter ff_af_anequalizer;
+extern 

Re: [FFmpeg-devel] [PATCH v2] lavu/frame: add QP side data

[James Almer]

On 3/15/2018 3:28 AM, wm4 wrote:
> On Fri,  2 Mar 2018 12:16:37 +0100
> wm4  wrote:
> 
>> This adds a way for an API user to transfer QP data and metadata without
>> having to keep the reference to AVFrame, and without having to
>> explicitly care about QP APIs. It might also provide a way to finally
>> remove the deprecated QP related fields. In the end, the QP table should
>> be handled in a very similar way to e.g. AV_FRAME_DATA_MOTION_VECTORS.
>>
>> There are two side data types, because I didn't care about having to
>> repack the QP data so the table and the metadata are in a single
>> AVBufferRef. Otherwise it would have either required a copy on decoding
>> (extra slowdown for something as obscure as the QP data), or would have
>> required making intrusive changes to the codecs which support export of
>> this data.
>>
>> The new side data types are added under deprecation guards, because I
>> don't intend to change the status of the QP export as being deprecated
>> (as it was before this patch too).
>> ---
>>  libavutil/frame.c  | 59 
>> ++
>>  libavutil/frame.h  | 17 +++
>>  tests/ref/fate/exif-image-embedded |  6 
>>  tests/ref/fate/exif-image-jpg  | 34 +-
>>  4 files changed, 96 insertions(+), 20 deletions(-)
>>
>> diff --git a/libavutil/frame.c b/libavutil/frame.c
>> index 0db2a2d57b..ea13cd3ed6 100644
>> --- a/libavutil/frame.c
>> +++ b/libavutil/frame.c
>> @@ -46,8 +46,17 @@ MAKE_ACCESSORS(AVFrame, frame, enum AVColorRange, 
>> color_range)
>> av_get_channel_layout_nb_channels((frame)->channel_layout))
>>  
>>  #if FF_API_FRAME_QP
>> +struct qp_properties {
>> +int stride;
>> +int type;
>> +};
>> +
>>  int av_frame_set_qp_table(AVFrame *f, AVBufferRef *buf, int stride, int 
>> qp_type)
>>  {
>> +struct qp_properties *p;
>> +AVFrameSideData *sd;
>> +AVBufferRef *ref;
>> +
>>  FF_DISABLE_DEPRECATION_WARNINGS
>>  av_buffer_unref(&f->qp_table_buf);
>>  
>> @@ -57,20 +66,56 @@ FF_DISABLE_DEPRECATION_WARNINGS
>>  f->qscale_type  = qp_type;
>>  FF_ENABLE_DEPRECATION_WARNINGS
>>  
>> +av_frame_remove_side_data(f, AV_FRAME_DATA_QP_TABLE_PROPERTIES);
>> +av_frame_remove_side_data(f, AV_FRAME_DATA_QP_TABLE_DATA);
>> +
>> +ref = av_buffer_ref(buf);
>> +if (!av_frame_new_side_data_from_buf(f, AV_FRAME_DATA_QP_TABLE_DATA, 
>> ref)) {
>> +av_buffer_unref(&ref);
>> +return AVERROR(ENOMEM);
>> +}
>> +
>> +sd = av_frame_new_side_data(f, AV_FRAME_DATA_QP_TABLE_PROPERTIES,
>> +sizeof(struct qp_properties));
>> +if (!sd)
>> +return AVERROR(ENOMEM);
>> +
>> +p = (struct qp_properties *)sd->data;
>> +p->stride = stride;
>> +p->type = qp_type;
>> +
>>  return 0;
>>  }
>>  
>>  int8_t *av_frame_get_qp_table(AVFrame *f, int *stride, int *type)
>>  {
>> -FF_DISABLE_DEPRECATION_WARNINGS
>> -*stride = f->qstride;
>> -*type   = f->qscale_type;
>> +AVBufferRef *buf = NULL;
>>  
>> -if (!f->qp_table_buf)
>> -return NULL;
>> +*stride = 0;
>> +*type   = 0;
>>  
>> -return f->qp_table_buf->data;
>> +FF_DISABLE_DEPRECATION_WARNINGS
>> +if (f->qp_table_buf) {
>> +*stride = f->qstride;
>> +*type   = f->qscale_type;
>> +buf = f->qp_table_buf;
>>  FF_ENABLE_DEPRECATION_WARNINGS
>> +} else {
>> +AVFrameSideData *sd;
>> +struct qp_properties *p;
>> +sd = av_frame_get_side_data(f, AV_FRAME_DATA_QP_TABLE_PROPERTIES);
>> +if (!sd)
>> +return NULL;
>> +p = (struct qp_properties *)sd->data;
>> +sd = av_frame_get_side_data(f, AV_FRAME_DATA_QP_TABLE_DATA);
>> +if (!sd)
>> +return NULL;
>> +*stride = p->stride;
>> +*type   = p->type;
>> +buf = sd->buf;
>> +}
>> +
>> +return buf ? buf->data : NULL;
>>  }
>>  #endif
>>  
>> @@ -787,6 +832,8 @@ const char *av_frame_side_data_name(enum 
>> AVFrameSideDataType type)
>>  case AV_FRAME_DATA_CONTENT_LIGHT_LEVEL: return "Content light 
>> level metadata";
>>  case AV_FRAME_DATA_GOP_TIMECODE:return "GOP timecode";
>>  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";
>>  }
>>  return NULL;
>>  }
>> diff --git a/libavutil/frame.h b/libavutil/frame.h
>> index ddbac3156d..9d57d6ce66 100644
>> --- a/libavutil/frame.h
>> +++ b/libavutil/frame.h
>> @@ -141,6 +141,23 @@ enum AVFrameSideDataType {
>>   * metadata key entry "name".
>>   */
>>  AV_FRAME_DATA_ICC_PROFILE,
>> +
>> +#if FF_API_FRAME_QP
>> +/**
>> + * Implementation-specific description of the format of 
>> AV_FRAME_QP_TABLE_DATA.
>> + * The contents of this side data 

Re: [FFmpeg-devel] [PATCH 1/2] avcodec/aac_adtstoasc: move the reference in the bsf internal buffer

[James Almer]

On 3/16/2018 8:16 PM, James Almer wrote:
> There's no need to allocate a new packet for it.
> 
> Signed-off-by: James Almer 
> ---
>  libavcodec/aac_adtstoasc_bsf.c | 33 ++---
>  1 file changed, 14 insertions(+), 19 deletions(-)
> 
> diff --git a/libavcodec/aac_adtstoasc_bsf.c b/libavcodec/aac_adtstoasc_bsf.c
> index 49f1f095e6..6541b1189c 100644
> --- a/libavcodec/aac_adtstoasc_bsf.c
> +++ b/libavcodec/aac_adtstoasc_bsf.c
> @@ -36,27 +36,26 @@ typedef struct AACBSFContext {
>   * This filter creates an MPEG-4 AudioSpecificConfig from an MPEG-2/4
>   * ADTS header and removes the ADTS header.
>   */
> -static int aac_adtstoasc_filter(AVBSFContext *bsfc, AVPacket *out)
> +static int aac_adtstoasc_filter(AVBSFContext *bsfc, AVPacket *pkt)
>  {
>  AACBSFContext *ctx = bsfc->priv_data;
>  
>  GetBitContext gb;
>  PutBitContext pb;
>  AACADTSHeaderInfo hdr;
> -AVPacket *in;
>  int ret;
>  
> -ret = ff_bsf_get_packet(bsfc, &in);
> +ret = ff_bsf_get_packet_ref(bsfc, pkt);
>  if (ret < 0)
>  return ret;
>  
> -if (bsfc->par_in->extradata && in->size >= 2 && (AV_RB16(in->data) >> 4) 
> != 0xfff)
> -goto finish;
> +if (bsfc->par_in->extradata && pkt->size >= 2 && (AV_RB16(pkt->data) >> 
> 4) != 0xfff)
> +return 0;
>  
> -if (in->size < AV_AAC_ADTS_HEADER_SIZE)
> +if (pkt->size < AV_AAC_ADTS_HEADER_SIZE)
>  goto packet_too_small;
>  
> -init_get_bits(&gb, in->data, AV_AAC_ADTS_HEADER_SIZE * 8);
> +init_get_bits(&gb, pkt->data, AV_AAC_ADTS_HEADER_SIZE * 8);
>  
>  if (ff_adts_header_parse(&gb, &hdr) < 0) {
>  av_log(bsfc, AV_LOG_ERROR, "Error parsing ADTS frame header!\n");
> @@ -71,10 +70,10 @@ static int aac_adtstoasc_filter(AVBSFContext *bsfc, 
> AVPacket *out)
>  goto fail;
>  }
>  
> -in->size -= AV_AAC_ADTS_HEADER_SIZE + 2 * !hdr.crc_absent;
> -if (in->size <= 0)
> +pkt->size -= AV_AAC_ADTS_HEADER_SIZE + 2 * !hdr.crc_absent;
> +if (pkt->size <= 0)
>  goto packet_too_small;
> -in->data += AV_AAC_ADTS_HEADER_SIZE + 2 * !hdr.crc_absent;
> +pkt->data += AV_AAC_ADTS_HEADER_SIZE + 2 * !hdr.crc_absent;
>  
>  if (!ctx->first_frame_done) {
>  intpce_size = 0;
> @@ -82,7 +81,7 @@ static int aac_adtstoasc_filter(AVBSFContext *bsfc, 
> AVPacket *out)
>  uint8_t   *extradata;
>  
>  if (!hdr.chan_config) {
> -init_get_bits(&gb, in->data, in->size * 8);
> +init_get_bits(&gb, pkt->data, pkt->size * 8);
>  if (get_bits(&gb, 3) != 5) {
>  avpriv_report_missing_feature(bsfc,
>"PCE-based channel 
> configuration "
> @@ -94,11 +93,11 @@ static int aac_adtstoasc_filter(AVBSFContext *bsfc, 
> AVPacket *out)
>  init_put_bits(&pb, pce_data, MAX_PCE_SIZE);
>  pce_size = ff_copy_pce_data(&pb, &gb) / 8;
>  flush_put_bits(&pb);
> -in->size -= get_bits_count(&gb)/8;
> -in->data += get_bits_count(&gb)/8;
> +pkt->size -= get_bits_count(&gb)/8;
> +pkt->data += get_bits_count(&gb)/8;
>  }
>  
> -extradata = av_packet_new_side_data(in, AV_PKT_DATA_NEW_EXTRADATA,
> +extradata = av_packet_new_side_data(pkt, AV_PKT_DATA_NEW_EXTRADATA,
>  2 + pce_size);
>  if (!extradata) {
>  ret = AVERROR(ENOMEM);
> @@ -120,17 +119,13 @@ static int aac_adtstoasc_filter(AVBSFContext *bsfc, 
> AVPacket *out)
>  ctx->first_frame_done = 1;
>  }
>  
> -finish:
> -av_packet_move_ref(out, in);
> -av_packet_free(&in);
> -
>  return 0;
>  
>  packet_too_small:
>  av_log(bsfc, AV_LOG_ERROR, "Input packet too small\n");
>  ret = AVERROR_INVALIDDATA;
>  fail:
> -av_packet_free(&in);
> +av_packet_unref(pkt);
>  return ret;
>  }
>  
> 

Will push later today.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 4/4] lavc, lavd, lavf, lavfi, tests: remove several register() calls

[Josh de Kock]

> On 18 Mar 2018, at 13:40, j...@itanimul.li wrote:
> 
> From: Josh de Kock 
> 
> ---
> doc/examples/filter_audio.c  | 2 --
> doc/examples/filtering_audio.c   | 2 --
> doc/examples/filtering_video.c   | 2 --
> doc/examples/transcoding.c   | 2 --
> fftools/ffmpeg.c | 6 --
> fftools/ffplay.c | 7 ---
> fftools/ffprobe.c| 4 
> libavcodec/tests/utils.c | 1 -
> libavdevice/lavfi.c  | 2 --
> libavfilter/lavfutils.c  | 2 --
> libavfilter/src_movie.c  | 2 --
> libavfilter/tests/filtfmts.c | 2 --
> libavformat/tests/movenc.c   | 2 --
> libavformat/tests/seek.c | 3 ---
> tests/api/api-band-test.c| 2 --
> tests/api/api-codec-param-test.c | 2 --
> tests/api/api-flac-test.c| 2 --
> tests/api/api-h264-test.c| 2 --
> tests/api/api-seek-test.c| 2 --
> tools/aviocat.c  | 1 -
> tools/enum_options.c | 2 --
> tools/graph2dot.c| 2 --
> tools/ismindex.c | 2 --
> tools/pktdumper.c| 3 ---
> tools/probetest.c| 3 ---
> tools/seek_print.c   | 1 -
> tools/sidxindex.c| 2 --
> tools/uncoded_frame.c| 4 
> 28 files changed, 69 deletions(-)
> 
> diff --git a/doc/examples/filter_audio.c b/doc/examples/filter_audio.c
> index 7467c21c30..1611e3d952 100644
> --- a/doc/examples/filter_audio.c
> +++ b/doc/examples/filter_audio.c
> @@ -289,8 +289,6 @@ int main(int argc, char *argv[])
> return 1;
> }
> 
> -avfilter_register_all();
> -
> /* Allocate the frame we will be using to store the data. */
> frame  = av_frame_alloc();
> if (!frame) {
> diff --git a/doc/examples/filtering_audio.c b/doc/examples/filtering_audio.c
> index 73a00e814c..b109dbcb96 100644
> --- a/doc/examples/filtering_audio.c
> +++ b/doc/examples/filtering_audio.c
> @@ -228,8 +228,6 @@ int main(int argc, char **argv)
> exit(1);
> }
> 
> -avfilter_register_all();
> -
> if ((ret = open_input_file(argv[1])) < 0)
> goto end;
> if ((ret = init_filters(filter_descr)) < 0)
> diff --git a/doc/examples/filtering_video.c b/doc/examples/filtering_video.c
> index 01d6644620..ed4e7bbd81 100644
> --- a/doc/examples/filtering_video.c
> +++ b/doc/examples/filtering_video.c
> @@ -222,8 +222,6 @@ int main(int argc, char **argv)
> exit(1);
> }
> 
> -avfilter_register_all();
> -
> if ((ret = open_input_file(argv[1])) < 0)
> goto end;
> if ((ret = init_filters(filter_descr)) < 0)
> diff --git a/doc/examples/transcoding.c b/doc/examples/transcoding.c
> index ed1fd6411b..a83fa3a185 100644
> --- a/doc/examples/transcoding.c
> +++ b/doc/examples/transcoding.c
> @@ -517,8 +517,6 @@ int main(int argc, char **argv)
> return 1;
> }
> 
> -avfilter_register_all();
> -
> if ((ret = open_input_file(argv[1])) < 0)
> goto end;
> if ((ret = open_output_file(argv[2])) < 0)
> diff --git a/fftools/ffmpeg.c b/fftools/ffmpeg.c
> index ee7258fcd1..47236774ef 100644
> --- a/fftools/ffmpeg.c
> +++ b/fftools/ffmpeg.c
> @@ -4803,12 +4803,6 @@ int main(int argc, char **argv)
> argv++;
> }
> 
> -avcodec_register_all();
> -#if CONFIG_AVDEVICE
> -avdevice_register_all();
> -#endif
> -avfilter_register_all();
> -av_register_all();
> avformat_network_init();
> 
> show_banner(argc, argv, options);
> diff --git a/fftools/ffplay.c b/fftools/ffplay.c
> index f2028d4b13..05a1e7a68d 100644
> --- a/fftools/ffplay.c
> +++ b/fftools/ffplay.c
> @@ -3652,13 +3652,6 @@ int main(int argc, char **argv)
> parse_loglevel(argc, argv, options);
> 
> /* register all codecs, demux and protocols */
> -#if CONFIG_AVDEVICE
> -avdevice_register_all();
> -#endif
> -#if CONFIG_AVFILTER
> -avfilter_register_all();
> -#endif
> -av_register_all();
> avformat_network_init();
> 
> init_opts();
> diff --git a/fftools/ffprobe.c b/fftools/ffprobe.c
> index a4ac6972a2..540ad9f6fe 100644
> --- a/fftools/ffprobe.c
> +++ b/fftools/ffprobe.c
> @@ -3567,12 +3567,8 @@ int main(int argc, char **argv)
> 
> options = real_options;
> parse_loglevel(argc, argv, options);
> -av_register_all();
> avformat_network_init();
> init_opts();
> -#if CONFIG_AVDEVICE
> -avdevice_register_all();
> -#endif
> 
> show_banner(argc, argv, options);
> parse_options(NULL, argc, argv, options, opt_input_file);
> diff --git a/libavcodec/tests/utils.c b/libavcodec/tests/utils.c
> index e2891fb389..f6ba7fe66e 100644
> --- a/libavcodec/tests/utils.c
> +++ b/libavcodec/tests/utils.c
> @@ -21,7 +21,6 @@
> int main(void){
> AVCodec *codec = NULL;
> int ret = 0;
> -avcodec_register_all();
> 
> while (codec = av_codec_next(codec)) {
> if (av_codec_is_encoder(codec)) {
> diff --git a/libavdevice/lavfi.c b/libavdevice/lavfi.c
> index 6f2ae958dc..ca8f05f3f7 100644
> --- a/libavdevice/

Re: [FFmpeg-devel] [PATCH 1/4] checkasm/Makefile: add EXTRALIBS-libavformat

[Carl Eugen Hoyos]

2018-03-18 14:40 GMT+01:00, j...@itanimul.li :
> From: Josh de Kock 

You could add a line that explains for which configure-option this
fixes something.
(I guess there is a configure option that needs this.)

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

Re: [FFmpeg-devel] [PATCH]avfilter/astreamslect: fixing activating in some cases

[Carl Eugen Hoyos]

2018-03-18 13:57 GMT+01:00, Nicolas George :
> Bodecs Bela (2018-03-17):
>> with my patch it works good.
>
> Thanks for the details. After more careful examination, I confirm my
> first impression: calling ff_filter_set_ready() from the framesync
> callback would be wrong. But this filter already misuses internal APIs
> (for example re-calling avfilter_config_links() after init) and contains
> several easily spotted bugs.

Not knowing what this is all about, I believe you should elaborate a
little.

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

Re: [FFmpeg-devel] swscale/rgb2rgb : add X86_64 SIMD (SSSE3 and AVX2) for shuffly_bytes func

[Martin Vignali]

2018-03-03 18:20 GMT+01:00 Martin Vignali :

> Hello,
>
> Patch in attach add SIMD for the 5 shuffle_bytes func for rgb2rgb
> The new SIMD are write using external ASM.
>
> Also add checkasm test for theses func
> Restricted to x86_64, because the scalar part doesn't compile on x86_32
>
> I consider for the scalar part that the src_size value is a multiple of 4
> (because the shuffle is for 4 bytes)
>
> Pass fate test on X86_64 and X86_32 (os 10.12)
>
>
>
>
> New patchs in attach :
- Now compile on x86_32 and x86_64
- Add cosmetic patch to put all shuffle_bytes declaration in the same place

Tested on X86_64 and X86_32 (os 10.12)

Checkasm result :  ./tests/checkasm/checkasm --test=sw_rgb --bench

checkasm: using random seed 292997963
MMX:
 - sw_rgb.shuffle_bytes_2103 [OK]
MMXEXT:
 - sw_rgb.shuffle_bytes_2103 [OK]
SSSE3:
 - sw_rgb.shuffle_bytes_2103 [OK]
 - sw_rgb.shuffle_bytes_0321 [OK]
 - sw_rgb.shuffle_bytes_1230 [OK]
 - sw_rgb.shuffle_bytes_3012 [OK]
 - sw_rgb.shuffle_bytes_3210 [OK]
AVX2:
 - sw_rgb.shuffle_bytes_2103 [OK]
 - sw_rgb.shuffle_bytes_0321 [OK]
 - sw_rgb.shuffle_bytes_1230 [OK]
 - sw_rgb.shuffle_bytes_3012 [OK]
 - sw_rgb.shuffle_bytes_3210 [OK]
checkasm: all 12 tests passed
shuffle_bytes_0321_c: 51.4
shuffle_bytes_0321_ssse3: 18.7
shuffle_bytes_0321_avx2: 12.7
shuffle_bytes_1230_c: 126.9
shuffle_bytes_1230_ssse3: 16.7
shuffle_bytes_1230_avx2: 12.9
shuffle_bytes_2103_c: 52.4
shuffle_bytes_2103_mmx: 76.7
shuffle_bytes_2103_mmxext: 197.2
shuffle_bytes_2103_ssse3: 17.4
shuffle_bytes_2103_avx2: 12.4
shuffle_bytes_3012_c: 127.4
shuffle_bytes_3012_ssse3: 14.7
shuffle_bytes_3012_avx2: 12.4
shuffle_bytes_3210_c: 127.4
shuffle_bytes_3210_ssse3: 18.2
shuffle_bytes_3210_avx2: 12.9


Martin


0001-swscale-rgb-add-X86-SIMD-SSSE3-AVX2-for.patch
Description: Binary data


0002-swscale-rgb-add-X86-SIMD-SSSE3-AVX2-for.patch
Description: Binary data


0003-checkasm-swscale-add-test-for-rgb-shuffle_bytes-func.patch
Description: Binary data


0004-swscale-rgb2rgb-cosmetic-move-shuffle_bytes-func-dec.patch
Description: Binary data
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 1/4] checkasm/Makefile: add EXTRALIBS-libavformat

[James Almer]

On 3/18/2018 10:40 AM, j...@itanimul.li wrote:
> From: Josh de Kock 
> 
> ---
>  tests/checkasm/Makefile | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/tests/checkasm/Makefile b/tests/checkasm/Makefile
> index 0520e264e2..ae7e810d25 100644
> --- a/tests/checkasm/Makefile
> +++ b/tests/checkasm/Makefile
> @@ -61,7 +61,7 @@ tests/checkasm/checkasm.o: CFLAGS += -Umain
>  CHECKASM := tests/checkasm/checkasm$(EXESUF)
>  
>  $(CHECKASM): $(CHECKASMOBJS) $(FF_STATIC_DEP_LIBS)
> - $(LD) $(LDFLAGS) $(LDEXEFLAGS) $(LD_O) $(CHECKASMOBJS) 
> $(FF_STATIC_DEP_LIBS) $(EXTRALIBS-avcodec) $(EXTRALIBS-avfilter) 
> $(EXTRALIBS-avutil) $(EXTRALIBS-swresample) $(EXTRALIBS)
> + $(LD) $(LDFLAGS) $(LDEXEFLAGS) $(LD_O) $(CHECKASMOBJS) 
> $(FF_STATIC_DEP_LIBS) $(EXTRALIBS-avcodec) $(EXTRALIBS-avfilter) 
> $(EXTRALIBS-avformat) $(EXTRALIBS-avutil) $(EXTRALIBS-swresample) $(EXTRALIBS)

This is not the correct fix. We currently only need to link to avcodec,
avfilter and avutil here, which may or may not depend on other fflibs.
Seeing swresample there already hints that this line got duct tape fixes
as linking failures popped up. How long until someone gets a linking
failure pointing to swscale or postproc, seeing avfilter may link to it
depending on enabled filters, much like it does with avformat?

The *_FFLIBS variables in config.mak list these dependencies per lib,
and should be used to assemble a proper linking command here.

>  
>  checkasm: $(CHECKASM)
>  
> 

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

Re: [FFmpeg-devel] [PATCH 1/4] checkasm/Makefile: add EXTRALIBS-libavformat

[Paul B Mahol]

On 3/18/18, James Almer  wrote:
> On 3/18/2018 10:40 AM, j...@itanimul.li wrote:
>> From: Josh de Kock 
>>
>> ---
>>  tests/checkasm/Makefile | 2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/tests/checkasm/Makefile b/tests/checkasm/Makefile
>> index 0520e264e2..ae7e810d25 100644
>> --- a/tests/checkasm/Makefile
>> +++ b/tests/checkasm/Makefile
>> @@ -61,7 +61,7 @@ tests/checkasm/checkasm.o: CFLAGS += -Umain
>>  CHECKASM := tests/checkasm/checkasm$(EXESUF)
>>
>>  $(CHECKASM): $(CHECKASMOBJS) $(FF_STATIC_DEP_LIBS)
>> -$(LD) $(LDFLAGS) $(LDEXEFLAGS) $(LD_O) $(CHECKASMOBJS)
>> $(FF_STATIC_DEP_LIBS) $(EXTRALIBS-avcodec) $(EXTRALIBS-avfilter)
>> $(EXTRALIBS-avutil) $(EXTRALIBS-swresample) $(EXTRALIBS)
>> +$(LD) $(LDFLAGS) $(LDEXEFLAGS) $(LD_O) $(CHECKASMOBJS)
>> $(FF_STATIC_DEP_LIBS) $(EXTRALIBS-avcodec) $(EXTRALIBS-avfilter)
>> $(EXTRALIBS-avformat) $(EXTRALIBS-avutil) $(EXTRALIBS-swresample)
>> $(EXTRALIBS)
>
> This is not the correct fix. We currently only need to link to avcodec,
> avfilter and avutil here, which may or may not depend on other fflibs.
> Seeing swresample there already hints that this line got duct tape fixes
> as linking failures popped up. How long until someone gets a linking
> failure pointing to swscale or postproc, seeing avfilter may link to it
> depending on enabled filters, much like it does with avformat?
>
> The *_FFLIBS variables in config.mak list these dependencies per lib,
> and should be used to assemble a proper linking command here.
>
>>
>>  checkasm: $(CHECKASM)
>>
>>
>
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>

Try patchset without it and than complain instead.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] swscale/rgb2rgb : add X86_64 SIMD (SSSE3 and AVX2) for shuffly_bytes func

[Carl Eugen Hoyos]

2018-03-18 16:08 GMT+01:00, Martin Vignali :

> shuffle_bytes_0321_c: 51.4
> shuffle_bytes_0321_ssse3: 18.7
> shuffle_bytes_0321_avx2: 12.7
> shuffle_bytes_1230_c: 126.9
> shuffle_bytes_1230_ssse3: 16.7
> shuffle_bytes_1230_avx2: 12.9
> shuffle_bytes_2103_c: 52.4
> shuffle_bytes_2103_mmx: 76.7
> shuffle_bytes_2103_mmxext: 197.2
> shuffle_bytes_2103_ssse3: 17.4
> shuffle_bytes_2103_avx2: 12.4
> shuffle_bytes_3012_c: 127.4
> shuffle_bytes_3012_ssse3: 14.7
> shuffle_bytes_3012_avx2: 12.4
> shuffle_bytes_3210_c: 127.4
> shuffle_bytes_3210_ssse3: 18.2
> shuffle_bytes_3210_avx2: 12.9

Does the patch have measurable overall impact?

Thank you, Carl Eugen
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] swscale/rgb2rgb : add X86_64 SIMD (SSSE3 and AVX2) for shuffly_bytes func

[James Almer]

On 3/18/2018 12:08 PM, Martin Vignali wrote:
> 2018-03-03 18:20 GMT+01:00 Martin Vignali :
> 
>> Hello,
>>
>> Patch in attach add SIMD for the 5 shuffle_bytes func for rgb2rgb
>> The new SIMD are write using external ASM.
>>
>> Also add checkasm test for theses func
>> Restricted to x86_64, because the scalar part doesn't compile on x86_32
>>
>> I consider for the scalar part that the src_size value is a multiple of 4
>> (because the shuffle is for 4 bytes)
>>
>> Pass fate test on X86_64 and X86_32 (os 10.12)
>>
>>
>>
>>
>> New patchs in attach :
> - Now compile on x86_32 and x86_64
> - Add cosmetic patch to put all shuffle_bytes declaration in the same place
> 
> Tested on X86_64 and X86_32 (os 10.12)
> 
> Checkasm result :  ./tests/checkasm/checkasm --test=sw_rgb --bench
> 
> checkasm: using random seed 292997963
> MMX:
>  - sw_rgb.shuffle_bytes_2103 [OK]
> MMXEXT:
>  - sw_rgb.shuffle_bytes_2103 [OK]
> SSSE3:
>  - sw_rgb.shuffle_bytes_2103 [OK]
>  - sw_rgb.shuffle_bytes_0321 [OK]
>  - sw_rgb.shuffle_bytes_1230 [OK]
>  - sw_rgb.shuffle_bytes_3012 [OK]
>  - sw_rgb.shuffle_bytes_3210 [OK]
> AVX2:
>  - sw_rgb.shuffle_bytes_2103 [OK]
>  - sw_rgb.shuffle_bytes_0321 [OK]
>  - sw_rgb.shuffle_bytes_1230 [OK]
>  - sw_rgb.shuffle_bytes_3012 [OK]
>  - sw_rgb.shuffle_bytes_3210 [OK]
> checkasm: all 12 tests passed
> shuffle_bytes_0321_c: 51.4
> shuffle_bytes_0321_ssse3: 18.7
> shuffle_bytes_0321_avx2: 12.7
> shuffle_bytes_1230_c: 126.9
> shuffle_bytes_1230_ssse3: 16.7
> shuffle_bytes_1230_avx2: 12.9
> shuffle_bytes_2103_c: 52.4
> shuffle_bytes_2103_mmx: 76.7
> shuffle_bytes_2103_mmxext: 197.2
> shuffle_bytes_2103_ssse3: 17.4
> shuffle_bytes_2103_avx2: 12.4
> shuffle_bytes_3012_c: 127.4
> shuffle_bytes_3012_ssse3: 14.7
> shuffle_bytes_3012_avx2: 12.4
> shuffle_bytes_3210_c: 127.4
> shuffle_bytes_3210_ssse3: 18.2
> shuffle_bytes_3210_avx2: 12.9

These AVX2 numbers are not worth it. Some CPU archs throttle down the
frequency when using ymm instructions, so unless the function is
considerably faster than the SSE* version then it's usually not worth
adding.

> 
> 
> Martin
> 
> 
> 
> ___
> 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 1/4] checkasm/Makefile: add EXTRALIBS-libavformat

[James Almer]

On 3/18/2018 12:17 PM, Paul B Mahol wrote:
> On 3/18/18, James Almer  wrote:
>> On 3/18/2018 10:40 AM, j...@itanimul.li wrote:
>>> From: Josh de Kock 
>>>
>>> ---
>>>  tests/checkasm/Makefile | 2 +-
>>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>>
>>> diff --git a/tests/checkasm/Makefile b/tests/checkasm/Makefile
>>> index 0520e264e2..ae7e810d25 100644
>>> --- a/tests/checkasm/Makefile
>>> +++ b/tests/checkasm/Makefile
>>> @@ -61,7 +61,7 @@ tests/checkasm/checkasm.o: CFLAGS += -Umain
>>>  CHECKASM := tests/checkasm/checkasm$(EXESUF)
>>>
>>>  $(CHECKASM): $(CHECKASMOBJS) $(FF_STATIC_DEP_LIBS)
>>> -   $(LD) $(LDFLAGS) $(LDEXEFLAGS) $(LD_O) $(CHECKASMOBJS)
>>> $(FF_STATIC_DEP_LIBS) $(EXTRALIBS-avcodec) $(EXTRALIBS-avfilter)
>>> $(EXTRALIBS-avutil) $(EXTRALIBS-swresample) $(EXTRALIBS)
>>> +   $(LD) $(LDFLAGS) $(LDEXEFLAGS) $(LD_O) $(CHECKASMOBJS)
>>> $(FF_STATIC_DEP_LIBS) $(EXTRALIBS-avcodec) $(EXTRALIBS-avfilter)
>>> $(EXTRALIBS-avformat) $(EXTRALIBS-avutil) $(EXTRALIBS-swresample)
>>> $(EXTRALIBS)
>>
>> This is not the correct fix. We currently only need to link to avcodec,
>> avfilter and avutil here, which may or may not depend on other fflibs.
>> Seeing swresample there already hints that this line got duct tape fixes
>> as linking failures popped up. How long until someone gets a linking
>> failure pointing to swscale or postproc, seeing avfilter may link to it
>> depending on enabled filters, much like it does with avformat?
>>
>> The *_FFLIBS variables in config.mak list these dependencies per lib,
>> and should be used to assemble a proper linking command here.
>>
>>>
>>>  checkasm: $(CHECKASM)
>>>
>>>
>>
>> ___
>> ffmpeg-devel mailing list
>> ffmpeg-devel@ffmpeg.org
>> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>>
> 
> Try patchset without it and than complain instead.

I'm not saying it's not needed, I'm saying it's not the correct way to
fix the linking failure the following patches would introduce.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 1/4] checkasm/Makefile: add EXTRALIBS-libavformat

[Paul B Mahol]

On 3/18/18, James Almer  wrote:
> On 3/18/2018 12:17 PM, Paul B Mahol wrote:
>> On 3/18/18, James Almer  wrote:
>>> On 3/18/2018 10:40 AM, j...@itanimul.li wrote:
 From: Josh de Kock 

 ---
  tests/checkasm/Makefile | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

 diff --git a/tests/checkasm/Makefile b/tests/checkasm/Makefile
 index 0520e264e2..ae7e810d25 100644
 --- a/tests/checkasm/Makefile
 +++ b/tests/checkasm/Makefile
 @@ -61,7 +61,7 @@ tests/checkasm/checkasm.o: CFLAGS += -Umain
  CHECKASM := tests/checkasm/checkasm$(EXESUF)

  $(CHECKASM): $(CHECKASMOBJS) $(FF_STATIC_DEP_LIBS)
 -  $(LD) $(LDFLAGS) $(LDEXEFLAGS) $(LD_O) $(CHECKASMOBJS)
 $(FF_STATIC_DEP_LIBS) $(EXTRALIBS-avcodec) $(EXTRALIBS-avfilter)
 $(EXTRALIBS-avutil) $(EXTRALIBS-swresample) $(EXTRALIBS)
 +  $(LD) $(LDFLAGS) $(LDEXEFLAGS) $(LD_O) $(CHECKASMOBJS)
 $(FF_STATIC_DEP_LIBS) $(EXTRALIBS-avcodec) $(EXTRALIBS-avfilter)
 $(EXTRALIBS-avformat) $(EXTRALIBS-avutil) $(EXTRALIBS-swresample)
 $(EXTRALIBS)
>>>
>>> This is not the correct fix. We currently only need to link to avcodec,
>>> avfilter and avutil here, which may or may not depend on other fflibs.
>>> Seeing swresample there already hints that this line got duct tape fixes
>>> as linking failures popped up. How long until someone gets a linking
>>> failure pointing to swscale or postproc, seeing avfilter may link to it
>>> depending on enabled filters, much like it does with avformat?
>>>
>>> The *_FFLIBS variables in config.mak list these dependencies per lib,
>>> and should be used to assemble a proper linking command here.
>>>

  checkasm: $(CHECKASM)


>>>
>>> ___
>>> ffmpeg-devel mailing list
>>> ffmpeg-devel@ffmpeg.org
>>> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>>>
>>
>> Try patchset without it and than complain instead.
>
> I'm not saying it's not needed, I'm saying it's not the correct way to
> fix the linking failure the following patches would introduce.

And how do you know that?, without even providing alternative?
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] swscale/rgb2rgb : add X86_64 SIMD (SSSE3 and AVX2) for shuffly_bytes func

[Martin Vignali]

2018-03-18 16:49 GMT+01:00 James Almer :

> On 3/18/2018 12:08 PM, Martin Vignali wrote:
> > 2018-03-03 18:20 GMT+01:00 Martin Vignali :
> >
> >> Hello,
> >>
> >> Patch in attach add SIMD for the 5 shuffle_bytes func for rgb2rgb
> >> The new SIMD are write using external ASM.
> >>
> >> Also add checkasm test for theses func
> >> Restricted to x86_64, because the scalar part doesn't compile on x86_32
> >>
> >> I consider for the scalar part that the src_size value is a multiple of
> 4
> >> (because the shuffle is for 4 bytes)
> >>
> >> Pass fate test on X86_64 and X86_32 (os 10.12)
> >>
> >>
> >>
> >>
> >> New patchs in attach :
> > - Now compile on x86_32 and x86_64
> > - Add cosmetic patch to put all shuffle_bytes declaration in the same
> place
> >
> > Tested on X86_64 and X86_32 (os 10.12)
> >
> > Checkasm result :  ./tests/checkasm/checkasm --test=sw_rgb --bench
> >
> > checkasm: using random seed 292997963
> > MMX:
> >  - sw_rgb.shuffle_bytes_2103 [OK]
> > MMXEXT:
> >  - sw_rgb.shuffle_bytes_2103 [OK]
> > SSSE3:
> >  - sw_rgb.shuffle_bytes_2103 [OK]
> >  - sw_rgb.shuffle_bytes_0321 [OK]
> >  - sw_rgb.shuffle_bytes_1230 [OK]
> >  - sw_rgb.shuffle_bytes_3012 [OK]
> >  - sw_rgb.shuffle_bytes_3210 [OK]
> > AVX2:
> >  - sw_rgb.shuffle_bytes_2103 [OK]
> >  - sw_rgb.shuffle_bytes_0321 [OK]
> >  - sw_rgb.shuffle_bytes_1230 [OK]
> >  - sw_rgb.shuffle_bytes_3012 [OK]
> >  - sw_rgb.shuffle_bytes_3210 [OK]
> > checkasm: all 12 tests passed
> > shuffle_bytes_0321_c: 51.4
> > shuffle_bytes_0321_ssse3: 18.7
> > shuffle_bytes_0321_avx2: 12.7
> > shuffle_bytes_1230_c: 126.9
> > shuffle_bytes_1230_ssse3: 16.7
> > shuffle_bytes_1230_avx2: 12.9
> > shuffle_bytes_2103_c: 52.4
> > shuffle_bytes_2103_mmx: 76.7
> > shuffle_bytes_2103_mmxext: 197.2
> > shuffle_bytes_2103_ssse3: 17.4
> > shuffle_bytes_2103_avx2: 12.4
> > shuffle_bytes_3012_c: 127.4
> > shuffle_bytes_3012_ssse3: 14.7
> > shuffle_bytes_3012_avx2: 12.4
> > shuffle_bytes_3210_c: 127.4
> > shuffle_bytes_3210_ssse3: 18.2
> > shuffle_bytes_3210_avx2: 12.9
>
> These AVX2 numbers are not worth it. Some CPU archs throttle down the
> frequency when using ymm instructions, so unless the function is
> considerably faster than the SSE* version then it's usually not worth
> adding.
>
>
I run the test again with a bigger width (512 instead of 128)
This is my result :
shuffle_bytes_0321_c: 128.6
shuffle_bytes_0321_ssse3: 41.6
shuffle_bytes_0321_avx2: 23.4
shuffle_bytes_1230_c: 626.4
shuffle_bytes_1230_ssse3: 41.6
shuffle_bytes_1230_avx2: 23.9
shuffle_bytes_2103_c: 128.4
shuffle_bytes_2103_mmx: 307.1
shuffle_bytes_2103_mmxext: 224.6
shuffle_bytes_2103_ssse3: 72.9
shuffle_bytes_2103_avx2: 32.9
shuffle_bytes_3012_c: 620.9
shuffle_bytes_3012_ssse3: 40.6
shuffle_bytes_3012_avx2: 36.1
shuffle_bytes_3210_c: 602.6
shuffle_bytes_3210_ssse3: 75.4
shuffle_bytes_3210_avx2: 33.6


So except for the 3012 version (don't know why), we are around x2 in AVX2.
Do you still think, it's need to remove AVX2 version ?


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

Re: [FFmpeg-devel] swscale/rgb2rgb : add X86_64 SIMD (SSSE3 and AVX2) for shuffly_bytes func

[James Almer]

On 3/18/2018 1:23 PM, Martin Vignali wrote:
> 2018-03-18 16:49 GMT+01:00 James Almer :
> 
>> On 3/18/2018 12:08 PM, Martin Vignali wrote:
>>> 2018-03-03 18:20 GMT+01:00 Martin Vignali :
>>>
 Hello,

 Patch in attach add SIMD for the 5 shuffle_bytes func for rgb2rgb
 The new SIMD are write using external ASM.

 Also add checkasm test for theses func
 Restricted to x86_64, because the scalar part doesn't compile on x86_32

 I consider for the scalar part that the src_size value is a multiple of
>> 4
 (because the shuffle is for 4 bytes)

 Pass fate test on X86_64 and X86_32 (os 10.12)




 New patchs in attach :
>>> - Now compile on x86_32 and x86_64
>>> - Add cosmetic patch to put all shuffle_bytes declaration in the same
>> place
>>>
>>> Tested on X86_64 and X86_32 (os 10.12)
>>>
>>> Checkasm result :  ./tests/checkasm/checkasm --test=sw_rgb --bench
>>>
>>> checkasm: using random seed 292997963
>>> MMX:
>>>  - sw_rgb.shuffle_bytes_2103 [OK]
>>> MMXEXT:
>>>  - sw_rgb.shuffle_bytes_2103 [OK]
>>> SSSE3:
>>>  - sw_rgb.shuffle_bytes_2103 [OK]
>>>  - sw_rgb.shuffle_bytes_0321 [OK]
>>>  - sw_rgb.shuffle_bytes_1230 [OK]
>>>  - sw_rgb.shuffle_bytes_3012 [OK]
>>>  - sw_rgb.shuffle_bytes_3210 [OK]
>>> AVX2:
>>>  - sw_rgb.shuffle_bytes_2103 [OK]
>>>  - sw_rgb.shuffle_bytes_0321 [OK]
>>>  - sw_rgb.shuffle_bytes_1230 [OK]
>>>  - sw_rgb.shuffle_bytes_3012 [OK]
>>>  - sw_rgb.shuffle_bytes_3210 [OK]
>>> checkasm: all 12 tests passed
>>> shuffle_bytes_0321_c: 51.4
>>> shuffle_bytes_0321_ssse3: 18.7
>>> shuffle_bytes_0321_avx2: 12.7
>>> shuffle_bytes_1230_c: 126.9
>>> shuffle_bytes_1230_ssse3: 16.7
>>> shuffle_bytes_1230_avx2: 12.9
>>> shuffle_bytes_2103_c: 52.4
>>> shuffle_bytes_2103_mmx: 76.7
>>> shuffle_bytes_2103_mmxext: 197.2
>>> shuffle_bytes_2103_ssse3: 17.4
>>> shuffle_bytes_2103_avx2: 12.4
>>> shuffle_bytes_3012_c: 127.4
>>> shuffle_bytes_3012_ssse3: 14.7
>>> shuffle_bytes_3012_avx2: 12.4
>>> shuffle_bytes_3210_c: 127.4
>>> shuffle_bytes_3210_ssse3: 18.2
>>> shuffle_bytes_3210_avx2: 12.9
>>
>> These AVX2 numbers are not worth it. Some CPU archs throttle down the
>> frequency when using ymm instructions, so unless the function is
>> considerably faster than the SSE* version then it's usually not worth
>> adding.
>>
>>
> I run the test again with a bigger width (512 instead of 128)
> This is my result :
> shuffle_bytes_0321_c: 128.6
> shuffle_bytes_0321_ssse3: 41.6
> shuffle_bytes_0321_avx2: 23.4
> shuffle_bytes_1230_c: 626.4
> shuffle_bytes_1230_ssse3: 41.6
> shuffle_bytes_1230_avx2: 23.9
> shuffle_bytes_2103_c: 128.4
> shuffle_bytes_2103_mmx: 307.1
> shuffle_bytes_2103_mmxext: 224.6
> shuffle_bytes_2103_ssse3: 72.9
> shuffle_bytes_2103_avx2: 32.9
> shuffle_bytes_3012_c: 620.9
> shuffle_bytes_3012_ssse3: 40.6
> shuffle_bytes_3012_avx2: 36.1
> shuffle_bytes_3210_c: 602.6
> shuffle_bytes_3210_ssse3: 75.4
> shuffle_bytes_3210_avx2: 33.6
> 
> 
> So except for the 3012 version (don't know why), we are around x2 in AVX2.
> Do you still think, it's need to remove AVX2 version ?
> 
> 
> Martin

No, those look good now.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] swscale/rgb2rgb : add X86_64 SIMD (SSSE3 and AVX2) for shuffly_bytes func

[Nicolas George]

Martin Vignali (2018-03-18):
> I run the test again with a bigger width (512 instead of 128)
> This is my result :
> shuffle_bytes_0321_c: 128.6
> shuffle_bytes_0321_ssse3: 41.6
> shuffle_bytes_0321_avx2: 23.4

IIUC, these benchmarks are expressed in CPU cycles. But what James says
is that it can cause the CPU frequency to be throttled: if that happens,
less cycles can use more time, and even worse, cause other unrelated to
take more time. A benchmark in actual time and typical use case would be
needed to decide.

Regards,

-- 
  Nicolas George


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

Re: [FFmpeg-devel] swscale/rgb2rgb : add X86_64 SIMD (SSSE3 and AVX2) for shuffly_bytes func

[Paul B Mahol]

On 3/18/18, Nicolas George  wrote:
> Martin Vignali (2018-03-18):
>> I run the test again with a bigger width (512 instead of 128)
>> This is my result :
>> shuffle_bytes_0321_c: 128.6
>> shuffle_bytes_0321_ssse3: 41.6
>> shuffle_bytes_0321_avx2: 23.4
>
> IIUC, these benchmarks are expressed in CPU cycles. But what James says
> is that it can cause the CPU frequency to be throttled: if that happens,
> less cycles can use more time, and even worse, cause other unrelated to
> take more time. A benchmark in actual time and typical use case would be
> needed to decide.

Yes, always also test overall with typical code usecase.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 1/4] checkasm/Makefile: add EXTRALIBS-libavformat

[James Almer]

On 3/18/2018 1:06 PM, Paul B Mahol wrote:
> On 3/18/18, James Almer  wrote:
>> On 3/18/2018 12:17 PM, Paul B Mahol wrote:
>>> On 3/18/18, James Almer  wrote:
 On 3/18/2018 10:40 AM, j...@itanimul.li wrote:
> From: Josh de Kock 
>
> ---
>  tests/checkasm/Makefile | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/tests/checkasm/Makefile b/tests/checkasm/Makefile
> index 0520e264e2..ae7e810d25 100644
> --- a/tests/checkasm/Makefile
> +++ b/tests/checkasm/Makefile
> @@ -61,7 +61,7 @@ tests/checkasm/checkasm.o: CFLAGS += -Umain
>  CHECKASM := tests/checkasm/checkasm$(EXESUF)
>
>  $(CHECKASM): $(CHECKASMOBJS) $(FF_STATIC_DEP_LIBS)
> - $(LD) $(LDFLAGS) $(LDEXEFLAGS) $(LD_O) $(CHECKASMOBJS)
> $(FF_STATIC_DEP_LIBS) $(EXTRALIBS-avcodec) $(EXTRALIBS-avfilter)
> $(EXTRALIBS-avutil) $(EXTRALIBS-swresample) $(EXTRALIBS)
> + $(LD) $(LDFLAGS) $(LDEXEFLAGS) $(LD_O) $(CHECKASMOBJS)
> $(FF_STATIC_DEP_LIBS) $(EXTRALIBS-avcodec) $(EXTRALIBS-avfilter)
> $(EXTRALIBS-avformat) $(EXTRALIBS-avutil) $(EXTRALIBS-swresample)
> $(EXTRALIBS)

 This is not the correct fix. We currently only need to link to avcodec,
 avfilter and avutil here, which may or may not depend on other fflibs.
 Seeing swresample there already hints that this line got duct tape fixes
 as linking failures popped up. How long until someone gets a linking
 failure pointing to swscale or postproc, seeing avfilter may link to it
 depending on enabled filters, much like it does with avformat?

 The *_FFLIBS variables in config.mak list these dependencies per lib,
 and should be used to assemble a proper linking command here.

>
>  checkasm: $(CHECKASM)
>
>

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

>>>
>>> Try patchset without it and than complain instead.
>>
>> I'm not saying it's not needed, I'm saying it's not the correct way to
>> fix the linking failure the following patches would introduce.
> 
> And how do you know that?, without even providing alternative?

I provided an alternative. Look at my comment about the *_FFLIBS
variables. The build system already uses it when linking the libraries
themselves.
The build system has a lot of measures to only build the required
objects and only link the required libraries based on configure time
options. Hardcoding avformat and swresample extralibs for this
executable when avcodec and avfilter may be built without the modules
that require said libraries is doing the exact opposite of that.

Sure, we can commit this as a "temporary" fix, seeing that something
needs to be done in a timely manner so the iterate() api can be
committed, but the result will be that nobody will bother to implement
it right afterwards.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] swscale/rgb2rgb : add X86_64 SIMD (SSSE3 and AVX2) for shuffly_bytes func

[Martin Vignali]

2018-03-18 17:37 GMT+01:00 Paul B Mahol :

> On 3/18/18, Nicolas George  wrote:
> > Martin Vignali (2018-03-18):
> >> I run the test again with a bigger width (512 instead of 128)
> >> This is my result :
> >> shuffle_bytes_0321_c: 128.6
> >> shuffle_bytes_0321_ssse3: 41.6
> >> shuffle_bytes_0321_avx2: 23.4
> >
> > IIUC, these benchmarks are expressed in CPU cycles. But what James says
> > is that it can cause the CPU frequency to be throttled: if that happens,
> > less cycles can use more time, and even worse, cause other unrelated to
> > take more time. A benchmark in actual time and typical use case would be
> > needed to decide.
>
> Yes, always also test overall with typical code usecase.
>
>
I tested it using a "benchmark" command line, who test two shuffle func
./ffmpeg -benchmark -f lavfi -i rgbtestsrc=size=3840x2160:duration=10 -vf
format=argb,format=rgba -f null -

With the patch :
bench: utime=3.611s
With only SSSE 3 (disable AVX2 part), i have similar result.

Without the patch :
bench: utime=6.972s

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

Re: [FFmpeg-devel] swscale/rgb2rgb : add X86_64 SIMD (SSSE3 and AVX2) for shuffly_bytes func

[James Almer]

On 3/18/2018 1:28 PM, Nicolas George wrote:
> Martin Vignali (2018-03-18):
>> I run the test again with a bigger width (512 instead of 128)
>> This is my result :
>> shuffle_bytes_0321_c: 128.6
>> shuffle_bytes_0321_ssse3: 41.6
>> shuffle_bytes_0321_avx2: 23.4
> 
> IIUC, these benchmarks are expressed in CPU cycles. But what James says
> is that it can cause the CPU frequency to be throttled: if that happens,
> less cycles can use more time, and even worse, cause other unrelated to
> take more time. A benchmark in actual time and typical use case would be
> needed to decide.
> 
> Regards,

In any case, short of swscale being used without any decoding going on,
AVX2 code is most likely going to be used and said throttling will
already have taken place because countless other functions.

And 2x speed up from an AVX2 version is basically the best you're going
to get out of such an implementation.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] swscale/rgb2rgb : add X86_64 SIMD (SSSE3 and AVX2) for shuffly_bytes func

[Carl Eugen Hoyos]

2018-03-18 17:46 GMT+01:00, Martin Vignali :
> 2018-03-18 17:37 GMT+01:00 Paul B Mahol :
>
>> On 3/18/18, Nicolas George  wrote:
>> > Martin Vignali (2018-03-18):
>> >> I run the test again with a bigger width (512 instead of 128)
>> >> This is my result :
>> >> shuffle_bytes_0321_c: 128.6
>> >> shuffle_bytes_0321_ssse3: 41.6
>> >> shuffle_bytes_0321_avx2: 23.4
>> >
>> > IIUC, these benchmarks are expressed in CPU cycles. But what James says
>> > is that it can cause the CPU frequency to be throttled: if that happens,
>> > less cycles can use more time, and even worse, cause other unrelated to
>> > take more time. A benchmark in actual time and typical use case would be
>> > needed to decide.
>>
>> Yes, always also test overall with typical code usecase.

+1

> I tested it using a "benchmark" command line, who test two shuffle func
> ./ffmpeg -benchmark -f lavfi -i rgbtestsrc=size=3840x2160:duration=10 -vf
> format=argb,format=rgba -f null -
>
> With the patch :
> bench: utime=3.611s
> With only SSSE 3 (disable AVX2 part), i have similar result.

Indicating James' original comment that the avx2 optimization
makes no sense is correct?

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

Re: [FFmpeg-devel] swscale/rgb2rgb : add X86_64 SIMD (SSSE3 and AVX2) for shuffly_bytes func

[Paul B Mahol]

On 3/18/18, Carl Eugen Hoyos  wrote:
> 2018-03-18 17:46 GMT+01:00, Martin Vignali :
>> 2018-03-18 17:37 GMT+01:00 Paul B Mahol :
>>
>>> On 3/18/18, Nicolas George  wrote:
>>> > Martin Vignali (2018-03-18):
>>> >> I run the test again with a bigger width (512 instead of 128)
>>> >> This is my result :
>>> >> shuffle_bytes_0321_c: 128.6
>>> >> shuffle_bytes_0321_ssse3: 41.6
>>> >> shuffle_bytes_0321_avx2: 23.4
>>> >
>>> > IIUC, these benchmarks are expressed in CPU cycles. But what James says
>>> > is that it can cause the CPU frequency to be throttled: if that
>>> > happens,
>>> > less cycles can use more time, and even worse, cause other unrelated to
>>> > take more time. A benchmark in actual time and typical use case would
>>> > be
>>> > needed to decide.
>>>
>>> Yes, always also test overall with typical code usecase.
>
> +1
>
>> I tested it using a "benchmark" command line, who test two shuffle func
>> ./ffmpeg -benchmark -f lavfi -i rgbtestsrc=size=3840x2160:duration=10 -vf
>> format=argb,format=rgba -f null -
>>
>> With the patch :
>> bench: utime=3.611s
>> With only SSSE 3 (disable AVX2 part), i have similar result.
>
> Indicating James' original comment that the avx2 optimization
> makes no sense is correct?

You are almost always wrong.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] Fix iterating of input and output devices

[Timo Rothenpieler]

Am 16.03.2018 um 10:52 schrieb Timo Rothenpieler:

Will push tomorrow unless someone sees a problem with this.



applied



smime.p7s
Description: S/MIME Cryptographic Signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH 2/2] lavf/img2dec: use new iteration API

[Josh de Kock]

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

diff --git a/libavformat/img2dec.c b/libavformat/img2dec.c
index f3f52c83b3..159617f046 100644
--- a/libavformat/img2dec.c
+++ b/libavformat/img2dec.c
@@ -324,6 +324,7 @@ int ff_img_read_header(AVFormatContext *s1)
 int probe_buffer_size = 2048;
 uint8_t *probe_buffer = av_realloc(NULL, probe_buffer_size + 
AVPROBE_PADDING_SIZE);
 AVInputFormat *fmt = NULL;
+void *opaque = NULL;
 AVProbeData pd = { 0 };
 
 if (!probe_buffer)
@@ -340,7 +341,7 @@ int ff_img_read_header(AVFormatContext *s1)
 pd.buf_size = probe_buffer_size;
 pd.filename = s1->url;
 
-while ((fmt = av_iformat_next(fmt))) {
+while ((fmt = av_demuxer_iterate(&opaque))) {
 if (fmt->read_header != ff_img_read_header ||
 !fmt->read_probe ||
 (fmt->flags & AVFMT_NOFILE) ||
-- 
2.14.3 (Apple Git-98)

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

[FFmpeg-devel] [PATCH v2 1/2] lav*, tests: remove several register_all() calls

[Josh de Kock]

Because lavf and lavd being separated incrementally, some of the hacky
behaviour in how options are found/parsed is being exposed. Basically,
finding options works on some behaviour with iterating AVClasses, and
making lavd not a hack-of-a-library incrementally (i.e. by separating
iteration) messed this up because the 'child_class_next' wants to
iterate formats when it gets an avdevice. Essentially a way to fix it
would be to have avdevices have a different child_class_next function.
Removing avdevice_register_all() in ffmpeg.c breaks searching of
options, because it activates the old API which allows iteration of
devices within the format iteration function. Essentially, we need a
avdevice_get_class() function, but I think the best way to do it would
just to take the plunge and make an struct AVDevice.
---
 doc/examples/filter_audio.c  | 2 --
 doc/examples/filtering_audio.c   | 2 --
 doc/examples/filtering_video.c   | 2 --
 doc/examples/transcoding.c   | 2 --
 fftools/ffmpeg.c | 3 ---
 fftools/ffplay.c | 4 
 fftools/ffprobe.c| 1 -
 libavcodec/tests/utils.c | 1 -
 libavdevice/lavfi.c  | 2 --
 libavfilter/lavfutils.c  | 2 --
 libavfilter/src_movie.c  | 2 --
 libavfilter/tests/filtfmts.c | 2 --
 libavformat/tests/movenc.c   | 2 --
 libavformat/tests/seek.c | 3 ---
 tests/api/api-band-test.c| 2 --
 tests/api/api-codec-param-test.c | 2 --
 tests/api/api-flac-test.c| 2 --
 tests/api/api-h264-test.c| 2 --
 tests/api/api-seek-test.c| 2 --
 tools/aviocat.c  | 1 -
 tools/enum_options.c | 2 --
 tools/graph2dot.c| 2 --
 tools/ismindex.c | 2 --
 tools/pktdumper.c| 3 ---
 tools/probetest.c| 3 ---
 tools/seek_print.c   | 1 -
 tools/sidxindex.c| 2 --
 tools/uncoded_frame.c| 4 
 28 files changed, 60 deletions(-)

diff --git a/doc/examples/filter_audio.c b/doc/examples/filter_audio.c
index 7467c21c30..1611e3d952 100644
--- a/doc/examples/filter_audio.c
+++ b/doc/examples/filter_audio.c
@@ -289,8 +289,6 @@ int main(int argc, char *argv[])
 return 1;
 }
 
-avfilter_register_all();
-
 /* Allocate the frame we will be using to store the data. */
 frame  = av_frame_alloc();
 if (!frame) {
diff --git a/doc/examples/filtering_audio.c b/doc/examples/filtering_audio.c
index 73a00e814c..b109dbcb96 100644
--- a/doc/examples/filtering_audio.c
+++ b/doc/examples/filtering_audio.c
@@ -228,8 +228,6 @@ int main(int argc, char **argv)
 exit(1);
 }
 
-avfilter_register_all();
-
 if ((ret = open_input_file(argv[1])) < 0)
 goto end;
 if ((ret = init_filters(filter_descr)) < 0)
diff --git a/doc/examples/filtering_video.c b/doc/examples/filtering_video.c
index 01d6644620..ed4e7bbd81 100644
--- a/doc/examples/filtering_video.c
+++ b/doc/examples/filtering_video.c
@@ -222,8 +222,6 @@ int main(int argc, char **argv)
 exit(1);
 }
 
-avfilter_register_all();
-
 if ((ret = open_input_file(argv[1])) < 0)
 goto end;
 if ((ret = init_filters(filter_descr)) < 0)
diff --git a/doc/examples/transcoding.c b/doc/examples/transcoding.c
index ed1fd6411b..a83fa3a185 100644
--- a/doc/examples/transcoding.c
+++ b/doc/examples/transcoding.c
@@ -517,8 +517,6 @@ int main(int argc, char **argv)
 return 1;
 }
 
-avfilter_register_all();
-
 if ((ret = open_input_file(argv[1])) < 0)
 goto end;
 if ((ret = open_output_file(argv[2])) < 0)
diff --git a/fftools/ffmpeg.c b/fftools/ffmpeg.c
index ee7258fcd1..7d1747c14a 100644
--- a/fftools/ffmpeg.c
+++ b/fftools/ffmpeg.c
@@ -4803,12 +4803,9 @@ int main(int argc, char **argv)
 argv++;
 }
 
-avcodec_register_all();
 #if CONFIG_AVDEVICE
 avdevice_register_all();
 #endif
-avfilter_register_all();
-av_register_all();
 avformat_network_init();
 
 show_banner(argc, argv, options);
diff --git a/fftools/ffplay.c b/fftools/ffplay.c
index f2028d4b13..bc9ddb8885 100644
--- a/fftools/ffplay.c
+++ b/fftools/ffplay.c
@@ -3655,10 +3655,6 @@ int main(int argc, char **argv)
 #if CONFIG_AVDEVICE
 avdevice_register_all();
 #endif
-#if CONFIG_AVFILTER
-avfilter_register_all();
-#endif
-av_register_all();
 avformat_network_init();
 
 init_opts();
diff --git a/fftools/ffprobe.c b/fftools/ffprobe.c
index a4ac6972a2..2582649fd3 100644
--- a/fftools/ffprobe.c
+++ b/fftools/ffprobe.c
@@ -3567,7 +3567,6 @@ int main(int argc, char **argv)
 
 options = real_options;
 parse_loglevel(argc, argv, options);
-av_register_all();
 avformat_network_init();
 init_opts();
 #if CONFIG_AVDEVICE
diff --git a/libavcodec/tests/utils.c b/libavcodec/tests/utils.c
index e2891fb389..f6ba7fe66e 100644
--- a/libavcodec/tests/utils.c
+++ b/libavcodec/tests/utils.c
@@ -21,7 +21,6 @@
 int main(void){
 AVC

[FFmpeg-devel] save frames via Zero-MQ

[Oleksiy Druzhynin]

Dear FFmpeg community.

We use ffmpeg/server as a stream source and extracts frames and audio fragment 
per every second using this command:


ffmpeg -i rtmp://localhost/live/STREAM_NAME -r 1/1 -start_number 0 %d.jpg -f 
segment -segment_time 1 -acodec pcm_s16le -ac 1 -ar 16000 -threads 0 
-start_number 1 %d.wav

Out real-time stream processing tool just pulls frames and wavs from the disk 
to send it next by the message bus.

We want to customize FFmpeg to send the frames and wavs to the ZMQ topic.

Could you give a piece of advice whether it's possible (no engineering 
obstacles)? And if we do that could we contribute with that to FFmpeg code?

Regards,

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

Re: [FFmpeg-devel] [PATCH 1/4] checkasm/Makefile: add EXTRALIBS-libavformat

[Josh de Kock]

On Sun, Mar 18, 2018 at 01:42:12PM -0300, James Almer wrote:
> On 3/18/2018 1:06 PM, Paul B Mahol wrote:
> > [...]
> > And how do you know that?, without even providing alternative?
> 
> I provided an alternative. Look at my comment about the *_FFLIBS
> variables. The build system already uses it when linking the libraries
> themselves.
> The build system has a lot of measures to only build the required
> objects and only link the required libraries based on configure time
> options. Hardcoding avformat and swresample extralibs for this
> executable when avcodec and avfilter may be built without the modules
> that require said libraries is doing the exact opposite of that.

I will look into the *_FFLIBS variables. I figured it would be an OK
patch because of the swresample one recently added.

> Sure, we can commit this as a "temporary" fix, seeing that something
> needs to be done in a timely manner so the iterate() api can be
> committed, but the result will be that nobody will bother to implement
> it right afterwards.

This would be preferred, or at least looking at the other patches first
as they are more complex. This is an issue which can be looked at after
all the other major issues are discussed, the main one being:

How avdevice and avformat interact going forward (see the v2 of the patch
which removes a bunch of register_all() functions for an explanation
of this issue).

-- 
Josh

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

Re: [FFmpeg-devel] swscale/rgb2rgb : add X86_64 SIMD (SSSE3 and AVX2) for shuffly_bytes func

[Nicolas George]

Paul B Mahol (2018-03-18):
> You are almost always wrong.

And you, just now, were rude.

Regards,

-- 
  Nicolas George


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

Re: [FFmpeg-devel] swscale/rgb2rgb : add X86_64 SIMD (SSSE3 and AVX2) for shuffly_bytes func

[Carl Eugen Hoyos]

2018-03-18 18:20 GMT+01:00, Paul B Mahol :
> On 3/18/18, Carl Eugen Hoyos  wrote:
>> 2018-03-18 17:46 GMT+01:00, Martin Vignali :
>>> 2018-03-18 17:37 GMT+01:00 Paul B Mahol :
>>>
 On 3/18/18, Nicolas George  wrote:
 > Martin Vignali (2018-03-18):
 >> I run the test again with a bigger width (512 instead of 128)
 >> This is my result :
 >> shuffle_bytes_0321_c: 128.6
 >> shuffle_bytes_0321_ssse3: 41.6
 >> shuffle_bytes_0321_avx2: 23.4
 >
 > IIUC, these benchmarks are expressed in CPU cycles. But what James
 > says
 > is that it can cause the CPU frequency to be throttled: if that
 > happens,
 > less cycles can use more time, and even worse, cause other unrelated
 > to
 > take more time. A benchmark in actual time and typical use case would
 > be
 > needed to decide.

 Yes, always also test overall with typical code usecase.
>>
>> +1
>>
>>> I tested it using a "benchmark" command line, who test two shuffle func
>>> ./ffmpeg -benchmark -f lavfi -i rgbtestsrc=size=3840x2160:duration=10 -vf
>>> format=argb,format=rgba -f null -
>>>
>>> With the patch :
>>> bench: utime=3.611s
>>> With only SSSE 3 (disable AVX2 part), i have similar result.
>>
>> Indicating James' original comment that the avx2 optimization
>> makes no sense is correct?
>
> You are almost always wrong.

I tend to agree but I wonder how you know that I am wrong here:
What in above mail indicates that avx2 has an advantage over
ssse3?

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

Re: [FFmpeg-devel] swscale/rgb2rgb : add X86_64 SIMD (SSSE3 and AVX2) for shuffly_bytes func

[Paul B Mahol]

On 3/18/18, Carl Eugen Hoyos  wrote:
> 2018-03-18 18:20 GMT+01:00, Paul B Mahol :
>> On 3/18/18, Carl Eugen Hoyos  wrote:
>>> 2018-03-18 17:46 GMT+01:00, Martin Vignali :
 2018-03-18 17:37 GMT+01:00 Paul B Mahol :

> On 3/18/18, Nicolas George  wrote:
> > Martin Vignali (2018-03-18):
> >> I run the test again with a bigger width (512 instead of 128)
> >> This is my result :
> >> shuffle_bytes_0321_c: 128.6
> >> shuffle_bytes_0321_ssse3: 41.6
> >> shuffle_bytes_0321_avx2: 23.4
> >
> > IIUC, these benchmarks are expressed in CPU cycles. But what James
> > says
> > is that it can cause the CPU frequency to be throttled: if that
> > happens,
> > less cycles can use more time, and even worse, cause other unrelated
> > to
> > take more time. A benchmark in actual time and typical use case would
> > be
> > needed to decide.
>
> Yes, always also test overall with typical code usecase.
>>>
>>> +1
>>>
 I tested it using a "benchmark" command line, who test two shuffle func
 ./ffmpeg -benchmark -f lavfi -i rgbtestsrc=size=3840x2160:duration=10
 -vf
 format=argb,format=rgba -f null -

 With the patch :
 bench: utime=3.611s
 With only SSSE 3 (disable AVX2 part), i have similar result.
>>>
>>> Indicating James' original comment that the avx2 optimization
>>> makes no sense is correct?
>>
>> You are almost always wrong.
>
> I tend to agree but I wonder how you know that I am wrong here:
> What in above mail indicates that avx2 has an advantage over
> ssse3?

It might work with new CPUs much better.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] swscale/rgb2rgb : add X86_64 SIMD (SSSE3 and AVX2) for shuffly_bytes func

[Carl Eugen Hoyos]

2018-03-18 19:04 GMT+01:00, Paul B Mahol :
> On 3/18/18, Carl Eugen Hoyos  wrote:
>> 2018-03-18 18:20 GMT+01:00, Paul B Mahol :
>>> On 3/18/18, Carl Eugen Hoyos  wrote:
 2018-03-18 17:46 GMT+01:00, Martin Vignali :
> 2018-03-18 17:37 GMT+01:00 Paul B Mahol :
>
>> On 3/18/18, Nicolas George  wrote:
>> > Martin Vignali (2018-03-18):
>> >> I run the test again with a bigger width (512 instead of 128)
>> >> This is my result :
>> >> shuffle_bytes_0321_c: 128.6
>> >> shuffle_bytes_0321_ssse3: 41.6
>> >> shuffle_bytes_0321_avx2: 23.4
>> >
>> > IIUC, these benchmarks are expressed in CPU cycles. But what James
>> > says
>> > is that it can cause the CPU frequency to be throttled: if that
>> > happens,
>> > less cycles can use more time, and even worse, cause other unrelated
>> > to
>> > take more time. A benchmark in actual time and typical use case
>> > would
>> > be
>> > needed to decide.
>>
>> Yes, always also test overall with typical code usecase.

 +1

> I tested it using a "benchmark" command line, who test two shuffle func
> ./ffmpeg -benchmark -f lavfi -i rgbtestsrc=size=3840x2160:duration=10
> -vf
> format=argb,format=rgba -f null -
>
> With the patch :
> bench: utime=3.611s
> With only SSSE 3 (disable AVX2 part), i have similar result.

 Indicating James' original comment that the avx2 optimization
 makes no sense is correct?
>>>
>>> You are almost always wrong.
>>
>> I tend to agree but I wonder how you know that I am wrong here:
>> What in above mail indicates that avx2 has an advantage over
>> ssse3?
>
> It might work with new CPUs much better.

"might" indicates that I am wrong?
Your reasoning is not much better than mine...

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

Re: [FFmpeg-devel] [PATCH] lavfi: Add OpenCL avgblur filter

[Mark Thompson]

On 16/03/18 15:06, Carl Eugen Hoyos wrote:
> 2018-03-16 8:33 GMT+01:00, dylanf...@gmail.com :
>> From: drfer3 
> 
>> --- /dev/null
>> +++ b/libavfilter/opencl/avgblur.cl
>> @@ -0,0 +1,60 @@
>> +/*
>> + * This file is part of FFmpeg.
> 
> Please add your name.

Is there some specific reason for wanting it in this case?  I prefer not to add 
it and would weakly encourage others not to (though I realise that many people 
do like to add it), because it is often inaccurate when multiple people touch a 
file.  The only source for anyone actually needing authorship information 
should be the commit history.

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

Re: [FFmpeg-devel] [PATCH] lavfi: Add OpenCL avgblur filter

[Carl Eugen Hoyos]

2018-03-18 19:12 GMT+01:00, Mark Thompson :
> On 16/03/18 15:06, Carl Eugen Hoyos wrote:
>> 2018-03-16 8:33 GMT+01:00, dylanf...@gmail.com :
>>> From: drfer3 
>>
>>> --- /dev/null
>>> +++ b/libavfilter/opencl/avgblur.cl
>>> @@ -0,0 +1,60 @@
>>> +/*
>>> + * This file is part of FFmpeg.
>>
>> Please add your name.
>
> Is there some specific reason for wanting it in this case?

Nothing specifically, it is just a good idea.
(You may even interpret it as an insurance.)

> I prefer not to add it and would weakly encourage others
> not to (though I realise that many people do like to add it),

Sounds like a really horrible suggestion and I wonder
where you got it from.

> because it is often inaccurate when multiple people
> touch a file.

So you argue that because some people did not add
their copyright statements (because they know it is not
necessary) we should forbid contributors to add them?

> The only source for anyone actually needing authorship
> information should be the commit history.

FFmpeg is a superb example for a project where looking
at the commit history is not sufficient to find out about
authorship (this is just to explain that there are different,
not necessarily closely related issues at hand).

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

[FFmpeg-devel] Reimbursement request

[Carl Eugen Hoyos]

Hi!

As already discussed, FFmpeg was present on Chemnitzer Linux Tage, in
addition, Thilo and I went to Brussels for FOSDEM where we attended
the talks in the multimedia room kindly (co-) organized by Kieran and
answered some questions. I would like to request reimbursement for the
travel costs, that's flights-only, Thilo payed the gasoline and the
hotel.

Chemnitz: 125,85
Brussels: 192,41

Thank you, Carl Eugen
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] lavfi: Add OpenCL avgblur filter

[Mark Thompson]

On 18/03/18 18:36, Carl Eugen Hoyos wrote:
> 2018-03-18 19:12 GMT+01:00, Mark Thompson :
>> On 16/03/18 15:06, Carl Eugen Hoyos wrote:
>>> 2018-03-16 8:33 GMT+01:00, dylanf...@gmail.com :
 From: drfer3 
>>>
 --- /dev/null
 +++ b/libavfilter/opencl/avgblur.cl
 @@ -0,0 +1,60 @@
 +/*
 + * This file is part of FFmpeg.
>>>
>>> Please add your name.
>>
>> Is there some specific reason for wanting it in this case?
> 
> Nothing specifically, it is just a good idea.
> (You may even interpret it as an insurance.)

Insurance?

>> I prefer not to add it and would weakly encourage others
>> not to (though I realise that many people do like to add it),
> 
> Sounds like a really horrible suggestion and I wonder
> where you got it from.
> 
>> because it is often inaccurate when multiple people
>> touch a file.
> 
> So you argue that because some people did not add
> their copyright statements (because they know it is not
> necessary) we should forbid contributors to add them?

No, I'm not arguing for anything, and I definitely don't want to forbid it (I'm 
unsure how you got that from what I said).

I was just wondering if there was any specific reason why you were encouraging 
it in this case (I don't think I've seen you ask for it before, though I admit 
I wouldn't necessarily notice).

>> The only source for anyone actually needing authorship
>> information should be the commit history.
> 
> FFmpeg is a superb example for a project where looking
> at the commit history is not sufficient to find out about
> authorship (this is just to explain that there are different,
> not necessarily closely related issues at hand).

I agree that this is true for older code in the repository (pre-git in 
particular).  I think we should be discouraging new commits with unclear 
provenance, though.

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

Re: [FFmpeg-devel] Reimbursement request

[Thomas Volkert]

Hi,

On 18.03.2018 19:42, Carl Eugen Hoyos wrote:
> Hi!
>
> As already discussed, FFmpeg was present on Chemnitzer Linux Tage, in
> addition, Thilo and I went to Brussels for FOSDEM where we attended
> the talks in the multimedia room kindly (co-) organized by Kieran and
> answered some questions. I would like to request reimbursement for the
> travel costs, that's flights-only, Thilo payed the gasoline and the
> hotel.
>
> Chemnitz: 125,85
> Brussels: 192,41
>

The pictures from "Chemnitzer Linuxtage" are now available on our
Facebook page.

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

Re: [FFmpeg-devel] [PATCH] doc/utils: document the "ms" and "us" suffixes for durations

[Marton Balint]

On Sat, 10 Mar 2018, Moritz Barsnick wrote:


These suffixes were recently introduced in 
61c972384d311508d07f9360d196909e27195655
and completed in 8218249f1f04de65904f58519bde21948e5a0783.

Signed-off-by: Moritz Barsnick 
---

I chose not to document the suffixes in the section describing the
HH:MM:SS.mmm syntax, even though they work there (with expected, but
quite difficult to explain effects).

doc/utils.texi | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/doc/utils.texi b/doc/utils.texi
index d55dd315c3..a094ee151c 100644
--- a/doc/utils.texi
+++ b/doc/utils.texi
@@ -110,11 +110,12 @@ maximum of 2 digits. The @var{m} at the end expresses 
decimal value for
@emph{or}

@example
-[-]@var{S}+[.@var{m}...]
+[-]@var{S}+[.@var{m}...][ms|us]
@end example

@var{S} expresses the number of seconds, with the optional decimal part
-@var{m}.
+@var{m}. The optional literal suffixes @samp{ms} or @samp{us} indicate to
+interpret the value as milliseconds or microseconds, respectively.


I think you missed the normal "s" suffix (as in seconds) which is also 
supported from now on.


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

[FFmpeg-devel] [PATCH 1/2] ffmpeg: fallback to codecpar parameters on input filter eof

[Marton Balint]

Fixes ticket #6854 and the following simpler case:

ffmpeg -f lavfi -i testsrc=d=1 -f lavfi -i testsrc=d=0 -filter_complex overlay 
-f null none

Signed-off-by: Marton Balint 
---
 fftools/ffmpeg.c | 33 -
 1 file changed, 16 insertions(+), 17 deletions(-)

diff --git a/fftools/ffmpeg.c b/fftools/ffmpeg.c
index ee7258fcd1..8876c99560 100644
--- a/fftools/ffmpeg.c
+++ b/fftools/ffmpeg.c
@@ -1855,23 +1855,6 @@ static void flush_encoders(void)
ost->file_index, ost->st->index);
 
 if (ost->filter && !fg->graph) {
-int x;
-for (x = 0; x < fg->nb_inputs; x++) {
-InputFilter *ifilter = fg->inputs[x];
-if (ifilter->format < 0) {
-AVCodecParameters *par = ifilter->ist->st->codecpar;
-// We never got any input. Set a fake format, which 
will
-// come from libavformat.
-ifilter->format = par->format;
-ifilter->sample_rate= par->sample_rate;
-ifilter->channels   = par->channels;
-ifilter->channel_layout = par->channel_layout;
-ifilter->width  = par->width;
-ifilter->height = par->height;
-ifilter->sample_aspect_ratio= 
par->sample_aspect_ratio;
-}
-}
-
 if (!ifilter_has_all_input_formats(fg))
 continue;
 
@@ -2214,6 +2197,22 @@ static int ifilter_send_eof(InputFilter *ifilter, 
int64_t pts)
 } else {
 // the filtergraph was never configured
 FilterGraph *fg = ifilter->graph;
+if (ifilter->format < 0) {
+AVCodecParameters *par = ifilter->ist->st->codecpar;
+// We never got any input. Set a fake format, which will
+// come from libavformat.
+ifilter->format = par->format;
+ifilter->sample_rate= par->sample_rate;
+ifilter->channels   = par->channels;
+ifilter->channel_layout = par->channel_layout;
+ifilter->width  = par->width;
+ifilter->height = par->height;
+ifilter->sample_aspect_ratio= par->sample_aspect_ratio;
+}
+if (ifilter->format < 0 && (ifilter->type == AVMEDIA_TYPE_AUDIO || 
ifilter->type == AVMEDIA_TYPE_VIDEO)) {
+av_log(NULL, AV_LOG_ERROR, "Cannot determine format of input %d, 
stream %d after EOF\n", ifilter->ist->file_index, ifilter->ist->st->index);
+return AVERROR_INVALIDDATA;
+}
 for (i = 0; i < fg->nb_inputs; i++)
 if (!fg->inputs[i]->eof)
 break;
-- 
2.13.6

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

[FFmpeg-devel] [PATCH 2/2] ffmpeg: do not finish output streams manually on eof even if no input is provided

[Marton Balint]

The generic code should be able to finish the streams just fine initializing
and flushing the filters and codecs properly.

Signed-off-by: Marton Balint 
---
 fftools/ffmpeg.c | 12 +---
 1 file changed, 1 insertion(+), 11 deletions(-)

diff --git a/fftools/ffmpeg.c b/fftools/ffmpeg.c
index 8876c99560..5399397c6e 100644
--- a/fftools/ffmpeg.c
+++ b/fftools/ffmpeg.c
@@ -2186,7 +2186,7 @@ static int ifilter_send_frame(InputFilter *ifilter, 
AVFrame *frame)
 
 static int ifilter_send_eof(InputFilter *ifilter, int64_t pts)
 {
-int i, j, ret;
+int ret;
 
 ifilter->eof = 1;
 
@@ -2213,16 +2213,6 @@ static int ifilter_send_eof(InputFilter *ifilter, 
int64_t pts)
 av_log(NULL, AV_LOG_ERROR, "Cannot determine format of input %d, 
stream %d after EOF\n", ifilter->ist->file_index, ifilter->ist->st->index);
 return AVERROR_INVALIDDATA;
 }
-for (i = 0; i < fg->nb_inputs; i++)
-if (!fg->inputs[i]->eof)
-break;
-if (i == fg->nb_inputs) {
-// All the input streams have finished without the filtergraph
-// ever being configured.
-// Mark the output streams as finished.
-for (j = 0; j < fg->nb_outputs; j++)
-finish_output_stream(fg->outputs[j]->ost);
-}
 }
 
 return 0;
-- 
2.13.6

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

Re: [FFmpeg-devel] [PATCH] lavfi: Add OpenCL avgblur filter

[Mark Thompson]

On 18/03/18 12:48, dylanf...@gmail.com wrote:
> From: drfer3 
> 
> Behaves like the existing avgblur filter, except working on OpenCL
> hardware frames. Takes exactly the same options.
> ---
>  configure   |   1 +
>  libavfilter/Makefile|   2 +
>  libavfilter/allfilters.c|   1 +
>  libavfilter/opencl/avgblur.cl   |  60 
>  libavfilter/opencl_source.h |   1 +
>  libavfilter/vf_avgblur_opencl.c | 318 
> 
>  6 files changed, 383 insertions(+)
>  create mode 100644 libavfilter/opencl/avgblur.cl
>  create mode 100644 libavfilter/vf_avgblur_opencl.c
> 
> diff --git a/configure b/configure
> index 0c5ed07a07..481d338caf 100755
> --- a/configure
> +++ b/configure
> @@ -3202,6 +3202,7 @@ aresample_filter_deps="swresample"
>  ass_filter_deps="libass"
>  atempo_filter_deps="avcodec"
>  atempo_filter_select="rdft"
> +avgblur_opencl_filter_deps="opencl"
>  azmq_filter_deps="libzmq"
>  blackframe_filter_deps="gpl"
>  boxblur_filter_deps="gpl"
> diff --git a/libavfilter/Makefile b/libavfilter/Makefile
> index fc16512e2c..1043b41d80 100644
> --- a/libavfilter/Makefile
> +++ b/libavfilter/Makefile
> @@ -139,6 +139,8 @@ OBJS-$(CONFIG_ALPHAMERGE_FILTER) += 
> vf_alphamerge.o
>  OBJS-$(CONFIG_ASS_FILTER)+= vf_subtitles.o
>  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_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 cc423af738..3f67e321bf 100644
> --- a/libavfilter/allfilters.c
> +++ b/libavfilter/allfilters.c
> @@ -149,6 +149,7 @@ static void register_all(void)
>  REGISTER_FILTER(ASS,ass,vf);
>  REGISTER_FILTER(ATADENOISE, atadenoise, vf);
>  REGISTER_FILTER(AVGBLUR,avgblur,vf);
> +REGISTER_FILTER(AVGBLUR_OPENCL, avgblur_opencl, vf);
>  REGISTER_FILTER(BBOX,   bbox,   vf);
>  REGISTER_FILTER(BENCH,  bench,  vf);
>  REGISTER_FILTER(BITPLANENOISE,  bitplanenoise,  vf);
> diff --git a/libavfilter/opencl/avgblur.cl b/libavfilter/opencl/avgblur.cl
> new file mode 100644
> index 00..28e0c90d15
> --- /dev/null
> +++ b/libavfilter/opencl/avgblur.cl
> @@ -0,0 +1,60 @@
> +/*
> + * Copyright (c) 2018 Dylan Fernando
> + *
> + * 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
> + */
> +
> +
> +__kernel void avgblur_horiz(__write_only image2d_t dst,
> +__read_only  image2d_t src,
> +int rad)
> +{
> +const sampler_t sampler = (CLK_NORMALIZED_COORDS_FALSE |
> +   CLK_FILTER_NEAREST);
> +int2 loc = (int2)(get_global_id(0), get_global_id(1));
> +int2 size = (int2)(get_global_size(0), get_global_size(1));
> +
> +int count = 0;
> +float4 acc = (float4)(0,0,0,0);
> +
> +for (int xx = max(0,loc.x-rad); xx < min(loc.x+rad+1,size.x); xx++) {

Keep to the same style as the rest of the code - spaces around operators.

> +count++;
> +acc += read_imagef(src, sampler, (int2)(xx, loc.y));

Setting CLK_ADDRESS_CLAMP_TO_EDGE in the sampler would let you read over the 
edges and possibly avoid some of the min/max branching?  (I don't know whether 
that would actually help at all, would need to be measured - feel free to 
ignore this suggestion.)

> +}
> +
> +write_imagef(dst, loc, acc / count);
> +}
> +
> +__kernel void avgblur_vert(__write_only image2d_t dst,
> +   __read_only  image2d_t src,
> +   int radv)
> +{
> +const sampler_t sampler = (CLK_NORMALIZED_COORDS_FALSE |
> +   CLK_FILTER_NEAREST);
> +int2 loc = (int2)(get_global_id(0), get_global_id(1));
> +int2 size = (int2)(get_global_size(0), get_global_size(1));

Re: [FFmpeg-devel] Reimbursement request

[Thilo Borgmann]

Hi,

> As already discussed, FFmpeg was present on Chemnitzer Linux Tage, in
> addition, Thilo and I went to Brussels for FOSDEM where we attended
> the talks in the multimedia room kindly (co-) organized by Kieran and
> answered some questions. I would like to request reimbursement for the
> travel costs, that's flights-only, Thilo payed the gasoline and the
> hotel.

from my side there are hotel & gas for Chemnitz, and flight & hotel for 
Brussels that I'd like to ask to reimburse for. For Chemnitz it is the usual 
drive by car Carl Eugen and me do from Berlin, which are around 290 km one way 
as well as a shared hotel room (they did not manage to put all of us into one 
suite this time, so we had to stick to two rooms for all four of us):

> Chemnitz: 125,85

Hotel: 194.00 EUR
Gas:   36.62 + 21.67 + 39.51 =  97.80 EUR
-
Total: 291,80 EUR


> Brussels: 192,41

Flight:111.81 EUR
Hotel: 186.69 EUR
-
Total: 298,50 EUR


BTW, on both events some of our T-Shirts have found their way to some users, 
forgot to mention this in the CLT report. Also, we ran out of stock of our 
stickers during CLT, so I will order new ones asap. I also forgot to mention 
that we have met the organizers of a similar event in Prague in October 
(LinuxDays) [1]. I'll try to have us there with a booth, too!

Also, regarding FOSDEM, I'd really like to have a booth there from next year 
on. In contrast to Chemnitz (and possibly Prague), Brussels is an expensive 
place in general though I could get an AirBNB near the price of an actual hotel 
in Chemnitz. FOSDEM of course is the biggest event with a bigger audience of 
technical knowledge in our field, so we really should consider a booth at 
FOSDEM, IMHO. (However this is almost a year in the future)

If there are no objections, I'll send all the invoices to Stefano privately 
(like I almost always do...;)

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

Re: [FFmpeg-devel] [PATCH 1/2] avcodec/aac_adtstoasc: move the reference in the bsf internal buffer

[James Almer]

On 3/18/2018 11:21 AM, James Almer wrote:
> On 3/16/2018 8:16 PM, James Almer wrote:
>> There's no need to allocate a new packet for it.
>>
>> Signed-off-by: James Almer 
>> ---
>>  libavcodec/aac_adtstoasc_bsf.c | 33 ++---
>>  1 file changed, 14 insertions(+), 19 deletions(-)
>>
>> diff --git a/libavcodec/aac_adtstoasc_bsf.c b/libavcodec/aac_adtstoasc_bsf.c
>> index 49f1f095e6..6541b1189c 100644
>> --- a/libavcodec/aac_adtstoasc_bsf.c
>> +++ b/libavcodec/aac_adtstoasc_bsf.c
>> @@ -36,27 +36,26 @@ typedef struct AACBSFContext {
>>   * This filter creates an MPEG-4 AudioSpecificConfig from an MPEG-2/4
>>   * ADTS header and removes the ADTS header.
>>   */
>> -static int aac_adtstoasc_filter(AVBSFContext *bsfc, AVPacket *out)
>> +static int aac_adtstoasc_filter(AVBSFContext *bsfc, AVPacket *pkt)
>>  {
>>  AACBSFContext *ctx = bsfc->priv_data;
>>  
>>  GetBitContext gb;
>>  PutBitContext pb;
>>  AACADTSHeaderInfo hdr;
>> -AVPacket *in;
>>  int ret;
>>  
>> -ret = ff_bsf_get_packet(bsfc, &in);
>> +ret = ff_bsf_get_packet_ref(bsfc, pkt);
>>  if (ret < 0)
>>  return ret;
>>  
>> -if (bsfc->par_in->extradata && in->size >= 2 && (AV_RB16(in->data) >> 
>> 4) != 0xfff)
>> -goto finish;
>> +if (bsfc->par_in->extradata && pkt->size >= 2 && (AV_RB16(pkt->data) >> 
>> 4) != 0xfff)
>> +return 0;
>>  
>> -if (in->size < AV_AAC_ADTS_HEADER_SIZE)
>> +if (pkt->size < AV_AAC_ADTS_HEADER_SIZE)
>>  goto packet_too_small;
>>  
>> -init_get_bits(&gb, in->data, AV_AAC_ADTS_HEADER_SIZE * 8);
>> +init_get_bits(&gb, pkt->data, AV_AAC_ADTS_HEADER_SIZE * 8);
>>  
>>  if (ff_adts_header_parse(&gb, &hdr) < 0) {
>>  av_log(bsfc, AV_LOG_ERROR, "Error parsing ADTS frame header!\n");
>> @@ -71,10 +70,10 @@ static int aac_adtstoasc_filter(AVBSFContext *bsfc, 
>> AVPacket *out)
>>  goto fail;
>>  }
>>  
>> -in->size -= AV_AAC_ADTS_HEADER_SIZE + 2 * !hdr.crc_absent;
>> -if (in->size <= 0)
>> +pkt->size -= AV_AAC_ADTS_HEADER_SIZE + 2 * !hdr.crc_absent;
>> +if (pkt->size <= 0)
>>  goto packet_too_small;
>> -in->data += AV_AAC_ADTS_HEADER_SIZE + 2 * !hdr.crc_absent;
>> +pkt->data += AV_AAC_ADTS_HEADER_SIZE + 2 * !hdr.crc_absent;
>>  
>>  if (!ctx->first_frame_done) {
>>  intpce_size = 0;
>> @@ -82,7 +81,7 @@ static int aac_adtstoasc_filter(AVBSFContext *bsfc, 
>> AVPacket *out)
>>  uint8_t   *extradata;
>>  
>>  if (!hdr.chan_config) {
>> -init_get_bits(&gb, in->data, in->size * 8);
>> +init_get_bits(&gb, pkt->data, pkt->size * 8);
>>  if (get_bits(&gb, 3) != 5) {
>>  avpriv_report_missing_feature(bsfc,
>>"PCE-based channel 
>> configuration "
>> @@ -94,11 +93,11 @@ static int aac_adtstoasc_filter(AVBSFContext *bsfc, 
>> AVPacket *out)
>>  init_put_bits(&pb, pce_data, MAX_PCE_SIZE);
>>  pce_size = ff_copy_pce_data(&pb, &gb) / 8;
>>  flush_put_bits(&pb);
>> -in->size -= get_bits_count(&gb)/8;
>> -in->data += get_bits_count(&gb)/8;
>> +pkt->size -= get_bits_count(&gb)/8;
>> +pkt->data += get_bits_count(&gb)/8;
>>  }
>>  
>> -extradata = av_packet_new_side_data(in, AV_PKT_DATA_NEW_EXTRADATA,
>> +extradata = av_packet_new_side_data(pkt, AV_PKT_DATA_NEW_EXTRADATA,
>>  2 + pce_size);
>>  if (!extradata) {
>>  ret = AVERROR(ENOMEM);
>> @@ -120,17 +119,13 @@ static int aac_adtstoasc_filter(AVBSFContext *bsfc, 
>> AVPacket *out)
>>  ctx->first_frame_done = 1;
>>  }
>>  
>> -finish:
>> -av_packet_move_ref(out, in);
>> -av_packet_free(&in);
>> -
>>  return 0;
>>  
>>  packet_too_small:
>>  av_log(bsfc, AV_LOG_ERROR, "Input packet too small\n");
>>  ret = AVERROR_INVALIDDATA;
>>  fail:
>> -av_packet_free(&in);
>> +av_packet_unref(pkt);
>>  return ret;
>>  }
>>  
>>
> 
> Will push later today.

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

Re: [FFmpeg-devel] [PATCH V3 06/11] lavc/h264_metadata_bsf: support dump options.

[Mark Thompson]

On 14/03/18 05:42, Jun Zhao wrote:
> Subject: [PATCH V3 06/11] lavc/h264_metadata_bsf: support dump options.
> Subject: [PATCH V3 07/11] lavc/h265_metadata_bsf: support dump options.
> Subject: [PATCH V3 08/11] lavc/mpeg2_metadata_bsf: support dump options.

Added the flags for the options I added earlier, and applied.

Thanks,

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

Re: [FFmpeg-devel] [PATCH 5/7] vf_crop: Add support for cropping hardware frames

[Mark Thompson]

On 11/03/18 22:41, Mark Thompson wrote:
> Set the cropping fields in the AVFrame.
> ---
>  libavfilter/vf_crop.c | 61 
> ---
>  1 file changed, 43 insertions(+), 18 deletions(-)
> 
> diff --git a/libavfilter/vf_crop.c b/libavfilter/vf_crop.c
> index 0fdc4949e3..0b1b8a048b 100644
> --- a/libavfilter/vf_crop.c
> +++ b/libavfilter/vf_crop.c
> @@ -98,9 +98,17 @@ static int query_formats(AVFilterContext *ctx)
>  
>  for (fmt = 0; av_pix_fmt_desc_get(fmt); fmt++) {
>  const AVPixFmtDescriptor *desc = av_pix_fmt_desc_get(fmt);
> -if (!(desc->flags & (AV_PIX_FMT_FLAG_HWACCEL | 
> AV_PIX_FMT_FLAG_BITSTREAM)) &&
> -!((desc->log2_chroma_w || desc->log2_chroma_h) && !(desc->flags 
> & AV_PIX_FMT_FLAG_PLANAR)) &&
> -(ret = ff_add_format(&formats, fmt)) < 0)
> +if (desc->flags & AV_PIX_FMT_FLAG_BITSTREAM)
> +continue;
> +if (!(desc->flags & AV_PIX_FMT_FLAG_HWACCEL)) {
> +// Not usable if there is any subsampling but the format is
> +// not planar (e.g. YUYV422).
> +if ((desc->log2_chroma_w || desc->log2_chroma_h) &&
> +!(desc->flags & AV_PIX_FMT_FLAG_PLANAR))
> +continue;
> +}
> +ret = ff_add_format(&formats, fmt);
> +if (ret < 0)
>  return ret;
>  }
>  
> @@ -157,8 +165,14 @@ static int config_input(AVFilterLink *link)
>  s->var_values[VAR_POS]   = NAN;
>  
>  av_image_fill_max_pixsteps(s->max_step, NULL, pix_desc);
> -s->hsub = pix_desc->log2_chroma_w;
> -s->vsub = pix_desc->log2_chroma_h;
> +
> +if (pix_desc->flags & AV_PIX_FMT_FLAG_HWACCEL) {
> +s->hsub = 1;
> +s->vsub = 1;
> +} else {
> +s->hsub = pix_desc->log2_chroma_w;
> +s->vsub = pix_desc->log2_chroma_h;
> +}
>  
>  if ((ret = av_expr_parse_and_eval(&res, (expr = s->w_expr),
>var_names, s->var_values,
> @@ -285,22 +299,33 @@ static int filter_frame(AVFilterLink *link, AVFrame 
> *frame)
>  (int)s->var_values[VAR_N], s->var_values[VAR_T], 
> s->var_values[VAR_POS],
>  s->x, s->y, s->x+s->w, s->y+s->h);
>  
> -frame->data[0] += s->y * frame->linesize[0];
> -frame->data[0] += s->x * s->max_step[0];
> -
> -if (!(desc->flags & AV_PIX_FMT_FLAG_PAL || desc->flags & 
> AV_PIX_FMT_FLAG_PSEUDOPAL)) {
> -for (i = 1; i < 3; i ++) {
> -if (frame->data[i]) {
> -frame->data[i] += (s->y >> s->vsub) * frame->linesize[i];
> -frame->data[i] += (s->x * s->max_step[i]) >> s->hsub;
> +if (desc->flags & AV_PIX_FMT_FLAG_HWACCEL) {
> +frame->crop_top   += s->y;
> +frame->crop_left  += s->x;
> +frame->crop_bottom = frame->height - frame->crop_top - 
> frame->crop_bottom - s->h;
> +frame->crop_right  = frame->width  - frame->crop_left - 
> frame->crop_right - s->w;
> +
> +} else {
> +frame->width  = s->w;
> +frame->height = s->h;
> +
> +frame->data[0] += s->y * frame->linesize[0];
> +frame->data[0] += s->x * s->max_step[0];
> +
> +if (!(desc->flags & AV_PIX_FMT_FLAG_PAL || desc->flags & 
> AV_PIX_FMT_FLAG_PSEUDOPAL)) {
> +for (i = 1; i < 3; i ++) {
> +if (frame->data[i]) {
> +frame->data[i] += (s->y >> s->vsub) * frame->linesize[i];
> +frame->data[i] += (s->x * s->max_step[i]) >> s->hsub;
> +}
>  }
>  }
> -}
>  
> -/* alpha plane */
> -if (frame->data[3]) {
> -frame->data[3] += s->y * frame->linesize[3];
> -frame->data[3] += s->x * s->max_step[3];
> +/* alpha plane */
> +if (frame->data[3]) {
> +frame->data[3] += s->y * frame->linesize[3];
> +frame->data[3] += s->x * s->max_step[3];
> +}
>  }
>  
>  return ff_filter_frame(link->dst->outputs[0], frame);
> 

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

Re: [FFmpeg-devel] [PATCH v4 2/2] avformat/libopenmpt: Probe file format from file data if possible

[Josh de Kock]

On 2018/03/18 8:23, wm4 wrote:
> On Sun, 18 Mar 2018 08:44:12 +0100
> Jörn Heusipp  wrote:
>
>> On 03/04/2018 08:55 AM, Jörn Heusipp wrote:
>>> On 02/21/2018 12:11 PM, Jörn Heusipp wrote:
libavformat/libopenmpt.c | 57
 
1 file changed, 57 insertions(+)
>>>
>>> Uhm, ping?
>>
>> So, my patches have been waiting without any further comment for more
>> than 2 months by now.
>>
>> What should I do?
>
> I assume everything that was asked for in previous patch replies before
> was fixed. If nobody applies them until Tuesdays, I'll apply them if
> you ping this thread again on that day.

Patch looks fine, feel free to apply whenever.

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

[FFmpeg-devel] Event-driven I/O

[Philip Prindeville]

Hi,

I’m looking at struct AVIOContext and avio_alloc_context(), and wondering if 
there’s an alternate mode of I/O where reading a stream (for instance) is 
event-driven by data arriving on a network socket.

This is in a trivial sequential case with no seeking or pausing.

I’m using libevent2 and all events (timeouts, sockets posting data ready for 
reading, button-presses, etc) are dispatched as events from that main loop.

Receiving data and decoding it also needs to be handled from this main loop.

Are there any examples to go by?

Thanks,

-Philip

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

[FFmpeg-devel] [PATCH] configure: add const_nan dependency to h264_metadata_bsf

[James Almer]

Fixes compilation with some compilers.

Signed-off-by: James Almer 
---
See 
http://fate.ffmpeg.org/log.cgi?time=20180318215121&log=compile&slot=x86_64-freedos-djgpp

 configure | 1 +
 1 file changed, 1 insertion(+)

diff --git a/configure b/configure
index d5ed95b769..6b27f571c6 100755
--- a/configure
+++ b/configure
@@ -2920,6 +2920,7 @@ vc1_parser_select="vc1dsp"
 # bitstream_filters
 aac_adtstoasc_bsf_select="adts_header"
 filter_units_bsf_select="cbs"
+h264_metadata_bsf_deps="const_nan"
 h264_metadata_bsf_select="cbs_h264"
 h264_redundant_pps_bsf_select="cbs_h264"
 hevc_metadata_bsf_select="cbs_h265"
-- 
2.16.2

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

Re: [FFmpeg-devel] [PATCH] configure: add const_nan dependency to h264_metadata_bsf

[James Almer]

On 3/18/2018 7:13 PM, James Almer wrote:
> Fixes compilation with some compilers.
> 
> Signed-off-by: James Almer 
> ---
> See 
> http://fate.ffmpeg.org/log.cgi?time=20180318215121&log=compile&slot=x86_64-freedos-djgpp
> 
>  configure | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/configure b/configure
> index d5ed95b769..6b27f571c6 100755
> --- a/configure
> +++ b/configure
> @@ -2920,6 +2920,7 @@ vc1_parser_select="vc1dsp"
>  # bitstream_filters
>  aac_adtstoasc_bsf_select="adts_header"
>  filter_units_bsf_select="cbs"
> +h264_metadata_bsf_deps="const_nan"
>  h264_metadata_bsf_select="cbs_h264"
>  h264_redundant_pps_bsf_select="cbs_h264"
>  hevc_metadata_bsf_select="cbs_h265"
> 

Approved by jkqxz on IRC, so pushed.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 1/4] checkasm/Makefile: add EXTRALIBS-libavformat

[Michael Niedermayer]

On Sun, Mar 18, 2018 at 01:40:15PM +, j...@itanimul.li wrote:
> From: Josh de Kock 
> 
> ---
>  tests/checkasm/Makefile | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/tests/checkasm/Makefile b/tests/checkasm/Makefile
> index 0520e264e2..ae7e810d25 100644
> --- a/tests/checkasm/Makefile
> +++ b/tests/checkasm/Makefile
> @@ -61,7 +61,7 @@ tests/checkasm/checkasm.o: CFLAGS += -Umain
>  CHECKASM := tests/checkasm/checkasm$(EXESUF)
>  
>  $(CHECKASM): $(CHECKASMOBJS) $(FF_STATIC_DEP_LIBS)
> - $(LD) $(LDFLAGS) $(LDEXEFLAGS) $(LD_O) $(CHECKASMOBJS) 
> $(FF_STATIC_DEP_LIBS) $(EXTRALIBS-avcodec) $(EXTRALIBS-avfilter) 
> $(EXTRALIBS-avutil) $(EXTRALIBS-swresample) $(EXTRALIBS)
> + $(LD) $(LDFLAGS) $(LDEXEFLAGS) $(LD_O) $(CHECKASMOBJS) 
> $(FF_STATIC_DEP_LIBS) $(EXTRALIBS-avcodec) $(EXTRALIBS-avfilter) 
> $(EXTRALIBS-avformat) $(EXTRALIBS-avutil) $(EXTRALIBS-swresample) $(EXTRALIBS)

These additional dependancies should not be needed.
It does not entirely feel right to me that adding a new API would cause
additional dependancies between libraries to appear


thx

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

"I am not trying to be anyone's saviour, I'm trying to think about the
 future and not be sad" - Elon Musk



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

Re: [FFmpeg-devel] [PATCH 2/2] ffmpeg: do not finish output streams manually on eof even if no input is provided

[Michael Niedermayer]

On Sun, Mar 18, 2018 at 08:09:09PM +0100, Marton Balint wrote:
> The generic code should be able to finish the streams just fine initializing
> and flushing the filters and codecs properly.
> 
> Signed-off-by: Marton Balint 
> ---
>  fftools/ffmpeg.c | 12 +---
>  1 file changed, 1 insertion(+), 11 deletions(-)

This changes:
./ffmpeg -i ~/tickets/3015/test_video -filter:a apad -f flv -vcodec flv -ar 
22050 -shortest test.flv

Didnt investigate beyond a quick look which didnt tell me anything.
If the change is good this could be turned into a fate test

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

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


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

Re: [FFmpeg-devel] [PATCH V3 06/11] lavc/h264_metadata_bsf: support dump options.

[Jun Zhao]

On 2018/3/19 4:35, Mark Thompson wrote:
> On 14/03/18 05:42, Jun Zhao wrote:
>> Subject: [PATCH V3 06/11] lavc/h264_metadata_bsf: support dump options.
>> Subject: [PATCH V3 07/11] lavc/h265_metadata_bsf: support dump options.
>> Subject: [PATCH V3 08/11] lavc/mpeg2_metadata_bsf: support dump options.
> Added the flags for the options I added earlier, and applied.
>
> Thanks,
Thanks, Mark
> - Mark
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

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

Re: [FFmpeg-devel] [PATCH V3 05/11] lavc/extract_extradata_bsf: support dump options.

[Jun Zhao]

On 2018/3/17 23:19, James Almer wrote:
> On 3/14/2018 2:42 AM, Jun Zhao wrote:
>> 0005-lavc-extract_extradata_bsf-support-dump-options.patch
>>
>>
>> From 3d49b455b8bea2ee311b011fd9078e180c7bdf9a Mon Sep 17 00:00:00 2001
>> From: Jun Zhao 
>> Date: Thu, 8 Mar 2018 14:05:53 +0800
>> Subject: [PATCH V3 05/11] lavc/extract_extradata_bsf: support dump options.
>>
>> support dump bit stream filter options
>>
>> Signed-off-by: Jun Zhao 
>> ---
>>  libavcodec/extract_extradata_bsf.c | 3 ++-
>>  1 file changed, 2 insertions(+), 1 deletion(-)
>>
>> diff --git a/libavcodec/extract_extradata_bsf.c 
>> b/libavcodec/extract_extradata_bsf.c
>> index 1c386becd7..007a6a71f5 100644
>> --- a/libavcodec/extract_extradata_bsf.c
>> +++ b/libavcodec/extract_extradata_bsf.c
>> @@ -322,9 +322,10 @@ static const enum AVCodecID codec_ids[] = {
>>  };
>>  
>>  #define OFFSET(x) offsetof(ExtractExtradataContext, x)
>> +#define FLAGS (AV_OPT_FLAG_VIDEO_PARAM|AV_OPT_FLAG_BSF_PARAM)
>>  static const AVOption options[] = {
>>  { "remove", "remove the extradata from the bitstream", OFFSET(remove), 
>> AV_OPT_TYPE_INT,
>> -{ .i64 = 0 }, 0, 1 },
>> +{ .i64 = 0 }, 0, 1 , FLAGS},
>>  { NULL },
>>  };
> Applied, thanks.
Thanks, James
> ___
> 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 1/2] ffmpeg: fallback to codecpar parameters on input filter eof

[Michael Niedermayer]

On Sun, Mar 18, 2018 at 08:09:08PM +0100, Marton Balint wrote:
> Fixes ticket #6854 and the following simpler case:
> 

> ffmpeg -f lavfi -i testsrc=d=1 -f lavfi -i testsrc=d=0 -filter_complex 
> overlay -f null none

this could be usefull as a fate test


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

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


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

[FFmpeg-devel] [PATCH 2/2] avcodec/mpeg4_unpack_bframes: allocate a new packet when data needs to be changed

[James Almer]

Nothing currently guarantees that the packet will be writtable.

Signed-off-by: James Almer 
---
 libavcodec/mpeg4_unpack_bframes_bsf.c | 8 +++-
 1 file changed, 7 insertions(+), 1 deletion(-)

diff --git a/libavcodec/mpeg4_unpack_bframes_bsf.c 
b/libavcodec/mpeg4_unpack_bframes_bsf.c
index ba970794c5..00cc35c2ab 100644
--- a/libavcodec/mpeg4_unpack_bframes_bsf.c
+++ b/libavcodec/mpeg4_unpack_bframes_bsf.c
@@ -149,8 +149,14 @@ static int mpeg4_unpack_bframes_filter(AVBSFContext *ctx, 
AVPacket *out)
 av_packet_move_ref(out, in);
 out->size = pos_vop2;
 } else if (pos_p >= 0) {
+ret = av_new_packet(out, in->size);
+if (ret < 0)
+goto fail;
+ret = av_packet_copy_props(out, in);
+if (ret < 0)
+goto fail;
+memcpy(out->data, in->data, in->size);
 av_log(ctx, AV_LOG_DEBUG, "Updating DivX userdata (remove trailing 
'p').\n");
-av_packet_move_ref(out, in);
 /* remove 'p' (packed) from the end of the (DivX) userdata string */
 out->data[pos_p] = '\0';
 } else {
-- 
2.16.2

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

[FFmpeg-devel] [PATCH 1/2] avcodec/mpeg4_unpack_bframes: reduce code duplication

[James Almer]

Also fixes one potential leak of side data in out if
the av_packet_from_data() call fails.

Signed-off-by: James Almer 
---
 libavcodec/mpeg4_unpack_bframes_bsf.c | 20 ++--
 1 file changed, 10 insertions(+), 10 deletions(-)

diff --git a/libavcodec/mpeg4_unpack_bframes_bsf.c 
b/libavcodec/mpeg4_unpack_bframes_bsf.c
index e227f58ec6..ba970794c5 100644
--- a/libavcodec/mpeg4_unpack_bframes_bsf.c
+++ b/libavcodec/mpeg4_unpack_bframes_bsf.c
@@ -108,8 +108,8 @@ static int mpeg4_unpack_bframes_filter(AVBSFContext *ctx, 
AVPacket *out)
 s->b_frame_buf  = create_new_buffer(in->data + pos_vop2, 
s->b_frame_buf_size);
 if (!s->b_frame_buf) {
 s->b_frame_buf_size = 0;
-av_packet_free(&in);
-return AVERROR(ENOMEM);
+ret = AVERROR(ENOMEM);
+goto fail;
 }
 }
 
@@ -122,14 +122,12 @@ static int mpeg4_unpack_bframes_filter(AVBSFContext *ctx, 
AVPacket *out)
 /* use frame from BSFContext */
 ret = av_packet_copy_props(out, in);
 if (ret < 0) {
-av_packet_free(&in);
-return ret;
+goto fail;
 }
 
 ret = av_packet_from_data(out, s->b_frame_buf, s->b_frame_buf_size);
 if (ret < 0) {
-av_packet_free(&in);
-return ret;
+goto fail;
 }
 if (in->size <= MAX_NVOP_SIZE) {
 /* N-VOP */
@@ -142,9 +140,8 @@ static int mpeg4_unpack_bframes_filter(AVBSFContext *ctx, 
AVPacket *out)
 s->b_frame_buf  = create_new_buffer(in->data, in->size);
 if (!s->b_frame_buf) {
 s->b_frame_buf_size = 0;
-av_packet_unref(out);
-av_packet_free(&in);
-return AVERROR(ENOMEM);
+ret = AVERROR(ENOMEM);
+goto fail;
 }
 }
 } else if (nb_vop >= 2) {
@@ -161,9 +158,12 @@ static int mpeg4_unpack_bframes_filter(AVBSFContext *ctx, 
AVPacket *out)
 av_packet_move_ref(out, in);
 }
 
+fail:
+if (ret < 0)
+av_packet_unref(out);
 av_packet_free(&in);
 
-return 0;
+return ret;
 }
 
 static int mpeg4_unpack_bframes_init(AVBSFContext *ctx)
-- 
2.16.2

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

Re: [FFmpeg-devel] [PATCH] lavfi: Add OpenCL avgblur filter

[Dylan Fernando]

On Mon, Mar 19, 2018 at 6:16 AM, Mark Thompson  wrote:

> On 18/03/18 12:48, dylanf...@gmail.com wrote:
> > From: drfer3 
> >
> > Behaves like the existing avgblur filter, except working on OpenCL
> > hardware frames. Takes exactly the same options.
> > ---
> >  configure   |   1 +
> >  libavfilter/Makefile|   2 +
> >  libavfilter/allfilters.c|   1 +
> >  libavfilter/opencl/avgblur.cl   |  60 
> >  libavfilter/opencl_source.h |   1 +
> >  libavfilter/vf_avgblur_opencl.c | 318 ++
> ++
> >  6 files changed, 383 insertions(+)
> >  create mode 100644 libavfilter/opencl/avgblur.cl
> >  create mode 100644 libavfilter/vf_avgblur_opencl.c
> >
> > diff --git a/configure b/configure
> > index 0c5ed07a07..481d338caf 100755
> > --- a/configure
> > +++ b/configure
> > @@ -3202,6 +3202,7 @@ aresample_filter_deps="swresample"
> >  ass_filter_deps="libass"
> >  atempo_filter_deps="avcodec"
> >  atempo_filter_select="rdft"
> > +avgblur_opencl_filter_deps="opencl"
> >  azmq_filter_deps="libzmq"
> >  blackframe_filter_deps="gpl"
> >  boxblur_filter_deps="gpl"
> > diff --git a/libavfilter/Makefile b/libavfilter/Makefile
> > index fc16512e2c..1043b41d80 100644
> > --- a/libavfilter/Makefile
> > +++ b/libavfilter/Makefile
> > @@ -139,6 +139,8 @@ OBJS-$(CONFIG_ALPHAMERGE_FILTER) +=
> vf_alphamerge.o
> >  OBJS-$(CONFIG_ASS_FILTER)+= vf_subtitles.o
> >  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_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 cc423af738..3f67e321bf 100644
> > --- a/libavfilter/allfilters.c
> > +++ b/libavfilter/allfilters.c
> > @@ -149,6 +149,7 @@ static void register_all(void)
> >  REGISTER_FILTER(ASS,ass,vf);
> >  REGISTER_FILTER(ATADENOISE, atadenoise, vf);
> >  REGISTER_FILTER(AVGBLUR,avgblur,vf);
> > +REGISTER_FILTER(AVGBLUR_OPENCL, avgblur_opencl, vf);
> >  REGISTER_FILTER(BBOX,   bbox,   vf);
> >  REGISTER_FILTER(BENCH,  bench,  vf);
> >  REGISTER_FILTER(BITPLANENOISE,  bitplanenoise,  vf);
> > diff --git a/libavfilter/opencl/avgblur.cl b/libavfilter/opencl/avgblur.
> cl
> > new file mode 100644
> > index 00..28e0c90d15
> > --- /dev/null
> > +++ b/libavfilter/opencl/avgblur.cl
> > @@ -0,0 +1,60 @@
> > +/*
> > + * Copyright (c) 2018 Dylan Fernando
> > + *
> > + * 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
> > + */
> > +
> > +
> > +__kernel void avgblur_horiz(__write_only image2d_t dst,
> > +__read_only  image2d_t src,
> > +int rad)
> > +{
> > +const sampler_t sampler = (CLK_NORMALIZED_COORDS_FALSE |
> > +   CLK_FILTER_NEAREST);
> > +int2 loc = (int2)(get_global_id(0), get_global_id(1));
> > +int2 size = (int2)(get_global_size(0), get_global_size(1));
> > +
> > +int count = 0;
> > +float4 acc = (float4)(0,0,0,0);
> > +
> > +for (int xx = max(0,loc.x-rad); xx < min(loc.x+rad+1,size.x); xx++)
> {
>
> Keep to the same style as the rest of the code - spaces around operators.
>
> > +count++;
> > +acc += read_imagef(src, sampler, (int2)(xx, loc.y));
>
> Setting CLK_ADDRESS_CLAMP_TO_EDGE in the sampler would let you read over
> the edges and possibly avoid some of the min/max branching?  (I don't know
> whether that would actually help at all, would need to be measured - feel
> free to ignore this suggestion.)
>
> > +}
> > +
> > +write_imagef(dst, loc, acc / count);
> > +}
> > +
> > +__kernel void avgblur_vert(__write_only image2d_t dst,
> > +   __read_only  image2d_t src,
> > + 

[FFmpeg-devel] [PATCH] lavfi: Add OpenCL avgblur filter

[dylanf123]

From: drfer3 

Behaves like the existing avgblur filter, except working on OpenCL
hardware frames. Takes exactly the same options.
---
 configure   |   1 +
 libavfilter/Makefile|   2 +
 libavfilter/allfilters.c|   1 +
 libavfilter/opencl/avgblur.cl   |  60 
 libavfilter/opencl_source.h |   1 +
 libavfilter/vf_avgblur_opencl.c | 328 
 6 files changed, 393 insertions(+)
 create mode 100644 libavfilter/opencl/avgblur.cl
 create mode 100644 libavfilter/vf_avgblur_opencl.c

diff --git a/configure b/configure
index 0c5ed07a07..481d338caf 100755
--- a/configure
+++ b/configure
@@ -3202,6 +3202,7 @@ aresample_filter_deps="swresample"
 ass_filter_deps="libass"
 atempo_filter_deps="avcodec"
 atempo_filter_select="rdft"
+avgblur_opencl_filter_deps="opencl"
 azmq_filter_deps="libzmq"
 blackframe_filter_deps="gpl"
 boxblur_filter_deps="gpl"
diff --git a/libavfilter/Makefile b/libavfilter/Makefile
index fc16512e2c..1043b41d80 100644
--- a/libavfilter/Makefile
+++ b/libavfilter/Makefile
@@ -139,6 +139,8 @@ OBJS-$(CONFIG_ALPHAMERGE_FILTER) += 
vf_alphamerge.o
 OBJS-$(CONFIG_ASS_FILTER)+= vf_subtitles.o
 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_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 cc423af738..3f67e321bf 100644
--- a/libavfilter/allfilters.c
+++ b/libavfilter/allfilters.c
@@ -149,6 +149,7 @@ static void register_all(void)
 REGISTER_FILTER(ASS,ass,vf);
 REGISTER_FILTER(ATADENOISE, atadenoise, vf);
 REGISTER_FILTER(AVGBLUR,avgblur,vf);
+REGISTER_FILTER(AVGBLUR_OPENCL, avgblur_opencl, vf);
 REGISTER_FILTER(BBOX,   bbox,   vf);
 REGISTER_FILTER(BENCH,  bench,  vf);
 REGISTER_FILTER(BITPLANENOISE,  bitplanenoise,  vf);
diff --git a/libavfilter/opencl/avgblur.cl b/libavfilter/opencl/avgblur.cl
new file mode 100644
index 00..6a8d70df93
--- /dev/null
+++ b/libavfilter/opencl/avgblur.cl
@@ -0,0 +1,60 @@
+/*
+ * Copyright (c) 2018 Dylan Fernando
+ *
+ * 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
+ */
+
+
+__kernel void avgblur_horiz(__write_only image2d_t dst,
+__read_only  image2d_t src,
+int rad)
+{
+const sampler_t sampler = (CLK_NORMALIZED_COORDS_FALSE |
+   CLK_FILTER_NEAREST);
+int2 loc = (int2)(get_global_id(0), get_global_id(1));
+int2 size = (int2)(get_global_size(0), get_global_size(1));
+
+int count = 0;
+float4 acc = (float4)(0,0,0,0);
+
+for (int xx = max(0, loc.x - rad); xx < min(loc.x + rad + 1, size.x); 
xx++) {
+count++;
+acc += read_imagef(src, sampler, (int2)(xx, loc.y));
+}
+
+write_imagef(dst, loc, acc / count);
+}
+
+__kernel void avgblur_vert(__write_only image2d_t dst,
+   __read_only  image2d_t src,
+   int radv)
+{
+const sampler_t sampler = (CLK_NORMALIZED_COORDS_FALSE |
+   CLK_FILTER_NEAREST);
+int2 loc = (int2)(get_global_id(0), get_global_id(1));
+int2 size = (int2)(get_global_size(0), get_global_size(1));
+
+int count = 0;
+float4 acc = (float4)(0,0,0,0);
+
+for (int yy = max(0, loc.y - radv); yy < min(loc.y + radv + 1, size.y); 
yy++) {
+count++;
+acc += read_imagef(src, sampler, (int2)(loc.x, yy));
+}
+
+write_imagef(dst, loc, acc / count);
+}
diff --git a/libavfilter/opencl_source.h b/libavfilter/opencl_source.h
index 23cdfc6ac9..02bc1723b0 100644
--- a/libavfilter/opencl_source.h
+++ b/libavfilter/opencl_source.h
@@ -19,6 +19,7 @@
 #ifndef AVFILTER_OPENCL_SOURCE_H
 #define AVFILTER_OPENCL_SOURCE_H
 
+extern const char *ff_opencl_source_avgblur;
 extern 

[FFmpeg-devel] [DISCUSSION] New iteration APIs, lavf and lavd

[Josh de Kock]

Hi,

The new iteration API to replace the old _next() is nearing the end of 
it's completion with the lavfi patch on the mailing list and only one 
outstanding issue:


AVOptions would not be found for devices as there is no AVClass for 
lavd. At the moment it would work if you were to still call 
avdevice_register_all() because then devices get registered as formats 
in the old API (which the child_class_next function still uses). When 
the format_child_class_next() function switches to the iterate() API
it would no longer have access to devices and thus there would be no way 
for av_opt_find() to find an option for devices. The fix for this is 
simple, add an AVClass for lavd--fairly clean and unobjectionable.



This leaves the new iteration API in an odd limbo of both being now 
consistent with the newer BSF API, and using static lav* components, but 
also lying to the user that lavf and lavd are separate libraries. We 
have a few options in regards to this:


1) Agree that both lavf and lavd are fine in their current state

This requires no further discussion, and is the easiest to implement but 
leaves ffmpeg with a questionable ecosystem of dependent libraries. It 
also would require another iteration API change if lavf and lavd were to 
be separated in the future (luckily only return types due to the usage 
of an opaque state i.e. `const AVInputFormat *av_indev_iterate(void 
**opaque)` -> `const AVInputDevice *av_indev_iterate(void **opaque)`)


2) Disagree that both lavf and lavd are fine in their current state and 
move towards defining lavd as its own separate library immediately at 
the same time as the new iteration APIs.


This is possibly the hardest and most annoying option, as it would 
require designing a new API for essentially a new library, and 
converting the current library's components (also doing it immediately). 
This could range from being simple-ish to being quite tough depending on 
how much the new library API just copies the lavf API directly (though a 
disadvantage of this is that it wouldn't be able to take good use of 
designing the API around how devices should be, it has to design around 
how they currently are).


3) Disagree that both lavf and lavd are fine in their current state and 
merge lavd into lavd to allow redesigning of lavd to happen slowly at 
its own pace.


This may require a fair amount of work, but not too much upfront. It 
takes the fact that lavf and lavd aren't really separate libraries to 
'delete' lavd to give space for a new library to be designed from scratch.


4) Scrap the entire API

This is super easy, just figure out which commits are related to the new 
API using `git log`, then revert. We can then have a whole new 
discussion on how we'd rather do things entirely instead, though this 
sounds like a lot of work that people would agree to and then it'd just 
not get done.


There may be other options I haven't described, I'd love to hear them. 
As for the ones I did, 2 will impede the new ffmpeg release the most 
(something I think no one wants), and 4 just moves backwards. I think 1 
or 3 are preferred, and I lean towards 3 (and obviously this is just my 
opinion, you are entitled to your own).


What are your thoughts on how to proceed with the new iteration APIs, 
and lavf & lavd being separated?


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

[FFmpeg-devel] [PATCH] avcodec/mp3_header_decompress: don't free the user provided packet on error

[James Almer]

It's owned by the caller.

Signed-off-by: James Almer 
---
 libavcodec/mp3_header_decompress_bsf.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/libavcodec/mp3_header_decompress_bsf.c 
b/libavcodec/mp3_header_decompress_bsf.c
index 22c1ef0220..294858953c 100644
--- a/libavcodec/mp3_header_decompress_bsf.c
+++ b/libavcodec/mp3_header_decompress_bsf.c
@@ -87,7 +87,7 @@ static int mp3_header_decompress(AVBSFContext *ctx, AVPacket 
*out)
 goto fail;
 ret = av_packet_copy_props(out, in);
 if (ret < 0) {
-av_packet_free(&out);
+av_packet_unref(out);
 goto fail;
 }
 memcpy(out->data + frame_size - buf_size, buf, buf_size + 
AV_INPUT_BUFFER_PADDING_SIZE);
-- 
2.16.2

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

Re: [FFmpeg-devel] [PATCH] checkasm/hevc_idct : update test bit depth from 8 9 and 10 to 8 10 and 12

[Yingming Fan]

Hi, is there any review? This patch has been going on for a week.

Yingming Fan

> On 11 Mar 2018, at 10:17 AM, Yingming Fan  wrote:
> 
> Hi, there. Is there any comment? I think i did the right fix.
> 
> Yingming Fan
> 
>> On 8 Mar 2018, at 4:17 PM, Hendrik Leppkes  wrote:
>> 
>> On Thu, Mar 8, 2018 at 9:16 AM, Paul B Mahol  wrote:
>>> On 3/8/18, Yingming Fan  wrote:
 From: Yingming Fan 
 
 ---
 We have 8 10 and 12 SIMD codes, but previous checkasm hevc_idct only test 8
 and 10 bit depth.
 
 tests/checkasm/hevc_idct.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)
 
 diff --git a/tests/checkasm/hevc_idct.c b/tests/checkasm/hevc_idct.c
 index eea712101d..c20111c2df 100644
 --- a/tests/checkasm/hevc_idct.c
 +++ b/tests/checkasm/hevc_idct.c
 @@ -87,7 +87,7 @@ void checkasm_check_hevc_idct(void)
 {
int bit_depth;
 
 -for (bit_depth = 8; bit_depth <= 10; bit_depth++) {
 +for (bit_depth = 8; bit_depth <= 12; bit_depth += 2) {
HEVCDSPContext h;
 
ff_hevc_dsp_init(&h, bit_depth);
 @@ -95,7 +95,7 @@ void checkasm_check_hevc_idct(void)
}
report("idct_dc");
 
 -for (bit_depth = 8; bit_depth <= 10; bit_depth++) {
 +for (bit_depth = 8; bit_depth <= 12; bit_depth += 2) {
HEVCDSPContext h;
 
ff_hevc_dsp_init(&h, bit_depth);
>>> 
>>> Isn't this dropping 9 case?
>> 
>> It is, but we don't have any optimizations for 9 anyway, so there is
>> nothing to test.
>> 
>> - Hendrik
>> ___
>> 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] checkasm/hevc_idct : update test bit depth from 8 9 and 10 to 8 10 and 12

[James Almer]

On 3/19/2018 12:38 AM, Yingming Fan wrote:
> Hi, is there any review? This patch has been going on for a week.
> 
> Yingming Fan

Pushed, sorry for the delay.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] avcodec/arm/hevcdsp_sao : add NEON optimization for sao

[Yingming Fan]

Hi, is there any review about this patch? What’s your option about wrapper we 
used in this patch.

Yingming Fan

> On 11 Mar 2018, at 8:59 PM, Yingming Fan  wrote:
> 
> 
>> On 11 Mar 2018, at 8:54 PM, Carl Eugen Hoyos  wrote:
>> 
>> 2018-03-08 8:03 GMT+01:00 Yingming Fan :
>>> From: Meng Wang 
>> 
>>> +stride_dst /= sizeof(uint8_t);
>>> +stride_src /= sizeof(uint8_t);
>> 
>> FFmpeg requires sizeof(uint8_t) to be 1, please simplify
>> your patch accordingly.
>> 
>> Why is the wrapper function needed?
> 
> We use wrapper because codes in wrapper no need to be written with assembly, 
> C codes more readable.
> 
>> 
>> Carl Eugen
>> ___
>> ffmpeg-devel mailing list
>> ffmpeg-devel@ffmpeg.org
>> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> 

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

Re: [FFmpeg-devel] [PATCH] lavc/cfhd: added interlaced frame decoding

[Gagandeep Singh]

On Sat, Mar 17, 2018 at 5:00 PM, Carl Eugen Hoyos 
wrote:

> 2018-03-17 10:42 GMT+01:00, Gagandeep Singh :
> > ticket #5522: interlaced frame required horizontal-temporal inverse
> > transform. though the output is not satisfactory yet.
>
> > diff --git a/libavcodec/cfhd.c b/libavcodec/cfhd.c
> > index a064cd1599..b17c7c1dc5 100644
> > --- a/libavcodec/cfhd.c
> > +++ b/libavcodec/cfhd.c
> > @@ -50,8 +50,11 @@ enum CFHDParam {
> >  ChannelWidth = 104,
> >  ChannelHeight= 105,
> >  PrescaleShift= 109,
> > +Progressive  =  68,
>
> I suspect this can be ordered better.
>
> >  };
> >
> > +
> > +
>
> Please do not add random cosmetic changes to your patch.
>
> [...]
>
> > +static inline void interlaced_vertical_filter(int16_t *output, int16_t
> > *low, int16_t *high,
> > + int width, int linesize, int plane)
> > +{
> > +int i;
>
> > +int16_t even, odd;
>
> Could the code be simplified by using an unsigned type?
> Why not a standard type?
>
> > +for (i = 0; i < width; i++) {
>
> > +
> > +
>
> Maybe you disagree, but these empty lines make
> reading the code more difficult imo.
>
> > +  even = (*low - *high)/2;
> > +  odd  = (*low + *high)/2;
> > +
> > +  if (even > 1023) even = 1023;
> > +  if (even < 0) even = 0;
> > +  if (odd > 1023) odd = 1023;
> > +  if (odd < 0) odd = 0;
>
> FFMIN / FFMAX
>
> [...]
>
> > +  }
> > +  else {
>
> Please merge these lines.
>
> Thank you, Carl Eugen


>


 libavcodec/cfhd.c | 107
+-
 1 file changed, 58 insertions(+), 49 deletions(-)

diff --git a/libavcodec/cfhd.c b/libavcodec/cfhd.c
index b17c7c1dc5..57e0042d01 100644
--- a/libavcodec/cfhd.c
+++ b/libavcodec/cfhd.c
@@ -46,15 +46,13 @@ enum CFHDParam {
 SubbandNumber=  48,
 Quantization =  53,
 ChannelNumber=  62,
+Progressive  =  68,
 BitsPerComponent = 101,
 ChannelWidth = 104,
 ChannelHeight= 105,
 PrescaleShift= 109,
-Progressive  =  68,
 };

-
-
 static av_cold int cfhd_init(AVCodecContext *avctx)
 {
 CFHDContext *s = avctx->priv_data;
@@ -145,17 +143,15 @@ static inline void interlaced_vertical_filter(int16_t
*output, int16_t *low, int
  int width, int linesize, int plane)
 {
 int i;
-int16_t even, odd;
+int even, odd;
 for (i = 0; i < width; i++) {
-
-
   even = (*low - *high)/2;
   odd  = (*low + *high)/2;

-  if (even > 1023) even = 1023;
-  if (even < 0) even = 0;
-  if (odd > 1023) odd = 1023;
-  if (odd < 0) odd = 0;
+  even = FFMIN(even, 1023);
+  even = FFMAX(even, 0);
+  odd  = FFMIN(odd, 1023);
+  odd  = FFMAX(odd, 0);

   output[i] = even;
   output[i + linesize] = odd;
@@ -163,6 +159,23 @@ static inline void interlaced_vertical_filter(int16_t
*output, int16_t *low, int
   high++;
 }
 }
+
+static inline void horiz_haar_filter(int16_t *output, int16_t *low,
int16_t *high,
+ int width)
+{
+int i;
+int even, odd;
+for (i = 0; i < width; i+=2) {
+  even = (*low - *high);
+  odd  = (*low + *high);
+
+  output[i] = even;
+  output[i + 1] =odd;
+  low++;
+  high++;
+}
+}
+
 static void horiz_filter(int16_t *output, int16_t *low, int16_t *high,
  int width)
 {
@@ -222,7 +235,8 @@ static int alloc_buffers(AVCodecContext *avctx)
 int width  = i ? avctx->width  >> chroma_x_shift : avctx->width;
 int height = i ? avctx->height >> chroma_y_shift : avctx->height;
 ptrdiff_t stride   = FFALIGN(width  / 8, 8) * 8;
-if (chroma_y_shift) height = FFALIGN(height / 8, 2) * 8;
+if (chroma_y_shift)
+height = FFALIGN(height / 8, 2) * 8;
 s->plane[i].width  = width;
 s->plane[i].height = height;
 s->plane[i].stride = stride;
@@ -233,7 +247,6 @@ static int alloc_buffers(AVCodecContext *avctx)
 h4 = h8 * 2;
 w2 = w4 * 2;
 h2 = h4 * 2;
-
 s->plane[i].idwt_buf =
 av_mallocz_array(height * stride,
sizeof(*s->plane[i].idwt_buf));
 s->plane[i].idwt_tmp =
@@ -273,7 +286,6 @@ static int alloc_buffers(AVCodecContext *avctx)
 s->a_height = s->coded_height;
 s->a_width  = s->coded_width;
 s->a_format = s->coded_format;
-
 return 0;
 }

@@ -304,8 +316,8 @@ static int cfhd_decode(AVCodecContext *avctx, void
*data, int *got_frame,
 if (abs_tag8 >= 0x60 && abs_tag8 <= 0x6f) {
 av_log(avctx, AV_LOG_DEBUG, "large len %x\n", ((tagu & 0xff)
<< 16) | data);
 } else if (tag == Progressive) {
-av_log(avctx, AV_LOG_DEBUG, "Progressive?%"PRIu16"\n", data);
-s->progressive = data;
+av_log(avctx, AV_LOG_DEBUG, "Progressive?%"PRIu16"\n", 0x0001
& data);
+s->progressive = 0x0001 & data;
 } else if (tag == ImageWidth) {
 a