On Thu, Nov 26, 2015 at 6:04 AM, Ganesh Ajjanagadde
wrote:
> This is needed in order to obtain what is available for hardcoded
> table generation.
>
> A minimal avutil/host_libm.h is also created.
>
I'm really not a fan of this change. configure is slow and complex
enough as it is, and host tools
On Tue, Nov 10, 2015 at 1:41 AM, Timothy Gu wrote:
> On Sun, Nov 8, 2015 at 9:28 AM Claudio Freire
> wrote:
>>
>> This particular piece of code is going to disappear soon, so not sure
>> it's worth applying the patch.
>
>
> Oh, okay then.
Funny thing, in the end it's going to survive, so I'm go
---
ffprobe.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/ffprobe.c b/ffprobe.c
index c304a6d..216db379 100644
--- a/ffprobe.c
+++ b/ffprobe.c
@@ -2148,7 +2148,7 @@ static int show_stream(WriterContext *w, AVFormatContext
*fmt_ctx, int stream_id
}
}
Fixes FATE failures on --enable-small builds.
---
tests/fate-run.sh | 4 ++--
tests/ref/fate/concat-demuxer-extended-lavf-mxf | 2 +-
tests/ref/fate/concat-demuxer-extended-lavf-mxf_d10 | 2 +-
tests/ref/fate/concat-demuxer-simple1-lavf-mxf | 4 ++--
test
This is needed in order to obtain what is available for hardcoded
table generation.
A minimal avutil/host_libm.h is also created.
Signed-off-by: Ganesh Ajjanagadde
---
configure | 41 +
libavutil/host_libm.h | 51 ++
On Wed, Nov 25, 2015 at 10:13 PM, Ronald S. Bultje wrote:
> Hi,
>
> On Wed, Nov 25, 2015 at 8:48 PM, Ganesh Ajjanagadde
> wrote:
>>
>> On Wed, Nov 25, 2015 at 8:29 PM, Ganesh Ajjanagadde
>> wrote:
>> > On Wed, Nov 25, 2015 at 8:19 PM, Ronald S. Bultje
>> > wrote:
>> >> Hi,
>> >>
>> >> On Wed, N
Hi,
On Wed, Nov 25, 2015 at 8:48 PM, Ganesh Ajjanagadde
wrote:
> On Wed, Nov 25, 2015 at 8:29 PM, Ganesh Ajjanagadde
> wrote:
> > On Wed, Nov 25, 2015 at 8:19 PM, Ronald S. Bultje
> wrote:
> >> Hi,
> >>
> >> On Wed, Nov 25, 2015 at 7:36 PM, Ganesh Ajjanagadde
> >> wrote:
> >>
> >>> On Wed, No
On Wed, Nov 25, 2015 at 6:32 PM, Ganesh Ajjanagadde
wrote:
> On Wed, Nov 25, 2015 at 6:19 PM, Ronald S. Bultje wrote:
>> Hi,
>>
>> On Wed, Nov 25, 2015 at 5:17 PM, Ganesh Ajjanagadde
>> wrote:
>>>
>>> On systems having cbrt, there is no reason to use the slow pow function.
>>>
>>> Sample benchma
On Wed, Nov 25, 2015 at 9:22 PM, Timothy Gu wrote:
> On Wed, Nov 25, 2015 at 6:03 PM Timothy Gu wrote:
>
>> On Wed, Nov 25, 2015 at 05:17:29PM -0500, Ganesh Ajjanagadde wrote:
>> > +double f = value * cbrt_lut[value] * pow(2, (exponent -
>> 400) * 0.25 + FRAC_BITS + 5) / IMDCT_SCALAR;
On Wed, Nov 25, 2015 at 6:03 PM Timothy Gu wrote:
> On Wed, Nov 25, 2015 at 05:17:29PM -0500, Ganesh Ajjanagadde wrote:
> > +double f = value * cbrt_lut[value] * pow(2, (exponent -
> 400) * 0.25 + FRAC_BITS + 5) / IMDCT_SCALAR;
>
> While at it, you could change pow(2 to exp2(, which h
On Wed, Nov 25, 2015 at 9:03 PM, Timothy Gu wrote:
> On Wed, Nov 25, 2015 at 05:17:29PM -0500, Ganesh Ajjanagadde wrote:
>> +double f = value * cbrt_lut[value] * pow(2, (exponent - 400) *
>> 0.25 + FRAC_BITS + 5) / IMDCT_SCALAR;
>
> While at it, you could change pow(2 to exp2(, which
On Wed, Nov 25, 2015 at 05:17:29PM -0500, Ganesh Ajjanagadde wrote:
> +double f = value * cbrt_lut[value] * pow(2, (exponent - 400) *
> 0.25 + FRAC_BITS + 5) / IMDCT_SCALAR;
While at it, you could change pow(2 to exp2(, which has a libm.h shim
and is easily 4 times faster than pow() o
On Wed, Nov 25, 2015 at 8:29 PM, Ganesh Ajjanagadde wrote:
> On Wed, Nov 25, 2015 at 8:19 PM, Ronald S. Bultje wrote:
>> Hi,
>>
>> On Wed, Nov 25, 2015 at 7:36 PM, Ganesh Ajjanagadde
>> wrote:
>>
>>> On Wed, Nov 25, 2015 at 6:49 PM, James Almer wrote:
>>> > On 11/25/2015 8:32 PM, Ganesh Ajjanag
On Wed, Nov 25, 2015 at 8:19 PM, Ronald S. Bultje wrote:
> Hi,
>
> On Wed, Nov 25, 2015 at 7:36 PM, Ganesh Ajjanagadde
> wrote:
>
>> On Wed, Nov 25, 2015 at 6:49 PM, James Almer wrote:
>> > On 11/25/2015 8:32 PM, Ganesh Ajjanagadde wrote:
>> >> On Wed, Nov 25, 2015 at 6:19 PM, Ronald S. Bultje
Hi,
On Wed, Nov 25, 2015 at 7:36 PM, Ganesh Ajjanagadde
wrote:
> On Wed, Nov 25, 2015 at 6:49 PM, James Almer wrote:
> > On 11/25/2015 8:32 PM, Ganesh Ajjanagadde wrote:
> >> On Wed, Nov 25, 2015 at 6:19 PM, Ronald S. Bultje
> wrote:
> >>> Hi,
> >>>
> >>> On Wed, Nov 25, 2015 at 5:17 PM, Ganes
On Tue, Nov 24, 2015 at 10:43 AM Kirill Gavrilov
wrote:
> On Mon, Nov 23, 2015 at 11:37 PM, Aaron Colwell
> wrote:
>
> > matroskaenc.c applies divisors to the display width/height when
> generating
> > stereo content. This patch adds the corresponding multipliers to
> > matroskadec.c
> > so that
On Wed, Nov 25, 2015 at 6:49 PM, James Almer wrote:
> On 11/25/2015 8:32 PM, Ganesh Ajjanagadde wrote:
>> On Wed, Nov 25, 2015 at 6:19 PM, Ronald S. Bultje wrote:
>>> Hi,
>>>
>>> On Wed, Nov 25, 2015 at 5:17 PM, Ganesh Ajjanagadde
>>> wrote:
On systems having cbrt, there is no reason t
On Wed, Nov 25, 2015 at 09:14:48PM +0100, Matthieu Bouron wrote:
> On Wed, Nov 25, 2015 at 06:36:03PM +0100, Michael Niedermayer wrote:
> > On Wed, Nov 25, 2015 at 03:40:15PM +0100, Matthieu Bouron wrote:
> > > From: Matthieu Bouron
[...]
> >
> > > +
> > > +static int try_decode_video_frame(AVCode
On Thu, Nov 19, 2015 at 12:58:35AM +0100, Michael Niedermayer wrote:
> From: Michael Niedermayer
>
> It appears rets_count is redundant
>
> Signed-off-by: Michael Niedermayer
> ---
> libavcodec/pthread_slice.c |5 +
> 1 file changed, 1 insertion(+), 4 deletions(-)
applied
[...]
--
M
On Friday 20 November 2015 02:59:34 am James Almer wrote:
> On 11/19/2015 10:05 PM, Carl Eugen Hoyos wrote:
> > Hi!
> >
> > Attached patch fixes a memleak with the sample from bug 909.
> > /* find out the channel configuration */
> > ret = ff_opus_parse_extradata(avctx, c);
> > -if (
On Tuesday 24 November 2015 02:16:11 am Michael Niedermayer wrote:
> On Tue, Nov 24, 2015 at 12:44:34AM +0100, Carl Eugen Hoyos wrote:
> > Hi!
> >
> > Attached patch allows more extensions for hevc, as requested
> > on the user mailing list.
> >
> > Please comment, Carl Eugen
>
> should be ok
Pat
On 11/25/2015 8:32 PM, Ganesh Ajjanagadde wrote:
> On Wed, Nov 25, 2015 at 6:19 PM, Ronald S. Bultje wrote:
>> Hi,
>>
>> On Wed, Nov 25, 2015 at 5:17 PM, Ganesh Ajjanagadde
>> wrote:
>>>
>>> On systems having cbrt, there is no reason to use the slow pow function.
>>>
>>> Sample benchmark (x86-64,
On Wednesday 25 November 2015 12:57:07 am Tomas Härdin wrote:
> On Tue, 2015-11-24 at 12:02 +0100, Carl Eugen Hoyos wrote:
> > Hi!
> >
> > Attached patch fixes ticket #5029.
> >
> > Please comment, Carl Eugen
>
> Looks simple enough, but (ab)using MXFCodecUL like that
> has a slight stink to it.
On Wed, Nov 25, 2015 at 6:19 PM, Ronald S. Bultje wrote:
> Hi,
>
> On Wed, Nov 25, 2015 at 5:17 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
Hi,
On Wed, Nov 25, 2015 at 5:17 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
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 (
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
Signed-off-by: Ganesh Ajjanagadde
---
libavformat/matroskaenc.c | 43 +++
1 file changed, 35 insertions(+), 8 deletions(-)
diff --git a/libavformat/matroskaenc.c b/libavformat/matroskaenc.c
index 10cf0a0..41aa8e0 100644
--- a/libavformat/matroskaenc.c
+++ b/libavformat/matroskaenc.c
@@ -845
---
libavformat/avformat.h | 12
libavformat/utils.c| 20
2 files changed, 32 insertions(+)
diff --git a/libavformat/avformat.h b/libavformat/avformat.h
index bb3a674..33f6d28 100644
--- a/libavformat/avformat.h
+++ b/libavformat/avformat.h
@@ -2799,6 +2799,1
This solves the problem discussed in
https://ffmpeg.org/pipermail/ffmpeg-devel/2015-September/179238.html
by allowing AVCodec::write_header to be delayed until after packets have been
run through required bitstream filters in order to generate global extradata.
It also provides a mechanism by whi
---
libavformat/tee.c | 44 +++-
1 file changed, 3 insertions(+), 41 deletions(-)
diff --git a/libavformat/tee.c b/libavformat/tee.c
index af52a49..8c54d32 100644
--- a/libavformat/tee.c
+++ b/libavformat/tee.c
@@ -405,45 +405,6 @@ fail:
return ret;
}
---
ffmpeg.c | 46 --
ffmpeg.h | 1 -
ffmpeg_opt.c | 6 +-
3 files changed, 9 insertions(+), 44 deletions(-)
diff --git a/ffmpeg.c b/ffmpeg.c
index bf5e983..c24c8ed 100644
--- a/ffmpeg.c
+++ b/ffmpeg.c
@@ -683,47 +683,10 @@ static void wri
---
libavformat/avformat.h | 11 +++
libavformat/utils.c| 49 +
2 files changed, 60 insertions(+)
diff --git a/libavformat/avformat.h b/libavformat/avformat.h
index 36f9d02..d94191e 100644
--- a/libavformat/avformat.h
+++ b/libavformat/a
---
libavcodec/aac_ac3_parser.c | 45 +++--
1 file changed, 23 insertions(+), 22 deletions(-)
diff --git a/libavcodec/aac_ac3_parser.c b/libavcodec/aac_ac3_parser.c
index 6a76eb8..c9ba6bf 100644
--- a/libavcodec/aac_ac3_parser.c
+++ b/libavcodec/aac_ac3_par
This caused issues when seeking in some unusual MPEGTS files
---
libavcodec/aac_ac3_parser.c | 4
1 file changed, 4 insertions(+)
diff --git a/libavcodec/aac_ac3_parser.c b/libavcodec/aac_ac3_parser.c
index 2f7d568..6a76eb8 100644
--- a/libavcodec/aac_ac3_parser.c
+++ b/libavcodec/aac_ac3_pa
This caused issues when seeking in some unusual MPEGTS files
---
libavcodec/aac_ac3_parser.c | 4
1 file changed, 4 insertions(+)
diff --git a/libavcodec/aac_ac3_parser.c b/libavcodec/aac_ac3_parser.c
index 2f7d568..6a76eb8 100644
--- a/libavcodec/aac_ac3_parser.c
+++ b/libavcodec/aac_ac3_pa
On Wed, Nov 25, 2015 at 06:36:03PM +0100, Michael Niedermayer wrote:
> On Wed, Nov 25, 2015 at 03:40:15PM +0100, Matthieu Bouron wrote:
> > From: Matthieu Bouron
> >
> > ---
> > tests/api/Makefile | 1 +
> > tests/api/api-codec-param-test.c| 223
> > ++
I tracked down the source of the confusion. The Chromium team has a repo
that sits between Chromium and the main ffmpeg repo. This repo is discussed
here:
https://chromium.googlesource.com/chromium/third_party/ffmpeg.git
The trouble is that this page shows README instead of README.chromium, so
it
On Wed, Nov 18, 2015 at 01:49:49PM -0500, ker...@gmail.com wrote:
> From: Rick Kern
>
> Enable with configure --enable-vtenc and encode using -codec:v vtenc_h264.
>
> Signed-off-by: Rick Kern
> ---
> MAINTAINERS|1 +
> configure | 14 +
> libavcodec/Makefile|
On Wed, Nov 18, 2015 at 01:49:51PM -0500, ker...@gmail.com wrote:
> From: Rick Kern
>
> Signed-off-by: Rick Kern
> ---
> libavcodec/vtenc.c | 308
> ++---
> 1 file changed, 154 insertions(+), 154 deletions(-)
it is not possible to push changes w
On Sat, Nov 21, 2015 at 10:17:51PM +0100, Clément Bœsch wrote:
> From: Clément Bœsch
>
> ---
> libavfilter/avf_showwaves.c | 2 +-
> libavfilter/vf_pullup.c | 2 +-
> libavfilter/vf_scale.c | 2 +-
> 3 files changed, 3 insertions(+), 3 deletions(-)
LGTM
also wont review the other 2, s
On Sun, Nov 22, 2015 at 12:05:50PM -0500, Ganesh Ajjanagadde wrote:
> Signed-off-by: Ganesh Ajjanagadde
> ---
> libavfilter/vsrc_mptestsrc.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
should be ok
thx
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FA
On Wed, Nov 25, 2015 at 03:40:15PM +0100, Matthieu Bouron wrote:
> From: Matthieu Bouron
>
> ---
> tests/api/Makefile | 1 +
> tests/api/api-codec-param-test.c| 223
>
> tests/fate/api.mak | 8 ++
> tests/ref/fate/ap
On 11/25/15, Moritz Barsnick wrote:
> On Wed, Nov 25, 2015 at 09:48:36 +0100, Paul B Mahol wrote:
>> Patch attached.
>
>> +For example, you have recorded guitar with two microphones placed in
>> +different location. Because the front of sound wave has fixed speed in
>> +normal conditions, the phas
On Wed, Nov 25, 2015 at 9:50 AM, Moritz Barsnick wrote:
> On Wed, Nov 25, 2015 at 09:48:36 +0100, Paul B Mahol wrote:
>> Patch attached.
>
>> +For example, you have recorded guitar with two microphones placed in
>> +different location. Because the front of sound wave has fixed speed in
>> +normal
Hi,
On Wed, Nov 25, 2015 at 8:00 AM, Ganesh Ajjanagadde
wrote:
> pow2 is being used for trivial squaring. Its name is not good: is this
> 2^x or x^2?
2^x is exp2, not pow2. (I have no opinion on the patch itself.)
Ronald
___
ffmpeg-devel mailing lis
On November 24, 2015 at 6:06:36 PM, Michael Niedermayer (michae...@gmx.at)
wrote:
On Tue, Nov 24, 2015 at 03:01:28PM -0500, Alex Agranovsky wrote:
[...]
> From 2c253d7978a6c9c2dc701d393eb5b9d68e831c98 Mon Sep 17 00:00:00 2001
> From: Alex Agranovsky
> Date: Tue, 24 Nov 2015 00:07:34 -0500
Patch attached.
From db6a900bbe6a20afc44d3bc7b5416a2093d0c95f Mon Sep 17 00:00:00 2001
From: Paul B Mahol
Date: Wed, 25 Nov 2015 11:36:45 +0100
Subject: [PATCH] avfilter: add audio compressor filter
Signed-off-by: Paul B Mahol
---
doc/filters.texi | 72 +
liba
On Wed, Nov 25, 2015 at 09:48:36 +0100, Paul B Mahol wrote:
> Patch attached.
> +For example, you have recorded guitar with two microphones placed in
> +different location. Because the front of sound wave has fixed speed in
> +normal conditions, the phasing of microphones can vary and depends on
>
From: Matthieu Bouron
---
tests/api/Makefile | 1 +
tests/api/api-codec-param-test.c| 223
tests/fate/api.mak | 8 ++
tests/ref/fate/api-jpeg-codec-param | 12 ++
tests/ref/fate/api-png-codec-param | 12 ++
5 files
On 11/25/2015 12:05 AM, Bruce Dawson wrote:
> This would make ffmpeg fail on VS versions prior to VS 2013, for those
> using the BUILD.gn file, which I assume is not many. It would be easy to
> add additional conditionals for earlier versions, but if it's just for
> Chromium then 2013/2015 is suffi
pow2 is being used for trivial squaring. Its name is not good: is this
2^x or x^2? In any case, using x * x is IMHO more readable in this
context.
Signed-off-by: Ganesh Ajjanagadde
---
libavfilter/af_dynaudnorm.c | 13 -
1 file changed, 4 insertions(+), 9 deletions(-)
diff --git a/l
On Tue, Nov 24, 2015 at 10:13:22PM -0500, Ganesh Ajjanagadde wrote:
> This is a trivial rewrite of the loops that results in better
> prefetching and associated cache efficiency. Essentially, the problem is
> that modern prefetching logic is based on finite state Markov memory, a
> reasonable
> as
On Wed, Nov 25, 2015 at 1:38 AM, Bruce Dawson wrote:
> Yes - the modifications to BUILD.gn seem to all be done by Google/Chromium
> engineers.
>
> When Chromium pulls in a third party dependency they sometimes but the
> build files just outside of the copy of the third party repo, and this time
>
When creating a fresh working copy I noticed that the
"doc/examples/pc-uninstalled" folder which is created by ./configure is
not cleaned up when running "make distclean".
Attached patch adds the removal of "doc/examples/pc-uninstalled" folder
to "make distclean".
Regards,
Tobias
>From 166a9
On Sat, Nov 21, 2015 at 10:17:50PM +0100, Clément Bœsch wrote:
> From: Clément Bœsch
>
> ---
> libavcodec/ac3dec_fixed.c | 2 +-
> libavcodec/ac3dec_float.c | 2 +-
> libavcodec/ac3enc_opts_template.c | 4 ++--
> libavcodec/alac.c | 2 +-
> libavcodec/cinepake
On 11/25/15, Ganesh Ajjanagadde wrote:
> This removes wasteful pow(x, 2.0) that although not terribly important
> for speed, is still useless.
>
> Signed-off-by: Ganesh Ajjanagadde
> --
> Observed while auditing the codeb
On 11/25/15, Ganesh Ajjanagadde wrote:
> Gain computation for various curves was being done in a needlessly
> inaccurate fashion. Of course these are all subjective curves, but when
> a curve is advertised to the user, it should be matched as closely as
> possible within the limitations of libm. I
Patch attached.
From bda6d56599de5b0e1359d3244222e31ff6790007 Mon Sep 17 00:00:00 2001
From: Paul B Mahol
Date: Tue, 24 Nov 2015 11:14:36 +0100
Subject: [PATCH] avfilter: add compensation delay line filter
Signed-off-by: Paul B Mahol
---
doc/filters.texi | 42
libavf
59 matches
Mail list logo
