On Fri, May 22, 2015 at 11:59:54PM +0200, Michael Niedermayer wrote:
> this increases mpeg4 and msmpeg4v3 decoding speed by about 0.3-0.5% overall
>
> This reverts the merges of 848e86f74d3e6e87fa592ee8ba8c184cc5fd9a42 and
> 9c1db92ad372d4cd69e0490e691c56e4097cb193
>
> Speed tested with decoding
Based on commit 4ae15605f6298d8369a1f1374596b52a3839c703
Signed-off-by: James Almer
---
libavcodec/libdcadec.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/libavcodec/libdcadec.c b/libavcodec/libdcadec.c
index 9ea61fa..890d270 100644
--- a/libavcodec/libdcadec.c
+++ b/
also store 1 for D10
Signed-off-by: Michael Niedermayer
---
libavformat/mxfenc.c| 11 +++
tests/ref/lavf/mxf |6 +++---
tests/ref/lavf/mxf_d10 |2 +-
tests/ref/lavf/mxf_opatom |2 +-
tests/ref/lavf/mxf_opatom_audio |2 +-
5 files
On Sun, May 24, 2015 at 12:04:54AM +0200, Andreas Cadhalpun wrote:
> If avio_read fails, the buffer can contain uninitialized data.
>
> This fixes 'Conditional jump or move depends on uninitialised value(s)'
> valgrind warnings.
should be ok
thanks
[...]
--
Michael GnuPG fingerprint: 9FF21
On Sun, May 24, 2015 at 12:04:39AM +0200, Andreas Cadhalpun wrote:
> Signed-off-by: Andreas Cadhalpun
> ---
> libavformat/mov.c | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
LGTM
thanks
[...]
--
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
If you think
On Sun, May 24, 2015 at 12:04:23AM +0200, Andreas Cadhalpun wrote:
> Without this the mov demuxer can return a large number of empty packets.
>
> Signed-off-by: Andreas Cadhalpun
> ---
> libavformat/mov.c | 5 +
> 1 file changed, 5 insertions(+)
>
> diff --git a/libavformat/mov.c b/libavfor
On Sun, May 24, 2015 at 12:04:08AM +0200, Andreas Cadhalpun wrote:
> Otherwise the loop can take a lot of time if num_descr is very large.
>
> Signed-off-by: Andreas Cadhalpun
> ---
> libavformat/mov_chan.c | 5 +
> 1 file changed, 5 insertions(+)
LGTM
thx
[...]
--
Michael GnuPG fin
If avio_read fails, the buffer can contain uninitialized data.
This fixes 'Conditional jump or move depends on uninitialised value(s)'
valgrind warnings.
Signed-off-by: Andreas Cadhalpun
---
libavformat/mov.c | 48
1 file changed, 36 insertions(+
Without this the mov demuxer can return a large number of empty packets.
Signed-off-by: Andreas Cadhalpun
---
libavformat/mov.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/libavformat/mov.c b/libavformat/mov.c
index f6f07be..a6290d1 100644
--- a/libavformat/mov.c
+++ b/libavformat/m
Signed-off-by: Andreas Cadhalpun
---
libavformat/mov.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/libavformat/mov.c b/libavformat/mov.c
index a6290d1..0692e02 100644
--- a/libavformat/mov.c
+++ b/libavformat/mov.c
@@ -2175,10 +2175,11 @@ static int mov_read_stsz(MOVCon
Otherwise the loop can take a lot of time if num_descr is very large.
Signed-off-by: Andreas Cadhalpun
---
libavformat/mov_chan.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/libavformat/mov_chan.c b/libavformat/mov_chan.c
index e36034e..a2fa8d6 100644
--- a/libavformat/mov_chan.c
++
On 5/23/15, Mike Swanson wrote:
> Per the message I get from ffmpeg/ffplay (likewise video players like
> mpv that depend on ffmpeg), I get the following message on every frame
> of an APNG file that I constructed:
> [apng @ 0x7f85c800a460] Blending with pixel format rgb24 is not
> implemented. Up
Hello,
In attach, a first draft, for a patch in order to have a correct timecode
when segment files
(before this patch, the timecode is reset for each segment).
This is not a ready to apply patch.
One problem, is to get the real rate of the file, in order to correctly
increment timecode (i set 2
On Fri, 22 May 2015 22:52:24 +0530
Niklesh Lalwani wrote:
> From: Niklesh
>
> Using char** for style_start and style_end, and using uint8_t** for
> style_entries. This seems to be the least messy way. Signed-off-by:
> Niklesh ---
> libavcodec/movtextdec.c | 29 +
>
On Sat, 23 May 2015 19:33:15 +0200
Michael Niedermayer wrote:
> On Sat, May 23, 2015 at 06:16:49PM +0200, wm4 wrote:
> > On Fri, 22 May 2015 23:59:54 +0200
> > Michael Niedermayer wrote:
> >
> > > this increases mpeg4 and msmpeg4v3 decoding speed by about 0.3-0.5%
> > > overall
> >
> > Nobody
On 23/05/15 2:42 PM, Michael Niedermayer wrote:
> On Sat, May 23, 2015 at 02:26:01PM -0300, James Almer wrote:
>> Signed-off-by: James Almer
>> ---
>> libavcodec/libwebpenc.c | 5 -
>> libavcodec/libwebpenc_animencoder.c | 11 +--
>> libavcodec/libwebpenc_common.c |
On Sat, May 23, 2015 at 02:26:01PM -0300, James Almer wrote:
> Signed-off-by: James Almer
> ---
> libavcodec/libwebpenc.c | 5 -
> libavcodec/libwebpenc_animencoder.c | 11 +--
> libavcodec/libwebpenc_common.c | 7 ---
> libavcodec/libwebpenc_common.h | 2
On Sat, May 23, 2015 at 06:16:49PM +0200, wm4 wrote:
> On Fri, 22 May 2015 23:59:54 +0200
> Michael Niedermayer wrote:
>
> > this increases mpeg4 and msmpeg4v3 decoding speed by about 0.3-0.5% overall
>
> Nobody cares. If it makes the code slightly cleaner, it's good. The
> code is terrible enou
Signed-off-by: James Almer
---
libavcodec/libwebpenc.c | 5 -
libavcodec/libwebpenc_animencoder.c | 11 +--
libavcodec/libwebpenc_common.c | 7 ---
libavcodec/libwebpenc_common.h | 2 --
4 files changed, 9 insertions(+), 16 deletions(-)
diff --git a/libav
On 23/05/15 7:42 AM, Michael Niedermayer wrote:
> On Sat, May 23, 2015 at 02:15:39AM -0300, James Almer wrote:
>> The libwebpmux pkg-config file already has an explicit dependecy on libwebp
>> >= 0.2.0.
>> Also remove the warning and silently disable the anim encoder when
>> libwebpmux is not new
Per the message I get from ffmpeg/ffplay (likewise video players like
mpv that depend on ffmpeg), I get the following message on every frame
of an APNG file that I constructed:
[apng @ 0x7f85c800a460] Blending with pixel format rgb24 is not
implemented. Update your FFmpeg version to the newest one
On Fri, 22 May 2015 23:59:54 +0200
Michael Niedermayer wrote:
> this increases mpeg4 and msmpeg4v3 decoding speed by about 0.3-0.5% overall
Nobody cares. If it makes the code slightly cleaner, it's good. The
code is terrible enough as it is.
___
ffmpeg
Michael Niedermayer gmx.at> writes:
> this increases mpeg4 and msmpeg4v3
> decoding speed by about 0.3-0.5% overall
Decreases?
Imo, this is enough to justify the revert.
Why did you merge originally / What is
the advantage of not reverting?
Carl Eugen
On 23.05.2015 17:18, Michael Niedermayer wrote:
> On Sat, May 23, 2015 at 03:14:58PM +0200, Andreas Cadhalpun wrote:
>> nutdec.c | 88
>> ---
>> 1 file changed, 62 insertions(+), 26 deletions(-)
>> 86ac74fde804529ef5cf923c4e3009997d493
On Sat, May 23, 2015 at 03:14:58PM +0200, Andreas Cadhalpun wrote:
> On 23.05.2015 14:05, Michael Niedermayer wrote:
> > On Sat, May 23, 2015 at 11:05:48AM +0200, Andreas Cadhalpun wrote:
> >> 4cc0440459f6b5e2223aaf2b667e3f222908714d
> >> 0001-nutdec-fix-various-memleaks-on-failure.patch
> >> Fro
On Sat, May 23, 2015 at 03:29:33PM +0200, wm4 wrote:
> On Sat, 23 May 2015 15:10:36 +0200
> Michael Niedermayer wrote:
>
> > The first frame is very often not valid, (it appears to be truncated)
> > the error message thus serves no purpose
> >
> > Found-by: rcombs
> > Signed-off-by: Michael Nied
On Sat, 23 May 2015 15:10:36 +0200
Michael Niedermayer wrote:
> The first frame is very often not valid, (it appears to be truncated)
> the error message thus serves no purpose
>
> Found-by: rcombs
> Signed-off-by: Michael Niedermayer
> ---
> libavcodec/dcadec.c |2 +-
> 1 file changed, 1
On 23.05.2015 14:05, Michael Niedermayer wrote:
> On Sat, May 23, 2015 at 11:05:48AM +0200, Andreas Cadhalpun wrote:
>> 4cc0440459f6b5e2223aaf2b667e3f222908714d
>> 0001-nutdec-fix-various-memleaks-on-failure.patch
>> From 60de9fa45698acd206dccfc6eb634a1e6a49889f Mon Sep 17 00:00:00 2001
>> From:
The first frame is very often not valid, (it appears to be truncated)
the error message thus serves no purpose
Found-by: rcombs
Signed-off-by: Michael Niedermayer
---
libavcodec/dcadec.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavcodec/dcadec.c b/libavcodec/dcade
On Sat, May 23, 2015 at 11:05:48AM +0200, Andreas Cadhalpun wrote:
> On 23.05.2015 10:52, Andreas Cadhalpun wrote:
> > On 23.05.2015 01:36, Michael Niedermayer wrote:
> >> On Fri, May 22, 2015 at 11:36:55PM +0200, Andreas Cadhalpun wrote:
> >> [...]
> >>> @@ -1095,10 +1121,14 @@ static int decode_f
On Sat, May 23, 2015 at 02:15:39AM -0300, James Almer wrote:
> The libwebpmux pkg-config file already has an explicit dependecy on libwebp
> >= 0.2.0.
> Also remove the warning and silently disable the anim encoder when libwebpmux
> is not new enough.
> This is more in line with other library com
On Sat, May 23, 2015 at 01:54:24AM -0300, James Almer wrote:
> On 23/05/15 12:34 AM, James Almer wrote:
> > On 22/05/15 10:43 PM, Michael Niedermayer wrote:
> >> applied
> >>
> >> i think the AVOption table and AVClass name could still be improved
> >> to match each encoder more individually, i don
On 23.05.2015 10:52, Andreas Cadhalpun wrote:
> On 23.05.2015 01:36, Michael Niedermayer wrote:
>> On Fri, May 22, 2015 at 11:36:55PM +0200, Andreas Cadhalpun wrote:
>> [...]
>>> @@ -1095,10 +1121,14 @@ static int decode_frame(NUTContext *nut, AVPacket
>>> *pkt, int frame_code)
>>> pkt->pos =
On 23.05.2015 01:36, Michael Niedermayer wrote:
> On Fri, May 22, 2015 at 11:36:55PM +0200, Andreas Cadhalpun wrote:
>> Signed-off-by: Andreas Cadhalpun
>> ---
>> libavformat/nutdec.c | 77
>> +---
>> 1 file changed, 55 insertions(+), 22 deletions(
On 23.05.2015 00:50, Michael Niedermayer wrote:
> On Fri, May 22, 2015 at 11:36:32PM +0200, Andreas Cadhalpun wrote:
>> If it fails, the buffers can be (partially) uninitialized.
>>
>> This fixes 'Conditional jump or move depends on uninitialised value(s)'
>> valgrind warnings.
>>
>> Signed-off-by:
On 23.05.2015 00:42, Michael Niedermayer wrote:
> On Fri, May 22, 2015 at 11:36:17PM +0200, Andreas Cadhalpun wrote:
>> If x is 2 it is not initialized before it is used.
>>
>> This fixes 'Conditional jump or move depends on uninitialised value(s)'
>> valgrind warnings.
>>
>> Signed-off-by: Andreas
36 matches
Mail list logo
