Re: [FFmpeg-devel] [PATCH] libavfilter: constify filter list
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
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.
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
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
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
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
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
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
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.
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
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
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
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
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
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
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()
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
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 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 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
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()
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()
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
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
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
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
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
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()
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
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()
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
--- 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
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
--- 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
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
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
--- 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
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
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-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.
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
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()
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
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
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
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
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-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.
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.
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