Re: [FFmpeg-devel] [PATCH 2/2] avfilter: add sidechaingate filter
On 12/1/15, Ganesh Ajjanagadde wrote:
> On Sun, Nov 29, 2015 at 6:03 PM, Paul B Mahol wrote:
>> Signed-off-by: Paul B Mahol
>> ---
>> doc/filters.texi | 61 +
>> libavfilter/Makefile | 1 +
>> libavfilter/af_agate.c | 170
>> ++-
>> libavfilter/allfilters.c | 1 +
>> 4 files changed, 230 insertions(+), 3 deletions(-)
>>
>> diff --git a/doc/filters.texi b/doc/filters.texi
>> index 0395c7a..ed4a376 100644
>> --- a/doc/filters.texi
>> +++ b/doc/filters.texi
>> @@ -2531,6 +2531,67 @@ ffmpeg -i main.flac -i sidechain.flac
>> -filter_complex "[1:a]asplit=2[sc][mix];[0
>> @end example
>> @end itemize
>>
>> +@section sidechaingate
>> +
>> +A sidechain gate acts like a normal (wideband) gate but has the ability
>> to
>> +filter the detected signal before sending it to the gain reduction stage.
>> +Normally a gate uses the full range signal to detect a level above the
>> +threshold.
>> +For example: If you cut all lower frequencies from your sidechain signal
>> +the gate will decrease the volume of your track only if not enough highs
>> +appear. With this technique you are able to reduce the resonation of a
>> +natural drum or remove "rumbling" of muted strokes from a heavily
>> distorted
>> +guitar.
>> +It needs two input streams and returns one output stream.
>> +First input stream will be processed depending on second stream signal.
>> +
>> +The filter accepts the following options:
>> +
>> +@table @option
>> +@item level_in
>> +Set input level before filtering.
>> +Default is 1. Allowed range is from 0.015625 to 64.
>> +
>> +@item range
>> +Set the level of gain reduction when the signal is below the threshold.
>> +Default is 0.06125. Allowed range is from 0 to 1.
>> +
>> +@item threshold
>> +If a signal rises above this level the gain reduction is released.
>> +Default is 0.125. Allowed range is from 0 to 1.
>> +
>> +@item ratio
>> +Set a ratio about which the signal is reduced.
>> +Default is 2. Allowed range is from 1 to 9000.
>> +
>> +@item attack
>> +Amount of milliseconds the signal has to rise above the threshold before
>> gain
>> +reduction stops.
>> +Default is 20 milliseconds. Allowed range is from 0.01 to 9000.
>> +
>> +@item release
>> +Amount of milliseconds the signal has to fall below the threshold before
>> the
>> +reduction is increased again. Default is 250 milliseconds.
>> +Allowed range is from 0.01 to 9000.
>> +
>> +@item makeup
>> +Set amount of amplification of signal after processing.
>> +Default is 1. Allowed range is from 1 to 64.
>> +
>> +@item knee
>> +Curve the sharp knee around the threshold to enter gain reduction more
>> softly.
>> +Default is 2.828427125. Allowed range is from 1 to 8.
>> +
>> +@item detection
>> +Choose if exact signal should be taken for detection or an RMS like one.
>> +Default is peak. Can be peak or rms.
>> +
>> +@item link
>> +Choose if the average level between all channels or the louder channel
>> affects
>> +the reduction.
>> +Default is average. Can be average or maximum.
>> +@end table
>> +
>> @section silencedetect
>>
>> Detect silence in an audio stream.
>> diff --git a/libavfilter/Makefile b/libavfilter/Makefile
>> index e31bdaa..582fd0e 100644
>> --- a/libavfilter/Makefile
>> +++ b/libavfilter/Makefile
>> @@ -82,6 +82,7 @@ OBJS-$(CONFIG_REPLAYGAIN_FILTER) +=
>> af_replaygain.o
>> OBJS-$(CONFIG_RESAMPLE_FILTER) += af_resample.o
>> OBJS-$(CONFIG_RUBBERBAND_FILTER) += af_rubberband.o
>> OBJS-$(CONFIG_SIDECHAINCOMPRESS_FILTER) += af_sidechaincompress.o
>> +OBJS-$(CONFIG_SIDECHAINGATE_FILTER) += af_agate.o
>> OBJS-$(CONFIG_SILENCEDETECT_FILTER) += af_silencedetect.o
>> OBJS-$(CONFIG_SILENCEREMOVE_FILTER) += af_silenceremove.o
>> OBJS-$(CONFIG_STEREOTOOLS_FILTER)+= af_stereotools.o
>> diff --git a/libavfilter/af_agate.c b/libavfilter/af_agate.c
>> index d3f74fb..23e45c6 100644
>> --- a/libavfilter/af_agate.c
>> +++ b/libavfilter/af_agate.c
>> @@ -18,6 +18,12 @@
>> * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA
>> 02110-1301 USA
>> */
>>
>> +/**
>> + * @file
>> + * Audio (Sidechain) Gate filter
>> + */
>> +
>> +#include "libavutil/avassert.h"
>> #include "libavutil/channel_layout.h"
>> #include "libavutil/opt.h"
>> #include "avfilter.h"
>> @@ -46,12 +52,14 @@ typedef struct AudioGateContext {
>> double lin_slope;
>> double attack_coeff;
>> double release_coeff;
>> +
>> +AVFrame *input_frame[2];
>> } AudioGateContext;
>>
>> #define OFFSET(x) offsetof(AudioGateContext, x)
>> #define A AV_OPT_FLAG_AUDIO_PARAM|AV_OPT_FLAG_FILTERING_PARAM
>>
>> -static const AVOption agate_options[] = {
>> +static const AVOption options[] = {
>> { "level_in", "set input level",OFFSET(level_in),
>> AV_OPT_TYPE_DOUBLE, {.dbl=1}, 0.015625, 64, A },
>> { "range", "set max gain reduction", OFFSET(range),
>> AV_OPT_TYPE_DOUBLE, {.db
[FFmpeg-devel] Does FFplay support HEVC interlaced bitstream display?
Hi, everyone. I noticed that HEVC support interlaced field encoding, but FFplay didn't support HEVC interlaced bitstream display. We know FFplay play h264 interlaced bitstream perfectly. I'd like to know if FFplay support HEVC interlaced bitstream display. And will FFmpeg support that? Best Regards. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/7] lavf: add API to apply a list of bsfs to a packet
On Mon, Nov 30, 2015 at 18:05:25 -0600, Rodger Combs wrote: > libavformat/avformat.h | 11 +++ > libavformat/utils.c| 49 + > 2 files changed, 60 insertions(+) I would find it useful to have an informational message (at least in loglevel debug, perhaps even in loglevel default) about automatically inserted bitstream filters. OTOH (unrelated), currently, even explicitly inserted bitstream filters don't mention themselves in logs at all. Whereas, in loglevel debug, I can observe every implicit and explicit video/audio filter and its connections. Thanks for the patchset, BTW. I think it removes one of my biggest personal grudges against ffmpeg and its usage. ;-) (Untested, BTW.) Moritz ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] avfilter: add audio emphasis filter
Signed-off-by: Paul B Mahol
---
configure | 3 +
doc/filters.texi | 46 ++
libavfilter/Makefile | 1 +
libavfilter/af_aemphasis.c | 354 +
libavfilter/allfilters.c | 1 +
5 files changed, 405 insertions(+)
create mode 100644 libavfilter/af_aemphasis.c
diff --git a/configure b/configure
index a30d831..7f3d3de 100755
--- a/configure
+++ b/configure
@@ -1771,8 +1771,10 @@ INTRINSICS_LIST="
MATH_FUNCS="
atanf
atan2f
+cabs
cbrt
cbrtf
+cexp
copysign
cosf
erf
@@ -2785,6 +2787,7 @@ unix_protocol_deps="sys_un_h"
unix_protocol_select="network"
# filters
+aemphasis_filter_deps="cabs cexp"
amovie_filter_deps="avcodec avformat"
aresample_filter_deps="swresample"
ass_filter_deps="libass"
diff --git a/doc/filters.texi b/doc/filters.texi
index fc71a99..1303045 100644
--- a/doc/filters.texi
+++ b/doc/filters.texi
@@ -528,6 +528,52 @@ aecho=0.8:0.9:1000|1800:0.3|0.25
@end example
@end itemize
+@section aemphasis
+Audio emphasis filter creates or restores material directly taken from LPs or
+emphased CDs with different filter curves. E.g. to store music on vinyl the
+signal has to be altered by a filter first to even out the disadvantages of
+this recording medium.
+Once the material is played back the inverse filter has to be applied to
+restore the distortion of the frequency response.
+
+The filter accepts the following options:
+
+@table @option
+@item level_in
+Set input gain.
+
+@item level_out
+Set output gain.
+
+@item mode
+Set filter mode. For restoring material use @code{reproduction} mode, otherwise
+use @code{production} mode. Default is @code{reproduction} mode.
+
+@item type
+Set filter type. Selects medium. Can be one of the following:
+
+@table @option
+@item col
+select Columbia.
+@item emi
+select EMI.
+@item bsi
+select BSI (78RPM).
+@item riaa
+select RIAA.
+@item cd
+select Compat Disc (CD).
+@item 50fm
+select 50µs (FM).
+@item 75fm
+select 75µs (FM).
+@item 50kf
+select 50µs (FM-KF).
+@item 75kf
+select 75µs (FM-KF).
+@end table
+@end table
+
@section aeval
Modify an audio signal according to the specified expressions.
diff --git a/libavfilter/Makefile b/libavfilter/Makefile
index e31bdaa..7a42948 100644
--- a/libavfilter/Makefile
+++ b/libavfilter/Makefile
@@ -27,6 +27,7 @@ OBJS-$(CONFIG_ACOMPRESSOR_FILTER)+=
af_sidechaincompress.o
OBJS-$(CONFIG_ACROSSFADE_FILTER) += af_afade.o
OBJS-$(CONFIG_ADELAY_FILTER) += af_adelay.o
OBJS-$(CONFIG_AECHO_FILTER) += af_aecho.o
+OBJS-$(CONFIG_AEMPHASIS_FILTER) += af_aemphasis.o
OBJS-$(CONFIG_AEVAL_FILTER) += aeval.o
OBJS-$(CONFIG_AFADE_FILTER) += af_afade.o
OBJS-$(CONFIG_AFORMAT_FILTER)+= af_aformat.o
diff --git a/libavfilter/af_aemphasis.c b/libavfilter/af_aemphasis.c
new file mode 100644
index 000..80c65d0
--- /dev/null
+++ b/libavfilter/af_aemphasis.c
@@ -0,0 +1,354 @@
+/*
+ * Copyright (c) 2001-2010 Krzysztof Foltman, Markus Schmidt, Thor Harald
Johansen, Damien Zammit and others
+ *
+ * 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 "avfilter.h"
+#include "internal.h"
+#include "audio.h"
+
+typedef struct BiquadCoeffs {
+double a0, a1, a2, b1, b2;
+} BiquadCoeffs;
+
+typedef struct BiquadD2 {
+double a0, a1, a2, b1, b2, w1, w2;
+} BiquadD2;
+
+typedef struct RIAACurve {
+BiquadD2 r1;
+BiquadD2 brickw;
+int use_brickw;
+} RIAACurve;
+
+typedef struct AudioEmphasisContext {
+const AVClass *class;
+int mode, type;
+double level_in, level_out;
+
+RIAACurve *rc;
+} AudioEmphasisContext;
+
+#define OFFSET(x) offsetof(AudioEmphasisContext, x)
+#define FLAGS AV_OPT_FLAG_AUDIO_PARAM|AV_OPT_FLAG_FILTERING_PARAM
+
+static const AVOption aemphasis_options[] = {
+{ "level_in", "set input gain", OFFSET(level_in),
AV_OPT_TYPE_DOUBLE, {.dbl=1}, 0, 64, FLAGS },
+{ "level_out","set output gain", OFFSET(level_out),
AV_OPT_TYPE_DOUBLE, {.dbl=1}, 0, 64, FLAGS },
+{ "mode", "set filter mode", OFFSET(mode), AV_OPT_TYPE_INT,
{.i64=0}, 0, 1, FLAGS, "mode" },
+{ "rep
[FFmpeg-devel] [PATCH] avfilter: add audio pulsator filter
Signed-off-by: Paul B Mahol
---
doc/filters.texi | 57 +
libavfilter/Makefile | 1 +
libavfilter/af_apulsator.c | 279 +
libavfilter/allfilters.c | 1 +
4 files changed, 338 insertions(+)
create mode 100644 libavfilter/af_apulsator.c
diff --git a/doc/filters.texi b/doc/filters.texi
index fc71a99..a4afcac 100644
--- a/doc/filters.texi
+++ b/doc/filters.texi
@@ -1030,6 +1030,63 @@ It accepts the following values:
@end table
@end table
+@section apulsator
+
+Audio pulsator is something between an autopanner and a tremolo.
+But it can produce funny stereo effects as well. Pulsator changes the volume
+of the left and right channel based on a LFO (low frequency oscillator) with
+different waveforms and shifted phases.
+This filter have the ability to define an offset between left and right
+channel. An offset of 0 means that both LFO shapes match each other.
+The left and right channel are altered equally - a conventional tremolo.
+An offset of 50% means that the shape of the right channel is exactly shifted
+in phase (or moved backwards about half of the frequency) - pulsator acts as
+an autopanner. At 1 both curves match again. Every setting in between moves the
+phase shift gapless between all stages and produces some "bypassing" sounds
with
+sine and triangle waveforms. The more you set the offset near 1 (starting from
+the 0.5) the faster the signal passes from the left to the right speaker.
+
+The filter accepts the following options:
+
+@table @option
+@item level_in
+Set input gain. By default it is 1. Range is [0.015625 - 64].
+
+@item level_out
+Set output gain. By default it is 1. Range is [0.015625 - 64].
+
+@item mode
+Set waveform shape the LFO will use. Can be one of: sine, triangle, square,
+sawup or sawdown. Default is sine.
+
+@item amount
+Set modulation. Define how much of original signal is affected by the LFO.
+
+@item offset_l
+Set left channel offset. Default is 0. Allowed range is [0 - 1].
+
+@item offset_r
+Set right channel offset. Default is 0.5. Allowed range is [0 - 1].
+
+@item width
+Set pulse width.
+
+@item timing
+Set possible timing mode. Can be one of: bpm, ms or hz. Default is hz.
+
+@item bpm
+Set bpm. Default is 120. Allowed range is [30 - 300]. Only used if timing
+is set to bpm.
+
+@item ms
+Set ms. Default is 500. Allowed range is [10 - 2000]. Only used if timing
+is set to ms.
+
+@item hz
+Set frequency in Hz. Default is 2. Allowed range is [0.01 - 100]. Only used
+if timing is set to hz.
+@end table
+
@anchor{aresample}
@section aresample
diff --git a/libavfilter/Makefile b/libavfilter/Makefile
index e31bdaa..b6c0d7b 100644
--- a/libavfilter/Makefile
+++ b/libavfilter/Makefile
@@ -40,6 +40,7 @@ OBJS-$(CONFIG_ANULL_FILTER) += af_anull.o
OBJS-$(CONFIG_APAD_FILTER) += af_apad.o
OBJS-$(CONFIG_APERMS_FILTER) += f_perms.o
OBJS-$(CONFIG_APHASER_FILTER)+= af_aphaser.o
generate_wave_table.o
+OBJS-$(CONFIG_APULSATOR_FILTER) += af_apulsator.o
OBJS-$(CONFIG_AREALTIME_FILTER) += f_realtime.o
OBJS-$(CONFIG_ARESAMPLE_FILTER) += af_aresample.o
OBJS-$(CONFIG_AREVERSE_FILTER) += f_reverse.o
diff --git a/libavfilter/af_apulsator.c b/libavfilter/af_apulsator.c
new file mode 100644
index 000..9100eff
--- /dev/null
+++ b/libavfilter/af_apulsator.c
@@ -0,0 +1,279 @@
+/*
+ * Copyright (c) 2001-2010 Krzysztof Foltman, Markus Schmidt, Thor Harald
Johansen and others
+ *
+ * This file is part of FFmpeg.
+ *
+ * FFmpeg is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public
+ * License as published by the Free Software Foundation; either
+ * version 2.1 of the License, or (at your option) any later version.
+ *
+ * FFmpeg is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+ * Lesser General Public License for more details.
+ *
+ * You should have received a copy of the GNU Lesser General Public
+ * License along with FFmpeg; if not, write to the Free Software
+ * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA
+ */
+
+#include "libavutil/opt.h"
+#include "avfilter.h"
+#include "internal.h"
+#include "audio.h"
+
+enum PulsatorModes { SINE, TRIANGLE, SQUARE, SAWUP, SAWDOWN, NB_MODES };
+enum PulsatorTimings { UNIT_BPM, UNIT_MS, UNIT_HZ, NB_TIMINGS };
+
+typedef struct SimpleLFO {
+double phase;
+double freq;
+double offset;
+double amount;
+double pwidth;
+int mode;
+int srate;
+} SimpleLFO;
+
+typedef struct AudioPulsatorContext {
+const AVClass *class;
+int mode;
+double level_in;
+double level_out;
+double amount;
+double offset_l;
+double offset_r;
+double pwidth;
+double bpm;
+double hz;
+
Re: [FFmpeg-devel] Does FFplay support HEVC interlaced bitstream display?
Fan Yingming wrote: Hi, everyone. I noticed that HEVC support interlaced field encoding, but FFplay didn't support HEVC interlaced bitstream display. We know FFplay play h264 interlaced bitstream perfectly. I'd like to know if FFplay support HEVC interlaced bitstream display. And will FFmpeg support that? I don't think so. It is possible to play hevc interlaced with ffmpeg via mpv but you'll have to set up your own filter chain and possibly adjust for field order. I've done it on a homemade (libx265) test. libx265 only takes a certain field order and expects fields, plus interlaced support is (was) flagged as experimental. It did seem to work though, it was a while ago so this is just a paste from notes on the playback side - basically you need to weave the fields that the decoder outputs as weaved frames is what other decoders output. mpv -fs --vf=lavfi=[tinterlace=merge,setsar=1/1,yadif=1] hevc-interl-5M.mkv ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] FFMPEG API
Hi, I'm new with ffmpeg, I'm using the (XX-57) version. I have the following old code but I can't find the *avcodec_alloc_frame*: AVPicture* pConvertedFrame = *avcodec_alloc_frame*(); *I get: * *error C3861: 'avcodec_alloc_frame': identifier not found * I tried the *"* *get_frame_defaults(pConvertedFrame);" *with no luck!!! Any idea? -- Best regards, J.B. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] Does FFplay support HEVC interlaced bitstream display?
On Tue, 1 Dec 2015 12:12:13 + Andy Furniss wrote: > Fan Yingming wrote: > > Hi, everyone. > > > > I noticed that HEVC support interlaced field encoding, but FFplay > > didn't support HEVC interlaced bitstream display. > > > > We know FFplay play h264 interlaced bitstream perfectly. > > > > I'd like to know if FFplay support HEVC interlaced bitstream > > display. And will FFmpeg support that? > > I don't think so. > > It is possible to play hevc interlaced with ffmpeg via mpv but you'll > have to set up your own filter chain and possibly adjust for field order. > > I've done it on a homemade (libx265) test. libx265 only takes a certain > field order and expects fields, plus interlaced support is (was) flagged > as experimental. It did seem to work though, it was a while ago so this > is just a paste from notes on the playback side - basically you need to > weave the fields that the decoder outputs as weaved frames is what other > decoders output. > > mpv -fs --vf=lavfi=[tinterlace=merge,setsar=1/1,yadif=1] hevc-interl-5M.mkv Exactly the same (without the lavfi wrapper of course) should work on ffplay. So does this mean the HEVC decoder outputs separate fields only? This is really odd, although I can understand why. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] Does FFplay support HEVC interlaced bitstream display?
On Tue, Dec 1, 2015 at 1:36 PM, wm4 wrote: > On Tue, 1 Dec 2015 12:12:13 + > Andy Furniss wrote: > >> Fan Yingming wrote: >> > Hi, everyone. >> > >> > I noticed that HEVC support interlaced field encoding, but FFplay >> > didn't support HEVC interlaced bitstream display. >> > >> > We know FFplay play h264 interlaced bitstream perfectly. >> > >> > I'd like to know if FFplay support HEVC interlaced bitstream >> > display. And will FFmpeg support that? >> >> I don't think so. >> >> It is possible to play hevc interlaced with ffmpeg via mpv but you'll >> have to set up your own filter chain and possibly adjust for field order. >> >> I've done it on a homemade (libx265) test. libx265 only takes a certain >> field order and expects fields, plus interlaced support is (was) flagged >> as experimental. It did seem to work though, it was a while ago so this >> is just a paste from notes on the playback side - basically you need to >> weave the fields that the decoder outputs as weaved frames is what other >> decoders output. >> >> mpv -fs --vf=lavfi=[tinterlace=merge,setsar=1/1,yadif=1] hevc-interl-5M.mkv > > Exactly the same (without the lavfi wrapper of course) should work on > ffplay. > > So does this mean the HEVC decoder outputs separate fields only? This > is really odd, although I can understand why. The reason for that is that HEVC doesn't actually have any interlaced coding tools, just some metadata to flag a stream as interlaced. So an interlaced stream is just a stream of half-height frames at twice the fps. I thought there was a patch to assemble them back into frames, though. Maybe it was never applied. - Hendrik ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 1/2] avutil/mathematics: return INT64_MIN (=AV_NOPTS_VALUE) from av_rescale_rnd() for overflows
From: Michael Niedermayer
Fixes integer overflow
Fixes: mozilla bug 1229167
Found-by: Tyson Smith
Signed-off-by: Michael Niedermayer
---
libavutil/mathematics.c | 13 ++---
1 file changed, 10 insertions(+), 3 deletions(-)
diff --git a/libavutil/mathematics.c b/libavutil/mathematics.c
index 689325f..c12c73e 100644
--- a/libavutil/mathematics.c
+++ b/libavutil/mathematics.c
@@ -72,7 +72,7 @@ int64_t av_rescale_rnd(int64_t a, int64_t b, int64_t c, enum
AVRounding rnd)
}
if (a < 0)
-return -av_rescale_rnd(-FFMAX(a, -INT64_MAX), b, c, rnd ^ ((rnd >> 1)
& 1));
+return -(uint64_t)av_rescale_rnd(-FFMAX(a, -INT64_MAX), b, c, rnd ^
((rnd >> 1) & 1));
if (rnd == AV_ROUND_NEAR_INF)
r = c / 2;
@@ -82,8 +82,13 @@ int64_t av_rescale_rnd(int64_t a, int64_t b, int64_t c, enum
AVRounding rnd)
if (b <= INT_MAX && c <= INT_MAX) {
if (a <= INT_MAX)
return (a * b + r) / c;
-else
-return a / c * b + (a % c * b + r) / c;
+else {
+int64_t ad = a / c;
+int64_t a2 = (a % c * b + r) / c;
+if (ad >= INT32_MAX && ad > (INT64_MAX - a2) / b)
+return INT64_MIN;
+return ad * b + a2;
+}
} else {
#if 1
uint64_t a0 = a & 0x;
@@ -107,6 +112,8 @@ int64_t av_rescale_rnd(int64_t a, int64_t b, int64_t c,
enum AVRounding rnd)
t1++;
}
}
+if (t1 > INT64_MAX)
+return INT64_MIN;
return t1;
}
#else
--
1.7.9.5
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 2/2] avutil/rational: Test av_rescale_rnd() with combinations of "special" values
From: Michael Niedermayer
Signed-off-by: Michael Niedermayer
---
libavutil/Makefile |1 +
libavutil/rational.c | 44
2 files changed, 45 insertions(+)
diff --git a/libavutil/Makefile b/libavutil/Makefile
index 1bac2b9..b43cede 100644
--- a/libavutil/Makefile
+++ b/libavutil/Makefile
@@ -106,6 +106,7 @@ OBJS = adler32.o
\
hash.o \
hmac.o \
imgutils.o \
+ integer.o\
intmath.o\
lfg.o\
lls.o\
diff --git a/libavutil/rational.c b/libavutil/rational.c
index 81a9402..6b3f50a 100644
--- a/libavutil/rational.c
+++ b/libavutil/rational.c
@@ -183,9 +183,18 @@ uint32_t av_q2intfloat(AVRational q) {
}
#ifdef TEST
+
+#include "integer.h"
+
int main(void)
{
AVRational a,b,r;
+int i,j,k;
+static const int64_t numlist[] = {
+INT64_MIN, INT64_MIN+1, INT64_MAX, INT32_MIN, INT32_MAX, 1,0,-1,
+123456789, INT32_MAX-1, INT32_MAX+1LL, UINT32_MAX-1, UINT32_MAX,
UINT32_MAX+1LL
+};
+
for (a.num = -2; a.num <= 2; a.num++) {
for (a.den = -2; a.den <= 2; a.den++) {
for (b.num = -2; b.num <= 2; b.num++) {
@@ -207,6 +216,41 @@ int main(void)
}
}
+for (i = 0; i < FF_ARRAY_ELEMS(numlist); i++) {
+int64_t a = numlist[i];
+
+for (j = 0; j < FF_ARRAY_ELEMS(numlist); j++) {
+int64_t b = numlist[j];
+if (b<=0)
+continue;
+for (k = 0; k < FF_ARRAY_ELEMS(numlist); k++) {
+int64_t c = numlist[k];
+int64_t res;
+AVInteger ai;
+
+if (c<=0)
+continue;
+res = av_rescale_rnd(a,b,c, AV_ROUND_ZERO);
+
+ai = av_mul_i(av_int2i(a), av_int2i(b));
+ai = av_div_i(ai, av_int2i(c));
+
+if (av_cmp_i(ai, av_int2i(INT64_MAX)) > 0 && res == INT64_MIN)
+continue;
+if (av_cmp_i(ai, av_int2i(INT64_MIN)) < 0 && res == INT64_MIN)
+continue;
+if (av_cmp_i(ai, av_int2i(res)) == 0)
+continue;
+
+// Special exception for INT64_MIN, remove this in case
INT64_MIN is handled without off by 1 error
+if (av_cmp_i(ai, av_int2i(res-1)) == 0 && a == INT64_MIN)
+continue;
+
+av_log(NULL, AV_LOG_ERROR, "%"PRId64" * %"PRId64" / %"PRId64"
= %"PRId64" or %"PRId64"\n", a,b,c, res, av_i2int(ai));
+}
+}
+}
+
for (a.num = 1; a.num <= 10; a.num++) {
for (a.den = 1; a.den <= 10; a.den++) {
if (av_gcd(a.num, a.den) > 1)
--
1.7.9.5
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] Does FFplay support HEVC interlaced bitstream display?
Hendrik Leppkes wrote: On Tue, Dec 1, 2015 at 1:36 PM, wm4 wrote: On Tue, 1 Dec 2015 12:12:13 + Andy Furniss wrote: Fan Yingming wrote: Hi, everyone. I noticed that HEVC support interlaced field encoding, but FFplay didn't support HEVC interlaced bitstream display. We know FFplay play h264 interlaced bitstream perfectly. I'd like to know if FFplay support HEVC interlaced bitstream display. And will FFmpeg support that? I don't think so. It is possible to play hevc interlaced with ffmpeg via mpv but you'll have to set up your own filter chain and possibly adjust for field order. I've done it on a homemade (libx265) test. libx265 only takes a certain field order and expects fields, plus interlaced support is (was) flagged as experimental. It did seem to work though, it was a while ago so this is just a paste from notes on the playback side - basically you need to weave the fields that the decoder outputs as weaved frames is what other decoders output. mpv -fs --vf=lavfi=[tinterlace=merge,setsar=1/1,yadif=1] hevc-interl-5M.mkv Exactly the same (without the lavfi wrapper of course) should work on ffplay. Yea, I guess, just posting what I new worked for me. So does this mean the HEVC decoder outputs separate fields only? This is really odd, although I can understand why. The reason for that is that HEVC doesn't actually have any interlaced coding tools, just some metadata to flag a stream as interlaced. So an interlaced stream is just a stream of half-height frames at twice the fps. I thought there was a patch to assemble them back into frames, though. Maybe it was never applied. With very recent mpv/ffmpeg my test still outputs fields. On the "just metadata" comment - you do have to feed (IIRC) top field first so I would hope there is some spatial handling of the bobbing in there somewhere, but then "my hope" may not match with reality :-) ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] Does FFplay support HEVC interlaced bitstream display?
Andy Furniss wrote: On the "just metadata" comment - you do have to feed (IIRC) top field first so I would hope there is some spatial handling of the bobbing in there somewhere, but then "my hope" may not match with reality :-) Of course I am thinking of libx265 here - maybe the spec says nothing. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 2/2] avfilter: add sidechaingate filter
On Tue, Dec 1, 2015 at 3:50 AM, Paul B Mahol wrote:
> On 12/1/15, Ganesh Ajjanagadde wrote:
>> On Sun, Nov 29, 2015 at 6:03 PM, Paul B Mahol wrote:
>>> Signed-off-by: Paul B Mahol
>>> ---
>>> doc/filters.texi | 61 +
>>> libavfilter/Makefile | 1 +
>>> libavfilter/af_agate.c | 170
>>> ++-
>>> libavfilter/allfilters.c | 1 +
>>> 4 files changed, 230 insertions(+), 3 deletions(-)
>>>
>>> diff --git a/doc/filters.texi b/doc/filters.texi
>>> index 0395c7a..ed4a376 100644
>>> --- a/doc/filters.texi
>>> +++ b/doc/filters.texi
>>> @@ -2531,6 +2531,67 @@ ffmpeg -i main.flac -i sidechain.flac
>>> -filter_complex "[1:a]asplit=2[sc][mix];[0
>>> @end example
>>> @end itemize
>>>
>>> +@section sidechaingate
>>> +
>>> +A sidechain gate acts like a normal (wideband) gate but has the ability
>>> to
>>> +filter the detected signal before sending it to the gain reduction stage.
>>> +Normally a gate uses the full range signal to detect a level above the
>>> +threshold.
>>> +For example: If you cut all lower frequencies from your sidechain signal
>>> +the gate will decrease the volume of your track only if not enough highs
>>> +appear. With this technique you are able to reduce the resonation of a
>>> +natural drum or remove "rumbling" of muted strokes from a heavily
>>> distorted
>>> +guitar.
>>> +It needs two input streams and returns one output stream.
>>> +First input stream will be processed depending on second stream signal.
>>> +
>>> +The filter accepts the following options:
>>> +
>>> +@table @option
>>> +@item level_in
>>> +Set input level before filtering.
>>> +Default is 1. Allowed range is from 0.015625 to 64.
>>> +
>>> +@item range
>>> +Set the level of gain reduction when the signal is below the threshold.
>>> +Default is 0.06125. Allowed range is from 0 to 1.
>>> +
>>> +@item threshold
>>> +If a signal rises above this level the gain reduction is released.
>>> +Default is 0.125. Allowed range is from 0 to 1.
>>> +
>>> +@item ratio
>>> +Set a ratio about which the signal is reduced.
>>> +Default is 2. Allowed range is from 1 to 9000.
>>> +
>>> +@item attack
>>> +Amount of milliseconds the signal has to rise above the threshold before
>>> gain
>>> +reduction stops.
>>> +Default is 20 milliseconds. Allowed range is from 0.01 to 9000.
>>> +
>>> +@item release
>>> +Amount of milliseconds the signal has to fall below the threshold before
>>> the
>>> +reduction is increased again. Default is 250 milliseconds.
>>> +Allowed range is from 0.01 to 9000.
>>> +
>>> +@item makeup
>>> +Set amount of amplification of signal after processing.
>>> +Default is 1. Allowed range is from 1 to 64.
>>> +
>>> +@item knee
>>> +Curve the sharp knee around the threshold to enter gain reduction more
>>> softly.
>>> +Default is 2.828427125. Allowed range is from 1 to 8.
>>> +
>>> +@item detection
>>> +Choose if exact signal should be taken for detection or an RMS like one.
>>> +Default is peak. Can be peak or rms.
>>> +
>>> +@item link
>>> +Choose if the average level between all channels or the louder channel
>>> affects
>>> +the reduction.
>>> +Default is average. Can be average or maximum.
>>> +@end table
>>> +
>>> @section silencedetect
>>>
>>> Detect silence in an audio stream.
>>> diff --git a/libavfilter/Makefile b/libavfilter/Makefile
>>> index e31bdaa..582fd0e 100644
>>> --- a/libavfilter/Makefile
>>> +++ b/libavfilter/Makefile
>>> @@ -82,6 +82,7 @@ OBJS-$(CONFIG_REPLAYGAIN_FILTER) +=
>>> af_replaygain.o
>>> OBJS-$(CONFIG_RESAMPLE_FILTER) += af_resample.o
>>> OBJS-$(CONFIG_RUBBERBAND_FILTER) += af_rubberband.o
>>> OBJS-$(CONFIG_SIDECHAINCOMPRESS_FILTER) += af_sidechaincompress.o
>>> +OBJS-$(CONFIG_SIDECHAINGATE_FILTER) += af_agate.o
>>> OBJS-$(CONFIG_SILENCEDETECT_FILTER) += af_silencedetect.o
>>> OBJS-$(CONFIG_SILENCEREMOVE_FILTER) += af_silenceremove.o
>>> OBJS-$(CONFIG_STEREOTOOLS_FILTER)+= af_stereotools.o
>>> diff --git a/libavfilter/af_agate.c b/libavfilter/af_agate.c
>>> index d3f74fb..23e45c6 100644
>>> --- a/libavfilter/af_agate.c
>>> +++ b/libavfilter/af_agate.c
>>> @@ -18,6 +18,12 @@
>>> * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA
>>> 02110-1301 USA
>>> */
>>>
>>> +/**
>>> + * @file
>>> + * Audio (Sidechain) Gate filter
>>> + */
>>> +
>>> +#include "libavutil/avassert.h"
>>> #include "libavutil/channel_layout.h"
>>> #include "libavutil/opt.h"
>>> #include "avfilter.h"
>>> @@ -46,12 +52,14 @@ typedef struct AudioGateContext {
>>> double lin_slope;
>>> double attack_coeff;
>>> double release_coeff;
>>> +
>>> +AVFrame *input_frame[2];
>>> } AudioGateContext;
>>>
>>> #define OFFSET(x) offsetof(AudioGateContext, x)
>>> #define A AV_OPT_FLAG_AUDIO_PARAM|AV_OPT_FLAG_FILTERING_PARAM
>>>
>>> -static const AVOption agate_options[] = {
>>> +static const AVOption options[] = {
>>> { "level_in", "set input
Re: [FFmpeg-devel] FFMPEG API
only add the include and AVPicture* pConvertedFrame = (AVPicture*)*av_frame_alloc*(); On Tue, Dec 1, 2015 at 2:33 PM, Yosef B wrote: > Hi, > I'm new with ffmpeg, I'm using the (XX-57) version. > > I have the following old code but I can't find the *avcodec_alloc_frame*: > AVPicture* pConvertedFrame = *avcodec_alloc_frame*(); > > *I get: * > *error C3861: 'avcodec_alloc_frame': identifier not found * > > I tried the *"* > *get_frame_defaults(pConvertedFrame);" *with no luck!!! > > Any idea? > > -- > > Best regards, > > J.B. > -- Best regards, J.B. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 2/2] avfilter: add sidechaingate filter
On 12/1/15, Ganesh Ajjanagadde wrote:
> On Tue, Dec 1, 2015 at 3:50 AM, Paul B Mahol wrote:
>> On 12/1/15, Ganesh Ajjanagadde wrote:
>>> On Sun, Nov 29, 2015 at 6:03 PM, Paul B Mahol wrote:
Signed-off-by: Paul B Mahol
---
doc/filters.texi | 61 +
libavfilter/Makefile | 1 +
libavfilter/af_agate.c | 170
++-
libavfilter/allfilters.c | 1 +
4 files changed, 230 insertions(+), 3 deletions(-)
diff --git a/doc/filters.texi b/doc/filters.texi
index 0395c7a..ed4a376 100644
--- a/doc/filters.texi
+++ b/doc/filters.texi
@@ -2531,6 +2531,67 @@ ffmpeg -i main.flac -i sidechain.flac
-filter_complex "[1:a]asplit=2[sc][mix];[0
@end example
@end itemize
+@section sidechaingate
+
+A sidechain gate acts like a normal (wideband) gate but has the ability
to
+filter the detected signal before sending it to the gain reduction
stage.
+Normally a gate uses the full range signal to detect a level above the
+threshold.
+For example: If you cut all lower frequencies from your sidechain
signal
+the gate will decrease the volume of your track only if not enough
highs
+appear. With this technique you are able to reduce the resonation of a
+natural drum or remove "rumbling" of muted strokes from a heavily
distorted
+guitar.
+It needs two input streams and returns one output stream.
+First input stream will be processed depending on second stream signal.
+
+The filter accepts the following options:
+
+@table @option
+@item level_in
+Set input level before filtering.
+Default is 1. Allowed range is from 0.015625 to 64.
+
+@item range
+Set the level of gain reduction when the signal is below the threshold.
+Default is 0.06125. Allowed range is from 0 to 1.
+
+@item threshold
+If a signal rises above this level the gain reduction is released.
+Default is 0.125. Allowed range is from 0 to 1.
+
+@item ratio
+Set a ratio about which the signal is reduced.
+Default is 2. Allowed range is from 1 to 9000.
+
+@item attack
+Amount of milliseconds the signal has to rise above the threshold
before
gain
+reduction stops.
+Default is 20 milliseconds. Allowed range is from 0.01 to 9000.
+
+@item release
+Amount of milliseconds the signal has to fall below the threshold
before
the
+reduction is increased again. Default is 250 milliseconds.
+Allowed range is from 0.01 to 9000.
+
+@item makeup
+Set amount of amplification of signal after processing.
+Default is 1. Allowed range is from 1 to 64.
+
+@item knee
+Curve the sharp knee around the threshold to enter gain reduction more
softly.
+Default is 2.828427125. Allowed range is from 1 to 8.
+
+@item detection
+Choose if exact signal should be taken for detection or an RMS like
one.
+Default is peak. Can be peak or rms.
+
+@item link
+Choose if the average level between all channels or the louder channel
affects
+the reduction.
+Default is average. Can be average or maximum.
+@end table
+
@section silencedetect
Detect silence in an audio stream.
diff --git a/libavfilter/Makefile b/libavfilter/Makefile
index e31bdaa..582fd0e 100644
--- a/libavfilter/Makefile
+++ b/libavfilter/Makefile
@@ -82,6 +82,7 @@ OBJS-$(CONFIG_REPLAYGAIN_FILTER) +=
af_replaygain.o
OBJS-$(CONFIG_RESAMPLE_FILTER) += af_resample.o
OBJS-$(CONFIG_RUBBERBAND_FILTER) += af_rubberband.o
OBJS-$(CONFIG_SIDECHAINCOMPRESS_FILTER) += af_sidechaincompress.o
+OBJS-$(CONFIG_SIDECHAINGATE_FILTER) += af_agate.o
OBJS-$(CONFIG_SILENCEDETECT_FILTER) += af_silencedetect.o
OBJS-$(CONFIG_SILENCEREMOVE_FILTER) += af_silenceremove.o
OBJS-$(CONFIG_STEREOTOOLS_FILTER)+= af_stereotools.o
diff --git a/libavfilter/af_agate.c b/libavfilter/af_agate.c
index d3f74fb..23e45c6 100644
--- a/libavfilter/af_agate.c
+++ b/libavfilter/af_agate.c
@@ -18,6 +18,12 @@
* Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA
02110-1301 USA
*/
+/**
+ * @file
+ * Audio (Sidechain) Gate filter
+ */
+
+#include "libavutil/avassert.h"
#include "libavutil/channel_layout.h"
#include "libavutil/opt.h"
#include "avfilter.h"
@@ -46,12 +52,14 @@ typedef struct AudioGateContext {
double lin_slope;
double attack_coeff;
double release_coeff;
+
+AVFrame *input_frame[2];
} AudioGateContext;
#define OFFSET(x) offsetof(AudioGateCont
Re: [FFmpeg-devel] FFMPEG API
On Tue, 1 Dec 2015 14:33:09 +0200 Yosef B wrote: > Hi, > I'm new with ffmpeg, I'm using the (XX-57) version. > > I have the following old code but I can't find the *avcodec_alloc_frame*: > AVPicture* pConvertedFrame = *avcodec_alloc_frame*(); > > *I get: * > *error C3861: 'avcodec_alloc_frame': identifier not found * > > I tried the *"* > *get_frame_defaults(pConvertedFrame);" *with no luck!!! > > Any idea? > The correct mailing list for such question is: libav-u...@ffmpeg.org ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 2/2] avfilter: add sidechaingate filter
Le primidi 11 frimaire, an CCXXIV, Paul B Mahol a écrit : > I don't think API is needed for this. Just one call in right place IIRC. Can you show an example? That would be more useful than handwaving. I must say I have no idea what the "right place" would be. Also, I would appreciate if Ganesh and you took the habit of trimming your email: 460+ lines of quote for 2 lines of reply, that makes a very poor signal/noise ratio. Regards, -- Nicolas George signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] vp9: reinit internal buffers on bpp change.
Fixes mozilla bug 1229128. --- libavcodec/vp9.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/libavcodec/vp9.c b/libavcodec/vp9.c index d4061e2..858d561 100644 --- a/libavcodec/vp9.c +++ b/libavcodec/vp9.c @@ -219,7 +219,8 @@ static int update_size(AVCodecContext *ctx, int w, int h, enum AVPixelFormat fmt av_assert0(w > 0 && h > 0); -if (s->intra_pred_data[0] && w == ctx->width && h == ctx->height && ctx->pix_fmt == fmt) +if (s->intra_pred_data[0] && w == ctx->width && h == ctx->height && +ctx->pix_fmt == fmt && s->bpp == s->last_bpp) return 0; if ((res = ff_set_dimensions(ctx, w, h)) < 0) -- 2.1.2 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] vp9: reinit internal buffers on bpp change.
On Tue, Dec 1, 2015 at 3:13 PM, Ronald S. Bultje wrote: > Fixes mozilla bug 1229128. > --- > libavcodec/vp9.c | 3 ++- > 1 file changed, 2 insertions(+), 1 deletion(-) > > diff --git a/libavcodec/vp9.c b/libavcodec/vp9.c > index d4061e2..858d561 100644 > --- a/libavcodec/vp9.c > +++ b/libavcodec/vp9.c > @@ -219,7 +219,8 @@ static int update_size(AVCodecContext *ctx, int w, int h, > enum AVPixelFormat fmt > > av_assert0(w > 0 && h > 0); > > -if (s->intra_pred_data[0] && w == ctx->width && h == ctx->height && > ctx->pix_fmt == fmt) > +if (s->intra_pred_data[0] && w == ctx->width && h == ctx->height && > +ctx->pix_fmt == fmt && s->bpp == s->last_bpp) > return 0; Doesn't the pixfmt change when bitdepth changes? Also, someone yell at Mozilla for having "hidden" bug reports. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 2/2] avfilter: add sidechaingate filter
Dana 1. 12. 2015. 15:08 osoba "Nicolas George" napisala je: > > Le primidi 11 frimaire, an CCXXIV, Paul B Mahol a écrit : > > I don't think API is needed for this. Just one call in right place IIRC. > > Can you show an example? That would be more useful than handwaving. I must > say I have no idea what the "right place" would be. Similar how its freed when no longer used. > > Also, I would appreciate if Ganesh and you took the habit of trimming your > email: 460+ lines of quote for 2 lines of reply, that makes a very poor > signal/noise ratio. > > Regards, > > -- > Nicolas George > > ___ > 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 2/2] avfilter: add sidechaingate filter
Le primidi 11 frimaire, an CCXXIV, Paul B Mahol a écrit : > Similar how its freed when no longer used. Please elaborate. I know the API, I do not see what you suggest. (Thanks for trimming.) 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: add audio emphasis filter
On Tue, Dec 01, 2015 at 12:22:43 +0100, Paul B Mahol wrote:
> +select Compat Disc (CD).
Compact
> +@item 50fm
> +select 50??s (FM).
a) I'm not sure whether you're allowed or encouraged to use UTF-8
characters in ffmpeg's code. If encouraged, then okay. Riddles me
though how you managed to send the UTF-8 patch in an ascii-encoded
e-mail. ;-)
("??" as quoted above is mutt's interpretation in this response.
When I saved the content of your mail as a patch, mutt was so kind
to retain the UTF-8 characters.)
I didn't really check much except the docs, sorry.
Moritz
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] vp9: reinit internal buffers on bpp change.
Hi, On Tue, Dec 1, 2015 at 9:21 AM, Hendrik Leppkes wrote: > On Tue, Dec 1, 2015 at 3:13 PM, Ronald S. Bultje > wrote: > > Fixes mozilla bug 1229128. > > --- > > libavcodec/vp9.c | 3 ++- > > 1 file changed, 2 insertions(+), 1 deletion(-) > > > > diff --git a/libavcodec/vp9.c b/libavcodec/vp9.c > > index d4061e2..858d561 100644 > > --- a/libavcodec/vp9.c > > +++ b/libavcodec/vp9.c > > @@ -219,7 +219,8 @@ static int update_size(AVCodecContext *ctx, int w, > int h, enum AVPixelFormat fmt > > > > av_assert0(w > 0 && h > 0); > > > > -if (s->intra_pred_data[0] && w == ctx->width && h == ctx->height && > ctx->pix_fmt == fmt) > > +if (s->intra_pred_data[0] && w == ctx->width && h == ctx->height && > > +ctx->pix_fmt == fmt && s->bpp == s->last_bpp) > > return 0; > > Doesn't the pixfmt change when bitdepth changes? Hm, yes, let me dig some deeper, I think there's something more shitty hiding in there... Patch withdrawn, for now. Ronald ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH] vp9: always keep s->bytesperpixel and ctx->pix_fmt in sync.
Fixes mozilla bug 1229128.
---
libavcodec/vp9.c | 43 ++-
1 file changed, 22 insertions(+), 21 deletions(-)
diff --git a/libavcodec/vp9.c b/libavcodec/vp9.c
index d4061e2..9bf746c 100644
--- a/libavcodec/vp9.c
+++ b/libavcodec/vp9.c
@@ -69,6 +69,7 @@ typedef struct VP9Context {
uint8_t ss_h, ss_v;
uint8_t last_bpp, bpp, bpp_index, bytesperpixel;
uint8_t last_keyframe;
+enum AVPixelFormat last_fmt;
ThreadFrame next_refs[8];
struct {
@@ -211,7 +212,7 @@ static int vp9_ref_frame(AVCodecContext *ctx, VP9Frame
*dst, VP9Frame *src)
return 0;
}
-static int update_size(AVCodecContext *ctx, int w, int h, enum AVPixelFormat
fmt)
+static int update_size(AVCodecContext *ctx, int w, int h)
{
VP9Context *s = ctx->priv_data;
uint8_t *p;
@@ -219,12 +220,12 @@ static int update_size(AVCodecContext *ctx, int w, int h,
enum AVPixelFormat fmt
av_assert0(w > 0 && h > 0);
-if (s->intra_pred_data[0] && w == ctx->width && h == ctx->height &&
ctx->pix_fmt == fmt)
+if (s->intra_pred_data[0] && w == ctx->width && h == ctx->height &&
ctx->pix_fmt == s->last_fmt)
return 0;
if ((res = ff_set_dimensions(ctx, w, h)) < 0)
return res;
-ctx->pix_fmt = fmt;
+s->last_fmt = ctx->pix_fmt;
s->sb_cols = (w + 63) >> 6;
s->sb_rows = (h + 63) >> 6;
s->cols = (w + 7) >> 3;
@@ -383,14 +384,13 @@ static int update_prob(VP56RangeCoder *c, int p)
255 - inv_recenter_nonneg(inv_map_table[d], 255 - p);
}
-static enum AVPixelFormat read_colorspace_details(AVCodecContext *ctx)
+static int read_colorspace_details(AVCodecContext *ctx)
{
static const enum AVColorSpace colorspaces[8] = {
AVCOL_SPC_UNSPECIFIED, AVCOL_SPC_BT470BG, AVCOL_SPC_BT709,
AVCOL_SPC_SMPTE170M,
AVCOL_SPC_SMPTE240M, AVCOL_SPC_BT2020_NCL, AVCOL_SPC_RESERVED,
AVCOL_SPC_RGB,
};
VP9Context *s = ctx->priv_data;
-enum AVPixelFormat res;
int bits = ctx->profile <= 1 ? 0 : 1 + get_bits1(&s->gb); // 0:8, 1:10,
2:12
s->bpp_index = bits;
@@ -401,10 +401,10 @@ static enum AVPixelFormat
read_colorspace_details(AVCodecContext *ctx)
static const enum AVPixelFormat pix_fmt_rgb[3] = {
AV_PIX_FMT_GBRP, AV_PIX_FMT_GBRP10, AV_PIX_FMT_GBRP12
};
+s->ss_h = s->ss_v = 0;
+ctx->color_range = AVCOL_RANGE_JPEG;
+ctx->pix_fmt = pix_fmt_rgb[bits];
if (ctx->profile & 1) {
-s->ss_h = s->ss_v = 0;
-res = pix_fmt_rgb[bits];
-ctx->color_range = AVCOL_RANGE_JPEG;
if (get_bits1(&s->gb)) {
av_log(ctx, AV_LOG_ERROR, "Reserved bit set in RGB\n");
return AVERROR_INVALIDDATA;
@@ -427,7 +427,8 @@ static enum AVPixelFormat
read_colorspace_details(AVCodecContext *ctx)
if (ctx->profile & 1) {
s->ss_h = get_bits1(&s->gb);
s->ss_v = get_bits1(&s->gb);
-if ((res = pix_fmt_for_ss[bits][s->ss_v][s->ss_h]) ==
AV_PIX_FMT_YUV420P) {
+ctx->pix_fmt = pix_fmt_for_ss[bits][s->ss_v][s->ss_h];
+if (ctx->pix_fmt == AV_PIX_FMT_YUV420P) {
av_log(ctx, AV_LOG_ERROR, "YUV 4:2:0 not supported in profile
%d\n",
ctx->profile);
return AVERROR_INVALIDDATA;
@@ -438,11 +439,11 @@ static enum AVPixelFormat
read_colorspace_details(AVCodecContext *ctx)
}
} else {
s->ss_h = s->ss_v = 1;
-res = pix_fmt_for_ss[bits][1][1];
+ctx->pix_fmt = pix_fmt_for_ss[bits][1][1];
}
}
-return res;
+return 0;
}
static int decode_frame_header(AVCodecContext *ctx,
@@ -450,7 +451,6 @@ static int decode_frame_header(AVCodecContext *ctx,
{
VP9Context *s = ctx->priv_data;
int c, i, j, k, l, m, n, w, h, max, size2, res, sharp;
-enum AVPixelFormat fmt = ctx->pix_fmt;
int last_invisible;
const uint8_t *data2;
@@ -486,8 +486,8 @@ static int decode_frame_header(AVCodecContext *ctx,
av_log(ctx, AV_LOG_ERROR, "Invalid sync code\n");
return AVERROR_INVALIDDATA;
}
-if ((fmt = read_colorspace_details(ctx)) < 0)
-return fmt;
+if ((res = read_colorspace_details(ctx)) < 0)
+return res;
// for profile 1, here follows the subsampling bits
s->s.h.refreshrefmask = 0xff;
w = get_bits(&s->gb, 16) + 1;
@@ -503,14 +503,14 @@ static int decode_frame_header(AVCodecContext *ctx,
return AVERROR_INVALIDDATA;
}
if (ctx->profile >= 1) {
-if ((fmt = read_colorspace_details(ctx)) < 0)
-return fmt;
+if ((res = read_colorspace_details(ctx)) < 0)
+return res;
} else {
s->ss_h = s->ss_v = 1;
s->bpp = 8;
s->bpp_index
[FFmpeg-devel] [PATCH] avutil/threadmessage: fix condition broadcasting
From: Clément Bœsch Fix a dead lock under certain conditions. Let's assume we have a queue of 1 message max, 2 senders, and 1 receiver. Scenario (real record obtained with debug added): [...] SENDER #0: acquired lock SENDER #0: queue is full, wait SENDER #1: acquired lock SENDER #1: queue is full, wait RECEIVER: acquired lock RECEIVER: reading a msg from the queue RECEIVER: signal the cond RECEIVER: acquired lock RECEIVER: queue is empty, wait SENDER #0: writing a msg the queue SENDER #0: signal the cond SENDER #0: acquired lock SENDER #0: queue is full, wait SENDER #1: queue is full, wait Translated: - initially the queue contains 1/1 message with 2 senders blocking on it, waiting to push another message. - Meanwhile the receiver is obtaining the lock, read the message, signal & release the lock. For some reason it is able to acquire the lock again before the signal wakes up one of the sender. Since it just emptied the queue, the reader waits for the queue to fill up again. - The signal finally reaches one of the sender, which writes a message and then signal the condition. Unfortunately, instead of waking up the reader, it actually wakes up the other worker (signal = notify the condition just for 1 waiter), who can't push another message in the queue because it's full. - Meanwhile, the receiver is still waiting. Deadlock. This scenario can be triggered with for example: tests/api/api-threadmessage-test 2 1 100 100 999 The fix is simply to make sure to notify everyone when work is done (be it reading or writing). Another solution would be to use 2 distincts conditions. --- libavutil/threadmessage.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/libavutil/threadmessage.c b/libavutil/threadmessage.c index b7fcbe2..2089c6d 100644 --- a/libavutil/threadmessage.c +++ b/libavutil/threadmessage.c @@ -107,7 +107,7 @@ static int av_thread_message_queue_send_locked(AVThreadMessageQueue *mq, if (mq->err_send) return mq->err_send; av_fifo_generic_write(mq->fifo, msg, mq->elsize, NULL); -pthread_cond_signal(&mq->cond); +pthread_cond_broadcast(&mq->cond); return 0; } @@ -123,7 +123,7 @@ static int av_thread_message_queue_recv_locked(AVThreadMessageQueue *mq, if (av_fifo_size(mq->fifo) < mq->elsize) return mq->err_recv; av_fifo_generic_read(mq->fifo, msg, mq->elsize, NULL); -pthread_cond_signal(&mq->cond); +pthread_cond_broadcast(&mq->cond); return 0; } -- 2.6.2 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avfilter/showcqt: BASEFREQ and ENDFREQ cast to double
On Mon, Nov 30, 2015 at 08:03:41PM -0800, Muhammad Faiz wrote: > On Mon, Nov 30, 2015 at 12:06 PM, Michael Niedermayer > wrote: > > On Mon, Nov 30, 2015 at 07:02:47PM +0100, Nicolas George wrote: > >> Le decadi 10 frimaire, an CCXXIV, Michael Niedermayer a écrit : > >> > > ISO/IEC 9899:TC3 > >> > > 5.2.4.2.2 Characteristics of floating types > >> > > > >> > > 8 Except for assignment and cast (which remove all extra range and > >> > > precision), the values > >> > > of operations with floating operands and values subject to the > >> > > usual arithmetic > >> > > conversions and of floating constants are evaluated to a format > >> > > whose range and precision > >> > > may be greater than required by the type. The use of evaluation > >> > > formats is characterized > >> > > by the implementation-defined value of FLT_EVAL_METHOD:19) > >> > > -1 indeterminable; > >> > > 0 evaluate all operations and constants just to the > >> > > range and precision of the > >> > > type; > >> > > 1 evaluate operations and constants of type float and > >> > > double to the > >> > > range and precision of the double type, evaluate long > >> > > double > >> > > operations and constants to the range and precision of > >> > > the long double > >> > > type; > >> > > 2 evaluate all operations and constants to the range and > >> > > precision of the > >> > > long double type. > >> > > All other negative values for FLT_EVAL_METHOD characterize > >> > > implementation-defined > >> > > behavior. > >> > > >> > a few more related parts: > >> > 5 The accuracy of the floating-point operations (+, -, *, /) and of > >> > the library functions in > >> > and that return floating-point results is > >> > implementation- > >> > defined, as is the accuracy of the conversion between floating-point > >> > internal > >> > representations and string representations performed by the library > >> > functions in > >> > , , and . The implementation may state > >> > that the > >> > accuracy is unknown. > >> > > >> > 6.4.4.2 Floating constants > >> > 7 The translation-time conversion of floating constants should match > >> > the execution-time > >> > conversion of character strings by library functions, such as > >> > strtod, given matching > >> > inputs suitable for both conversions, the same result format, and > >> > default execution-time > >> > rounding.64) > >> > >> I am not sure why you quoting this. Are you implying this is not a compiler > >> bug, the compiler is actually allowed to do that? Possible. But still, I do > > > > yes, i suspect that is not a compiler bug but i certainly do not have > > deep enough knowledge of C to say that for sure > > > > > >> not think we should apply this unless we actually understand what is going > >> on here, why a cast that should not change anything does change the result. > >> Otherwise, it could just be a coincidence, and break in a different way on > >> a > >> different compiler. > > > > I would not be surprised if a strict and litteral reading of C would > > allow that still to fail, but then theres the question if such > > equals check is even possible in C in such a strict reading of the > > standard. > > and theres also IEEE ... > > But at least the standard said: > 'Except for assignment and cast (which remove all extra range and precision)' > so we can be sure that BASEFREQ is in double precision > when casted to double. > So, this patch should be OK > > > > > One could use a special value as default like -1 and check for that > > which may be less likely to cause problems with float accuracy and > > rounding in case the cast does not work on some real world case or > > if the risk of it failing on some obscure plaform should be avoided > > Unless the platform which makes this patch useless is reported, > the patch should be OK for workaround. yes nicolas are you ok with this being applied ? (IIRC you objected to it) language lawyering note: in a strict reading the standard the 2 occurances of the constant do probably not need to be parsed with teh same precission nor with precission better or equal than "double". In that case the code from the patch can fail and probably more or less every clean alternative could too [...] -- 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: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avfilter/showcqt: BASEFREQ and ENDFREQ cast to double
Le primidi 11 frimaire, an CCXXIV, Michael Niedermayer a écrit : > nicolas are you ok with this being applied ? (IIRC you objected to it) I am not really satisfied but I do not object. Hopefully it will not break again. 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/showcqt: BASEFREQ and ENDFREQ cast to double
On Tue, Dec 1, 2015 at 10:38 AM, Nicolas George wrote: > Le primidi 11 frimaire, an CCXXIV, Michael Niedermayer a écrit : >> nicolas are you ok with this being applied ? (IIRC you objected to it) > > I am not really satisfied but I do not object. Hopefully it will not break > again. same here - it seems like the heart of the matter is really not well understood, and someone down the road may see the code and wonder why the cast is being done. Hopefully the git blame still points to this change. > > Regards, > > -- > Nicolas George > > ___ > 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] avutil/threadmessage: fix condition broadcasting
Le primidi 11 frimaire, an CCXXIV, Clement Boesch a écrit : > The fix is simply to make sure to notify everyone when work is done (be > it reading or writing). Another solution would be to use 2 distincts > conditions. Another solution would be to document that this API does not support interleaving messages from several threads (nor to, actually). I am fine with either solution, with a slight preference with using two conditions (less spurious wakeups) but it can come later. Your current patch seems fine. Thanks for explaining. I guess I had not thought of several simultaneous writers when convincing myself that a single condition was enough. 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] vp9: always keep s->bytesperpixel and ctx->pix_fmt in sync.
On Tue, Dec 1, 2015 at 4:08 PM, Ronald S. Bultje wrote:
> Fixes mozilla bug 1229128.
> ---
> libavcodec/vp9.c | 43 ++-
> 1 file changed, 22 insertions(+), 21 deletions(-)
>
> diff --git a/libavcodec/vp9.c b/libavcodec/vp9.c
> index d4061e2..9bf746c 100644
> --- a/libavcodec/vp9.c
> +++ b/libavcodec/vp9.c
> @@ -69,6 +69,7 @@ typedef struct VP9Context {
> uint8_t ss_h, ss_v;
> uint8_t last_bpp, bpp, bpp_index, bytesperpixel;
> uint8_t last_keyframe;
> +enum AVPixelFormat last_fmt;
> ThreadFrame next_refs[8];
>
> struct {
> @@ -211,7 +212,7 @@ static int vp9_ref_frame(AVCodecContext *ctx, VP9Frame
> *dst, VP9Frame *src)
> return 0;
> }
>
> -static int update_size(AVCodecContext *ctx, int w, int h, enum AVPixelFormat
> fmt)
> +static int update_size(AVCodecContext *ctx, int w, int h)
> {
> VP9Context *s = ctx->priv_data;
> uint8_t *p;
> @@ -219,12 +220,12 @@ static int update_size(AVCodecContext *ctx, int w, int
> h, enum AVPixelFormat fmt
>
> av_assert0(w > 0 && h > 0);
>
> -if (s->intra_pred_data[0] && w == ctx->width && h == ctx->height &&
> ctx->pix_fmt == fmt)
> +if (s->intra_pred_data[0] && w == ctx->width && h == ctx->height &&
> ctx->pix_fmt == s->last_fmt)
> return 0;
>
> if ((res = ff_set_dimensions(ctx, w, h)) < 0)
> return res;
> -ctx->pix_fmt = fmt;
> +s->last_fmt = ctx->pix_fmt;
> s->sb_cols = (w + 63) >> 6;
> s->sb_rows = (h + 63) >> 6;
> s->cols = (w + 7) >> 3;
> @@ -383,14 +384,13 @@ static int update_prob(VP56RangeCoder *c, int p)
> 255 - inv_recenter_nonneg(inv_map_table[d], 255 - p);
> }
>
> -static enum AVPixelFormat read_colorspace_details(AVCodecContext *ctx)
> +static int read_colorspace_details(AVCodecContext *ctx)
> {
> static const enum AVColorSpace colorspaces[8] = {
> AVCOL_SPC_UNSPECIFIED, AVCOL_SPC_BT470BG, AVCOL_SPC_BT709,
> AVCOL_SPC_SMPTE170M,
> AVCOL_SPC_SMPTE240M, AVCOL_SPC_BT2020_NCL, AVCOL_SPC_RESERVED,
> AVCOL_SPC_RGB,
> };
> VP9Context *s = ctx->priv_data;
> -enum AVPixelFormat res;
> int bits = ctx->profile <= 1 ? 0 : 1 + get_bits1(&s->gb); // 0:8, 1:10,
> 2:12
>
> s->bpp_index = bits;
> @@ -401,10 +401,10 @@ static enum AVPixelFormat
> read_colorspace_details(AVCodecContext *ctx)
> static const enum AVPixelFormat pix_fmt_rgb[3] = {
> AV_PIX_FMT_GBRP, AV_PIX_FMT_GBRP10, AV_PIX_FMT_GBRP12
> };
> +s->ss_h = s->ss_v = 0;
> +ctx->color_range = AVCOL_RANGE_JPEG;
> +ctx->pix_fmt = pix_fmt_rgb[bits];
> if (ctx->profile & 1) {
> -s->ss_h = s->ss_v = 0;
> -res = pix_fmt_rgb[bits];
> -ctx->color_range = AVCOL_RANGE_JPEG;
> if (get_bits1(&s->gb)) {
> av_log(ctx, AV_LOG_ERROR, "Reserved bit set in RGB\n");
> return AVERROR_INVALIDDATA;
> @@ -427,7 +427,8 @@ static enum AVPixelFormat
> read_colorspace_details(AVCodecContext *ctx)
> if (ctx->profile & 1) {
> s->ss_h = get_bits1(&s->gb);
> s->ss_v = get_bits1(&s->gb);
> -if ((res = pix_fmt_for_ss[bits][s->ss_v][s->ss_h]) ==
> AV_PIX_FMT_YUV420P) {
> +ctx->pix_fmt = pix_fmt_for_ss[bits][s->ss_v][s->ss_h];
> +if (ctx->pix_fmt == AV_PIX_FMT_YUV420P) {
> av_log(ctx, AV_LOG_ERROR, "YUV 4:2:0 not supported in
> profile %d\n",
> ctx->profile);
> return AVERROR_INVALIDDATA;
> @@ -438,11 +439,11 @@ static enum AVPixelFormat
> read_colorspace_details(AVCodecContext *ctx)
> }
> } else {
> s->ss_h = s->ss_v = 1;
> -res = pix_fmt_for_ss[bits][1][1];
> +ctx->pix_fmt = pix_fmt_for_ss[bits][1][1];
> }
> }
>
> -return res;
> +return 0;
> }
>
> static int decode_frame_header(AVCodecContext *ctx,
> @@ -450,7 +451,6 @@ static int decode_frame_header(AVCodecContext *ctx,
> {
> VP9Context *s = ctx->priv_data;
> int c, i, j, k, l, m, n, w, h, max, size2, res, sharp;
> -enum AVPixelFormat fmt = ctx->pix_fmt;
> int last_invisible;
> const uint8_t *data2;
>
> @@ -486,8 +486,8 @@ static int decode_frame_header(AVCodecContext *ctx,
> av_log(ctx, AV_LOG_ERROR, "Invalid sync code\n");
> return AVERROR_INVALIDDATA;
> }
> -if ((fmt = read_colorspace_details(ctx)) < 0)
> -return fmt;
> +if ((res = read_colorspace_details(ctx)) < 0)
> +return res;
> // for profile 1, here follows the subsampling bits
> s->s.h.refreshrefmask = 0xff;
> w = get_bits(&s->gb, 16) + 1;
> @@ -503,14 +503,14 @@ static int decode_frame_header(AVCodecContext *ctx,
> return AVERROR_INVALIDDATA;
> }
> if (ctx->profile >= 1) {
> -
Re: [FFmpeg-devel] [PATCH 1/2] avutil/threadmessage: add av_thread_message_flush()
Le decadi 10 frimaire, an CCXXIV, Clement Boesch a écrit :
> From: Clément Bœsch
>
> ---
> libavutil/threadmessage.c | 37 ++---
> libavutil/threadmessage.h | 21 ++---
> 2 files changed, 52 insertions(+), 6 deletions(-)
>
> diff --git a/libavutil/threadmessage.c b/libavutil/threadmessage.c
> index b7fcbe2..87ce8dc 100644
> --- a/libavutil/threadmessage.c
> +++ b/libavutil/threadmessage.c
> @@ -40,14 +40,16 @@ struct AVThreadMessageQueue {
> int err_send;
> int err_recv;
> unsigned elsize;
> +void (*free_func)(void *msg);
> #else
> int dummy;
> #endif
> };
>
> -int av_thread_message_queue_alloc(AVThreadMessageQueue **mq,
> - unsigned nelem,
> - unsigned elsize)
> +int av_thread_message_queue_alloc2(AVThreadMessageQueue **mq,
> + unsigned nelem,
> + unsigned elsize,
> + void (*free_func)(void *msg))
I must say I am not very fond of this aspect of the change, because of
foobar2 and numerous function arguments.
What about having the application set queue->free_func with a second
function if needed, either directly or through
av_thread_message_queue_set_free_func()?
> {
> #if HAVE_THREADS
> AVThreadMessageQueue *rmq;
> @@ -73,6 +75,7 @@ int av_thread_message_queue_alloc(AVThreadMessageQueue **mq,
> return AVERROR(ret);
> }
> rmq->elsize = elsize;
> +rmq->free_func = free_func;
> *mq = rmq;
> return 0;
> #else
> @@ -81,10 +84,18 @@ int av_thread_message_queue_alloc(AVThreadMessageQueue
> **mq,
> #endif /* HAVE_THREADS */
> }
>
> +int av_thread_message_queue_alloc(AVThreadMessageQueue **mq,
> + unsigned nelem,
> + unsigned elsize)
> +{
> +return av_thread_message_queue_alloc2(mq, nelem, elsize, NULL);
> +}
> +
> void av_thread_message_queue_free(AVThreadMessageQueue **mq)
> {
> #if HAVE_THREADS
> if (*mq) {
> +av_thread_message_flush(*mq);
> av_fifo_freep(&(*mq)->fifo);
> pthread_cond_destroy(&(*mq)->cond);
> pthread_mutex_destroy(&(*mq)->lock);
> @@ -182,3 +193,23 @@ void
> av_thread_message_queue_set_err_recv(AVThreadMessageQueue *mq,
> pthread_mutex_unlock(&mq->lock);
> #endif /* HAVE_THREADS */
> }
> +
> +void av_thread_message_flush(AVThreadMessageQueue *mq)
> +{
> +#if HAVE_THREADS
> +int used, off;
> +
> +pthread_mutex_lock(&mq->lock);
> +used = av_fifo_size(mq->fifo);
> +if (mq->free_func) {
> +for (off = 0; off < used; off += mq->elsize) {
> +void *msg;
> +av_fifo_generic_peek_at(mq->fifo, &msg, off, mq->elsize, NULL);
> +mq->free_func(msg);
> +}
> +}
> +av_fifo_drain(mq->fifo, used);
> +pthread_cond_broadcast(&mq->cond);
> +pthread_mutex_unlock(&mq->lock);
> +#endif /* HAVE_THREADS */
> +}
> diff --git a/libavutil/threadmessage.h b/libavutil/threadmessage.h
> index a8481d8..f9004a8 100644
> --- a/libavutil/threadmessage.h
> +++ b/libavutil/threadmessage.h
> @@ -33,17 +33,27 @@ typedef enum AVThreadMessageFlags {
> } AVThreadMessageFlags;
>
> /**
> + * @deprecated use av_thread_message_queue_alloc2 instead
> + */
> +attribute_deprecated
> +int av_thread_message_queue_alloc(AVThreadMessageQueue **mq,
> + unsigned nelem,
> + unsigned elsize);
> +
> +/**
> * Allocate a new message queue.
> *
> * @param mq pointer to the message queue
> * @param nelem maximum number of elements in the queue
> * @param elsize size of each element in the queue
> + * @param free_func free message callback function, can be NULL
> * @return >=0 for success; <0 for error, in particular AVERROR(ENOSYS) if
> * lavu was built without thread support
> */
> -int av_thread_message_queue_alloc(AVThreadMessageQueue **mq,
> - unsigned nelem,
> - unsigned elsize);
> +int av_thread_message_queue_alloc2(AVThreadMessageQueue **mq,
> + unsigned nelem,
> + unsigned elsize,
> + void (*free_func)(void *msg));
>
> /**
> * Free a message queue.
> @@ -88,4 +98,9 @@ void
> av_thread_message_queue_set_err_send(AVThreadMessageQueue *mq,
> void av_thread_message_queue_set_err_recv(AVThreadMessageQueue *mq,
>int err);
>
> +/**
> + * Flush the message queue
> + */
> +void av_thread_message_flush(AVThreadMessageQueue *mq);
Can you explain in the doxy (and to me) how it is better than:
while (av_thread_message_queue_recv_locked(mq, msg,
AV_THREAD_MESSAGE_NONBLOCK))
free_func(msg);
?
> +
> #endif /* AVUTIL_THREADMESSAG
Re: [FFmpeg-devel] [PATCH 5/5] lavfi: make request_frame() non-recursive.
Le decadi 10 frimaire, an CCXXIV, Hendrik Leppkes a écrit :
> We generally just use ints for boolean properties, any particular
> reason this uses unsigned instead?
Just a matter of personal habit, justified below. But as I look at it, I see
it is rather inconsistent with other fields in the struct that are int
although they really would be better unsigned. Will change.
When it does not matter, I usually use unsigned instead of signed because
that often leaves the compiler more room for optimization. For example,
"type half(type x) { return x / 2; }" compiles into this for unsigned:
movl%edi, %eax
shrl%eax
ret
And this for signed:
movl%edi, %eax
movl$2, %ecx
cltd
idivl %ecx
ret
In other words, "x / 2" can be optimized into "x >> 1" for unsigned, but not
for signed because the rounding is not the same for negative.
I suppose in fact you already knew that. Of course it does not make a
difference here, but I prefer this habit instead of the other way around.
For booleans, I feel that int gives the impression there is a third case,
possibly error: think of ssize_t for the return value of syscalls. And if it
becomes a counter, then it should naturally be unsigned.
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/2] avutil/threadmessage: add av_thread_message_flush()
On Tue, Dec 01, 2015 at 05:11:06PM +0100, Nicolas George wrote:
> Le decadi 10 frimaire, an CCXXIV, Clement Boesch a écrit :
> > From: Clément Bœsch
> >
> > ---
> > libavutil/threadmessage.c | 37 ++---
> > libavutil/threadmessage.h | 21 ++---
> > 2 files changed, 52 insertions(+), 6 deletions(-)
> >
> > diff --git a/libavutil/threadmessage.c b/libavutil/threadmessage.c
> > index b7fcbe2..87ce8dc 100644
> > --- a/libavutil/threadmessage.c
> > +++ b/libavutil/threadmessage.c
> > @@ -40,14 +40,16 @@ struct AVThreadMessageQueue {
> > int err_send;
> > int err_recv;
> > unsigned elsize;
> > +void (*free_func)(void *msg);
> > #else
> > int dummy;
> > #endif
> > };
> >
> > -int av_thread_message_queue_alloc(AVThreadMessageQueue **mq,
> > - unsigned nelem,
> > - unsigned elsize)
>
> > +int av_thread_message_queue_alloc2(AVThreadMessageQueue **mq,
> > + unsigned nelem,
> > + unsigned elsize,
> > + void (*free_func)(void *msg))
>
> I must say I am not very fond of this aspect of the change, because of
> foobar2 and numerous function arguments.
>
> What about having the application set queue->free_func with a second
> function if needed, either directly or through
> av_thread_message_queue_set_free_func()?
>
Yeah, sure, no opinion really. Will send a new patch.
[...]
> > +/**
> > + * Flush the message queue
> > + */
> > +void av_thread_message_flush(AVThreadMessageQueue *mq);
>
> Can you explain in the doxy (and to me) how it is better than:
>
> while (av_thread_message_queue_recv_locked(mq, msg,
> AV_THREAD_MESSAGE_NONBLOCK))
> free_func(msg);
>
current:
int used, off;
pthread_mutex_lock(&mq->lock);
used = av_fifo_size(mq->fifo);
if (mq->free_func) {
for (off = 0; off < used; off += mq->elsize) {
void *msg;
av_fifo_generic_peek_at(mq->fifo, &msg, off, mq->elsize, NULL);
mq->free_func(msg);
}
}
av_fifo_drain(mq->fifo, used);
pthread_cond_broadcast(&mq->cond);
pthread_mutex_unlock(&mq->lock);
yours:
void *msg;
pthread_mutex_lock(&mq->lock);
while (av_thread_message_queue_recv_locked(mq, msg,
AV_THREAD_MESSAGE_NONBLOCK))
if (mq->free_func)
mq->free_func(msg);
pthread_mutex_unlock(&mq->lock);
Your suggestion is twice smaller. I don't mind that much but I guess I like
saving a few checks and preventing a bunch of signal broadcasting. Also,
passing the AV_THREAD_MESSAGE_NONBLOCK seems a bit like a (smart) hack to me. I
will pick your solution (which I admit haven't thought of initially) if you
insist, but I prefer my version.
[...]
--
Clément B.
signature.asc
Description: PGP signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/2] avutil/threadmessage: add av_thread_message_flush()
Le primidi 11 frimaire, an CCXXIV, Clement Boesch a écrit : > Your suggestion is twice smaller. I guess I was not clear enough: I was not asking about merits of this implementations over yours, but about the usefulness of the function for the application compared to reading and discarding each message in turn. I guess it is more efficient, but there are probably others, otherwise you would not have bothered. 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 5/5] lavfi: make request_frame() non-recursive.
On Tue, Dec 01, 2015 at 05:26:23PM +0100, Nicolas George wrote:
> Le decadi 10 frimaire, an CCXXIV, Hendrik Leppkes a écrit :
> > We generally just use ints for boolean properties, any particular
> > reason this uses unsigned instead?
>
> Just a matter of personal habit, justified below. But as I look at it, I see
> it is rather inconsistent with other fields in the struct that are int
> although they really would be better unsigned. Will change.
>
>
> When it does not matter, I usually use unsigned instead of signed because
> that often leaves the compiler more room for optimization. For example,
> "type half(type x) { return x / 2; }" compiles into this for unsigned:
>
> movl%edi, %eax
> shrl%eax
> ret
>
> And this for signed:
>
> movl%edi, %eax
> movl$2, %ecx
> cltd
> idivl %ecx
> ret
>
> In other words, "x / 2" can be optimized into "x >> 1" for unsigned, but not
> for signed because the rounding is not the same for negative.
>
> I suppose in fact you already knew that. Of course it does not make a
> difference here, but I prefer this habit instead of the other way around.
> For booleans, I feel that int gives the impression there is a third case,
> possibly error: think of ssize_t for the return value of syscalls. And if it
> becomes a counter, then it should naturally be unsigned.
>
There is at least one case where you actually want it signed, which is
when you loop over it. Typically, in the case of a width/height, you
actually want it signed because it indicates the compiler that an overflow
will not happen since a signed overflow is undefined.
for (x = x_start; x < width; x++)
Here, if we are dealing with signed, the compiler can simply assume that x
will not overflow, go back to 0 and then reach width. See
-Wstrict-overflow compiler option.
Regards,
--
Clément B.
signature.asc
Description: PGP signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/2] avutil/threadmessage: add av_thread_message_flush()
On Tue, Dec 01, 2015 at 05:34:39PM +0100, Nicolas George wrote: > Le primidi 11 frimaire, an CCXXIV, Clement Boesch a écrit : > > Your suggestion is twice smaller. > > I guess I was not clear enough: I was not asking about merits of this > implementations over yours, but about the usefulness of the function for the > application compared to reading and discarding each message in turn. I guess > it is more efficient, but there are probably others, otherwise you would not > have bothered. > Ah. Well then the user can not do it himself since he has no way of acquiring the queue lock (AVThreadMessageQueue is opaque) -- Clément B. signature.asc Description: PGP signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 5/5] lavfi: make request_frame() non-recursive.
On Tue, Dec 1, 2015 at 11:26 AM, Nicolas George wrote:
> Le decadi 10 frimaire, an CCXXIV, Hendrik Leppkes a écrit :
>> We generally just use ints for boolean properties, any particular
>> reason this uses unsigned instead?
>
> Just a matter of personal habit, justified below. But as I look at it, I see
> it is rather inconsistent with other fields in the struct that are int
> although they really would be better unsigned. Will change.
>
>
> When it does not matter, I usually use unsigned instead of signed because
> that often leaves the compiler more room for optimization. For example,
> "type half(type x) { return x / 2; }" compiles into this for unsigned:
>
> movl%edi, %eax
> shrl%eax
> ret
>
> And this for signed:
>
> movl%edi, %eax
> movl$2, %ecx
> cltd
> idivl %ecx
> ret
>
> In other words, "x / 2" can be optimized into "x >> 1" for unsigned, but not
> for signed because the rounding is not the same for negative.
>
> I suppose in fact you already knew that. Of course it does not make a
> difference here, but I prefer this habit instead of the other way around.
> For booleans, I feel that int gives the impression there is a third case,
> possibly error: think of ssize_t for the return value of syscalls. And if it
> becomes a counter, then it should naturally be unsigned.
All true, but note the bizarre GCC bug I posted regarding perf
regression for unsigned vs signed counters:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=48052
May be related to Clement's point below.
>
> Regards,
>
> --
> Nicolas George
>
> ___
> 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] vp9: always keep s->bytesperpixel and ctx->pix_fmt in sync.
Hi,
On Tue, Dec 1, 2015 at 11:09 AM, Hendrik Leppkes
wrote:
> On Tue, Dec 1, 2015 at 4:08 PM, Ronald S. Bultje
> wrote:
> > Fixes mozilla bug 1229128.
> > ---
> > libavcodec/vp9.c | 43 ++-
> > 1 file changed, 22 insertions(+), 21 deletions(-)
> >
> > diff --git a/libavcodec/vp9.c b/libavcodec/vp9.c
> > index d4061e2..9bf746c 100644
> > --- a/libavcodec/vp9.c
> > +++ b/libavcodec/vp9.c
> > @@ -69,6 +69,7 @@ typedef struct VP9Context {
> > uint8_t ss_h, ss_v;
> > uint8_t last_bpp, bpp, bpp_index, bytesperpixel;
> > uint8_t last_keyframe;
> > +enum AVPixelFormat last_fmt;
> > ThreadFrame next_refs[8];
> >
> > struct {
> > @@ -211,7 +212,7 @@ static int vp9_ref_frame(AVCodecContext *ctx,
> VP9Frame *dst, VP9Frame *src)
> > return 0;
> > }
> >
> > -static int update_size(AVCodecContext *ctx, int w, int h, enum
> AVPixelFormat fmt)
> > +static int update_size(AVCodecContext *ctx, int w, int h)
> > {
> > VP9Context *s = ctx->priv_data;
> > uint8_t *p;
> > @@ -219,12 +220,12 @@ static int update_size(AVCodecContext *ctx, int w,
> int h, enum AVPixelFormat fmt
> >
> > av_assert0(w > 0 && h > 0);
> >
> > -if (s->intra_pred_data[0] && w == ctx->width && h == ctx->height &&
> ctx->pix_fmt == fmt)
> > +if (s->intra_pred_data[0] && w == ctx->width && h == ctx->height &&
> ctx->pix_fmt == s->last_fmt)
> > return 0;
> >
> > if ((res = ff_set_dimensions(ctx, w, h)) < 0)
> > return res;
> > -ctx->pix_fmt = fmt;
> > +s->last_fmt = ctx->pix_fmt;
> > s->sb_cols = (w + 63) >> 6;
> > s->sb_rows = (h + 63) >> 6;
> > s->cols = (w + 7) >> 3;
> > @@ -383,14 +384,13 @@ static int update_prob(VP56RangeCoder *c, int p)
> > 255 - inv_recenter_nonneg(inv_map_table[d], 255 -
> p);
> > }
> >
> > -static enum AVPixelFormat read_colorspace_details(AVCodecContext *ctx)
> > +static int read_colorspace_details(AVCodecContext *ctx)
> > {
> > static const enum AVColorSpace colorspaces[8] = {
> > AVCOL_SPC_UNSPECIFIED, AVCOL_SPC_BT470BG, AVCOL_SPC_BT709,
> AVCOL_SPC_SMPTE170M,
> > AVCOL_SPC_SMPTE240M, AVCOL_SPC_BT2020_NCL, AVCOL_SPC_RESERVED,
> AVCOL_SPC_RGB,
> > };
> > VP9Context *s = ctx->priv_data;
> > -enum AVPixelFormat res;
> > int bits = ctx->profile <= 1 ? 0 : 1 + get_bits1(&s->gb); // 0:8,
> 1:10, 2:12
> >
> > s->bpp_index = bits;
> > @@ -401,10 +401,10 @@ static enum AVPixelFormat
> read_colorspace_details(AVCodecContext *ctx)
> > static const enum AVPixelFormat pix_fmt_rgb[3] = {
> > AV_PIX_FMT_GBRP, AV_PIX_FMT_GBRP10, AV_PIX_FMT_GBRP12
> > };
> > +s->ss_h = s->ss_v = 0;
> > +ctx->color_range = AVCOL_RANGE_JPEG;
> > +ctx->pix_fmt = pix_fmt_rgb[bits];
> > if (ctx->profile & 1) {
> > -s->ss_h = s->ss_v = 0;
> > -res = pix_fmt_rgb[bits];
> > -ctx->color_range = AVCOL_RANGE_JPEG;
> > if (get_bits1(&s->gb)) {
> > av_log(ctx, AV_LOG_ERROR, "Reserved bit set in RGB\n");
> > return AVERROR_INVALIDDATA;
> > @@ -427,7 +427,8 @@ static enum AVPixelFormat
> read_colorspace_details(AVCodecContext *ctx)
> > if (ctx->profile & 1) {
> > s->ss_h = get_bits1(&s->gb);
> > s->ss_v = get_bits1(&s->gb);
> > -if ((res = pix_fmt_for_ss[bits][s->ss_v][s->ss_h]) ==
> AV_PIX_FMT_YUV420P) {
> > +ctx->pix_fmt = pix_fmt_for_ss[bits][s->ss_v][s->ss_h];
> > +if (ctx->pix_fmt == AV_PIX_FMT_YUV420P) {
> > av_log(ctx, AV_LOG_ERROR, "YUV 4:2:0 not supported in
> profile %d\n",
> > ctx->profile);
> > return AVERROR_INVALIDDATA;
> > @@ -438,11 +439,11 @@ static enum AVPixelFormat
> read_colorspace_details(AVCodecContext *ctx)
> > }
> > } else {
> > s->ss_h = s->ss_v = 1;
> > -res = pix_fmt_for_ss[bits][1][1];
> > +ctx->pix_fmt = pix_fmt_for_ss[bits][1][1];
> > }
> > }
> >
> > -return res;
> > +return 0;
> > }
> >
> > static int decode_frame_header(AVCodecContext *ctx,
> > @@ -450,7 +451,6 @@ static int decode_frame_header(AVCodecContext *ctx,
> > {
> > VP9Context *s = ctx->priv_data;
> > int c, i, j, k, l, m, n, w, h, max, size2, res, sharp;
> > -enum AVPixelFormat fmt = ctx->pix_fmt;
> > int last_invisible;
> > const uint8_t *data2;
> >
> > @@ -486,8 +486,8 @@ static int decode_frame_header(AVCodecContext *ctx,
> > av_log(ctx, AV_LOG_ERROR, "Invalid sync code\n");
> > return AVERROR_INVALIDDATA;
> > }
> > -if ((fmt = read_colorspace_details(ctx)) < 0)
> > -return fmt;
> > +if ((res = read_colorspace_details(ctx)) < 0)
> > +return res;
> > // for profile 1, here follows the subsampling bi
[FFmpeg-devel] [PATCH] vp9: always keep s->bytesperpixel and ctx->pix_fmt in sync.
Fixes mozilla bug 1229128.
---
libavcodec/vp9.c | 43 ++-
1 file changed, 22 insertions(+), 21 deletions(-)
diff --git a/libavcodec/vp9.c b/libavcodec/vp9.c
index d4061e2..dc0 100644
--- a/libavcodec/vp9.c
+++ b/libavcodec/vp9.c
@@ -69,6 +69,7 @@ typedef struct VP9Context {
uint8_t ss_h, ss_v;
uint8_t last_bpp, bpp, bpp_index, bytesperpixel;
uint8_t last_keyframe;
+enum AVPixelFormat pix_fmt, last_fmt;
ThreadFrame next_refs[8];
struct {
@@ -211,7 +212,7 @@ static int vp9_ref_frame(AVCodecContext *ctx, VP9Frame
*dst, VP9Frame *src)
return 0;
}
-static int update_size(AVCodecContext *ctx, int w, int h, enum AVPixelFormat
fmt)
+static int update_size(AVCodecContext *ctx, int w, int h)
{
VP9Context *s = ctx->priv_data;
uint8_t *p;
@@ -219,12 +220,12 @@ static int update_size(AVCodecContext *ctx, int w, int h,
enum AVPixelFormat fmt
av_assert0(w > 0 && h > 0);
-if (s->intra_pred_data[0] && w == ctx->width && h == ctx->height &&
ctx->pix_fmt == fmt)
+if (s->intra_pred_data[0] && w == ctx->width && h == ctx->height &&
s->pix_fmt == s->last_fmt)
return 0;
if ((res = ff_set_dimensions(ctx, w, h)) < 0)
return res;
-ctx->pix_fmt = fmt;
+s->last_fmt = ctx->pix_fmt = s->pix_fmt;
s->sb_cols = (w + 63) >> 6;
s->sb_rows = (h + 63) >> 6;
s->cols = (w + 7) >> 3;
@@ -383,14 +384,13 @@ static int update_prob(VP56RangeCoder *c, int p)
255 - inv_recenter_nonneg(inv_map_table[d], 255 - p);
}
-static enum AVPixelFormat read_colorspace_details(AVCodecContext *ctx)
+static int read_colorspace_details(AVCodecContext *ctx)
{
static const enum AVColorSpace colorspaces[8] = {
AVCOL_SPC_UNSPECIFIED, AVCOL_SPC_BT470BG, AVCOL_SPC_BT709,
AVCOL_SPC_SMPTE170M,
AVCOL_SPC_SMPTE240M, AVCOL_SPC_BT2020_NCL, AVCOL_SPC_RESERVED,
AVCOL_SPC_RGB,
};
VP9Context *s = ctx->priv_data;
-enum AVPixelFormat res;
int bits = ctx->profile <= 1 ? 0 : 1 + get_bits1(&s->gb); // 0:8, 1:10,
2:12
s->bpp_index = bits;
@@ -401,10 +401,10 @@ static enum AVPixelFormat
read_colorspace_details(AVCodecContext *ctx)
static const enum AVPixelFormat pix_fmt_rgb[3] = {
AV_PIX_FMT_GBRP, AV_PIX_FMT_GBRP10, AV_PIX_FMT_GBRP12
};
+s->ss_h = s->ss_v = 0;
+ctx->color_range = AVCOL_RANGE_JPEG;
+s->pix_fmt = pix_fmt_rgb[bits];
if (ctx->profile & 1) {
-s->ss_h = s->ss_v = 0;
-res = pix_fmt_rgb[bits];
-ctx->color_range = AVCOL_RANGE_JPEG;
if (get_bits1(&s->gb)) {
av_log(ctx, AV_LOG_ERROR, "Reserved bit set in RGB\n");
return AVERROR_INVALIDDATA;
@@ -427,7 +427,8 @@ static enum AVPixelFormat
read_colorspace_details(AVCodecContext *ctx)
if (ctx->profile & 1) {
s->ss_h = get_bits1(&s->gb);
s->ss_v = get_bits1(&s->gb);
-if ((res = pix_fmt_for_ss[bits][s->ss_v][s->ss_h]) ==
AV_PIX_FMT_YUV420P) {
+s->pix_fmt = pix_fmt_for_ss[bits][s->ss_v][s->ss_h];
+if (s->pix_fmt == AV_PIX_FMT_YUV420P) {
av_log(ctx, AV_LOG_ERROR, "YUV 4:2:0 not supported in profile
%d\n",
ctx->profile);
return AVERROR_INVALIDDATA;
@@ -438,11 +439,11 @@ static enum AVPixelFormat
read_colorspace_details(AVCodecContext *ctx)
}
} else {
s->ss_h = s->ss_v = 1;
-res = pix_fmt_for_ss[bits][1][1];
+s->pix_fmt = pix_fmt_for_ss[bits][1][1];
}
}
-return res;
+return 0;
}
static int decode_frame_header(AVCodecContext *ctx,
@@ -450,7 +451,6 @@ static int decode_frame_header(AVCodecContext *ctx,
{
VP9Context *s = ctx->priv_data;
int c, i, j, k, l, m, n, w, h, max, size2, res, sharp;
-enum AVPixelFormat fmt = ctx->pix_fmt;
int last_invisible;
const uint8_t *data2;
@@ -486,8 +486,8 @@ static int decode_frame_header(AVCodecContext *ctx,
av_log(ctx, AV_LOG_ERROR, "Invalid sync code\n");
return AVERROR_INVALIDDATA;
}
-if ((fmt = read_colorspace_details(ctx)) < 0)
-return fmt;
+if ((res = read_colorspace_details(ctx)) < 0)
+return res;
// for profile 1, here follows the subsampling bits
s->s.h.refreshrefmask = 0xff;
w = get_bits(&s->gb, 16) + 1;
@@ -503,14 +503,14 @@ static int decode_frame_header(AVCodecContext *ctx,
return AVERROR_INVALIDDATA;
}
if (ctx->profile >= 1) {
-if ((fmt = read_colorspace_details(ctx)) < 0)
-return fmt;
+if ((res = read_colorspace_details(ctx)) < 0)
+return res;
} else {
s->ss_h = s->ss_v = 1;
s->bpp = 8;
s
Re: [FFmpeg-devel] [PATCH] vp9: always keep s->bytesperpixel and ctx->pix_fmt in sync.
On Tue, Dec 1, 2015 at 6:24 PM, Ronald S. Bultje wrote:
> Fixes mozilla bug 1229128.
> ---
> libavcodec/vp9.c | 43 ++-
> 1 file changed, 22 insertions(+), 21 deletions(-)
>
> diff --git a/libavcodec/vp9.c b/libavcodec/vp9.c
> index d4061e2..dc0 100644
> --- a/libavcodec/vp9.c
> +++ b/libavcodec/vp9.c
> @@ -69,6 +69,7 @@ typedef struct VP9Context {
> uint8_t ss_h, ss_v;
> uint8_t last_bpp, bpp, bpp_index, bytesperpixel;
> uint8_t last_keyframe;
> +enum AVPixelFormat pix_fmt, last_fmt;
> ThreadFrame next_refs[8];
>
> struct {
> @@ -211,7 +212,7 @@ static int vp9_ref_frame(AVCodecContext *ctx, VP9Frame
> *dst, VP9Frame *src)
> return 0;
> }
>
> -static int update_size(AVCodecContext *ctx, int w, int h, enum AVPixelFormat
> fmt)
> +static int update_size(AVCodecContext *ctx, int w, int h)
> {
> VP9Context *s = ctx->priv_data;
> uint8_t *p;
> @@ -219,12 +220,12 @@ static int update_size(AVCodecContext *ctx, int w, int
> h, enum AVPixelFormat fmt
>
> av_assert0(w > 0 && h > 0);
>
> -if (s->intra_pred_data[0] && w == ctx->width && h == ctx->height &&
> ctx->pix_fmt == fmt)
> +if (s->intra_pred_data[0] && w == ctx->width && h == ctx->height &&
> s->pix_fmt == s->last_fmt)
> return 0;
>
> if ((res = ff_set_dimensions(ctx, w, h)) < 0)
> return res;
> -ctx->pix_fmt = fmt;
> +s->last_fmt = ctx->pix_fmt = s->pix_fmt;
> s->sb_cols = (w + 63) >> 6;
> s->sb_rows = (h + 63) >> 6;
> s->cols = (w + 7) >> 3;
> @@ -383,14 +384,13 @@ static int update_prob(VP56RangeCoder *c, int p)
> 255 - inv_recenter_nonneg(inv_map_table[d], 255 - p);
> }
>
> -static enum AVPixelFormat read_colorspace_details(AVCodecContext *ctx)
> +static int read_colorspace_details(AVCodecContext *ctx)
> {
> static const enum AVColorSpace colorspaces[8] = {
> AVCOL_SPC_UNSPECIFIED, AVCOL_SPC_BT470BG, AVCOL_SPC_BT709,
> AVCOL_SPC_SMPTE170M,
> AVCOL_SPC_SMPTE240M, AVCOL_SPC_BT2020_NCL, AVCOL_SPC_RESERVED,
> AVCOL_SPC_RGB,
> };
> VP9Context *s = ctx->priv_data;
> -enum AVPixelFormat res;
> int bits = ctx->profile <= 1 ? 0 : 1 + get_bits1(&s->gb); // 0:8, 1:10,
> 2:12
>
> s->bpp_index = bits;
> @@ -401,10 +401,10 @@ static enum AVPixelFormat
> read_colorspace_details(AVCodecContext *ctx)
> static const enum AVPixelFormat pix_fmt_rgb[3] = {
> AV_PIX_FMT_GBRP, AV_PIX_FMT_GBRP10, AV_PIX_FMT_GBRP12
> };
> +s->ss_h = s->ss_v = 0;
> +ctx->color_range = AVCOL_RANGE_JPEG;
> +s->pix_fmt = pix_fmt_rgb[bits];
> if (ctx->profile & 1) {
> -s->ss_h = s->ss_v = 0;
> -res = pix_fmt_rgb[bits];
> -ctx->color_range = AVCOL_RANGE_JPEG;
> if (get_bits1(&s->gb)) {
> av_log(ctx, AV_LOG_ERROR, "Reserved bit set in RGB\n");
> return AVERROR_INVALIDDATA;
> @@ -427,7 +427,8 @@ static enum AVPixelFormat
> read_colorspace_details(AVCodecContext *ctx)
> if (ctx->profile & 1) {
> s->ss_h = get_bits1(&s->gb);
> s->ss_v = get_bits1(&s->gb);
> -if ((res = pix_fmt_for_ss[bits][s->ss_v][s->ss_h]) ==
> AV_PIX_FMT_YUV420P) {
> +s->pix_fmt = pix_fmt_for_ss[bits][s->ss_v][s->ss_h];
> +if (s->pix_fmt == AV_PIX_FMT_YUV420P) {
> av_log(ctx, AV_LOG_ERROR, "YUV 4:2:0 not supported in
> profile %d\n",
> ctx->profile);
> return AVERROR_INVALIDDATA;
> @@ -438,11 +439,11 @@ static enum AVPixelFormat
> read_colorspace_details(AVCodecContext *ctx)
> }
> } else {
> s->ss_h = s->ss_v = 1;
> -res = pix_fmt_for_ss[bits][1][1];
> +s->pix_fmt = pix_fmt_for_ss[bits][1][1];
> }
> }
>
> -return res;
> +return 0;
> }
>
> static int decode_frame_header(AVCodecContext *ctx,
> @@ -450,7 +451,6 @@ static int decode_frame_header(AVCodecContext *ctx,
> {
> VP9Context *s = ctx->priv_data;
> int c, i, j, k, l, m, n, w, h, max, size2, res, sharp;
> -enum AVPixelFormat fmt = ctx->pix_fmt;
> int last_invisible;
> const uint8_t *data2;
>
> @@ -486,8 +486,8 @@ static int decode_frame_header(AVCodecContext *ctx,
> av_log(ctx, AV_LOG_ERROR, "Invalid sync code\n");
> return AVERROR_INVALIDDATA;
> }
> -if ((fmt = read_colorspace_details(ctx)) < 0)
> -return fmt;
> +if ((res = read_colorspace_details(ctx)) < 0)
> +return res;
> // for profile 1, here follows the subsampling bits
> s->s.h.refreshrefmask = 0xff;
> w = get_bits(&s->gb, 16) + 1;
> @@ -503,14 +503,14 @@ static int decode_frame_header(AVCodecContext *ctx,
> return AVERROR_INVALIDDATA;
> }
> if (ctx->profile >= 1) {
> -
Re: [FFmpeg-devel] [PATCH 1/2] avutil/threadmessage: add av_thread_message_flush()
Le primidi 11 frimaire, an CCXXIV, Clement Boesch a écrit : > Ah. Well then the user can not do it himself since he has no way of > acquiring the queue lock (AVThreadMessageQueue is opaque) Yes, but why does it matter, if the elements are to be discarded anyway. Ah, I think I see a point: this API is for the sender, not the receiver, and you are afraid that the receiver can read one element in the middle while the sender is flushing. Is that 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] vp9: always keep s->bytesperpixel and ctx->pix_fmt in sync.
Hi,
On Tue, Dec 1, 2015 at 12:34 PM, Hendrik Leppkes
wrote:
> On Tue, Dec 1, 2015 at 6:24 PM, Ronald S. Bultje
> wrote:
> > Fixes mozilla bug 1229128.
> > ---
> > libavcodec/vp9.c | 43 ++-
> > 1 file changed, 22 insertions(+), 21 deletions(-)
> >
> > diff --git a/libavcodec/vp9.c b/libavcodec/vp9.c
> > index d4061e2..dc0 100644
> > --- a/libavcodec/vp9.c
> > +++ b/libavcodec/vp9.c
> > @@ -69,6 +69,7 @@ typedef struct VP9Context {
> > uint8_t ss_h, ss_v;
> > uint8_t last_bpp, bpp, bpp_index, bytesperpixel;
> > uint8_t last_keyframe;
> > +enum AVPixelFormat pix_fmt, last_fmt;
> > ThreadFrame next_refs[8];
> >
> > struct {
> > @@ -211,7 +212,7 @@ static int vp9_ref_frame(AVCodecContext *ctx,
> VP9Frame *dst, VP9Frame *src)
> > return 0;
> > }
> >
> > -static int update_size(AVCodecContext *ctx, int w, int h, enum
> AVPixelFormat fmt)
> > +static int update_size(AVCodecContext *ctx, int w, int h)
> > {
> > VP9Context *s = ctx->priv_data;
> > uint8_t *p;
> > @@ -219,12 +220,12 @@ static int update_size(AVCodecContext *ctx, int w,
> int h, enum AVPixelFormat fmt
> >
> > av_assert0(w > 0 && h > 0);
> >
> > -if (s->intra_pred_data[0] && w == ctx->width && h == ctx->height &&
> ctx->pix_fmt == fmt)
> > +if (s->intra_pred_data[0] && w == ctx->width && h == ctx->height &&
> s->pix_fmt == s->last_fmt)
> > return 0;
> >
> > if ((res = ff_set_dimensions(ctx, w, h)) < 0)
> > return res;
> > -ctx->pix_fmt = fmt;
> > +s->last_fmt = ctx->pix_fmt = s->pix_fmt;
> > s->sb_cols = (w + 63) >> 6;
> > s->sb_rows = (h + 63) >> 6;
> > s->cols = (w + 7) >> 3;
> > @@ -383,14 +384,13 @@ static int update_prob(VP56RangeCoder *c, int p)
> > 255 - inv_recenter_nonneg(inv_map_table[d], 255 -
> p);
> > }
> >
> > -static enum AVPixelFormat read_colorspace_details(AVCodecContext *ctx)
> > +static int read_colorspace_details(AVCodecContext *ctx)
> > {
> > static const enum AVColorSpace colorspaces[8] = {
> > AVCOL_SPC_UNSPECIFIED, AVCOL_SPC_BT470BG, AVCOL_SPC_BT709,
> AVCOL_SPC_SMPTE170M,
> > AVCOL_SPC_SMPTE240M, AVCOL_SPC_BT2020_NCL, AVCOL_SPC_RESERVED,
> AVCOL_SPC_RGB,
> > };
> > VP9Context *s = ctx->priv_data;
> > -enum AVPixelFormat res;
> > int bits = ctx->profile <= 1 ? 0 : 1 + get_bits1(&s->gb); // 0:8,
> 1:10, 2:12
> >
> > s->bpp_index = bits;
> > @@ -401,10 +401,10 @@ static enum AVPixelFormat
> read_colorspace_details(AVCodecContext *ctx)
> > static const enum AVPixelFormat pix_fmt_rgb[3] = {
> > AV_PIX_FMT_GBRP, AV_PIX_FMT_GBRP10, AV_PIX_FMT_GBRP12
> > };
> > +s->ss_h = s->ss_v = 0;
> > +ctx->color_range = AVCOL_RANGE_JPEG;
> > +s->pix_fmt = pix_fmt_rgb[bits];
> > if (ctx->profile & 1) {
> > -s->ss_h = s->ss_v = 0;
> > -res = pix_fmt_rgb[bits];
> > -ctx->color_range = AVCOL_RANGE_JPEG;
> > if (get_bits1(&s->gb)) {
> > av_log(ctx, AV_LOG_ERROR, "Reserved bit set in RGB\n");
> > return AVERROR_INVALIDDATA;
> > @@ -427,7 +427,8 @@ static enum AVPixelFormat
> read_colorspace_details(AVCodecContext *ctx)
> > if (ctx->profile & 1) {
> > s->ss_h = get_bits1(&s->gb);
> > s->ss_v = get_bits1(&s->gb);
> > -if ((res = pix_fmt_for_ss[bits][s->ss_v][s->ss_h]) ==
> AV_PIX_FMT_YUV420P) {
> > +s->pix_fmt = pix_fmt_for_ss[bits][s->ss_v][s->ss_h];
> > +if (s->pix_fmt == AV_PIX_FMT_YUV420P) {
> > av_log(ctx, AV_LOG_ERROR, "YUV 4:2:0 not supported in
> profile %d\n",
> > ctx->profile);
> > return AVERROR_INVALIDDATA;
> > @@ -438,11 +439,11 @@ static enum AVPixelFormat
> read_colorspace_details(AVCodecContext *ctx)
> > }
> > } else {
> > s->ss_h = s->ss_v = 1;
> > -res = pix_fmt_for_ss[bits][1][1];
> > +s->pix_fmt = pix_fmt_for_ss[bits][1][1];
> > }
> > }
> >
> > -return res;
> > +return 0;
> > }
> >
> > static int decode_frame_header(AVCodecContext *ctx,
> > @@ -450,7 +451,6 @@ static int decode_frame_header(AVCodecContext *ctx,
> > {
> > VP9Context *s = ctx->priv_data;
> > int c, i, j, k, l, m, n, w, h, max, size2, res, sharp;
> > -enum AVPixelFormat fmt = ctx->pix_fmt;
> > int last_invisible;
> > const uint8_t *data2;
> >
> > @@ -486,8 +486,8 @@ static int decode_frame_header(AVCodecContext *ctx,
> > av_log(ctx, AV_LOG_ERROR, "Invalid sync code\n");
> > return AVERROR_INVALIDDATA;
> > }
> > -if ((fmt = read_colorspace_details(ctx)) < 0)
> > -return fmt;
> > +if ((res = read_colorspace_details(ctx)) < 0)
> > +return res;
> > // for profile 1, here follows the su
[FFmpeg-devel] [PATCH] avfilter/vf_shuffleframes: Assert that the case of an uninitialized ret does not occur
From: Michael Niedermayer
Fixes CID1258479
Signed-off-by: Michael Niedermayer
---
libavfilter/vf_shuffleframes.c |8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/libavfilter/vf_shuffleframes.c b/libavfilter/vf_shuffleframes.c
index 041429f..f49c9c6 100644
--- a/libavfilter/vf_shuffleframes.c
+++ b/libavfilter/vf_shuffleframes.c
@@ -18,6 +18,7 @@
* Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA
*/
+#include "libavutil/avassert.h"
#include "libavutil/avstring.h"
#include "libavutil/common.h"
#include "libavutil/internal.h"
@@ -90,9 +91,7 @@ static int filter_frame(AVFilterLink *inlink, AVFrame *frame)
s->pts[s->in_frames] = frame->pts;
s->in_frames++;
ret = 0;
-}
-
-if (s->in_frames == s->nb_frames) {
+} else if (s->in_frames == s->nb_frames) {
int n, x;
for (n = 0; n < s->nb_frames; n++) {
@@ -109,7 +108,8 @@ static int filter_frame(AVFilterLink *inlink, AVFrame
*frame)
for (n = 0; n < s->nb_frames; n++)
av_frame_free(&s->frames[n]);
-}
+} else
+av_assert0(0);
return ret;
}
--
1.7.9.5
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avformat/mp3dec: prefer "fast_seek" to TOC seek for CBR files.
Thanks wm4, next patch will fix that declaration.
Michael, any concerns?
On Mon, Nov 30, 2015 at 2:51 PM, wm4 wrote:
> On Mon, 30 Nov 2015 14:29:50 -0800
> chcunning...@chromium.org wrote:
>
> > From: Chris Cunningham
> >
> > "Fast seek" uses linear interpolation to find the position of the
> > requested seek time. For CBR this is more direct than using the
> > mp3 TOC and bypassing the TOC avoids problems with TOC precision.
> > (see https://crbug.com/545914#c13)
> >
> > For VBR, fast seek is not precise, so continue to prefer the TOC
> > when available (the lesser of two evils).
> >
> > Also, some re-ordering of the logic in mp3_seek to simplify and
> > give usetoc=1 precedence over fastseek flag.
> > ---
> > libavformat/mp3dec.c| 42 --
> > libavformat/seek-test.c | 8 +---
> > tests/fate/seek.mak | 2 +-
> > 3 files changed, 26 insertions(+), 26 deletions(-)
> >
> > diff --git a/libavformat/mp3dec.c b/libavformat/mp3dec.c
> > index 32ca00c..3dc2b5c 100644
> > --- a/libavformat/mp3dec.c
> > +++ b/libavformat/mp3dec.c
> > @@ -115,7 +115,8 @@ static void read_xing_toc(AVFormatContext *s,
> int64_t filesize, int64_t duration
> > {
> > int i;
> > MP3DecContext *mp3 = s->priv_data;
> > -int fill_index = mp3->usetoc == 1 && duration > 0;
> > +int fast_seek = s->flags & AVFMT_FLAG_FAST_SEEK;
> > +int fill_index = (mp3->usetoc || fast_seek) && duration > 0;
> >
> > if (!filesize &&
> > !(filesize = avio_size(s->pb))) {
> > @@ -344,9 +345,6 @@ static int mp3_read_header(AVFormatContext *s)
> > int ret;
> > int i;
> >
> > -if (mp3->usetoc < 0)
> > -mp3->usetoc = (s->flags & AVFMT_FLAG_FAST_SEEK) ? 1 : 2;
> > -
> > st = avformat_new_stream(s, NULL);
> > if (!st)
> > return AVERROR(ENOMEM);
> > @@ -501,38 +499,38 @@ static int mp3_seek(AVFormatContext *s, int
> stream_index, int64_t timestamp,
> > MP3DecContext *mp3 = s->priv_data;
> > AVIndexEntry *ie, ie1;
> > AVStream *st = s->streams[0];
> > -int64_t ret = av_index_search_timestamp(st, timestamp, flags);
> > -int64_t best_pos;
> > -int fast_seek = (s->flags & AVFMT_FLAG_FAST_SEEK) ? 1 : 0;
> > +int fast_seek = s->flags & AVFMT_FLAG_FAST_SEEK;
> > int64_t filesize = mp3->header_filesize;
> >
> > -if (mp3->usetoc == 2)
> > -return -1; // generic index code
> > -
> > if (filesize <= 0) {
> > int64_t size = avio_size(s->pb);
> > if (size > 0 && size > s->internal->data_offset)
> > filesize = size - s->internal->data_offset;
> > }
> >
> > -if ( (mp3->is_cbr || fast_seek)
> > -&& (mp3->usetoc == 0 || !mp3->xing_toc)
> > -&& st->duration > 0
> > -&& filesize > 0) {
> > -ie = &ie1;
> > -timestamp = av_clip64(timestamp, 0, st->duration);
> > -ie->timestamp = timestamp;
> > -ie->pos = av_rescale(timestamp, filesize, st->duration) +
> s->internal->data_offset;
> > -} else if (mp3->xing_toc) {
> > +if (mp3->xing_toc && (mp3->usetoc || (fast_seek && !mp3->is_cbr))) {
> > +// NOTE: The MP3 TOC is not a precise lookup table. Accuracy is
> worse
> > +// for bigger files.
> > +av_log(s, AV_LOG_WARNING, "Using MP3 TOC to seek; may be
> imprecise.\n");
> > +
> > +int64_t ret = av_index_search_timestamp(st, timestamp, flags);
> > if (ret < 0)
> > return ret;
> >
> > ie = &st->index_entries[ret];
> > +} else if (fast_seek && st->duration > 0 && filesize > 0) {
> > +if (!mp3->is_cbr)
> > +av_log(s, AV_LOG_WARNING, "Using scaling to seek VBR MP3;
> may be imprecise.\n");
> > +
> > +ie = &ie1;
> > +timestamp = av_clip64(timestamp, 0, st->duration);
> > +ie->timestamp = timestamp;
> > +ie->pos = av_rescale(timestamp, filesize, st->duration) +
> s->internal->data_offset;
> > } else {
> > -return -1;
> > +return -1; // generic index code
> > }
> >
> > -best_pos = mp3_sync(s, ie->pos, flags);
> > +int64_t best_pos = mp3_sync(s, ie->pos, flags);
>
> We don't like having declarations after statements.
>
> > if (best_pos < 0)
> > return best_pos;
> >
> > @@ -546,7 +544,7 @@ static int mp3_seek(AVFormatContext *s, int
> stream_index, int64_t timestamp,
> > }
> >
> > static const AVOption options[] = {
> > -{ "usetoc", "use table of contents", offsetof(MP3DecContext,
> usetoc), AV_OPT_TYPE_INT, {.i64 = -1}, -1, 2, AV_OPT_FLAG_DECODING_PARAM},
> > +{ "usetoc", "use table of contents", offsetof(MP3DecContext,
> usetoc), AV_OPT_TYPE_INT, {.i64 = 0}, 0, 1, AV_OPT_FLAG_DECODING_PARAM},
> > { NULL },
> > };
> >
> > diff --git a/libavformat/seek-test.c b/libavformat/seek-test.c
> > index 1926f21..bfd06db 100644
> > --- a/libavformat/seek-test.c
> > +++ b/libavformat/seek-test.c
> > @@ -56,7 +56,7 @@ static void ts_s
[FFmpeg-devel] [PATCH] avformat/mp3dec: prefer "fast_seek" to TOC seek for CBR files.
From: Chris Cunningham
"Fast seek" uses linear interpolation to find the position of the
requested seek time. For CBR this is more direct than using the
mp3 TOC and bypassing the TOC avoids problems with TOC precision.
(see https://crbug.com/545914#c13)
For VBR, fast seek is not precise, so continue to prefer the TOC
when available (the lesser of two evils).
Also, some re-ordering of the logic in mp3_seek to simplify and
give usetoc=1 precedence over fastseek flag.
---
libavformat/mp3dec.c| 39 +++
libavformat/seek-test.c | 8 +---
tests/fate/seek.mak | 2 +-
3 files changed, 25 insertions(+), 24 deletions(-)
diff --git a/libavformat/mp3dec.c b/libavformat/mp3dec.c
index 32ca00c..04c9861 100644
--- a/libavformat/mp3dec.c
+++ b/libavformat/mp3dec.c
@@ -115,7 +115,8 @@ static void read_xing_toc(AVFormatContext *s, int64_t
filesize, int64_t duration
{
int i;
MP3DecContext *mp3 = s->priv_data;
-int fill_index = mp3->usetoc == 1 && duration > 0;
+int fast_seek = s->flags & AVFMT_FLAG_FAST_SEEK;
+int fill_index = (mp3->usetoc || fast_seek) && duration > 0;
if (!filesize &&
!(filesize = avio_size(s->pb))) {
@@ -344,9 +345,6 @@ static int mp3_read_header(AVFormatContext *s)
int ret;
int i;
-if (mp3->usetoc < 0)
-mp3->usetoc = (s->flags & AVFMT_FLAG_FAST_SEEK) ? 1 : 2;
-
st = avformat_new_stream(s, NULL);
if (!st)
return AVERROR(ENOMEM);
@@ -501,35 +499,36 @@ static int mp3_seek(AVFormatContext *s, int stream_index,
int64_t timestamp,
MP3DecContext *mp3 = s->priv_data;
AVIndexEntry *ie, ie1;
AVStream *st = s->streams[0];
-int64_t ret = av_index_search_timestamp(st, timestamp, flags);
int64_t best_pos;
-int fast_seek = (s->flags & AVFMT_FLAG_FAST_SEEK) ? 1 : 0;
+int fast_seek = s->flags & AVFMT_FLAG_FAST_SEEK;
int64_t filesize = mp3->header_filesize;
-if (mp3->usetoc == 2)
-return -1; // generic index code
-
if (filesize <= 0) {
int64_t size = avio_size(s->pb);
if (size > 0 && size > s->internal->data_offset)
filesize = size - s->internal->data_offset;
}
-if ( (mp3->is_cbr || fast_seek)
-&& (mp3->usetoc == 0 || !mp3->xing_toc)
-&& st->duration > 0
-&& filesize > 0) {
-ie = &ie1;
-timestamp = av_clip64(timestamp, 0, st->duration);
-ie->timestamp = timestamp;
-ie->pos = av_rescale(timestamp, filesize, st->duration) +
s->internal->data_offset;
-} else if (mp3->xing_toc) {
+if (mp3->xing_toc && (mp3->usetoc || (fast_seek && !mp3->is_cbr))) {
+// NOTE: The MP3 TOC is not a precise lookup table. Accuracy is worse
+// for bigger files.
+av_log(s, AV_LOG_WARNING, "Using MP3 TOC to seek; may be
imprecise.\n");
+
+int64_t ret = av_index_search_timestamp(st, timestamp, flags);
if (ret < 0)
return ret;
ie = &st->index_entries[ret];
+} else if (fast_seek && st->duration > 0 && filesize > 0) {
+if (!mp3->is_cbr)
+av_log(s, AV_LOG_WARNING, "Using scaling to seek VBR MP3; may be
imprecise.\n");
+
+ie = &ie1;
+timestamp = av_clip64(timestamp, 0, st->duration);
+ie->timestamp = timestamp;
+ie->pos = av_rescale(timestamp, filesize, st->duration) +
s->internal->data_offset;
} else {
-return -1;
+return -1; // generic index code
}
best_pos = mp3_sync(s, ie->pos, flags);
@@ -546,7 +545,7 @@ static int mp3_seek(AVFormatContext *s, int stream_index,
int64_t timestamp,
}
static const AVOption options[] = {
-{ "usetoc", "use table of contents", offsetof(MP3DecContext, usetoc),
AV_OPT_TYPE_INT, {.i64 = -1}, -1, 2, AV_OPT_FLAG_DECODING_PARAM},
+{ "usetoc", "use table of contents", offsetof(MP3DecContext, usetoc),
AV_OPT_TYPE_INT, {.i64 = 0}, 0, 1, AV_OPT_FLAG_DECODING_PARAM},
{ NULL },
};
diff --git a/libavformat/seek-test.c b/libavformat/seek-test.c
index 1926f21..bfd06db 100644
--- a/libavformat/seek-test.c
+++ b/libavformat/seek-test.c
@@ -56,7 +56,7 @@ static void ts_str(char buffer[60], int64_t ts, AVRational
base)
int main(int argc, char **argv)
{
const char *filename;
-AVFormatContext *ic = NULL;
+AVFormatContext *ic = avformat_alloc_context();
int i, ret, stream_id;
int j;
int64_t timestamp;
@@ -76,8 +76,10 @@ int main(int argc, char **argv)
frame_count = atoi(argv[i+1]);
} else if(!strcmp(argv[i], "-duration")){
duration = atoi(argv[i+1]);
-} else if(!strcmp(argv[i], "-usetoc")) {
-av_dict_set(&format_opts, "usetoc", argv[i+1], 0);
+} else if(!strcmp(argv[i], "-fastseek")) {
+if (atoi(argv[i+1])) {
+ic->flags |= AVFMT_FLAG_FAST_SEEK;
+}
} else {
argc = 1;
}
diff --git a/tests/fate/see
Re: [FFmpeg-devel] [PATCH] tests/api: Fix API test build on windows with --enable-shared
On Mon, Nov 30, 2015 at 10:50 PM, Hendrik Leppkes wrote: > --- > I'm not quite sure if this fix is 100% correct, but it works here. > > The problem is that FF_DEP_LIBS points to the .dll files, but you can't link > to the .dll files, > you need to point to the import libraries. Unfortunately there is no variable > which simply > holds all import libraries - but they do appear to be part of FF_EXTRALIBS, > so thats used instead. > > tests/api/Makefile | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/tests/api/Makefile b/tests/api/Makefile > index c48c34a..a6d8e42 100644 > --- a/tests/api/Makefile > +++ b/tests/api/Makefile > @@ -14,7 +14,7 @@ $(APITESTOBJS) $(APITESTOBJS:.o=.i): CPPFLAGS += -DTEST > $(APITESTOBJS) $(APITESTOBJS:.o=.i): CFLAGS += -Umain > > $(APITESTPROGS): %$(EXESUF): %.o $(EXEOBJS) $(FF_DEP_LIBS) > - $(LD) $(LDFLAGS) $(LDEXEFLAGS) $(LD_O) $(filter %.o,$^) > $(FF_DEP_LIBS) $(FFEXTRALIBS) $(ELIBS) > + $(LD) $(LDFLAGS) $(LDEXEFLAGS) $(LD_O) $(filter %.o,$^) > $(FF_EXTRALIBS) $(ELIBS) > > testclean:: > $(RM) $(addprefix $(APITESTSDIR)/,$(CLEANSUFFIXES) *-test$(EXESUF)) > -- > 2.6.2.windows.1 > Anyone that knows the build system a bit more? Or maybe anyone that just feels like testing on some other systems than mine? :) - Hendrik ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 2/2] avfilter: add sidechaingate filter
On 12/1/15, Nicolas George wrote: > Le primidi 11 frimaire, an CCXXIV, Paul B Mahol a ecrit : >> Similar how its freed when no longer used. > > Please elaborate. I know the API, I do not see what you suggest. > > (Thanks for trimming.) > > Regards, After carefully looking at this functon, I see no leaking at all. > > -- > Nicolas George > ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avfilter/vf_shuffleframes: Assert that the case of an uninitialized ret does not occur
On 12/1/15, Michael Niedermayer wrote: > From: Michael Niedermayer > > Fixes CID1258479 > > Signed-off-by: Michael Niedermayer > --- > libavfilter/vf_shuffleframes.c |8 > 1 file changed, 4 insertions(+), 4 deletions(-) > ok ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] request for feedback on video codec idea
On 10/14/15, Nicolas George wrote:
> Le tridi 23 vendémiaire, an CCXXIV, Roger Pack a écrit :
>> For instance, given 3 frames of video ("one after another" from the
>> incoming video stream), "combine them" into one stream like:
>> pixel 1 frame 1, pixel 1 frame 2, pixel 1 frame 3, pixel 2 frame 2,
>> pixel 2 frame 2, pixel 2 frame 3 ...
>>
>> then basically apply LZ4 or density algorithm to those bytes.
>>
>> The theory being that if there is a lot of repeated content between
>> frames, it will compress well.
>
> Standard answer: profile, don't speculate.
>
> I have no idea if this can prove promising, but I am pretty sure you could
> implement enough of it to get an estimate in just a few minutes with your
> language of choice.
>
> Choose a test clip that has convenient properties (frame size multiple of
> your chosen block size, number of frames multiple of the frame group size,
> etc.).
>
> In the program, hardcode the frame size, pixel format, etc., and forego
> error checks. Read a group of frames from standard input, assuming rawvideo
> format, then output the pixels to standard output in the order you want.
>
> Run with standard input piped from ffmpeg to get the rawvideo contents and
> standard output piped to your favorite command-line stream compression
> utility (gzip, xz).
>
> If the result looks promising, enhance. If not, you know you tried.
Great idea. I think I will do that.
I did get as far as "single frame" encoding using lzo.
It works *great* for synthetically generated data like testsrc. I
mean like twice as fast as anything else, with better compression LOL.
With real data, not so much. I'm attaching it here not for it to be
committed but for followers in case it saves anybody some time that
also wants to go down this path.
I will hopefully find time to work on the "multi frame" aspect soon,
and probably save time by doing what you suggested there.
Thanks!
diff --git a/configure b/configure
index a30d831..43108e4 100755
--- a/configure
+++ b/configure
@@ -1961,6 +1961,8 @@ CONFIG_EXTRA="
hpeldsp
huffman
huffyuvdsp
+rzipenc
+rzipdec
huffyuvencdsp
idctdsp
iirfilter
@@ -2283,6 +2285,8 @@ hevc_qsv_decoder_select="hevc_mp4toannexb_bsf hevc_parser
qsvdec hevc_qsv_hwacce
hevc_qsv_encoder_select="qsvenc"
huffyuv_decoder_select="bswapdsp huffyuvdsp llviddsp"
huffyuv_encoder_select="bswapdsp huffman huffyuvencdsp llviddsp"
+rzip_encoder_select="lzo"
+#rzip_decoder_select="lzo"
iac_decoder_select="imc_decoder"
imc_decoder_select="bswapdsp fft mdct sinewin"
indeo3_decoder_select="hpeldsp"
diff --git a/libavcodec/Makefile b/libavcodec/Makefile
index d85215d..d54d0ff 100644
--- a/libavcodec/Makefile
+++ b/libavcodec/Makefile
@@ -310,6 +310,8 @@ OBJS-$(CONFIG_HNM4_VIDEO_DECODER) += hnm4video.o
OBJS-$(CONFIG_HQ_HQA_DECODER) += hq_hqa.o hq_hqadata.o hq_hqadsp.o \
canopus.o
OBJS-$(CONFIG_HQX_DECODER) += hqx.o hqxvlc.o hqxdsp.o canopus.o
+OBJS-$(CONFIG_RZIP_DECODER)+= rzip.o rzipdec.o
+OBJS-$(CONFIG_RZIP_ENCODER)+= rzip.o rzipenc.o
OBJS-$(CONFIG_HUFFYUV_DECODER) += huffyuv.o huffyuvdec.o
OBJS-$(CONFIG_HUFFYUV_ENCODER) += huffyuv.o huffyuvenc.o
OBJS-$(CONFIG_IDCIN_DECODER) += idcinvideo.o
diff --git a/libavcodec/allcodecs.c b/libavcodec/allcodecs.c
index 9f60d7c..7335b24 100644
--- a/libavcodec/allcodecs.c
+++ b/libavcodec/allcodecs.c
@@ -203,6 +203,7 @@ void avcodec_register_all(void)
REGISTER_DECODER(HQ_HQA,hq_hqa);
REGISTER_DECODER(HQX, hqx);
REGISTER_ENCDEC (HUFFYUV, huffyuv);
+REGISTER_ENCDEC (RZIP, rzip);
REGISTER_DECODER(IDCIN, idcin);
REGISTER_DECODER(IFF_ILBM, iff_ilbm);
REGISTER_DECODER(INDEO2,indeo2);
diff --git a/libavcodec/avcodec.h b/libavcodec/avcodec.h
index 5e36c94..33c3cd6 100644
--- a/libavcodec/avcodec.h
+++ b/libavcodec/avcodec.h
@@ -130,6 +130,7 @@ enum AVCodecID {
AV_CODEC_ID_SVQ3,
AV_CODEC_ID_DVVIDEO,
AV_CODEC_ID_HUFFYUV,
+AV_CODEC_ID_RZIP,
AV_CODEC_ID_CYUV,
AV_CODEC_ID_H264,
AV_CODEC_ID_INDEO3,
diff --git a/libavcodec/codec_desc.c b/libavcodec/codec_desc.c
index 9cad3e6..616069b 100644
--- a/libavcodec/codec_desc.c
+++ b/libavcodec/codec_desc.c
@@ -188,6 +188,13 @@ static const AVCodecDescriptor codec_descriptors[] = {
.props = AV_CODEC_PROP_INTRA_ONLY | AV_CODEC_PROP_LOSSY,
},
{
+.id= AV_CODEC_ID_RZIP,
+.type = AVMEDIA_TYPE_VIDEO,
+.name = "RZIP",
+.long_name = NULL_IF_CONFIG_SMALL("Rzip"),
+.props = AV_CODEC_PROP_INTRA_ONLY | AV_CODEC_PROP_LOSSLESS,
+},
+{
.id= AV_CODEC_ID_HUFFYUV,
.type = AVMEDIA_TYPE_VIDEO,
.name = "huffyuv",
diff --git a/libavcodec/rzip.c b/libavcodec/rzip.c
new file mode 100644
index 000..e69de29
dif
Re: [FFmpeg-devel] request for feedback on video codec idea
On 10/14/15, Hendrik Leppkes wrote:
> On Wed, Oct 14, 2015 at 8:08 PM, Roger Pack wrote:
>> Lacking a better place to debate this, I would like to ask some
>> questions on a video codec idea...
>>
>> The goal is basically to create a very fast lossless screen capture
>> codec (i.e. in the input there will be lots of repeated "colors" of
>> neighboring pixels, not a lot of dynamic content between frames).
>>
>> I have become aware of some "fast" compression tools like LZO, LZ4,
>> density, etc. It seems like they all basically compress "the first
>> 64KB then the next 64KB" or something like that [1].
>>
>> My idea is to basically put pixels of the same position, from multiple
>> frames, "together" in a stream, then apply normal (fast) compression
>> algorithms to the stream. The hope being that if the pixels are the
>> "same" between frames (presumed to be so because of not much dynamic
>> content), the compression will be able to detect the similarity and
>> compress it well.
>>
>> For instance, given 3 frames of video ("one after another" from the
>> incoming video stream), "combine them" into one stream like:
>> pixel 1 frame 1, pixel 1 frame 2, pixel 1 frame 3, pixel 2 frame 2,
>> pixel 2 frame 2, pixel 2 frame 3 ...
>>
>> then basically apply LZ4 or density algorithm to those bytes.
>>
>> The theory being that if there is a lot of repeated content between
>> frames, it will compress well.
>>
>> The basic need/desire for this was that huffyuv, though super fast at
>> encoding (it basically zips the frame), seems to create *huge* files,
>> I assume because "each frame is an I-frame" so it has to re encode
>> everything each frame. And also the egotistical desire to create the
>> "fastest video codec in existence" in case the same were useful in
>> other situations (i.e. use very little cpu--even huffyuv uses quite a
>> bit of cpu) :)
>>
>> Any feedback on the concept?
>> Also does anything similar to this already exist? (though should I
>> create my new codec, it would be open source of course, which is
>> already different than many [probably efficient] screen capture codecs
>> out there).
>>
>> Thanks.
>> -roger-
>>
>
> I can't really comment on the merits of this compression scheme, but
> note that you might have trouble with the ffmpeg API when handling
> such a codec, since every single data packet would result in X output
> frames (3 in your example) - this is not a scheme that avcodec can
> really represent well.
> On top of that, containers might have troubles timestamping this properly.
True, I had hoped that FFmpeg would have some "b frame" type
functionality that I could leverage somehow...or perhaps I can fake it
by using null frames or something along those lines.
Cheers!
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] AAC encoder: improve SF range utilization
On Tue, Dec 1, 2015 at 7:35 AM, Claudio Freire wrote: > On Mon, Nov 30, 2015 at 1:04 PM, Hendrik Leppkes wrote: >> On Mon, Nov 30, 2015 at 4:50 PM, Claudio Freire >> wrote: >>> On Mon, Nov 30, 2015 at 12:27 PM, Rostislav Pehlivanov >>> wrote: On Sun, 2015-11-29 at 16:54 -0300, Claudio Freire wrote: > Before pushing this, I'd like some feedback, > especially about > the implementation of point 3. I'm not sure the AAC encoder > setting the cutoff in the encoder context like this is legal or > desirable. I think setting the cutoff is necessary. You can't avoid holes and yet keep a full bandwidth as you decrease bits unless you like the sound of massive quantization errors. >>> >>> My point was more about whether a codec should write into the context >>> struct like that or not. Basically an API technicality that's unclear >>> to me. >>> >> >> It seems slightly odd to write into that variable, since thats the >> cutoff the user requests. >> Maybe you can use/write into a private variable instead? ac3enc seems >> to use a private variable for similar purposes. > > Attached patch does that. > > I'm far more comfortable with this implementation, so if all agree, I'll push. This part looks good to me now, thanks! I'll leave the other parts for atomnuker to judge. ;) > > On Mon, Nov 30, 2015 at 2:20 PM, Rostislav Pehlivanov > wrote: >> On Mon, 2015-11-30 at 12:50 -0300, Claudio Freire wrote: >>> Also I don't see how a static var would help or even be correct here. >>> Perhaps you meant something else? >> static uint8_t cond1 = param1 && param2; >> static uint8_t cond2 = param3 && !param4; >> ...etc >> return cond1 && cond2; > > I didn't do that since it would not short circuit some terms that > ought to be short-circuited. > > But I did split lines and it does read better. In fact, maybe that was > all that was needed? > > ___ > 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] avfilter/vf_shuffleframes: Assert that the case of an uninitialized ret does not occur
On Tue, Dec 01, 2015 at 07:21:19PM +, Paul B Mahol wrote: > On 12/1/15, Michael Niedermayer wrote: > > From: Michael Niedermayer > > > > Fixes CID1258479 > > > > Signed-off-by: Michael Niedermayer > > --- > > libavfilter/vf_shuffleframes.c |8 > > 1 file changed, 4 insertions(+), 4 deletions(-) > > > > ok applied thx [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB Avoid a single point of failure, be that a person or equipment. signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [patch] AV_CH_LAYOUT_6POINT1_BACK not reachable in parsing
[bug submit webpage seems to be down, sending directly]
Trying to make heads and tails out of DTS 6.1 I can across this typo.
I also noticed that this wiki page is incorrect or misleading, the
channel order for 6.1 given does not match the source code. At the
least it should be clarified that the layout given does not apply to
DTS. https://trac.ffmpeg.org/wiki/AudioChannelManipulation
Thanks
Martin
diff --git a/libavutil/channel_layout.c b/libavutil/channel_layout.c
index 601c7e6..26c87c9 100644
--- a/libavutil/channel_layout.c
+++ b/libavutil/channel_layout.c
@@ -94,7 +94,7 @@ static const struct {
{ "6.0(front)", 6, AV_CH_LAYOUT_6POINT0_FRONT },
{ "hexagonal", 6, AV_CH_LAYOUT_HEXAGONAL },
{ "6.1", 7, AV_CH_LAYOUT_6POINT1 },
-{ "6.1", 7, AV_CH_LAYOUT_6POINT1_BACK },
+{ "6.1(back)", 7, AV_CH_LAYOUT_6POINT1_BACK },
{ "6.1(front)", 7, AV_CH_LAYOUT_6POINT1_FRONT },
{ "7.0", 7, AV_CH_LAYOUT_7POINT0 },
{ "7.0(front)", 7, AV_CH_LAYOUT_7POINT0_FRONT },
--
%%%
Martin Cracauerhttp://www.cons.org/cracauer/
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 2/2] avfilter: add sidechaingate filter
On Tue, Dec 1, 2015 at 2:14 PM, Paul B Mahol wrote: > On 12/1/15, Nicolas George wrote: >> Le primidi 11 frimaire, an CCXXIV, Paul B Mahol a ecrit : >>> Similar how its freed when no longer used. >> >> Please elaborate. I know the API, I do not see what you suggest. >> >> (Thanks for trimming.) >> >> Regards, > > After carefully looking at this functon, I see no leaking at all. Care to elaborate on this? My question is: what happens when e.g layouts get set and allocated/ref'ed correctly, but while trying to allocate formats, ENOMEM occurs? Or in other words, where does the formats get deallocated in such a case? And why does Coverity flag these things? > >> >> -- >> Nicolas George >> > ___ > 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 3/4] avcodec/ppc/fdctdsp: use more accurate constants
On Mon, Nov 16, 2015 at 1:58 PM, Ganesh Ajjanagadde wrote: > On Mon, Nov 16, 2015 at 1:20 PM, Hendrik Leppkes wrote: >> On Mon, Nov 16, 2015 at 6:24 PM, Ganesh Ajjanagadde wrote: >>> On Mon, Nov 16, 2015 at 9:48 AM, Daniel Serpell wrote: Hi!, El Fri, Nov 13, 2015 at 11:42:30AM -0500, Ganesh Ajjanagadde escribio: > Whoever wrote this stuff had a pretty bad libm - digits differ pretty > quickly. They where correctly rounded to 24bit precision. I don't know if that was intentional, so I can't comment on the correctness of the patch. >>> >>> Unless I am off here, doing things at 24 bits makes very little sense: >>> float itself offers 32 bits >> >> Actually floats offer 23-bits of precision for the significand (with 8 >> for mantissa and one sign bit) - 7-8 digits, so any more precision >> than that couldn't be stored accurately anymore, so when using single >> precision like this code, more precision is not needed. > > Point taken. However, the general remark still applies: precision is > being lost unnecessarily at an intermediate computation stage since it > is anyway a static computation. > >> Maybe it was even specifically wanted to have values that are >> represented accurately, but I do not know the history of this code >> either. pushed >> >> - Hendrik >> ___ >> ffmpeg-devel mailing list >> ffmpeg-devel@ffmpeg.org >> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 3/4] avcodec/mpegaudio_tablegen: more dynamic table creation speedups
On Sat, Nov 28, 2015 at 4:47 PM, Ganesh Ajjanagadde wrote: > On Sat, Nov 28, 2015 at 4:35 PM, Derek Buitenhuis > wrote: >> On 11/28/2015 9:26 PM, Derek Buitenhuis wrote: >>> Changing all of them sounds fine to me. >> >> [21:31] <@ubitux> re: i%4 vs i&3; you should ask him to make sure the >> compiler is smart enough regarding the signess of i > > No idea, actually GCC even to this day has issues with signed vs unsigned. > > Trivial example (unrelated), > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=48052 which is still > open. Lesson for FFmpeg - make sure looping is done with int i instead > of unsigned i. I have not done an extensive audit, but FFmpeg seems > mostly good in this respect. > > So I will follow Derek's suggestion and use i & 3 uniformly here; I > lack the energy to investigate and will err on the safe side wrt > performance. pushed with the i & 3. > >> >> - Derek >> ___ >> ffmpeg-devel mailing list >> ffmpeg-devel@ffmpeg.org >> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/4] avutil/tablegen: add tablegen libm compatibility shims
On Sat, Nov 28, 2015 at 4:23 PM, Ganesh Ajjanagadde wrote: > On Sat, Nov 28, 2015 at 3:19 PM, Derek Buitenhuis > wrote: >> On 11/28/2015 7:51 PM, Ganesh Ajjanagadde wrote: >>> In principle of course, e.g with more ifdefry, configure, or something >>> of that sort. I do not believe this is what he meant. >> >> I will await his reply to clarify, then. Perhaps do not write so >> matter-of-factly. >> >>> In any case, the point is moot - the implementations are not broken - >>> if they are, avutil/libm needs fixing as well. >> >> Now, yes. It would certainly be nice if this was noted somewhere in the >> patch notes >> (not necessarily in the commit messages). There are quite a few threads on >> the list >> from you now regarding tablegen, and it can be a pain in the butt / tedious >> to figure >> out how the current version differs from the N others. > > I assumed from the cover letter that this supersedes all such prior > stuff. Anyway, will attempt but can't guarantee improvements in > future. > >> Anyway, shouldn't this patce dropped, since 79abf2d0ded860acf505de22c4f7a750e5e98446 removed hardcoded tables anyway? >>> >>> No, if you actually read even the first line of the commit message, >>> you can see it was only for aac, not for this patch series. >> >> Indeed, I misread, and missed the 'aac_'. You could certainly be less of >> an ass about it, though. > > Sorry about that. Please do continue to call me out on such things; I > do not like unpleasantness on ffmpeg-devel. pushed, thanks > >> >> - Derek >> ___ >> 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
[FFmpeg-devel] [PATCH] doc/filters/drawtext: fix centering example
Signed-off-by: Andrey Utkin --- doc/filters.texi | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/doc/filters.texi b/doc/filters.texi index fc71a99..06686bd 100644 --- a/doc/filters.texi +++ b/doc/filters.texi @@ -5605,7 +5605,7 @@ within the parameter list. @item Show the text at the center of the video frame: @example -drawtext="fontsize=30:fontfile=FreeSerif.ttf:text='hello world':x=(w-text_w)/2:y=(h-text_h-line_h)/2" +drawtext="fontsize=30:fontfile=FreeSerif.ttf:text='hello world':x=(w-text_w)/2:y=(h-text_h)/2" @end example @item -- 2.6.3 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 2/4] avcodec/mpegaudio_tablegen: speed up dynamic table creation
On Sat, Nov 28, 2015 at 12:03 PM, Ganesh Ajjanagadde
wrote:
> This does some miscellaneous stuff mainly avoiding the usage of pow to
> achieve significant speedups. This is not speed critical, but is
> unnecessary latency and cycles wasted for a user.
>
> All tables tested and are identical to the old ones
> (bit-exact even in floating point case).
>
> Sample benchmark (x86-64, Haswell, GNU/Linux):
> old:
> 102329530 decicycles in mpegaudio_tableinit, 1 runs, 0 skips
>
> new:
> 34111900 decicycles in mpegaudio_tableinit, 1 runs, 0 skips
>
> Reviewed-by: Ronald S. Bultje
> Signed-off-by: Ganesh Ajjanagadde
> ---
> libavcodec/mpegaudio_tablegen.c | 1 +
> libavcodec/mpegaudio_tablegen.h | 19 +--
> 2 files changed, 14 insertions(+), 6 deletions(-)
>
> diff --git a/libavcodec/mpegaudio_tablegen.c b/libavcodec/mpegaudio_tablegen.c
> index 90c9de4..9a9bb4d 100644
> --- a/libavcodec/mpegaudio_tablegen.c
> +++ b/libavcodec/mpegaudio_tablegen.c
> @@ -23,6 +23,7 @@
> #include
> #define CONFIG_HARDCODED_TABLES 0
> #include "mpegaudio_tablegen.h"
> +#include "libavutil/tablegen.h"
> #include "tableprint.h"
>
> int main(void)
> diff --git a/libavcodec/mpegaudio_tablegen.h b/libavcodec/mpegaudio_tablegen.h
> index 86b2cd3..dd67a09 100644
> --- a/libavcodec/mpegaudio_tablegen.h
> +++ b/libavcodec/mpegaudio_tablegen.h
> @@ -45,12 +45,21 @@ static float expval_table_float[512][16];
> static av_cold void mpegaudio_tableinit(void)
> {
> int i, value, exponent;
> +double exp2_lut[4] = {
> +1., /* 2 ^ (0 * 0.25) */
> +1.18920711500272106672, /* 2 ^ (1 * 0.25) */
> +M_SQRT2 , /* 2 ^ (2 * 0.25) */
> +1.68179283050742908606, /* 2 ^ (3 * 0.25) */
> +};
> +double cbrt_lut[16];
> +for (i = 0; i < 16; ++i)
> +cbrt_lut[i] = cbrt(i);
> +
> for (i = 1; i < TABLE_4_3_SIZE; i++) {
> double value = i / 4;
> double f, fm;
> int e, m;
> -/* cbrtf() isn't available on all systems, so we use powf(). */
> -f = value / IMDCT_SCALAR * pow(value, 1.0 / 3.0) * pow(2, (i & 3) *
> 0.25);
> +f = value / IMDCT_SCALAR * cbrt(value) * exp2_lut[i & 3];
> fm = frexp(f, &e);
> m = (uint32_t)(fm * (1LL << 31) + 0.5);
> e += FRAC_BITS - 31 + 5 - 100;
> @@ -61,10 +70,8 @@ static av_cold void mpegaudio_tableinit(void)
> }
> for (exponent = 0; exponent < 512; exponent++) {
> for (value = 0; value < 16; value++) {
> -/* cbrtf() isn't available on all systems, so we use powf(). */
> -double f = (double)value * pow(value, 1.0 / 3.0) * pow(2,
> (exponent - 400) * 0.25 + FRAC_BITS + 5) / IMDCT_SCALAR;
> -/* llrint() isn't always available, so round and cast manually.
> */
> -expval_table_fixed[exponent][value] = (long long int) (f <
> 0x ? floor(f + 0.5) : 0x);
> +double f = value * cbrt_lut[value] * pow(2, (exponent - 400) *
> 0.25 + FRAC_BITS + 5) / IMDCT_SCALAR;
> +expval_table_fixed[exponent][value] = (f < 0x ?
> llrint(f) : 0x);
> expval_table_float[exponent][value] = f;
> }
> exp_table_fixed[exponent] = expval_table_fixed[exponent][1];
> --
> 2.6.2
>
pushed
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 4/4] avcodec/cbrt_tablegen: speed up dynamic table creation
On Sat, Nov 28, 2015 at 12:03 PM, Ganesh Ajjanagadde
wrote:
> On systems having cbrt, there is no reason to use the slow pow function.
>
> Sample benchmark (x86-64, Haswell, GNU/Linux):
> new:
> 5124920 decicycles in cbrt_tableinit, 1 runs, 0 skips
>
> old:
> 12321680 decicycles in cbrt_tableinit, 1 runs, 0 skips
>
> Reviewed-by: Ronald S. Bultje
> Signed-off-by: Ganesh Ajjanagadde
> ---
> libavcodec/cbrt_tablegen.h | 5 ++---
> libavcodec/cbrt_tablegen_template.c | 1 +
> 2 files changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/libavcodec/cbrt_tablegen.h b/libavcodec/cbrt_tablegen.h
> index 27a3e3a..59b5a1d 100644
> --- a/libavcodec/cbrt_tablegen.h
> +++ b/libavcodec/cbrt_tablegen.h
> @@ -29,7 +29,7 @@
> #include "libavcodec/aac_defines.h"
>
> #if USE_FIXED
> -#define CBRT(x) (int)floor((x).f * 8192 + 0.5)
> +#define CBRT(x) lrint((x).f * 8192)
> #else
> #define CBRT(x) x.i
> #endif
> @@ -49,13 +49,12 @@ static av_cold void AAC_RENAME(cbrt_tableinit)(void)
> {
> if (!cbrt_tab[(1<<13) - 1]) {
> int i;
> -/* cbrtf() isn't available on all systems, so we use powf(). */
> for (i = 0; i < 1<<13; i++) {
> union {
> float f;
> uint32_t i;
> } f;
> -f.f = pow(i, 1.0 / 3.0) * i;
> +f.f = cbrt(i) * i;
> cbrt_tab[i] = CBRT(f);
> }
> }
> diff --git a/libavcodec/cbrt_tablegen_template.c
> b/libavcodec/cbrt_tablegen_template.c
> index 9dd2cf5..1d71d34 100644
> --- a/libavcodec/cbrt_tablegen_template.c
> +++ b/libavcodec/cbrt_tablegen_template.c
> @@ -23,6 +23,7 @@
> #include
> #define CONFIG_HARDCODED_TABLES 0
> #include "cbrt_tablegen.h"
> +#include "libavutil/tablegen.h"
> #include "tableprint.h"
>
> int main(void)
> --
> 2.6.2
>
pushed, identical stand-alone patch reviewed by Ronald.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 05/10] avfilter/avf_showcqt: use hypot()
On Mon, Nov 30, 2015 at 11:15 PM, Muhammad Faiz wrote:
> On Sun, Nov 22, 2015 at 9:05 AM, Ganesh Ajjanagadde
> wrote:
>> Signed-off-by: Ganesh Ajjanagadde
>> ---
>> libavfilter/avf_showcqt.c | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/libavfilter/avf_showcqt.c b/libavfilter/avf_showcqt.c
>> index d6e2928..cd90c88 100644
>> --- a/libavfilter/avf_showcqt.c
>> +++ b/libavfilter/avf_showcqt.c
>> @@ -170,7 +170,7 @@ static double a_weighting(void *p, double f)
>> static double b_weighting(void *p, double f)
>> {
>> double ret = 12200.0*12200.0 * (f*f*f);
>> -ret /= (f*f + 20.6*20.6) * (f*f + 12200.0*12200.0) * sqrt(f*f +
>> 158.5*158.5);
>> +ret /= (f*f + 20.6*20.6) * (f*f + 12200.0*12200.0) * hypot(f, 158.5);
>> return ret;
>> }
>>
>
> I prefer sqrt in this code, because extra precision and range is not required.
I assume by this you don't consider this a readability improvement
either. Since you are the maintainer ultimately, patch dropped.
Thanks.
>
> Thank's.
> ___
> 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] doc/filters/drawtext: fix centering example
On Tue, 1 Dec 2015 21:15:53 +0200, Andrey Utkin wrote: > Signed-off-by: Andrey Utkin > --- > doc/filters.texi | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) LGTM and applied. Thanks. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 0/9] improve rounding across FFmpeg
Currently, there are numerous instances where the appropriate libm rounding functions lrint, llrint, rint, etc are not used and instead ad-hoc, slow, and sometimes risky floor(x + 0.5) and the like are being used. The risk comes from the fact that such a thing is broken for negative values and values close to the 0.5 fractional part boundary. The ad-hoc nature comes from the fact that we anyway have compat hacks in avutil/libm for broken platforms, and they are not being used. The slowness comes from the generate code, e.g llrint compiles down to a single asm instruction cvttsd2si, while floor(x + 0.5) needs to do multiple things. Note that the audit may have missed some things; essentially this was found by doing a grep for 'floor' across the codebase and checking. Patches split per file. Ganesh Ajjanagadde (9): avfilter/vsrc_mptestsrc: use lrint instead of floor hack avfilter/vf_perspective: use lrint instead of floor hack avfilter/af_stereotools: use lrint instead of floor hack avfilter/af_flanger: use rint instead of floor hack avcodec/cos_tablegen: use rint instead of floor hack avcodec/kbdwin: use lrint instead of floor hack avcodec/mdct_template: use lrint instead of floor hack avcodec/wavpackenc: use lrint instead of floor hack avcodec/sonic: use lrint instead of floor hack libavcodec/cos_tablegen.c| 4 ++-- libavcodec/kbdwin.c | 3 ++- libavcodec/mdct_template.c | 5 +++-- libavcodec/sonic.c | 2 +- libavcodec/wavpackenc.c | 4 ++-- libavfilter/af_flanger.c | 2 +- libavfilter/af_stereotools.c | 8 libavfilter/vf_perspective.c | 10 +- libavfilter/vsrc_mptestsrc.c | 2 +- 9 files changed, 21 insertions(+), 19 deletions(-) -- 2.6.2 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 1/9] avfilter/vsrc_mptestsrc: use lrint instead of floor hack
lrint is faster, and is more consistent across the codebase. Signed-off-by: Ganesh Ajjanagadde --- libavfilter/vsrc_mptestsrc.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/libavfilter/vsrc_mptestsrc.c b/libavfilter/vsrc_mptestsrc.c index 668a001..1cdd3a4 100644 --- a/libavfilter/vsrc_mptestsrc.c +++ b/libavfilter/vsrc_mptestsrc.c @@ -121,7 +121,7 @@ static void idct(uint8_t *dst, int dst_linesize, int src[64]) for (k = 0; k < 8; k++) sum += c[k*8+i]*tmp[8*k+j]; -dst[dst_linesize*i + j] = av_clip_uint8((int)floor(sum+0.5)); +dst[dst_linesize*i + j] = av_clip_uint8(lrint(sum)); } } } -- 2.6.2 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 2/9] avfilter/vf_perspective: use lrint instead of floor hack
Signed-off-by: Ganesh Ajjanagadde
---
libavfilter/vf_perspective.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/libavfilter/vf_perspective.c b/libavfilter/vf_perspective.c
index 970870c..13053f1 100644
--- a/libavfilter/vf_perspective.c
+++ b/libavfilter/vf_perspective.c
@@ -213,10 +213,10 @@ static int config_input(AVFilterLink *inlink)
for (x = 0; x < w; x++){
int u, v;
-u = (int)floor(SUB_PIXELS * (x0 * x + x1 * y + x2) /
-(x6 * x + x7 * y + x8) + 0.5);
-v = (int)floor(SUB_PIXELS * (x3 * x + x4 * y + x5) /
-(x6 * x + x7 * y + x8) + 0.5);
+u = lrint(SUB_PIXELS * (x0 * x + x1 * y + x2) /
+(x6 * x + x7 * y + x8));
+v = lrint(SUB_PIXELS * (x3 * x + x4 * y + x5) /
+(x6 * x + x7 * y + x8));
s->pv[x + y * w][0] = u;
s->pv[x + y * w][1] = v;
@@ -235,7 +235,7 @@ static int config_input(AVFilterLink *inlink)
sum += temp[j];
for (j = 0; j < 4; j++)
-s->coeff[i][j] = (int)floor((1 << COEFF_BITS) * temp[j] / sum +
0.5);
+s->coeff[i][j] = lrint((1 << COEFF_BITS) * temp[j] / sum);
}
return 0;
--
2.6.2
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 3/9] avfilter/af_stereotools: use lrint instead of floor hack
Signed-off-by: Ganesh Ajjanagadde --- libavfilter/af_stereotools.c | 8 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/libavfilter/af_stereotools.c b/libavfilter/af_stereotools.c index a22efb0..e878824 100644 --- a/libavfilter/af_stereotools.c +++ b/libavfilter/af_stereotools.c @@ -139,10 +139,10 @@ static int filter_frame(AVFilterLink *inlink, AVFrame *in) const double sc_level = s->sc_level; const double delay = s->delay; const int length = s->length; -const int mute_l = floor(s->mute_l + 0.5); -const int mute_r = floor(s->mute_r + 0.5); -const int phase_l = floor(s->phase_l + 0.5); -const int phase_r = floor(s->phase_r + 0.5); +const int mute_l = lrint(s->mute_l); +const int mute_r = lrint(s->mute_r); +const int phase_l = lrint(s->phase_l); +const int phase_r = lrint(s->phase_r); double *buffer = s->buffer; AVFrame *out; double *dst; -- 2.6.2 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 4/9] avfilter/af_flanger: use rint instead of floor hack
Signed-off-by: Ganesh Ajjanagadde --- libavfilter/af_flanger.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/libavfilter/af_flanger.c b/libavfilter/af_flanger.c index f8ec830..a92367c 100644 --- a/libavfilter/af_flanger.c +++ b/libavfilter/af_flanger.c @@ -130,7 +130,7 @@ static int config_input(AVFilterLink *inlink) return AVERROR(ENOMEM); ff_generate_wave_table(s->wave_shape, AV_SAMPLE_FMT_FLT, s->lfo, s->lfo_length, - floor(s->delay_min * inlink->sample_rate + 0.5), + rint(s->delay_min * inlink->sample_rate), s->max_samples - 2., 3 * M_PI_2); return av_samples_alloc_array_and_samples(&s->delay_buffer, NULL, -- 2.6.2 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 5/9] avcodec/cos_tablegen: use rint instead of floor hack
Signed-off-by: Ganesh Ajjanagadde
---
libavcodec/cos_tablegen.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/libavcodec/cos_tablegen.c b/libavcodec/cos_tablegen.c
index dbd0cc0..332216c 100644
--- a/libavcodec/cos_tablegen.c
+++ b/libavcodec/cos_tablegen.c
@@ -24,6 +24,7 @@
#include
#include
+#include "libavutil/libm.h"
#include "libavutil/mathematics.h"
#define BITS 16
@@ -40,10 +41,9 @@ static int clip_f15(int v)
static void printval(double val, int fixed)
{
if (fixed) {
-/* lrint() isn't always available, so round and cast manually. */
double new_val = val * (double) (1 << 15);
-new_val = new_val >= 0 ? floor(new_val + 0.5) : ceil(new_val - 0.5);
+new_val = rint(new_val);
printf(" "FIXEDFMT",", clip_f15((long int) new_val));
} else {
--
2.6.2
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 6/9] avcodec/kbdwin: use lrint instead of floor hack
Signed-off-by: Ganesh Ajjanagadde --- libavcodec/kbdwin.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/libavcodec/kbdwin.c b/libavcodec/kbdwin.c index bf32aeb..77d5e2b 100644 --- a/libavcodec/kbdwin.c +++ b/libavcodec/kbdwin.c @@ -17,6 +17,7 @@ */ #include "libavutil/avassert.h" +#include "libavutil/libm.h" #include "libavutil/mathematics.h" #include "libavutil/attributes.h" #include "kbdwin.h" @@ -53,5 +54,5 @@ av_cold void ff_kbd_window_init_fixed(int32_t *window, float alpha, int n) ff_kbd_window_init(local_window, alpha, n); for (i = 0; i < n; i++) -window[i] = (int)floor(2147483647.0 * local_window[i] + 0.5); +window[i] = lrint(2147483647.0 * local_window[i]); } -- 2.6.2 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 7/9] avcodec/mdct_template: use lrint instead of floor hack
Signed-off-by: Ganesh Ajjanagadde --- libavcodec/mdct_template.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/libavcodec/mdct_template.c b/libavcodec/mdct_template.c index e7e5f62..ecdeb54 100644 --- a/libavcodec/mdct_template.c +++ b/libavcodec/mdct_template.c @@ -23,6 +23,7 @@ #include #include "libavutil/common.h" #include "libavutil/mathematics.h" +#include "libavutil/libm.h" #include "fft.h" #include "fft-internal.h" @@ -82,8 +83,8 @@ av_cold int ff_mdct_init(FFTContext *s, int nbits, int inverse, double scale) for(i=0;itcos[i*tstep] = (FFTSample)floor(-cos(alpha) * 2147483648.0 + 0.5); -s->tsin[i*tstep] = (FFTSample)floor(-sin(alpha) * 2147483648.0 + 0.5); +s->tcos[i*tstep] = lrint(-cos(alpha) * 2147483648.0); +s->tsin[i*tstep] = lrint(-sin(alpha) * 2147483648.0); #else s->tcos[i*tstep] = FIX15(-cos(alpha) * scale); s->tsin[i*tstep] = FIX15(-sin(alpha) * scale); -- 2.6.2 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 8/9] avcodec/wavpackenc: use lrint instead of floor hack
Signed-off-by: Ganesh Ajjanagadde --- libavcodec/wavpackenc.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/libavcodec/wavpackenc.c b/libavcodec/wavpackenc.c index 977bcf0..6a9b716 100644 --- a/libavcodec/wavpackenc.c +++ b/libavcodec/wavpackenc.c @@ -954,7 +954,7 @@ static void analyze_mono(WavPackEncodeContext *s, int32_t *samples, int do_sampl memcpy(s->sampleptrs[info.nterms + 1][0], s->sampleptrs[i][0], s->block_samples * 4); if (s->extra_flags & EXTRA_BRANCHES) -recurse_mono(s, &info, 0, (int) floor(s->delta_decay + 0.5), +recurse_mono(s, &info, 0, lrint(s->delta_decay), log2mono(s->sampleptrs[0][0], s->block_samples, 0)); if (s->extra_flags & EXTRA_SORT_FIRST) @@ -1773,7 +1773,7 @@ static void analyze_stereo(WavPackEncodeContext *s, memcpy(s->sampleptrs[info.nterms + 1][1], s->sampleptrs[i][1], s->block_samples * 4); if (s->extra_flags & EXTRA_BRANCHES) -recurse_stereo(s, &info, 0, (int) floor(s->delta_decay + 0.5), +recurse_stereo(s, &info, 0, lrint(s->delta_decay), log2stereo(s->sampleptrs[0][0], s->sampleptrs[0][1], s->block_samples, 0)); -- 2.6.2 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 9/9] avcodec/sonic: use lrint instead of floor hack
Signed-off-by: Ganesh Ajjanagadde --- libavcodec/sonic.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/libavcodec/sonic.c b/libavcodec/sonic.c index 4ec7d89..0a848d1 100644 --- a/libavcodec/sonic.c +++ b/libavcodec/sonic.c @@ -537,7 +537,7 @@ static int modified_levinson_durbin(int *window, int window_entries, if (xx == 0.0) k = 0; else -k = (int)(floor(-xy/xx * (double)LATTICE_FACTOR / (double)(tap_quant[i]) + 0.5)); +k = lrint(-xy/xx * LATTICE_FACTOR / tap_quant[i]); if (k > (LATTICE_FACTOR/tap_quant[i])) k = LATTICE_FACTOR/tap_quant[i]; -- 2.6.2 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] Fix sample_aspect_ratio computation for stereo matroska content.
On Mon, Nov 30, 2015 at 4:35 PM wm4 wrote: > > I tried your patch, and it actually makes it work better (looks correct > with the patch). The patch itself also LGTM. > > Ok. Great. Thanks for the review. What do I need to do next to get this checked in. I don't have commit access. Aaron ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 06/11] avfilter/af_volumedetect: use log10 instead of hardcoded constant
On Sat, Oct 31, 2015 at 6:12 PM, Ganesh Ajjanagadde wrote: > On Sat, Oct 31, 2015 at 6:02 PM, Mark Harris wrote: >> On Wed, Oct 28, 2015 at 9:20 PM, Ganesh Ajjanagadde >> wrote: >>> This is likely more precise and conveys the intent better. >>> >>> Signed-off-by: Ganesh Ajjanagadde >>> --- >>> libavfilter/af_volumedetect.c | 2 +- >>> 1 file changed, 1 insertion(+), 1 deletion(-) >>> >>> diff --git a/libavfilter/af_volumedetect.c b/libavfilter/af_volumedetect.c >>> index 01f24ba..ad5fef3 100644 >>> --- a/libavfilter/af_volumedetect.c >>> +++ b/libavfilter/af_volumedetect.c >>> @@ -78,7 +78,7 @@ static inline double logdb(uint64_t v) >>> double d = v / (double)(0x8000 * 0x8000); >>> if (!v) >>> return MAX_DB; >>> -return log(d) * -4.3429448190325182765112891891660508229; /* >>> -10/log(10) */ >>> +return log10(d) * 10; >> >> Wouldn't this reverse the sign of the result? > > Missed the sign, of course you are right. Thanks. I dropped this stuff > on my end due to the whole log episode, and don't mind if it gets > included or not. Will leave it to the maintainer to decide. pushed, thanks. > >> >>> } >>> >>> static void print_stats(AVFilterContext *ctx) >>> -- >>> 2.6.2 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] AAC encoder: improve SF range utilization
On Tue, 2015-12-01 at 03:35 -0300, Claudio Freire wrote: > > Attached patch does that. > Went over the patch, everything me and other people said has been addressed, so LGTM. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 0/9] improve rounding across FFmpeg
On Tue, 1 Dec 2015 19:27:49 -0500, Ganesh Ajjanagadde wrote: > The slowness comes from the generate code, e.g llrint compiles down to > a single asm instruction cvttsd2si, while floor(x + 0.5) needs to do > multiple things. How much slower is it? ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 0/9] improve rounding across FFmpeg
On Tue, Dec 1, 2015 at 7:39 PM, Lou Logan wrote: > On Tue, 1 Dec 2015 19:27:49 -0500, Ganesh Ajjanagadde wrote: > >> The slowness comes from the generate code, e.g llrint compiles down to >> a single asm instruction cvttsd2si, while floor(x + 0.5) needs to do >> multiple things. > > How much slower is it? I don't know and honestly don't care myself as it is not really the selling point of the patch since AFAIK these are not performance critical. The point is really moot - I merely claimed that it is slower, which is obvious from the asm. The more serious reasons for avoiding it are also given in the message. > ___ > 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
[FFmpeg-devel] [PATCHv2] avutil/crc: avoid needless space wastage of hardcoded crc table
There was no reason AFAIK for making AV_CRC_24_IEEE 12. This simply
resulted in wasted space under --enable-hardcoded-tables:
dynamic: 1318672 libavutil/libavutil.so.55
old: 1330680 libavutil/libavutil.so.55
new: 1326488 libavutil/libavutil.so.55
Minor version number is bumped, with ifdefry due to API breakage.
Signed-off-by: Ganesh Ajjanagadde
---
libavutil/crc.h | 4
libavutil/version.h | 5 -
2 files changed, 8 insertions(+), 1 deletion(-)
diff --git a/libavutil/crc.h b/libavutil/crc.h
index e86bf1d..9af4421 100644
--- a/libavutil/crc.h
+++ b/libavutil/crc.h
@@ -40,7 +40,11 @@ typedef enum {
AV_CRC_32_IEEE,
AV_CRC_32_IEEE_LE, /*< reversed bitorder version of AV_CRC_32_IEEE */
AV_CRC_16_ANSI_LE, /*< reversed bitorder version of AV_CRC_16_ANSI */
+#if FF_API_CRC_BIG_TABLE
AV_CRC_24_IEEE = 12,
+#else
+AV_CRC_24_IEEE,
+#endif /* FF_API_CRC_BIG_TABLE */
AV_CRC_MAX, /*< Not part of public API! Do not use outside
libavutil. */
}AVCRCId;
diff --git a/libavutil/version.h b/libavutil/version.h
index e0ddfd2..67e778a 100644
--- a/libavutil/version.h
+++ b/libavutil/version.h
@@ -56,7 +56,7 @@
*/
#define LIBAVUTIL_VERSION_MAJOR 55
-#define LIBAVUTIL_VERSION_MINOR 9
+#define LIBAVUTIL_VERSION_MINOR 10
#define LIBAVUTIL_VERSION_MICRO 100
#define LIBAVUTIL_VERSION_INT AV_VERSION_INT(LIBAVUTIL_VERSION_MAJOR, \
@@ -108,6 +108,9 @@
#ifndef FF_API_ERROR_FRAME
#define FF_API_ERROR_FRAME (LIBAVUTIL_VERSION_MAJOR < 56)
#endif
+#ifndef FF_API_CRC_BIG_TABLE
+#define FF_API_CRC_BIG_TABLE(LIBAVUTIL_VERSION_INT <
AV_VERSION_INT(55, 10, 100))
+#endif
/**
--
2.6.2
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCHv2] avutil/crc: avoid needless space wastage of hardcoded crc table
On 12/1/2015 9:53 PM, Ganesh Ajjanagadde wrote:
> There was no reason AFAIK for making AV_CRC_24_IEEE 12. This simply
> resulted in wasted space under --enable-hardcoded-tables:
> dynamic: 1318672 libavutil/libavutil.so.55
> old: 1330680 libavutil/libavutil.so.55
> new: 1326488 libavutil/libavutil.so.55
>
> Minor version number is bumped, with ifdefry due to API breakage.
>
> Signed-off-by: Ganesh Ajjanagadde
> ---
> libavutil/crc.h | 4
> libavutil/version.h | 5 -
> 2 files changed, 8 insertions(+), 1 deletion(-)
>
> diff --git a/libavutil/crc.h b/libavutil/crc.h
> index e86bf1d..9af4421 100644
> --- a/libavutil/crc.h
> +++ b/libavutil/crc.h
> @@ -40,7 +40,11 @@ typedef enum {
> AV_CRC_32_IEEE,
> AV_CRC_32_IEEE_LE, /*< reversed bitorder version of AV_CRC_32_IEEE */
> AV_CRC_16_ANSI_LE, /*< reversed bitorder version of AV_CRC_16_ANSI */
> +#if FF_API_CRC_BIG_TABLE
> AV_CRC_24_IEEE = 12,
> +#else
> +AV_CRC_24_IEEE,
> +#endif /* FF_API_CRC_BIG_TABLE */
> AV_CRC_MAX, /*< Not part of public API! Do not use outside
> libavutil. */
> }AVCRCId;
>
> diff --git a/libavutil/version.h b/libavutil/version.h
> index e0ddfd2..67e778a 100644
> --- a/libavutil/version.h
> +++ b/libavutil/version.h
> @@ -56,7 +56,7 @@
> */
>
> #define LIBAVUTIL_VERSION_MAJOR 55
> -#define LIBAVUTIL_VERSION_MINOR 9
> +#define LIBAVUTIL_VERSION_MINOR 10
> #define LIBAVUTIL_VERSION_MICRO 100
>
> #define LIBAVUTIL_VERSION_INT AV_VERSION_INT(LIBAVUTIL_VERSION_MAJOR, \
> @@ -108,6 +108,9 @@
> #ifndef FF_API_ERROR_FRAME
> #define FF_API_ERROR_FRAME (LIBAVUTIL_VERSION_MAJOR < 56)
> #endif
> +#ifndef FF_API_CRC_BIG_TABLE
> +#define FF_API_CRC_BIG_TABLE(LIBAVUTIL_VERSION_INT <
> AV_VERSION_INT(55, 10, 100))
This is wrong. With this check, FF_API_CRC_BIG_TABLE is false. The point
of these FF_API defines is to make sure they are true until the next major
bump. That's why you use LIBAVUTIL_VERSION_MAJOR < 56, like it's being
done for the rest.
> +#endif
>
>
> /**
>
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avformat/mp3dec: prefer "fast_seek" to TOC seek for CBR files.
On Tue, Dec 01, 2015 at 10:47:53AM -0800, Chris Cunningham wrote: > Thanks wm4, next patch will fix that declaration. > > Michael, any concerns? iam fine with the patch > > On Mon, Nov 30, 2015 at 2:51 PM, wm4 wrote: [...] > > Other than that LGTM. wm4, your replies are missing from the mailing list (and i dont know what "Other" was meant for so dunno if i should apply or wait) [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB The misfortune of the wise is better than the prosperity of the fool. -- Epicurus signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] tests/api: Fix API test build on windows with --enable-shared
On Tue, Dec 01, 2015 at 08:04:22PM +0100, Hendrik Leppkes wrote: > On Mon, Nov 30, 2015 at 10:50 PM, Hendrik Leppkes wrote: > > --- > > I'm not quite sure if this fix is 100% correct, but it works here. > > > > The problem is that FF_DEP_LIBS points to the .dll files, but you can't > > link to the .dll files, > > you need to point to the import libraries. Unfortunately there is no > > variable which simply > > holds all import libraries - but they do appear to be part of FF_EXTRALIBS, > > so thats used instead. > > > > tests/api/Makefile | 2 +- > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > diff --git a/tests/api/Makefile b/tests/api/Makefile > > index c48c34a..a6d8e42 100644 > > --- a/tests/api/Makefile > > +++ b/tests/api/Makefile > > @@ -14,7 +14,7 @@ $(APITESTOBJS) $(APITESTOBJS:.o=.i): CPPFLAGS += -DTEST > > $(APITESTOBJS) $(APITESTOBJS:.o=.i): CFLAGS += -Umain > > > > $(APITESTPROGS): %$(EXESUF): %.o $(EXEOBJS) $(FF_DEP_LIBS) > > - $(LD) $(LDFLAGS) $(LDEXEFLAGS) $(LD_O) $(filter %.o,$^) > > $(FF_DEP_LIBS) $(FFEXTRALIBS) $(ELIBS) > > + $(LD) $(LDFLAGS) $(LDEXEFLAGS) $(LD_O) $(filter %.o,$^) > > $(FF_EXTRALIBS) $(ELIBS) > > > > testclean:: > > $(RM) $(addprefix $(APITESTSDIR)/,$(CLEANSUFFIXES) *-test$(EXESUF)) > > -- > > 2.6.2.windows.1 > > > > Anyone that knows the build system a bit more? Or maybe anyone that > just feels like testing on some other systems than mine? :) seems to work on everything i tried but that probably is a small subset of what is out there [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB it is not once nor twice but times without number that the same ideas make their appearance in the world. -- Aristotle signature.asc Description: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] tests/api: Fix API test build on windows with --enable-shared
On Tue, Dec 1, 2015 at 8:29 PM, Michael Niedermayer wrote: > On Tue, Dec 01, 2015 at 08:04:22PM +0100, Hendrik Leppkes wrote: >> On Mon, Nov 30, 2015 at 10:50 PM, Hendrik Leppkes >> wrote: >> > --- >> > I'm not quite sure if this fix is 100% correct, but it works here. >> > >> > The problem is that FF_DEP_LIBS points to the .dll files, but you can't >> > link to the .dll files, >> > you need to point to the import libraries. Unfortunately there is no >> > variable which simply >> > holds all import libraries - but they do appear to be part of >> > FF_EXTRALIBS, so thats used instead. >> > >> > tests/api/Makefile | 2 +- >> > 1 file changed, 1 insertion(+), 1 deletion(-) >> > >> > diff --git a/tests/api/Makefile b/tests/api/Makefile >> > index c48c34a..a6d8e42 100644 >> > --- a/tests/api/Makefile >> > +++ b/tests/api/Makefile >> > @@ -14,7 +14,7 @@ $(APITESTOBJS) $(APITESTOBJS:.o=.i): CPPFLAGS += -DTEST >> > $(APITESTOBJS) $(APITESTOBJS:.o=.i): CFLAGS += -Umain >> > >> > $(APITESTPROGS): %$(EXESUF): %.o $(EXEOBJS) $(FF_DEP_LIBS) >> > - $(LD) $(LDFLAGS) $(LDEXEFLAGS) $(LD_O) $(filter %.o,$^) >> > $(FF_DEP_LIBS) $(FFEXTRALIBS) $(ELIBS) >> > + $(LD) $(LDFLAGS) $(LDEXEFLAGS) $(LD_O) $(filter %.o,$^) >> > $(FF_EXTRALIBS) $(ELIBS) >> > >> > testclean:: >> > $(RM) $(addprefix $(APITESTSDIR)/,$(CLEANSUFFIXES) *-test$(EXESUF)) >> > -- >> > 2.6.2.windows.1 >> > >> >> Anyone that knows the build system a bit more? Or maybe anyone that > >> just feels like testing on some other systems than mine? :) > > seems to work on everything i tried but that probably is a small > subset of what is out there that is still a far larger set than what anyone else actively working on FFmpeg has AFAIK, and definitely supersedes what I have :). In other words, it is a best effort wrt development, and we can't hope for much more. > > [...] > -- > Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB > > it is not once nor twice but times without number that the same ideas make > their appearance in the world. -- Aristotle > > ___ > 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] [PATCHv2] avutil/crc: avoid needless space wastage of hardcoded crc table
On Tue, Dec 1, 2015 at 8:08 PM, James Almer wrote:
> On 12/1/2015 9:53 PM, Ganesh Ajjanagadde wrote:
>> There was no reason AFAIK for making AV_CRC_24_IEEE 12. This simply
>> resulted in wasted space under --enable-hardcoded-tables:
>> dynamic: 1318672 libavutil/libavutil.so.55
>> old: 1330680 libavutil/libavutil.so.55
>> new: 1326488 libavutil/libavutil.so.55
>>
>> Minor version number is bumped, with ifdefry due to API breakage.
>>
>> Signed-off-by: Ganesh Ajjanagadde
>> ---
>> libavutil/crc.h | 4
>> libavutil/version.h | 5 -
>> 2 files changed, 8 insertions(+), 1 deletion(-)
>>
>> diff --git a/libavutil/crc.h b/libavutil/crc.h
>> index e86bf1d..9af4421 100644
>> --- a/libavutil/crc.h
>> +++ b/libavutil/crc.h
>> @@ -40,7 +40,11 @@ typedef enum {
>> AV_CRC_32_IEEE,
>> AV_CRC_32_IEEE_LE, /*< reversed bitorder version of AV_CRC_32_IEEE */
>> AV_CRC_16_ANSI_LE, /*< reversed bitorder version of AV_CRC_16_ANSI */
>> +#if FF_API_CRC_BIG_TABLE
>> AV_CRC_24_IEEE = 12,
>> +#else
>> +AV_CRC_24_IEEE,
>> +#endif /* FF_API_CRC_BIG_TABLE */
>> AV_CRC_MAX, /*< Not part of public API! Do not use outside
>> libavutil. */
>> }AVCRCId;
>>
>> diff --git a/libavutil/version.h b/libavutil/version.h
>> index e0ddfd2..67e778a 100644
>> --- a/libavutil/version.h
>> +++ b/libavutil/version.h
>> @@ -56,7 +56,7 @@
>> */
>>
>> #define LIBAVUTIL_VERSION_MAJOR 55
>> -#define LIBAVUTIL_VERSION_MINOR 9
>> +#define LIBAVUTIL_VERSION_MINOR 10
>> #define LIBAVUTIL_VERSION_MICRO 100
>>
>> #define LIBAVUTIL_VERSION_INT AV_VERSION_INT(LIBAVUTIL_VERSION_MAJOR, \
>> @@ -108,6 +108,9 @@
>> #ifndef FF_API_ERROR_FRAME
>> #define FF_API_ERROR_FRAME (LIBAVUTIL_VERSION_MAJOR < 56)
>> #endif
>> +#ifndef FF_API_CRC_BIG_TABLE
>> +#define FF_API_CRC_BIG_TABLE(LIBAVUTIL_VERSION_INT <
>> AV_VERSION_INT(55, 10, 100))
>
> This is wrong. With this check, FF_API_CRC_BIG_TABLE is false. The point
> of these FF_API defines is to make sure they are true until the next major
> bump. That's why you use LIBAVUTIL_VERSION_MAJOR < 56, like it's being
> done for the rest.
Finally getting a sense for these things, thanks. Barring that, does
it look fine?
>
>> +#endif
>>
>>
>> /**
>>
>
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/2] ffprobe: Do not print profile names in -bitexact
On Fri, Nov 27, 2015 at 02:33:02PM -0800, Timothy Gu wrote: > Instead, print "unknown" if it's unknown, or their numerical values if > they are known. > --- > > Addresses Nicholas's comment. > > --- > ffprobe.c | 12 +--- > 1 file changed, 9 insertions(+), 3 deletions(-) Ping. Timothy ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCHv2] avutil/crc: avoid needless space wastage of hardcoded crc table
On 12/1/2015 10:35 PM, Ganesh Ajjanagadde wrote:
> On Tue, Dec 1, 2015 at 8:08 PM, James Almer wrote:
>> On 12/1/2015 9:53 PM, Ganesh Ajjanagadde wrote:
>>> There was no reason AFAIK for making AV_CRC_24_IEEE 12. This simply
>>> resulted in wasted space under --enable-hardcoded-tables:
>>> dynamic: 1318672 libavutil/libavutil.so.55
>>> old: 1330680 libavutil/libavutil.so.55
>>> new: 1326488 libavutil/libavutil.so.55
>>>
>>> Minor version number is bumped, with ifdefry due to API breakage.
>>>
>>> Signed-off-by: Ganesh Ajjanagadde
>>> ---
>>> libavutil/crc.h | 4
>>> libavutil/version.h | 5 -
>>> 2 files changed, 8 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/libavutil/crc.h b/libavutil/crc.h
>>> index e86bf1d..9af4421 100644
>>> --- a/libavutil/crc.h
>>> +++ b/libavutil/crc.h
>>> @@ -40,7 +40,11 @@ typedef enum {
>>> AV_CRC_32_IEEE,
>>> AV_CRC_32_IEEE_LE, /*< reversed bitorder version of AV_CRC_32_IEEE */
>>> AV_CRC_16_ANSI_LE, /*< reversed bitorder version of AV_CRC_16_ANSI */
>>> +#if FF_API_CRC_BIG_TABLE
>>> AV_CRC_24_IEEE = 12,
>>> +#else
>>> +AV_CRC_24_IEEE,
>>> +#endif /* FF_API_CRC_BIG_TABLE */
>>> AV_CRC_MAX, /*< Not part of public API! Do not use outside
>>> libavutil. */
>>> }AVCRCId;
>>>
>>> diff --git a/libavutil/version.h b/libavutil/version.h
>>> index e0ddfd2..67e778a 100644
>>> --- a/libavutil/version.h
>>> +++ b/libavutil/version.h
>>> @@ -56,7 +56,7 @@
>>> */
>>>
>>> #define LIBAVUTIL_VERSION_MAJOR 55
>>> -#define LIBAVUTIL_VERSION_MINOR 9
>>> +#define LIBAVUTIL_VERSION_MINOR 10
>>> #define LIBAVUTIL_VERSION_MICRO 100
>>>
>>> #define LIBAVUTIL_VERSION_INT AV_VERSION_INT(LIBAVUTIL_VERSION_MAJOR, \
>>> @@ -108,6 +108,9 @@
>>> #ifndef FF_API_ERROR_FRAME
>>> #define FF_API_ERROR_FRAME (LIBAVUTIL_VERSION_MAJOR < 56)
>>> #endif
>>> +#ifndef FF_API_CRC_BIG_TABLE
>>> +#define FF_API_CRC_BIG_TABLE(LIBAVUTIL_VERSION_INT <
>>> AV_VERSION_INT(55, 10, 100))
>>
>> This is wrong. With this check, FF_API_CRC_BIG_TABLE is false. The point
>> of these FF_API defines is to make sure they are true until the next major
>> bump. That's why you use LIBAVUTIL_VERSION_MAJOR < 56, like it's being
>> done for the rest.
>
> Finally getting a sense for these things, thanks. Barring that, does
> it look fine?
Yes. You can also skip bumping minor. You're scheduling a change for the next
major bump and not making any changes with immediate effects, so a minor bump
is not necessary.
>
>>
>>> +#endif
>>>
>>>
>>> /**
>>>
>>
>> ___
>> 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
>
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] AAC encoder: improve SF range utilization
On Tue, Dec 01, 2015 at 03:35:40AM -0300, Claudio Freire wrote: > On Mon, Nov 30, 2015 at 1:04 PM, Hendrik Leppkes wrote: > > On Mon, Nov 30, 2015 at 4:50 PM, Claudio Freire > > wrote: > >> On Mon, Nov 30, 2015 at 12:27 PM, Rostislav Pehlivanov > >> wrote: > >>> On Sun, 2015-11-29 at 16:54 -0300, Claudio Freire wrote: > Before pushing this, I'd like some feedback, > especially about > the implementation of point 3. I'm not sure the AAC encoder > setting the cutoff in the encoder context like this is legal or > desirable. > >>> I think setting the cutoff is necessary. You can't avoid holes and yet > >>> keep a full bandwidth as you decrease bits unless you like the sound of > >>> massive quantization errors. > >> > >> My point was more about whether a codec should write into the context > >> struct like that or not. Basically an API technicality that's unclear > >> to me. > >> > > > > It seems slightly odd to write into that variable, since thats the > > cutoff the user requests. > > Maybe you can use/write into a private variable instead? ac3enc seems > > to use a private variable for similar purposes. > > Attached patch does that. > > I'm far more comfortable with this implementation, so if all agree, I'll push. > > On Mon, Nov 30, 2015 at 2:20 PM, Rostislav Pehlivanov > wrote: > > On Mon, 2015-11-30 at 12:50 -0300, Claudio Freire wrote: > >> Also I don't see how a static var would help or even be correct here. > >> Perhaps you meant something else? > > static uint8_t cond1 = param1 && param2; > > static uint8_t cond2 = param3 && !param4; > > ...etc > > return cond1 && cond2; > > I didn't do that since it would not short circuit some terms that > ought to be short-circuited. > > But I did split lines and it does read better. In fact, maybe that was > all that was needed? > libavcodec/aaccoder.c | 60 -- > libavcodec/aaccoder_twoloop.h | 136 > -- > libavcodec/aacenc.c |2 > libavcodec/aacenc_is.c| 11 ++- > libavcodec/aacenc_utils.h | 63 +++ > libavcodec/aacpsy.c | 20 -- > libavcodec/psymodel.c |1 > libavcodec/psymodel.h |1 > tests/fate/aac.mak| 18 ++--- > 9 files changed, 231 insertions(+), 81 deletions(-) > 404ff616bb267619be431a7c45afa4db82070b65 > 0001-AAC-encoder-improve-SF-range-utilization.patch some stuff in mips will need to be updated by someone or disabled after this is pushed: CC libavcodec/aacpsy.o /ffmpeg/libavcodec/aacpsy.c: In function ‘psy_3gpp_analyze_channel’: /ffmpeg/libavcodec/aacpsy.c:666: error: too many arguments to function ‘calc_thr_3gpp_mips’ make: *** [libavcodec/aacpsy.o] Error 1 make: Target `all' not remade because of errors. [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB During times of universal deceit, telling the truth becomes a revolutionary act. -- George Orwell 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 audio pulsator filter
On Tue, Dec 1, 2015 at 7:04 AM, Paul B Mahol wrote:
> Signed-off-by: Paul B Mahol
> ---
> doc/filters.texi | 57 +
> libavfilter/Makefile | 1 +
> libavfilter/af_apulsator.c | 279
> +
> libavfilter/allfilters.c | 1 +
> 4 files changed, 338 insertions(+)
> create mode 100644 libavfilter/af_apulsator.c
>
> diff --git a/doc/filters.texi b/doc/filters.texi
> index fc71a99..a4afcac 100644
> --- a/doc/filters.texi
> +++ b/doc/filters.texi
> @@ -1030,6 +1030,63 @@ It accepts the following values:
> @end table
> @end table
>
> +@section apulsator
> +
> +Audio pulsator is something between an autopanner and a tremolo.
> +But it can produce funny stereo effects as well. Pulsator changes the volume
> +of the left and right channel based on a LFO (low frequency oscillator) with
> +different waveforms and shifted phases.
> +This filter have the ability to define an offset between left and right
> +channel. An offset of 0 means that both LFO shapes match each other.
> +The left and right channel are altered equally - a conventional tremolo.
> +An offset of 50% means that the shape of the right channel is exactly shifted
> +in phase (or moved backwards about half of the frequency) - pulsator acts as
> +an autopanner. At 1 both curves match again. Every setting in between moves
> the
> +phase shift gapless between all stages and produces some "bypassing" sounds
> with
> +sine and triangle waveforms. The more you set the offset near 1 (starting
> from
> +the 0.5) the faster the signal passes from the left to the right speaker.
> +
> +The filter accepts the following options:
> +
> +@table @option
> +@item level_in
> +Set input gain. By default it is 1. Range is [0.015625 - 64].
> +
> +@item level_out
> +Set output gain. By default it is 1. Range is [0.015625 - 64].
> +
> +@item mode
> +Set waveform shape the LFO will use. Can be one of: sine, triangle, square,
> +sawup or sawdown. Default is sine.
> +
> +@item amount
> +Set modulation. Define how much of original signal is affected by the LFO.
> +
> +@item offset_l
> +Set left channel offset. Default is 0. Allowed range is [0 - 1].
> +
> +@item offset_r
> +Set right channel offset. Default is 0.5. Allowed range is [0 - 1].
> +
> +@item width
> +Set pulse width.
> +
> +@item timing
> +Set possible timing mode. Can be one of: bpm, ms or hz. Default is hz.
> +
> +@item bpm
> +Set bpm. Default is 120. Allowed range is [30 - 300]. Only used if timing
> +is set to bpm.
> +
> +@item ms
> +Set ms. Default is 500. Allowed range is [10 - 2000]. Only used if timing
> +is set to ms.
> +
> +@item hz
> +Set frequency in Hz. Default is 2. Allowed range is [0.01 - 100]. Only used
> +if timing is set to hz.
> +@end table
> +
> @anchor{aresample}
> @section aresample
>
> diff --git a/libavfilter/Makefile b/libavfilter/Makefile
> index e31bdaa..b6c0d7b 100644
> --- a/libavfilter/Makefile
> +++ b/libavfilter/Makefile
> @@ -40,6 +40,7 @@ OBJS-$(CONFIG_ANULL_FILTER) += af_anull.o
> OBJS-$(CONFIG_APAD_FILTER) += af_apad.o
> OBJS-$(CONFIG_APERMS_FILTER) += f_perms.o
> OBJS-$(CONFIG_APHASER_FILTER)+= af_aphaser.o
> generate_wave_table.o
> +OBJS-$(CONFIG_APULSATOR_FILTER) += af_apulsator.o
> OBJS-$(CONFIG_AREALTIME_FILTER) += f_realtime.o
> OBJS-$(CONFIG_ARESAMPLE_FILTER) += af_aresample.o
> OBJS-$(CONFIG_AREVERSE_FILTER) += f_reverse.o
> diff --git a/libavfilter/af_apulsator.c b/libavfilter/af_apulsator.c
> new file mode 100644
> index 000..9100eff
> --- /dev/null
> +++ b/libavfilter/af_apulsator.c
> @@ -0,0 +1,279 @@
> +/*
> + * Copyright (c) 2001-2010 Krzysztof Foltman, Markus Schmidt, Thor Harald
> Johansen and others
> + *
> + * This file is part of FFmpeg.
> + *
> + * FFmpeg is free software; you can redistribute it and/or
> + * modify it under the terms of the GNU Lesser General Public
> + * License as published by the Free Software Foundation; either
> + * version 2.1 of the License, or (at your option) any later version.
> + *
> + * FFmpeg is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
> + * Lesser General Public License for more details.
> + *
> + * You should have received a copy of the GNU Lesser General Public
> + * License along with FFmpeg; if not, write to the Free Software
> + * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301
> USA
> + */
> +
> +#include "libavutil/opt.h"
> +#include "avfilter.h"
> +#include "internal.h"
> +#include "audio.h"
> +
> +enum PulsatorModes { SINE, TRIANGLE, SQUARE, SAWUP, SAWDOWN, NB_MODES };
> +enum PulsatorTimings { UNIT_BPM, UNIT_MS, UNIT_HZ, NB_TIMINGS };
> +
> +typedef struct SimpleLFO {
> +double phase;
> +double freq;
> +double offset;
> +double
Re: [FFmpeg-devel] [PATCHv2] avutil/crc: avoid needless space wastage of hardcoded crc table
On Tue, Dec 1, 2015 at 8:38 PM, James Almer wrote:
> On 12/1/2015 10:35 PM, Ganesh Ajjanagadde wrote:
>> On Tue, Dec 1, 2015 at 8:08 PM, James Almer wrote:
>>> On 12/1/2015 9:53 PM, Ganesh Ajjanagadde wrote:
There was no reason AFAIK for making AV_CRC_24_IEEE 12. This simply
resulted in wasted space under --enable-hardcoded-tables:
dynamic: 1318672 libavutil/libavutil.so.55
old: 1330680 libavutil/libavutil.so.55
new: 1326488 libavutil/libavutil.so.55
Minor version number is bumped, with ifdefry due to API breakage.
Signed-off-by: Ganesh Ajjanagadde
---
libavutil/crc.h | 4
libavutil/version.h | 5 -
2 files changed, 8 insertions(+), 1 deletion(-)
diff --git a/libavutil/crc.h b/libavutil/crc.h
index e86bf1d..9af4421 100644
--- a/libavutil/crc.h
+++ b/libavutil/crc.h
@@ -40,7 +40,11 @@ typedef enum {
AV_CRC_32_IEEE,
AV_CRC_32_IEEE_LE, /*< reversed bitorder version of AV_CRC_32_IEEE */
AV_CRC_16_ANSI_LE, /*< reversed bitorder version of AV_CRC_16_ANSI */
+#if FF_API_CRC_BIG_TABLE
AV_CRC_24_IEEE = 12,
+#else
+AV_CRC_24_IEEE,
+#endif /* FF_API_CRC_BIG_TABLE */
AV_CRC_MAX, /*< Not part of public API! Do not use outside
libavutil. */
}AVCRCId;
diff --git a/libavutil/version.h b/libavutil/version.h
index e0ddfd2..67e778a 100644
--- a/libavutil/version.h
+++ b/libavutil/version.h
@@ -56,7 +56,7 @@
*/
#define LIBAVUTIL_VERSION_MAJOR 55
-#define LIBAVUTIL_VERSION_MINOR 9
+#define LIBAVUTIL_VERSION_MINOR 10
#define LIBAVUTIL_VERSION_MICRO 100
#define LIBAVUTIL_VERSION_INT AV_VERSION_INT(LIBAVUTIL_VERSION_MAJOR, \
@@ -108,6 +108,9 @@
#ifndef FF_API_ERROR_FRAME
#define FF_API_ERROR_FRAME (LIBAVUTIL_VERSION_MAJOR < 56)
#endif
+#ifndef FF_API_CRC_BIG_TABLE
+#define FF_API_CRC_BIG_TABLE(LIBAVUTIL_VERSION_INT <
AV_VERSION_INT(55, 10, 100))
>>>
>>> This is wrong. With this check, FF_API_CRC_BIG_TABLE is false. The point
>>> of these FF_API defines is to make sure they are true until the next major
>>> bump. That's why you use LIBAVUTIL_VERSION_MAJOR < 56, like it's being
>>> done for the rest.
>>
>> Finally getting a sense for these things, thanks. Barring that, does
>> it look fine?
>
> Yes. You can also skip bumping minor. You're scheduling a change for the next
> major bump and not making any changes with immediate effects, so a minor bump
> is not necessary.
Would like to ask for comments regarding always hard or always soft
tables. Clearly, with this change (to be pushed soon), the space cost
of hardcoded tables is reduced once we do a major bump, and the
overhead of --enable-hardcoded-tables here is ~8 kB, down from ~ 12
kB.
I personally have a very slight preference for runtime tables here
(the default configure), since the runtime generation code anyway
needs to be present for nonstandard crc's but am definitely ok with
hardcoded as well. In any case, as the size is small, we should be
able to come to a decision here, and not continue to be on the fence
for this one unlike e.g mpegaudio_tablegen.
[...]
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 2/9] avfilter/vf_perspective: use lrint instead of floor hack
On Tue, Dec 01, 2015 at 07:27:51PM -0500, Ganesh Ajjanagadde wrote: > Signed-off-by: Ganesh Ajjanagadde > --- > libavfilter/vf_perspective.c | 10 +- > 1 file changed, 5 insertions(+), 5 deletions(-) should be ok [...] -- 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: Digital signature ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 1/9] avfilter/vsrc_mptestsrc: use lrint instead of floor hack
On Tue, Dec 01, 2015 at 07:27:50PM -0500, Ganesh Ajjanagadde wrote: > lrint is faster, and is more consistent across the codebase. > > Signed-off-by: Ganesh Ajjanagadde > --- > libavfilter/vsrc_mptestsrc.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) should be ok [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB While the State exists there can be no freedom; when there is freedom there will be no State. -- 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] AAC encoder: improve SF range utilization
On Tue, Dec 1, 2015 at 10:47 PM, Michael Niedermayer wrote: >> libavcodec/aaccoder.c | 60 -- >> libavcodec/aaccoder_twoloop.h | 136 >> -- >> libavcodec/aacenc.c |2 >> libavcodec/aacenc_is.c| 11 ++- >> libavcodec/aacenc_utils.h | 63 +++ >> libavcodec/aacpsy.c | 20 -- >> libavcodec/psymodel.c |1 >> libavcodec/psymodel.h |1 >> tests/fate/aac.mak| 18 ++--- >> 9 files changed, 231 insertions(+), 81 deletions(-) >> 404ff616bb267619be431a7c45afa4db82070b65 >> 0001-AAC-encoder-improve-SF-range-utilization.patch > > some stuff in mips will need to be updated by someone or disabled > after this is pushed: > CC libavcodec/aacpsy.o > /ffmpeg/libavcodec/aacpsy.c: In function ‘psy_3gpp_analyze_channel’: > /ffmpeg/libavcodec/aacpsy.c:666: error: too many arguments to function > ‘calc_thr_3gpp_mips’ > make: *** [libavcodec/aacpsy.o] Error 1 > make: Target `all' not remade because of errors. Oh, didn't realize mips had an alternative calc_thr_3gpp. I'll see about updating it as I push. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 1/3] common.mak: Use CCFLAGS for assembly generation as well
CCFLAGS is equivalent to CPPFLAGS + CFLAGS. --- common.mak | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/common.mak b/common.mak index d611ef8..05836ba 100644 --- a/common.mak +++ b/common.mak @@ -63,7 +63,7 @@ COMPILE_HOSTC = $(call COMPILE,HOSTCC) $(COMPILE_C) %.s: %.c - $(CC) $(CPPFLAGS) $(CFLAGS) -S -o $@ $< + $(CC) $(CCFLAGS) -S -o $@ $< %.o: %.S $(COMPILE_S) -- 2.1.4 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 2/3] decklink: Header cleanup
---
libavdevice/decklink_common.cpp | 4
libavdevice/decklink_common.h | 8 +++-
libavdevice/decklink_common_c.h | 2 ++
libavdevice/decklink_dec.cpp| 4
libavdevice/decklink_dec.h | 2 ++
libavdevice/decklink_enc.cpp| 4
libavdevice/decklink_enc.h | 2 ++
7 files changed, 13 insertions(+), 13 deletions(-)
diff --git a/libavdevice/decklink_common.cpp b/libavdevice/decklink_common.cpp
index ac7964c..58502ee 100644
--- a/libavdevice/decklink_common.cpp
+++ b/libavdevice/decklink_common.cpp
@@ -26,11 +26,7 @@
#include
#endif
-#include
-#include
-
extern "C" {
-#include "libavformat/avformat.h"
#include "libavformat/internal.h"
#include "libavutil/imgutils.h"
}
diff --git a/libavdevice/decklink_common.h b/libavdevice/decklink_common.h
index 3bc30f0..c7e3ef2 100644
--- a/libavdevice/decklink_common.h
+++ b/libavdevice/decklink_common.h
@@ -19,9 +19,15 @@
* Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA
*/
-#include
+#include
+#include
+#include
+
+extern "C" {
+#include "libavformat/avformat.h"
#include "decklink_common_c.h"
+}
class decklink_output_callback;
class decklink_input_callback;
diff --git a/libavdevice/decklink_common_c.h b/libavdevice/decklink_common_c.h
index fb2b788..3644fb4 100644
--- a/libavdevice/decklink_common_c.h
+++ b/libavdevice/decklink_common_c.h
@@ -19,6 +19,8 @@
* Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA
*/
+#include "libavutil/log.h"
+
struct decklink_cctx {
const AVClass *cclass;
diff --git a/libavdevice/decklink_dec.cpp b/libavdevice/decklink_dec.cpp
index 89f93de..da8e42b 100644
--- a/libavdevice/decklink_dec.cpp
+++ b/libavdevice/decklink_dec.cpp
@@ -21,11 +21,7 @@
#include
-#include
-#include
-
extern "C" {
-#include "libavformat/avformat.h"
#include "libavformat/internal.h"
#include "libavutil/imgutils.h"
}
diff --git a/libavdevice/decklink_dec.h b/libavdevice/decklink_dec.h
index 6bd9226..c499bc9 100644
--- a/libavdevice/decklink_dec.h
+++ b/libavdevice/decklink_dec.h
@@ -23,6 +23,8 @@
extern "C" {
#endif
+#include "libavformat/avformat.h"
+
int ff_decklink_read_header(AVFormatContext *avctx);
int ff_decklink_read_packet(AVFormatContext *avctx, AVPacket *pkt);
int ff_decklink_read_close(AVFormatContext *avctx);
diff --git a/libavdevice/decklink_enc.cpp b/libavdevice/decklink_enc.cpp
index 6c5450f..334c3dc 100644
--- a/libavdevice/decklink_enc.cpp
+++ b/libavdevice/decklink_enc.cpp
@@ -21,11 +21,7 @@
#include
-#include
-#include
-
extern "C" {
-#include "libavformat/avformat.h"
#include "libavformat/internal.h"
#include "libavutil/imgutils.h"
}
diff --git a/libavdevice/decklink_enc.h b/libavdevice/decklink_enc.h
index 6086947..23c59a2 100644
--- a/libavdevice/decklink_enc.h
+++ b/libavdevice/decklink_enc.h
@@ -23,6 +23,8 @@
extern "C" {
#endif
+#include "libavformat/avformat.h"
+
int ff_decklink_write_header(AVFormatContext *avctx);
int ff_decklink_write_packet(AVFormatContext *avctx, AVPacket *pkt);
int ff_decklink_write_trailer(AVFormatContext *avctx);
--
2.1.4
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 3/3] avdevice: Mark decklink_common.h as unconditional SKIPHEADER
It is a C++ file, incompatible with the checkheaders infrastructure. --- libavdevice/Makefile | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/libavdevice/Makefile b/libavdevice/Makefile index f57ec0b..8394e87 100644 --- a/libavdevice/Makefile +++ b/libavdevice/Makefile @@ -58,8 +58,9 @@ OBJS-$(HAVE_LIBC_MSVCRT) += file_open.o # Windows resource file SLIBOBJS-$(HAVE_GNU_WINDRES) += avdeviceres.o +SKIPHEADERS += decklink_common.h SKIPHEADERS-$(CONFIG_DECKLINK) += decklink_enc.h decklink_dec.h \ -decklink_common.h decklink_common_c.h +decklink_common_c.h SKIPHEADERS-$(CONFIG_DSHOW_INDEV)+= dshow_capture.h SKIPHEADERS-$(CONFIG_FBDEV_INDEV)+= fbdev_common.h SKIPHEADERS-$(CONFIG_FBDEV_OUTDEV) += fbdev_common.h -- 2.1.4 ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH] avfilter: add audio pulsator filter
On 12/2/15, Ganesh Ajjanagadde wrote:
>> +static void lfo_advance(SimpleLFO *lfo, unsigned count)
>> +{
>> +lfo->phase = fabs(lfo->phase + count * lfo->freq / lfo->srate);
>> +if (lfo->phase >= 1)
>> +lfo->phase = fmod(lfo->phase, 1);
>> +}
>> +
>> +static double lfo_get_value(SimpleLFO *lfo)
>> +{
>> +double phs = FFMIN(100, lfo->phase / FFMIN(1.99, FFMAX(0.01,
>> lfo->pwidth)) + lfo->offset);
>> +double val;
>> +
>> +if (phs > 1)
>> +phs = fmod(phs, 1.);
>> +
>> +switch (lfo->mode) {
>> +case SINE:
>> +val = sin(phs * 2 * M_PI);
>> +break;
>> +case TRIANGLE:
>> +if (phs > 0.75)
>> +val = (phs - 0.75) * 4 - 1;
>> +else if (phs > 0.5)
>> +val = (phs - 0.5) * 4 * -1;
>> +else if (phs > 0.25)
>> +val = 1 - (phs - 0.25) * 4;
>> +else
>> +val = phs * 4;
>
> Why didn't you remove the useless branch and replace with a simple
> -4*phs + 2 for 0.25 to 0.75 case?
>
> I guess you did not remove the branch because you believed (but have
> not substantiated) that some notion of "bit-exactness" (highly dubious
> since floating point is not reproducible exactly across all platforms)
> with respect to some reference is violated. This "reference" is copied
> over from some other source code with no link whatsoever in the commit
> message or for the reviewer; only a simple copyright notice, making it
> impossible for a reviewer to do a proper review.
>
> [...]
In both cases the output is different and that is for s16 output case.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 4/9] avfilter/af_flanger: use rint instead of floor hack
On 12/2/15, Ganesh Ajjanagadde wrote: > Signed-off-by: Ganesh Ajjanagadde > --- > libavfilter/af_flanger.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/libavfilter/af_flanger.c b/libavfilter/af_flanger.c > index f8ec830..a92367c 100644 > --- a/libavfilter/af_flanger.c > +++ b/libavfilter/af_flanger.c > @@ -130,7 +130,7 @@ static int config_input(AVFilterLink *inlink) > return AVERROR(ENOMEM); > > ff_generate_wave_table(s->wave_shape, AV_SAMPLE_FMT_FLT, s->lfo, > s->lfo_length, > - floor(s->delay_min * inlink->sample_rate + 0.5), > + rint(s->delay_min * inlink->sample_rate), > s->max_samples - 2., 3 * M_PI_2); > > return av_samples_alloc_array_and_samples(&s->delay_buffer, NULL, > -- > 2.6.2 > > ___ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel > Have you checked that output is same? ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 3/9] avfilter/af_stereotools: use lrint instead of floor hack
On 12/2/15, Ganesh Ajjanagadde wrote: > Signed-off-by: Ganesh Ajjanagadde > --- > libavfilter/af_stereotools.c | 8 > 1 file changed, 4 insertions(+), 4 deletions(-) > > diff --git a/libavfilter/af_stereotools.c b/libavfilter/af_stereotools.c > index a22efb0..e878824 100644 > --- a/libavfilter/af_stereotools.c > +++ b/libavfilter/af_stereotools.c > @@ -139,10 +139,10 @@ static int filter_frame(AVFilterLink *inlink, AVFrame > *in) > const double sc_level = s->sc_level; > const double delay = s->delay; > const int length = s->length; > -const int mute_l = floor(s->mute_l + 0.5); > -const int mute_r = floor(s->mute_r + 0.5); > -const int phase_l = floor(s->phase_l + 0.5); > -const int phase_r = floor(s->phase_r + 0.5); > +const int mute_l = lrint(s->mute_l); > +const int mute_r = lrint(s->mute_r); > +const int phase_l = lrint(s->phase_l); > +const int phase_r = lrint(s->phase_r); > double *buffer = s->buffer; > AVFrame *out; > double *dst; > -- > 2.6.2 > > ___ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > http://ffmpeg.org/mailman/listinfo/ffmpeg-devel > ok ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 2/2] avfilter: add sidechaingate filter
On 12/2/15, Ganesh Ajjanagadde wrote: > On Tue, Dec 1, 2015 at 2:14 PM, Paul B Mahol wrote: >> On 12/1/15, Nicolas George wrote: >>> Le primidi 11 frimaire, an CCXXIV, Paul B Mahol a ecrit : Similar how its freed when no longer used. >>> >>> Please elaborate. I know the API, I do not see what you suggest. >>> >>> (Thanks for trimming.) >>> >>> Regards, >> >> After carefully looking at this functon, I see no leaking at all. > > Care to elaborate on this? My question is: what happens when e.g > layouts get set and allocated/ref'ed correctly, but while trying to > allocate formats, ENOMEM occurs? Or in other words, where does the > formats get deallocated in such a case? And why does Coverity flag > these things? Maybe it is for test program: libavfilter/filtfmts.c ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Re: [FFmpeg-devel] [PATCH 2/2] avfilter: add sidechaingate filter
On 12/2/15, Paul B Mahol wrote: > On 12/2/15, Ganesh Ajjanagadde wrote: >> On Tue, Dec 1, 2015 at 2:14 PM, Paul B Mahol wrote: >>> On 12/1/15, Nicolas George wrote: Le primidi 11 frimaire, an CCXXIV, Paul B Mahol a ecrit : > Similar how its freed when no longer used. Please elaborate. I know the API, I do not see what you suggest. (Thanks for trimming.) Regards, >>> >>> After carefully looking at this functon, I see no leaking at all. >> >> Care to elaborate on this? My question is: what happens when e.g >> layouts get set and allocated/ref'ed correctly, but while trying to >> allocate formats, ENOMEM occurs? Or in other words, where does the >> formats get deallocated in such a case? And why does Coverity flag >> these things? > > Maybe it is for test program: libavfilter/filtfmts.c > Also I changed return value of query_formats to always be -1 and run program under 'valgrind --leak-check=full --show-leak-kinds=all' I see unrelated leaks from af_aformat and others, and no leaks from query_formats. PS: I better wasted this time on writing equirectangular2cubic filter. ___ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
