This instruction is deprecated on ARMv8, and it is serializing on
some ARMv7 cores as well [1].
http://article.gmane.org/gmane.linux.ports.arm.kernel/339293
---
libavcodec/arm/h264dsp_init_arm.c | 7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git
On 2014-07-08 10:58:10 +0300, Martin Storsjö wrote:
This instruction is deprecated on ARMv8, and it is serializing on
some ARMv7 cores as well [1].
http://article.gmane.org/gmane.linux.ports.arm.kernel/339293
---
libavcodec/arm/h264dsp_init_arm.c | 7 ++-
1 file changed, 6
This silences a warning with gcc.
---
libavformat/mov.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/libavformat/mov.c b/libavformat/mov.c
index 4a2d265..cc2dc87 100644
--- a/libavformat/mov.c
+++ b/libavformat/mov.c
@@ -213,7 +213,7 @@ static int
On Mon, 7 Jul 2014, James Almer wrote:
On 07/07/14 4:08 PM, Martin Storsjö wrote:
This silences a warning with gcc.
---
In my defense, clang didn't show this warning.
---
libavformat/mov.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavformat/mov.c
On Tue, Jul 08, 2014 at 12:07:02PM +0300, Martin Storsjö wrote:
This silences a warning with gcc.
---
libavformat/mov.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
Also OK.
Diego
___
libav-devel mailing list
libav-devel@libav.org
---
corrected identation and commit message
libavformat/audiointerleave.c | 8 +---
libavformat/internal.h| 2 +-
libavformat/mux.c | 18 +-
3 files changed, 19 insertions(+), 9 deletions(-)
diff --git a/libavformat/audiointerleave.c
The long story is finally coming to an end. Only three patches remain
until the behemoth is defeated. Rejoice.
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel
---
libavcodec/x86/dsputil_init.c | 2 +-
libavcodec/x86/dsputil_x86.h| 4 ++--
libavcodec/x86/dsputilenc_mmx.c | 4 ++--
libavcodec/x86/motion_est.c | 2 +-
4 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/libavcodec/x86/dsputil_init.c b/libavcodec/x86/dsputil_init.c
it does as advertised, OK by me
On 07/08/2014 02:39 PM, Diego Biurrun wrote:
---
libavcodec/x86/dsputil_init.c | 2 +-
libavcodec/x86/dsputil_x86.h| 4 ++--
libavcodec/x86/dsputilenc_mmx.c | 4 ++--
libavcodec/x86/motion_est.c | 2 +-
4 files changed, 6 insertions(+), 6
On 08/07/14 14:39, Diego Biurrun wrote:
---
Possibly ok.
lu
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel
---
Updated with a more straightforward ARM init structure.
configure | 13 +-
libavcodec/Makefile| 1 +
libavcodec/arm/Makefile| 2 +
libavcodec/arm/dsputil_armv6.S |
On Wed, Mar 26, 2014 at 04:41:27AM -0700, Diego Biurrun wrote:
---
libavcodec/dsputil.c | 10 --
libavcodec/dsputil.h | 1 -
libavcodec/utils.c | 13 -
3 files changed, 8 insertions(+), 16 deletions(-)
Patch dropped; I'll leave this untouched for now.
Diego
---
Some fixes in the x86 part...
configure | 13 +-
libavcodec/Makefile| 1 +
libavcodec/arm/Makefile| 2 +
libavcodec/arm/dsputil_armv6.S | 55
On Tue, Jul 08, 2014 at 05:39:53AM -0700, Diego Biurrun wrote:
[...]
Disregard this one, better patch coming up ..
Diego
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel
On 06/07/14 07:24, Andrew Kelley wrote:
This fixes a segmentation fault because request_frame in fifo.c assumes
that the call to ff_request_frame will populate fifo-root.next.
Before, it was possible for request_frame in af_compand to not do this,
resulting in a null pointer access. Now,
On Sat, 5 Jul 2014 22:24:43 -0700, Andrew Kelley superjo...@gmail.com wrote:
This fixes a segmentation fault because request_frame in fifo.c assumes
that the call to ff_request_frame will populate fifo-root.next.
Before, it was possible for request_frame in af_compand to not do this,
On Tue, 1 Jul 2014 01:23:45 -0400
Vittorio Giovara vittorio.giov...@gmail.com wrote:
Rather than using deprecated *J pixel formats, keep the full scale ones in
a separate list, and check for avctx-color_range before opening the encoder.
This slightly changes the format handshaking
From: Alexander V. Lukyanov lavv...@gmail.com
AVFormatContext-priv_data is not always a MpegTSContext, it can be
RTSPState when decoding a RTP stream. So it is necessary to pass
MpegTSContext pointer explicitly.
Within libav, the write_section_data function doesn't actually use
the MpegTSContext
On 08/07/14 22:37, Martin Storsjö wrote:
Within libav, the write_section_data function doesn't actually use
the MpegTSContext at all, so this doesn't change anything at the
moment (no memory was corrupted before), but it reduces the risk of
anybody trying to touch the MpegTSContext via
On Mon, Jul 7, 2014 at 8:56 AM, Luca Barbato lu_z...@gentoo.org wrote:
On 04/07/14 16:54, Luca Barbato wrote:
The specification requires at most 1 track enable per alternate group.
---
libavformat/movenc.c | 21 -
libavformat/movenc.h | 2 ++
2 files changed, 18
From: Andrew Kelley superjo...@gmail.com
Signed-off-by: Vittorio Giovara vittorio.giov...@gmail.com
---
Slightly different wording, is it still ok?
Vittorio
doc/platform.texi | 11 +++
1 file changed, 11 insertions(+)
diff --git a/doc/platform.texi b/doc/platform.texi
index
On 09/07/14 03:41, Vittorio Giovara wrote:
From: Andrew Kelley superjo...@gmail.com
Signed-off-by: Vittorio Giovara vittorio.giov...@gmail.com
---
Slightly different wording, is it still ok?
Vittorio
doc/platform.texi | 11 +++
1 file changed, 11 insertions(+)
diff --git
On Jul 8, 2014 6:42 PM, Vittorio Giovara vittorio.giov...@gmail.com
wrote:
From: Andrew Kelley superjo...@gmail.com
Signed-off-by: Vittorio Giovara vittorio.giov...@gmail.com
---
Slightly different wording, is it still ok?
Vittorio
doc/platform.texi | 11 +++
1 file changed, 11
23 matches
Mail list logo
