Re: [FFmpeg-devel] [PATCH] libavfilter: constify filter list

2018-01-31 Thread Tobias Rapp

On 30.01.2018 20:37, Michael Niedermayer wrote:

On Tue, Jan 30, 2018 at 08:27:27PM +0700, Muhammad Faiz wrote:

On Tue, Jan 30, 2018 at 7:50 PM, Michael Niedermayer
 wrote:

Its also a step away from supporting plugins.
Why plugins matter ? Because having plugin
support is a big advantage, it allows a much wider
community to work on, write and maintain filters.

With plugins, people can write filters that are
written in languages other than C. Or filters which
some developer in FFmpeg doesnt want. Or they can be
maintained externally by people who just do not like us.
Or by people who perfer a FOSS license different from
LGPL/GPL/BSD. Iam sure others can come up with more
reasons ...

Of course avfilter_register() isnt enough for plugins
but it or something equivalent is needed for plugins.

So i would prefer if avfilter_register() stays supported
indefinitly or in case a different system is written for
plugins then until that system is in place.


It just returns error and logs error message that currently external
filter is unsupported. If someone wants to implement support for
external filter, it can be easily added later using separate
list/table.


Iam not sure "easily" is true

We started out with a fully public API that allowed external filters.
and little by little its removed or made private.
each individual change may be easy to undo but as a whole moving
libavfilter back to having a public API is not that easy anymore

IIRC the arguments to make things private where that people wanted to
improve the API. But from the idea and impression of a plan like:
1. make it private
2. design and implement better API
3. make it public again

Somehow now people lost sight and interrest in 3. and even 2. is becoming
less interresting. But the problem is really without 2 + 3 actually happening
doing 1 seems like not a good idea at all.

To me it seems even mentioning external filters and public API makes some
people angry.
But really that has to be the goal at some point. To again have a public API


I agree that having (again) a public filter API would be good. This 
would give users the freedom to implement their own special-purpose 
filters (see the "dumpwave" discussion).



Is the plan to have 2 seperrate lists at that point ?
one static for internal filters and one dynamic for externally registered
ones ?

Iam not objecting to the patch, theres nothing i have that uses the call
but iam a bit concerned about interrest_to_remove > interrest_in_public_api

thanks


Regards,
Tobias

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


Re: [FFmpeg-devel] [PATCH] libavfilter: constify filter list

2018-01-31 Thread wm4
On Wed, 31 Jan 2018 09:08:23 +0100
Tobias Rapp  wrote:

> On 30.01.2018 20:37, Michael Niedermayer wrote:
> > On Tue, Jan 30, 2018 at 08:27:27PM +0700, Muhammad Faiz wrote:  
> >> On Tue, Jan 30, 2018 at 7:50 PM, Michael Niedermayer
> >>  wrote:  
> >>> Its also a step away from supporting plugins.
> >>> Why plugins matter ? Because having plugin
> >>> support is a big advantage, it allows a much wider
> >>> community to work on, write and maintain filters.
> >>>
> >>> With plugins, people can write filters that are
> >>> written in languages other than C. Or filters which
> >>> some developer in FFmpeg doesnt want. Or they can be
> >>> maintained externally by people who just do not like us.
> >>> Or by people who perfer a FOSS license different from
> >>> LGPL/GPL/BSD. Iam sure others can come up with more
> >>> reasons ...
> >>>
> >>> Of course avfilter_register() isnt enough for plugins
> >>> but it or something equivalent is needed for plugins.
> >>>
> >>> So i would prefer if avfilter_register() stays supported
> >>> indefinitly or in case a different system is written for
> >>> plugins then until that system is in place.  
> >>
> >> It just returns error and logs error message that currently external
> >> filter is unsupported. If someone wants to implement support for
> >> external filter, it can be easily added later using separate
> >> list/table.  
> > 
> > Iam not sure "easily" is true
> > 
> > We started out with a fully public API that allowed external filters.
> > and little by little its removed or made private.
> > each individual change may be easy to undo but as a whole moving
> > libavfilter back to having a public API is not that easy anymore
> > 
> > IIRC the arguments to make things private where that people wanted to
> > improve the API. But from the idea and impression of a plan like:
> > 1. make it private
> > 2. design and implement better API
> > 3. make it public again
> > 
> > Somehow now people lost sight and interrest in 3. and even 2. is becoming
> > less interresting. But the problem is really without 2 + 3 actually 
> > happening
> > doing 1 seems like not a good idea at all.
> > 
> > To me it seems even mentioning external filters and public API makes some
> > people angry.
> > But really that has to be the goal at some point. To again have a public 
> > API  
> 
> I agree that having (again) a public filter API would be good. This 
> would give users the freedom to implement their own special-purpose 
> filters (see the "dumpwave" discussion).

Someone needs to design and write it.

Whether we have external filters is completely orthogonal to this
change. They were not possible before, because not enough API for
implementing them is public. They can be possible in the future, but
then registering them would need a different API anyway (one that
doesn't use global mutable state, but uses some sort of context
instead).
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel


Re: [FFmpeg-devel] [PATCH v3] avcodec/libopus: support disabling phase inversion.

2018-01-31 Thread Menno de Gier
On Fri, Jan 26, 2018 at 11:30 AM, Menno de Gier  wrote:

> From: Menno 
>
> This supports disabling phase inversion in both the libopus encoder and the
> decoder.
>
> Signed-off-by: Menno 
> ---
>  doc/encoders.texi   |  5 +
>  libavcodec/libopusdec.c | 33 +
>  libavcodec/libopusenc.c | 14 ++
>  3 files changed, 52 insertions(+)
>
> diff --git a/doc/encoders.texi b/doc/encoders.texi
> index 6a410a8cb6..c5dfc646d9 100644
> --- a/doc/encoders.texi
> +++ b/doc/encoders.texi
> @@ -981,6 +981,11 @@ Other values include 0 for mono and stereo, 1 for
> surround sound with masking
>  and LFE bandwidth optimizations, and 255 for independent streams with an
>  unspecified channel layout.
>
> +@item apply_phase_inv (N.A.) (requires libopus >= 1.2)
> +If set to 0, disables the use of phase inversion for intensity stereo,
> +improving the quality of mono downmixes, but slightly reducing normal
> stereo
> +quality. The default is 1 (phase inversion enabled).
> +
>  @end table
>
>  @anchor{libshine}
> diff --git a/libavcodec/libopusdec.c b/libavcodec/libopusdec.c
> index 4f7f4755c2..f82ae57e54 100644
> --- a/libavcodec/libopusdec.c
> +++ b/libavcodec/libopusdec.c
> @@ -25,6 +25,7 @@
>  #include "libavutil/internal.h"
>  #include "libavutil/intreadwrite.h"
>  #include "libavutil/ffmath.h"
> +#include "libavutil/opt.h"
>
>  #include "avcodec.h"
>  #include "internal.h"
> @@ -33,11 +34,15 @@
>  #include "libopus.h"
>
>  struct libopus_context {
> +AVClass *class;
>  OpusMSDecoder *dec;
>  int pre_skip;
>  #ifndef OPUS_SET_GAIN
>  union { int i; double d; } gain;
>  #endif
> +#ifdef OPUS_SET_PHASE_INVERSION_DISABLED_REQUEST
> +int apply_phase_inv;
> +#endif
>  };
>
>  #define OPUS_HEAD_SIZE 19
> @@ -136,6 +141,15 @@ static av_cold int libopus_decode_init(AVCodecContext
> *avc)
>  }
>  #endif
>
> +#ifdef OPUS_SET_PHASE_INVERSION_DISABLED_REQUEST
> +ret = opus_multistream_decoder_ctl(opus->dec,
> +   OPUS_SET_PHASE_INVERSION_
> DISABLED(!opus->apply_phase_inv));
> +if (ret != OPUS_OK)
> +av_log(avc, AV_LOG_WARNING,
> +   "Unable to set phase inversion: %s\n",
> +   opus_strerror(ret));
> +#endif
> +
>  /* Decoder delay (in samples) at 48kHz */
>  avc->delay = avc->internal->skip_samples = opus->pre_skip;
>
> @@ -209,6 +223,24 @@ static void libopus_flush(AVCodecContext *avc)
>  avc->internal->skip_samples = opus->pre_skip;
>  }
>
> +
> +#define OFFSET(x) offsetof(struct libopus_context, x)
> +#define FLAGS AV_OPT_FLAG_AUDIO_PARAM | AV_OPT_FLAG_DECODING_PARAM
> +static const AVOption libopusdec_options[] = {
> +#ifdef OPUS_SET_PHASE_INVERSION_DISABLED_REQUEST
> +{ "apply_phase_inv", "Apply intensity stereo phase inversion",
> OFFSET(apply_phase_inv), AV_OPT_TYPE_BOOL, { .i64 = 1 }, 0, 1, FLAGS },
> +{ NULL },
> +#endif
> +};
> +
> +static const AVClass libopusdec_class = {
> +.class_name = "libopusdec",
> +.item_name  = av_default_item_name,
> +.option = libopusdec_options,
> +.version= LIBAVUTIL_VERSION_INT,
> +};
> +
> +
>  AVCodec ff_libopus_decoder = {
>  .name   = "libopus",
>  .long_name  = NULL_IF_CONFIG_SMALL("libopus Opus"),
> @@ -223,5 +255,6 @@ AVCodec ff_libopus_decoder = {
>  .sample_fmts= (const enum AVSampleFormat[]){ AV_SAMPLE_FMT_FLT,
>   AV_SAMPLE_FMT_S16,
>   AV_SAMPLE_FMT_NONE },
> +.priv_class = &libopusdec_class,
>  .wrapper_name   = "libopus",
>  };
> diff --git a/libavcodec/libopusenc.c b/libavcodec/libopusenc.c
> index b449497d15..4ae81b0bb2 100644
> --- a/libavcodec/libopusenc.c
> +++ b/libavcodec/libopusenc.c
> @@ -39,6 +39,9 @@ typedef struct LibopusEncOpts {
>  int packet_size;
>  int max_bandwidth;
>  int mapping_family;
> +#ifdef OPUS_SET_PHASE_INVERSION_DISABLED_REQUEST
> +int apply_phase_inv;
> +#endif
>  } LibopusEncOpts;
>
>  typedef struct LibopusEncContext {
> @@ -154,6 +157,14 @@ static int libopus_configure_encoder(AVCodecContext
> *avctx, OpusMSEncoder *enc,
> "Unable to set maximum bandwidth: %s\n",
> opus_strerror(ret));
>  }
>
> +#ifdef OPUS_SET_PHASE_INVERSION_DISABLED_REQUEST
> +ret = opus_multistream_encoder_ctl(enc,
> +   OPUS_SET_PHASE_INVERSION_
> DISABLED(!opts->apply_phase_inv));
> +if (ret != OPUS_OK)
> +av_log(avctx, AV_LOG_WARNING,
> +   "Unable to set phase inversion: %s\n",
> +   opus_strerror(ret));
> +#endif
>  return OPUS_OK;
>  }
>
> @@ -530,6 +541,9 @@ static const AVOption libopus_options[] = {
>  { "on", "Use variable bit rate", 0,
> AV_OPT_TYPE_CONST, { .i64 = 1 }, 0, 0, FLAGS, "vbr" },
>  { "constrained","Use constrained VBR",   0,
> AV_OPT_TYPE_CONST, { .i64 = 2 }, 0, 0, FLAGS, "vb

Re: [FFmpeg-devel] [PATCH] libavfilter: constify filter list

2018-01-31 Thread Tobias Rapp

On 31.01.2018 10:03, wm4 wrote:

On Wed, 31 Jan 2018 09:08:23 +0100
Tobias Rapp  wrote:


On 30.01.2018 20:37, Michael Niedermayer wrote:

On Tue, Jan 30, 2018 at 08:27:27PM +0700, Muhammad Faiz wrote:

On Tue, Jan 30, 2018 at 7:50 PM, Michael Niedermayer
 wrote:

Its also a step away from supporting plugins.
Why plugins matter ? Because having plugin
support is a big advantage, it allows a much wider
community to work on, write and maintain filters.

With plugins, people can write filters that are
written in languages other than C. Or filters which
some developer in FFmpeg doesnt want. Or they can be
maintained externally by people who just do not like us.
Or by people who perfer a FOSS license different from
LGPL/GPL/BSD. Iam sure others can come up with more
reasons ...

Of course avfilter_register() isnt enough for plugins
but it or something equivalent is needed for plugins.

So i would prefer if avfilter_register() stays supported
indefinitly or in case a different system is written for
plugins then until that system is in place.


It just returns error and logs error message that currently external
filter is unsupported. If someone wants to implement support for
external filter, it can be easily added later using separate
list/table.


Iam not sure "easily" is true

We started out with a fully public API that allowed external filters.
and little by little its removed or made private.
each individual change may be easy to undo but as a whole moving
libavfilter back to having a public API is not that easy anymore

IIRC the arguments to make things private where that people wanted to
improve the API. But from the idea and impression of a plan like:
1. make it private
2. design and implement better API
3. make it public again

Somehow now people lost sight and interrest in 3. and even 2. is becoming
less interresting. But the problem is really without 2 + 3 actually happening
doing 1 seems like not a good idea at all.

To me it seems even mentioning external filters and public API makes some
people angry.
But really that has to be the goal at some point. To again have a public API


I agree that having (again) a public filter API would be good. This
would give users the freedom to implement their own special-purpose
filters (see the "dumpwave" discussion).


Someone needs to design and write it.

Whether we have external filters is completely orthogonal to this
change. They were not possible before, because not enough API for
implementing them is public. They can be possible in the future, but
then registering them would need a different API anyway (one that
doesn't use global mutable state, but uses some sort of context
instead).


Thanks for clarifying, so don't count my comment as an disagreement on 
the patch.


Regards,
Tobias

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


[FFmpeg-devel] [PATCH] configure - add dependencies for MPEG-PS and MPEG-ES demuxers

2018-01-31 Thread Gyan Doshi


MPEG-1/2 video streams in MPEG-PS containers fail to be identified 
unless the raw MPEG video demuxer is also enabled. Once identified, 
decoding for these streams, whether as ES or in PS, isn't error-free 
unless the mpegvideo parser is enabled. Patch adds these dependencies.


MPEG-1/2 videos streams in other containers like MP4, MKV don't have 
these requirements.
From 4c84a9421213ba49f09a30e2777c84b5e15101bf Mon Sep 17 00:00:00 2001
From: Gyan Doshi 
Date: Wed, 31 Jan 2018 14:45:23 +0530
Subject: [PATCH] configure - add dependencies for MPEG-PS and MPEG-ES demuxers

MPEG-1/2 video streams in MPEG-1/2 PS containers require the mpegvideo demuxer
in order to be recognized.

In turn, the mpegvideo parser is required for decoding these and raw MPEG-1/2 
ES.
---
 configure | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/configure b/configure
index fcfa7aa442..3b9956d467 100755
--- a/configure
+++ b/configure
@@ -3031,9 +3031,11 @@ mov_muxer_select="iso_media riffenc rtpenc_chain"
 mp3_demuxer_select="mpegaudio_parser"
 mp3_muxer_select="mpegaudioheader"
 mp4_muxer_select="mov_muxer"
+mpegps_demuxer_select="mpegvideo_demuxer"
 mpegts_demuxer_select="iso_media"
 mpegts_muxer_select="adts_muxer latm_muxer"
 mpegtsraw_demuxer_select="mpegts_demuxer"
+mpegvideo_demuxer_select="mpegvideo_parser"
 mxf_d10_muxer_select="mxf_muxer"
 mxf_opatom_muxer_select="mxf_muxer"
 nut_muxer_select="riffenc"
-- 
2.11.1.windows.1___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel


Re: [FFmpeg-devel] [PATCH] id3v2: fix unsynchronization

2018-01-31 Thread Michael Niedermayer
On Tue, Jan 30, 2018 at 01:43:25PM +0100, wm4 wrote:
> The ID3v2 "unsynchronization scheme" requires replacing any 0xFF 0x00
> sequences with 0xFF. This has to be done on every byte of the source
> data, while the current code skipped a byte after a replacement. This
> meant 0xFF 0x00 0xFF 00 was translated to 0xFF 0xFF 0x00 instead of 0xFF
> 0xFF. It feels a bit messy to do this correctly with the avio use. But
> fortunately, this translation can be done in-place, so we can just do it
> in memory.
> 
> Inspired by what taglib does.
> ---
> Sample (which had corrupted cover art, displays fine with the fix):
> https://0x0.st/sbQ9.bin (unfortunately a bit too large for FATE)
> ---
>  libavformat/id3v2.c | 26 ++
>  1 file changed, 14 insertions(+), 12 deletions(-)

if this works better than before then its a good idea.
Also your code looks better and more efficient than what was there
before

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

The bravest are surely those who have the clearest vision
of what is before them, glory and danger alike, and yet
notwithstanding go out to meet it. -- Thucydides


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


Re: [FFmpeg-devel] [PATCH] libavfilter: constify filter list

2018-01-31 Thread Muhammad Faiz
On Wed, Jan 31, 2018 at 5:26 AM, Mark Thompson  wrote:
> On 30/01/18 18:06, Muhammad Faiz wrote:
>> On Tue, Jan 30, 2018 at 9:09 PM, Mark Thompson  wrote:
>>> On 30/01/18 07:24, Muhammad Faiz wrote:
 Move REGISTER_FILTER to FILTER_TABLE in configure.
 Auto generate filter extern and filter table.
 Sort filter table, use bsearch on avfilter_get_by_name.
 Define next pointer at filter extern, no need to initialize
 next pointer at run time, so AVFilter can be set to const.
 Make avfilter_register always return error.
 Target checkasm now depends on EXTRALIBS-avformat.

 Signed-off-by: Muhammad Faiz 
 ---
>>>
>>> I like the idea of this, but I'm not sure about some of the implementation 
>>> details.
>>>
>>> Have you considered dropping the "next" links entirely and having just the 
>>> array of pointers instead?  I feel like they don't really add anything 
>>> useful once we are in this form, and result in more boilerplate on every 
>>> filter and some tricky generation code.
>>>
>>> avfilter_next() would be a bit slower (since it would have to search the 
>>> array, and therefore have runtime linear in the number of filters), but 
>>> avfilter_get_by_name() is a lot faster because of the binary search (and is 
>>> the only common use of it) so I don't think that complaint would be a 
>>> strong one.
>>
>> Making avfilter_next() slower (even if it is rarely used) isn't good, I 
>> think.
>
> I think the slowdown is irrelevant if it is rarely used.
>
> On the other side, you get rid of a field in AVFilter and avoid having to put 
> some pointless boilerplate in a lot of places.

The other solution is to initialize next pointer on
avfilter_register_all() as before,  add new iterate API, and deprecate
both avfilter_register_all() and avfilter_next().


>
> Related: the one remaining use of avfilter_next() inside lavfi, in 
> filter_child_class_next(), should also be replaced with array operations.  (I 
> can easily do that if you don't want to bother as part of this patch.)

Oh, I forgot it.


>
>>>
  Makefile   |   4 +-
  configure  | 440 
 -
 ...
  tests/checkasm/Makefile|   2 +-
  303 files changed, 1229 insertions(+), 796 deletions(-)

 diff --git a/Makefile b/Makefile
 index 9defddebfd..f607579369 100644
 --- a/Makefile
 +++ b/Makefile
 @@ -56,6 +56,7 @@ tools/uncoded_frame$(EXESUF): ELIBS = $(FF_EXTRALIBS)
  tools/target_dec_%_fuzzer$(EXESUF): $(FF_DEP_LIBS)

  CONFIGURABLE_COMPONENTS =   \
 +$(SRC_PATH)/configure   \
  $(wildcard $(FFLIBS:%=$(SRC_PATH)/lib%/all*.c)) \
  $(SRC_PATH)/libavcodec/bitstream_filters.c  \
  $(SRC_PATH)/libavformat/protocols.c \
 @@ -142,7 +143,8 @@ distclean:: clean
   $(RM) .version avversion.h config.asm config.h mapfile  \
   ffbuild/.config ffbuild/config.* libavutil/avconfig.h \
   version.h libavutil/ffversion.h libavcodec/codec_names.h \
 - libavcodec/bsf_list.c libavformat/protocol_list.c
 + libavcodec/bsf_list.c libavformat/protocol_list.c \
 + libavfilter/filter_list.h libavfilter/filter_list.c
  ifeq ($(SRC_LINK),src)
   $(RM) src
  endif
 diff --git a/configure b/configure
 index fcfa7aa442..3261f5fd1a 100755
 --- a/configure
 +++ b/configure
 @@ -3177,6 +3177,381 @@ unix_protocol_deps="sys_un_h"
  unix_protocol_select="network"

  # filters
 +FILTER_TABLE="
 +abench  af
 +acompressor af
 +acontrast   af
 ...
 +spectrumsynth   vaf
 +amovie  avsrc
 +movie   avsrc
 +"
 +
 +UNCONDITIONAL_FILTER_TABLE="
 +abuffer asrc
 +buffer  vsrc
 +abuffersink asink
 +buffersink  vsink
 +afifo   af
 +fifovf
 +"
 +
>>>
>>> I don't really like having this table in configure.  Since you're 
>>> generating the filter_list.h header with the external definitions from it 
>>> anyway, why not write that and use it as the source rather than having the 
>>> table here?
>>
>> Imho, parsing source code and then generating source code is
>> pointless, it is redundant. Previously, it was just parsing source
>> code without generating source code. And now it is just generating
>> source code without parsing source code. There are no duplicates here.
>
> This is parsing a huge variable in configure and generating two different 
> files from it.  Parsing one file and generating one file seems clearer, 
> though I guess that's mostly subjective.

Without ff_next_* stuff, it will generate only one file. 

Re: [FFmpeg-devel] [PATCH] id3v2: fix unsynchronization

2018-01-31 Thread wm4
On Wed, 31 Jan 2018 11:34:27 +0100
Michael Niedermayer  wrote:

> On Tue, Jan 30, 2018 at 01:43:25PM +0100, wm4 wrote:
> > The ID3v2 "unsynchronization scheme" requires replacing any 0xFF 0x00
> > sequences with 0xFF. This has to be done on every byte of the source
> > data, while the current code skipped a byte after a replacement. This
> > meant 0xFF 0x00 0xFF 00 was translated to 0xFF 0xFF 0x00 instead of 0xFF
> > 0xFF. It feels a bit messy to do this correctly with the avio use. But
> > fortunately, this translation can be done in-place, so we can just do it
> > in memory.
> > 
> > Inspired by what taglib does.
> > ---
> > Sample (which had corrupted cover art, displays fine with the fix):
> > https://0x0.st/sbQ9.bin (unfortunately a bit too large for FATE)
> > ---
> >  libavformat/id3v2.c | 26 ++
> >  1 file changed, 14 insertions(+), 12 deletions(-)  
> 
> if this works better than before then its a good idea.
> Also your code looks better and more efficient than what was there
> before

It definitely makes the sample at hand work, however the sample Libav
attempted to fix seems to be lost.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel


Re: [FFmpeg-devel] [PATCH] libavfilter: constify filter list

2018-01-31 Thread Michael Niedermayer
On Wed, Jan 31, 2018 at 10:03:58AM +0100, wm4 wrote:
> On Wed, 31 Jan 2018 09:08:23 +0100
> Tobias Rapp  wrote:
> 
> > On 30.01.2018 20:37, Michael Niedermayer wrote:
> > > On Tue, Jan 30, 2018 at 08:27:27PM +0700, Muhammad Faiz wrote:  
> > >> On Tue, Jan 30, 2018 at 7:50 PM, Michael Niedermayer
> > >>  wrote:  
> > >>> Its also a step away from supporting plugins.
> > >>> Why plugins matter ? Because having plugin
> > >>> support is a big advantage, it allows a much wider
> > >>> community to work on, write and maintain filters.
> > >>>
> > >>> With plugins, people can write filters that are
> > >>> written in languages other than C. Or filters which
> > >>> some developer in FFmpeg doesnt want. Or they can be
> > >>> maintained externally by people who just do not like us.
> > >>> Or by people who perfer a FOSS license different from
> > >>> LGPL/GPL/BSD. Iam sure others can come up with more
> > >>> reasons ...
> > >>>
> > >>> Of course avfilter_register() isnt enough for plugins
> > >>> but it or something equivalent is needed for plugins.
> > >>>
> > >>> So i would prefer if avfilter_register() stays supported
> > >>> indefinitly or in case a different system is written for
> > >>> plugins then until that system is in place.  
> > >>
> > >> It just returns error and logs error message that currently external
> > >> filter is unsupported. If someone wants to implement support for
> > >> external filter, it can be easily added later using separate
> > >> list/table.  
> > > 
> > > Iam not sure "easily" is true
> > > 
> > > We started out with a fully public API that allowed external filters.
> > > and little by little its removed or made private.
> > > each individual change may be easy to undo but as a whole moving
> > > libavfilter back to having a public API is not that easy anymore
> > > 
> > > IIRC the arguments to make things private where that people wanted to
> > > improve the API. But from the idea and impression of a plan like:
> > > 1. make it private
> > > 2. design and implement better API
> > > 3. make it public again
> > > 
> > > Somehow now people lost sight and interrest in 3. and even 2. is becoming
> > > less interresting. But the problem is really without 2 + 3 actually 
> > > happening
> > > doing 1 seems like not a good idea at all.
> > > 
> > > To me it seems even mentioning external filters and public API makes some
> > > people angry.
> > > But really that has to be the goal at some point. To again have a public 
> > > API  
> > 
> > I agree that having (again) a public filter API would be good. This 
> > would give users the freedom to implement their own special-purpose 
> > filters (see the "dumpwave" discussion).
> 
> Someone needs to design and write it.
> 
> Whether we have external filters is completely orthogonal to this
> change. 

> They were not possible before, because not enough API for
> implementing them is public. 

This is correct if by "before" you mean today before this is applied.
But longer ago, as in years, it was possible


> They can be possible in the future, but
> then registering them would need a different API anyway (one that
> doesn't use global mutable state, but uses some sort of context
> instead).

i understand that you arent a native english speaker nor am i but
what you write here is not true.

Several people desire to eliminate all "global mutable state"
and thats fine, iam happy if that is achieved. But its not
that its neccessary for a fully functional API register or otherwise.
The registering code with "global mutable state" and some form
of thread synchronization would work perfectly fine.

What exactly is in relation to registering the problem with 
"global mutable state" ?

One application registering a filter with a common name and another 
application unintentionally using that ?

This is not even possible because each application is in its own process and
will have its own independant copy of libavfilter in its address space only
with "read only" pages shared or with pages with "copy on write".

The "one registers the other uses it by mistake" issue is as far as i
understand only possible if an application uses libavfilter and that
application uses also a lib that itself uses libavfilter too or
similar cases. 
And then both mess with registering custom filters and using custom
filters.
That looks like a very rare situation. If thats the only issue, i would
really not say theres a "need" to avoid "global mutable state"



[...]

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Never trust a computer, one day, it may think you are the virus. -- Compn


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


Re: [FFmpeg-devel] [PATCH] hwcontext_vaapi: add iHD open source driver.

2018-01-31 Thread Mark Thompson
On 31/01/18 00:35, Jun Zhao wrote:
> Now FFmpeg-VAAPI work with iHD open source driver
> (https://github.com/intel/media-driver) initiatory.
> 
> From 069611945880643aad6ffb5ea70b732f40bbb510 Mon Sep 17 00:00:00 2001
> From: Jun Zhao 
> Date: Wed, 31 Jan 2018 08:21:30 +0800
> Subject: [PATCH] hwcontext_vaapi: add iHD open source driver.
> 
> Signed-off-by: Jun Zhao 
> ---
>  libavutil/hwcontext_vaapi.c | 4 
>  1 file changed, 4 insertions(+)
> 
> diff --git a/libavutil/hwcontext_vaapi.c b/libavutil/hwcontext_vaapi.c
> index 29698d1b27..34c5a2c264 100644
> --- a/libavutil/hwcontext_vaapi.c
> +++ b/libavutil/hwcontext_vaapi.c
> @@ -285,6 +285,10 @@ static const struct {
>  "ubit",
>  AV_VAAPI_DRIVER_QUIRK_ATTRIB_MEMTYPE,
>  },
> +{
> +"Intel iHD open source driver",
> +"Intel iHD driver",
> +},
>  {
>  "VDPAU wrapper",
>  "Splitted-Desktop Systems VDPAU backend for VA-API",
> -- 
> 2.14.1
> 

Why?  This is the "list of shame" for drivers with bad or incomplete 
implementations which need explicit workarounds.  Since the iHD driver is new 
(in some sense), hopefully it will be a correct implementation which does not 
require any of these.

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


Re: [FFmpeg-devel] [PATCH] libavfilter: constify filter list

2018-01-31 Thread wm4
On Wed, 31 Jan 2018 12:11:25 +0100
Michael Niedermayer  wrote:

> On Wed, Jan 31, 2018 at 10:03:58AM +0100, wm4 wrote:
> > On Wed, 31 Jan 2018 09:08:23 +0100
> > Tobias Rapp  wrote:
> >   
> > > On 30.01.2018 20:37, Michael Niedermayer wrote:  
> > > > On Tue, Jan 30, 2018 at 08:27:27PM +0700, Muhammad Faiz wrote:
> > > >> On Tue, Jan 30, 2018 at 7:50 PM, Michael Niedermayer
> > > >>  wrote:
> > > >>> Its also a step away from supporting plugins.
> > > >>> Why plugins matter ? Because having plugin
> > > >>> support is a big advantage, it allows a much wider
> > > >>> community to work on, write and maintain filters.
> > > >>>
> > > >>> With plugins, people can write filters that are
> > > >>> written in languages other than C. Or filters which
> > > >>> some developer in FFmpeg doesnt want. Or they can be
> > > >>> maintained externally by people who just do not like us.
> > > >>> Or by people who perfer a FOSS license different from
> > > >>> LGPL/GPL/BSD. Iam sure others can come up with more
> > > >>> reasons ...
> > > >>>
> > > >>> Of course avfilter_register() isnt enough for plugins
> > > >>> but it or something equivalent is needed for plugins.
> > > >>>
> > > >>> So i would prefer if avfilter_register() stays supported
> > > >>> indefinitly or in case a different system is written for
> > > >>> plugins then until that system is in place.
> > > >>
> > > >> It just returns error and logs error message that currently external
> > > >> filter is unsupported. If someone wants to implement support for
> > > >> external filter, it can be easily added later using separate
> > > >> list/table.
> > > > 
> > > > Iam not sure "easily" is true
> > > > 
> > > > We started out with a fully public API that allowed external filters.
> > > > and little by little its removed or made private.
> > > > each individual change may be easy to undo but as a whole moving
> > > > libavfilter back to having a public API is not that easy anymore
> > > > 
> > > > IIRC the arguments to make things private where that people wanted to
> > > > improve the API. But from the idea and impression of a plan like:
> > > > 1. make it private
> > > > 2. design and implement better API
> > > > 3. make it public again
> > > > 
> > > > Somehow now people lost sight and interrest in 3. and even 2. is 
> > > > becoming
> > > > less interresting. But the problem is really without 2 + 3 actually 
> > > > happening
> > > > doing 1 seems like not a good idea at all.
> > > > 
> > > > To me it seems even mentioning external filters and public API makes 
> > > > some
> > > > people angry.
> > > > But really that has to be the goal at some point. To again have a 
> > > > public API
> > > 
> > > I agree that having (again) a public filter API would be good. This 
> > > would give users the freedom to implement their own special-purpose 
> > > filters (see the "dumpwave" discussion).  
> > 
> > Someone needs to design and write it.
> > 
> > Whether we have external filters is completely orthogonal to this
> > change.   
> 
> > They were not possible before, because not enough API for
> > implementing them is public.   
> 
> This is correct if by "before" you mean today before this is applied.
> But longer ago, as in years, it was possible
> 
> 
> > They can be possible in the future, but
> > then registering them would need a different API anyway (one that
> > doesn't use global mutable state, but uses some sort of context
> > instead).  
> 
> i understand that you arent a native english speaker nor am i but
> what you write here is not true.
> 
> Several people desire to eliminate all "global mutable state"
> and thats fine, iam happy if that is achieved. But its not
> that its neccessary for a fully functional API register or otherwise.
> The registering code with "global mutable state" and some form
> of thread synchronization would work perfectly fine.
> 
> What exactly is in relation to registering the problem with 
> "global mutable state" ?
> 
> One application registering a filter with a common name and another 
> application unintentionally using that ?

Yes. It's not library-safe.

> This is not even possible because each application is in its own process and
> will have its own independant copy of libavfilter in its address space only
> with "read only" pages shared or with pages with "copy on write".

This is a library. There can be multiple users of a library in the same
process.

> The "one registers the other uses it by mistake" issue is as far as i
> understand only possible if an application uses libavfilter and that
> application uses also a lib that itself uses libavfilter too or
> similar cases. 
> And then both mess with registering custom filters and using custom
> filters.
> That looks like a very rare situation. If thats the only issue, i would
> really not say theres a "need" to avoid "global mutable state"

I don't agree. It will cause problems you're not even thinking about
now. Look at any library that thou

[FFmpeg-devel] [CLT2018] FFmpeg at Chemnitzer Linux-Tage

2018-01-31 Thread Thilo Borgmann
Hi,

once again, FFmpeg has been accepted for CLT 2018 in Chemnitz, Germany!
This "Chemnitzer Linux Tage" will take place on 10th and 11th of March.
You can find more details on their homepage:

https://chemnitzer.linux-tage.de/2018/en/

Thus once again, we will man a booth with our staff and are happily waiting for
our users to get in touch with us! If you're a developer and want to help us or
just want to visit and check in at our booth, please let us know.

Our CLT team currently registered:

Carl Eugen Hoyos
Thomas Volkert
Alexander Strasser
Thilo Borgmann

We would like to encourage everyone visiting the CLT to bring us sample files
and/or command lines that show suspicious or buggy behavior - this will be your
change to get your bug fixed right away! :)

We are currently reworking our demo cycles so that we might end up with a
totally different demo this year. Ideas & suggestions more than welcome!

See you in Chemnitz!
-Thilo
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel


[FFmpeg-devel] [CLT2018] FFmpeg at Chemnitzer Linux-Tage

2018-01-31 Thread Thilo Borgmann
Hi,

once again, FFmpeg has been accepted for CLT 2018 in Chemnitz, Germany!
This "Chemnitzer Linux Tage" will take place on 10th and 11th of March.
You can find more details on their homepage:

https://chemnitzer.linux-tage.de/2018/en/

Thus once again, we will man a booth with our staff and are happily waiting for
our users to get in touch with us! If you're a developer and want to help us or
just want to visit and check in at our booth, please let us know.

Our CLT team currently registered:

Carl Eugen Hoyos
Thomas Volkert
Alexander Strasser
Thilo Borgmann

We would like to encourage everyone visiting the CLT to bring us sample files
and/or command lines that show suspicious or buggy behavior - this will be your
change to get your bug fixed right away!

We are currently reworking our demo cycles so that we might end up with a
totally different demo this year. Ideas & suggestions more than welcome!

See you in Chemnitz!
-Thilo
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel


Re: [FFmpeg-devel] [CLT2018] FFmpeg at Chemnitzer Linux-Tage

2018-01-31 Thread Thilo Borgmann
Am 31.01.18 um 12:38 schrieb Thilo Borgmann:
> ...

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


Re: [FFmpeg-devel] [PATCH] libavfilter: constify filter list

2018-01-31 Thread Mark Thompson
On 31/01/18 10:37, Muhammad Faiz wrote:
> On Wed, Jan 31, 2018 at 5:26 AM, Mark Thompson  wrote:
>> On 30/01/18 18:06, Muhammad Faiz wrote:
>>> On Tue, Jan 30, 2018 at 9:09 PM, Mark Thompson  wrote:
 On 30/01/18 07:24, Muhammad Faiz wrote:
> Move REGISTER_FILTER to FILTER_TABLE in configure.
> Auto generate filter extern and filter table.
> Sort filter table, use bsearch on avfilter_get_by_name.
> Define next pointer at filter extern, no need to initialize
> next pointer at run time, so AVFilter can be set to const.
> Make avfilter_register always return error.
> Target checkasm now depends on EXTRALIBS-avformat.
>
> Signed-off-by: Muhammad Faiz 
> ---

 I like the idea of this, but I'm not sure about some of the implementation 
 details.

 Have you considered dropping the "next" links entirely and having just the 
 array of pointers instead?  I feel like they don't really add anything 
 useful once we are in this form, and result in more boilerplate on every 
 filter and some tricky generation code.

 avfilter_next() would be a bit slower (since it would have to search the 
 array, and therefore have runtime linear in the number of filters), but 
 avfilter_get_by_name() is a lot faster because of the binary search (and 
 is the only common use of it) so I don't think that complaint would be a 
 strong one.
>>>
>>> Making avfilter_next() slower (even if it is rarely used) isn't good, I 
>>> think.
>>
>> I think the slowdown is irrelevant if it is rarely used.
>>
>> On the other side, you get rid of a field in AVFilter and avoid having to 
>> put some pointless boilerplate in a lot of places.
> 
> The other solution is to initialize next pointer on
> avfilter_register_all() as before,  add new iterate API, and deprecate
> both avfilter_register_all() and avfilter_next().

I guess having thought about this further my problem is that you appear to be 
writing a lot of new infrastructure for creating and updating the next links 
(with special generation code in configure and extra boilerplate on every 
filter) when the feature does not have any clear value.  Once other functions 
are properly updated the only place where the next link is used is in 
avfilter_next(), which is only slowed down a little bit and would never be 
called in performance-sensitive code anyway.  A new iterate API would be 
welcome but is mostly orthogonal - you aren't going to call that in 
performance-sensitive code either.

So, can we just drop the next links completely?

- Mark


(Everything else trimmed.  I'm ok with the huge lists in configure if other 
people agree to it, I just found it rather inelegant compared to the current 
per-library information in separate files.)
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel


Re: [FFmpeg-devel] [PATCH] libavfilter: constify filter list

2018-01-31 Thread wm4
On Wed, 31 Jan 2018 11:52:14 +
Mark Thompson  wrote:

> >> On the other side, you get rid of a field in AVFilter and avoid having to 
> >> put some pointless boilerplate in a lot of places.  
> > 
> > The other solution is to initialize next pointer on
> > avfilter_register_all() as before,  add new iterate API, and deprecate
> > both avfilter_register_all() and avfilter_next().  
> 
> I guess having thought about this further my problem is that you appear to be 
> writing a lot of new infrastructure for creating and updating the next links 
> (with special generation code in configure and extra boilerplate on every 
> filter) when the feature does not have any clear value.  Once other functions 
> are properly updated the only place where the next link is used is in 
> avfilter_next(), which is only slowed down a little bit and would never be 
> called in performance-sensitive code anyway.  A new iterate API would be 
> welcome but is mostly orthogonal - you aren't going to call that in 
> performance-sensitive code either.
> 
> So, can we just drop the next links completely?

Just as a comment on the side: if he changes that, I'd prefer of the
next links are lazily initialized and only when using the old API. That
would waste less memory (since writing the next link will trigger copy
on write and in the worst case waste 4K (a page) per filter.

(Personally I found the static next links rather neat, but yeah, maybe
it's too much configure magic.)
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel


[FFmpeg-devel] [PATCH] avformat/bintext: Implement bin_probe()

2018-01-31 Thread Michael Niedermayer
Fixes misdetection of sbQ9.bin

Signed-off-by: Michael Niedermayer 
---
 libavformat/bintext.c | 49 -
 1 file changed, 48 insertions(+), 1 deletion(-)

diff --git a/libavformat/bintext.c b/libavformat/bintext.c
index 12e3bfde4d..722a40c3e5 100644
--- a/libavformat/bintext.c
+++ b/libavformat/bintext.c
@@ -126,6 +126,53 @@ static void predict_width(AVCodecParameters *par, uint64_t 
fsize, int got_width)
 par->width = fsize > 4000 ? (160<<3) : (80<<3);
 }
 
+static int bin_probe(AVProbeData *p)
+{
+const uint8_t *d = p->buf;
+int magic = 0, sauce = 0;
+int invisible = 0;
+int i;
+
+if (p->buf_size > 256)
+magic = !memcmp(d + p->buf_size - 256, next_magic, sizeof(next_magic));
+if (p->buf_size > 128)
+sauce = !memcmp(d + p->buf_size - 128, "SAUCE00", 7);
+
+if (magic)
+return AVPROBE_SCORE_MAX / 2;
+
+if (av_match_ext(p->filename, "bin")) {
+AVCodecParameters par;
+int got_width = 0;
+par.width = par.height = 0;
+if (sauce)
+return AVPROBE_SCORE_MAX / 2;
+
+predict_width(&par, p->buf_size, got_width);
+if (par.width <= 0)
+return 0;
+calculate_height(&par, p->buf_size);
+if (par.height <= 0)
+return 0;
+
+for (i = 0; i < p->buf_size - 256;  i+=2) {
+if ((d[i+1] & 15) == (d[i+1] >> 4) && d[i] && d[i] != 0xFF && d[i] 
!= ' ') {
+invisible ++;
+}
+}
+
+if (par.width * par.height * 2 / (8*16) == p->buf_size)
+return AVPROBE_SCORE_MAX / 2;
+return 1;
+}
+
+if (sauce)
+return 1;
+
+return 0;
+}
+
+
 static int bintext_read_header(AVFormatContext *s)
 {
 BinDemuxContext *bin = s->priv_data;
@@ -343,9 +390,9 @@ AVInputFormat ff_bintext_demuxer = {
 .name   = "bin",
 .long_name  = NULL_IF_CONFIG_SMALL("Binary text"),
 .priv_data_size = sizeof(BinDemuxContext),
+.read_probe = bin_probe,
 .read_header= bintext_read_header,
 .read_packet= read_packet,
-.extensions = "bin",
 .priv_class = CLASS("Binary text demuxer"),
 };
 #endif
-- 
2.16.1

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


[FFmpeg-devel] [PATCH] vc2enc: prevent bitrate overshoots

2018-01-31 Thread James Darnley
From: Rostislav Pehlivanov 

The rounding caused by the size scaler wasn't compensated for and the
slice sizes grew beyond what is allowed per frame.

Signed-off-by: Rostislav Pehlivanov 
---
 libavcodec/vc2enc.c | 22 ++
 1 file changed, 14 insertions(+), 8 deletions(-)

diff --git a/libavcodec/vc2enc.c b/libavcodec/vc2enc.c
index 2f08441d55..b7adcd3d36 100644
--- a/libavcodec/vc2enc.c
+++ b/libavcodec/vc2enc.c
@@ -164,6 +164,7 @@ typedef struct VC2EncContext {
 int chroma_y_shift;
 
 /* Rate control stuff */
+int frame_max_bytes;
 int slice_max_bytes;
 int slice_min_bytes;
 int q_ceil;
@@ -715,7 +716,7 @@ static int calc_slice_sizes(VC2EncContext *s)
 
 for (i = 0; i < s->num_x*s->num_y; i++) {
 SliceArgs *args = &enc_args[i];
-bytes_left += s->slice_max_bytes - args->bytes;
+bytes_left += args->bytes;
 for (j = 0; j < slice_redist_range; j++) {
 if (args->bytes > bytes_top[j]) {
 bytes_top[j] = args->bytes;
@@ -725,8 +726,10 @@ static int calc_slice_sizes(VC2EncContext *s)
 }
 }
 
+bytes_left = s->frame_max_bytes - bytes_left;
+
 /* Second pass - distribute leftover bytes */
-while (1) {
+while (bytes_left > 0) {
 int distributed = 0;
 for (i = 0; i < slice_redist_range; i++) {
 SliceArgs *args;
@@ -994,13 +997,13 @@ static av_cold int vc2_encode_frame(AVCodecContext 
*avctx, AVPacket *avpkt,
   const AVFrame *frame, int *got_packet)
 {
 int ret = 0;
-int sig_size = 256;
+int slice_ceil, sig_size = 256;
 VC2EncContext *s = avctx->priv_data;
 const int bitexact = avctx->flags & AV_CODEC_FLAG_BITEXACT;
 const char *aux_data = bitexact ? "Lavc" : LIBAVCODEC_IDENT;
 const int aux_data_size = bitexact ? sizeof("Lavc") : 
sizeof(LIBAVCODEC_IDENT);
 const int header_size = 100 + aux_data_size;
-int64_t max_frame_bytes, r_bitrate = avctx->bit_rate >> (s->interlaced);
+int64_t r_bitrate = avctx->bit_rate >> (s->interlaced);
 
 s->avctx = avctx;
 s->size_scaler = 2;
@@ -1009,18 +1012,21 @@ static av_cold int vc2_encode_frame(AVCodecContext 
*avctx, AVPacket *avpkt,
 s->next_parse_offset = 0;
 
 /* Rate control */
-max_frame_bytes = (av_rescale(r_bitrate, s->avctx->time_base.num,
-  s->avctx->time_base.den) >> 3) - header_size;
-s->slice_max_bytes = av_rescale(max_frame_bytes, 1, s->num_x*s->num_y);
+s->frame_max_bytes = (av_rescale(r_bitrate, s->avctx->time_base.num,
+ s->avctx->time_base.den) >> 3) - 
header_size;
+s->slice_max_bytes = slice_ceil = av_rescale(s->frame_max_bytes, 1, 
s->num_x*s->num_y);
 
 /* Find an appropriate size scaler */
 while (sig_size > 255) {
 int r_size = SSIZE_ROUND(s->slice_max_bytes);
+if (r_size > slice_ceil) {
+s->slice_max_bytes -= r_size - slice_ceil;
+r_size = SSIZE_ROUND(s->slice_max_bytes);
+}
 sig_size = r_size/s->size_scaler; /* Signalled slize size */
 s->size_scaler <<= 1;
 }
 
-s->slice_max_bytes = SSIZE_ROUND(s->slice_max_bytes);
 s->slice_min_bytes = s->slice_max_bytes - 
s->slice_max_bytes*(s->tolerance/100.0f);
 
 ret = encode_frame(s, avpkt, frame, aux_data, header_size, s->interlaced);
-- 
2.16.1

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


Re: [FFmpeg-devel] [PATCH] avformat/bintext: Implement bin_probe()

2018-01-31 Thread Carl Eugen Hoyos
2018-01-31 15:22 GMT+01:00 Michael Niedermayer :
> Fixes misdetection of sbQ9.bin
>
> Signed-off-by: Michael Niedermayer 
> ---
>  libavformat/bintext.c | 49 -
>  1 file changed, 48 insertions(+), 1 deletion(-)
>
> diff --git a/libavformat/bintext.c b/libavformat/bintext.c
> index 12e3bfde4d..722a40c3e5 100644
> --- a/libavformat/bintext.c
> +++ b/libavformat/bintext.c
> @@ -126,6 +126,53 @@ static void predict_width(AVCodecParameters *par, 
> uint64_t fsize, int got_width)
>  par->width = fsize > 4000 ? (160<<3) : (80<<3);
>  }
>
> +static int bin_probe(AVProbeData *p)
> +{
> +const uint8_t *d = p->buf;
> +int magic = 0, sauce = 0;
> +int invisible = 0;
> +int i;
> +
> +if (p->buf_size > 256)
> +magic = !memcmp(d + p->buf_size - 256, next_magic, 
> sizeof(next_magic));
> +if (p->buf_size > 128)
> +sauce = !memcmp(d + p->buf_size - 128, "SAUCE00", 7);
> +
> +if (magic)
> +return AVPROBE_SCORE_MAX / 2;

This seems too low to me or am I wrong?

> +
> +if (av_match_ext(p->filename, "bin")) {
> +AVCodecParameters par;
> +int got_width = 0;
> +par.width = par.height = 0;

> +if (sauce)
> +return AVPROBE_SCORE_MAX / 2;

Same here.

> +
> +predict_width(&par, p->buf_size, got_width);
> +if (par.width <= 0)
> +return 0;
> +calculate_height(&par, p->buf_size);
> +if (par.height <= 0)
> +return 0;
> +
> +for (i = 0; i < p->buf_size - 256;  i+=2) {
> +if ((d[i+1] & 15) == (d[i+1] >> 4) && d[i] && d[i] != 0xFF && 
> d[i] != ' ') {

> +invisible ++;

This looks unused.

> +}
> +}
> +
> +if (par.width * par.height * 2 / (8*16) == p->buf_size)
> +return AVPROBE_SCORE_MAX / 2;

Shouldn't this also be a higher score?

Thank you for looking into this issue, Carl Eugen
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel


Re: [FFmpeg-devel] [PATCH] configure - add dependencies for MPEG-PS and MPEG-ES demuxers

2018-01-31 Thread Carl Eugen Hoyos
2018-01-31 11:03 GMT+01:00 Gyan Doshi :
>
> MPEG-1/2 video streams in MPEG-PS containers fail to be identified unless
> the raw MPEG video demuxer is also enabled. Once identified, decoding for
> these streams, whether as ES or in PS, isn't error-free unless the mpegvideo
> parser is enabled. Patch adds these dependencies.

While this would help me personally, I don't think it is correct:
Many such examples exist, I believe the dependencies are meant to
ensure compilation, not necessarily specific use-cases.

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


Re: [FFmpeg-devel] [PATCH] configure - add dependencies for MPEG-PS and MPEG-ES demuxers

2018-01-31 Thread Gyan Doshi


On 1/31/2018 10:18 PM, Carl Eugen Hoyos wrote:


While this would help me personally, I don't think it is correct:
Many such examples exist, I believe the dependencies are meant to
ensure compilation, not necessarily specific use-cases.


Compilation in its own does succeed. And that's the problem. The most 
common major payloads can't be accessed (or identified) without these 
other components, making the PS demuxer, solo, close to useless.


Will *_suggest be fine?


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


[FFmpeg-devel] [PATCH 2/3] avcodec/aacsbr_fixed: Fix overflows in rounding in sbr_hf_assemble()

2018-01-31 Thread Michael Niedermayer
Fixes: runtime error: signed integer overflow: 2052929346 + 204817098 cannot be 
represented in type 'int'
Fixes: 5275/clusterfuzz-testcase-minimized-5367635958038528

Found-by: continuous fuzzing process 
https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer 
---
 libavcodec/aacsbr_fixed.c | 9 +
 1 file changed, 5 insertions(+), 4 deletions(-)

diff --git a/libavcodec/aacsbr_fixed.c b/libavcodec/aacsbr_fixed.c
index 3d5875a469..eeada0b9f2 100644
--- a/libavcodec/aacsbr_fixed.c
+++ b/libavcodec/aacsbr_fixed.c
@@ -568,7 +568,8 @@ static void sbr_hf_assemble(int Y1[38][64][2],
 int A = (1-((indexsine+(kx & 1))&2));
 int B = (A^(-idx)) + idx;
 int *out = &Y1[i][kx][idx];
-int shift, round;
+int shift;
+unsigned round;
 
 SoftFloat *in  = sbr->s_m[e];
 for (m = 0; m+1 < m_max; m+=2) {
@@ -581,12 +582,12 @@ static void sbr_hf_assemble(int Y1[38][64][2],
 }
 if (shift < 32) {
 round = 1 << (shift-1);
-out[2*m  ] += (in[m  ].mant * A + round) >> shift;
+out[2*m  ] += (int)(in[m  ].mant * A + round) >> shift;
 }
 
 if (shift2 < 32) {
 round = 1 << (shift2-1);
-out[2*m+2] += (in[m+1].mant * B + round) >> shift2;
+out[2*m+2] += (int)(in[m+1].mant * B + round) >> 
shift2;
 }
 }
 if(m_max&1)
@@ -597,7 +598,7 @@ static void sbr_hf_assemble(int Y1[38][64][2],
 return;
 } else if (shift < 32) {
 round = 1 << (shift-1);
-out[2*m  ] += (in[m  ].mant * A + round) >> shift;
+out[2*m  ] += (int)(in[m  ].mant * A + round) >> shift;
 }
 }
 }
-- 
2.16.1

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


[FFmpeg-devel] [PATCH 1/3] avcodec/exr: Fix memleaks in decode_header()

2018-01-31 Thread Michael Niedermayer
Fixes: 4793/clusterfuzz-testcase-minimized-5707366629638144

Found-by: continuous fuzzing process 
https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer 
---
 libavcodec/exr.c | 82 ++--
 1 file changed, 56 insertions(+), 26 deletions(-)

diff --git a/libavcodec/exr.c b/libavcodec/exr.c
index 454dc74cfb..cafd179cbd 100644
--- a/libavcodec/exr.c
+++ b/libavcodec/exr.c
@@ -1306,6 +1306,7 @@ static int decode_header(EXRContext *s, AVFrame *frame)
 AVDictionary *metadata = NULL;
 int magic_number, version, i, flags, sar = 0;
 int layer_match = 0;
+int ret;
 
 s->current_channel_offset = 0;
 s->xmin   = ~0;
@@ -1364,8 +1365,10 @@ static int decode_header(EXRContext *s, AVFrame *frame)
 if ((var_size = check_header_variable(s, "channels",
   "chlist", 38)) >= 0) {
 GetByteContext ch_gb;
-if (!var_size)
-return AVERROR_INVALIDDATA;
+if (!var_size) {
+ret = AVERROR_INVALIDDATA;
+goto fail;
+}
 
 bytestream2_init(&ch_gb, s->gb.buffer, var_size);
 
@@ -1424,14 +1427,16 @@ static int decode_header(EXRContext *s, AVFrame *frame)
 
 if (bytestream2_get_bytes_left(&ch_gb) < 4) {
 av_log(s->avctx, AV_LOG_ERROR, "Incomplete header.\n");
-return AVERROR_INVALIDDATA;
+ret = AVERROR_INVALIDDATA;
+goto fail;
 }
 
 current_pixel_type = bytestream2_get_le32(&ch_gb);
 if (current_pixel_type >= EXR_UNKNOWN) {
 avpriv_report_missing_feature(s->avctx, "Pixel type %d",
   current_pixel_type);
-return AVERROR_PATCHWELCOME;
+ret = AVERROR_PATCHWELCOME;
+goto fail;
 }
 
 bytestream2_skip(&ch_gb, 4);
@@ -1442,7 +1447,8 @@ static int decode_header(EXRContext *s, AVFrame *frame)
 avpriv_report_missing_feature(s->avctx,
   "Subsampling %dx%d",
   xsub, ysub);
-return AVERROR_PATCHWELCOME;
+ret = AVERROR_PATCHWELCOME;
+goto fail;
 }
 
 if (channel_index >= 0 && s->channel_offsets[channel_index] == 
-1) { /* channel has not been previously assigned */
@@ -1450,7 +1456,8 @@ static int decode_header(EXRContext *s, AVFrame *frame)
 s->pixel_type != current_pixel_type) {
 av_log(s->avctx, AV_LOG_ERROR,
"RGB channels not of the same depth.\n");
-return AVERROR_INVALIDDATA;
+ret = AVERROR_INVALIDDATA;
+goto fail;
 }
 s->pixel_type = current_pixel_type;
 s->channel_offsets[channel_index] = 
s->current_channel_offset;
@@ -1458,8 +1465,10 @@ static int decode_header(EXRContext *s, AVFrame *frame)
 
 s->channels = av_realloc(s->channels,
  ++s->nb_channels * 
sizeof(EXRChannel));
-if (!s->channels)
-return AVERROR(ENOMEM);
+if (!s->channels) {
+ret = AVERROR(ENOMEM);;
+goto fail;
+}
 channel = &s->channels[s->nb_channels - 1];
 channel->pixel_type = current_pixel_type;
 channel->xsub   = xsub;
@@ -1484,7 +1493,8 @@ static int decode_header(EXRContext *s, AVFrame *frame)
 av_log(s->avctx, AV_LOG_ERROR, "Missing green 
channel.\n");
 if (s->channel_offsets[2] < 0)
 av_log(s->avctx, AV_LOG_ERROR, "Missing blue 
channel.\n");
-return AVERROR_INVALIDDATA;
+ret = AVERROR_INVALIDDATA;
+goto fail;
 }
 }
 
@@ -1493,8 +1503,10 @@ static int decode_header(EXRContext *s, AVFrame *frame)
 continue;
 } else if ((var_size = check_header_variable(s, "dataWindow", "box2i",
  31)) >= 0) {
-if (!var_size)
-return AVERROR_INVALIDDATA;
+if (!var_size) {
+ret = AVERROR_INVALIDDATA;
+goto fail;
+}
 
 s->xmin   = bytestream2_get_le32(&s->gb);
 s->ymin   = bytestream2_get_le32(&s->gb);
@@ -1506,8 +1518,10 @@ static int decode_header(EXRContext *s, AVFrame *frame)
 continue;
 } else if ((v

[FFmpeg-devel] [PATCH 3/3] avcodec/huffyuvdec: Check input buffer size

2018-01-31 Thread Michael Niedermayer
Fixes: Timeout
Fixes: 5487/clusterfuzz-testcase-4696837035393024

Found-by: continuous fuzzing process 
https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
Signed-off-by: Michael Niedermayer 
---
 libavcodec/huffyuvdec.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/libavcodec/huffyuvdec.c b/libavcodec/huffyuvdec.c
index 979c4b9d5c..66357bfb40 100644
--- a/libavcodec/huffyuvdec.c
+++ b/libavcodec/huffyuvdec.c
@@ -919,6 +919,9 @@ static int decode_frame(AVCodecContext *avctx, void *data, 
int *got_frame,
 AVFrame *const p = data;
 int table_size = 0, ret;
 
+if (buf_size < (width * height + 7)/8)
+return AVERROR_INVALIDDATA;
+
 av_fast_padded_malloc(&s->bitstream_buffer,
&s->bitstream_buffer_size,
buf_size);
-- 
2.16.1

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


Re: [FFmpeg-devel] [PATCH] configure - add dependencies for MPEG-PS and MPEG-ES demuxers

2018-01-31 Thread Hendrik Leppkes
On Wed, Jan 31, 2018 at 6:22 PM, Gyan Doshi  wrote:
>
> On 1/31/2018 10:18 PM, Carl Eugen Hoyos wrote:
>>
>>
>> While this would help me personally, I don't think it is correct:
>> Many such examples exist, I believe the dependencies are meant to
>> ensure compilation, not necessarily specific use-cases.
>
>
> Compilation in its own does succeed. And that's the problem. The most common
> major payloads can't be accessed (or identified) without these other
> components, making the PS demuxer, solo, close to useless.
>

It is somewhat intentional that components do not depend on each other
like this. Someone that has only specific requirements may not need
those detections, so we generally do not force anything like that.
Anyone who wants a very minimal build needs to configure components
very carefully, specifically because of these interactions.

Note that _suggest serves a different purpose in configure then one
might know from other systems, and would not be appropriate.

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


Re: [FFmpeg-devel] [PATCH 3/3] avcodec/huffyuvdec: Check input buffer size

2018-01-31 Thread Paul B Mahol
On 1/31/18, Michael Niedermayer  wrote:
> Fixes: Timeout
> Fixes: 5487/clusterfuzz-testcase-4696837035393024
>
> Found-by: continuous fuzzing process
> https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
> Signed-off-by: Michael Niedermayer 
> ---
>  libavcodec/huffyuvdec.c | 3 +++
>  1 file changed, 3 insertions(+)
>
> diff --git a/libavcodec/huffyuvdec.c b/libavcodec/huffyuvdec.c
> index 979c4b9d5c..66357bfb40 100644
> --- a/libavcodec/huffyuvdec.c
> +++ b/libavcodec/huffyuvdec.c
> @@ -919,6 +919,9 @@ static int decode_frame(AVCodecContext *avctx, void
> *data, int *got_frame,
>  AVFrame *const p = data;
>  int table_size = 0, ret;
>
> +if (buf_size < (width * height + 7)/8)
> +return AVERROR_INVALIDDATA;
> +

Are you sure this is enough?

Something similar you had already posted long ago.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel


Re: [FFmpeg-devel] [PATCH] configure - add dependencies for MPEG-PS and MPEG-ES demuxers

2018-01-31 Thread Gyan Doshi

On 1/31/2018 11:50 PM, Hendrik Leppkes wrote:


Anyone who wants a very minimal build needs to configure components
very carefully, specifically because of these interactions.


In this case, how would a non-dev user go about discovering which 
components other than the 'obvious' ones are required for adequate 
functionality?


For someone who has compiled only the PS demuxer + MPEG-1/2 decoders, 
there's no part of the documentation devoted to selection of 
non-dependent but still essential components. In this case, ffmpeg's 
console output also provides no clues, only the appearance of a broken 
demuxer.


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


Re: [FFmpeg-devel] [PATCH] configure - add dependencies for MPEG-PS and MPEG-ES demuxers

2018-01-31 Thread James Almer
On 1/31/2018 3:20 PM, Hendrik Leppkes wrote:
> On Wed, Jan 31, 2018 at 6:22 PM, Gyan Doshi  wrote:
>>
>> On 1/31/2018 10:18 PM, Carl Eugen Hoyos wrote:
>>>
>>>
>>> While this would help me personally, I don't think it is correct:
>>> Many such examples exist, I believe the dependencies are meant to
>>> ensure compilation, not necessarily specific use-cases.
>>
>>
>> Compilation in its own does succeed. And that's the problem. The most common
>> major payloads can't be accessed (or identified) without these other
>> components, making the PS demuxer, solo, close to useless.
>>
> 
> It is somewhat intentional that components do not depend on each other
> like this. Someone that has only specific requirements may not need
> those detections, so we generally do not force anything like that.
> Anyone who wants a very minimal build needs to configure components
> very carefully, specifically because of these interactions.
> 
> Note that _suggest serves a different purpose in configure then one
> might know from other systems, and would not be appropriate.
> 
> - Hendrik

Demuxers selecting parsers is done a lot, not for compilation reasons
but for stream handling reason. See dtshd demuxer and dca parser.

No comment about the demuxer selecting demuxer line. That's usually only
done when they both share pretty much the exact same code.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel


Re: [FFmpeg-devel] [PATCH 1/3] avcodec/exr: Fix memleaks in decode_header()

2018-01-31 Thread Moritz Barsnick
On Wed, Jan 31, 2018 at 19:20:08 +0100, Michael Niedermayer wrote:

> @@ -1458,8 +1465,10 @@ static int decode_header(EXRContext *s, AVFrame *frame)
>
>  s->channels = av_realloc(s->channels,
>   ++s->nb_channels * 
> sizeof(EXRChannel));
> -if (!s->channels)
> -return AVERROR(ENOMEM);
> +if (!s->channels) {
> +ret = AVERROR(ENOMEM);;
^^
Duplicate semicolon. This should have given you a new warning.

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


Re: [FFmpeg-devel] [PATCH] configure - add dependencies for MPEG-PS and MPEG-ES demuxers

2018-01-31 Thread Gyan Doshi

On 2/1/2018 1:34 AM, James Almer wrote:


No comment about the demuxer selecting demuxer line. That's usually only
done when they both share pretty much the exact same code.


In this case, if the mpegvideo demuxer isn't enabled, the PS demuxer 
sends the video stream to the MPEG audio decoder which then complains 
about 'Header missing'.



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


Re: [FFmpeg-devel] [PATCH 1/3] avcodec/exr: Fix memleaks in decode_header()

2018-01-31 Thread Moritz Barsnick
On Wed, Jan 31, 2018 at 21:04:54 +0100, Moritz Barsnick wrote:
> > +ret = AVERROR(ENOMEM);;
> ^^
> Duplicate semicolon. This should have given you a new warning.

Actually, no warning, yet still not desired.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel


[FFmpeg-devel] [PATCH v3 2/6] lavf/rtp: replace linked list with array

2018-01-31 Thread Josh de Kock
---
 libavformat/allformats.c |   4 --
 libavformat/rdt.c|   9 +---
 libavformat/rdt.h|   5 --
 libavformat/rtpdec.c | 138 ++-
 libavformat/rtpdec.h |  25 +++--
 5 files changed, 100 insertions(+), 81 deletions(-)

diff --git a/libavformat/allformats.c b/libavformat/allformats.c
index ec84096..83ed766 100644
--- a/libavformat/allformats.c
+++ b/libavformat/allformats.c
@@ -282,10 +282,6 @@ static void register_all(void)
 REGISTER_DEMUXER (SDR2, sdr2);
 REGISTER_DEMUXER (SDS,  sds);
 REGISTER_DEMUXER (SDX,  sdx);
-#if CONFIG_RTPDEC
-ff_register_rtp_dynamic_payload_handlers();
-ff_register_rdt_dynamic_payload_handlers();
-#endif
 REGISTER_DEMUXER (SEGAFILM, segafilm);
 REGISTER_MUXER   (SEGMENT,  segment);
 REGISTER_MUXER   (SEGMENT,  stream_segment);
diff --git a/libavformat/rdt.c b/libavformat/rdt.c
index b69827f..31a32ff 100644
--- a/libavformat/rdt.c
+++ b/libavformat/rdt.c
@@ -554,7 +554,7 @@ rdt_close_context (PayloadContext *rdt)
 }
 
 #define RDT_HANDLER(n, s, t) \
-static RTPDynamicProtocolHandler rdt_ ## n ## _handler = { \
+RTPDynamicProtocolHandler ff_rdt_ ## n ## _handler = { \
 .enc_name = s, \
 .codec_type   = t, \
 .codec_id = AV_CODEC_ID_NONE, \
@@ -570,10 +570,3 @@ RDT_HANDLER(live_audio, "x-pn-multirate-realaudio-live", 
AVMEDIA_TYPE_AUDIO);
 RDT_HANDLER(video,  "x-pn-realvideo",AVMEDIA_TYPE_VIDEO);
 RDT_HANDLER(audio,  "x-pn-realaudio",AVMEDIA_TYPE_AUDIO);
 
-void ff_register_rdt_dynamic_payload_handlers(void)
-{
-ff_register_dynamic_payload_handler(&rdt_video_handler);
-ff_register_dynamic_payload_handler(&rdt_audio_handler);
-ff_register_dynamic_payload_handler(&rdt_live_video_handler);
-ff_register_dynamic_payload_handler(&rdt_live_audio_handler);
-}
diff --git a/libavformat/rdt.h b/libavformat/rdt.h
index ce6026f..2480565 100644
--- a/libavformat/rdt.h
+++ b/libavformat/rdt.h
@@ -60,11 +60,6 @@ void ff_rdt_calc_response_and_checksum(char response[41], 
char chksum[9],
const char *challenge);
 
 /**
- * Register RDT-related dynamic payload handlers with our cache.
- */
-void ff_register_rdt_dynamic_payload_handlers(void);
-
-/**
  * Add subscription information to Subscribe parameter string.
  *
  * @param cmd string to write the subscription information into.
diff --git a/libavformat/rtpdec.c b/libavformat/rtpdec.c
index 4acb1ca..6499e27 100644
--- a/libavformat/rtpdec.c
+++ b/libavformat/rtpdec.c
@@ -69,88 +69,104 @@ static RTPDynamicProtocolHandler t140_dynamic_handler = { 
/* RFC 4103 */
 .codec_id   = AV_CODEC_ID_TEXT,
 };
 
-static RTPDynamicProtocolHandler *rtp_first_dynamic_payload_handler = NULL;
+extern RTPDynamicProtocolHandler ff_rdt_video_handler;
+extern RTPDynamicProtocolHandler ff_rdt_audio_handler;
+extern RTPDynamicProtocolHandler ff_rdt_live_video_handler;
+extern RTPDynamicProtocolHandler ff_rdt_live_audio_handler;
+
+static const RTPDynamicProtocolHandler *rtp_dynamic_protocol_handler_list[] = {
+/* rtp */
+&ff_ac3_dynamic_handler,
+&ff_amr_nb_dynamic_handler,
+&ff_amr_wb_dynamic_handler,
+&ff_dv_dynamic_handler,
+&ff_g726_16_dynamic_handler,
+&ff_g726_24_dynamic_handler,
+&ff_g726_32_dynamic_handler,
+&ff_g726_40_dynamic_handler,
+&ff_g726le_16_dynamic_handler,
+&ff_g726le_24_dynamic_handler,
+&ff_g726le_32_dynamic_handler,
+&ff_g726le_40_dynamic_handler,
+&ff_h261_dynamic_handler,
+&ff_h263_1998_dynamic_handler,
+&ff_h263_2000_dynamic_handler,
+&ff_h263_rfc2190_dynamic_handler,
+&ff_h264_dynamic_handler,
+&ff_hevc_dynamic_handler,
+&ff_ilbc_dynamic_handler,
+&ff_jpeg_dynamic_handler,
+&ff_mp4a_latm_dynamic_handler,
+&ff_mp4v_es_dynamic_handler,
+&ff_mpeg_audio_dynamic_handler,
+&ff_mpeg_audio_robust_dynamic_handler,
+&ff_mpeg_video_dynamic_handler,
+&ff_mpeg4_generic_dynamic_handler,
+&ff_mpegts_dynamic_handler,
+&ff_ms_rtp_asf_pfa_handler,
+&ff_ms_rtp_asf_pfv_handler,
+&ff_qcelp_dynamic_handler,
+&ff_qdm2_dynamic_handler,
+&ff_qt_rtp_aud_handler,
+&ff_qt_rtp_vid_handler,
+&ff_quicktime_rtp_aud_handler,
+&ff_quicktime_rtp_vid_handler,
+&ff_rfc4175_rtp_handler,
+&ff_svq3_dynamic_handler,
+&ff_theora_dynamic_handler,
+&ff_vc2hq_dynamic_handler,
+&ff_vorbis_dynamic_handler,
+&ff_vp8_dynamic_handler,
+&ff_vp9_dynamic_handler,
+&gsm_dynamic_handler,
+&l24_dynamic_handler,
+&opus_dynamic_handler,
+&realmedia_mp3_dynamic_handler,
+&speex_dynamic_handler,
+&t140_dynamic_handler,
+/* rdt */
+&ff_rdt_video_handler,
+&ff_rdt_audio_handler,
+&ff_rdt_live_video_handler,
+&ff_rdt_live_audio_handler,
+NULL,
+};
 
-void ff_register_dynamic_payload_handler(RTPDynamicProtoco

[FFmpeg-devel] [PATCH v3 4/6] lavf: move fifo test muxer into separate file

2018-01-31 Thread Josh de Kock
This fixes the fate-fifo-muxer test.
---
 libavformat/Makefile   |   2 +-
 libavformat/allformats.c   |   1 +
 libavformat/fifo_test.c| 150 +
 libavformat/tests/fifo_muxer.c | 115 +--
 4 files changed, 154 insertions(+), 114 deletions(-)
 create mode 100644 libavformat/fifo_test.c

diff --git a/libavformat/Makefile b/libavformat/Makefile
index de0de92..e0bb8ae 100644
--- a/libavformat/Makefile
+++ b/libavformat/Makefile
@@ -163,7 +163,7 @@ OBJS-$(CONFIG_EAC3_MUXER)+= rawenc.o
 OBJS-$(CONFIG_EPAF_DEMUXER)  += epafdec.o pcm.o
 OBJS-$(CONFIG_FFMETADATA_DEMUXER)+= ffmetadec.o
 OBJS-$(CONFIG_FFMETADATA_MUXER)  += ffmetaenc.o
-OBJS-$(CONFIG_FIFO_MUXER)+= fifo.o
+OBJS-$(CONFIG_FIFO_MUXER)+= fifo.o fifo_test.o
 OBJS-$(CONFIG_FILMSTRIP_DEMUXER) += filmstripdec.o
 OBJS-$(CONFIG_FILMSTRIP_MUXER)   += filmstripenc.o
 OBJS-$(CONFIG_FITS_DEMUXER)  += fitsdec.o
diff --git a/libavformat/allformats.c b/libavformat/allformats.c
index 0952019..f6a8a23 100644
--- a/libavformat/allformats.c
+++ b/libavformat/allformats.c
@@ -125,6 +125,7 @@ extern AVOutputFormat ff_f4v_muxer;
 extern AVInputFormat  ff_ffmetadata_demuxer;
 extern AVOutputFormat ff_ffmetadata_muxer;
 extern AVOutputFormat ff_fifo_muxer;
+extern AVOutputFormat ff_fifo_test_muxer;
 extern AVInputFormat  ff_filmstrip_demuxer;
 extern AVOutputFormat ff_filmstrip_muxer;
 extern AVInputFormat  ff_fits_demuxer;
diff --git a/libavformat/fifo_test.c b/libavformat/fifo_test.c
new file mode 100644
index 000..b86195b
--- /dev/null
+++ b/libavformat/fifo_test.c
@@ -0,0 +1,150 @@
+/*
+ * FIFO test pseudo-muxer
+ * Copyright (c) 2016 Jan Sebechlebsky
+ *
+ * This file is part of FFmpeg.
+ *
+ * FFmpeg is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public License
+ * as published by the Free Software Foundation; either
+ * version 2.1 of the License, or (at your option) any later version.
+ *
+ * FFmpeg is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU Lesser General Public License for more details.
+ *
+ * You should have received a copy of the GNU Lesser General Public License
+ * along with FFmpeg; if not, write to the Free Software * Foundation, Inc.,
+ * 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA
+ */
+
+#include 
+#include "libavutil/opt.h"
+#include "libavutil/time.h"
+#include "libavutil/avassert.h"
+#include "libavformat/avformat.h"
+#include "libavformat/url.h"
+#include "libavformat/network.h"
+
+/* Implementation of mock muxer to simulate real muxer failures */
+
+#define MAX_TST_PACKETS 128
+#define SLEEPTIME_50_MS 5
+#define SLEEPTIME_10_MS 1
+
+/* Implementation of mock muxer to simulate real muxer failures */
+
+/* This is structure of data sent in packets to
+ * failing muxer */
+typedef struct FailingMuxerPacketData {
+int ret; /* return value of write_packet call*/
+int recover_after;   /* set ret to zero after this number of recovery 
attempts */
+unsigned sleep_time; /* sleep for this long in write_packet to simulate 
long I/O operation */
+} FailingMuxerPacketData;
+
+
+typedef struct FailingMuxerContext {
+AVClass *class;
+int write_header_ret;
+int write_trailer_ret;
+/* If non-zero, summary of processed packets will be printed in deinit */
+int print_deinit_summary;
+
+int flush_count;
+int pts_written[MAX_TST_PACKETS];
+int pts_written_nr;
+} FailingMuxerContext;
+
+static int failing_write_header(AVFormatContext *avf)
+{
+FailingMuxerContext *ctx = avf->priv_data;
+return ctx->write_header_ret;
+}
+
+static int failing_write_packet(AVFormatContext *avf, AVPacket *pkt)
+{
+FailingMuxerContext *ctx = avf->priv_data;
+int ret = 0;
+if (!pkt) {
+ctx->flush_count++;
+} else {
+FailingMuxerPacketData *data = (FailingMuxerPacketData*) pkt->data;
+
+if (!data->recover_after) {
+data->ret = 0;
+} else {
+data->recover_after--;
+}
+
+ret = data->ret;
+
+if (data->sleep_time) {
+int64_t slept = 0;
+while (slept < data->sleep_time) {
+if (ff_check_interrupt(&avf->interrupt_callback))
+return AVERROR_EXIT;
+av_usleep(SLEEPTIME_10_MS);
+slept += SLEEPTIME_10_MS;
+}
+}
+
+if (!ret) {
+ctx->pts_written[ctx->pts_written_nr++] = pkt->pts;
+av_packet_unref(pkt);
+}
+}
+return ret;
+}
+
+static int failing_write_trailer(AVFormatContext *avf)
+{
+FailingMuxerContext *ctx = avf->priv_data;
+return ctx->write_trailer_ret;
+}
+
+static void 

[FFmpeg-devel] [PATCH v3 3/6] lavf: add new API for iterating muxers and demuxers

2018-01-31 Thread Josh de Kock
---
 configure|   6 +-
 doc/APIchanges   |   7 +-
 libavformat/.gitignore   |   2 +
 libavformat/allformats.c | 866 ---
 libavformat/avformat.h   |  31 ++
 libavformat/format.c |  68 +---
 libavformat/version.h|   3 +
 7 files changed, 564 insertions(+), 419 deletions(-)

diff --git a/configure b/configure
index d0bb8c7..dcc244a 100755
--- a/configure
+++ b/configure
@@ -3523,8 +3523,6 @@ find_things(){
 sed -n "s/^[^#]*$pattern.*([^,]*, *\([^,]*\)\(,.*\)*).*/\1_$thing/p" 
"$file"
 }
 
-MUXER_LIST=$(find_thingsmuxer_MUX libavformat/allformats.c)
-DEMUXER_LIST=$(find_things  demuxer  DEMUXlibavformat/allformats.c)
 OUTDEV_LIST=$(find_things   outdev   OUTDEV   libavdevice/alldevices.c)
 INDEV_LIST=$(find_thingsindev_IN  libavdevice/alldevices.c)
 FILTER_LIST=$(find_things   filter   FILTER   libavfilter/allfilters.c)
@@ -3536,6 +3534,8 @@ find_things_extern(){
 sed -n "s/^[^#]*extern.*$pattern *ff_\([^ ]*\)_$thing;/\1_$thing/p" "$file"
 }
 
+MUXER_LIST=$(find_things_extern muxer AVOutputFormat libavformat/allformats.c)
+DEMUXER_LIST=$(find_things_extern demuxer AVInputFormat 
libavformat/allformats.c)
 ENCODER_LIST=$(find_things_extern encoder AVCodec libavcodec/allcodecs.c)
 DECODER_LIST=$(find_things_extern decoder AVCodec libavcodec/allcodecs.c)
 CODEC_LIST="
@@ -7034,6 +7034,8 @@ print_enabled_components(){
 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
+print_enabled_components libavformat/demuxer_list.c AVInputFormat demuxer_list 
$DEMUXER_LIST
+print_enabled_components libavformat/muxer_list.c AVOutputFormat muxer_list 
$MUXER_LIST
 print_enabled_components libavformat/protocol_list.c URLProtocol url_protocols 
$PROTOCOL_LIST
 
 # Settings for pkg-config files
diff --git a/doc/APIchanges b/doc/APIchanges
index 77da22c..2a12f22 100644
--- a/doc/APIchanges
+++ b/doc/APIchanges
@@ -15,7 +15,12 @@ libavutil: 2017-10-21
 
 API changes, most recent first:
 
-2018-01-xx - xxx - lavc 58.9.100 - avcodec.h
+2018-xx-xx - xxx - lavf 58.9.100 - avformat.h
+  Deprecate use of av_register_input_format(), av_register_output_format(),
+  avformat_register_all(), av_iformat_next(), av_oformat_next().
+  Add av_demuxer_iterate(), and av_muxer_iterate().
+
+2018-xx-xx - xxx - lavc 58.9.100 - avcodec.h
   Deprecate use of avcodec_register(), avcodec_register_all(), and
   av_codec_next(). Add av_codec_iterate().
 
diff --git a/libavformat/.gitignore b/libavformat/.gitignore
index cdc24b7..fb70c12 100644
--- a/libavformat/.gitignore
+++ b/libavformat/.gitignore
@@ -1 +1,3 @@
 /protocol_list.c
+/muxer_list.c
+/demuxer_list.c
diff --git a/libavformat/allformats.c b/libavformat/allformats.c
index 83ed766..0952019 100644
--- a/libavformat/allformats.c
+++ b/libavformat/allformats.c
@@ -26,370 +26,528 @@
 #include "url.h"
 #include "version.h"
 
-#define REGISTER_MUXER(X, x)\
-{   \
-extern AVOutputFormat ff_##x##_muxer;   \
-if (CONFIG_##X##_MUXER) \
-av_register_output_format(&ff_##x##_muxer); \
-}
+/* (de)muxers */
+extern AVOutputFormat ff_a64_muxer;
+extern AVInputFormat  ff_aa_demuxer;
+extern AVInputFormat  ff_aac_demuxer;
+extern AVInputFormat  ff_ac3_demuxer;
+extern AVOutputFormat ff_ac3_muxer;
+extern AVInputFormat  ff_acm_demuxer;
+extern AVInputFormat  ff_act_demuxer;
+extern AVInputFormat  ff_adf_demuxer;
+extern AVInputFormat  ff_adp_demuxer;
+extern AVInputFormat  ff_ads_demuxer;
+extern AVOutputFormat ff_adts_muxer;
+extern AVInputFormat  ff_adx_demuxer;
+extern AVOutputFormat ff_adx_muxer;
+extern AVInputFormat  ff_aea_demuxer;
+extern AVInputFormat  ff_afc_demuxer;
+extern AVInputFormat  ff_aiff_demuxer;
+extern AVOutputFormat ff_aiff_muxer;
+extern AVInputFormat  ff_aix_demuxer;
+extern AVInputFormat  ff_amr_demuxer;
+extern AVOutputFormat ff_amr_muxer;
+extern AVInputFormat  ff_amrnb_demuxer;
+extern AVInputFormat  ff_amrwb_demuxer;
+extern AVInputFormat  ff_anm_demuxer;
+extern AVInputFormat  ff_apc_demuxer;
+extern AVInputFormat  ff_ape_demuxer;
+extern AVInputFormat  ff_apng_demuxer;
+extern AVOutputFormat ff_apng_muxer;
+extern AVInputFormat  ff_aptx_demuxer;
+extern AVOutputFormat ff_aptx_muxer;
+extern AVInputFormat  ff_aqtitle_demuxer;
+extern AVInputFormat  ff_asf_demuxer;
+extern AVOutputFormat ff_asf_muxer;
+extern AVInputFormat  ff_asf_o_demuxer;
+extern AVInputFormat  ff_ass_demuxer;
+extern AVOutputFormat ff_ass_muxer;
+extern AVInputFormat  ff_ast_demuxer;
+extern AVOutputFormat ff_ast_muxer;
+extern AVOutputFormat ff_asf_stream_mu

[FFmpeg-devel] [PATCH v3 5/6] lavd: add new API for iterating input and output devices

2018-01-31 Thread Josh de Kock
This also adds an avpriv function to register devices in
libavformat
---
 configure|  27 +--
 libavdevice/alldevices.c | 181 ---
 libavdevice/avdevice.c   |  46 
 libavdevice/avdevice.h   |  28 
 libavdevice/version.h|   4 ++
 libavformat/allformats.c |  45 +++-
 libavformat/format.c |   8 +++
 libavformat/internal.h   |   7 ++
 8 files changed, 251 insertions(+), 95 deletions(-)

diff --git a/configure b/configure
index dcc244a..8f75657 100755
--- a/configure
+++ b/configure
@@ -568,6 +568,12 @@ add_suffix(){
 for v; do echo ${v}${suffix}; done
 }
 
+remove_suffix(){
+suffix=$1
+shift
+for v; do echo ${v%$suffix}; done
+}
+
 set_all(){
 value=$1
 shift
@@ -3523,17 +3529,18 @@ find_things(){
 sed -n "s/^[^#]*$pattern.*([^,]*, *\([^,]*\)\(,.*\)*).*/\1_$thing/p" 
"$file"
 }
 
-OUTDEV_LIST=$(find_things   outdev   OUTDEV   libavdevice/alldevices.c)
-INDEV_LIST=$(find_thingsindev_IN  libavdevice/alldevices.c)
 FILTER_LIST=$(find_things   filter   FILTER   libavfilter/allfilters.c)
 
 find_things_extern(){
 thing=$1
 pattern=$2
 file=$source_path/$3
-sed -n "s/^[^#]*extern.*$pattern *ff_\([^ ]*\)_$thing;/\1_$thing/p" "$file"
+out=${4:-$thing}
+sed -n "s/^[^#]*extern.*$pattern *ff_\([^ ]*\)_$thing;/\1_$out/p" "$file"
 }
 
+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)
 DEMUXER_LIST=$(find_things_extern demuxer AVInputFormat 
libavformat/allformats.c)
 ENCODER_LIST=$(find_things_extern encoder AVCodec libavcodec/allcodecs.c)
@@ -7025,7 +7032,17 @@ print_enabled_components(){
 shift 3
 echo "static const $struct_name * const $name[] = {" > $TMPH
 for c in $*; do
-enabled $c && printf "&ff_%s,\n" $c >> $TMPH
+if enabled $c; then
+case $name in
+indev_list)
+c=$(add_suffix _demuxer $(remove_suffix _indev $c))
+;;
+outdev_list)
+c=$(add_suffix _muxer $(remove_suffix _outdev $c))
+;;
+esac
+printf "&ff_%s,\n" $c >> $TMPH
+fi
 done
 echo "NULL };" >> $TMPH
 cp_if_changed $TMPH $file
@@ -7034,6 +7051,8 @@ print_enabled_components(){
 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
+print_enabled_components libavdevice/indev_list.c AVInputFormat indev_list 
$INDEV_LIST
+print_enabled_components libavdevice/outdev_list.c AVOutputFormat outdev_list 
$OUTDEV_LIST
 print_enabled_components libavformat/demuxer_list.c AVInputFormat demuxer_list 
$DEMUXER_LIST
 print_enabled_components libavformat/muxer_list.c AVOutputFormat muxer_list 
$MUXER_LIST
 print_enabled_components libavformat/protocol_list.c URLProtocol url_protocols 
$PROTOCOL_LIST
diff --git a/libavdevice/alldevices.c b/libavdevice/alldevices.c
index b767b6a..b34fd5d 100644
--- a/libavdevice/alldevices.c
+++ b/libavdevice/alldevices.c
@@ -22,57 +22,152 @@
 #include "libavutil/thread.h"
 #include "avdevice.h"
 
-#define REGISTER_OUTDEV(X, x)   \
-{   \
-extern AVOutputFormat ff_##x##_muxer;   \
-if (CONFIG_##X##_OUTDEV)\
-av_register_output_format(&ff_##x##_muxer); \
+#if FF_API_NEXT
+#include "libavformat/internal.h"
+#endif
+
+/* devices */
+extern AVInputFormat  ff_alsa_demuxer;
+extern AVOutputFormat ff_alsa_muxer;
+extern AVInputFormat  ff_avfoundation_demuxer;
+extern AVInputFormat  ff_bktr_demuxer;
+extern AVOutputFormat ff_caca_muxer;
+extern AVInputFormat  ff_decklink_demuxer;
+extern AVOutputFormat ff_decklink_muxer;
+extern AVInputFormat  ff_libndi_newtek_demuxer;
+extern AVOutputFormat ff_libndi_newtek_muxer;
+extern AVInputFormat  ff_dshow_demuxer;
+extern AVInputFormat  ff_fbdev_demuxer;
+extern AVOutputFormat ff_fbdev_muxer;
+extern AVInputFormat  ff_gdigrab_demuxer;
+extern AVInputFormat  ff_iec61883_demuxer;
+extern AVInputFormat  ff_jack_demuxer;
+extern AVInputFormat  ff_kmsgrab_demuxer;
+extern AVInputFormat  ff_lavfi_demuxer;
+extern AVInputFormat  ff_openal_demuxer;
+extern AVOutputFormat ff_opengl_muxer;
+extern AVInputFormat  ff_oss_demuxer;
+extern AVOutputFormat ff_oss_muxer;
+extern AVInputFormat  ff_pulse_demuxer;
+extern AVOutputFormat ff_pulse_muxer;
+extern AVOutputFormat ff_sdl2_muxer;
+extern AVInputFormat  ff_sndio_demuxer;
+extern AVOutputForma

[FFmpeg-devel] [PATCH v3 1/6] lavc: add new API for iterating codecs and codec parsers

2018-01-31 Thread Josh de Kock
Also replace linked list with an array.
---
 configure  |   12 +-
 doc/APIchanges |4 +
 libavcodec/.gitignore  |2 +
 libavcodec/allcodecs.c | 1473 
 libavcodec/avcodec.h   |   31 +
 libavcodec/parser.c|   84 ++-
 libavcodec/utils.c |  112 
 libavcodec/version.h   |3 +
 8 files changed, 971 insertions(+), 750 deletions(-)

diff --git a/configure b/configure
index fcfa7aa..d0bb8c7 100755
--- a/configure
+++ b/configure
@@ -3523,9 +3523,6 @@ find_things(){
 sed -n "s/^[^#]*$pattern.*([^,]*, *\([^,]*\)\(,.*\)*).*/\1_$thing/p" 
"$file"
 }
 
-ENCODER_LIST=$(find_things  encoder  ENC  libavcodec/allcodecs.c)
-DECODER_LIST=$(find_things  decoder  DEC  libavcodec/allcodecs.c)
-PARSER_LIST=$(find_things   parser   PARSER   libavcodec/allcodecs.c)
 MUXER_LIST=$(find_thingsmuxer_MUX libavformat/allformats.c)
 DEMUXER_LIST=$(find_things  demuxer  DEMUXlibavformat/allformats.c)
 OUTDEV_LIST=$(find_things   outdev   OUTDEV   libavdevice/alldevices.c)
@@ -3539,6 +3536,13 @@ find_things_extern(){
 sed -n "s/^[^#]*extern.*$pattern *ff_\([^ ]*\)_$thing;/\1_$thing/p" "$file"
 }
 
+ENCODER_LIST=$(find_things_extern encoder AVCodec libavcodec/allcodecs.c)
+DECODER_LIST=$(find_things_extern decoder AVCodec libavcodec/allcodecs.c)
+CODEC_LIST="
+$ENCODER_LIST
+$DECODER_LIST
+"
+PARSER_LIST=$(find_things_extern parser AVCodecParser libavcodec/parser.c)
 BSF_LIST=$(find_things_extern bsf AVBitStreamFilter 
libavcodec/bitstream_filters.c)
 HWACCEL_LIST=$(find_things_extern hwaccel AVHWAccel libavcodec/hwaccels.h)
 PROTOCOL_LIST=$(find_things_extern protocol URLProtocol 
libavformat/protocols.c)
@@ -7027,6 +7031,8 @@ print_enabled_components(){
 cp_if_changed $TMPH $file
 }
 
+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
 print_enabled_components libavformat/protocol_list.c URLProtocol url_protocols 
$PROTOCOL_LIST
 
diff --git a/doc/APIchanges b/doc/APIchanges
index 6185545..77da22c 100644
--- a/doc/APIchanges
+++ b/doc/APIchanges
@@ -15,6 +15,10 @@ libavutil: 2017-10-21
 
 API changes, most recent first:
 
+2018-01-xx - xxx - lavc 58.9.100 - avcodec.h
+  Deprecate use of avcodec_register(), avcodec_register_all(), and
+  av_codec_next(). Add av_codec_iterate().
+
 2018-01-xx - xxx - lavf 58.7.100 - avformat.h
   Deprecate AVFormatContext filename field which had limited length, use the
   new dynamically allocated url field instead.
diff --git a/libavcodec/.gitignore b/libavcodec/.gitignore
index 77a2ab1..28814f7 100644
--- a/libavcodec/.gitignore
+++ b/libavcodec/.gitignore
@@ -2,3 +2,5 @@
 /*_tables.c
 /*_tables.h
 /bsf_list.c
+/codec_list.c
+/parser_list.c
diff --git a/libavcodec/allcodecs.c b/libavcodec/allcodecs.c
index ed1e7ab..e8f0eca 100644
--- a/libavcodec/allcodecs.c
+++ b/libavcodec/allcodecs.c
@@ -29,641 +29,864 @@
 #include "avcodec.h"
 #include "version.h"
 
-#define REGISTER_ENCODER(X, x)  \
-{   \
-extern AVCodec ff_##x##_encoder;\
-if (CONFIG_##X##_ENCODER)   \
-avcodec_register(&ff_##x##_encoder);\
-}
+extern AVCodec ff_a64multi_encoder;
+extern AVCodec ff_a64multi5_encoder;
+extern AVCodec ff_aasc_decoder;
+extern AVCodec ff_aic_decoder;
+extern AVCodec ff_alias_pix_encoder;
+extern AVCodec ff_alias_pix_decoder;
+extern AVCodec ff_amv_encoder;
+extern AVCodec ff_amv_decoder;
+extern AVCodec ff_anm_decoder;
+extern AVCodec ff_ansi_decoder;
+extern AVCodec ff_apng_encoder;
+extern AVCodec ff_apng_decoder;
+extern AVCodec ff_asv1_encoder;
+extern AVCodec ff_asv1_decoder;
+extern AVCodec ff_asv2_encoder;
+extern AVCodec ff_asv2_decoder;
+extern AVCodec ff_aura_decoder;
+extern AVCodec ff_aura2_decoder;
+extern AVCodec ff_avrp_encoder;
+extern AVCodec ff_avrp_decoder;
+extern AVCodec ff_avrn_decoder;
+extern AVCodec ff_avs_decoder;
+extern AVCodec ff_avui_encoder;
+extern AVCodec ff_avui_decoder;
+extern AVCodec ff_ayuv_encoder;
+extern AVCodec ff_ayuv_decoder;
+extern AVCodec ff_bethsoftvid_decoder;
+extern AVCodec ff_bfi_decoder;
+extern AVCodec ff_bink_decoder;
+extern AVCodec ff_bmp_encoder;
+extern AVCodec ff_bmp_decoder;
+extern AVCodec ff_bmv_video_decoder;
+extern AVCodec ff_brender_pix_decoder;
+extern AVCodec ff_c93_decoder;
+extern AVCodec ff_cavs_decoder;
+extern AVCodec ff_cdgraphics_decoder;
+extern AVCodec ff_cdxl_decoder;
+extern AVCodec ff_cfhd_decoder;
+extern AVCodec ff_cinepak_encoder;
+extern AVCodec ff_cinepak_decoder;
+extern AVCodec ff_clearvideo_decoder;
+extern AVCodec ff_cljr_encoder;
+extern AVCodec f

[FFmpeg-devel] [PATCH v3 6/6] cmdutils: make use of new iteration APIs

2018-01-31 Thread Josh de Kock
---
 fftools/cmdutils.c | 122 +++--
 1 file changed, 43 insertions(+), 79 deletions(-)

diff --git a/fftools/cmdutils.c b/fftools/cmdutils.c
index 6920ca0..9ecc51b 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"
@@ -1275,34 +1267,24 @@ static int show_formats_devices(void *optctx, const 
char *opt, const char *arg,
 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;\
+encode= 1;  \
+}   \
+}   \
+} } while(0)
+
+x(av_muxer_iterate, ofmt, muxdemuxers != SHOW_DEMUXERS && 
!device_only);
+x(av_outdev_iterate, ofmt, muxdemuxers != SHOW_DEMUXERS);
+x(av_demuxer_iterate, ifmt, muxdemuxers != SHOW_MUXERS && 
!device_only);
+x(av_indev_iterate, ifmt, muxdemuxers != SHOW_MUXERS);
+#undef x
 if (!name)
 break;
 last_name = name;
@@ -1442,7 +1424,8 @@ static char get_media_type_char(enum AVMediaType type)
 static const AVCodec *next_codec_for_id(enum AVCodecID id, const AVCodec *prev,
 int encoder)
 {
-while ((prev = av_codec_next(prev))) {
+void *i = 0;
+while ((prev = av_codec_iterate(&i))) {
 if (prev->id == id &&
 (encoder ? av_codec_is_encoder(prev) : av_codec_is_decoder(prev)))
 return prev;
@@ -2116,7 +2099,7 @@ double get_rotation(AVStream *st)
 }
 
 #if CONFIG_AVDEVICE
-static int print_device_sources(AVInputFormat *fmt, AVDictionary *opts)
+static int print_device_sources(const AVInputFormat *fmt, AVDictionary *opts)
 {
 int ret, i;
 AVDeviceInfoList *device_list = NULL;
@@ -2131,7 +2114,7 @@ static int print_device_sources(AVInputFormat *fmt, 
AVDictionary *opts)
 goto fail;
 }
 
-if ((ret = avdevice_list_input_sources(fmt, NULL, opts, &device_list)) < 
0) {
+if ((ret = avdevice_list_input_sources((AVInputFormat*)fmt, NULL, opts, 
&device_list)) < 0) {
 printf("Cannot list sources.\n");
 goto fail;
 }
@@ -2146,7 +2129,7 @@ static int print_device_sources(AVInputFormat *fmt, 
AVDictionary *opts)
 return ret;
 }
 
-static int print_device_sinks(AVOutputFormat *fmt, AVDictionary *opts)
+static int print_device_sinks(const AVOutputFormat *fmt, AVDictionary *opts)
 {
 int ret, i;
 AVDeviceInfoList *device_list = NULL;
@@ -2161,7 +2144,7 @@ static int print_device_sinks(AVOutputFormat *fmt, 
AVDictionary *opts)
 goto fail;
 }
 
-if

[FFmpeg-devel] [PATCH] librsvgdec: Fix frame clearing code

2018-01-31 Thread Calvin Walton
The existing code attempts to clear the frame by painting in OVER mode
with transparent black - which is, of course, a no-op. As a result if
you have many input frames (e.g. you're using a sequence of svg files),
you'll start to see new frames drawn over old frames as memory gets
re-used.

Fix that by clearing the frame using the SOURCE blend mode, which
will replace whatever is in the buffer with transparent black.

Referencing the cairo FAQ,
https://www.cairographics.org/FAQ/#clear_a_surface
---
 libavcodec/librsvgdec.c | 7 +--
 1 file changed, 5 insertions(+), 2 deletions(-)

It would probably be nice to get this into 3.4 branch as well?

diff --git a/libavcodec/librsvgdec.c b/libavcodec/librsvgdec.c
index e57070f8e4..e16cb6247d 100644
--- a/libavcodec/librsvgdec.c
+++ b/libavcodec/librsvgdec.c
@@ -82,8 +82,11 @@ static int librsvg_decode_frame(AVCodecContext *avctx, void 
*data, int *got_fram
 
 crender = cairo_create(image);
 
-cairo_set_source_rgba(crender, 0.0, 0.0, 0.0, 1.0f);
-cairo_paint_with_alpha(crender, 0.0f);
+cairo_save(crender);
+cairo_set_source_rgba(crender, 0.0, 0.0, 0.0, 0.0f);
+cairo_set_operator(crender, CAIRO_OPERATOR_SOURCE);
+cairo_paint(crender);
+cairo_restore(crender);
 
 cairo_scale(crender, dimensions.width / (double)unscaled_dimensions.width,
 dimensions.height / (double)unscaled_dimensions.height);
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel


[FFmpeg-devel] Remove carriage return ('\r') in Windows CC_IDENT

2018-01-31 Thread 王消寒

From 07e33b2aa09b8b224ac35a5b56b29490a6486bdf Mon Sep 17 00:00:00 2001
From: Xiaohan Wang 
Date: Wed, 31 Jan 2018 14:20:02 -0800
Subject: [PATCH] Remove carriage return ('\r') in Windows CC_IDENT

Currently the Windows CC_IDENT is ended with '\r\n'. "head -n1" will not
remove the '\r' and this is causing building error in Chromium.

This CL adds "tr -d '\r'" to remove '\r' in the CC_IDENT string. Since in
most cases '\r' only appears at the end of a string/line, this should
work in most cases.

See example:

printf "hello\r\nworld\r\n" | head -n1 | hd
  68 65 6c 6c 6f 0d 0a  |hello..|

printf "hello\r\nworld\r\n" | head -n1 | tr -d '\r' | hd
  68 65 6c 6c 6f 0a |hello.|

Also note a similar previous change at:
https://lists.ffmpeg.org/pipermail/ffmpeg-cvslog/2013-October/069950.html
---
 configure | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/configure b/configure
index a83581ea98..4a68c6364d 100755
--- a/configure
+++ b/configure
@@ -4289,7 +4289,7 @@ probe_cc(){
 _ld_path='-libpath:'
 elif $_cc -nologo- 2>&1 | grep -q Microsoft; then
 _type=msvc
-_ident=$($_cc 2>&1 | head -n1)
+_ident=$($_cc 2>&1 | head -n1 | tr -d '\r')
 _DEPCMD='$(DEP$(1)) $(DEP$(1)FLAGS) $($(1)DEP_FLAGS) $< 2>&1 | awk '\''/including/ { sub(/^.*file: */, ""); gsub(/\\/, "/"); if (!match($$0, / /)) print "$@:", $$0 }'\'' > $(@:.o=.d)'
 _DEPFLAGS='$(CPPFLAGS) $(CFLAGS) -showIncludes -Zs'
 _cflags_speed="-O2"
-- 
2.16.0.rc1.238.g530d649a79-goog

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


Re: [FFmpeg-devel] [mp3] Skip APE tags when parsing mp3 packets.

2018-01-31 Thread Carl Eugen Hoyos
2018-01-30 15:30 GMT+01:00 James Almer :

> I recently changed the raw aac demuxer to stop propagating "junk" at the
> beginning and end of the stream (things like id3 and ape tags) by
> discarding anything that's not a complete frame, but the result was that
> it kinda broke some fully playable files that had one or two damaged
> frames.

Tickets #6634 and #6900.

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


[FFmpeg-devel] [PATCH] delogo will fail if interp is zero.

2018-01-31 Thread wuxiaoyong
With ROUNDED_DIV operation, if the first parameter is 0, it will
overflow and return a very large number, delogo will fail.
So, if it's zero, just set it to 1, it will not affect the result so
much.

Signed-off-by: wuxiaoyong 
---
 libavfilter/vf_delogo.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/libavfilter/vf_delogo.c b/libavfilter/vf_delogo.c
index 065d093..73ad6b9 100644
--- a/libavfilter/vf_delogo.c
+++ b/libavfilter/vf_delogo.c
@@ -126,7 +126,7 @@ static void apply_delogo(uint8_t *dst, int dst_linesize,
  botleft[x-logo_x1-1]  +
  botleft[x-logo_x1+1]) * weightb;
 weight = (weightl + weightr + weightt + weightb) * 3U;
-interp = ROUNDED_DIV(interp, weight);
+interp = ROUNDED_DIV(interp <= 0 ? 1 : interp, weight);
 
 if (y >= logo_y+band && y < logo_y+logo_h-band &&
 x >= logo_x+band && x < logo_x+logo_w-band) {
-- 
2.7.4

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


Re: [FFmpeg-devel] [PATCH] libavfilter: constify filter list

2018-01-31 Thread Michael Niedermayer
On Wed, Jan 31, 2018 at 12:24:43PM +0100, wm4 wrote:
> On Wed, 31 Jan 2018 12:11:25 +0100
> Michael Niedermayer  wrote:
> 
> > On Wed, Jan 31, 2018 at 10:03:58AM +0100, wm4 wrote:
> > > On Wed, 31 Jan 2018 09:08:23 +0100
> > > Tobias Rapp  wrote:
> > >   
> > > > On 30.01.2018 20:37, Michael Niedermayer wrote:  
> > > > > On Tue, Jan 30, 2018 at 08:27:27PM +0700, Muhammad Faiz wrote:
> > > > >> On Tue, Jan 30, 2018 at 7:50 PM, Michael Niedermayer
> > > > >>  wrote:
> > > > >>> Its also a step away from supporting plugins.
> > > > >>> Why plugins matter ? Because having plugin
> > > > >>> support is a big advantage, it allows a much wider
> > > > >>> community to work on, write and maintain filters.
> > > > >>>
> > > > >>> With plugins, people can write filters that are
> > > > >>> written in languages other than C. Or filters which
> > > > >>> some developer in FFmpeg doesnt want. Or they can be
> > > > >>> maintained externally by people who just do not like us.
> > > > >>> Or by people who perfer a FOSS license different from
> > > > >>> LGPL/GPL/BSD. Iam sure others can come up with more
> > > > >>> reasons ...
> > > > >>>
> > > > >>> Of course avfilter_register() isnt enough for plugins
> > > > >>> but it or something equivalent is needed for plugins.
> > > > >>>
> > > > >>> So i would prefer if avfilter_register() stays supported
> > > > >>> indefinitly or in case a different system is written for
> > > > >>> plugins then until that system is in place.
> > > > >>
> > > > >> It just returns error and logs error message that currently external
> > > > >> filter is unsupported. If someone wants to implement support for
> > > > >> external filter, it can be easily added later using separate
> > > > >> list/table.
> > > > > 
> > > > > Iam not sure "easily" is true
> > > > > 
> > > > > We started out with a fully public API that allowed external filters.
> > > > > and little by little its removed or made private.
> > > > > each individual change may be easy to undo but as a whole moving
> > > > > libavfilter back to having a public API is not that easy anymore
> > > > > 
> > > > > IIRC the arguments to make things private where that people wanted to
> > > > > improve the API. But from the idea and impression of a plan like:
> > > > > 1. make it private
> > > > > 2. design and implement better API
> > > > > 3. make it public again
> > > > > 
> > > > > Somehow now people lost sight and interrest in 3. and even 2. is 
> > > > > becoming
> > > > > less interresting. But the problem is really without 2 + 3 actually 
> > > > > happening
> > > > > doing 1 seems like not a good idea at all.
> > > > > 
> > > > > To me it seems even mentioning external filters and public API makes 
> > > > > some
> > > > > people angry.
> > > > > But really that has to be the goal at some point. To again have a 
> > > > > public API
> > > > 
> > > > I agree that having (again) a public filter API would be good. This 
> > > > would give users the freedom to implement their own special-purpose 
> > > > filters (see the "dumpwave" discussion).  
> > > 
> > > Someone needs to design and write it.
> > > 
> > > Whether we have external filters is completely orthogonal to this
> > > change.   
> > 
> > > They were not possible before, because not enough API for
> > > implementing them is public.   
> > 
> > This is correct if by "before" you mean today before this is applied.
> > But longer ago, as in years, it was possible
> > 
> > 
> > > They can be possible in the future, but
> > > then registering them would need a different API anyway (one that
> > > doesn't use global mutable state, but uses some sort of context
> > > instead).  
> > 
> > i understand that you arent a native english speaker nor am i but
> > what you write here is not true.
> > 
> > Several people desire to eliminate all "global mutable state"
> > and thats fine, iam happy if that is achieved. But its not
> > that its neccessary for a fully functional API register or otherwise.
> > The registering code with "global mutable state" and some form
> > of thread synchronization would work perfectly fine.
> > 
> > What exactly is in relation to registering the problem with 
> > "global mutable state" ?
> > 
> > One application registering a filter with a common name and another 
> > application unintentionally using that ?
> 
> Yes. It's not library-safe.
> 
> > This is not even possible because each application is in its own process and
> > will have its own independant copy of libavfilter in its address space only
> > with "read only" pages shared or with pages with "copy on write".
> 
> This is a library. There can be multiple users of a library in the same
> process.
> 
> > The "one registers the other uses it by mistake" issue is as far as i
> > understand only possible if an application uses libavfilter and that
> > application uses also a lib that itself uses libavfilter too or
> > similar cases. 
> > And then both mess with registering custom filt

Re: [FFmpeg-devel] [PATCH] avformat/bintext: Implement bin_probe()

2018-01-31 Thread Michael Niedermayer
On Wed, Jan 31, 2018 at 05:43:24PM +0100, Carl Eugen Hoyos wrote:
> 2018-01-31 15:22 GMT+01:00 Michael Niedermayer :
> > Fixes misdetection of sbQ9.bin
> >
> > Signed-off-by: Michael Niedermayer 
> > ---
> >  libavformat/bintext.c | 49 
> > -
> >  1 file changed, 48 insertions(+), 1 deletion(-)
> >
> > diff --git a/libavformat/bintext.c b/libavformat/bintext.c
> > index 12e3bfde4d..722a40c3e5 100644
> > --- a/libavformat/bintext.c
> > +++ b/libavformat/bintext.c
> > @@ -126,6 +126,53 @@ static void predict_width(AVCodecParameters *par, 
> > uint64_t fsize, int got_width)
> >  par->width = fsize > 4000 ? (160<<3) : (80<<3);
> >  }
> >
> > +static int bin_probe(AVProbeData *p)
> > +{
> > +const uint8_t *d = p->buf;
> > +int magic = 0, sauce = 0;
> > +int invisible = 0;
> > +int i;
> > +
> > +if (p->buf_size > 256)
> > +magic = !memcmp(d + p->buf_size - 256, next_magic, 
> > sizeof(next_magic));
> > +if (p->buf_size > 128)
> > +sauce = !memcmp(d + p->buf_size - 128, "SAUCE00", 7);
> > +
> > +if (magic)
> > +return AVPROBE_SCORE_MAX / 2;
> 
> This seems too low to me or am I wrong?
> 
> > +
> > +if (av_match_ext(p->filename, "bin")) {
> > +AVCodecParameters par;
> > +int got_width = 0;
> > +par.width = par.height = 0;
> 
> > +if (sauce)
> > +return AVPROBE_SCORE_MAX / 2;
> 
> Same here.

was thinking the same but that was what the filename based detection
used before.
I kind of just left it where it was, the main goal of the patch was
just to fix the misdetection not to raise the score.
But we can surely raise these.
WHat would you think is a good value ?


> 
> > +
> > +predict_width(&par, p->buf_size, got_width);
> > +if (par.width <= 0)
> > +return 0;
> > +calculate_height(&par, p->buf_size);
> > +if (par.height <= 0)
> > +return 0;
> > +
> > +for (i = 0; i < p->buf_size - 256;  i+=2) {
> > +if ((d[i+1] & 15) == (d[i+1] >> 4) && d[i] && d[i] != 0xFF && 
> > d[i] != ' ') {
> 
> > +invisible ++;
> 
> This looks unused.

yes, iam aware, ive added it thinking it would be needed but all my test files
where detected correctly so it wasnt needed
i can remove it if people prefer ?
or it can be left so next time something gets probed wrong the code is
already there to check the next level of information.


> 
> > +}
> > +}
> > +
> > +if (par.width * par.height * 2 / (8*16) == p->buf_size)
> > +return AVPROBE_SCORE_MAX / 2;
> 
> Shouldn't this also be a higher score?

This one here, no. This is a rather weak test. It looks stronger than it
is
Its weak as width and height are computed currently from the size


> 
> Thank you for looking into this issue, Carl Eugen
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Why not whip the teacher when the pupil misbehaves? -- Diogenes of Sinope


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


Re: [FFmpeg-devel] [PATCH] libavfilter: constify filter list

2018-01-31 Thread Michael Niedermayer
On Thu, Feb 01, 2018 at 02:06:52AM +0100, Michael Niedermayer wrote:
[...]
> > I've also
> > mentioned multiple times how the main problem is creating public API
> > so filters can be implemented. This is not a trivial task, but adding
> > some sort of filter register API is absolutely trivial (even if it
> > readds the current API, which I hope it won't). So why bring it up
> > again and cause tons of fruitless discussions? Just why? Please explain
> > this.
> 
> Yes, iam concerned and upset about the lack of activity on what you
> call the "main problem".

> If there was someone working on creating a new public API, then i would
> never complain about him removing existing API.

re-reading what i wrote, i realize this can be very badly mis interpreted
Its of course meant just in the context of a removial not breaking any users
and following API deprecation and all when that is needed.

[...]

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

The greatest way to live with honor in this world is to be what we pretend
to be. -- Socrates


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


Re: [FFmpeg-devel] [PATCH 3/3] avcodec/huffyuvdec: Check input buffer size

2018-01-31 Thread Michael Niedermayer
On Wed, Jan 31, 2018 at 07:56:06PM +0100, Paul B Mahol wrote:
> On 1/31/18, Michael Niedermayer  wrote:
> > Fixes: Timeout
> > Fixes: 5487/clusterfuzz-testcase-4696837035393024
> >
> > Found-by: continuous fuzzing process
> > https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
> > Signed-off-by: Michael Niedermayer 
> > ---
> >  libavcodec/huffyuvdec.c | 3 +++
> >  1 file changed, 3 insertions(+)
> >
> > diff --git a/libavcodec/huffyuvdec.c b/libavcodec/huffyuvdec.c
> > index 979c4b9d5c..66357bfb40 100644
> > --- a/libavcodec/huffyuvdec.c
> > +++ b/libavcodec/huffyuvdec.c
> > @@ -919,6 +919,9 @@ static int decode_frame(AVCodecContext *avctx, void
> > *data, int *got_frame,
> >  AVFrame *const p = data;
> >  int table_size = 0, ret;
> >
> > +if (buf_size < (width * height + 7)/8)
> > +return AVERROR_INVALIDDATA;
> > +
> 
> Are you sure this is enough?

I dont know if thats the only way the decoder can be made to waste
large amounts of CPU with little input data

I do belive it stops this specific class of issues though


> 
> Something similar you had already posted long ago.

for other decoders, yes. Did i forget a patch for huffyuv ?

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

Old school: Use the lowest level language in which you can solve the problem
conveniently.
New school: Use the highest level language in which the latest supercomputer
can solve the problem without the user falling asleep waiting.


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


Re: [FFmpeg-devel] [PATCH] libavfilter: constify filter list

2018-01-31 Thread wm4
On Thu, 1 Feb 2018 02:06:52 +0100
Michael Niedermayer  wrote:

> On Wed, Jan 31, 2018 at 12:24:43PM +0100, wm4 wrote:
> > On Wed, 31 Jan 2018 12:11:25 +0100
> > Michael Niedermayer  wrote:
> >   
> > > On Wed, Jan 31, 2018 at 10:03:58AM +0100, wm4 wrote:  
> > > > On Wed, 31 Jan 2018 09:08:23 +0100
> > > > Tobias Rapp  wrote:
> > > > 
> > > > > On 30.01.2018 20:37, Michael Niedermayer wrote:
> > > > > > On Tue, Jan 30, 2018 at 08:27:27PM +0700, Muhammad Faiz wrote:  
> > > > > >> On Tue, Jan 30, 2018 at 7:50 PM, Michael Niedermayer
> > > > > >>  wrote:  
> > > > > >>> Its also a step away from supporting plugins.
> > > > > >>> Why plugins matter ? Because having plugin
> > > > > >>> support is a big advantage, it allows a much wider
> > > > > >>> community to work on, write and maintain filters.
> > > > > >>>
> > > > > >>> With plugins, people can write filters that are
> > > > > >>> written in languages other than C. Or filters which
> > > > > >>> some developer in FFmpeg doesnt want. Or they can be
> > > > > >>> maintained externally by people who just do not like us.
> > > > > >>> Or by people who perfer a FOSS license different from
> > > > > >>> LGPL/GPL/BSD. Iam sure others can come up with more
> > > > > >>> reasons ...
> > > > > >>>
> > > > > >>> Of course avfilter_register() isnt enough for plugins
> > > > > >>> but it or something equivalent is needed for plugins.
> > > > > >>>
> > > > > >>> So i would prefer if avfilter_register() stays supported
> > > > > >>> indefinitly or in case a different system is written for
> > > > > >>> plugins then until that system is in place.  
> > > > > >>
> > > > > >> It just returns error and logs error message that currently 
> > > > > >> external
> > > > > >> filter is unsupported. If someone wants to implement support for
> > > > > >> external filter, it can be easily added later using separate
> > > > > >> list/table.  
> > > > > > 
> > > > > > Iam not sure "easily" is true
> > > > > > 
> > > > > > We started out with a fully public API that allowed external 
> > > > > > filters.
> > > > > > and little by little its removed or made private.
> > > > > > each individual change may be easy to undo but as a whole moving
> > > > > > libavfilter back to having a public API is not that easy anymore
> > > > > > 
> > > > > > IIRC the arguments to make things private where that people wanted 
> > > > > > to
> > > > > > improve the API. But from the idea and impression of a plan like:
> > > > > > 1. make it private
> > > > > > 2. design and implement better API
> > > > > > 3. make it public again
> > > > > > 
> > > > > > Somehow now people lost sight and interrest in 3. and even 2. is 
> > > > > > becoming
> > > > > > less interresting. But the problem is really without 2 + 3 actually 
> > > > > > happening
> > > > > > doing 1 seems like not a good idea at all.
> > > > > > 
> > > > > > To me it seems even mentioning external filters and public API 
> > > > > > makes some
> > > > > > people angry.
> > > > > > But really that has to be the goal at some point. To again have a 
> > > > > > public API  
> > > > > 
> > > > > I agree that having (again) a public filter API would be good. This 
> > > > > would give users the freedom to implement their own special-purpose 
> > > > > filters (see the "dumpwave" discussion).
> > > > 
> > > > Someone needs to design and write it.
> > > > 
> > > > Whether we have external filters is completely orthogonal to this
> > > > change. 
> > >   
> > > > They were not possible before, because not enough API for
> > > > implementing them is public. 
> > > 
> > > This is correct if by "before" you mean today before this is applied.
> > > But longer ago, as in years, it was possible
> > > 
> > >   
> > > > They can be possible in the future, but
> > > > then registering them would need a different API anyway (one that
> > > > doesn't use global mutable state, but uses some sort of context
> > > > instead).
> > > 
> > > i understand that you arent a native english speaker nor am i but
> > > what you write here is not true.
> > > 
> > > Several people desire to eliminate all "global mutable state"
> > > and thats fine, iam happy if that is achieved. But its not
> > > that its neccessary for a fully functional API register or otherwise.
> > > The registering code with "global mutable state" and some form
> > > of thread synchronization would work perfectly fine.
> > > 
> > > What exactly is in relation to registering the problem with 
> > > "global mutable state" ?
> > > 
> > > One application registering a filter with a common name and another 
> > > application unintentionally using that ?  
> > 
> > Yes. It's not library-safe.
> >   
> > > This is not even possible because each application is in its own process 
> > > and
> > > will have its own independant copy of libavfilter in its address space 
> > > only
> > > with "read only" pages shared or with pages with "copy on write".  
> > 
> > This is a

Re: [FFmpeg-devel] [PATCH v3 1/6] lavc: add new API for iterating codecs and codec parsers

2018-01-31 Thread Michael Niedermayer
On Wed, Jan 31, 2018 at 08:25:50PM +, Josh de Kock wrote:
> Also replace linked list with an array.
> ---
>  configure  |   12 +-
>  doc/APIchanges |4 +
>  libavcodec/.gitignore  |2 +
>  libavcodec/allcodecs.c | 1473 
> 
>  libavcodec/avcodec.h   |   31 +
>  libavcodec/parser.c|   84 ++-
>  libavcodec/utils.c |  112 
>  libavcodec/version.h   |3 +
>  8 files changed, 971 insertions(+), 750 deletions(-)

breaks build
simple example:
cd buildhere && ../configure && make -j12
LD  ffmpeg_g
libavcodec/libavcodec.a(allcodecs.o):(.rodata+0xd8): undefined reference to 
`ff_hap_encoder'
libavcodec/libavcodec.a(allcodecs.o):(.rodata+0x4b8): undefined reference to 
`ff_libfdk_aac_encoder'
libavcodec/libavcodec.a(allcodecs.o):(.rodata+0x4c0): undefined reference to 
`ff_libgsm_encoder'
libavcodec/libavcodec.a(allcodecs.o):(.rodata+0x4c8): undefined reference to 
`ff_libgsm_ms_encoder'
libavcodec/libavcodec.a(allcodecs.o):(.rodata+0x4d0): undefined reference to 
`ff_libilbc_encoder'
libavcodec/libavcodec.a(allcodecs.o):(.rodata+0x4d8): undefined reference to 
`ff_libmp3lame_encoder'
libavcodec/libavcodec.a(allcodecs.o):(.rodata+0x4e0): undefined reference to 
`ff_libopencore_amrnb_encoder'
libavcodec/libavcodec.a(allcodecs.o):(.rodata+0x4e8): undefined reference to 
`ff_libopenjpeg_encoder'
libavcodec/libavcodec.a(allcodecs.o):(.rodata+0x4f0): undefined reference to 
`ff_libopus_encoder'
libavcodec/libavcodec.a(allcodecs.o):(.rodata+0x4f8): undefined reference to 
`ff_libspeex_encoder'
libavcodec/libavcodec.a(allcodecs.o):(.rodata+0x500): undefined reference to 
`ff_libtheora_encoder'
libavcodec/libavcodec.a(allcodecs.o):(.rodata+0x508): undefined reference to 
`ff_libtwolame_encoder'
libavcodec/libavcodec.a(allcodecs.o):(.rodata+0x510): undefined reference to 
`ff_libvo_amrwbenc_encoder'
libavcodec/libavcodec.a(allcodecs.o):(.rodata+0x518): undefined reference to 
`ff_libvorbis_encoder'
libavcodec/libavcodec.a(allcodecs.o):(.rodata+0x520): undefined reference to 
`ff_libvpx_vp8_encoder'
libavcodec/libavcodec.a(allcodecs.o):(.rodata+0x528): undefined reference to 
`ff_libvpx_vp9_encoder'
libavcodec/libavcodec.a(allcodecs.o):(.rodata+0x530): undefined reference to 
`ff_libwebp_anim_encoder'
libavcodec/libavcodec.a(allcodecs.o):(.rodata+0x538): undefined reference to 
`ff_libwebp_encoder'
libavcodec/libavcodec.a(allcodecs.o):(.rodata+0x540): undefined reference to 
`ff_libx264_encoder'
libavcodec/libavcodec.a(allcodecs.o):(.rodata+0x548): undefined reference to 
`ff_libx264rgb_encoder'
libavcodec/libavcodec.a(allcodecs.o):(.rodata+0x550): undefined reference to 
`ff_libx265_encoder'
libavcodec/libavcodec.a(allcodecs.o):(.rodata+0x558): undefined reference to 
`ff_libxavs_encoder'
libavcodec/libavcodec.a(allcodecs.o):(.rodata+0x560): undefined reference to 
`ff_libxvid_encoder'
libavcodec/libavcodec.a(allcodecs.o):(.rodata+0x568): undefined reference to 
`ff_libopenh264_encoder'
libavcodec/libavcodec.a(allcodecs.o):(.rodata+0x12e8): undefined reference to 
`ff_libfdk_aac_decoder'
libavcodec/libavcodec.a(allcodecs.o):(.rodata+0x12f0): undefined reference to 
`ff_libgsm_decoder'
libavcodec/libavcodec.a(allcodecs.o):(.rodata+0x12f8): undefined reference to 
`ff_libgsm_ms_decoder'
libavcodec/libavcodec.a(allcodecs.o):(.rodata+0x1300): undefined reference to 
`ff_libilbc_decoder'
libavcodec/libavcodec.a(allcodecs.o):(.rodata+0x1308): undefined reference to 
`ff_libopencore_amrnb_decoder'
libavcodec/libavcodec.a(allcodecs.o):(.rodata+0x1310): undefined reference to 
`ff_libopencore_amrwb_decoder'
libavcodec/libavcodec.a(allcodecs.o):(.rodata+0x1318): undefined reference to 
`ff_libopenjpeg_decoder'
libavcodec/libavcodec.a(allcodecs.o):(.rodata+0x1320): undefined reference to 
`ff_libopus_decoder'
libavcodec/libavcodec.a(allcodecs.o):(.rodata+0x1328): undefined reference to 
`ff_libspeex_decoder'
libavcodec/libavcodec.a(allcodecs.o):(.rodata+0x1330): undefined reference to 
`ff_libvorbis_decoder'
libavcodec/libavcodec.a(allcodecs.o):(.rodata+0x1338): undefined reference to 
`ff_libvpx_vp8_decoder'
libavcodec/libavcodec.a(allcodecs.o):(.rodata+0x1340): undefined reference to 
`ff_libvpx_vp9_decoder'
libavcodec/libavcodec.a(allcodecs.o):(.rodata+0x1348): undefined reference to 
`ff_libzvbi_teletext_decoder'
libavcodec/libavcodec.a(allcodecs.o):(.rodata+0x1368): undefined reference to 
`ff_libopenh264_decoder'

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

The worst form of inequality is to try to make unequal things equal.
-- Aristotle


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] avformat/hls: store referer message in HLS http request

2018-01-31 Thread Steven Liu
2018-01-09 15:39 GMT+08:00 Steven Liu :
> Signed-off-by: Steven Liu 
> ---
>  libavformat/hls.c | 4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/libavformat/hls.c b/libavformat/hls.c
> index 950cc4c3bd..9657b83fd9 100644
> --- a/libavformat/hls.c
> +++ b/libavformat/hls.c
> @@ -202,6 +202,7 @@ typedef struct HLSContext {
>  int64_t first_timestamp;
>  int64_t cur_timestamp;
>  AVIOInterruptCB *interrupt_callback;
> +char *referer;   ///< holds HTTP referer set as an 
> AVOption to the HTTP protocol context
>  char *user_agent;///< holds HTTP user agent set as 
> an AVOption to the HTTP protocol context
>  char *cookies;   ///< holds HTTP cookie values set 
> in either the initial response or as an AVOption to the HTTP protocol context
>  char *headers;   ///< holds HTTP headers set as an 
> AVOption to the HTTP protocol context
> @@ -1179,6 +1180,7 @@ static int open_input(HLSContext *c, struct playlist 
> *pls, struct segment *seg,
>
>  // broker prior HTTP options that should be consistent across requests
>  av_dict_set(&opts, "user_agent", c->user_agent, 0);
> +av_dict_set(&opts, "referer", c->referer, 0);
>  av_dict_set(&opts, "cookies", c->cookies, 0);
>  av_dict_set(&opts, "headers", c->headers, 0);
>  av_dict_set(&opts, "http_proxy", c->http_proxy, 0);
> @@ -1652,7 +1654,7 @@ static int save_avio_options(AVFormatContext *s)
>  {
>  HLSContext *c = s->priv_data;
>  static const char * const opts[] = {
> -"headers", "http_proxy", "user_agent", "user-agent", "cookies", NULL 
> };
> +"headers", "http_proxy", "user_agent", "user-agent", "cookies", 
> "referer", NULL };
>  const char * const * opt = opts;
>  uint8_t *buf;
>  int ret = 0;
> --
> 2.14.3 (Apple Git-98)
>
>
>

patchset pushed


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


Re: [FFmpeg-devel] [PATCH] hwcontext_vaapi: add iHD open source driver.

2018-01-31 Thread Jun Zhao


On 2018/1/31 19:13, Mark Thompson wrote:
> On 31/01/18 00:35, Jun Zhao wrote:
>> Now FFmpeg-VAAPI work with iHD open source driver
>> (https://github.com/intel/media-driver) initiatory.
>>
>> From 069611945880643aad6ffb5ea70b732f40bbb510 Mon Sep 17 00:00:00 2001
>> From: Jun Zhao 
>> Date: Wed, 31 Jan 2018 08:21:30 +0800
>> Subject: [PATCH] hwcontext_vaapi: add iHD open source driver.
>>
>> Signed-off-by: Jun Zhao 
>> ---
>>  libavutil/hwcontext_vaapi.c | 4 
>>  1 file changed, 4 insertions(+)
>>
>> diff --git a/libavutil/hwcontext_vaapi.c b/libavutil/hwcontext_vaapi.c
>> index 29698d1b27..34c5a2c264 100644
>> --- a/libavutil/hwcontext_vaapi.c
>> +++ b/libavutil/hwcontext_vaapi.c
>> @@ -285,6 +285,10 @@ static const struct {
>>  "ubit",
>>  AV_VAAPI_DRIVER_QUIRK_ATTRIB_MEMTYPE,
>>  },
>> +{
>> +"Intel iHD open source driver",
>> +"Intel iHD driver",
>> +},
>>  {
>>  "VDPAU wrapper",
>>  "Splitted-Desktop Systems VDPAU backend for VA-API",
>> -- 
>> 2.14.1
>>
> Why?  This is the "list of shame" for drivers with bad or incomplete 
> implementations which need explicit workarounds.  Since the iHD driver is new 
> (in some sense), hopefully it will be a correct implementation which does not 
> require any of these.
>
> - Mark
I leave the driver_quick with zero and just want to give a log message to
identify FFmpeg VA-API can co-work with iHD open source driver, so if
iHD fix the related issue, you don't want to give any log message in
FFmpeg VA-API?
> ___
> 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] hwcontext_vaapi: add iHD open source driver.

2018-01-31 Thread Jun Zhao


On 2018/2/1 14:45, Jun Zhao wrote:
>
> On 2018/1/31 19:13, Mark Thompson wrote:
>> On 31/01/18 00:35, Jun Zhao wrote:
>>> Now FFmpeg-VAAPI work with iHD open source driver
>>> (https://github.com/intel/media-driver) initiatory.
>>>
>>> From 069611945880643aad6ffb5ea70b732f40bbb510 Mon Sep 17 00:00:00 2001
>>> From: Jun Zhao 
>>> Date: Wed, 31 Jan 2018 08:21:30 +0800
>>> Subject: [PATCH] hwcontext_vaapi: add iHD open source driver.
>>>
>>> Signed-off-by: Jun Zhao 
>>> ---
>>>  libavutil/hwcontext_vaapi.c | 4 
>>>  1 file changed, 4 insertions(+)
>>>
>>> diff --git a/libavutil/hwcontext_vaapi.c b/libavutil/hwcontext_vaapi.c
>>> index 29698d1b27..34c5a2c264 100644
>>> --- a/libavutil/hwcontext_vaapi.c
>>> +++ b/libavutil/hwcontext_vaapi.c
>>> @@ -285,6 +285,10 @@ static const struct {
>>>  "ubit",
>>>  AV_VAAPI_DRIVER_QUIRK_ATTRIB_MEMTYPE,
>>>  },
>>> +{
>>> +"Intel iHD open source driver",
>>> +"Intel iHD driver",
>>> +},
>>>  {
>>>  "VDPAU wrapper",
>>>  "Splitted-Desktop Systems VDPAU backend for VA-API",
>>> -- 
>>> 2.14.1
>>>
>> Why?  This is the "list of shame" for drivers with bad or incomplete 
>> implementations which need explicit workarounds.  Since the iHD driver is 
>> new (in some sense), hopefully it will be a correct implementation which 
>> does not require any of these.
>>
>> - Mark
> I leave the driver_quick with zero and just want to give a log message to
> identify FFmpeg VA-API can co-work with iHD open source driver, so if
> iHD fix the related issue, you don't want to give any log message in
> FFmpeg VA-API?
Forget this commits, the code have handle this case, my fault.
>> ___
>> 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