On Sat, Oct 31, 2015 at 10:15 AM, Ganesh Ajjanagadde wrote:
> On Fri, Oct 30, 2015 at 7:29 PM, Michael Niedermayer
> wrote:
>> On Fri, Oct 30, 2015 at 06:53:34PM -0400, Ganesh Ajjanagadde wrote:
>>> On Fri, Oct 30, 2015 at 6:35 PM, Michael Niedermayer
>>> wrote:
>>> > From: Michael Niedermayer
On Sun, Nov 01, 2015 at 07:29:36PM -0500, Ganesh Ajjanagadde wrote:
[...]
> I believe vf_palettegen and libavformat/subtitles are the only ones
> lacking review, but may be mistaken.
>
Those are probably fine.
--
Clément B.
signature.asc
Description: PGP signature
On Tue, Nov 3, 2015 at 5:06 AM, Muhammad Faiz wrote:
> On Sat, Oct 31, 2015 at 10:15 AM, Ganesh Ajjanagadde wrote:
>> On Fri, Oct 30, 2015 at 7:29 PM, Michael Niedermayer
>> wrote:
>>> On Fri, Oct 30, 2015 at 06:53:34PM -0400, Ganesh Ajjanagadde wrote:
On Fri, Oct 30, 2015 at 6:35 PM, Micha
On Tue, Nov 3, 2015 at 2:17 AM, Clément Bœsch wrote:
> On Mon, Nov 02, 2015 at 10:10:33PM -0500, Ganesh Ajjanagadde wrote:
>> On Mon, Nov 2, 2015 at 9:32 PM, Ganesh Ajjanagadde wrote:
>> > On Mon, Nov 2, 2015 at 6:49 PM, Ganesh Ajjanagadde
>> > wrote:
>> >> On Mon, Nov 2, 2015 at 6:37 PM, wm4
On Tue, Nov 3, 2015 at 12:45 AM, Timothy Gu wrote:
> On Mon, Nov 2, 2015 at 8:23 PM Rostislav Pehlivanov
> wrote:
>
>> >if one removes the crippling
>> >-fno-tree-vectorize
>> Yes, I think a config option to turn this flag on (like the unsafe
>> bitstream reader) would be good. Defaulting to off
On Tue, Nov 3, 2015 at 1:08 PM, Ganesh Ajjanagadde wrote:
> On Tue, Nov 3, 2015 at 2:17 AM, Clément Bœsch wrote:
>> On Mon, Nov 02, 2015 at 10:10:33PM -0500, Ganesh Ajjanagadde wrote:
>>> On Mon, Nov 2, 2015 at 9:32 PM, Ganesh Ajjanagadde wrote:
>>> > On Mon, Nov 2, 2015 at 6:49 PM, Ganesh Ajjan
On Tue, Nov 03, 2015 at 07:20:39AM -0500, Ganesh Ajjanagadde wrote:
[...]
> This is an opinion, so I will state mine here: if you are developing
> use ccache + GCC > ccache + clang > clang = gcc. Reason for the first
> is due to the terrible interaction ccache has with clang.
I'm curious; what are
On Tue, Nov 3, 2015 at 8:36 AM, Clément Bœsch wrote:
> On Tue, Nov 03, 2015 at 07:20:39AM -0500, Ganesh Ajjanagadde wrote:
> [...]
>> This is an opinion, so I will state mine here: if you are developing
>> use ccache + GCC > ccache + clang > clang = gcc. Reason for the first
>> is due to the terri
On Tue, Nov 3, 2015 at 8:16 AM, Hendrik Leppkes wrote:
> On Tue, Nov 3, 2015 at 1:08 PM, Ganesh Ajjanagadde wrote:
>> On Tue, Nov 3, 2015 at 2:17 AM, Clément Bœsch wrote:
>>> On Mon, Nov 02, 2015 at 10:10:33PM -0500, Ganesh Ajjanagadde wrote:
On Mon, Nov 2, 2015 at 9:32 PM, Ganesh Ajjanagad
On Sat, Oct 31, 2015 at 12:33:54AM +0100, Michael Niedermayer wrote:
> On Sat, Oct 31, 2015 at 12:14:44AM +0100, Hendrik Leppkes wrote:
> > On Fri, Oct 30, 2015 at 11:35 PM, Michael Niedermayer
> > wrote:
> > > From: Michael Niedermayer
> > >
> > > This should fix the build failure of avf_showcq
On Tue, Nov 03, 2015 at 08:41:33AM -0500, Ganesh Ajjanagadde wrote:
> On Tue, Nov 3, 2015 at 8:36 AM, Clément Bœsch wrote:
> > On Tue, Nov 03, 2015 at 07:20:39AM -0500, Ganesh Ajjanagadde wrote:
> > [...]
> >> This is an opinion, so I will state mine here: if you are developing
> >> use ccache + G
On Tue, Nov 03, 2015 at 02:42:55PM +0100, Clément Bœsch wrote:
[...]
> > > Wasn't there a concern that these emulations don't behave identical to
> > > the C library versions in regards to NaN handling?
> > > I faintly remember something in the previous discussion.
> >
> > yes, i forgot about that
On Tue, Nov 3, 2015 at 8:43 AM, Clément Bœsch wrote:
> On Tue, Nov 03, 2015 at 08:41:33AM -0500, Ganesh Ajjanagadde wrote:
>> On Tue, Nov 3, 2015 at 8:36 AM, Clément Bœsch wrote:
>> > On Tue, Nov 03, 2015 at 07:20:39AM -0500, Ganesh Ajjanagadde wrote:
>> > [...]
>> >> This is an opinion, so I wil
On Tue, Oct 27, 2015 at 9:38 PM, Ganesh Ajjanagadde
wrote:
> When sbr->reset is set in encode_frame, a bunch of qsort calls might get made.
> Thus, there is the potential of calling qsort whenever the spectral
> contents change.
>
> AV_QSORT is substantially faster due to the inlining of the compa
On Tue, Nov 3, 2015 at 5:42 AM, Clément Bœsch wrote:
> On Sat, Oct 31, 2015 at 12:33:54AM +0100, Michael Niedermayer wrote:
>> On Sat, Oct 31, 2015 at 12:14:44AM +0100, Hendrik Leppkes wrote:
>> > On Fri, Oct 30, 2015 at 11:35 PM, Michael Niedermayer
>> > wrote:
>> > > From: Michael Niedermayer
this makes draw_bar faster
slightly different result with old version
check result (with ~3 minutes audio file):
old:
real0m49.611s
user0m49.260s
sys 0m0.073s
new:
real0m47.606s
user0m47.378s
sys 0m0.068s
PSNR between old and new:
yuv444p PSNR
y:
On Tue, Nov 3, 2015 at 11:10 AM, Muhammad Faiz wrote:
> On Tue, Nov 3, 2015 at 5:42 AM, Clément Bœsch wrote:
>> On Sat, Oct 31, 2015 at 12:33:54AM +0100, Michael Niedermayer wrote:
>>> On Sat, Oct 31, 2015 at 12:14:44AM +0100, Hendrik Leppkes wrote:
>>> > On Fri, Oct 30, 2015 at 11:35 PM, Michael
On Tue, Nov 3, 2015 at 4:47 AM Ganesh Ajjanagadde > - GCC vectorization
slows down compilation A LOT in all versions. The newer
> > the worse.
>
> A ~ 20% slowdown on a build for a ~ 20% improvement in an overall FATE
> bench - sounds like a win to me especially with ccache.
Of course, but unfor
On 11/3/2015 4:44 AM, Clément Bœsch wrote:
> On Tue, Nov 03, 2015 at 04:09:43AM -0300, James Almer wrote:
>> Signed-off-by: James Almer
>> ---
>> libavutil/md5.c| 23 ++-
>> tests/ref/fate/md5 | 12 +++-
>> 2 files changed, 17 insertions(+), 18 deletions(-)
>>
>> d
On Tue, Nov 3, 2015 at 5:10 PM, Muhammad Faiz wrote:
> On Tue, Nov 3, 2015 at 5:42 AM, Clément Bœsch wrote:
>> On Sat, Oct 31, 2015 at 12:33:54AM +0100, Michael Niedermayer wrote:
>>> On Sat, Oct 31, 2015 at 12:14:44AM +0100, Hendrik Leppkes wrote:
>>> > On Fri, Oct 30, 2015 at 11:35 PM, Michael
On Tue, Nov 3, 2015 at 11:53 AM, Timothy Gu wrote:
> On Tue, Nov 3, 2015 at 4:47 AM Ganesh Ajjanagadde > - GCC vectorization
> slows down compilation A LOT in all versions. The newer
>
>> > the worse.
>>
>> A ~ 20% slowdown on a build for a ~ 20% improvement in an overall FATE
>> bench - sounds li
On Tue, Nov 3, 2015 at 3:47 AM, Ganesh Ajjanagadde wrote:
> On Tue, Nov 3, 2015 at 5:06 AM, Muhammad Faiz wrote:
>> On Sat, Oct 31, 2015 at 10:15 AM, Ganesh Ajjanagadde
>> wrote:
>>> On Fri, Oct 30, 2015 at 7:29 PM, Michael Niedermayer
>>> wrote:
On Fri, Oct 30, 2015 at 06:53:34PM -0400,
On Tue, Nov 3, 2015 at 9:21 AM, Hendrik Leppkes wrote:
> On Tue, Nov 3, 2015 at 5:10 PM, Muhammad Faiz wrote:
>> On Tue, Nov 3, 2015 at 5:42 AM, Clément Bœsch wrote:
>>> On Sat, Oct 31, 2015 at 12:33:54AM +0100, Michael Niedermayer wrote:
On Sat, Oct 31, 2015 at 12:14:44AM +0100, Hendrik Le
On Mon, Nov 02, 2015 at 11:45:05AM +0100, Matthieu Bouron wrote:
> From: Matthieu Bouron
>
> Codec supporting FF_CODEC_SKIP_FRAME_FILL must still extract and fill
> their parameters into AVCodecContext while honoring the skip_frame
> flag.
> ---
> libavcodec/internal.h | 5 +
> 1 file change
LGTM.
Tested the patch, doesn't change the output.
On 28 October 2015 at 01:38, Ganesh Ajjanagadde
wrote:
> When sbr->reset is set in encode_frame, a bunch of qsort calls might get
> made.
> Thus, there is the potential of calling qsort whenever the spectral
> contents change.
>
> AV_QSORT is su
On Mon, Nov 02, 2015 at 11:45:07AM +0100, Matthieu Bouron wrote:
> From: Matthieu Bouron
>
> ---
> libavcodec/mjpegdec.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
LGTM
thx
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
Breaking DRM is a litt
On Mon, Nov 02, 2015 at 11:45:08AM +0100, Matthieu Bouron wrote:
> From: Matthieu Bouron
>
> ---
> libavcodec/pngdec.c | 1 +
> 1 file changed, 1 insertion(+)
LGTM
thx
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
The misfortune of the wise is better than
On Tue, Nov 3, 2015 at 3:24 PM, Rostislav Pehlivanov
wrote:
> LGTM.
> Tested the patch, doesn't change the output.
I am personally fine with this, but was hoping for an opinion on
whether the perf increase here is important enough to justify the
binary size increase. Hence my ping to the AAC peop
On Tue, Nov 3, 2015 at 12:54 PM, Muhammad Faiz wrote:
> On Tue, Nov 3, 2015 at 3:47 AM, Ganesh Ajjanagadde wrote:
>> On Tue, Nov 3, 2015 at 5:06 AM, Muhammad Faiz wrote:
>>> On Sat, Oct 31, 2015 at 10:15 AM, Ganesh Ajjanagadde
>>> wrote:
On Fri, Oct 30, 2015 at 7:29 PM, Michael Niedermaye
On Sun, Nov 1, 2015 at 6:38 PM, Michael Niedermayer
wrote:
> On Sat, Oct 31, 2015 at 10:47:55AM -0400, Ganesh Ajjanagadde wrote:
>> There seems to be some typos in the log messages that are fixed by this.
>
> probably ok
Been 2 days and no objections, pushed.
Thanks.
>
> [...]
> --
> Michael
On Sun, Nov 1, 2015 at 5:54 PM, Michael Niedermayer
wrote:
> On Sun, Nov 01, 2015 at 12:19:47PM -0500, Ganesh Ajjanagadde wrote:
>> This is of use for defining comparator callbacks. Common approaches like
>> return x-y are not safe due to the risks of overflow.
>> Furthermore, the (x > y) - (x < y
On Tue, Nov 3, 2015 at 5:54 AM, Clément Bœsch wrote:
> On Sun, Nov 01, 2015 at 07:29:36PM -0500, Ganesh Ajjanagadde wrote:
> [...]
>> I believe vf_palettegen and libavformat/subtitles are the only ones
>> lacking review, but may be mistaken.
>>
>
> Those are probably fine.
Pushed, thanks.
>
> --
This improves accuracy for the bessel function at large arguments, and this in
turn
should improve the quality of the Kaiser window. It also improves the
performance of the bessel function and hence build_filter by ~ 20%.
Details are given below.
Algorithm: taken from the Boost project, who have
On Tue, Nov 3, 2015 at 4:49 PM, Ganesh Ajjanagadde
wrote:
> [...]
Same as v1, except with appropriate Boost license included inline and
commit message rework to include the perf numbers.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpe
On Tue, Nov 03, 2015 at 08:14:34AM -0800, Muhammad Faiz wrote:
> this makes draw_bar faster
> slightly different result with old version
>
> check result (with ~3 minutes audio file):
> old:
> real0m49.611s
> user0m49.260s
> sys 0m0.073s
> new:
> real0m47.606s
>
The binary increase is 16 kbytes per file * 2 (since it's a template for
the fixed and float decoders) = 32 kbytes. This is not very significant at
all, even for the most memory and storage-space constrained (with an MMU)
device. (not to mention that this is using the default compiler
optimizations
On Mon, Nov 02, 2015 at 10:20:39AM -0800, Bryan Huh wrote:
> Fixes an issue where an int64_t ffurl_seek return-value was being stored
> in an int (32-bit) "r" variable, leading to integer overflow when seeking
> into a large file (>2GB), and ultimately a "Failed to perform internal
> seek" error me
On Tue, Nov 3, 2015 at 1:20 PM, Ganesh Ajjanagadde wrote:
> On Tue, Nov 3, 2015 at 12:54 PM, Muhammad Faiz wrote:
>> On Tue, Nov 3, 2015 at 3:47 AM, Ganesh Ajjanagadde wrote:
>>> On Tue, Nov 3, 2015 at 5:06 AM, Muhammad Faiz wrote:
On Sat, Oct 31, 2015 at 10:15 AM, Ganesh Ajjanagadde
>>>
This speeds up build_filter by ~ 50%. This gain should be pretty
consistent across all architectures and platforms.
Essentially, this relies on a observation that the filters have some
even/odd symmetry that may be exploited during the construction of the
polyphase filter bank. In particular, phas
39 matches
Mail list logo
