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
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
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: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
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: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
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
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.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
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
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,
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,
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
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
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 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 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 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 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
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 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
21 matches
Mail list logo
