On 3/7/15, Martin Vignali wrote:
> Hello,
>
> Exemple to create the crash :
> ffmpeg -i fileWithoutSound -filter astats -f null -
>
> A patch in attach avoid the crash by avoiding Zero division in print_stats.
>
> I test the patch on several files, and the crash doesn't appear anymore.
>
> Best re
L'octidi 18 ventôse, an CCXXIII, Martin Vignali a écrit :
> +if (!nb_samples || !s->nb_channels)
Half your test is completely useless, as s->nb_channels can not be zero.
Did you manage tu reproduce the issue it is supposed to fix?
Regards,
--
Nicolas George
signature.asc
Description: D
On 3/8/15, Nicolas George wrote:
> L'octidi 18 ventose, an CCXXIII, Martin Vignali a ecrit :
>> +if (!nb_samples || !s->nb_channels)
>
> Half your test is completely useless, as s->nb_channels can not be zero.
>
> Did you manage tu reproduce the issue it is supposed to fix?
Yes, it gives me f
L'octidi 18 ventôse, an CCXXIII, Paul B Mahol a écrit :
> Yes, it gives me floating exception. Looks like uninit() is called
> unconditionally.
Of course uninit() is called unconditionally. But it should not crash, and I
re-checked here and it does not crash indeed.
This change seems very wrong t
On 3/8/15, Nicolas George wrote:
> L'octidi 18 ventose, an CCXXIII, Paul B Mahol a ecrit :
>> Yes, it gives me floating exception. Looks like uninit() is called
>> unconditionally.
>
> Of course uninit() is called unconditionally. But it should not crash, and
> I
> re-checked here and it does not
The divide-by-zero in channel part is not executed, when there is no sound
(like with file i put in attach in m previous email)
because, nb_channels = 0 in this case, so the for loop is not executed.
2015-03-08 10:36 GMT+01:00 Nicolas George :
> L'octidi 18 ventôse, an CCXXIII, Paul B Mahol a écr
L'octidi 18 ventôse, an CCXXIII, Paul B Mahol a écrit :
> You mean for case when there are channels present but without any
> samples? For example nb_channels = 2 and nb_samples = 0?
Yes. Are you suggesting that when you reproduce the crash, it happens with
nb_channels == 0? If so, I would very mu
On 3/8/15, Nicolas George wrote:
> L'octidi 18 ventose, an CCXXIII, Paul B Mahol a ecrit :
>> You mean for case when there are channels present but without any
>> samples? For example nb_channels = 2 and nb_samples = 0?
>
> Yes. Are you suggesting that when you reproduce the crash, it happens with
L'octidi 18 ventôse, an CCXXIII, Paul B Mahol a écrit :
> With nb_channels = 0 and nb_samples = 0 and compiled with clang i get
> floating exception.
nb_channels is not possible. If you reach it, please investigate, or at
least give some details to allow people to investigate.
Hiding bugs is neve
L'octidi 18 ventôse, an CCXXIII, Clement Boesch a écrit :
> Try adding tags with no text maybe. You may also try ASS drawing mode, but
> FFmpeg probably doesn't do cray stuff about it.
I tried various combinations, including empty styles, drawing mode, Picture,
Comment, empty lines, missing comma,
On 3/8/15, Nicolas George wrote:
> L'octidi 18 ventose, an CCXXIII, Paul B Mahol a ecrit :
>> With nb_channels = 0 and nb_samples = 0 and compiled with clang i get
>> floating exception.
>
> nb_channels is not possible. If you reach it, please investigate, or at
> least give some details to allow
L'octidi 18 ventôse, an CCXXIII, Gilles Chanteperdrix a écrit :
> If I read ffmpeg current documentation here:
>
> http://www.ffmpeg.org/doxygen/2.5/group__lavc__core.html#ga828218dcb8874ab2c5af8d486c365421
>
> It seems that when a subtitle rect type is SUBTITLE_ASS (which is
> the case in the co
L'octidi 18 ventôse, an CCXXIII, Paul B Mahol a écrit :
> Well, nb_channels is for certain 0 here.
Well, I am not "here" and I would like to see, because I am responsible for
the code path that leads there.
So please give enough information to reproduce the bug. You already stated
it was with cla
In attach a sample file
I use this line to create the crash :
ffmpag -i path_to_file_in_attach -filter astats -f null -
2015-03-08 11:05 GMT+01:00 Nicolas George :
> L'octidi 18 ventôse, an CCXXIII, Paul B Mahol a écrit :
> > Well, nb_channels is for certain 0 here.
>
> Well, I am not "here" and
On 3/8/15, Martin Vignali wrote:
> In attach a sample file
>
> I use this line to create the crash :
> ffmpag -i path_to_file_in_attach -filter astats -f null -
I used this same command and sample provided by Martin.
>
> 2015-03-08 11:05 GMT+01:00 Nicolas George :
>
>> L'octidi 18 ventose, an CC
L'octidi 18 ventôse, an CCXXIII, Martin Vignali a écrit :
> In attach a sample file, who make a crash. (on mac os x with latest git
> version, and on windows with older version).
>
> i just make the test now, and s->nb_channels can be 0. (this is the case
> with the file in attach).
Ok, got it.
---
libavformat/dump.c | 29 +
1 file changed, 29 insertions(+)
diff --git a/libavformat/dump.c b/libavformat/dump.c
index 56b37ff..9801042 100644
--- a/libavformat/dump.c
+++ b/libavformat/dump.c
@@ -291,6 +291,31 @@ static void dump_stereo3d(void *ctx, AVPacketSideDa
On Sun, Mar 08, 2015 at 11:56:34AM +0100, Thomas Volkert wrote:
> ---
> libavformat/dump.c | 29 +
> 1 file changed, 29 insertions(+)
>
> diff --git a/libavformat/dump.c b/libavformat/dump.c
> index 56b37ff..9801042 100644
> --- a/libavformat/dump.c
> +++ b/libavformat
L'octidi 18 ventôse, an CCXXIII, Clement Boesch a écrit :
> Factorize it with ashowinfo instead of copying the code.
>
> You can add a public helper returning the string.
I strongly support the second option. All enums like that should have a
corresponding string <-> enum utility.
Actually, we m
So testing on Windows 8.1 the results seem identical
||shell||command
||stdin->_cnt > 0||WaitForSingleObject||
||=||=||===||===||
||cmd.exe || .\test.exe _cnt > 0" in
that location ?
2015-03-0
alright, that table didn't work out, just imagine this:
.\test.exe :
> So testing on Windows 8.1 the results seem identical
>
> ||shell||command
> ||stdin->_cnt > 0||WaitForSingleObject||
> ||=||=||===||===
On Sun, Mar 08, 2015 at 03:55:09AM -0300, Claudio Freire wrote:
> On Fri, Mar 6, 2015 at 2:19 PM, Michael Niedermayer wrote:
> >> So it seems the test doesn't set up the LD_LIBRARY_PATH correctly.
> >> That's fixable, I'll see about getting a patch for that when I
> >> understand the makefile layo
On 03/08/2015 12:03 PM, Nicolas George wrote:
L'octidi 18 ventôse, an CCXXIII, Clement Boesch a écrit :
Factorize it with ashowinfo instead of copying the code.
You can add a public helper returning the string.
I strongly support the second option. All enums like that should have a
correspondi
This prevents a memcpy if segmentation.update_map == false.
---
libavcodec/vp9.c | 72 ++--
1 file changed, 34 insertions(+), 38 deletions(-)
diff --git a/libavcodec/vp9.c b/libavcodec/vp9.c
index aff86d0..6f129f0 100644
--- a/libavcodec/vp9.c
+
I have gtx960 card and I'll try to push it forward but the resources are
really scarce. Any example of how to cope with HEVC libvdpau would be
welcome. The libvdpau source code is not providing any guide.
Cheers
On 6 March 2015 at 19:48, Hendrik Leppkes wrote:
> On Fri, Mar 6, 2015 at 7:58 PM, P
On Sat, Mar 07, 2015 at 11:47:08PM +0800, zhaoxiu.zeng wrote:
> From ab12e3081ba987c2e05d819be97cde96952f1c2a Mon Sep 17 00:00:00 2001
> From: Zeng Zhaoxiu
> Date: Sat, 7 Mar 2015 23:29:46 +0800
> Subject: [PATCH 1/1] avcodec/hevc_parser: use avpriv_find_start_code in
> hevc_split()
>
> Signed-o
On Sun, Mar 08, 2015 at 07:49:29AM -0400, Ronald S. Bultje wrote:
> This prevents a memcpy if segmentation.update_map == false.
> ---
> libavcodec/vp9.c | 72
> ++--
> 1 file changed, 34 insertions(+), 38 deletions(-)
applied
thanks
[...]
--
---
libavcodec/vp9.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/libavcodec/vp9.c b/libavcodec/vp9.c
index 6f129f0..77e98f5 100644
--- a/libavcodec/vp9.c
+++ b/libavcodec/vp9.c
@@ -301,6 +301,7 @@ static int vp9_ref_frame(AVCodecContext *ctx, VP9Frame
*dst, VP9Frame *src)
dst->segm
On Sun, Mar 08, 2015 at 09:21:42AM -0400, Ronald S. Bultje wrote:
> ---
> libavcodec/vp9.c | 1 +
> 1 file changed, 1 insertion(+)
applied
thanks
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
Into a blind darkness they enter who follow after the Ignorance,
On Sun, Mar 08, 2015 at 12:57:03AM +, Timothy Gu wrote:
> On Sat, Mar 7, 2015 at 2:29 PM Michael Niedermayer wrote:
>
> > Signed-off-by: Michael Niedermayer
> > ---
> > doc/filters.texi | 23 +++
> > 1 file changed, 23 insertions(+)
> >
> > diff --git a/doc/filters.tex
On Sun, Mar 08, 2015 at 12:09:32AM +0100, Reimar Döffinger wrote:
> Slightly (ca. 4%?) faster and smaller ff_h264_decode_mb_cavlc
> in my tests on a G4 7450.
>
> Signed-off-by: Reimar Döffinger
> ---
> libavutil/ppc/intreadwrite.h | 10 ++
> 1 file changed, 10 insertions(+)
this does no
---
libavcodec/hevc.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavcodec/hevc.c b/libavcodec/hevc.c
index fdbaa28..7c7f920 100644
--- a/libavcodec/hevc.c
+++ b/libavcodec/hevc.c
@@ -307,7 +307,7 @@ static int set_sps(HEVCContext *s, const HEVCSPS *sps)
*fmt++ = sps
Rainer Hochecker online.de> writes:
>
> ---
> libavcodec/hevc.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/libavcodec/hevc.c b/libavcodec/hevc.c
> index fdbaa28..7c7f920 100644
> --- a/libavcodec/hevc.c
> +++ b/libavcodec/hevc.c
> -307,7 +307,7 static in
Slightly (ca. 4%?) faster and smaller ff_h264_decode_mb_cavlc
in my tests on a G4 7450.
Signed-off-by: Reimar Döffinger
---
libavutil/ppc/intreadwrite.h | 10 ++
1 file changed, 10 insertions(+)
diff --git a/libavutil/ppc/intreadwrite.h b/libavutil/ppc/intreadwrite.h
index 7671676..65b3
On Sun, Mar 08, 2015 at 05:12:50PM +0100, Rainer Hochecker wrote:
> ---
> libavcodec/hevc.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/libavcodec/hevc.c b/libavcodec/hevc.c
> index fdbaa28..7c7f920 100644
> --- a/libavcodec/hevc.c
> +++ b/libavcodec/hevc.c
> @@ -307,
On 08/03/15 1:16 PM, Reimar Döffinger wrote:
> Slightly (ca. 4%?) faster and smaller ff_h264_decode_mb_cavlc
> in my tests on a G4 7450.
>
> Signed-off-by: Reimar Döffinger
> ---
> libavutil/ppc/intreadwrite.h | 10 ++
> 1 file changed, 10 insertions(+)
>
> diff --git a/libavutil/ppc/in
On Sun, Mar 08, 2015 at 01:21:20PM -0300, James Almer wrote:
> On 08/03/15 1:16 PM, Reimar Döffinger wrote:
> > Slightly (ca. 4%?) faster and smaller ff_h264_decode_mb_cavlc
> > in my tests on a G4 7450.
> >
> > Signed-off-by: Reimar Döffinger
> > ---
> > libavutil/ppc/intreadwrite.h | 10 ++
On 08/03/15 1:25 PM, Reimar Döffinger wrote:
> On Sun, Mar 08, 2015 at 01:21:20PM -0300, James Almer wrote:
>> On 08/03/15 1:16 PM, Reimar Döffinger wrote:
>>> Slightly (ca. 4%?) faster and smaller ff_h264_decode_mb_cavlc
>>> in my tests on a G4 7450.
>>>
>>> Signed-off-by: Reimar Döffinger
>>> --
Reimar Döffinger gmx.de> writes:
>
> I sent an alternative patch "pthread: Fix ff_thread_get_format issues
> when called outside frame decode."
right, I didn't see you patch not the other code path.
> However there are additional bugs like update_context calling this and thus
> a single SPS c
On 08.03.2015, at 18:08, Rainer Hochecker wrote:
> Reimar Döffinger gmx.de> writes:
>> I sent an alternative patch "pthread: Fix ff_thread_get_format issues
>> when called outside frame decode."
>
> right, I didn't see you patch not the other code path.
>
>> However there are additional bugs li
Reimar Döffinger gmx.de> writes:
I tried this patch with Kodi but did not get very far.
int ff_thread_can_start_frame(AVCodecContext *avctx)
{
PerThreadContext *p = avctx->internal->thread_ctx;
if (avctx->active_thread_type&FF_THREAD_FRAME)
return 0;
av_assert0(!p->main_threa
On Sun, Mar 08, 2015 at 05:16:43PM +0100, Reimar Döffinger wrote:
> Slightly (ca. 4%?) faster and smaller ff_h264_decode_mb_cavlc
> in my tests on a G4 7450.
>
> Signed-off-by: Reimar Döffinger
breaks build:
CC libavcodec/aliaspixdec.o
libavcodec/aliaspixdec.c: In function ‘decode_frame’:
l
On 08.03.2015, at 19:15, Rainer Hochecker wrote:
> Reimar Döffinger gmx.de> writes:
>
> I tried this patch with Kodi but did not get very far.
>
> int ff_thread_can_start_frame(AVCodecContext *avctx)
> {
>PerThreadContext *p = avctx->internal->thread_ctx;
>if (avctx->active_thread_type&
On 08.03.2015, at 19:34, Michael Niedermayer wrote:
> On Sun, Mar 08, 2015 at 05:16:43PM +0100, Reimar Döffinger wrote:
>> Slightly (ca. 4%?) faster and smaller ff_h264_decode_mb_cavlc
>> in my tests on a G4 7450.
>>
>> Signed-off-by: Reimar Döffinger
>
> breaks build:
> CC libavcodec/alia
Hi,
my name is Stephan Holljes, my IRC nick is klaxa.
I want to work on implementing servers for network protocols within the
GSoC project.
I've been using ffmpeg for many years already and I always wanted to
contribute in a way other than providing end-user support, but I never
really found the
On Sun, Mar 08, 2015 at 07:43:29PM +0100, Reimar Döffinger wrote:
> On 08.03.2015, at 19:34, Michael Niedermayer wrote:
> > On Sun, Mar 08, 2015 at 05:16:43PM +0100, Reimar Döffinger wrote:
> >> Slightly (ca. 4%?) faster and smaller ff_h264_decode_mb_cavlc
> >> in my tests on a G4 7450.
> >>
> >>
On 07/03/15 6:34 AM, Michael Niedermayer wrote:
> On Sat, Mar 07, 2015 at 02:24:24AM -0300, James Almer wrote:
>> Regression test for the bug from trac ticket #4359 fixed in commit efff3854
>>
>> Signed-off-by: James Almer
>> ---
>
>> The file was uploaded to the ftp (Incoming folder). It should
On Sun, Mar 08, 2015 at 08:44:50PM +0100, Michael Niedermayer wrote:
> On Sun, Mar 08, 2015 at 07:43:29PM +0100, Reimar Döffinger wrote:
> > On 08.03.2015, at 19:34, Michael Niedermayer wrote:
> > > On Sun, Mar 08, 2015 at 05:16:43PM +0100, Reimar Döffinger wrote:
> > >> Slightly (ca. 4%?) faster
On Sat, Mar 07, 2015 at 07:39:24PM +0100, Andreas Cadhalpun wrote:
> Hi,
>
> I missed some occurrences of 'allow to' in my previous patch.
>
> Best regards,
> Andreas
> faq.texi |2 +-
> ffserver.texi |2 +-
> filters.texi |2 +-
> formats.texi |4 ++--
> indevs.texi |
On Sat, Mar 07, 2015 at 11:44:10PM +0800, zhaoxiu.zeng wrote:
> From 47c997fa0623ab94a7a93b2d2e4cc4fa64c85d5f Mon Sep 17 00:00:00 2001
> From: Zeng Zhaoxiu
> Date: Sat, 7 Mar 2015 23:26:42 +0800
> Subject: [PATCH 1/1] avcodec/wmalossless: use av_clip_intp2
this breaks build on ARM
ffmpeg/libavut
On Sun, Mar 08, 2015 at 09:59:21PM +0100, Reimar Döffinger wrote:
> On Sun, Mar 08, 2015 at 08:44:50PM +0100, Michael Niedermayer wrote:
> > On Sun, Mar 08, 2015 at 07:43:29PM +0100, Reimar Döffinger wrote:
> > > On 08.03.2015, at 19:34, Michael Niedermayer wrote:
> > > > On Sun, Mar 08, 2015 at 0
Reimar Döffinger gmx.de> writes:
I have tested this with Kodi. Works with sw decoding. With DXVA it crashes,
looks like heap corruption or the like.
setting thread_safe_callbacks = 1 cures the issue but I get some green
frames at start of playback.
__
On Sun, Mar 08, 2015 at 10:37:53PM +0100, Michael Niedermayer wrote:
> On Sun, Mar 08, 2015 at 09:59:21PM +0100, Reimar Döffinger wrote:
> > On Sun, Mar 08, 2015 at 08:44:50PM +0100, Michael Niedermayer wrote:
> > > On Sun, Mar 08, 2015 at 07:43:29PM +0100, Reimar Döffinger wrote:
> > > > On 08.03.
Hi,
attached patch fixes 'Conditional jump or move depends on uninitialized
variables' valgrind warnings.
Best regards,
Andreas
>From 8b1088fa1509b1613d095fbe1c11eec6d251c95c Mon Sep 17 00:00:00 2001
From: Andreas Cadhalpun
Date: Sun, 8 Mar 2015 22:52:47 +0100
Subject: [PATCH 1/8] ffmdec: ini
Hi,
attached patch fixes potential crashes.
Best regards,
Andreas
>From 011296153f6e0e0112803474c41c4afa840a1e6d Mon Sep 17 00:00:00 2001
From: Andreas Cadhalpun
Date: Sun, 8 Mar 2015 23:07:25 +0100
Subject: [PATCH 2/8] ffmdec: check codec pointer before use
It is only set in the COMM case of
Hi,
attached patch fixes assertions in av_rescale_rnd.
Best regards,
Andreas
>From 8f647fe16693509056483c4d1bc4a57895e9de10 Mon Sep 17 00:00:00 2001
From: Andreas Cadhalpun
Date: Sun, 8 Mar 2015 23:12:59 +0100
Subject: [PATCH 3/8] ffmdec: make sure the time base is valid
A negative time base c
Hi,
attached patch fixes crashes with ffm files containing an extradata_size
setting, but without extradata.
Such files are created by the ffm muxer, e.g. with for the asv1 codec.
Best regards,
Andreas
>From b3da247975db1bc0dd86805f2830aa0b718fd355 Mon Sep 17 00:00:00 2001
From: Andreas Cadha
Hi,
some broken files can lead to an endless resync loop, which is avoided
by attached patch.
Best regards,
Andreas
>From 5682a0cafbaf9339352f3147ef7c494dea47 Mon Sep 17 00:00:00 2001
From: Andreas Cadhalpun
Date: Sun, 8 Mar 2015 23:29:42 +0100
Subject: [PATCH 5/8] ffmdec: break infinite
Hi,
if ffm files are shorter than expected, these loops never finish.
Attached patch fixes that.
Best regards,
Andreas
>From 697ac779497e26e27e6337205e37a371020add1e Mon Sep 17 00:00:00 2001
From: Andreas Cadhalpun
Date: Sun, 8 Mar 2015 23:31:48 +0100
Subject: [PATCH 6/8] ffmdec: fix infinite
Hi,
if AVERROR(EAGAIN) is returned from ffm_is_avail_data it always causes
an infinite EAGAIN loop.
Best regards,
Andreas
>From 115425287fe1f898baa79705f05d495c061e310a Mon Sep 17 00:00:00 2001
From: Andreas Cadhalpun
Date: Sun, 8 Mar 2015 23:34:29 +0100
Subject: [PATCH 7/8] ffmdec: don't ret
Hi,
I'm not sure what the purpose of this avio_seek was, but it can result
in an endless loop. Maybe it always does.
Best regards,
Andreas
>From e69589b1435b4d3e7a0a4de6158149f11a99a681 Mon Sep 17 00:00:00 2001
From: Andreas Cadhalpun
Date: Sun, 8 Mar 2015 23:39:23 +0100
Subject: [PATCH 8/8]
On Mon, Mar 09, 2015 at 12:02:55AM +0100, Andreas Cadhalpun wrote:
> Hi,
>
> attached patch fixes 'Conditional jump or move depends on
> uninitialized variables' valgrind warnings.
>
> Best regards,
> Andreas
> ffmdec.c |2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
> 4a297cdd7cdb82
On Sun, Mar 8, 2015 at 8:23 AM, Michael Niedermayer wrote:
> i think its better to leave fuzz at a small value otherwise we
> would forget to update the target when it improves and then
> subsequent worsenings could be missed
An updated version with that fixed.
It's a bit tricky to squash commit
On Sun, Mar 8, 2015 at 11:06 PM, Claudio Freire wrote:
> On Sun, Mar 8, 2015 at 8:23 AM, Michael Niedermayer wrote:
>> i think its better to leave fuzz at a small value otherwise we
>> would forget to update the target when it improves and then
>> subsequent worsenings could be missed
>
> An upda
On Mon, Mar 09, 2015 at 12:04:13AM +0100, Andreas Cadhalpun wrote:
> Hi,
>
> some broken files can lead to an endless resync loop, which is
> avoided by attached patch.
>
> Best regards,
> Andreas
> ffmdec.c | 10 +-
> 1 file changed, 9 insertions(+), 1 deletion(-)
> 048852d2d9b0c2515
On Mon, Mar 09, 2015 at 12:04:37AM +0100, Andreas Cadhalpun wrote:
> Hi,
>
> if ffm files are shorter than expected, these loops never finish.
> Attached patch fixes that.
>
> Best regards,
> Andreas
> ffmdec.c |4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
> 15281e8220cd5aef860
allowing access to the size but not the extradata itself is not useful
and could lead to potential problems if writing happens through this field
Signed-off-by: Michael Niedermayer
---
libavcodec/options_table.h |1 -
1 file changed, 1 deletion(-)
diff --git a/libavcodec/options_table.h b/l
On Mon, Mar 09, 2015 at 12:03:54AM +0100, Andreas Cadhalpun wrote:
> Hi,
>
> attached patch fixes crashes with ffm files containing an
> extradata_size setting, but without extradata.
>
> Such files are created by the ffm muxer, e.g. with for the asv1 codec.
>
> Best regards,
> Andreas
> ffmde
>> +{ "reconnect", "auto reconnect after disconnect before EOF",
>> OFFSET(reconnect), AV_OPT_TYPE_INT, { .i64 = 0 }, 0, 1, D },
>
> The default of this setting is probably worth a discussion.
The default value is not my concern,
So I make the default behavior remain unchanged.
May I have you
On Mon, Mar 09, 2015 at 12:05:31AM +0100, Andreas Cadhalpun wrote:
> Hi,
>
> I'm not sure what the purpose of this avio_seek was, but it can
> result in an endless loop. Maybe it always does.
ffm files can be written to and read at the same time, they can act
as ring buffers so that data is writt
>> +read_ret = http_buf_read(h, buf, size);
>> +if (s->reconnect && s->filesize > 0 && s->off < s->filesize &&
>> read_ret < 0) {
>>
>
> minor: you can chek read_ret < 0 first, this condition usually will net be
> meet.
Fine, I'll fix.
>> +av_log(h, AV_LOG_WARNING, "Will reconnect
On Mon, Mar 09, 2015 at 12:05:01AM +0100, Andreas Cadhalpun wrote:
> Hi,
>
> if AVERROR(EAGAIN) is returned from ffm_is_avail_data it always
> causes an infinite EAGAIN loop.
it should only loop until more data is written into the ffm file
(this of course is not guranteed to ever happen)
[...]
On Mon, Mar 09, 2015 at 12:03:33AM +0100, Andreas Cadhalpun wrote:
> Hi,
>
> attached patch fixes assertions in av_rescale_rnd.
>
> Best regards,
> Andreas
> ffmdec.c | 11 +++
> 1 file changed, 11 insertions(+)
> 26bb6e42cc4cb5afc9ac83c27152edece8d62943
> 0003-ffmdec-make-sure-the-
On Sat, 7 Mar 2015 20:24:16 +0200
Ilinca Andrei wrote:
>Hello!
welcome!
>
>*Why directshow digital video capture ?*
>
>Simply because It sounds really interesting and entertaining.
> I have some experience using Matlab and Simulink for converting from
> time-domain to
On Sun, 8 Mar 2015 20:34:52 +0100
Stephan Holljes wrote:
> Hi,
>
welcome!
> my name is Stephan Holljes, my IRC nick is klaxa.
> I want to work on implementing servers for network protocols within
> the GSoC project.
>
> I've been using ffmpeg for many years already and I always wanted to
> co
I have attached the patch, changing the configuration file.
From 82e64037476a6e7dd914fb9bb6faefcf4de2de8d Mon Sep 17 00:00:00 2001
From: Arwa Arif
Date: Mon, 9 Mar 2015 09:05:35 +0530
Subject: [PATCH] Add dependencies to configure file for vf_fftfilt
---
configure |3 +++
1 file changed, 3 i
On Mon, Mar 09, 2015 at 12:03:11AM +0100, Andreas Cadhalpun wrote:
> Hi,
>
> attached patch fixes potential crashes.
>
> Best regards,
> Andreas
> ffmdec.c | 12 ++--
> 1 file changed, 6 insertions(+), 6 deletions(-)
> fa490a9bc11b6c8748f707fabf79d28de237ef30
> 0002-ffmdec-check-cod
On 08.03.2015, at 22:56, Rainer Hochecker wrote:
> Reimar Döffinger gmx.de> writes:
>
>
> I have tested this with Kodi. Works with sw decoding. With DXVA it crashes,
> looks like heap corruption or the like.
> setting thread_safe_callbacks = 1 cures the issue but I get some green
> frames at st
All,
x264 is the external library of FFmpeg. If I want to contribute to it, should
I contribute to VideoLan directly? Thanks.
Rong
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
Reimar Döffinger gmx.de> writes:
>
> Any reason to believe this patch causes it?
> Because I can't see how it would.
> Maybe it's just a bug with DXVA and multithreading in the HEVC code?
> Can you provide some more information like a stacktrace, possibly using a
tool like DrMemory?
I don't thi
80 matches
Mail list logo
