Re: [libav-devel] [PATCH] mpegaudiodsp: aarch64: Adjust function prototype after 2caa93b813adc5dbb7771dfe615da826a2947d18

2016-11-09 Thread Diego Biurrun
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

Re: [libav-devel] [PATCH 1/2] crypto: Add encryption support

2016-11-09 Thread Luca Barbato
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

Re: [libav-devel] [PATCH 2/2] hlsenc: Add encryption support

2016-11-09 Thread Luca Barbato
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

[libav-devel] [PATCH 1/2 v3] matroskaenc: fix muxing AAC streams when using aac_adtstoasc bsf

2016-11-09 Thread James Almer
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

[libav-devel] [PATCH 2/2 v3] matroskaenc: write updated STREAMINFO metadata for FLAC streams if available

2016-11-09 Thread James Almer
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 ---

Re: [libav-devel] [PATCH 1/3] lavu: Add AVSphericalMapping type and frame side data

2016-11-09 Thread Diego Biurrun
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

Re: [libav-devel] [PATCH 1/2 v2] matroskaenc: fix muxing AAC streams when using aac_adtstoasc bsf

2016-11-09 Thread James Almer
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 >>

Re: [libav-devel] [PATCH 1/2 v2] matroskaenc: fix muxing AAC streams when using aac_adtstoasc bsf

2016-11-09 Thread Anton Khirnov
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

[libav-devel] [PATCH 2/3] aarch64: vp9mc: Use movrel macro with separate offset parameter

2016-11-09 Thread Martin Storsjö
--- 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 ---

[libav-devel] [PATCH 1/3] aarch64: Add an offset parameter to the movrel macro

2016-11-09 Thread Martin Storsjö
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

[libav-devel] [PATCH 3/3] aarch64: h264idct: Use the offset parameter to movrel

2016-11-09 Thread Martin Storsjö
--- 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 @@

Re: [libav-devel] [PATCHv3 2/3] aarch64: vp9: Add NEON optimizations of VP9 MC functions

2016-11-09 Thread Martin Storsjö
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

[libav-devel] [PATCH 1/3] libxvid: Require availability of mkstemp()

2016-11-09 Thread Diego Biurrun
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

[libav-devel] [PATCH 2/3] libxvid: Use proper context in av_log() calls

2016-11-09 Thread Diego Biurrun
--- 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

[libav-devel] [PATCH 3/3] libxvid: Check return value of write() call

2016-11-09 Thread Diego Biurrun
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

Re: [libav-devel] [PATCHv3 2/3] aarch64: vp9: Add NEON optimizations of VP9 MC functions

2016-11-09 Thread Martin Storsjö
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