On 2/21/15, James Almer wrote:
> On 21/02/15 3:47 PM, Paul B Mahol wrote:
>> On 2/21/15, James Almer wrote:
>>> On 21/02/15 8:49 AM, Paul B Mahol wrote:
Have you measured performance drop before and after?
>>>
>>> filter_order 8 in decorrelate()
>>>
>>> Before
>>> 903 decicycles in scalarpro
Hi,
2015-02-22 13:13 GMT+01:00 Paul B Mahol :
> I'm more afraid of overhead that memset() does.
A single AVZERO128U (or whatever that is called) might do it.
wmalossless could use the same, but for both tak and it, I bet that's
mostly setup, ie quite less called.
--
Christophe
On Sun, Feb 22, 2015 at 07:59:55AM +0100, Gilles Chanteperdrix wrote:
> When a client behind a NAT issues a pause command, and stay paused for a
> long time, the router may stop the RTP/RTCP port redirection. Resend the
> hole punching packets after each PLAY command to cause the router to
> restar
On Wed, Feb 18, 2015 at 06:20:54PM -0800, Chris Kennedy wrote:
> More details attached, debug level and gdb backtrace. Hopefully this
> helps, and I will work on getting a file I can share showing the issue.
>
> Thanks
>
[...]
> ffmpeg -nostdin -nostats -analyzeduration 774552000 -threads 1 -i i
On 22/02/15 9:22 AM, Christophe Gisquet wrote:
> Hi,
>
> 2015-02-22 13:13 GMT+01:00 Paul B Mahol :
>> I'm more afraid of overhead that memset() does.
>
> A single AVZERO128U (or whatever that is called) might do it.
That's a good idea. Although there are no AV_ZEROU macros so we'll have to add
On 22/02/15 9:13 AM, Paul B Mahol wrote:
> On 2/21/15, James Almer wrote:
>> On 21/02/15 3:47 PM, Paul B Mahol wrote:
>>> On 2/21/15, James Almer wrote:
On 21/02/15 8:49 AM, Paul B Mahol wrote:
> Have you measured performance drop before and after?
filter_order 8 in decorrelate
On 21/02/15 9:18 AM, Paul B Mahol wrote:
> On 2/21/15, James Almer wrote:
>> It's already called by scalarproduct_int16 if required.
>>
>> Signed-off-by: James Almer
>> ---
>> libavcodec/takdec.c | 3 ---
>> 1 file changed, 3 deletions(-)
>>
>> diff --git a/libavcodec/takdec.c b/libavcodec/takde
On 21/02/15 9:32 AM, Paul B Mahol wrote:
> On 2/21/15, James Almer wrote:
>> Signed-off-by: James Almer
>> ---
>> At least this is what i interpreted 544 meant. This patch can be discarded
>> otherwise.
>>
>> libavcodec/takdec.c | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff
Hi,
using the a64multienc encoder currently results in a crash due to a
double free.
This seems to be broken since [1].
Attached patch fixes this.
Best regards,
Andreas
1:
https://git.videolan.org/?p=ffmpeg.git;a=commitdiff;h=13e9cc9ce0646ba8e31d837b5e6372ec80fa7a73
>From 78b5bdd67c72fbb316
Hi,
increasing the packet size without enlarging the packet buffer can't be
correct...
This seems to be broken since [1].
Best regards,
Andreas
1:
https://git.videolan.org/?p=ffmpeg.git;a=commitdiff;h=7340008f18dc7d1557efbf5a331c9452913f7f61
>From c1bc01a84654df6a0e9ec4ea62f95920bfb80e32 Mon
Hi,
this patch fixes another case of using uninitialized values.
Best regards,
Andreas
>From 469ebfec4f33b807d7e27abfc38d8f392481b792 Mon Sep 17 00:00:00 2001
From: Andreas Cadhalpun
Date: Sun, 22 Feb 2015 20:48:38 +0100
Subject: [PATCH 4/4] avcodec/a64multienc: fix use of uninitialized values
Hi,
without this patch valgrind complains loudly about 'Conditional jump or
move depends on uninitialised value(s)' in avpriv_do_elbg.
(This patch applies to libav after cherry-picking [1].)
Best regards,
Andreas
1:
https://git.videolan.org/?p=ffmpeg.git;a=commitdiff;h=e4c180c05ac9aed33c16
On 22.02.2015 23:23, Luca Barbato wrote:
On 22/02/15 21:56, Andreas Cadhalpun wrote:
using the a64multienc encoder currently results in a crash due to a
double free.
This seems to be broken since [1].
I would expect that an unref would be needed somewhere, do we have a
fate test for it?
The
Dear ffmpeg coderz,
I work for Laoviland Experience, a digital innovation start-up based in
Montpellier, France. We develop creative software for inspiration and
automation of graphical creations.(see our website www.laoviland.com for
additional info).
We are searching for specific technical
On 22 February 2015 at 23:08, Boris Jaulmes wrote:
> Dear ffmpeg coderz,
Yes the "coderz" got your email the first time. I am sure all the
ffmpeg rockstar devs will be emailing you soon.
Kieran
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http
On Sun, Feb 22, 2015 at 09:58:09PM +0100, Andreas Cadhalpun wrote:
> Hi,
>
> increasing the packet size without enlarging the packet buffer can't
> be correct...
> This seems to be broken since [1].
>
> Best regards,
> Andreas
>
> 1:
> https://git.videolan.org/?p=ffmpeg.git;a=commitdiff;h=73400
Hi!
I believe attached patch improves the fade documentation.
Please comment, Carl Eugen
diff --git a/doc/filters.texi b/doc/filters.texi
index 191b52f..d394aec 100644
--- a/doc/filters.texi
+++ b/doc/filters.texi
@@ -4503,7 +4503,8 @@ The number of seconds for which the fade effect has to
last.
On Sun, Feb 22, 2015 at 09:56:52PM +0100, Andreas Cadhalpun wrote:
> Hi,
>
> using the a64multienc encoder currently results in a crash due to a
> double free.
> This seems to be broken since [1].
>
> Attached patch fixes this.
>
> Best regards,
> Andreas
>
> 1:
> https://git.videolan.org/?p=f
On Sun, Feb 22, 2015 at 09:58:54PM +0100, Andreas Cadhalpun wrote:
> Hi,
>
> this patch fixes another case of using uninitialized values.
>
> Best regards,
> Andreas
> a64multienc.c | 10 +++---
> 1 file changed, 7 insertions(+), 3 deletions(-)
> 839c039050a554b3cee5fb98b0168c87632f4c90
On Sun, Feb 22, 2015 at 09:58:39PM +0100, Andreas Cadhalpun wrote:
> Hi,
>
> without this patch valgrind complains loudly about 'Conditional jump
> or move depends on uninitialised value(s)' in avpriv_do_elbg.
>
> (This patch applies to libav after cherry-picking [1].)
>
> Best regards,
> Andrea
Hi!
Attached patch fixes a crash with the following command line:
$ ffmpeg -loop 1 -i fate-suite/lena.pnm -vf format=yuva420p,fade -f null -
Please comment, Carl Eugen
diff --git a/libavfilter/vf_fade.c b/libavfilter/vf_fade.c
index 80ce75d..5d012af 100644
--- a/libavfilter/vf_fade.c
+++ b/libavf
21 matches
Mail list logo
