Re: [FFmpeg-devel] [PATCH] New API usage example (encode_raw_audio_file_to_aac)
On 3/31/17, Paolo Prete wrote: > --- > configure | 2 + > doc/Makefile| 41 ++-- > doc/examples/.gitignore | 1 + > doc/examples/Makefile | 1 + > doc/examples/encode_raw_audio_file_to_aac.c | 338 > > 5 files changed, 363 insertions(+), 20 deletions(-) > create mode 100644 doc/examples/encode_raw_audio_file_to_aac.c What is the status of this patch? It's been quite a while and there have been no objections. Maybe it should be committed. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avfilter: add arbitrary audio FIR filter
On 5/6/17, Muhammad Faiz wrote:
> On Sat, May 6, 2017 at 2:30 AM, Paul B Mahol wrote:
>> Signed-off-by: Paul B Mahol
>> ---
>> configure| 2 +
>> doc/filters.texi | 10 +
>> libavfilter/Makefile | 1 +
>> libavfilter/af_afir.c| 484
>> +++
>> libavfilter/allfilters.c | 1 +
>> 5 files changed, 498 insertions(+)
>> create mode 100644 libavfilter/af_afir.c
>>
>> diff --git a/configure b/configure
>> index b3cb5b0..0d83c6a 100755
>> --- a/configure
>> +++ b/configure
>> @@ -3078,6 +3078,8 @@ unix_protocol_select="network"
>> # filters
>> afftfilt_filter_deps="avcodec"
>> afftfilt_filter_select="fft"
>> +afir_filter_deps="avcodec"
>> +afir_filter_select="fft"
>> amovie_filter_deps="avcodec avformat"
>> aresample_filter_deps="swresample"
>> ass_filter_deps="libass"
>> diff --git a/doc/filters.texi b/doc/filters.texi
>> index 119e747..ea343d1 100644
>> --- a/doc/filters.texi
>> +++ b/doc/filters.texi
>> @@ -878,6 +878,16 @@ afftfilt="1-clip((b/nb)*b,0,1)"
>> @end example
>> @end itemize
>>
>> +@section afirfilter
>> +
>> +Apply an Arbitary Frequency Impulse Response filter.
>> +
>> +This filter uses second stream as FIR coefficients.
>> +If second stream holds single channel, it will be used
>> +for all input channels in first stream, otherwise
>> +number of channels in second stream must be same as
>> +number of channels in first stream.
>> +
>> @anchor{aformat}
>> @section aformat
>
> Seems that you forgot to update the documentation.
>
>>
>> diff --git a/libavfilter/Makefile b/libavfilter/Makefile
>> index 66c36e4..c797eb5 100644
>> --- a/libavfilter/Makefile
>> +++ b/libavfilter/Makefile
>> @@ -38,6 +38,7 @@ OBJS-$(CONFIG_AEMPHASIS_FILTER) +=
>> af_aemphasis.o
>> OBJS-$(CONFIG_AEVAL_FILTER) += aeval.o
>> OBJS-$(CONFIG_AFADE_FILTER) += af_afade.o
>> OBJS-$(CONFIG_AFFTFILT_FILTER) += af_afftfilt.o
>> window_func.o
>> +OBJS-$(CONFIG_AFIR_FILTER) += af_afir.o
>> OBJS-$(CONFIG_AFORMAT_FILTER)+= af_aformat.o
>> OBJS-$(CONFIG_AGATE_FILTER) += af_agate.o
>> OBJS-$(CONFIG_AINTERLEAVE_FILTER)+= f_interleave.o
>> diff --git a/libavfilter/af_afir.c b/libavfilter/af_afir.c
>> new file mode 100644
>> index 000..9411c9b
>> --- /dev/null
>> +++ b/libavfilter/af_afir.c
>> @@ -0,0 +1,484 @@
>> +/*
>> + * Copyright (c) 2017 Paul B Mahol
>> + *
>> + * This file is part of FFmpeg.
>> + *
>> + * FFmpeg is free software; you can redistribute it and/or
>> + * modify it under the terms of the GNU Lesser General Public
>> + * License as published by the Free Software Foundation; either
>> + * version 2.1 of the License, or (at your option) any later version.
>> + *
>> + * FFmpeg is distributed in the hope that it will be useful,
>> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
>> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
>> + * Lesser General Public License for more details.
>> + *
>> + * You should have received a copy of the GNU Lesser General Public
>> + * License along with FFmpeg; if not, write to the Free Software
>> + * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA
>> 02110-1301 USA
>> + */
>> +
>> +/**
>> + * @file
>> + * An arbitrary audio FIR filter
>> + */
>> +
>> +#include "libavutil/audio_fifo.h"
>> +#include "libavutil/common.h"
>> +#include "libavutil/opt.h"
>> +#include "libavcodec/avfft.h"
>> +
>> +#include "audio.h"
>> +#include "avfilter.h"
>> +#include "formats.h"
>> +#include "internal.h"
>> +
>> +#define MAX_IR_DURATION 20
>> +
>> +typedef struct FIRContext {
>> +const AVClass *class;
>> +
>> +float wet_gain;
>> +float dry_gain;
>> +int auto_gain;
>> +
>> +float gain;
>> +
>> +int eof_coeffs;
>> +int have_coeffs;
>> +int nb_coeffs;
>> +int nb_taps;
>> +int part_size;
>> +int nb_partitions;
>> +int fft_length;
>> +int nb_channels;
>> +int nb_coef_channels;
>> +int one2many;
>> +int nb_samples;
>> +
>> +RDFTContext **rdft, **irdft;
>> +float **sum;
>> +float **block;
>> +FFTComplex **coeff;
>> +
>> +AVAudioFifo *fifo[2];
>> +AVFrame *in[2];
>> +AVFrame *buffer;
>> +int64_t pts;
>> +} FIRContext;
>> +
>> +static int fir_channel(AVFilterContext *ctx, void *arg, int ch, int
>> nb_jobs)
>> +{
>> +FIRContext *s = ctx->priv;
>> +AVFrame *out = arg;
>> +const FFTComplex *coeff = s->coeff[ch * !s->one2many];
>> +const float *src = (const float *)s->in[0]->extended_data[ch];
>> +float *dst = (float *)out->extended_data[ch];
>> +float *buf = (float *)s->buffer->extended_data[ch];
>> +float *sum = s->sum[ch];
>> +float *block = s->block[ch];
>> +int n, i;
>> +
>> +memset(sum, 0, sizeof(*sum) * 2 * (s->part_size + 1));
>> +memset(block, 0, sizeof(*block) * 2 * (s->part_size + 1));
>> +for (n =
[FFmpeg-devel] [PATCH 3/3] lavfi: add a framework to fix alignment problems.
A lot of filters require aligned frame data, but do not document it.
It can result in crashes with perfectly valid uses of the API.
Signed-off-by: Nicolas George
---
libavfilter/avfilter.h | 9 +
1 file changed, 9 insertions(+)
diff --git a/libavfilter/avfilter.h b/libavfilter/avfilter.h
index 60662c19ac..db9c02b8c0 100644
--- a/libavfilter/avfilter.h
+++ b/libavfilter/avfilter.h
@@ -569,6 +569,15 @@ struct AVFilterLink {
*/
AVBufferRef *hw_frames_ctx;
+/**
+ * Minimum alignment of frame data required by the destination filter.
+ * All frame data pointers must have the alignment lower bits cleared,
+ * i.e. be a multiple of 1
[FFmpeg-devel] [PATCH 2/3] lavc: add a framework to fix alignment problems.
A lot of codecs require aligned frame data, but do not document it.
It can result in crashes with perfectly valid uses of the API.
TODO Implementation missing.
Design rationale:
- requiring frame data to be always aligned would be wasteful;
- alignment requirements will evolve
(the 16->32 bump is still recent);
- requiring applications to worry about alignment is not convenient.
Signed-off-by: Nicolas George
---
libavcodec/avcodec.h | 10 ++
1 file changed, 10 insertions(+)
diff --git a/libavcodec/avcodec.h b/libavcodec/avcodec.h
index 35df4f6ced..51a7e2db21 100644
--- a/libavcodec/avcodec.h
+++ b/libavcodec/avcodec.h
@@ -3644,6 +3644,16 @@ typedef struct AVCodecContext {
* AVCodecContext.get_format callback)
*/
int hwaccel_flags;
+
+/**
+ * Minimum alignment of frame data required by the codec.
+ * All frame data pointers must have the alignment lower bits cleared,
+ * i.e. be a multiple of 1
[FFmpeg-devel] [PATCH 1/3] lavu/frame: add av_frame_realign().
TODO Actual implementation. Signed-off-by: Nicolas George --- libavutil/frame.h | 9 + 1 file changed, 9 insertions(+) Here is a proposal for actually fixing the alignment problems that are all over the place in the current code base. Note that it is only a design proposal, all the actual implementation is missing. I do not want to waste my time implementing if the design is to be bikeshedded to death. diff --git a/libavutil/frame.h b/libavutil/frame.h index 4d8c1bed4f..162ea0716c 100644 --- a/libavutil/frame.h +++ b/libavutil/frame.h @@ -746,6 +746,15 @@ void av_frame_remove_side_data(AVFrame *frame, enum AVFrameSideDataType type); const char *av_frame_side_data_name(enum AVFrameSideDataType type); /** + * Realign the data pointers of a frame. + * Make sure all frame data pointers have the alignment lower bits cleared, + * i.e. are a multiple of 1<=0 for success or an AVERROR code. + */ +int av_frame_realign(AVFrame *frame, unsigned align); + +/** * @} */ -- 2.11.0 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avfilter: align data frame when needed
Le sextidi 16 floréal, an CCXXV, Kieran Kunhya a écrit : > I sent a patch about this nearly three years ago, it wasn't applied for > whatever reason. > This is pretty common if you don't use av_malloc. Thanks for pointing it. As for the rest, I can observe that my hope that some people will start acting like adult and spend their time in constructive ways instead of spending it flaming scapegoats. And I am quite fed up to be the designated scapegoat just because I happen to see flaws in other people's design. This project is in sore need of an Architect ( http://esr.ibiblio.org/?p=7478 ), but I do not see many around here. So I have taken the moral high ground, and just posted a proposal for an actual fix, despite my statement of not intending to do so. Regards, -- Nicolas George signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avfilter: align data frame when needed
On Sat, 6 May 2017 11:20:13 +0200 Nicolas George wrote: > Le sextidi 16 floréal, an CCXXV, Kieran Kunhya a écrit : > > I sent a patch about this nearly three years ago, it wasn't applied for > > whatever reason. > > This is pretty common if you don't use av_malloc. > > Thanks for pointing it. Well, nobody expected that apparently you didn't know that you have to use av_malloc for everything in FFmpeg exactly because of alignment requirements. Usually every API user learns this the hard way. (I wonder if you ever used the FFmpeg API outside of ffmpeg.c...) > As for the rest, I can observe that my hope that some people will start > acting like adult I can't say your behavior was particularly adult like. You raised a fuzz because a bug was found and we wanted it to be fixed. Adults fix their bugs and don't blame them on others. > and spend their time in constructive ways instead of > spending it flaming scapegoats. This isn't about "scapegoats" - we just tried to get rid of that bug. (Still trying...) Apropos "scapegoat" - you're blaming everyone here, without acknowledging any responsibility yourself. What we really don't want in this project is that every time a bug is pointed out, someone freaks out and raises a shit storm. > And I am quite fed up to be the > designated scapegoat just because I happen to see flaws in other > people's design. "Seeing flaws in other people's design" is ok, but your behavior otherwise was a little questionable. By the way, I can't help to observe that you refused to fix the bug since it was not your fault (even though your change triggered it). Fine, but what exactly makes you expect others to fix that bug? These "others" are even less responsible for the bug than you. That would still have been fine, but then you rejected bug fix patches by others. Now I'm the first to say that we should fix bugs properly, instead of painting them over with hacks, but let me remind you that no better solution was in sight (or anyone working on it), and the crash still happened, so applying whatever short-term fixes we had would have been fine. (Or alternatively, reverting the patch that triggered it.) > This project is in sore need of an Architect ( > http://esr.ibiblio.org/?p=7478 > ), but I do not see many around here. That's... rich. I hope you don't claim to be that Architect. If you think that's an insult, be aware that you just insulted everyone else here. (Fortunately you added a "many" so that the reader can chose whether he should be affected by the insult or not. How funny of you.) > So I have taken the moral high ground, and just posted a proposal for an > actual fix, despite my statement of not intending to do so. This is amazing. When I saw your patches I thought you started to understand (although I wasn't impressed by the lack of implementation), but here you go and turn that around into yet another passive aggressive bout. Very adult-like. Maybe we can avoid all this bullshit the next time? ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 2/3] lavc: add a framework to fix alignment problems.
On Sat, May 6, 2017 at 11:20 AM, Nicolas George wrote:
> A lot of codecs require aligned frame data, but do not document it.
> It can result in crashes with perfectly valid uses of the API.
>
> TODO Implementation missing.
>
> Design rationale:
>
> - requiring frame data to be always aligned would be wasteful;
>
> - alignment requirements will evolve
> (the 16->32 bump is still recent);
>
> - requiring applications to worry about alignment is not convenient.
>
> Signed-off-by: Nicolas George
> ---
> libavcodec/avcodec.h | 10 ++
> 1 file changed, 10 insertions(+)
>
> diff --git a/libavcodec/avcodec.h b/libavcodec/avcodec.h
> index 35df4f6ced..51a7e2db21 100644
> --- a/libavcodec/avcodec.h
> +++ b/libavcodec/avcodec.h
> @@ -3644,6 +3644,16 @@ typedef struct AVCodecContext {
> * AVCodecContext.get_format callback)
> */
> int hwaccel_flags;
> +
> +/**
> + * Minimum alignment of frame data required by the codec.
> + * All frame data pointers must have the alignment lower bits cleared,
> + * i.e. be a multiple of 1< + * - encoding: set by the encoder and used by the framework
> + * - decoding: unused
> + */
> +unsigned alignment;
> +
> } AVCodecContext;
>
I don't think this is very practical. We have a bunch of generic DSPs
and if a codec uses those it would need to be constantly updated if
the requirements of those DSPs change. Today it may only use SSE and
be happy with 16-byte alignment, but what if someone adds an AVX2
implementation, or AVX512?
Going through all codecs that use some DSP and somehow set their
alignment value seems rather unfortunate - and on top of that, it'll
add arch-specific conditions, which leads to a lot of unnecessary
changes to a bunch of encoders (and filters) over time.
Or the alternative is that its initialized to some default value based
on the current CPU and only overriden in a minority of cases, which
still makes me wonder if the effort is worth it.
Right now the general consensus is that frames (and stride) should be
aligned to the maximum your CPU might require, ie. 32 byte on a AVX2
CPU, even if this is not documented.
I think it would be far better to officially document this. Making
applications aware of the alignment (which they likely are already
anyway, otherwise they would crash, even if they had to learn the hard
way) can make the entire process more efficient, since re-aligning can
be extremely expensive (ie. high res video) and should be avoided at
all cost if possible (which it not always is when you crop, for
example).
There is no particular reason we can't make the framework check the
alignment and re-align if required to the maximum CPU value (with a
loud warning, perhaps), but I don't think a per-codec or per-filter
alignment value is very practical.
Related, Libav introduced an API called av_cpu_max_align to query the
alignment requirements for the CPU, in case someone is not using
av_malloc to allocate their buffers, but their own allocation
mechanisms.
- Hendrik
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avcodec/dcaenc: Initial implementation of ADPCM encoding for DCA encoder
Tiny fix: missed inline attr.
On Thu, May 4, 2017 at 1:17 AM, Даниил Чередник
wrote:
> All notices were fixed. Also I found issue with uninitialized subband
> buffer - fixed. New patch attached.
>
> On Wed, May 3, 2017 at 7:49 AM, Rostislav Pehlivanov
> wrote:
>
>> On 2 May 2017 at 22:53, Даниил Чередник wrote:
>>
>> > Hi.
>> >
>> > This patch introduces initial implementation of subband ADPCM encoding
>> for
>> > DCA codec.
>> >
>> > Some results:
>> >
>> > sample:
>> >
>> > https://yadi.sk/d/B_3sVskM3HZiWK - original
>> >
>> > https://yadi.sk/d/7CK47Nt63HZiWf - without adpcm
>> >
>> > https://yadi.sk/d/25q1JDV93HZiWq - with adpcm
>> >
>> > chirp tone:
>> >
>> > https://yadi.sk/i/tZKHoJ1d3HZk4c
>> >
>> > Right now this feature is disabled by default. But it is ready to try
>> > using -dca_adpcm 1 option.
>> >
>> > There are some issues, should be solved before enabling this feature by
>> > default:
>> >
>> > 1. Speed up: I am trying to find best filter in each subband. But with
>> real
>> > signal, usually only few subbands has significant prediction gain. The
>> idea
>> > is try to analyze FFT spectrum (which is already calculated), to check
>> is
>> > particular subband looks like tonal or noise. If subband is noise like
>> - do
>> > not try to find best LPC predictor.
>> >
>> > 2. Modify psychoacoustic to use prediction gain for bit allocation.
>> Right
>> > now ADPCM encoded block can get some extra bits.
>> >
>> > 3. Tuning the prediction gain threshold.
>> >
>> >
>> > Thank you.
>> > --
>> > Daniil Cherednik
>> >
>> > ___
>> > ffmpeg-devel mailing list
>> > ffmpeg-devel@ffmpeg.org
>> > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>> >
>> >
>> >+static int64_t calc_corr(const int32_t *x, int len, int j, int k)
>>
>> Add inline attrib? Seems appropriate here.
>>
>>
>> >+for (n = 0; n < len; n++) {
>> >+s += MUL64(x[n-j], x[n-k]);
>> >+}
>>
>> For loops with 1 line we leave the brackets out.
>>
>>
>> >+for (i = 0; i <= DCA_ADPCM_COEFFS; i++) {
>> >+for (j = i; j <= DCA_ADPCM_COEFFS; j++) {
>> >+corr[k++] = calc_corr(in+4, len, i, j);
>> >+}
>> >+}
>>
>> Same
>>
>>
>> >+for (i = 0; i < len + DCA_ADPCM_COEFFS; i++) {
>> >+max |= FFABS(in[i]);
>> >+}
>>
>> Same
>>
>>
>> >for (ch = 0; ch < c->fullband_channels; ch++) {
>> >+for (band = 0; band < 32; band++) {
>> >+if (c->prediction_mode[ch][band] >= 0) {
>> >+quantize_adpcm_subband(c, ch, band);
>> >+}
>> >+}
>> >+}
>>
>> Same
>>
>>
>> >+for (ch = 0; ch < c->fullband_channels; ch++) {
>> >+for (band = 0; band < 32; band++) {
>> >+if (c->prediction_mode[ch][band] == -1) {
>> >+for (sample = 0; sample < SUBBAND_SAMPLES; sample++) {
>> >+c->quantized[ch][band][sample] =
>> quantize_value(c->subband[ch][band][sample], c->quant[ch][band]);
>> >+}
>> >+}
>> >+}
>> >+}
>>
>> Same, 4 whole whitespace lines added here.
>>
>>
>> >+if (c->bitrate_index == 3) {
>> >+step_size = ff_dca_lossless_quant[c->abits[ch][band]];
>> >+} else {
>> >+step_size = ff_dca_lossy_quant[c->abits[ch][band]];
>> >+}
>>
>> Same
>>
>>
>> >for (;;) {
>>
>> while (1) {
>>
>> >+if (i++ == last_pos)
>> >+break;
>>
>> Better yet remove the infinite loop and just use a normal for () loop.
>>
>>
>> >+static inline void ff_dca_core_dequantize(int32_t *output, const int32_t
>> *input,
>> >+ int32_t step_size, int32_t scale, int
>> residual, int len)
>>
>> Fix second line's alignment.
>>
>>
>> >+struct premultiplied_coeffs {
>> >+int32_t aa[10];
>> >+};
>>
>> I think it would be simpler to just use int32_t premultiplied_coeffs[10]
>> instead of a struct.
>>
>>
>> Apart from these style issues patch looks fine. I'll be able to test it in
>> a day.
>> ___
>> ffmpeg-devel mailing list
>> ffmpeg-devel@ffmpeg.org
>> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>>
>
>
>
> --
> Daniil Cherednik
>
--
Daniil Cherednik
0001-avcodec-dcaenc-Initial-implementation-of-ADPCM-encod_v3.patch
Description: Binary data
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] avdevice/alsa: wait until playback buffers are drained before closing
This fixes early abort on ALSA playback
---
libavdevice/alsa.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/libavdevice/alsa.c b/libavdevice/alsa.c
index 8d27913..1bbff30 100644
--- a/libavdevice/alsa.c
+++ b/libavdevice/alsa.c
@@ -300,6 +300,8 @@ av_cold int ff_alsa_close(AVFormatContext *s1)
{
AlsaData *s = s1->priv_data;
+snd_pcm_nonblock(s->h, 0);
+snd_pcm_drain(s->h);
av_freep(&s->reorder_buf);
if (CONFIG_ALSA_INDEV)
ff_timefilter_destroy(s->timefilter);
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] rtmpproto: send swfverify value as swfurl if latter is unused
Third ping. This patch is trivial, and makes behavior of librtmp and ffrtmp consistent when using rtmp_swfverify. What's blocking this? ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 2/3] lavc: add a framework to fix alignment problems.
Hi, On Sat, May 6, 2017 at 5:20 AM, Nicolas George wrote: > +/** > + * Minimum alignment of frame data required by the codec. > + * All frame data pointers must have the alignment lower bits cleared, > + * i.e. be a multiple of 1< + * - encoding: set by the encoder and used by the framework > + * - decoding: unused > + */ > +unsigned alignment; > + > } AVCodecContext; I agree it's likely that one codec (e.g. h264) would need 32-byte alignment on a particular system (e.g. x86/haswell), whereas another codec on the same system (e.g. wmavoice) might not. However, I find it unlikely that one codec *instance* would need different alignment from another codec *instance* (for the same codec). The above allows seems specifically designed for that. Do you think adding alignment to AVCodec would make more sense (and possibly set it at runtime using static_init)? Ronald ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avfilter: add arbitrary audio FIR filter
On Sat, May 6, 2017 at 3:54 PM, Paul B Mahol wrote:
> On 5/6/17, Muhammad Faiz wrote:
>> On Sat, May 6, 2017 at 2:30 AM, Paul B Mahol wrote:
>>> Signed-off-by: Paul B Mahol
>>> ---
>>> configure| 2 +
>>> doc/filters.texi | 10 +
>>> libavfilter/Makefile | 1 +
>>> libavfilter/af_afir.c| 484
>>> +++
>>> libavfilter/allfilters.c | 1 +
>>> 5 files changed, 498 insertions(+)
>>> create mode 100644 libavfilter/af_afir.c
>>>
>>> diff --git a/configure b/configure
>>> index b3cb5b0..0d83c6a 100755
>>> --- a/configure
>>> +++ b/configure
>>> @@ -3078,6 +3078,8 @@ unix_protocol_select="network"
>>> # filters
>>> afftfilt_filter_deps="avcodec"
>>> afftfilt_filter_select="fft"
>>> +afir_filter_deps="avcodec"
>>> +afir_filter_select="fft"
>>> amovie_filter_deps="avcodec avformat"
>>> aresample_filter_deps="swresample"
>>> ass_filter_deps="libass"
>>> diff --git a/doc/filters.texi b/doc/filters.texi
>>> index 119e747..ea343d1 100644
>>> --- a/doc/filters.texi
>>> +++ b/doc/filters.texi
>>> @@ -878,6 +878,16 @@ afftfilt="1-clip((b/nb)*b,0,1)"
>>> @end example
>>> @end itemize
>>>
>>> +@section afirfilter
>>> +
>>> +Apply an Arbitary Frequency Impulse Response filter.
>>> +
>>> +This filter uses second stream as FIR coefficients.
>>> +If second stream holds single channel, it will be used
>>> +for all input channels in first stream, otherwise
>>> +number of channels in second stream must be same as
>>> +number of channels in first stream.
>>> +
>>> @anchor{aformat}
>>> @section aformat
>>
>> Seems that you forgot to update the documentation.
>>
>>>
>>> diff --git a/libavfilter/Makefile b/libavfilter/Makefile
>>> index 66c36e4..c797eb5 100644
>>> --- a/libavfilter/Makefile
>>> +++ b/libavfilter/Makefile
>>> @@ -38,6 +38,7 @@ OBJS-$(CONFIG_AEMPHASIS_FILTER) +=
>>> af_aemphasis.o
>>> OBJS-$(CONFIG_AEVAL_FILTER) += aeval.o
>>> OBJS-$(CONFIG_AFADE_FILTER) += af_afade.o
>>> OBJS-$(CONFIG_AFFTFILT_FILTER) += af_afftfilt.o
>>> window_func.o
>>> +OBJS-$(CONFIG_AFIR_FILTER) += af_afir.o
>>> OBJS-$(CONFIG_AFORMAT_FILTER)+= af_aformat.o
>>> OBJS-$(CONFIG_AGATE_FILTER) += af_agate.o
>>> OBJS-$(CONFIG_AINTERLEAVE_FILTER)+= f_interleave.o
>>> diff --git a/libavfilter/af_afir.c b/libavfilter/af_afir.c
>>> new file mode 100644
>>> index 000..9411c9b
>>> --- /dev/null
>>> +++ b/libavfilter/af_afir.c
>>> @@ -0,0 +1,484 @@
>>> +/*
>>> + * Copyright (c) 2017 Paul B Mahol
>>> + *
>>> + * This file is part of FFmpeg.
>>> + *
>>> + * FFmpeg is free software; you can redistribute it and/or
>>> + * modify it under the terms of the GNU Lesser General Public
>>> + * License as published by the Free Software Foundation; either
>>> + * version 2.1 of the License, or (at your option) any later version.
>>> + *
>>> + * FFmpeg is distributed in the hope that it will be useful,
>>> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
>>> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
>>> + * Lesser General Public License for more details.
>>> + *
>>> + * You should have received a copy of the GNU Lesser General Public
>>> + * License along with FFmpeg; if not, write to the Free Software
>>> + * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA
>>> 02110-1301 USA
>>> + */
>>> +
>>> +/**
>>> + * @file
>>> + * An arbitrary audio FIR filter
>>> + */
>>> +
>>> +#include "libavutil/audio_fifo.h"
>>> +#include "libavutil/common.h"
>>> +#include "libavutil/opt.h"
>>> +#include "libavcodec/avfft.h"
>>> +
>>> +#include "audio.h"
>>> +#include "avfilter.h"
>>> +#include "formats.h"
>>> +#include "internal.h"
>>> +
>>> +#define MAX_IR_DURATION 20
>>> +
>>> +typedef struct FIRContext {
>>> +const AVClass *class;
>>> +
>>> +float wet_gain;
>>> +float dry_gain;
>>> +int auto_gain;
>>> +
>>> +float gain;
>>> +
>>> +int eof_coeffs;
>>> +int have_coeffs;
>>> +int nb_coeffs;
>>> +int nb_taps;
>>> +int part_size;
>>> +int nb_partitions;
>>> +int fft_length;
>>> +int nb_channels;
>>> +int nb_coef_channels;
>>> +int one2many;
>>> +int nb_samples;
>>> +
>>> +RDFTContext **rdft, **irdft;
>>> +float **sum;
>>> +float **block;
>>> +FFTComplex **coeff;
>>> +
>>> +AVAudioFifo *fifo[2];
>>> +AVFrame *in[2];
>>> +AVFrame *buffer;
>>> +int64_t pts;
>>> +} FIRContext;
>>> +
>>> +static int fir_channel(AVFilterContext *ctx, void *arg, int ch, int
>>> nb_jobs)
>>> +{
>>> +FIRContext *s = ctx->priv;
>>> +AVFrame *out = arg;
>>> +const FFTComplex *coeff = s->coeff[ch * !s->one2many];
>>> +const float *src = (const float *)s->in[0]->extended_data[ch];
>>> +float *dst = (float *)out->extended_data[ch];
>>> +float *buf = (float *)s->buffer->extended_data[ch];
>>> +float *sum = s->sum[ch];
>>
Re: [FFmpeg-devel] [PATCH] avfilter: align data frame when needed
On Fri, May 5, 2017 at 11:22 PM, Nicolas George wrote: > Le sextidi 16 floréal, an CCXXV, Muhammad Faiz a écrit : >> But if documentation >> says that data should be aligned to 4-bytes but I align it to >> 32-bytes, then there are no violations at all. So what's wrong with >> this patch? > > Useless code performing wasteful operations in speed-critical sections. This is not speed-critical section. The command: ./ffmpeg -filter_complex "aevalsrc=0:d=1000, aformat=fltp, firequalizer=fixed=on:delay=0.0013, volume=0.5" -f null null segfault at eof. So, this section is rarely executed. And code below this section do extensive copying. > > Write the doc, and we can discuss. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/3] lavu/frame: add av_frame_realign().
On Sat, May 6, 2017 at 4:20 PM, Nicolas George wrote: > TODO Actual implementation. > > Signed-off-by: Nicolas George > --- > libavutil/frame.h | 9 + > 1 file changed, 9 insertions(+) > > > Here is a proposal for actually fixing the alignment problems that are all > over the place in the current code base. > > Note that it is only a design proposal, all the actual implementation is > missing. I do not want to waste my time implementing if the design is to be > bikeshedded to death. > > > diff --git a/libavutil/frame.h b/libavutil/frame.h > index 4d8c1bed4f..162ea0716c 100644 > --- a/libavutil/frame.h > +++ b/libavutil/frame.h > @@ -746,6 +746,15 @@ void av_frame_remove_side_data(AVFrame *frame, enum > AVFrameSideDataType type); > const char *av_frame_side_data_name(enum AVFrameSideDataType type); > > /** > + * Realign the data pointers of a frame. > + * Make sure all frame data pointers have the alignment lower bits cleared, > + * i.e. are a multiple of 1< + * If not, a new frame is allocated and overwrites the current one. > + * @return >=0 for success or an AVERROR code. > + */ > +int av_frame_realign(AVFrame *frame, unsigned align); > + > +/** > * @} > */ > > -- > 2.11.0 Whatever the result here (accepted or rejected), we still need a fix without API change. Otherwise, it can't go to 3.3 branch. Thank's. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avfilter: align data frame when needed
Hi Muhammad, On Sat, May 6, 2017 at 10:13 AM, Muhammad Faiz wrote: > On Fri, May 5, 2017 at 11:22 PM, Nicolas George wrote: > > Le sextidi 16 floréal, an CCXXV, Muhammad Faiz a écrit : > >> But if documentation > >> says that data should be aligned to 4-bytes but I align it to > >> 32-bytes, then there are no violations at all. So what's wrong with > >> this patch? > > > > Useless code performing wasteful operations in speed-critical sections. > > This is not speed-critical section. Not in this case, no. But I believe we have multiple issues in this area and some of the affected areas _are_ speed-critical. Plus, we like speed even if it's pointless. There's no problem with that. Ronald ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/3] lavu/frame: add av_frame_realign().
Le septidi 17 floréal, an CCXXV, Muhammad Faiz a écrit : > Whatever the result here (accepted or rejected), we still need a fix > without API change. Otherwise, it can't go to 3.3 branch. There is no API change as is (except for the extra function in lavu, but that is only an add, and can be worked around), that is one of the points of the design. (I will answer to the other mails later, it takes a little more time.) Regards, -- Nicolas George signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avfilter: align data frame when needed
Hi, On Fri, May 5, 2017 at 12:17 PM, Nicolas George wrote: > Le sextidi 16 floréal, an CCXXV, Hendrik Leppkes a écrit : > > Blocking crash fixes on silly arguments doesn't help anyone. Send a > > My argument is not silly: the code to align the frame will be needed, > but NOT HERE. I actually think this is a fair point. I've hated the swscale frame alignment code for ages, and this can effectively be used to clean that up also. We could even start making padding requirements which would make swscale SIMD writing a LOT easier. Let's think about this a little bit guys. Nicolas may be overly aggressive, but he has a good point. Ronald ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/3] lavu/frame: add av_frame_realign().
On Sat, May 6, 2017 at 9:39 PM, Nicolas George wrote: > Le septidi 17 floréal, an CCXXV, Muhammad Faiz a écrit : >> Whatever the result here (accepted or rejected), we still need a fix >> without API change. Otherwise, it can't go to 3.3 branch. > > There is no API change as is (except for the extra function in lavu, but > that is only an add, and can be worked around), that is one of the > points of the design. As far as I know. No new features can go to release branch. Or maybe I'm wrong. Thank's. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avfilter: align data frame when needed
On Sat, May 6, 2017 at 9:36 PM, Ronald S. Bultje wrote: > Hi Muhammad, > > On Sat, May 6, 2017 at 10:13 AM, Muhammad Faiz wrote: > >> On Fri, May 5, 2017 at 11:22 PM, Nicolas George wrote: >> > Le sextidi 16 floréal, an CCXXV, Muhammad Faiz a écrit : >> >> But if documentation >> >> says that data should be aligned to 4-bytes but I align it to >> >> 32-bytes, then there are no violations at all. So what's wrong with >> >> this patch? >> > >> > Useless code performing wasteful operations in speed-critical sections. >> >> This is not speed-critical section. > > > Not in this case, no. But I believe we have multiple issues in this area > and some of the affected areas _are_ speed-critical. I guess, those speed-critical areas are video frames. Because the data is larger. > > Plus, we like speed even if it's pointless. There's no problem with that. But it should not generate crash. Thanks. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avfilter: align data frame when needed
On Sat, May 6, 2017 at 9:35 PM, Ronald S. Bultje wrote: > Hi, > > On Fri, May 5, 2017 at 12:17 PM, Nicolas George wrote: > >> Le sextidi 16 floréal, an CCXXV, Hendrik Leppkes a écrit : >> > Blocking crash fixes on silly arguments doesn't help anyone. Send a >> >> My argument is not silly: the code to align the frame will be needed, >> but NOT HERE. > > > I actually think this is a fair point. I've hated the swscale frame > alignment code for ages, and this can effectively be used to clean that up > also. We could even start making padding requirements which would make > swscale SIMD writing a LOT easier. > > Let's think about this a little bit guys. Nicolas may be overly aggressive, > but he has a good point. +1 But, my point is: Because the design of handling data alignment may take long time to discuss, and also it may add new features which can't be backported, we need temporal fix. There are two choices: - fix libmp3lame (previous patch) and filters/codecs that need aligned data - fix framequeue (this patch). And I think, fixing framequeue is more elegant. I think, Nicolas was afraid that if the crash is fixed, people will not be aware again with the alignment problem and will not discuss it. Thank's. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/3] lavu/frame: add av_frame_realign().
On Sat, May 6, 2017 at 5:40 PM, Muhammad Faiz wrote: > On Sat, May 6, 2017 at 9:39 PM, Nicolas George wrote: >> Le septidi 17 floréal, an CCXXV, Muhammad Faiz a écrit : >>> Whatever the result here (accepted or rejected), we still need a fix >>> without API change. Otherwise, it can't go to 3.3 branch. >> >> There is no API change as is (except for the extra function in lavu, but >> that is only an add, and can be worked around), that is one of the >> points of the design. > > As far as I know. No new features can go to release branch. > Or maybe I'm wrong. > This is correct. The 3.3 branch should be fixed without new API or some complex design, perhaps with the patch posted that re-aligns framequeue output. - Hendrik ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avfilter: align data frame when needed
Le septidi 17 floréal, an CCXXV, Muhammad Faiz a écrit : > - fix framequeue (this patch). Once again, this patch is not correct. In particular it is NOT ENOUGH to fix the crash in all cases. Regards, -- Nicolas George ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] libavcodec/h264_sei: Don't log random user data.
On Fri, May 05, 2017 at 09:30:54PM +, Kieran Kunhya wrote: > From d43c0366d4ba128772dc7909152f4e9635f269cb Mon Sep 17 00:00:00 2001 > From: Kieran Kunhya > Date: Fri, 5 May 2017 14:29:59 -0700 > Subject: [PATCH] libavcodec/h264_sei: Don't log random user data. This > prevents terminal junk. > > --- > libavcodec/h264_sei.c | 3 --- > 1 file changed, 3 deletions(-) > > diff --git a/libavcodec/h264_sei.c b/libavcodec/h264_sei.c > index a7e627eba3..c81ddfef4f 100644 > --- a/libavcodec/h264_sei.c > +++ b/libavcodec/h264_sei.c > @@ -257,9 +257,6 @@ static int > decode_unregistered_user_data(H264SEIUnregistered *h, GetBitContext * > if (e == 1 && build == 1 && !strncmp(user_data+16, "x264 - core ", > 16)) > h->x264_build = 67; > > -if (strlen(user_data + 16) > 0) > -av_log(logctx, AV_LOG_DEBUG, "user data:\"%s\"\n", user_data + 16); This is just at debug level. Do you have an example (file/usecase) where this causes excessive output ? [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Freedom in capitalist society always remains about the same as it was in ancient Greek republics: Freedom for slave owners. -- Vladimir Lenin signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 2/3] lavc: add a framework to fix alignment problems.
On Sat, 6 May 2017, Ronald S. Bultje wrote: Hi, On Sat, May 6, 2017 at 5:20 AM, Nicolas George wrote: +/** + * Minimum alignment of frame data required by the codec. + * All frame data pointers must have the alignment lower bits cleared, + * i.e. be a multiple of 1< I agree it's likely that one codec (e.g. h264) would need 32-byte alignment on a particular system (e.g. x86/haswell), whereas another codec on the same system (e.g. wmavoice) might not. However, I find it unlikely that one codec *instance* would need different alignment from another codec *instance* (for the same codec). I can imagine a case where alignment requirements are dependant on pixel format. Not the best example, because it is not a "codec", and it is using bitpacked formats, but the Decklink output device would require 128 byte or even 256 byte alignment for 10/12 bit, according to the SDK. Regards, Marton ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] libavcodec/h264_sei: Don't log random user data.
On 5/6/2017 1:37 PM, Michael Niedermayer wrote: > On Fri, May 05, 2017 at 09:30:54PM +, Kieran Kunhya wrote: >> From d43c0366d4ba128772dc7909152f4e9635f269cb Mon Sep 17 00:00:00 2001 >> From: Kieran Kunhya >> Date: Fri, 5 May 2017 14:29:59 -0700 >> Subject: [PATCH] libavcodec/h264_sei: Don't log random user data. This >> prevents terminal junk. >> >> --- >> libavcodec/h264_sei.c | 3 --- >> 1 file changed, 3 deletions(-) >> >> diff --git a/libavcodec/h264_sei.c b/libavcodec/h264_sei.c >> index a7e627eba3..c81ddfef4f 100644 >> --- a/libavcodec/h264_sei.c >> +++ b/libavcodec/h264_sei.c >> @@ -257,9 +257,6 @@ static int >> decode_unregistered_user_data(H264SEIUnregistered *h, GetBitContext * >> if (e == 1 && build == 1 && !strncmp(user_data+16, "x264 - core ", >> 16)) >> h->x264_build = 67; >> >> -if (strlen(user_data + 16) > 0) >> -av_log(logctx, AV_LOG_DEBUG, "user data:\"%s\"\n", user_data + 16); > > This is just at debug level. > Do you have an example (file/usecase) where this causes excessive > output ? It's not so much the amount to be printed as it's about not printing random binary data. x264 is no the only encoder that writes this SEI, and other encoders dump binary data in it. This can trash the terminal displaying the log message. The amount also matters, but that's solved by making sure strlen(user_data + 16) is a sane value. The proper change here would be to look at the uuid and print only those known to store printable strings, and of course after making sure they are in fact printable. As of now, that means x264's uuid only. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avfilter: align data frame when needed
On Sat, May 6, 2017 at 6:35 PM, Nicolas George wrote: > Le septidi 17 floréal, an CCXXV, Muhammad Faiz a écrit : >> - fix framequeue (this patch). > > Once again, this patch is not correct. In particular it is NOT ENOUGH > to fix the crash in all cases. > It is enough to restore the situation to the previous status before the avfilter changes, which in the short term would fix a regression. We can work on a more complete solution, but this particular regression needs to be resolved in a simple manner capable of easy backporting. - Hendrik ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 2/3] lavc: add a framework to fix alignment problems.
Le septidi 17 floréal, an CCXXV, Ronald S. Bultje a écrit : > I agree it's likely that one codec (e.g. h264) would need 32-byte alignment > on a particular system (e.g. x86/haswell), whereas another codec on the > same system (e.g. wmavoice) might not. > > However, I find it unlikely that one codec *instance* would need different > alignment from another codec *instance* (for the same codec). The above > allows seems specifically designed for that. Do you think adding alignment > to AVCodec would make more sense (and possibly set it at runtime using > static_init)? I think Marton's mail gives a reasonable example. As for me, I do not know exactly what is needed, this is one of the reason I did not want to draft the proposal myself. This way seemed more future-proof, but it can be discussed. Also, I thought our AVCodec structure were const, so putting the field there would have been incompatible with run-time CPU detection, but apparently I was wrong. Still, I do not think codecs are supposed to modify it. Regards, -- Nicolas George signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/3] lavu/frame: add av_frame_realign().
Le septidi 17 floréal, an CCXXV, Muhammad Faiz a écrit : > As far as I know. No new features can go to release branch. > Or maybe I'm wrong. As I said, if this is the only issue, then it is not: just copy-paste av_frame_realign() at the two places where it will be needed and make it static. But really, I do not care much what happens in releases. I will fight to the end to prevent short-term workarounds to be introduced in the master branch when a correct fix is so easy, but for the releases branches, do what you want. Only do not expect my help for the ugly way. Regards, -- Nicolas George signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] libavformat/hls: Observe Set-Cookie headers
On 2017-05-05 09:28 PM, wm4 wrote:
On Fri, 5 May 2017 20:55:05 -0400
Micah Galizia wrote:
Signed-off-by: Micah Galizia
---
libavformat/hls.c | 12 ++--
1 file changed, 10 insertions(+), 2 deletions(-)
diff --git a/libavformat/hls.c b/libavformat/hls.c
index bac53a4350..bda9abecfa 100644
--- a/libavformat/hls.c
+++ b/libavformat/hls.c
@@ -630,8 +630,16 @@ static int open_url(AVFormatContext *s, AVIOContext **pb,
const char *url,
ret = s->io_open(s, pb, url, AVIO_FLAG_READ, &tmp);
if (ret >= 0) {
// update cookies on http response with setcookies.
-void *u = (s->flags & AVFMT_FLAG_CUSTOM_IO) ? NULL : s->pb;
-update_options(&c->cookies, "cookies", u);
+char *new_cookies = NULL;
+
+if (s->flags ^ AVFMT_FLAG_CUSTOM_IO)
+av_opt_get(*pb, "cookies", AV_OPT_SEARCH_CHILDREN,
(uint8_t**)&new_cookies);
Did you mean & instead of ^?
No, the original code was structured to set *u to null (and thus did not
copy cookies) iff AVFMT_FLAG_CUSTOM_IO was set in the flags. So using ^
is logically equivalent -- cookies are copied only if
AVFMT_FLAG_CUSTOM_IO is not set.
Did you find out yet what difference AVFMT_FLAG_CUSTOM_IO is supposed
to make in the existing code?
Yes, I wrote back about it a day or two ago... here is the reference to
its original inclusion:
https://lists.ffmpeg.org/pipermail/ffmpeg-trac/2013-February/013020.html.
When the code was originally implemented we were using s->pb->opaque,
which in FFMPEG we could assume was a URLContext with options (one of
them possibly being "cookies").
Based on the email above, that wasn't true for other apps like mplayer,
and could cause crashes trying to treat opaque as a URLContext. So that
is the purpose of checking the AVFMT_FLAG_CUSTOM_IO flag (way back in 2013).
Now though, we don't seem to touch opaque at all. The options are stored
in AVIOContext's av_class, which does have options. Based on this I
think both patches are safe: this version has less change, but the
original gets rid of the check against AVFMT_FLAG_CUSTOM_IO that I don't
think we need anymore.
I hope that clears things up.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avfilter: align data frame when needed
On 5/5/2017 2:23 PM, Nicolas George wrote: > Le sextidi 16 floréal, an CCXXV, James Almer a écrit : >> stuff you broke > > Please stop spreading wm4's lies. The bug was already there. > > Regards, > Take a look at https://trac.ffmpeg.org/ticket/6346. That ticket reported a regression in concatdec, where some file started to segfault where it didn't before. A bisect showed the commit that started this was a commit made by myself, even if mostly authored by someone else. That commit was not the cause of the problem, but the one that exposed the underlying bug, as i stated in that ticket. You know what the underlying bug was? The autobsf feature in concatdec was broken by *you* in commits 0cb19c30c6 and b8fa374fb6 (see https://ffmpeg.org/pipermail/ffmpeg-devel/2017-April/210639.html). Now, what was my reaction? I worked around the issue to restore the original behavior. I didn't try to coerce you into fixing what you broke a year ago. I worked around what you broke and i unknowingly exposed, for immediate backporting purposes. Eventually i did go and fixed the underlying bug, as mentioned in the last comment from the ticket, but that's not important here. So, my point? Even if you didn't cause the underlying alignment issue, you exposed it and created a regression. Either work around it yourself, or help others trying to do it for you. Have the decency of not blocking every attempt others give at it. You're right that the real fix needs to go deeper, but that requires a design discussion, and the crashes in release/3.3 can't wait. They need an immediate, and able to backport solution. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 2/3] lavc: add a framework to fix alignment problems.
Le septidi 17 floréal, an CCXXV, Hendrik Leppkes a écrit : > I don't think this is very practical. We have a bunch of generic DSPs > and if a codec uses those it would need to be constantly updated if > the requirements of those DSPs change. Today it may only use SSE and > be happy with 16-byte alignment, but what if someone adds an AVX2 > implementation, or AVX512? Well, exactly: pray tell me, with your design what happens when Intel adds AVX512? I will tell you what happens: applications will have been written for 32-octets alignment, and as soon as their libavcodec is updated, the crashes will start. > Going through all codecs that use some DSP and somehow set their > alignment value seems rather unfortunate - and on top of that, it'll > add arch-specific conditions, which leads to a lot of unnecessary > changes to a bunch of encoders (and filters) over time. The way I see it, the functions that are used to init the DSP should return the required alignment. That will require a little change since they do not take an AVCodecContext argument, but only trivial and mechanical changes, so even if hundreds of files were touched it is really not an issue. Of course, setting a high default value by default is a possible short-term solution, especially in the branches. > Right now the general consensus is that frames (and stride) should be > aligned to the maximum your CPU might require, ie. 32 byte on a AVX2 > CPU, even if this is not documented. It may have been the consensus for people who work on the vectorized implementations, but not the general consensus, especially for people who work on user-facing API. > I think it would be far better to officially document this. Making > applications aware of the alignment (which they likely are already > anyway, otherwise they would crash, even if they had to learn the hard > way) can make the entire process more efficient, since re-aligning can > be extremely expensive (ie. high res video) and should be avoided at > all cost if possible (which it not always is when you crop, for > example). Encouraging the applications to be aware of the issue for performances reasons is a good thing. Forcing them to do so when it is not convenient, on pain of crash, when it can be done for them just as easily, not so much. > There is no particular reason we can't make the framework check the > alignment and re-align if required to the maximum CPU value (with a > loud warning, perhaps), but I don't think a per-codec or per-filter > alignment value is very practical. If the framework does the realigning, doing it per-codec or per-filter is almost free. And someone really smart said that "since re-aligning can be extremely expensive" it "should be avoided at all cost if possible", doing the realigning only if the codecs needs it is really the right thing to do. Regards, -- Nicolas George signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avdevice/alsa: wait until playback buffers are drained before closing
Le septidi 17 floréal, an CCXXV, Takayuki 'January June' Suwa a écrit :
> This fixes early abort on ALSA playback
>
> ---
> libavdevice/alsa.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/libavdevice/alsa.c b/libavdevice/alsa.c
> index 8d27913..1bbff30 100644
> --- a/libavdevice/alsa.c
> +++ b/libavdevice/alsa.c
> @@ -300,6 +300,8 @@ av_cold int ff_alsa_close(AVFormatContext *s1)
> {
> AlsaData *s = s1->priv_data;
>
> +snd_pcm_nonblock(s->h, 0);
> +snd_pcm_drain(s->h);
> av_freep(&s->reorder_buf);
> if (CONFIG_ALSA_INDEV)
> ff_timefilter_destroy(s->timefilter);
I guess I it ok. There are no provisions for non-blocking close for now.
I do not officially maintain the ALSA code, though.
Regards,
--
Nicolas George
signature.asc
Description: Digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] ffmpeg: check for unconnected outputs
On 5/2/2017 8:06 PM, wm4 wrote: > Fixes e.g.: > > ffmpeg -f lavfi -i testsrc -f lavfi -i testsrc -filter_complex > "[0:v][1:v]psnr[out]" -f null none This should be backported to release/3.3 before 3.3.1 is tagged. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avfilter: add arbitrary audio FIR filter
On 5/6/17, Muhammad Faiz wrote: > On Sat, May 6, 2017 at 2:33 AM, Paul B Mahol wrote: >> On 5/5/17, Muhammad Faiz wrote: >> Is pts handled correctly here? Seem it is not derived from input pts. >> > > It can not be derived in any other way. Probably, at least, first pts should be derived from input pts. Also, is time_base always 1/sample_rate? Thank's. >>> >>> Probably, like in asetnsamples filter. >> >> Done. Have an idea where artifacst come out for some IRs? > > I have no idea what's wrong here? I currently don't understand > partitioned convolution. > > My test case: > ./ffplay -f lavfi "aevalsrc='if(lt(t,1), if(n,0,1), sin(1000*t*t))', > aformat= channel_layouts=mono, asplit [afir_in0], firequalizer= > zero_phase=on:gain_entry='entry(0, 0); entry(100, -4); entry(1000, > -30); entry(5000, -50); entry(6000, -10); entry(1, -5)', aformat= > channel_layouts=mono,a > split [merge1], atrim= end_sample=883 [afir_in1]; [afir_in0][afir_in1] > afir, aformat=channel_layouts=mono, [merge1] amerge, > asplit[out0],showspectrum=s=1024x512[out1]" > > Note that your old patch didn't generate artifact. Artifacts are gone if you use bigger IR size, >2048. UPOLS should be rather trivial to understand and to implement. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] avcodec/aacdec_fixed: Fix various integer overflows
Fixes: 1377/clusterfuzz-testcase-minimized-5487049807233024
Found-by: continuous fuzzing process
https://github.com/google/oss-fuzz/tree/master/targets/ffmpeg
Signed-off-by: Michael Niedermayer
---
libavcodec/aacdec_fixed.c| 2 +-
libavcodec/aacdec_template.c | 4 ++--
libavcodec/sbrdsp_fixed.c| 28 +++-
3 files changed, 18 insertions(+), 16 deletions(-)
diff --git a/libavcodec/aacdec_fixed.c b/libavcodec/aacdec_fixed.c
index acb8178337..e3c68a9767 100644
--- a/libavcodec/aacdec_fixed.c
+++ b/libavcodec/aacdec_fixed.c
@@ -180,7 +180,7 @@ static void subband_scale(int *dst, int *src, int scale,
int offset, int len)
}
else {
s = s + 32;
-round = 1 << (s-1);
+round = 1U << (s-1);
for (i=0; i> s);
dst[i] = out * ssign;
diff --git a/libavcodec/aacdec_template.c b/libavcodec/aacdec_template.c
index 98a3240597..ae9baeee01 100644
--- a/libavcodec/aacdec_template.c
+++ b/libavcodec/aacdec_template.c
@@ -2792,9 +2792,9 @@ static void spectral_to_sample(AACContext *ac, int
samples)
int j;
/* preparation for resampler */
for(j = 0; jch[0].ret[j] =
(int32_t)av_clipl_int32((int64_t)che->ch[0].ret[j]<<7)+0x8000;
+che->ch[0].ret[j] =
(int32_t)av_clip64((int64_t)che->ch[0].ret[j]<<7, INT32_MIN,
INT32_MAX-0x8000)+0x8000;
if(type == TYPE_CPE)
-che->ch[1].ret[j] =
(int32_t)av_clipl_int32((int64_t)che->ch[1].ret[j]<<7)+0x8000;
+che->ch[1].ret[j] =
(int32_t)av_clip64((int64_t)che->ch[1].ret[j]<<7, INT32_MIN,
INT32_MAX-0x8000)+0x8000;
}
}
#endif /* USE_FIXED */
diff --git a/libavcodec/sbrdsp_fixed.c b/libavcodec/sbrdsp_fixed.c
index f4e3de0c71..fb9aba4e8d 100644
--- a/libavcodec/sbrdsp_fixed.c
+++ b/libavcodec/sbrdsp_fixed.c
@@ -34,8 +34,9 @@
static SoftFloat sbr_sum_square_c(int (*x)[2], int n)
{
SoftFloat ret;
-int64_t accu = 0;
-int i, nz, round;
+uint64_t accu = 0, round;
+int i, nz;
+unsigned u;
for (i = 0; i < n; i += 2) {
// Larger values are inavlid and could cause overflows of accu.
@@ -49,22 +50,22 @@ static SoftFloat sbr_sum_square_c(int (*x)[2], int n)
accu += (int64_t)x[i + 1][1] * x[i + 1][1];
}
-i = (int)(accu >> 32);
-if (i == 0) {
+u = accu >> 32;
+if (u == 0) {
nz = 1;
} else {
-nz = 0;
-while (FFABS(i) < 0x4000) {
-i <<= 1;
+nz = -1;
+while (u < 0x8000U) {
+u <<= 1;
nz++;
}
nz = 32 - nz;
}
-round = 1 << (nz-1);
-i = (int)((accu + round) >> nz);
-i >>= 1;
-ret = av_int2sf(i, 15 - nz);
+round = 1ULL << (nz-1);
+u = ((accu + round) >> nz);
+u >>= 1;
+ret = av_int2sf(u, 15 - nz);
return ret;
}
@@ -107,7 +108,8 @@ static void sbr_qmf_deint_neg_c(int *v, const int *src)
static av_always_inline SoftFloat autocorr_calc(int64_t accu)
{
-int nz, mant, expo, round;
+int nz, mant, expo;
+unsigned round;
int i = (int)(accu >> 32);
if (i == 0) {
nz = 1;
@@ -120,7 +122,7 @@ static av_always_inline SoftFloat autocorr_calc(int64_t
accu)
nz = 32-nz;
}
-round = 1 << (nz-1);
+round = 1U << (nz-1);
mant = (int)((accu + round) >> nz);
mant = (mant + 0x40)>>7;
mant <<= 6;
--
2.11.0
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] Fixed memory leaks associated with AVStream objects if FF_API_LAVF_AVCTX is defined
On 4/21/2017 3:30 AM, Aaron Levinson wrote: > From 4f27e910aca6dae6642b4d73cf07fa0d6c4b1618 Mon Sep 17 00:00:00 2001 > From: Aaron Levinson > Date: Thu, 20 Apr 2017 23:20:20 -0700 > Subject: [PATCH] Fixed memory leaks associated with AVStream objects if > FF_API_LAVF_AVCTX is defined > > Purpose: Fixed memory leaks associated with AVStream objects if > FF_API_LAVF_AVCTX is defined. If FF_API_LAVF_AVCTX is defined, > AVStream::codec is set to an AVCodecContext object, and this wasn't > being deallocated properly when the AVStream object was freed. While > FF_API_LAVF_AVCTX has to do with deprecated functionality, in > practice, it will always be defined for typical builds currently, > since it is defined in libavformat\version.h if > LIBAVFORMAT_VERSION_MAJOR is less than 58, and > LIBAVFORMAT_VERSION_MAJOR is currently set to 57. > > Comments: > > -- libavformat/utils.c: Now using avcodec_free_context() to properly >deallocate st->codec in free_stream() if FF_API_LAVF_AVCTX is >defined. > --- > libavformat/utils.c | 4 +--- > 1 file changed, 1 insertion(+), 3 deletions(-) > > diff --git a/libavformat/utils.c b/libavformat/utils.c > index ba82a76..fbd8b58 100644 > --- a/libavformat/utils.c > +++ b/libavformat/utils.c > @@ -4266,9 +4266,7 @@ static void free_stream(AVStream **pst) > av_freep(&st->index_entries); > #if FF_API_LAVF_AVCTX > FF_DISABLE_DEPRECATION_WARNINGS > -av_freep(&st->codec->extradata); > -av_freep(&st->codec->subtitle_header); > -av_freep(&st->codec); > +avcodec_free_context(&st->codec); > FF_ENABLE_DEPRECATION_WARNINGS > #endif > av_freep(&st->priv_data); Simplified the commit subject and applied, thanks. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] build: remove --enable-raise-major configure option
It's not used by anything, has dubious usefulness, the reasons for which
it was introduced are no longer valid, and only serves to add complexity
to the build system.
Signed-off-by: James Almer
---
Makefile | 6 --
configure | 2 --
ffbuild/library.mak | 2 +-
ffbuild/libversion.sh | 2 --
4 files changed, 1 insertion(+), 11 deletions(-)
diff --git a/Makefile b/Makefile
index d414cf841e..d177311262 100644
--- a/Makefile
+++ b/Makefile
@@ -107,12 +107,6 @@ $(1) :=
$(1)-yes :=
endef
-ifdef CONFIG_RAISE_MAJOR
-RAISE_MAJOR = 100
-else
-RAISE_MAJOR = 0
-endif
-
define DOSUBDIR
$(foreach V,$(SUBDIR_VARS),$(eval $(call RESET,$(V
SUBDIR := $(1)/
diff --git a/configure b/configure
index b76f9ce567..e28f27a739 100755
--- a/configure
+++ b/configure
@@ -109,7 +109,6 @@ Configuration options:
--enable-grayenable full grayscale support (slower color)
--disable-swscale-alpha disable alpha channel support in swscale
--disable-alldisable building components, libraries and programs
- --enable-raise-major increase major version numbers in sonames [no]
Program options:
--disable-programs do not build command line programs
@@ -1686,7 +1685,6 @@ CONFIG_LIST="
neon_clobber_test
ossfuzz
pic
-raise_major
thumb
valgrind_backtrace
xmm_clobber_test
diff --git a/ffbuild/library.mak b/ffbuild/library.mak
index cfc2d36067..22f1e4c37f 100644
--- a/ffbuild/library.mak
+++ b/ffbuild/library.mak
@@ -34,7 +34,7 @@ $(TESTPROGS) $(TOOLS): %$(EXESUF): %.o
$$(LD) $(LDFLAGS) $(LDEXEFLAGS) $$(LD_O) $$(filter %.o,$$^) $$(THISLIB)
$(FFEXTRALIBS) $$(ELIBS)
$(SUBDIR)lib$(NAME).version: $(SUBDIR)version.h | $(SUBDIR)
- $$(M) $$(SRC_PATH)/ffbuild/libversion.sh $(NAME) $$< $(RAISE_MAJOR) >
$$@
+ $$(M) $$(SRC_PATH)/ffbuild/libversion.sh $(NAME) $$< > $$@
$(SUBDIR)lib$(FULLNAME).pc: $(SUBDIR)version.h | $(SUBDIR)
$$(M) $$(SRC_PATH)/ffbuild/pkgconfig_generate.sh $(NAME) "$(DESC)"
diff --git a/ffbuild/libversion.sh b/ffbuild/libversion.sh
index 687adf28bc..990ce9f640 100755
--- a/ffbuild/libversion.sh
+++ b/ffbuild/libversion.sh
@@ -5,10 +5,8 @@ toupper(){
name=lib$1
ucname=$(toupper ${name})
file=$2
-raise_major=$3
eval $(awk "/#define ${ucname}_VERSION_M/ { print \$2 \"=\" \$3 }" "$file")
-eval ${ucname}_VERSION_MAJOR=$((${ucname}_VERSION_MAJOR+${raise_major}))
eval
${ucname}_VERSION=\$${ucname}_VERSION_MAJOR.\$${ucname}_VERSION_MINOR.\$${ucname}_VERSION_MICRO
eval echo "${name}_VERSION=\$${ucname}_VERSION"
eval echo "${name}_VERSION_MAJOR=\$${ucname}_VERSION_MAJOR"
--
2.12.1
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] rtmpproto: send swfverify value as swfurl if latter is unused
On Sat, May 06, 2017 at 01:13:41PM +0100, Ricardo Constantino wrote: > Third ping. > > This patch is trivial, and makes behavior of librtmp and ffrtmp consistent > when using rtmp_swfverify. > > What's blocking this? lack of maintainer for this code If you would be interrested in maintaining this, dont hesitate to suggest it and or send a patch that adds you to the MAINTAINERs file [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB There will always be a question for which you do not know the correct answer. signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] rtmpproto: send swfverify value as swfurl if latter is unused
On 6 May 2017 at 23:05, Michael Niedermayer wrote: > On Sat, May 06, 2017 at 01:13:41PM +0100, Ricardo Constantino wrote: > > Third ping. > > > > This patch is trivial, and makes behavior of librtmp and ffrtmp > consistent > > when using rtmp_swfverify. > > > > What's blocking this? > > lack of maintainer for this code > > If you would be interrested in maintaining this, dont hesitate to > suggest it and or send a patch that adds you to the > MAINTAINERs file > I wouldn't feel comfortable with such responsability. FWIW, Martin Storjö accepted the same patch in Libav: https://git.libav.org/?p=libav.git;a=commit;h=d4f3c26b700ae847433ba3c67dc99c32bc1fd4a1 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avfilter: add arbitrary audio FIR filter
On Sun, May 7, 2017 at 2:49 AM, Paul B Mahol wrote: > On 5/6/17, Muhammad Faiz wrote: >> On Sat, May 6, 2017 at 2:33 AM, Paul B Mahol wrote: >>> On 5/5/17, Muhammad Faiz wrote: >>> Is pts handled correctly here? Seem it is not derived from input pts. >>> >> >> It can not be derived in any other way. > > Probably, at least, first pts should be derived from input pts. > Also, is time_base always 1/sample_rate? > > Thank's. Probably, like in asetnsamples filter. >>> >>> Done. Have an idea where artifacst come out for some IRs? >> >> I have no idea what's wrong here? I currently don't understand >> partitioned convolution. >> >> My test case: >> ./ffplay -f lavfi "aevalsrc='if(lt(t,1), if(n,0,1), sin(1000*t*t))', >> aformat= channel_layouts=mono, asplit [afir_in0], firequalizer= >> zero_phase=on:gain_entry='entry(0, 0); entry(100, -4); entry(1000, >> -30); entry(5000, -50); entry(6000, -10); entry(1, -5)', aformat= >> channel_layouts=mono,a >> split [merge1], atrim= end_sample=883 [afir_in1]; [afir_in0][afir_in1] >> afir, aformat=channel_layouts=mono, [merge1] amerge, >> asplit[out0],showspectrum=s=1024x512[out1]" >> >> Note that your old patch didn't generate artifact. > > Artifacts are gone if you use bigger IR size, >2048. > > UPOLS should be rather trivial to understand and to implement. Still happens at 8821 (44100 Hz with 0.1s delay): ./ffplay -f lavfi "aevalsrc='if(lt(t,1), if(n,0,1), sin(1000*t*t))', aformat=channel_layouts=mono, asplit [afir_in0], fir equalizer=zero_phase=on:gain_entry='entry(0, 0); entry(100, -4); entry(1000, -30); entry(5000, -50); entry(6000, -10); entry(1, -5)':delay=0.1, aformat=channel_layo uts=mono,asplit [merge1], atrim=end_sample=8821 [afir_in1]; [afir_in0][afir_in1] afir, aformat=channel_layouts=mono, [merge1] amerge, asplit[out0],showspectrum=s=1024x5 12[out1]" ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] rtmpproto: send swfverify value as swfurl if latter is unused
On Sat, May 06, 2017 at 11:13:10PM +0100, Ricardo Constantino wrote: > On 6 May 2017 at 23:05, Michael Niedermayer wrote: > > > On Sat, May 06, 2017 at 01:13:41PM +0100, Ricardo Constantino wrote: > > > Third ping. > > > > > > This patch is trivial, and makes behavior of librtmp and ffrtmp > > consistent > > > when using rtmp_swfverify. > > > > > > What's blocking this? > > > > lack of maintainer for this code > > > > If you would be interrested in maintaining this, dont hesitate to > > suggest it and or send a patch that adds you to the > > MAINTAINERs file > > > > > I wouldn't feel comfortable with such responsability. ok patch applied > FWIW, Martin Storjö accepted the same patch in Libav: > https://git.libav.org/?p=libav.git;a=commit;h=d4f3c26b700ae847433ba3c67dc99c32bc1fd4a1 > ___ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Frequently ignored answer#1 FFmpeg bugs should be sent to our bugtracker. User questions about the command line tools should be sent to the ffmpeg-user ML. And questions about how to use libav* should be sent to the libav-user ML. signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avdevice/alsa: wait until playback buffers are drained before closing
On Sat, May 06, 2017 at 08:40:46PM +0200, Nicolas George wrote:
> Le septidi 17 floréal, an CCXXV, Takayuki 'January June' Suwa a écrit :
> > This fixes early abort on ALSA playback
> >
> > ---
> > libavdevice/alsa.c | 2 ++
> > 1 file changed, 2 insertions(+)
> >
> > diff --git a/libavdevice/alsa.c b/libavdevice/alsa.c
> > index 8d27913..1bbff30 100644
> > --- a/libavdevice/alsa.c
> > +++ b/libavdevice/alsa.c
> > @@ -300,6 +300,8 @@ av_cold int ff_alsa_close(AVFormatContext *s1)
> > {
> > AlsaData *s = s1->priv_data;
> >
> > +snd_pcm_nonblock(s->h, 0);
> > +snd_pcm_drain(s->h);
> > av_freep(&s->reorder_buf);
> > if (CONFIG_ALSA_INDEV)
> > ff_timefilter_destroy(s->timefilter);
>
> I guess I it ok. There are no provisions for non-blocking close for now.
> I do not officially maintain the ALSA code, though.
but you looked at the code and noone is listed in MAINTAINERs for it
applied
thanks to all
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
Take away the freedom of one citizen and you will be jailed, take away
the freedom of all citizens and you will be congratulated by your peers
in Parliament.
signature.asc
Description: Digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avfilter: add arbitrary audio FIR filter
On Sat, May 6, 2017 at 2:30 AM, Paul B Mahol wrote:
> Signed-off-by: Paul B Mahol
> ---
> configure| 2 +
> doc/filters.texi | 10 +
> libavfilter/Makefile | 1 +
> libavfilter/af_afir.c| 484
> +++
> libavfilter/allfilters.c | 1 +
> 5 files changed, 498 insertions(+)
> create mode 100644 libavfilter/af_afir.c
>
> diff --git a/configure b/configure
> index b3cb5b0..0d83c6a 100755
> --- a/configure
> +++ b/configure
> @@ -3078,6 +3078,8 @@ unix_protocol_select="network"
> # filters
> afftfilt_filter_deps="avcodec"
> afftfilt_filter_select="fft"
> +afir_filter_deps="avcodec"
> +afir_filter_select="fft"
> amovie_filter_deps="avcodec avformat"
> aresample_filter_deps="swresample"
> ass_filter_deps="libass"
> diff --git a/doc/filters.texi b/doc/filters.texi
> index 119e747..ea343d1 100644
> --- a/doc/filters.texi
> +++ b/doc/filters.texi
> @@ -878,6 +878,16 @@ afftfilt="1-clip((b/nb)*b,0,1)"
> @end example
> @end itemize
>
> +@section afirfilter
> +
> +Apply an Arbitary Frequency Impulse Response filter.
> +
> +This filter uses second stream as FIR coefficients.
> +If second stream holds single channel, it will be used
> +for all input channels in first stream, otherwise
> +number of channels in second stream must be same as
> +number of channels in first stream.
> +
> @anchor{aformat}
> @section aformat
>
> diff --git a/libavfilter/Makefile b/libavfilter/Makefile
> index 66c36e4..c797eb5 100644
> --- a/libavfilter/Makefile
> +++ b/libavfilter/Makefile
> @@ -38,6 +38,7 @@ OBJS-$(CONFIG_AEMPHASIS_FILTER) +=
> af_aemphasis.o
> OBJS-$(CONFIG_AEVAL_FILTER) += aeval.o
> OBJS-$(CONFIG_AFADE_FILTER) += af_afade.o
> OBJS-$(CONFIG_AFFTFILT_FILTER) += af_afftfilt.o window_func.o
> +OBJS-$(CONFIG_AFIR_FILTER) += af_afir.o
> OBJS-$(CONFIG_AFORMAT_FILTER)+= af_aformat.o
> OBJS-$(CONFIG_AGATE_FILTER) += af_agate.o
> OBJS-$(CONFIG_AINTERLEAVE_FILTER)+= f_interleave.o
> diff --git a/libavfilter/af_afir.c b/libavfilter/af_afir.c
> new file mode 100644
> index 000..9411c9b
> --- /dev/null
> +++ b/libavfilter/af_afir.c
> @@ -0,0 +1,484 @@
> +/*
> + * Copyright (c) 2017 Paul B Mahol
> + *
> + * This file is part of FFmpeg.
> + *
> + * FFmpeg is free software; you can redistribute it and/or
> + * modify it under the terms of the GNU Lesser General Public
> + * License as published by the Free Software Foundation; either
> + * version 2.1 of the License, or (at your option) any later version.
> + *
> + * FFmpeg is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
> + * Lesser General Public License for more details.
> + *
> + * You should have received a copy of the GNU Lesser General Public
> + * License along with FFmpeg; if not, write to the Free Software
> + * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301
> USA
> + */
> +
> +/**
> + * @file
> + * An arbitrary audio FIR filter
> + */
> +
> +#include "libavutil/audio_fifo.h"
> +#include "libavutil/common.h"
> +#include "libavutil/opt.h"
> +#include "libavcodec/avfft.h"
> +
> +#include "audio.h"
> +#include "avfilter.h"
> +#include "formats.h"
> +#include "internal.h"
> +
> +#define MAX_IR_DURATION 20
> +
> +typedef struct FIRContext {
> +const AVClass *class;
> +
> +float wet_gain;
> +float dry_gain;
> +int auto_gain;
> +
> +float gain;
> +
> +int eof_coeffs;
> +int have_coeffs;
> +int nb_coeffs;
> +int nb_taps;
> +int part_size;
> +int nb_partitions;
> +int fft_length;
> +int nb_channels;
> +int nb_coef_channels;
> +int one2many;
> +int nb_samples;
> +
> +RDFTContext **rdft, **irdft;
> +float **sum;
> +float **block;
> +FFTComplex **coeff;
> +
> +AVAudioFifo *fifo[2];
> +AVFrame *in[2];
> +AVFrame *buffer;
> +int64_t pts;
> +} FIRContext;
> +
> +static int fir_channel(AVFilterContext *ctx, void *arg, int ch, int nb_jobs)
> +{
> +FIRContext *s = ctx->priv;
> +AVFrame *out = arg;
> +const FFTComplex *coeff = s->coeff[ch * !s->one2many];
> +const float *src = (const float *)s->in[0]->extended_data[ch];
> +float *dst = (float *)out->extended_data[ch];
> +float *buf = (float *)s->buffer->extended_data[ch];
> +float *sum = s->sum[ch];
> +float *block = s->block[ch];
> +int n, i;
> +
> +memset(sum, 0, sizeof(*sum) * 2 * (s->part_size + 1));
> +memset(block, 0, sizeof(*block) * 2 * (s->part_size + 1));
> +for (n = 0; n < s->nb_samples; n++) {
> +block[n] = src[n] * s->dry_gain;
> +}
> +
> +av_rdft_calc(s->rdft[ch], block);
> +block[s->part_size / 2] = block[1];
block[s->part_size * 2]
> +block[1] = 0;
> +
> +for (i = 0; i
Re: [FFmpeg-devel] [PATCH v9] - Added Turing codec interface for ffmpeg
On Wed, May 03, 2017 at 09:29:14AM +, Saverio Blasi wrote:
> Dear Carl,
>
> Thanks for your email.
> Yes, I can confirm that the patch as it is generated with "git format-patch
> -1" passes the patcheck test without highlighting any trailing whitespaces.
> I can see though that the email that gets sent with "git send" has some new
> lines which are not in the original patch. For instance:
> + die "ERROR: libturing requires turing api
> +version 2 or greater."; }
>
> There is a new line between "api" and "version" which is not in the original
> patch file, which may lead to a trailing whitespace (after "api") in case the
> patch is generated copying and pasting the text from the email. I am not sure
> why these new lines are automatically generated and how to avoid that, would
> you be able to provide some help with this?
heres the output from patcheck:
not gcc 2.95 compatible
patcheck.stdout:197:+for(int option_idx=0;
option_idxoptions_added; option_idx++) {
x==0 / x!=0 can be simplified to !x / x
patcheck.stdout:166:+if(option_ctx->options == NULL) {
patcheck.stdout:168:+if(option_ctx->options == NULL) {
patcheck.stdout:173:+if (temp_ptr == NULL) {
patcheck.stdout:193:+if (option_ctx->argv == NULL) {
patcheck.stdout:369:+if (output->bitstream.size ==0) {
Possible security issue, make sure this is safe or use snprintf/av_strl*
patcheck.stdout:181:+strcpy(option_ctx->s, current_option);
missing whitespace between keyword and ( (feel free to ignore)
patcheck.stdout:166:+if(option_ctx->options == NULL) {
patcheck.stdout:168:+if(option_ctx->options == NULL) {
patcheck.stdout:197:+for(int option_idx=0;
option_idxoptions_added; option_idx++) {
Missing changelog entry (ignore if minor change)
not from patchchec but it looks like you assume error codes are positive
thx
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
Dictatorship: All citizens are under surveillance, all their steps and
actions recorded, for the politicians to enforce control.
Democracy: All politicians are under surveillance, all their steps and
actions recorded, for the citizens to enforce control.
signature.asc
Description: Digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] build: remove --enable-raise-major configure option
On 5/6/2017 2:59 PM, James Almer wrote:
It's not used by anything, has dubious usefulness, the reasons for which
it was introduced are no longer valid, and only serves to add complexity
to the build system.
Signed-off-by: James Almer
---
Makefile | 6 --
configure | 2 --
ffbuild/library.mak | 2 +-
ffbuild/libversion.sh | 2 --
4 files changed, 1 insertion(+), 11 deletions(-)
diff --git a/Makefile b/Makefile
index d414cf841e..d177311262 100644
--- a/Makefile
+++ b/Makefile
@@ -107,12 +107,6 @@ $(1) :=
$(1)-yes :=
endef
-ifdef CONFIG_RAISE_MAJOR
-RAISE_MAJOR = 100
-else
-RAISE_MAJOR = 0
-endif
-
define DOSUBDIR
$(foreach V,$(SUBDIR_VARS),$(eval $(call RESET,$(V
SUBDIR := $(1)/
diff --git a/configure b/configure
index b76f9ce567..e28f27a739 100755
--- a/configure
+++ b/configure
@@ -109,7 +109,6 @@ Configuration options:
--enable-grayenable full grayscale support (slower color)
--disable-swscale-alpha disable alpha channel support in swscale
--disable-alldisable building components, libraries and programs
- --enable-raise-major increase major version numbers in sonames [no]
Program options:
--disable-programs do not build command line programs
@@ -1686,7 +1685,6 @@ CONFIG_LIST="
neon_clobber_test
ossfuzz
pic
-raise_major
thumb
valgrind_backtrace
xmm_clobber_test
diff --git a/ffbuild/library.mak b/ffbuild/library.mak
index cfc2d36067..22f1e4c37f 100644
--- a/ffbuild/library.mak
+++ b/ffbuild/library.mak
@@ -34,7 +34,7 @@ $(TESTPROGS) $(TOOLS): %$(EXESUF): %.o
$$(LD) $(LDFLAGS) $(LDEXEFLAGS) $$(LD_O) $$(filter %.o,$$^) $$(THISLIB)
$(FFEXTRALIBS) $$(ELIBS)
$(SUBDIR)lib$(NAME).version: $(SUBDIR)version.h | $(SUBDIR)
- $$(M) $$(SRC_PATH)/ffbuild/libversion.sh $(NAME) $$< $(RAISE_MAJOR) >
$$@
+ $$(M) $$(SRC_PATH)/ffbuild/libversion.sh $(NAME) $$< > $$@
$(SUBDIR)lib$(FULLNAME).pc: $(SUBDIR)version.h | $(SUBDIR)
$$(M) $$(SRC_PATH)/ffbuild/pkgconfig_generate.sh $(NAME) "$(DESC)"
diff --git a/ffbuild/libversion.sh b/ffbuild/libversion.sh
index 687adf28bc..990ce9f640 100755
--- a/ffbuild/libversion.sh
+++ b/ffbuild/libversion.sh
@@ -5,10 +5,8 @@ toupper(){
name=lib$1
ucname=$(toupper ${name})
file=$2
-raise_major=$3
eval $(awk "/#define ${ucname}_VERSION_M/ { print \$2 \"=\" \$3 }" "$file")
-eval ${ucname}_VERSION_MAJOR=$((${ucname}_VERSION_MAJOR+${raise_major}))
eval
${ucname}_VERSION=\$${ucname}_VERSION_MAJOR.\$${ucname}_VERSION_MINOR.\$${ucname}_VERSION_MICRO
eval echo "${name}_VERSION=\$${ucname}_VERSION"
eval echo "${name}_VERSION_MAJOR=\$${ucname}_VERSION_MAJOR"
LGTM. However, it seems that some documentation needs to be updated as
well. In doc/developer.texi, it states: "Incrementing the third
component means a noteworthy binary compatible change (e.g. encoder bug
fix that matters for the decoder). The third component always starts at
100 to distinguish FFmpeg from Libav." Note that my review only covers
the content of the patch, and I don't know whether or not it makes sense
to discontinue this practice.
Aaron Levinson
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] build: remove --enable-raise-major configure option
On 5/6/2017 11:19 PM, Aaron Levinson wrote:
> On 5/6/2017 2:59 PM, James Almer wrote:
>> It's not used by anything, has dubious usefulness, the reasons for which
>> it was introduced are no longer valid, and only serves to add complexity
>> to the build system.
>>
>> Signed-off-by: James Almer
>> ---
>> Makefile | 6 --
>> configure | 2 --
>> ffbuild/library.mak | 2 +-
>> ffbuild/libversion.sh | 2 --
>> 4 files changed, 1 insertion(+), 11 deletions(-)
>>
>> diff --git a/Makefile b/Makefile
>> index d414cf841e..d177311262 100644
>> --- a/Makefile
>> +++ b/Makefile
>> @@ -107,12 +107,6 @@ $(1) :=
>> $(1)-yes :=
>> endef
>>
>> -ifdef CONFIG_RAISE_MAJOR
>> -RAISE_MAJOR = 100
>> -else
>> -RAISE_MAJOR = 0
>> -endif
>> -
>> define DOSUBDIR
>> $(foreach V,$(SUBDIR_VARS),$(eval $(call RESET,$(V
>> SUBDIR := $(1)/
>> diff --git a/configure b/configure
>> index b76f9ce567..e28f27a739 100755
>> --- a/configure
>> +++ b/configure
>> @@ -109,7 +109,6 @@ Configuration options:
>>--enable-grayenable full grayscale support (slower color)
>>--disable-swscale-alpha disable alpha channel support in swscale
>>--disable-alldisable building components, libraries and
>> programs
>> - --enable-raise-major increase major version numbers in sonames
>> [no]
>>
>> Program options:
>>--disable-programs do not build command line programs
>> @@ -1686,7 +1685,6 @@ CONFIG_LIST="
>> neon_clobber_test
>> ossfuzz
>> pic
>> -raise_major
>> thumb
>> valgrind_backtrace
>> xmm_clobber_test
>> diff --git a/ffbuild/library.mak b/ffbuild/library.mak
>> index cfc2d36067..22f1e4c37f 100644
>> --- a/ffbuild/library.mak
>> +++ b/ffbuild/library.mak
>> @@ -34,7 +34,7 @@ $(TESTPROGS) $(TOOLS): %$(EXESUF): %.o
>> $$(LD) $(LDFLAGS) $(LDEXEFLAGS) $$(LD_O) $$(filter %.o,$$^)
>> $$(THISLIB) $(FFEXTRALIBS) $$(ELIBS)
>>
>> $(SUBDIR)lib$(NAME).version: $(SUBDIR)version.h | $(SUBDIR)
>> -$$(M) $$(SRC_PATH)/ffbuild/libversion.sh $(NAME) $$<
>> $(RAISE_MAJOR) > $$@
>> +$$(M) $$(SRC_PATH)/ffbuild/libversion.sh $(NAME) $$< > $$@
>>
>> $(SUBDIR)lib$(FULLNAME).pc: $(SUBDIR)version.h | $(SUBDIR)
>> $$(M) $$(SRC_PATH)/ffbuild/pkgconfig_generate.sh $(NAME) "$(DESC)"
>> diff --git a/ffbuild/libversion.sh b/ffbuild/libversion.sh
>> index 687adf28bc..990ce9f640 100755
>> --- a/ffbuild/libversion.sh
>> +++ b/ffbuild/libversion.sh
>> @@ -5,10 +5,8 @@ toupper(){
>> name=lib$1
>> ucname=$(toupper ${name})
>> file=$2
>> -raise_major=$3
>>
>> eval $(awk "/#define ${ucname}_VERSION_M/ { print \$2 \"=\" \$3 }"
>> "$file")
>> -eval ${ucname}_VERSION_MAJOR=$((${ucname}_VERSION_MAJOR+${raise_major}))
>> eval
>> ${ucname}_VERSION=\$${ucname}_VERSION_MAJOR.\$${ucname}_VERSION_MINOR.\$${ucname}_VERSION_MICRO
>>
>> eval echo "${name}_VERSION=\$${ucname}_VERSION"
>> eval echo "${name}_VERSION_MAJOR=\$${ucname}_VERSION_MAJOR"
>>
>
> LGTM. However, it seems that some documentation needs to be updated as
> well. In doc/developer.texi, it states: "Incrementing the third
> component means a noteworthy binary compatible change (e.g. encoder bug
> fix that matters for the decoder). The third component always starts at
> 100 to distinguish FFmpeg from Libav." Note that my review only covers
> the content of the patch, and I don't know whether or not it makes sense
> to discontinue this practice.
That line has nothing to do with this option. It's talking about the
third component in a library version, that is, the micro version, and
applies to every build regardless of configure options.
Unlike minor versions which start at 0 and reset back to that after a
major bump, micro versions start at 100 and reset back to that as well
after a minor and/or major bump.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avfilter: align data frame when needed
On Sat, 6 May 2017 15:29:18 -0300 James Almer wrote: > On 5/5/2017 2:23 PM, Nicolas George wrote: > > Le sextidi 16 floréal, an CCXXV, James Almer a écrit : > >> stuff you broke > > > > Please stop spreading wm4's lies. The bug was already there. Oh, now he's accusing me of lying? Can we eject this guy from FFmpeg already? I see no reason why we should deal with his bullshit. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] videotoolbox: add hwcontext support
On Wed, 3 May 2017 05:26:04 +0200 wm4 wrote: > This adds tons of code for no other benefit than making VideoToolbox > support conform with the new hwaccel API (using hw_device_ctx and > hw_frames_ctx). > > Since VideoToolbox decoding does not actually require the user to > allocate frames, the new code does mostly nothing. > > One benefit is that ffmpeg_videotoolbox.c can be dropped once generic > hwaccel support for ffmpeg.c is merged from Libav. > > Does not consider VDA or VideoToolbox encoding. > > Fun fact: the frame transfer functions are copied from vaapi, as the > mapping makes copying generic boilerplate. Mapping itself is not > exported by the VT code, because I don't know how to test. > > TODO: API bumps > --- If nobody wants to review this, I'll push it on Monday or so. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
