On Tue, Nov 08, 2016 at 06:10:51PM +0100, Diego Biurrun wrote:
> ---
> libavcodec/aarch64/mpegaudiodsp_init.c | 5 +++--
> 1 file changed, 3 insertions(+), 2 deletions(-)
OKed by Luca on IRC.
Diego
___
libav-devel mailing list
libav-devel@libav.org
On 07/11/2016 09:34, Diego Biurrun wrote:
> Indentation is off.
Locally fixed, I'll push the set tomorrow.
lu
___
libav-devel mailing list
libav-devel@libav.org
https://lists.libav.org/mailman/listinfo/libav-devel
On 07/11/2016 09:29, Diego Biurrun wrote:
> Don't you leak hls->key_basename when returning errors here?
No, the error is propagated till the cleanup function is called.
___
libav-devel mailing list
libav-devel@libav.org
aac_adtstoasc makes the aac extradata available only after the first packet
is filtered, and as packet side data.
Assume extradata will be available as part of the first packet if
avpriv_mpeg4audio_get_config() fails the first time due to missing extradata
and reserve space for the
FLAC streams originating from the FLAC encoder send updated and more
complete STREAMINFO metadata as part of the last packet, so write that
to CodecPrivate instead of the incomplete one available in extradata
during init.
Signed-off-by: James Almer
---
On Mon, Nov 07, 2016 at 04:14:11PM -0500, Vittorio Giovara wrote:
> --- /dev/null
> +++ b/libavutil/spherical.h
> @@ -0,0 +1,99 @@
> +/**
> + * Projection of the video surface(s) on a sphere.
> + */
For these and similar doxygen comments I always wonder why they have to
span 3 lines and take up
On 11/9/2016 7:36 AM, Anton Khirnov wrote:
> Quoting James Almer (2016-11-02 21:02:30)
>> aac_adtstoasc makes the aac extradata available only after the first packet
>> is filtered, and as packet side data.
>>
>> Assume extradata will be available as part of the first packet if
>>
Quoting James Almer (2016-11-02 21:02:30)
> aac_adtstoasc makes the aac extradata available only after the first packet
> is filtered, and as packet side data.
>
> Assume extradata will be available as part of the first packet if
> avpriv_mpeg4audio_get_config() fails the first time due to
---
This goes on top of the latest version of the main aarch64 vp9 mc patch.
---
libavcodec/aarch64/vp9mc_neon.S | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/libavcodec/aarch64/vp9mc_neon.S b/libavcodec/aarch64/vp9mc_neon.S
index 6346878..720273b 100644
---
With apple tools, the linker fails with errors like these, if the
offset is negative:
ld: in section __TEXT,__text reloc 8: symbol index out of range for
architecture arm64
---
libavutil/aarch64/asm.S | 14 ++
1 file changed, 10 insertions(+), 4 deletions(-)
diff --git
---
libavcodec/aarch64/h264idct_neon.S | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavcodec/aarch64/h264idct_neon.S
b/libavcodec/aarch64/h264idct_neon.S
index ee23977..1c43c1f 100644
--- a/libavcodec/aarch64/h264idct_neon.S
+++ b/libavcodec/aarch64/h264idct_neon.S
@@
On Wed, 9 Nov 2016, Martin Storsjö wrote:
On Sat, 5 Nov 2016, Martin Storsjö wrote:
This work is sponsored by, and copyright, Google.
These are ported from the ARM version; it is essentially a 1:1
port with no extra added features, but with some hand tuning
(especially for the plain copy/avg
The replacement code uses tempnam(), which is dangerous.
Such a fringe feature is not worth the trouble.
---
This also fixes a loud warning complaining about insecure tempnam().
configure | 2 +-
libavcodec/Makefile | 3 +--
libavcodec/libxvid_rc.c | 17 ++---
3
---
libavcodec/libxvid_rc.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/libavcodec/libxvid_rc.c b/libavcodec/libxvid_rc.c
index 9130283..eddbbe8 100644
--- a/libavcodec/libxvid_rc.c
+++ b/libavcodec/libxvid_rc.c
@@ -68,7 +68,7 @@ av_cold int
libavcodec/libxvid_rc.c:106:9: warning: ignoring return value of ‘write’,
declared with attribute warn_unused_result [-Wunused-result]
---
libavcodec/libxvid_rc.c | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/libavcodec/libxvid_rc.c b/libavcodec/libxvid_rc.c
index
On Sat, 5 Nov 2016, Martin Storsjö wrote:
This work is sponsored by, and copyright, Google.
These are ported from the ARM version; it is essentially a 1:1
port with no extra added features, but with some hand tuning
(especially for the plain copy/avg functions). The ARM version
isn't very
16 matches
Mail list logo