Re: [FFmpeg-devel] [PATCH 1/2] avfilter/all: propagate errors of functions from avfilter/formats

2015-10-06 Thread Nicolas George 
Le quartidi 14 vendémiaire, an CCXXIV, Ganesh Ajjanagadde a écrit :
> -ff_channel_layouts_ref(layouts, >out_channel_layouts);
> +if (!layouts)
> +return AVERROR(ENOMEM);
> +if ((ret = ff_channel_layouts_ref(layouts, 
> >out_channel_layouts)) < 0) {
> +ff_channel_layouts_unref();
> +return ret;

This is a pattern that comes frequently, there is probably room for code
factorization.

How about this: currently, ff_formats_ref() and cousins reject NULL with
AVERROR_BUG. If it is changed to return AVERROR(ENOMEM) instead, then all
the "if (!formats) return AVERROR(ENOMEM);" become unnecessary.

Second, if ff_formats_ref() is changed to unref the format list on failure,
then all the unref become unnecessary. The changed code would be just:

 layouts = ff_all_channel_counts();
-ff_channel_layouts_ref(layouts, >out_channel_layouts);
+if ((ret = ff_channel_layouts_ref(layouts, >out_channel_layouts)) 
< 0)
+return ret;

That is rather less cluttered.

What do you think about this?

Regards,

-- 
  Nicolas George


signature.asc
Description: Digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 1/2] avfilter/all: propagate errors of functions from avfilter/formats

2015-10-06 Thread Michael Niedermayer 
On Tue, Oct 06, 2015 at 04:40:36PM +0200, Nicolas George wrote:
> Le quartidi 14 vendémiaire, an CCXXIV, Ganesh Ajjanagadde a écrit :
> > -ff_channel_layouts_ref(layouts, >out_channel_layouts);
> > +if (!layouts)
> > +return AVERROR(ENOMEM);
> > +if ((ret = ff_channel_layouts_ref(layouts, 
> > >out_channel_layouts)) < 0) {
> > +ff_channel_layouts_unref();
> > +return ret;
> 
> This is a pattern that comes frequently, there is probably room for code
> factorization.
> 
> How about this: currently, ff_formats_ref() and cousins reject NULL with
> AVERROR_BUG. If it is changed to return AVERROR(ENOMEM) instead, then all
> the "if (!formats) return AVERROR(ENOMEM);" become unnecessary.
> 
> Second, if ff_formats_ref() is changed to unref the format list on failure,
> then all the unref become unnecessary. The changed code would be just:
> 
>  layouts = ff_all_channel_counts();
> -ff_channel_layouts_ref(layouts, >out_channel_layouts);
> +if ((ret = ff_channel_layouts_ref(layouts, 
> >out_channel_layouts)) < 0)
> +return ret;
> 
> That is rather less cluttered.

+1

[...]

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

The worst form of inequality is to try to make unequal things equal.
-- Aristotle


signature.asc
Description: Digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 1/2] avfilter/all: propagate errors of functions from avfilter/formats

2015-10-06 Thread Ronald S. Bultje 
Hi,

On Tue, Oct 6, 2015 at 9:25 AM, Nicolas George  wrote:

> Le quintidi 15 vendémiaire, an CCXXIV, Ronald S. Bultje a écrit :
> > >  // inlink supports any channel layout
> > >  layouts = ff_all_channel_counts();
> > > -ff_channel_layouts_ref(layouts, >out_channel_layouts);
> > > +if (!layouts)
> > > +return AVERROR(ENOMEM);
> > > +if ((ret = ff_channel_layouts_ref(layouts,
> > >out_channel_layouts)) < 0) {
> > > +ff_channel_layouts_unref();
> > > +return ret;
> > > +}
>
> > I already feel fully inadequate to review this patch :-D. But this looks
> > weird.
>
> What do you find weird in this change?


It seems to me that unref is the counterpart of ref. If ref fails, it
should behave as if it never occurred; compare not having to call free when
malloc fails, or not having to call avformat_close when avformat_open_input
fails. However, here, it seems we call unref if ref fails.

Why?

Is unref not the counterpart of ref?
Does ref not clean up after itself when it fails?
Something else?

Ronald
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] modify ffplay for dumpstream in rtsp?

2015-10-06 Thread compn 
On Sun, 4 Oct 2015 18:37:31 +0200
Nicolas George  wrote:

> Le duodi 12 vendémiaire, an CCXXIV, compn a écrit :
> > he wants to play and dump at the same time. like vlc can. 
> > 
> > should this functionality be added to ffmpeg or ffplay?
> 
> ffmpeg can already display video on the fly, with the opengl, xv and
> sdl devices.

maybe we could make an example in the docs specifying how to do this.

this works for me:

ffmpeg -i http://samples.ffmpeg.org/V-codecs/sn40sample.avi -i
http://samples.ffmpeg.org/V-codecs/sn40sample.avi -f sdl out.mp4 

is there a way to just use a single input to dump 1 file and display 1
sdl output? hmm, probably.

-compn
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] modify ffplay for dumpstream in rtsp?

2015-10-06 Thread compn 
On Tue, 6 Oct 2015 10:50:30 -0400
compn  wrote:

> On Sun, 4 Oct 2015 18:37:31 +0200
> Nicolas George  wrote:
> 
> > Le duodi 12 vendémiaire, an CCXXIV, compn a écrit :
> > > he wants to play and dump at the same time. like vlc can. 
> > > 
> > > should this functionality be added to ffmpeg or ffplay?
> > 
> > ffmpeg can already display video on the fly, with the opengl, xv and
> > sdl devices.
> 
> maybe we could make an example in the docs specifying how to do this.

oops, i see it in the bottom of xv outdev
https://ffmpeg.org/ffmpeg-devices.html#Examples-14

> 
> this works for me:
> 
> ffmpeg -i http://samples.ffmpeg.org/V-codecs/sn40sample.avi -i
> http://samples.ffmpeg.org/V-codecs/sn40sample.avi -f sdl out.mp4 
> 
> is there a way to just use a single input to dump 1 file and display 1
> sdl output? hmm, probably.

i didnt realize that "display" (as in -f sdl display) was an option i
needed to pass. its not listed anywhere else in the documentation or
options afaict. i thought it was referring to xv's "display_name"
subopt.

should i send a patch to add the "display" option to each outdev
documentation indicating this feature?

or maybe a nice wiki documentation like this:
https://trac.ffmpeg.org/wiki/Creating%20multiple%20outputs


-compn
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH] vp9: add x86 simd (sse2/ssse3) for iadst4 10bpp functions.

2015-10-06 Thread Ronald S. Bultje 
---
 libavcodec/x86/vp9dsp_init.h|   6 ++
 libavcodec/x86/vp9dsp_init_16bpp_template.c |  21 +-
 libavcodec/x86/vp9itxfm.asm |  58 
 libavcodec/x86/vp9itxfm_16bpp.asm   | 100 ++--
 libavcodec/x86/vp9itxfm_template.asm|  58 
 5 files changed, 161 insertions(+), 82 deletions(-)

diff --git a/libavcodec/x86/vp9dsp_init.h b/libavcodec/x86/vp9dsp_init.h
index 5d07b62..b3b0558 100644
--- a/libavcodec/x86/vp9dsp_init.h
+++ b/libavcodec/x86/vp9dsp_init.h
@@ -62,6 +62,12 @@ void cat(ff_vp9_##typea##_##typeb##_##size##x##size##_add_, 
bpp, _##opt)(uint8_t
  
int16_t *block, \
  int 
eob)
 
+#define decl_itxfm_funcs(size, bpp, opt) \
+decl_itxfm_func(idct,  idct,  size, bpp, opt); \
+decl_itxfm_func(iadst, idct,  size, bpp, opt); \
+decl_itxfm_func(idct,  iadst, size, bpp, opt); \
+decl_itxfm_func(iadst, iadst, size, bpp, opt)
+
 #define mc_rep_func(avg, sz, hsz, hszb, dir, opt, type, f_sz, bpp) \
 static av_always_inline void \
 ff_vp9_##avg##_8tap_1d_##dir##_##sz##_##bpp##_##opt(uint8_t *dst, ptrdiff_t 
dst_stride, \
diff --git a/libavcodec/x86/vp9dsp_init_16bpp_template.c 
b/libavcodec/x86/vp9dsp_init_16bpp_template.c
index 6e12af3..93fc684 100644
--- a/libavcodec/x86/vp9dsp_init_16bpp_template.c
+++ b/libavcodec/x86/vp9dsp_init_16bpp_template.c
@@ -126,8 +126,11 @@ decl_ipred_fns(tm, BPC, mmxext, sse2);
 
 decl_itxfm_func(iwht, iwht, 4, BPC, mmxext);
 #if BPC == 10
-decl_itxfm_func(idct, idct, 4, BPC, mmxext);
-decl_itxfm_func(idct, idct, 4, BPC, ssse3);
+decl_itxfm_func(idct,  idct,  4, BPC, mmxext);
+decl_itxfm_func(idct,  iadst, 4, BPC, sse2);
+decl_itxfm_func(iadst, idct,  4, BPC, sse2);
+decl_itxfm_func(iadst, iadst, 4, BPC, sse2);
+decl_itxfm_funcs(4, BPC, ssse3);
 #endif
 #endif /* HAVE_YASM */
 
@@ -169,6 +172,11 @@ av_cold void INIT_FUNC(VP9DSPContext *dsp, int bitexact)
 init_itx_func(idx, ADST_DCT,  typea, typeb, size, bpp, opt); \
 init_itx_func(idx, DCT_ADST,  typea, typeb, size, bpp, opt); \
 init_itx_func(idx, ADST_ADST, typea, typeb, size, bpp, opt)
+#define init_itx_funcs(idx, size, bpp, opt) \
+init_itx_func(idx, DCT_DCT,   idct,  idct,  size, bpp, opt); \
+init_itx_func(idx, ADST_DCT,  idct,  iadst, size, bpp, opt); \
+init_itx_func(idx, DCT_ADST,  iadst, idct,  size, bpp, opt); \
+init_itx_func(idx, ADST_ADST, iadst, iadst, size, bpp, opt); \
 
 if (EXTERNAL_MMXEXT(cpu_flags)) {
 init_ipred_func(tm, TM_VP8, 4, BPC, mmxext);
@@ -185,13 +193,20 @@ av_cold void INIT_FUNC(VP9DSPContext *dsp, int bitexact)
 init_subpel3(1, avg, BPC, sse2);
 init_lpf_funcs(BPC, sse2);
 init_8_16_32_ipred_funcs(tm, TM_VP8, BPC, sse2);
+#if BPC == 10
+if (!bitexact) {
+init_itx_func(TX_4X4, ADST_DCT,  idct,  iadst, 4, 10, sse2);
+init_itx_func(TX_4X4, DCT_ADST,  iadst, idct,  4, 10, sse2);
+init_itx_func(TX_4X4, ADST_ADST, iadst, iadst, 4, 10, sse2);
+}
+#endif
 }
 
 if (EXTERNAL_SSSE3(cpu_flags)) {
 init_lpf_funcs(BPC, ssse3);
 #if BPC == 10
 if (!bitexact) {
-init_itx_func(TX_4X4, DCT_DCT, idct, idct, 4, 10, ssse3);
+init_itx_funcs(TX_4X4, 4, BPC, ssse3);
 }
 #endif
 }
diff --git a/libavcodec/x86/vp9itxfm.asm b/libavcodec/x86/vp9itxfm.asm
index 200f15e..a3e0f86 100644
--- a/libavcodec/x86/vp9itxfm.asm
+++ b/libavcodec/x86/vp9itxfm.asm
@@ -289,64 +289,6 @@ IDCT_4x4_FN ssse3
 ; void vp9_iadst_iadst_4x4_add_(uint8_t *dst, ptrdiff_t stride, int16_t 
*block, int eob);
 
;---
 
-%macro VP9_IADST4_1D 0
-movq2dq   xmm0, m0
-movq2dq   xmm1, m1
-movq2dq   xmm2, m2
-movq2dq   xmm3, m3
-%if cpuflag(ssse3)
-paddw   m3, m0
-%endif
-punpcklwd xmm0, xmm1
-punpcklwd xmm2, xmm3
-pmaddwd   xmm1, xmm0, [pw_5283_13377]
-pmaddwd   xmm4, xmm0, [pw_9929_13377]
-%if notcpuflag(ssse3)
-pmaddwd   xmm6, xmm0, [pw_13377_0]
-%endif
-pmaddwd   xmm0, [pw_15212_m13377]
-pmaddwd   xmm3, xmm2, [pw_15212_9929]
-%if notcpuflag(ssse3)
-pmaddwd   xmm7, xmm2, [pw_m13377_13377]
-%endif
-pmaddwd   xmm2, [pw_m5283_m15212]
-%if cpuflag(ssse3)
-psubw   m3, m2
-%else
-paddd xmm6, xmm7
-%endif
-paddd xmm0, xmm2
-paddd xmm3, xmm5
-paddd xmm2, xmm5
-%if notcpuflag(ssse3)
-paddd xmm6, xmm5
-%endif
-paddd xmm1, xmm3
-paddd xmm0, xmm3
-paddd xmm4, xmm2
-psrad xmm1, 14
-psrad xmm0, 14
-psrad xmm4, 14

Re: [FFmpeg-devel] modify ffplay for dumpstream in rtsp?

2015-10-06 Thread Moritz Barsnick 
On Tue, Oct 06, 2015 at 10:50:30 -0400, compn wrote:
> this works for me:
> 
> ffmpeg -i http://samples.ffmpeg.org/V-codecs/sn40sample.avi -i 
> http://samples.ffmpeg.org/V-codecs/sn40sample.avi -f sdl out.mp4 

But it ignores the second input file (what was that good for?)

> is there a way to just use a single input to dump 1 file and display 1
> sdl output? hmm, probably.

This isn't the ffmpeg-user list, but:
Sure, ffmpeg supports multiple outputs.

$ ffmpeg -i http://samples.ffmpeg.org/V-codecs/sn40sample.avi out.mp4 -f sdl bla

And I believe the restriction of ffmpeg (vs. ffplay) of not being able
to control the output, e.g. by skipping backwards or forwards, is quite
practical, as you don't want to do that while actually trying to dump
the same file. So ffmpeg remains the optimal solution for this, not an
ffplay hack, IMHO.

So, for the original "poster" [what do we call them on a mailing
list?]:

$ ffmpeg -i 
'rtsp://192.168.178.80:554/user=admin_password=PASSWORD_channel=1_stream=0.sdp?real_stream?tcp'
 -c copy dump.mkv -f sdl bla

Moritz
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH] vp9: add 10bpp simd (mmxext/ssse3) for idct_idct_4x4.

2015-10-06 Thread Ronald S. Bultje 
---
 libavcodec/x86/constants.c  |   2 +
 libavcodec/x86/constants.h  |   1 +
 libavcodec/x86/vp9dsp_init_16bpp_template.c |  12 
 libavcodec/x86/vp9itxfm.asm |  50 +-
 libavcodec/x86/vp9itxfm_16bpp.asm   | 100 
 libavcodec/x86/vp9itxfm_template.asm|  47 +
 6 files changed, 163 insertions(+), 49 deletions(-)

diff --git a/libavcodec/x86/constants.c b/libavcodec/x86/constants.c
index 3f3ee0f..0098e20 100644
--- a/libavcodec/x86/constants.c
+++ b/libavcodec/x86/constants.c
@@ -85,5 +85,7 @@ DECLARE_ALIGNED(32, const ymm_reg,  ff_pd_16)   = { 
0x00100010ULL, 0x000
 0x00100010ULL, 
0x00100010ULL };
 DECLARE_ALIGNED(32, const ymm_reg,  ff_pd_32)   = { 0x00200020ULL, 
0x00200020ULL,
 0x00200020ULL, 
0x00200020ULL };
+DECLARE_ALIGNED(32, const ymm_reg,  ff_pd_8192) = { 0x20002000ULL, 
0x20002000ULL,
+0x20002000ULL, 
0x20002000ULL };
 DECLARE_ALIGNED(32, const ymm_reg,  ff_pd_65535)= { 0xULL, 
0xULL,
 0xULL, 
0xULL };
diff --git a/libavcodec/x86/constants.h b/libavcodec/x86/constants.h
index ee8422e..f989755 100644
--- a/libavcodec/x86/constants.h
+++ b/libavcodec/x86/constants.h
@@ -65,6 +65,7 @@ extern const xmm_reg  ff_ps_neg;
 extern const ymm_reg  ff_pd_1;
 extern const ymm_reg  ff_pd_16;
 extern const ymm_reg  ff_pd_32;
+extern const ymm_reg  ff_pd_8192;
 extern const ymm_reg  ff_pd_65535;
 
 #endif /* AVCODEC_X86_CONSTANTS_H */
diff --git a/libavcodec/x86/vp9dsp_init_16bpp_template.c 
b/libavcodec/x86/vp9dsp_init_16bpp_template.c
index 7a56c3b..6e12af3 100644
--- a/libavcodec/x86/vp9dsp_init_16bpp_template.c
+++ b/libavcodec/x86/vp9dsp_init_16bpp_template.c
@@ -125,6 +125,10 @@ lpf_mix2_wrappers_set(BPC, avx);
 decl_ipred_fns(tm, BPC, mmxext, sse2);
 
 decl_itxfm_func(iwht, iwht, 4, BPC, mmxext);
+#if BPC == 10
+decl_itxfm_func(idct, idct, 4, BPC, mmxext);
+decl_itxfm_func(idct, idct, 4, BPC, ssse3);
+#endif
 #endif /* HAVE_YASM */
 
 av_cold void INIT_FUNC(VP9DSPContext *dsp, int bitexact)
@@ -170,6 +174,9 @@ av_cold void INIT_FUNC(VP9DSPContext *dsp, int bitexact)
 init_ipred_func(tm, TM_VP8, 4, BPC, mmxext);
 if (!bitexact) {
 init_itx_func_one(4 /* lossless */, iwht, iwht, 4, BPC, mmxext);
+#if BPC == 10
+init_itx_func(TX_4X4, DCT_DCT, idct, idct, 4, 10, mmxext);
+#endif
 }
 }
 
@@ -182,6 +189,11 @@ av_cold void INIT_FUNC(VP9DSPContext *dsp, int bitexact)
 
 if (EXTERNAL_SSSE3(cpu_flags)) {
 init_lpf_funcs(BPC, ssse3);
+#if BPC == 10
+if (!bitexact) {
+init_itx_func(TX_4X4, DCT_DCT, idct, idct, 4, 10, ssse3);
+}
+#endif
 }
 
 if (EXTERNAL_AVX(cpu_flags)) {
diff --git a/libavcodec/x86/vp9itxfm.asm b/libavcodec/x86/vp9itxfm.asm
index c564f27..200f15e 100644
--- a/libavcodec/x86/vp9itxfm.asm
+++ b/libavcodec/x86/vp9itxfm.asm
@@ -71,8 +71,6 @@ pw_13377x2: times 8 dw 13377*2
 pw_m13377_13377: times 4 dw -13377, 13377
 pw_13377_0: times 4 dw 13377, 0
 
-pd_8192: times 4 dd 8192
-
 cextern pw_8
 cextern pw_16
 cextern pw_32
@@ -80,38 +78,10 @@ cextern pw_512
 cextern pw_1024
 cextern pw_2048
 cextern pw_m1
+cextern pd_8192
 
 SECTION .text
 
-; (a*x + b*y + round) >> shift
-%macro VP9_MULSUB_2W_2X 5 ; dst1, dst2/src, round, coefs1, coefs2
-pmaddwdm%1, m%2, %4
-pmaddwdm%2,  %5
-paddd  m%1,  %3
-paddd  m%2,  %3
-psrad  m%1,  14
-psrad  m%2,  14
-%endmacro
-
-%macro VP9_MULSUB_2W_4X 7 ; dst1, dst2, coef1, coef2, rnd, tmp1/src, tmp2
-VP9_MULSUB_2W_2X%7,  %6,  %5, [pw_m%3_%4], [pw_%4_%3]
-VP9_MULSUB_2W_2X%1,  %2,  %5, [pw_m%3_%4], [pw_%4_%3]
-packssdw   m%1, m%7
-packssdw   m%2, m%6
-%endmacro
-
-%macro VP9_UNPACK_MULSUB_2W_4X 7-9 ; dst1, dst2, (src1, src2,) coef1, coef2, 
rnd, tmp1, tmp2
-%if %0 == 7
-punpckhwd  m%6, m%2, m%1
-punpcklwd  m%2, m%1
-VP9_MULSUB_2W_4X   %1, %2, %3, %4, %5, %6, %7
-%else
-punpckhwd  m%8, m%4, m%3
-punpcklwd  m%2, m%4, m%3
-VP9_MULSUB_2W_4X   %1, %2, %5, %6, %7, %8, %9
-%endif
-%endmacro
-
 %macro VP9_UNPACK_MULSUB_2D_4X 6 ; dst1 [src1], dst2 [src2], dst3, dst4, mul1, 
mul2
 punpckhwd  m%4, m%2, m%1
 punpcklwd  m%2, m%1
@@ -191,24 +161,6 @@ cglobal vp9_iwht_iwht_4x4_add, 3, 3, 0, dst, stride, 
block, eob
 ; void vp9_idct_idct_4x4_add_(uint8_t *dst, ptrdiff_t stride, int16_t 
*block, int eob);
 
;---
 
-%macro

Re: [FFmpeg-devel] [PATCH] add CONTRIBUTING.md

2015-10-06 Thread Stefano Sabatini 
On date Monday 2015-10-05 15:26:46 -0800, Lou Logan encoded:
> For the Github users to ignore.
> 
> Signed-off-by: Lou Logan 
> ---
>  CONTRIBUTING.md | 36 
>  1 file changed, 36 insertions(+)
>  create mode 100644 CONTRIBUTING.md
> 
> diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md
> new file mode 100644
> index 000..4bccf25
> --- /dev/null
> +++ b/CONTRIBUTING.md
> @@ -0,0 +1,36 @@
> +# Contributing to FFmpeg
> +
> +FFmpeg is a big project, but we like seeing patches from new contributors.
> +You can get started by reading the [Developer Documentation]
> +(https://ffmpeg.org/developer.html).
> +
> +## A note to Github users
> +
> +**FFmpeg development, including patch reviews, occurs on the ffmpeg-devel
> +mailing list, so most developers do not view Github pull requests.
> +Therefore, Github pull requests should be avoided because they will
> +likely be not be noticed.**

typo: likely not be noticed

[...]

I wonder if adding the contents to README.md is not a better choice

Note also since we're writing about github, that the README.md will
have a better visibility there, since it is shown on the project main
page:
https://github.com/FFmpeg/FFmpeg

-- 
FFmpeg = Fantastic and Fascinating Mysterious Perennial Ermetic Gigant
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH] doc/developer: use https instead of http

2015-10-06 Thread Ganesh Ajjanagadde 
Change to https for FFmpeg websites.

Signed-off-by: Ganesh Ajjanagadde 
---
 doc/developer.texi | 10 +-
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/doc/developer.texi b/doc/developer.texi
index 4d0fc9f..31952d8 100644
--- a/doc/developer.texi
+++ b/doc/developer.texi
@@ -28,7 +28,7 @@ this document.
 
 For more detailed legal information about the use of FFmpeg in
 external programs read the @file{LICENSE} file in the source tree and
-consult @url{http://ffmpeg.org/legal.html}.
+consult @url{https://ffmpeg.org/legal.html}.
 
 @section Contributing
 
@@ -436,7 +436,7 @@ Also please if you send several patches, send each patch as 
a separate mail,
 do not attach several unrelated patches to the same mail.
 
 Patches should be posted to the
-@uref{http://lists.ffmpeg.org/mailman/listinfo/ffmpeg-devel, ffmpeg-devel}
+@uref{https://lists.ffmpeg.org/mailman/listinfo/ffmpeg-devel, ffmpeg-devel}
 mailing list. Use @code{git send-email} when possible since it will properly
 send patches without requiring extra care. If you cannot, then send patches
 as base64-encoded attachments, so your patch is not trashed during
@@ -551,7 +551,7 @@ amounts of memory when fed damaged data.
 
 @item
 Did you test your decoder or demuxer against sample files?
-Samples may be obtained at @url{http://samples.ffmpeg.org}.
+Samples may be obtained at @url{https://samples.ffmpeg.org}.
 
 @item
 Does the patch not mix functional and cosmetic changes?
@@ -718,7 +718,7 @@ FFmpeg maintains a set of @strong{release branches}, which 
are the
 recommended deliverable for system integrators and distributors (such as
 Linux distributions, etc.). At regular times, a @strong{release
 manager} prepares, tests and publishes tarballs on the
-@url{http://ffmpeg.org} website.
+@url{https://ffmpeg.org} website.
 
 There are two kinds of releases:
 
@@ -797,7 +797,7 @@ Prepare the release tarballs in @code{bz2} and @code{gz} 
formats, and
 supplementing files that contain @code{gpg} signatures
 
 @item
-Publish the tarballs at @url{http://ffmpeg.org/releases}. Create and
+Publish the tarballs at @url{https://ffmpeg.org/releases}. Create and
 push an annotated tag in the form @code{nX}, with @code{X}
 containing the version number.
 
-- 
2.6.1

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] vp9: add x86 simd (sse2/ssse3) for iadst4 10bpp functions.

2015-10-06 Thread Henrik Gramner 
On Tue, Oct 6, 2015 at 5:42 PM, Ronald S. Bultje  wrote:
> +cglobal vp9_%1_%3_4x4_add_10, 3, 3, 0, dst, stride, block, eob
[...]
> +movam0, [blockq+0*16+0]
> +movam4, [blockq+0*16+8]
> +movam1, [blockq+1*16+0]
> +movam5, [blockq+1*16+8]
> +packssdwm0, m4
> +packssdwm1, m5
> +movam2, [blockq+2*16+0]
> +movam4, [blockq+2*16+8]
> +movam3, [blockq+3*16+0]
> +movam5, [blockq+3*16+8]
> +packssdwm2, m4
> +packssdwm3, m5

Use packssdw with a memory arg as the second operand.

The mixing of MMX and SSE is quite ugly in general, but whatever works.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH] avcodec/alac: also use a temp buffer for 24bit samples

2015-10-06 Thread James Almer 
Since AVFrame.extended_data is apparently not padded, simd functions
could in some cases overread, so make the decoder use a temp buffer
unconditionally.

Signed-off-by: James Almer 
---
 libavcodec/alac.c | 18 +-
 1 file changed, 5 insertions(+), 13 deletions(-)

diff --git a/libavcodec/alac.c b/libavcodec/alac.c
index 146668e..394bd19 100644
--- a/libavcodec/alac.c
+++ b/libavcodec/alac.c
@@ -80,7 +80,6 @@ typedef struct ALACContext {
 int extra_bits; /**< number of extra bits beyond 16-bit */
 int nb_samples; /**< number of samples in the current frame */
 
-int direct_output;
 int extra_bit_bug;
 
 ALACDSPContext dsp;
@@ -278,10 +277,6 @@ static int decode_element(AVCodecContext *avctx, AVFrame 
*frame, int ch_index,
 return AVERROR_INVALIDDATA;
 }
 alac->nb_samples = output_samples;
-if (alac->direct_output) {
-for (ch = 0; ch < channels; ch++)
-alac->output_samples_buffer[ch] = (int32_t 
*)frame->extended_data[ch_index + ch];
-}
 
 if (is_compressed) {
 int16_t lpc_coefs[2][32];
@@ -393,8 +388,9 @@ static int decode_element(AVCodecContext *avctx, AVFrame 
*frame, int ch_index,
 break;
 case 24: {
 for (ch = 0; ch < channels; ch++) {
+int32_t *outbuffer = (int32_t *)frame->extended_data[ch_index + 
ch];
 for (i = 0; i < alac->nb_samples; i++)
-alac->output_samples_buffer[ch][i] <<= 8;
+*outbuffer++ = alac->output_samples_buffer[ch][i] << 8;
 }}
 break;
 }
@@ -468,8 +464,7 @@ static av_cold int alac_decode_close(AVCodecContext *avctx)
 int ch;
 for (ch = 0; ch < FFMIN(alac->channels, 2); ch++) {
 av_freep(>predict_error_buffer[ch]);
-if (!alac->direct_output)
-av_freep(>output_samples_buffer[ch]);
+av_freep(>output_samples_buffer[ch]);
 av_freep(>extra_bits_buffer[ch]);
 }
 
@@ -491,11 +486,8 @@ static int allocate_buffers(ALACContext *alac)
 FF_ALLOC_OR_GOTO(alac->avctx, alac->predict_error_buffer[ch],
  buf_size, buf_alloc_fail);
 
-alac->direct_output = alac->sample_size > 16;
-if (!alac->direct_output) {
-FF_ALLOC_OR_GOTO(alac->avctx, alac->output_samples_buffer[ch],
- buf_size, buf_alloc_fail);
-}
+FF_ALLOC_OR_GOTO(alac->avctx, alac->output_samples_buffer[ch],
+ buf_size, buf_alloc_fail);
 
 FF_ALLOC_OR_GOTO(alac->avctx, alac->extra_bits_buffer[ch],
  buf_size, buf_alloc_fail);
-- 
2.5.2

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] vp9: 16bpp tm/dc/h/v intra pred simd (mostly sse2) functions.

2015-10-06 Thread Matt Oliver 
On 6 October 2015 at 07:51, Ronald S. Bultje  wrote:

> Hi,
>
> On Mon, Oct 5, 2015 at 7:39 AM, Ronald S. Bultje 
> wrote:
>
> > Hi,
> >
> > On Mon, Oct 5, 2015 at 5:54 AM, Henrik Gramner 
> wrote:
> >
> >> On Mon, Oct 5, 2015 at 10:55 AM, Matt Oliver 
> >> wrote:
> >> > This patch has broken the 32bit msvc builds:
> >> >
> >>
> http://fate.ffmpeg.org/report.cgi?time=20151005065109=x86_32-msvc12-windows-native
> >> >
> >> > I had a look through the code but couldnt find the cause. The error
> >> message
> >> > just points to the code line for a macro instantiation and I'm not
> >> familiar
> >> > enough with the code to be able to work out where within the macro the
> >> > error is actually occurring and why. So ill leave this one to someone
> >> more
> >> > familiar with the code.
> >>
> >> I see where the problem is.
> >>
> >> Using stack space in cglobal requires an extra register if the stack
> >> alignment is less than mmsize (32-bit msvc only has 4-byte stack
> >> alignment), and if the function already utilizes all available
> >> registers that will result in failure.
> >>
> >> The fix is either to reduce the number of registers used by the
> >> function or to only enable the function on x86-32 if the stack is at
> >> least 16-byte aligned. x86inc has the variable STACK_ALIGNMENT which
> >> can be tested for this, in C there's the HAVE_ALIGNED_STACK define
> >> which is set if the stack is 16-byte aligned.
> >
> >
> > Yeah, it should use 6 regs, I'll send a patch.
> >
>
> Should be fixed now, apologies for the breakage.
>
>
Yep, looks all good now, thanks
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] avcodec/alac: also use a temp buffer for 24bit samples

2015-10-06 Thread Paul B Mahol 
On 10/6/15, James Almer  wrote:
> Since AVFrame.extended_data is apparently not padded, simd functions
> could in some cases overread, so make the decoder use a temp buffer
> unconditionally.
>
> Signed-off-by: James Almer 
> ---
>  libavcodec/alac.c | 18 +-
>  1 file changed, 5 insertions(+), 13 deletions(-)
>
> diff --git a/libavcodec/alac.c b/libavcodec/alac.c
> index 146668e..394bd19 100644
> --- a/libavcodec/alac.c
> +++ b/libavcodec/alac.c
> @@ -80,7 +80,6 @@ typedef struct ALACContext {
>  int extra_bits; /**< number of extra bits beyond 16-bit */
>  int nb_samples; /**< number of samples in the current frame */
>
> -int direct_output;
>  int extra_bit_bug;
>
>  ALACDSPContext dsp;
> @@ -278,10 +277,6 @@ static int decode_element(AVCodecContext *avctx,
> AVFrame *frame, int ch_index,
>  return AVERROR_INVALIDDATA;
>  }
>  alac->nb_samples = output_samples;
> -if (alac->direct_output) {
> -for (ch = 0; ch < channels; ch++)
> -alac->output_samples_buffer[ch] = (int32_t
> *)frame->extended_data[ch_index + ch];
> -}
>
>  if (is_compressed) {
>  int16_t lpc_coefs[2][32];
> @@ -393,8 +388,9 @@ static int decode_element(AVCodecContext *avctx, AVFrame
> *frame, int ch_index,
>  break;
>  case 24: {
>  for (ch = 0; ch < channels; ch++) {
> +int32_t *outbuffer = (int32_t *)frame->extended_data[ch_index +
> ch];
>  for (i = 0; i < alac->nb_samples; i++)
> -alac->output_samples_buffer[ch][i] <<= 8;
> +*outbuffer++ = alac->output_samples_buffer[ch][i] << 8;
>  }}
>  break;
>  }
> @@ -468,8 +464,7 @@ static av_cold int alac_decode_close(AVCodecContext
> *avctx)
>  int ch;
>  for (ch = 0; ch < FFMIN(alac->channels, 2); ch++) {
>  av_freep(>predict_error_buffer[ch]);
> -if (!alac->direct_output)
> -av_freep(>output_samples_buffer[ch]);
> +av_freep(>output_samples_buffer[ch]);
>  av_freep(>extra_bits_buffer[ch]);
>  }
>
> @@ -491,11 +486,8 @@ static int allocate_buffers(ALACContext *alac)
>  FF_ALLOC_OR_GOTO(alac->avctx, alac->predict_error_buffer[ch],
>   buf_size, buf_alloc_fail);
>
> -alac->direct_output = alac->sample_size > 16;
> -if (!alac->direct_output) {
> -FF_ALLOC_OR_GOTO(alac->avctx, alac->output_samples_buffer[ch],
> - buf_size, buf_alloc_fail);
> -}
> +FF_ALLOC_OR_GOTO(alac->avctx, alac->output_samples_buffer[ch],
> + buf_size, buf_alloc_fail);
>
>  FF_ALLOC_OR_GOTO(alac->avctx, alac->extra_bits_buffer[ch],
>   buf_size, buf_alloc_fail);
> --
> 2.5.2
>
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>

it should be padded and not introduce slowdown
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH] vp9: initial attempt at a idct_idct_4x4 12bpp x86 simd (sse2) impl.

2015-10-06 Thread Ronald S. Bultje 
The trouble with this function is that intermediates overflow 31+sign
bits, so I've added some helpers (that will also be used in 10/12bpp
8x8, 16x16 and 32x32) to make that easier, basically emulating a half-
assed pmaddqd using 2xpmaddwd. It's currently sse2-only, if anyone sees
potential in adding ssse3, I'd love to hear it.
---
 libavcodec/x86/vp9dsp_init_16bpp_template.c |   4 +
 libavcodec/x86/vp9itxfm_16bpp.asm   | 122 
 2 files changed, 126 insertions(+)

diff --git a/libavcodec/x86/vp9dsp_init_16bpp_template.c 
b/libavcodec/x86/vp9dsp_init_16bpp_template.c
index 93fc684..35f99b7 100644
--- a/libavcodec/x86/vp9dsp_init_16bpp_template.c
+++ b/libavcodec/x86/vp9dsp_init_16bpp_template.c
@@ -131,6 +131,8 @@ decl_itxfm_func(idct,  iadst, 4, BPC, sse2);
 decl_itxfm_func(iadst, idct,  4, BPC, sse2);
 decl_itxfm_func(iadst, iadst, 4, BPC, sse2);
 decl_itxfm_funcs(4, BPC, ssse3);
+#else
+decl_itxfm_func(idct,  idct,  4, BPC, sse2);
 #endif
 #endif /* HAVE_YASM */
 
@@ -199,6 +201,8 @@ av_cold void INIT_FUNC(VP9DSPContext *dsp, int bitexact)
 init_itx_func(TX_4X4, DCT_ADST,  iadst, idct,  4, 10, sse2);
 init_itx_func(TX_4X4, ADST_ADST, iadst, iadst, 4, 10, sse2);
 }
+#else
+init_itx_func(TX_4X4, DCT_DCT, idct, idct, 4, 12, sse2);
 #endif
 }
 
diff --git a/libavcodec/x86/vp9itxfm_16bpp.asm 
b/libavcodec/x86/vp9itxfm_16bpp.asm
index 11f080c..3621287 100644
--- a/libavcodec/x86/vp9itxfm_16bpp.asm
+++ b/libavcodec/x86/vp9itxfm_16bpp.asm
@@ -31,6 +31,9 @@ cextern pw_2048
 cextern pw_4095
 cextern pd_8192
 
+pd_8: times 4 dd 8
+pd_3fff: times 4 dd 0x3fff
+
 ; FIXME these should probably be shared between 8bpp and 10/12bpp
 pw_m11585_11585: times 4 dw -11585, 11585
 pw_11585_11585: times 8 dw 11585
@@ -273,3 +276,122 @@ INIT_MMX ssse3
 IADST4_FN idct,  IDCT4,  iadst, IADST4
 IADST4_FN iadst, IADST4, idct,  IDCT4
 IADST4_FN iadst, IADST4, iadst, IADST4
+
+; inputs and outputs are dwords, coefficients are words
+;
+; dst1 = src1 * coef1 + src2 * coef2 + rnd >> 14
+; dst2 = src1 * coef2 - src2 * coef1 + rnd >> 14
+%macro SUMSUB_MUL 6 ; src/dst 1-2, tmp1-2, coef1-2
+pand   m%3, m%1, [pd_3fff]
+pand   m%4, m%2, [pd_3fff]
+psrad  m%1, 14
+psrad  m%2, 14
+packssdw   m%4, m%2
+packssdw   m%3, m%1
+punpckhwd  m%2, m%4, m%3
+punpcklwd  m%4, m%3
+pmaddwdm%3, m%4, [pw_%6_%5]
+pmaddwdm%1, m%2, [pw_%6_%5]
+pmaddwdm%4, [pw_m%5_%6]
+pmaddwdm%2, [pw_m%5_%6]
+paddd  m%3, [pd_8192]
+paddd  m%4, [pd_8192]
+psrad  m%3, 14
+psrad  m%4, 14
+paddd  m%1, m%3
+paddd  m%2, m%4
+%endmacro
+
+%macro IDCT4_12BPP_1D 0
+SUMSUB_MUL   0, 2, 4, 5, 11585, 11585
+SUMSUB_MUL   1, 3, 4, 5, 15137,  6270
+SUMSUB_BA d, 1, 0, 4
+SUMSUB_BA d, 3, 2, 4
+SWAP 1, 3, 0
+%endmacro
+
+INIT_XMM sse2
+cglobal vp9_idct_idct_4x4_add_12, 4, 4, 6, dst, stride, block, eob
+cmp   eobd, 1
+jg .idctfull
+
+; dc-only - this is special, since for 4x4 12bpp, the max coef size is
+; 17+sign bpp. Since the multiply is with 11585, which is 14bpp, the
+; result of each multiply is 31+sign bit, i.e. it _exactly_ fits in a
+; dword. After the final shift (4), the result is 13+sign bits, so we
+; don't need any additional processing to fit it in a word
+DEFINE_ARGS dst, stride, block, coef
+mov  coefd, dword [blockq]
+imul coefd, 11585
+add  coefd, 8192
+sar  coefd, 14
+imul coefd, 11585
+add  coefd, (8 << 14) + 8192
+sar  coefd, 14 + 4
+movdm0, coefd
+punpcklwd   m0, m0
+pshufd  m0, m0, q
+pxorm4, m4
+movam5, [pw_4095]
+movd  [blockq], m4
+DEFINE_ARGS dst, stride, stride3
+lea   stride3q, [strideq*3]
+movhm1, [dstq+strideq*0]
+movhm3, [dstq+strideq*2]
+movhps  m1, [dstq+strideq*1]
+movhps  m3, [dstq+stride3q ]
+paddw   m1, m0
+paddw   m3, m0
+pmaxsw  m1, m4
+pmaxsw  m3, m4
+pminsw  m1, m5
+pminsw  m3, m5
+movh   [dstq+strideq*0], m1
+movhps [dstq+strideq*1], m1
+movh   [dstq+strideq*2], m3
+movhps [dstq+stride3q ], m3
+RET
+
+.idctfull:
+DEFINE_ARGS dst, stride, block, eob
+movam0, [blockq+0*16]
+movam1, [blockq+1*16]
+movam2, [blockq+2*16]
+movam3, [blockq+3*16]
+
+IDCT4_12BPP_1D
+TRANSPOSE4x4D0, 1, 2, 3, 4
+

Re: [FFmpeg-devel] [PATCH] avcodec/alac: also use a temp buffer for 24bit samples

2015-10-06 Thread James Almer 
On 10/6/2015 4:40 PM, Paul B Mahol wrote:
> On 10/6/15, James Almer  wrote:
>> Since AVFrame.extended_data is apparently not padded, simd functions
>> could in some cases overread, so make the decoder use a temp buffer
>> unconditionally.
>>
>> Signed-off-by: James Almer 
>> ---
>>  libavcodec/alac.c | 18 +-
>>  1 file changed, 5 insertions(+), 13 deletions(-)
>>
>> diff --git a/libavcodec/alac.c b/libavcodec/alac.c
>> index 146668e..394bd19 100644
>> --- a/libavcodec/alac.c
>> +++ b/libavcodec/alac.c
>> @@ -80,7 +80,6 @@ typedef struct ALACContext {
>>  int extra_bits; /**< number of extra bits beyond 16-bit */
>>  int nb_samples; /**< number of samples in the current frame */
>>
>> -int direct_output;
>>  int extra_bit_bug;
>>
>>  ALACDSPContext dsp;
>> @@ -278,10 +277,6 @@ static int decode_element(AVCodecContext *avctx,
>> AVFrame *frame, int ch_index,
>>  return AVERROR_INVALIDDATA;
>>  }
>>  alac->nb_samples = output_samples;
>> -if (alac->direct_output) {
>> -for (ch = 0; ch < channels; ch++)
>> -alac->output_samples_buffer[ch] = (int32_t
>> *)frame->extended_data[ch_index + ch];
>> -}
>>
>>  if (is_compressed) {
>>  int16_t lpc_coefs[2][32];
>> @@ -393,8 +388,9 @@ static int decode_element(AVCodecContext *avctx, AVFrame
>> *frame, int ch_index,
>>  break;
>>  case 24: {
>>  for (ch = 0; ch < channels; ch++) {
>> +int32_t *outbuffer = (int32_t *)frame->extended_data[ch_index +
>> ch];
>>  for (i = 0; i < alac->nb_samples; i++)
>> -alac->output_samples_buffer[ch][i] <<= 8;
>> +*outbuffer++ = alac->output_samples_buffer[ch][i] << 8;
>>  }}
>>  break;
>>  }
>> @@ -468,8 +464,7 @@ static av_cold int alac_decode_close(AVCodecContext
>> *avctx)
>>  int ch;
>>  for (ch = 0; ch < FFMIN(alac->channels, 2); ch++) {
>>  av_freep(>predict_error_buffer[ch]);
>> -if (!alac->direct_output)
>> -av_freep(>output_samples_buffer[ch]);
>> +av_freep(>output_samples_buffer[ch]);
>>  av_freep(>extra_bits_buffer[ch]);
>>  }
>>
>> @@ -491,11 +486,8 @@ static int allocate_buffers(ALACContext *alac)
>>  FF_ALLOC_OR_GOTO(alac->avctx, alac->predict_error_buffer[ch],
>>   buf_size, buf_alloc_fail);
>>
>> -alac->direct_output = alac->sample_size > 16;
>> -if (!alac->direct_output) {
>> -FF_ALLOC_OR_GOTO(alac->avctx, alac->output_samples_buffer[ch],
>> - buf_size, buf_alloc_fail);
>> -}
>> +FF_ALLOC_OR_GOTO(alac->avctx, alac->output_samples_buffer[ch],
>> + buf_size, buf_alloc_fail);
>>
>>  FF_ALLOC_OR_GOTO(alac->avctx, alac->extra_bits_buffer[ch],
>>   buf_size, buf_alloc_fail);
>> --
>> 2.5.2
>>
>> ___
>> ffmpeg-devel mailing list
>> ffmpeg-devel@ffmpeg.org
>> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>>
> 
> it should be padded and not introduce slowdown

If you mean the temp buffers, they will be padded alongside the simd functions
once i commit them.
But If you mean the avframe.extended_data buffer, could you take care of that?
I'm not familiar enough with avframe to change the relevant alloc functions.

running "time ffmpeg -v 0 -threads 1 -i INPUT -threads 1 -f null -" (implicit
pcm_s16le output)

Before
real0m0.596s
user0m0.000s
sys 0m0.000s

After
real0m0.575s
user0m0.000s
sys 0m0.000s


running "time ffmpeg -v 0 -threads 1 -i INPUT -threads 1 -c:a pcm_s24le -f null 
-"

Before
real0m0.618s
user0m0.000s
sys 0m0.000s

After
real0m0.618s
user0m0.000s
sys 0m0.000s

With a ~1 minute 24 bit 44.1kh stereo sample. Curious that it's faster when the
output is s16.
You'll probably have to do the same for the tak decoder before you commit your
decorrelate simd patch, btw. It also uses avframe.extended_data buffer directly
for 24bit samples.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 1/3] dnxhddec: better support for 4:4:4

2015-10-06 Thread Michael Niedermayer 
On Mon, Oct 05, 2015 at 08:44:44PM +0200, Christophe Gisquet wrote:
> Profiles 1256 & 1270 (currently) signal at the frame header and MB
> levels the colorspace used, either RGB or YUV. While a MB-level
> varying colorspace is not supported, whether it is constant can be
> tracked so as to determine the exact colorspace.
> 
> It is not tested against a true RGB sequence, though.
> ---
>  libavcodec/dnxhddec.c | 82 
> ++-
>  1 file changed, 62 insertions(+), 20 deletions(-)
> 
> diff --git a/libavcodec/dnxhddec.c b/libavcodec/dnxhddec.c
> index fec9aac..52fd334 100644
> --- a/libavcodec/dnxhddec.c
> +++ b/libavcodec/dnxhddec.c
> @@ -43,6 +43,8 @@ typedef struct RowContext {
>  int last_dc[3];
>  int last_qscale;
>  int errors;
> +/** -1:not set yet  0:off=RGB  1:on=YUV  2:variable */
> +int format;
>  } RowContext;
>  
>  typedef struct DNXHDContext {
> @@ -202,6 +204,18 @@ static int dnxhd_decode_header(DNXHDContext *ctx, 
> AVFrame *frame,
>  }
>  ctx->avctx->bits_per_raw_sample = ctx->bit_depth;
>  
> +cid = AV_RB32(buf + 0x28);
> +if ((ret = dnxhd_init_vlc(ctx, cid)) < 0)
> +return ret;

this would allow ctx->bit_depth to be set but without initializing the
dsp contexts
subsequent runs would also skip init due to
" if (ctx->bit_depth != old_bit_depth) {"

[]
-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

In a rich man's house there is no place to spit but his face.
-- Diogenes of Sinope


signature.asc
Description: Digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] avcodec/alac: also use a temp buffer for 24bit samples

2015-10-06 Thread Paul B Mahol 
On 10/6/15, James Almer  wrote:
> On 10/6/2015 4:40 PM, Paul B Mahol wrote:
>> On 10/6/15, James Almer  wrote:
>>> Since AVFrame.extended_data is apparently not padded, simd functions
>>> could in some cases overread, so make the decoder use a temp buffer
>>> unconditionally.
>>>
>>> Signed-off-by: James Almer 
>>> ---
>>>  libavcodec/alac.c | 18 +-
>>>  1 file changed, 5 insertions(+), 13 deletions(-)
>>>
>>> diff --git a/libavcodec/alac.c b/libavcodec/alac.c
>>> index 146668e..394bd19 100644
>>> --- a/libavcodec/alac.c
>>> +++ b/libavcodec/alac.c
>>> @@ -80,7 +80,6 @@ typedef struct ALACContext {
>>>  int extra_bits; /**< number of extra bits beyond 16-bit */
>>>  int nb_samples; /**< number of samples in the current frame */
>>>
>>> -int direct_output;
>>>  int extra_bit_bug;
>>>
>>>  ALACDSPContext dsp;
>>> @@ -278,10 +277,6 @@ static int decode_element(AVCodecContext *avctx,
>>> AVFrame *frame, int ch_index,
>>>  return AVERROR_INVALIDDATA;
>>>  }
>>>  alac->nb_samples = output_samples;
>>> -if (alac->direct_output) {
>>> -for (ch = 0; ch < channels; ch++)
>>> -alac->output_samples_buffer[ch] = (int32_t
>>> *)frame->extended_data[ch_index + ch];
>>> -}
>>>
>>>  if (is_compressed) {
>>>  int16_t lpc_coefs[2][32];
>>> @@ -393,8 +388,9 @@ static int decode_element(AVCodecContext *avctx,
>>> AVFrame
>>> *frame, int ch_index,
>>>  break;
>>>  case 24: {
>>>  for (ch = 0; ch < channels; ch++) {
>>> +int32_t *outbuffer = (int32_t
>>> *)frame->extended_data[ch_index +
>>> ch];
>>>  for (i = 0; i < alac->nb_samples; i++)
>>> -alac->output_samples_buffer[ch][i] <<= 8;
>>> +*outbuffer++ = alac->output_samples_buffer[ch][i] << 8;
>>>  }}
>>>  break;
>>>  }
>>> @@ -468,8 +464,7 @@ static av_cold int alac_decode_close(AVCodecContext
>>> *avctx)
>>>  int ch;
>>>  for (ch = 0; ch < FFMIN(alac->channels, 2); ch++) {
>>>  av_freep(>predict_error_buffer[ch]);
>>> -if (!alac->direct_output)
>>> -av_freep(>output_samples_buffer[ch]);
>>> +av_freep(>output_samples_buffer[ch]);
>>>  av_freep(>extra_bits_buffer[ch]);
>>>  }
>>>
>>> @@ -491,11 +486,8 @@ static int allocate_buffers(ALACContext *alac)
>>>  FF_ALLOC_OR_GOTO(alac->avctx, alac->predict_error_buffer[ch],
>>>   buf_size, buf_alloc_fail);
>>>
>>> -alac->direct_output = alac->sample_size > 16;
>>> -if (!alac->direct_output) {
>>> -FF_ALLOC_OR_GOTO(alac->avctx,
>>> alac->output_samples_buffer[ch],
>>> - buf_size, buf_alloc_fail);
>>> -}
>>> +FF_ALLOC_OR_GOTO(alac->avctx, alac->output_samples_buffer[ch],
>>> + buf_size, buf_alloc_fail);
>>>
>>>  FF_ALLOC_OR_GOTO(alac->avctx, alac->extra_bits_buffer[ch],
>>>   buf_size, buf_alloc_fail);
>>> --
>>> 2.5.2
>>>
>>> ___
>>> ffmpeg-devel mailing list
>>> ffmpeg-devel@ffmpeg.org
>>> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>>>
>>
>> it should be padded and not introduce slowdown
>
> If you mean the temp buffers, they will be padded alongside the simd
> functions
> once i commit them.
> But If you mean the avframe.extended_data buffer, could you take care of
> that?
> I'm not familiar enough with avframe to change the relevant alloc functions.
>
> running "time ffmpeg -v 0 -threads 1 -i INPUT -threads 1 -f null -"
> (implicit
> pcm_s16le output)
>
> Before
> real0m0.596s
> user0m0.000s
> sys 0m0.000s
>
> After
> real0m0.575s
> user0m0.000s
> sys 0m0.000s
>
>
> running "time ffmpeg -v 0 -threads 1 -i INPUT -threads 1 -c:a pcm_s24le -f
> null -"
>
> Before
> real0m0.618s
> user0m0.000s
> sys 0m0.000s
>
> After
> real0m0.618s
> user0m0.000s
> sys 0m0.000s
>
> With a ~1 minute 24 bit 44.1kh stereo sample. Curious that it's faster when
> the
> output is s16.
> You'll probably have to do the same for the tak decoder before you commit
> your
> decorrelate simd patch, btw. It also uses avframe.extended_data buffer
> directly
> for 24bit samples.
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>

you set aligned number of samples before calling get_buffer and after
that changes
frame->nb_samples to actual number of samples.

Alternatively IIRC default 16 byte alignment could be increased.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] Add space after commas in HTTP/RTSP auth header

2015-10-06 Thread Michael Niedermayer 
On Tue, Oct 06, 2015 at 10:00:29AM -0400, Calvin Walton wrote:
> On Thu, 2015-10-01 at 13:56 +0300, Andrey Utkin wrote:
> > This fixes access to Grandstream cameras, which return 401 to ffmpeg
> > otherwise.
> > VLC sends Authorization: header with spaces between parameters, and
> > it
> > is known to work with Grandstream devices and broad range of other
> > HTTP
> > and RTSP servers, so author considers switching to such behaviour
> > safe.
> > Just for record - RFC 2617 (HTTP Auth) does not specify the need in
> > spaces, so this is not a bug of FFmpeg.
> 
> For those curious about the updated versions of the HTTP/1.1 specs, the
> current HTTP Auth RFC 7235 uses the # (list) ABNF from RFC 7230 section
> 7, which specifies the separator as "," surrounded by OWS (optional
> whitespace). Section 3.2.3 says:
> 
>    The OWS rule is used where zero or more linear whitespace octets
>    might appear.  For protocol elements where optional whitespace is
>    preferred to improve readability, a sender SHOULD generate the
>    optional whitespace as a single SP; otherwise, a sender SHOULD NOT
>    generate optional whitespace except as needed to white out invalid or
>    unwanted protocol elements during in-place message filtering.
> 
> So in this case, using ", " as the separator appears to be preferred
> but not required by the RFCs. But it certainly doesn't require that the
> space is present! I agree that this isn't really an FFmpeg bug, but
>  switching to use ", " is probably a good idea regardless.

ok, thanks for the explanation

patch applied

[...]
-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Freedom in capitalist society always remains about the same as it was in
ancient Greek republics: Freedom for slave owners. -- Vladimir Lenin


signature.asc
Description: Digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] avfilter/buffersrc: add av_warn_unused_result attributes

2015-10-06 Thread Nicolas George 
Le quartidi 14 vendémiaire, an CCXXIV, Ganesh Ajjanagadde a écrit :
> This adds av_warn_unused_result whenever it is relevant.
> 
> Signed-off-by: Ganesh Ajjanagadde 
> ---
>  libavfilter/buffersrc.h | 6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)

I do not have much of an opinion about this. It looks right in principle,
but warnings sometimes have unexpected advert effects.

> -int av_buffersrc_add_frame_flags(AVFilterContext *buffer_src,
> +av_warn_unused_result int av_buffersrc_add_frame_flags(AVFilterContext 
> *buffer_src,
>   AVFrame *frame, int flags);

It is a bit sad to break alignment, though. I would slightly prefer having
the long attribute on a line by itself:

av_warn_unused_result
int av_yada_yada_yada(argu *ments);

... if people are ok with it too. Otherwise, reindenting with the same
commit seems acceptable in this case.

Regards,

-- 
  Nicolas George


signature.asc
Description: Digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 2/2] avfilter/formats: add av_warn_unused_result to function prototypes

2015-10-06 Thread Nicolas George 
Le quartidi 14 vendémiaire, an CCXXIV, Ganesh Ajjanagadde a écrit :
> Off topic, but I would greatly appreciate any help/suggestions for how
> to get gmail to work correctly, or alternative mailbox providers for
> patch sending purposes.

I suspect it is related to using gmail as a webmail, and would not occur
with a real MUA, even accessing gmail with it.

Regards,

-- 
  Nicolas George


signature.asc
Description: Digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH 2/3] lavfi/af_pan: check ff_add_channel_layout() return.

2015-10-06 Thread Nicolas George 
Signed-off-by: Nicolas George 
---
 libavfilter/af_pan.c | 9 ++---
 1 file changed, 6 insertions(+), 3 deletions(-)

diff --git a/libavfilter/af_pan.c b/libavfilter/af_pan.c
index d116818..5062252 100644
--- a/libavfilter/af_pan.c
+++ b/libavfilter/af_pan.c
@@ -227,6 +227,7 @@ static int query_formats(AVFilterContext *ctx)
 AVFilterLink *outlink = ctx->outputs[0];
 AVFilterFormats *formats = NULL;
 AVFilterChannelLayouts *layouts;
+int ret;
 
 pan->pure_gains = are_gains_pure(pan);
 /* libswr supports any sample and packing formats */
@@ -245,9 +246,11 @@ static int query_formats(AVFilterContext *ctx)
 
 // outlink supports only requested output channel layout
 layouts = NULL;
-ff_add_channel_layout(,
-  pan->out_channel_layout ? pan->out_channel_layout :
-  FF_COUNT2LAYOUT(pan->nb_output_channels));
+ret = ff_add_channel_layout(,
+pan->out_channel_layout ? 
pan->out_channel_layout :
+FF_COUNT2LAYOUT(pan->nb_output_channels));
+if (ret < 0)
+return ret;
 ff_channel_layouts_ref(layouts, >in_channel_layouts);
 return 0;
 }
-- 
2.5.3

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH] lavf/mov: add support for sidx fragment indexes

2015-10-06 Thread Rodger Combs 
Fixes trac #3842
---
 libavformat/isom.h |   2 +
 libavformat/mov.c  | 245 -
 2 files changed, 208 insertions(+), 39 deletions(-)

diff --git a/libavformat/isom.h b/libavformat/isom.h
index aee9d6e..6e921c0 100644
--- a/libavformat/isom.h
+++ b/libavformat/isom.h
@@ -103,6 +103,7 @@ typedef struct MOVSbgp {
 typedef struct MOVFragmentIndexItem {
 int64_t moof_offset;
 int64_t time;
+int headers_read;
 } MOVFragmentIndexItem;
 
 typedef struct MOVFragmentIndex {
@@ -197,6 +198,7 @@ typedef struct MOVContext {
 int has_looked_for_mfra;
 MOVFragmentIndex** fragment_index_data;
 unsigned fragment_index_count;
+int fragment_index_complete;
 int atom_depth;
 unsigned int aax_mode;  ///< 'aax' file has been detected
 uint8_t file_key[20];
diff --git a/libavformat/mov.c b/libavformat/mov.c
index da170a6..8463d57 100644
--- a/libavformat/mov.c
+++ b/libavformat/mov.c
@@ -3349,7 +3349,7 @@ static int mov_read_tfhd(MOVContext *c, AVIOContext *pb, 
MOVAtom atom)
 MOVFragment *frag = >fragment;
 MOVTrackExt *trex = NULL;
 MOVFragmentIndex* index = NULL;
-int flags, track_id, i;
+int flags, track_id, i, found = 0;
 
 avio_r8(pb); /* version */
 flags = avio_rb24(pb);
@@ -3367,15 +3367,6 @@ static int mov_read_tfhd(MOVContext *c, AVIOContext *pb, 
MOVAtom atom)
 av_log(c->fc, AV_LOG_ERROR, "could not find corresponding trex\n");
 return AVERROR_INVALIDDATA;
 }
-for (i = 0; i < c->fragment_index_count; i++) {
-MOVFragmentIndex* candidate = c->fragment_index_data[i];
-if (candidate->track_id == frag->track_id) {
-av_log(c->fc, AV_LOG_DEBUG,
-   "found fragment index for track %u\n", frag->track_id);
-index = candidate;
-break;
-}
-}
 
 frag->base_data_offset = flags & MOV_TFHD_BASE_DATA_OFFSET ?
  avio_rb64(pb) : flags & 
MOV_TFHD_DEFAULT_BASE_IS_MOOF ?
@@ -3389,24 +3380,33 @@ static int mov_read_tfhd(MOVContext *c, AVIOContext 
*pb, MOVAtom atom)
 frag->flags= flags & MOV_TFHD_DEFAULT_FLAGS ?
  avio_rb32(pb) : trex->flags;
 frag->time = AV_NOPTS_VALUE;
-if (index) {
-int i, found = 0;
-for (i = index->current_item; i < index->item_count; i++) {
-if (frag->implicit_offset == index->items[i].moof_offset) {
-av_log(c->fc, AV_LOG_DEBUG, "found fragment index entry "
-"for track %u and moof_offset %"PRId64"\n",
-frag->track_id, index->items[i].moof_offset);
-frag->time = index->items[i].time;
-index->current_item = i + 1;
-found = 1;
+for (i = 0; i < c->fragment_index_count; i++) {
+int j;
+MOVFragmentIndex* candidate = c->fragment_index_data[i];
+if (candidate->track_id == frag->track_id) {
+av_log(c->fc, AV_LOG_DEBUG,
+   "found fragment index for track %u\n", frag->track_id);
+index = candidate;
+for (j = index->current_item; j < index->item_count; j++) {
+if (frag->implicit_offset == index->items[j].moof_offset) {
+av_log(c->fc, AV_LOG_DEBUG, "found fragment index entry "
+"for track %u and moof_offset %"PRId64"\n",
+frag->track_id, index->items[j].moof_offset);
+frag->time = index->items[j].time;
+index->current_item = j + 1;
+found = 1;
+break;
+}
 }
-}
-if (!found) {
-av_log(c->fc, AV_LOG_WARNING, "track %u has a fragment index "
-   "but it doesn't have an (in-order) entry for moof_offset "
-   "%"PRId64"\n", frag->track_id, frag->implicit_offset);
+if (found)
+break;
 }
 }
+if (index && !found) {
+av_log(c->fc, AV_LOG_DEBUG, "track %u has a fragment index but "
+   "it doesn't have an (in-order) entry for moof_offset "
+   "%"PRId64"\n", frag->track_id, frag->implicit_offset);
+}
 av_log(c->fc, AV_LOG_TRACE, "frag flags 0x%x\n", frag->flags);
 return 0;
 }
@@ -3596,7 +3596,106 @@ static int mov_read_trun(MOVContext *c, AVIOContext 
*pb, MOVAtom atom)
 return AVERROR_EOF;
 
 frag->implicit_offset = offset;
-st->duration = sc->track_end = dts + sc->time_offset;
+
+sc->track_end = dts + sc->time_offset;
+if (st->duration < sc->track_end)
+st->duration = sc->track_end;
+
+return 0;
+}
+
+static int mov_read_sidx(MOVContext *c, AVIOContext *pb, MOVAtom atom)
+{
+int64_t offset = avio_tell(pb) + atom.size, pts;
+uint8_t version;
+unsigned i, track_id;
+AVStream *st = NULL;
+MOVStreamContext *sc;
+MOVFragmentIndex

Re: [FFmpeg-devel] [PATCH 2/2] x86/alacdsp: add simd optimized functions

2015-10-06 Thread Paul B Mahol 
On 10/6/15, James Almer  wrote:
> On 10/5/2015 6:48 PM, Paul B Mahol wrote:
>> On 10/4/15, James Almer  wrote:
>>> Signed-off-by: James Almer 
>>> ---
>>>  libavcodec/alacdsp.c  |   3 +
>>>  libavcodec/alacdsp.h  |   1 +
>>>  libavcodec/x86/Makefile   |   2 +
>>>  libavcodec/x86/alacdsp.asm| 133
>>> ++
>>>  libavcodec/x86/alacdsp_init.c |  44 ++
>>>  5 files changed, 183 insertions(+)
>>>  create mode 100644 libavcodec/x86/alacdsp.asm
>>>  create mode 100644 libavcodec/x86/alacdsp_init.c
>>>
>>
>> Have you measured speed gain?
>
> About three to four times faster than c.

I was more interested in overall gain.
If fate covers this functions and fate still passes it should be fine imho.
 ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH 1/3] lavfi/af_pan: check ff_all_channel_counts() return.

2015-10-06 Thread Nicolas George 
Fix CID 1325680.

Signed-off-by: Nicolas George 
---
 libavfilter/af_pan.c | 2 ++
 1 file changed, 2 insertions(+)


Will push this series soon unless somebody objects.


diff --git a/libavfilter/af_pan.c b/libavfilter/af_pan.c
index 9117cc0..d116818 100644
--- a/libavfilter/af_pan.c
+++ b/libavfilter/af_pan.c
@@ -239,6 +239,8 @@ static int query_formats(AVFilterContext *ctx)
 
 // inlink supports any channel layout
 layouts = ff_all_channel_counts();
+if (!layouts)
+return AVERROR(ENOMEM);
 ff_channel_layouts_ref(layouts, >out_channel_layouts);
 
 // outlink supports only requested output channel layout
-- 
2.5.3

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH 3/3] lavfi/af_astreamsync: check ff_all_samplerates() return.

2015-10-06 Thread Nicolas George 
Fix CID 1325679.

Signed-off-by: Nicolas George 
---
 libavfilter/af_astreamsync.c | 2 ++
 1 file changed, 2 insertions(+)


The way the formats and layouts are set look fishy, but I do not have time
to look into it right now. And this filter is not useful for users anyway.


diff --git a/libavfilter/af_astreamsync.c b/libavfilter/af_astreamsync.c
index becfe34..1e2778a 100644
--- a/libavfilter/af_astreamsync.c
+++ b/libavfilter/af_astreamsync.c
@@ -98,6 +98,8 @@ static int query_formats(AVFilterContext *ctx)
 ff_formats_ref(formats, >inputs[i]->out_formats);
 ff_formats_ref(formats, >outputs[i]->in_formats);
 rates = ff_all_samplerates();
+if (!rates)
+return AVERROR(ENOMEM);
 ff_formats_ref(rates, >inputs[i]->out_samplerates);
 ff_formats_ref(rates, >outputs[i]->in_samplerates);
 layouts = ctx->inputs[i]->in_channel_layouts;
-- 
2.5.3

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] Issue using AVIOContext

2015-10-06 Thread Jorge A . Rodríguez Campos 
Hi,
I'm testing a program using  AVIOContext to extract some frames of a video,
I need to use an InputStream not a URL.  I'm using the source code of
avio_reading.c  to test my sample videos (
https://www.ffmpeg.org/doxygen/trunk/avio__reading_8c_source.html)

I tested this program with video1.wmv without any problems.
After that I converted video1.wmv into some video formats like mp4, mov,
asf, and avi

I got some errors only with mp4 and mov videos, the error is the same in
both cases:

[mov,mp4,m4a,3gp,3g2,mj2 @ 0x188ed00] stream 0, offset 0x30: partial file
[mov,mp4,m4a,3gp,3g2,mj2 @ 0x188ed00] Could not find codec parameters for
stream 0 (Video: h264 (avc1 / 0x31637661), none, 960x540, 728 kb/s):
unspecified pixel format
Consider increasing the value for the 'analyzeduration' and 'probesize'
options

I have tried to increase these values without success.
Looking into the output of this program, I noticed that all video is
scanned in order to find these parameters. So, I think the problem is that
some metadata are lost when I converted  from wmv to mp4.

I used this command to convert
ffmpeg -i video1.wmv -q:v 0 -vcodec libx264 -pix_fmt yuv420p video1.mp4

this is the output of av_dump_format using C program

Input #0, mov,mp4,m4a,3gp,3g2,mj2, from 'videos/bigdata.mp4':
  Metadata:
major_brand : isom
minor_version   : 512
compatible_brands: isomiso2avc1mp41
encoder : Lavf56.25.101
  Duration: 00:01:07.02, bitrate: N/A
Stream #0:0(eng): Video: h264 (avc1 / 0x31637661), none, 960x540, 728
kb/s, 30 fps, 30 tbr, 15360 tbn (default)
Metadata:
  handler_name: VideoHandler
Stream #0:1(eng): Audio: aac (mp4a / 0x6134706D), 32000 Hz, 2 channels,
93 kb/s (default)
Metadata:
  handler_name: SoundHandler

As you can see, there is a "none" value,  but I don't know how to fix this.
However, I tested this video without using an AVIOContext, and it works
fine.
Also, I tested it using ffmpeg command and also it works.

Finally this is the output of  ffmpeg -i  with this same video.

Input #0, mov,mp4,m4a,3gp,3g2,mj2, from 'videos/video1.mp4':
  Metadata:
major_brand : isom
minor_version   : 512
compatible_brands: isomiso2avc1mp41
encoder : Lavf56.25.101
  Duration: 00:01:07.02, start: 0.064000, bitrate: 824 kb/s
Stream #0:0(eng): Video: h264 (High) (avc1 / 0x31637661), yuv420p,
960x540, 728 kb/s, 30 fps, 30 tbr, 15360 tbn, 60 tbc (default)
Metadata:
  handler_name: VideoHandler
Stream #0:1(eng): Audio: aac (LC) (mp4a / 0x6134706D), 32000 Hz,
stereo, fltp, 93 kb/s (default)
Metadata:
  handler_name: SoundHandler


What do you think ?  I'm missing something when converting the video, or  I
need to add some lines in avio_reading.c ?
I'm using ffmpeg 2.6.2
thanks
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH] vp9: add 12bpp sse2 versions of iadst4.

2015-10-06 Thread Ronald S. Bultje 
---
 libavcodec/x86/vp9dsp_init_16bpp_template.c |   8 +-
 libavcodec/x86/vp9itxfm_16bpp.asm   | 119 
 2 files changed, 123 insertions(+), 4 deletions(-)

diff --git a/libavcodec/x86/vp9dsp_init_16bpp_template.c 
b/libavcodec/x86/vp9dsp_init_16bpp_template.c
index 35f99b7..13f2f39 100644
--- a/libavcodec/x86/vp9dsp_init_16bpp_template.c
+++ b/libavcodec/x86/vp9dsp_init_16bpp_template.c
@@ -127,13 +127,13 @@ decl_ipred_fns(tm, BPC, mmxext, sse2);
 decl_itxfm_func(iwht, iwht, 4, BPC, mmxext);
 #if BPC == 10
 decl_itxfm_func(idct,  idct,  4, BPC, mmxext);
-decl_itxfm_func(idct,  iadst, 4, BPC, sse2);
-decl_itxfm_func(iadst, idct,  4, BPC, sse2);
-decl_itxfm_func(iadst, iadst, 4, BPC, sse2);
 decl_itxfm_funcs(4, BPC, ssse3);
 #else
 decl_itxfm_func(idct,  idct,  4, BPC, sse2);
 #endif
+decl_itxfm_func(idct,  iadst, 4, BPC, sse2);
+decl_itxfm_func(iadst, idct,  4, BPC, sse2);
+decl_itxfm_func(iadst, iadst, 4, BPC, sse2);
 #endif /* HAVE_YASM */
 
 av_cold void INIT_FUNC(VP9DSPContext *dsp, int bitexact)
@@ -202,7 +202,7 @@ av_cold void INIT_FUNC(VP9DSPContext *dsp, int bitexact)
 init_itx_func(TX_4X4, ADST_ADST, iadst, iadst, 4, 10, sse2);
 }
 #else
-init_itx_func(TX_4X4, DCT_DCT, idct, idct, 4, 12, sse2);
+init_itx_funcs(TX_4X4, 4, 12, sse2);
 #endif
 }
 
diff --git a/libavcodec/x86/vp9itxfm_16bpp.asm 
b/libavcodec/x86/vp9itxfm_16bpp.asm
index 3621287..b4e8da8 100644
--- a/libavcodec/x86/vp9itxfm_16bpp.asm
+++ b/libavcodec/x86/vp9itxfm_16bpp.asm
@@ -49,6 +49,7 @@ pw_m5283_m15212: times 4 dw -5283, -15212
 pw_13377x2: times 8 dw 13377*2
 pw_m13377_13377: times 4 dw -13377, 13377
 pw_13377_0: times 4 dw 13377, 0
+pw_9929_m5283: times 4 dw 9929, -5283
 
 SECTION .text
 
@@ -395,3 +396,121 @@ cglobal vp9_idct_idct_4x4_add_12, 4, 4, 6, dst, stride, 
block, eob
 movh   [dstq+strideq*2], m2
 movhps [dstq+stride3q ], m2
 RET
+
+; out0 =  5283 * in0 + 13377 + in1 + 15212 * in2 +  9929 * in3 + rnd >> 14
+; out1 =  9929 * in0 + 13377 * in1 -  5283 * in2 - 15282 * in3 + rnd >> 14
+; out2 = 13377 * in0   - 13377 * in2 + 13377 * in3 + rnd >> 14
+; out3 = 15212 * in0 - 13377 * in1 +  9929 * in2 -  5283 * in3 + rnd >> 14
+%macro IADST4_12BPP_1D 0
+pandm4, m0, [pd_3fff]
+pandm5, m1, [pd_3fff]
+psrad   m0, 14
+psrad   m1, 14
+packssdwm5, m1
+packssdwm4, m0
+punpckhwd   m1, m4, m5
+punpcklwd   m4, m5
+pandm5, m2, [pd_3fff]
+pandm6, m3, [pd_3fff]
+psrad   m2, 14
+psrad   m3, 14
+packssdwm6, m3
+packssdwm5, m2
+punpckhwd   m3, m5, m6
+punpcklwd   m5, m6
+
+; m1/3 have the high bits of 1,0,3,2
+; m4/5 have the low bits of 1,0,3,2
+; m0/2/6/7 are free
+
+pmaddwd m7, m5, [pw_15212_9929]
+pmaddwd m6, m4, [pw_5283_13377]
+pmaddwd m2, m3, [pw_15212_9929]
+pmaddwd m0, m1, [pw_5283_13377]
+paddd   m6, m7
+paddd   m0, m2
+pmaddwd m7, m5, [pw_m13377_13377]
+pmaddwd m2, m4, [pw_13377_0]
+pmaddwd m8, m3, [pw_m13377_13377]
+pmaddwd m9, m1, [pw_13377_0]
+paddd   m2, m7
+paddd   m8, m9
+paddd   m6, [pd_8192]
+paddd   m2, [pd_8192]
+psrad   m6, 14
+psrad   m2, 14
+paddd   m0, m6  ; t0
+paddd   m2, m8  ; t2
+
+pmaddwd m7, m5, [pw_m5283_m15212]
+pmaddwd m6, m4, [pw_9929_13377]
+pmaddwd m8, m3, [pw_m5283_m15212]
+pmaddwd m9, m1, [pw_9929_13377]
+paddd   m6, m7
+paddd   m8, m9
+pmaddwd m5, [pw_9929_m5283]
+pmaddwd m4, [pw_15212_m13377]
+pmaddwd m3, [pw_9929_m5283]
+pmaddwd m1, [pw_15212_m13377]
+paddd   m4, m5
+paddd   m3, m1
+paddd   m6, [pd_8192]
+paddd   m4, [pd_8192]
+psrad   m6, 14
+psrad   m4, 14
+paddd   m8, m6  ; t1
+paddd   m3, m4  ; t3
+
+SWAP 1, 8
+%endmacro
+
+%macro IADST4_12BPP_FN 4
+INIT_XMM sse2
+cglobal vp9_%1_%3_4x4_add_12, 3, 3, 10, dst, stride, block, eob
+movam0, [blockq+0*16]
+movam1, [blockq+1*16]
+movam2, [blockq+2*16]
+movam3, [blockq+3*16]
+
+%2_12BPP_1D
+TRANSPOSE4x4D0, 1, 2, 3, 4
+%4_12BPP_1D
+
+pxorm4, m4
+ZERO_BLOCK  blockq, 16, 4, m4
+
+; writeout
+DEFINE_ARGS

[FFmpeg-devel] [PATCHv2] avcodec/libx264: silence -Waddress

2015-10-06 Thread Ganesh Ajjanagadde 
This patch moves the pointer validity check outside the macro,
and silences the -Waddress observed with GCC 5.2.

Note that this changes the error message slightly, from:
"bad option..." to "Error parsing option...".

Signed-off-by: Ganesh Ajjanagadde 
---
 libavcodec/libx264.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/libavcodec/libx264.c b/libavcodec/libx264.c
index 75b5a5f..cc79250 100644
--- a/libavcodec/libx264.c
+++ b/libavcodec/libx264.c
@@ -399,7 +399,7 @@ static av_cold int X264_close(AVCodecContext *avctx)
 #define OPT_STR(opt, param)   \
 do {  \
 int ret;  \
-if (param && (ret = x264_param_parse(>params, opt, param)) < 0) { \
+if ((ret = x264_param_parse(>params, opt, param)) < 0) { \
 if(ret == X264_PARAM_BAD_NAME)\
 av_log(avctx, AV_LOG_ERROR,   \
 "bad option '%s': '%s'\n", opt, param);   \
@@ -490,7 +490,7 @@ static av_cold int X264_init(AVCodecContext *avctx)
 x4->params.i_log_level  = X264_LOG_DEBUG;
 x4->params.i_csp= convert_pix_fmt(avctx->pix_fmt);
 
-OPT_STR("weightp", x4->wpredp);
+PARSE_X264_OPT("weightp", wpredp);
 
 if (avctx->bit_rate) {
 x4->params.rc.i_bitrate   = avctx->bit_rate / 1000;
@@ -520,7 +520,7 @@ static av_cold int X264_init(AVCodecContext *avctx)
 (float)avctx->rc_initial_buffer_occupancy / avctx->rc_buffer_size;
 }
 
-OPT_STR("level", x4->level);
+PARSE_X264_OPT("level", level);
 
 if (avctx->i_quant_factor > 0)
 x4->params.rc.f_ip_factor = 1 / fabs(avctx->i_quant_factor);
-- 
2.6.1

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 1/2] avutil/attributes: extend av_uninit to clang

2015-10-06 Thread Ganesh Ajjanagadde 
On Sat, Oct 3, 2015 at 8:38 AM, Ganesh Ajjanagadde
 wrote:
> On Sat, Sep 26, 2015 at 1:32 PM, Ganesh Ajjanagadde
>  wrote:
>> On Sat, Sep 19, 2015 at 1:00 AM, Ganesh Ajjanagadde
>>  wrote:
>>> Commit 6dac8c8327 disabled av_uninit for clang, due to some useless 
>>> warnings.
>>> The concept of av_uninit is inherently useful though. This patch silences a
>>> bunch of warnings on clang e.g
>>> http://fate.ffmpeg.org/log.cgi?time=20150918181527=compile=x86_64-darwin-clang-polly-vectorize-stripmine-3.7.
>>> Furthermore, it should be useful for general usage of av_uninit in future.
>>>
>>> Signed-off-by: Ganesh Ajjanagadde 
>>> ---
>>>  libavutil/attributes.h | 6 ++
>>>  1 file changed, 6 insertions(+)
>>>
>>> diff --git a/libavutil/attributes.h b/libavutil/attributes.h
>>> index 50e8eb3..b4b5f13 100644
>>> --- a/libavutil/attributes.h
>>> +++ b/libavutil/attributes.h
>>> @@ -141,6 +141,12 @@
>>>
>>>  #if defined(__GNUC__) && !defined(__INTEL_COMPILER) && !defined(__clang__)
>>>  #define av_uninit(x) x=x
>>> +#elif defined(__clang__)
>>> +#define av_uninit(x) \
>>> +_Pragma("clang diagnostic push") \
>>> +_Pragma("clang diagnostic ignored \"-Wuninitialized\"") \
>>> +x=x \
>>> +_Pragma("clang diagnostic pop")
>>>  #else
>>>  #define av_uninit(x) x
>>>  #endif
>>> --
>>> 2.5.2
>>>
>>
>> ping
>
> been a week, hence ping again.

ping: the reason I persist in this is because (long-term) the only 2
compilers where we can reasonably reach a near "warning is regression"
state and benefit from it are clang and gcc.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] avcodec/libx264: silence -Waddress

2015-10-06 Thread Ganesh Ajjanagadde 
On Sat, Oct 3, 2015 at 9:14 AM, Ronald S. Bultje  wrote:
> Hi,
>
> On Thu, Sep 17, 2015 at 7:03 AM, Ganesh Ajjanagadde 
> wrote:
>
>> On Thu, Sep 17, 2015 at 6:15 AM, Hendrik Leppkes 
>> wrote:
>> > On Thu, Sep 17, 2015 at 12:19 AM, Ganesh Ajjanagadde
>> >  wrote:
>> >> This patch moves the pointer validity check outside the macro,
>> >> and silences the -Waddress observed with GCC 5.2.
>> >>
>> >> Signed-off-by: Ganesh Ajjanagadde 
>> >> ---
>> >>  libavcodec/libx264.c | 8 +---
>> >>  1 file changed, 5 insertions(+), 3 deletions(-)
>> >>
>> >> diff --git a/libavcodec/libx264.c b/libavcodec/libx264.c
>> >> index 58fcfb0..c7c772e 100644
>> >> --- a/libavcodec/libx264.c
>> >> +++ b/libavcodec/libx264.c
>> >> @@ -346,7 +346,7 @@ static av_cold int X264_close(AVCodecContext *avctx)
>> >>  #define OPT_STR(opt, param)
>>\
>> >>  do {
>> \
>> >>  int ret;
>> \
>> >> -if (param && (ret = x264_param_parse(>params, opt, param))
>> < 0) { \
>> >> +if ((ret = x264_param_parse(>params, opt, param)) < 0) { \
>> >>  if(ret == X264_PARAM_BAD_NAME)
>> \
>> >>  av_log(avctx, AV_LOG_ERROR,
>>\
>> >>  "bad option '%s': '%s'\n", opt, param);
>>\
>> >> @@ -437,7 +437,8 @@ static av_cold int X264_init(AVCodecContext *avctx)
>> >>  x4->params.i_log_level  = X264_LOG_DEBUG;
>> >>  x4->params.i_csp= convert_pix_fmt(avctx->pix_fmt);
>> >>
>> >> -OPT_STR("weightp", x4->wpredp);
>> >> +if (x4->wpredp)
>> >> +OPT_STR("weightp", x4->wpredp);
>> >>
>> >>  if (avctx->bit_rate) {
>> >>  x4->params.rc.i_bitrate   = avctx->bit_rate / 1000;
>> >> @@ -467,7 +468,8 @@ static av_cold int X264_init(AVCodecContext *avctx)
>> >>  (float)avctx->rc_initial_buffer_occupancy /
>> avctx->rc_buffer_size;
>> >>  }
>> >>
>> >> -OPT_STR("level", x4->level);
>> >> +if (x4->level)
>> >> +OPT_STR("level", x4->level);
>> >>
>> >>  if (avctx->i_quant_factor > 0)
>> >>  x4->params.rc.f_ip_factor = 1 /
>> fabs(avctx->i_quant_factor);
>> >
>> >
>> > Instead of adding explicit checks here, why not make the file more
>> > consistent and use PARSE_X264_OPT for the things from the x4 context
>> > (like its already done for a bunch of other variables), and only use
>> > OPT_STR for the two special cases further down (without the check
>> > then)
>>
>> The behavior then won't be identical before and after the patch; e.g
>> the log portion of PARSE_X264_OPT is different from that of OPT_STR.
>> The current patch retains identical behavior. In particular, your
>> change does change the "user-facing" output slightly. Unless you (or
>> someone else) can confirm that it is irrelevant; I do not think your
>> proposal is good.
>
>
> How does it change? I don't think that's necessarily a terrible thing. If
> it's just cosmetic, we can live with it.

I clarified how it changes in the commit message for completeness - it
is just cosmetic. See updated patch.

>
> Ronald
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH] RFC: Automatic bitstream filtering

2015-10-06 Thread Rodger Combs 
This solves the problem discussed in 
https://ffmpeg.org/pipermail/ffmpeg-devel/2015-September/179238.html
by allowing AVCodec::write_header to be delayed until after packets have been
run through required bitstream filters in order to generate global extradata.

It also provides a mechanism by which a muxer can add a bitstream filter to a
stream automatically, rather than prompting the user to do so.

I'd like to split this into 4 commits:
- Moving av_apply_bitstream_filters from ffmpeg.c to its own API function
- Other lavf API changes
- Use of the new API in matroskaenc
- The minor style tweak in matroskaenc

There are a few other changes I think should be made before this is applied:
- Adding BSF arguments to AVBitStreamFilterContext rather than passing them
manually on each packet
- Providing an API to add a bitstream filter to an AVStream, rather than doing
so manually, and using it in check_bitstream
- Using said API in ffmpeg_opt.c and removing ffmpeg.c's own BSF handling
- Adding check_bitstream to other muxers that currently prompt the user to add
bitstream filters (such as aac_adtstoasc and h264_mpeg4toannexb). It could also
be used by e.g. movenc for generating the EAC3-specific atom.
---
 ffmpeg.c  | 45 --
 libavformat/avformat.h| 16 +++
 libavformat/matroskaenc.c | 22 -
 libavformat/mux.c | 25 +++-
 libavformat/utils.c   | 50 +++
 5 files changed, 115 insertions(+), 43 deletions(-)

diff --git a/ffmpeg.c b/ffmpeg.c
index e31a2c6..e6cd0e8 100644
--- a/ffmpeg.c
+++ b/ffmpeg.c
@@ -682,47 +682,10 @@ static void write_frame(AVFormatContext *s, AVPacket 
*pkt, OutputStream *ost)
 if (bsfc)
 av_packet_split_side_data(pkt);
 
-while (bsfc) {
-AVPacket new_pkt = *pkt;
-AVDictionaryEntry *bsf_arg = av_dict_get(ost->bsf_args,
- bsfc->filter->name,
- NULL, 0);
-int a = av_bitstream_filter_filter(bsfc, avctx,
-   bsf_arg ? bsf_arg->value : NULL,
-   _pkt.data, _pkt.size,
-   pkt->data, pkt->size,
-   pkt->flags & AV_PKT_FLAG_KEY);
-if(a == 0 && new_pkt.data != pkt->data) {
-uint8_t *t = av_malloc(new_pkt.size + 
AV_INPUT_BUFFER_PADDING_SIZE); //the new should be a subset of the old so 
cannot overflow
-if(t) {
-memcpy(t, new_pkt.data, new_pkt.size);
-memset(t + new_pkt.size, 0, AV_INPUT_BUFFER_PADDING_SIZE);
-new_pkt.data = t;
-new_pkt.buf = NULL;
-a = 1;
-} else
-a = AVERROR(ENOMEM);
-}
-if (a > 0) {
-pkt->side_data = NULL;
-pkt->side_data_elems = 0;
-av_free_packet(pkt);
-new_pkt.buf = av_buffer_create(new_pkt.data, new_pkt.size,
-   av_buffer_default_free, NULL, 0);
-if (!new_pkt.buf)
-exit_program(1);
-} else if (a < 0) {
-new_pkt = *pkt;
-av_log(NULL, AV_LOG_ERROR, "Failed to open bitstream filter %s for 
stream %d with codec %s",
-   bsfc->filter->name, pkt->stream_index,
-   avctx->codec ? avctx->codec->name : "copy");
-print_error("", a);
-if (exit_on_error)
-exit_program(1);
-}
-*pkt = new_pkt;
-
-bsfc = bsfc->next;
+if (ret = av_apply_bitstream_filters(s, pkt, bsfc, ost->bsf_args) < 0) {
+print_error("", ret);
+if (exit_on_error)
+exit_program(1);
 }
 
 if (!(s->oformat->flags & AVFMT_NOTIMESTAMPS)) {
diff --git a/libavformat/avformat.h b/libavformat/avformat.h
index e2a27d4..62807c4 100644
--- a/libavformat/avformat.h
+++ b/libavformat/avformat.h
@@ -598,6 +598,10 @@ typedef struct AVOutputFormat {
  */
 int (*free_device_capabilities)(struct AVFormatContext *s, struct 
AVDeviceCapabilitiesQuery *caps);
 enum AVCodecID data_codec; /**< default data codec */
+/**
+ * Check if a packet requires a bitstream filter. If so,
+ */
+int (*check_bitstream)(struct AVFormatContext *, const AVPacket *pkt);
 } AVOutputFormat;
 /**
  * @}
@@ -1167,6 +1171,14 @@ typedef struct AVStream {
 AVRational display_aspect_ratio;
 
 struct FFFrac *priv_pts;
+
+/**
+ * bitstream filter to run on stream
+ * - encoding: Set by muxer
+ * - decoding: unused
+ */
+int bitstream_checked;
+AVBitStreamFilterContext *bsfc;
 } AVStream;
 
 AVRational av_stream_get_r_frame_rate(const AVStream *s);
@@ -1782,6 +1794,8 @@ typedef struct AVFormatContext {
  * Demuxing: Set by

Re: [FFmpeg-devel] [PATCH] add CONTRIBUTING.md

2015-10-06 Thread Lou Logan 
On Tue, 6 Oct 2015 18:37:47 +0200, Stefano Sabatini wrote:

> If we keep CONTRIBUTING.md, better to make it independent from Github
> - that is I'm suggesting that we move all contributing indications to
> README.md, or we keep them in a separate file CONTRIBUTING.md, as
> proposed by this patch.
> 
> In case we adopt the second solution (which I'm fine with), then you
> could mention CONTRIBUTING.md in README.md and remove the
> corresponding section, since otherwise you're duplicating the
> information stated in README.md.

After looking at it again I decided to drop this patch. I don't really
like adding even more verbosity in yet another location for users to
(not) read; especially just to have a notice on the Github FFmpeg page.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] RFC: Automatic bitstream filtering

2015-10-06 Thread Ronald S. Bultje 
Hi,

On Tue, Oct 6, 2015 at 9:07 PM, Rodger Combs  wrote:

> This solves the problem discussed in
> https://ffmpeg.org/pipermail/ffmpeg-devel/2015-September/179238.html
> by allowing AVCodec::write_header to be delayed until after packets have
> been
> run through required bitstream filters in order to generate global
> extradata.
>
> It also provides a mechanism by which a muxer can add a bitstream filter
> to a
> stream automatically, rather than prompting the user to do so.


I think this is a wonderful idea - thanks!

Ronald
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH 2/2] ffplay: eliminate stream_component_close forward declaration

2015-10-06 Thread Marton Balint 
No change in fuctionality.

Signed-off-by: Marton Balint 
---
 ffplay.c | 116 +++
 1 file changed, 57 insertions(+), 59 deletions(-)

diff --git a/ffplay.c b/ffplay.c
index 7f73664..4a084b4 100644
--- a/ffplay.c
+++ b/ffplay.c
@@ -1132,7 +1132,63 @@ static void video_audio_display(VideoState *s)
 }
 }
 
-static void stream_component_close(VideoState *is, int stream_index);
+static void stream_component_close(VideoState *is, int stream_index)
+{
+AVFormatContext *ic = is->ic;
+AVCodecContext *avctx;
+
+if (stream_index < 0 || stream_index >= ic->nb_streams)
+return;
+avctx = ic->streams[stream_index]->codec;
+
+switch (avctx->codec_type) {
+case AVMEDIA_TYPE_AUDIO:
+decoder_abort(>auddec, >sampq);
+SDL_CloseAudio();
+decoder_destroy(>auddec);
+swr_free(>swr_ctx);
+av_freep(>audio_buf1);
+is->audio_buf1_size = 0;
+is->audio_buf = NULL;
+
+if (is->rdft) {
+av_rdft_end(is->rdft);
+av_freep(>rdft_data);
+is->rdft = NULL;
+is->rdft_bits = 0;
+}
+break;
+case AVMEDIA_TYPE_VIDEO:
+decoder_abort(>viddec, >pictq);
+decoder_destroy(>viddec);
+break;
+case AVMEDIA_TYPE_SUBTITLE:
+decoder_abort(>subdec, >subpq);
+decoder_destroy(>subdec);
+break;
+default:
+break;
+}
+
+ic->streams[stream_index]->discard = AVDISCARD_ALL;
+avcodec_close(avctx);
+switch (avctx->codec_type) {
+case AVMEDIA_TYPE_AUDIO:
+is->audio_st = NULL;
+is->audio_stream = -1;
+break;
+case AVMEDIA_TYPE_VIDEO:
+is->video_st = NULL;
+is->video_stream = -1;
+break;
+case AVMEDIA_TYPE_SUBTITLE:
+is->subtitle_st = NULL;
+is->subtitle_stream = -1;
+break;
+default:
+break;
+}
+}
 
 static void stream_close(VideoState *is)
 {
@@ -2737,64 +2793,6 @@ fail:
 return ret;
 }
 
-static void stream_component_close(VideoState *is, int stream_index)
-{
-AVFormatContext *ic = is->ic;
-AVCodecContext *avctx;
-
-if (stream_index < 0 || stream_index >= ic->nb_streams)
-return;
-avctx = ic->streams[stream_index]->codec;
-
-switch (avctx->codec_type) {
-case AVMEDIA_TYPE_AUDIO:
-decoder_abort(>auddec, >sampq);
-SDL_CloseAudio();
-decoder_destroy(>auddec);
-swr_free(>swr_ctx);
-av_freep(>audio_buf1);
-is->audio_buf1_size = 0;
-is->audio_buf = NULL;
-
-if (is->rdft) {
-av_rdft_end(is->rdft);
-av_freep(>rdft_data);
-is->rdft = NULL;
-is->rdft_bits = 0;
-}
-break;
-case AVMEDIA_TYPE_VIDEO:
-decoder_abort(>viddec, >pictq);
-decoder_destroy(>viddec);
-break;
-case AVMEDIA_TYPE_SUBTITLE:
-decoder_abort(>subdec, >subpq);
-decoder_destroy(>subdec);
-break;
-default:
-break;
-}
-
-ic->streams[stream_index]->discard = AVDISCARD_ALL;
-avcodec_close(avctx);
-switch (avctx->codec_type) {
-case AVMEDIA_TYPE_AUDIO:
-is->audio_st = NULL;
-is->audio_stream = -1;
-break;
-case AVMEDIA_TYPE_VIDEO:
-is->video_st = NULL;
-is->video_stream = -1;
-break;
-case AVMEDIA_TYPE_SUBTITLE:
-is->subtitle_st = NULL;
-is->subtitle_stream = -1;
-break;
-default:
-break;
-}
-}
-
 static int decode_interrupt_cb(void *ctx)
 {
 VideoState *is = ctx;
-- 
2.1.4

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH 1/2] ffplay: close streams and AVFormatContext in the main thread

2015-10-06 Thread Marton Balint 
To avoid race conditions.

Signed-off-by: Marton Balint 
---
 ffplay.c | 28 ++--
 1 file changed, 14 insertions(+), 14 deletions(-)

diff --git a/ffplay.c b/ffplay.c
index 79f430d..7f73664 100644
--- a/ffplay.c
+++ b/ffplay.c
@@ -1132,11 +1132,24 @@ static void video_audio_display(VideoState *s)
 }
 }
 
+static void stream_component_close(VideoState *is, int stream_index);
+
 static void stream_close(VideoState *is)
 {
 /* XXX: use a special url_shutdown call to abort parse cleanly */
 is->abort_request = 1;
 SDL_WaitThread(is->read_tid, NULL);
+
+/* close each stream */
+if (is->audio_stream >= 0)
+stream_component_close(is, is->audio_stream);
+if (is->video_stream >= 0)
+stream_component_close(is, is->video_stream);
+if (is->subtitle_stream >= 0)
+stream_component_close(is, is->subtitle_stream);
+
+avformat_close_input(>ic);
+
 packet_queue_destroy(>videoq);
 packet_queue_destroy(>audioq);
 packet_queue_destroy(>subtitleq);
@@ -3111,24 +3124,11 @@ static int read_thread(void *arg)
 av_free_packet(pkt);
 }
 }
-/* wait until the end */
-while (!is->abort_request) {
-SDL_Delay(100);
-}
 
 ret = 0;
  fail:
-/* close each stream */
-if (is->audio_stream >= 0)
-stream_component_close(is, is->audio_stream);
-if (is->video_stream >= 0)
-stream_component_close(is, is->video_stream);
-if (is->subtitle_stream >= 0)
-stream_component_close(is, is->subtitle_stream);
-if (ic) {
+if (ic && !is->ic)
 avformat_close_input();
-is->ic = NULL;
-}
 
 if (ret != 0) {
 SDL_Event event;
-- 
2.1.4

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] checkasm: add alacdsp tests

2015-10-06 Thread James Almer 
On 10/5/2015 5:08 PM, Henrik Gramner wrote:
> On Mon, Oct 5, 2015 at 12:50 AM, James Almer  wrote:
>> Signed-off-by: James Almer 
>> ---
>>  tests/checkasm/Makefile   |   1 +
>>  tests/checkasm/alacdsp.c  | 119 
>> ++
>>  tests/checkasm/checkasm.c |   3 ++
>>  tests/checkasm/checkasm.h |   1 +
>>  4 files changed, 124 insertions(+)
>>  create mode 100644 tests/checkasm/alacdsp.c
> 
> 
> Lgtm.

Pushed, thanks.

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCHv2] avfilter/buffersrc: add av_warn_unused_result attributes

2015-10-06 Thread Ganesh Ajjanagadde 
This adds av_warn_unused_result whenever it is relevant.

Signed-off-by: Ganesh Ajjanagadde 
---
 libavfilter/buffersrc.h | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/libavfilter/buffersrc.h b/libavfilter/buffersrc.h
index cd3d95f..847c093 100644
--- a/libavfilter/buffersrc.h
+++ b/libavfilter/buffersrc.h
@@ -78,6 +78,7 @@ unsigned av_buffersrc_get_nb_failed_requests(AVFilterContext 
*buffer_src);
  * This function is equivalent to av_buffersrc_add_frame_flags() with the
  * AV_BUFFERSRC_FLAG_KEEP_REF flag.
  */
+av_warn_unused_result
 int av_buffersrc_write_frame(AVFilterContext *ctx, const AVFrame *frame);
 
 /**
@@ -98,6 +99,7 @@ int av_buffersrc_write_frame(AVFilterContext *ctx, const 
AVFrame *frame);
  * This function is equivalent to av_buffersrc_add_frame_flags() without the
  * AV_BUFFERSRC_FLAG_KEEP_REF flag.
  */
+av_warn_unused_result
 int av_buffersrc_add_frame(AVFilterContext *ctx, AVFrame *frame);
 
 /**
@@ -115,6 +117,7 @@ int av_buffersrc_add_frame(AVFilterContext *ctx, AVFrame 
*frame);
  * @return>= 0 in case of success, a negative AVERROR code
  *in case of failure
  */
+av_warn_unused_result
 int av_buffersrc_add_frame_flags(AVFilterContext *buffer_src,
  AVFrame *frame, int flags);
 
-- 
2.6.1

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 2/2] x86/alacdsp: add simd optimized functions

2015-10-06 Thread James Almer 
On 10/6/2015 4:44 AM, Paul B Mahol wrote:
> On 10/6/15, James Almer  wrote:
>> On 10/5/2015 6:48 PM, Paul B Mahol wrote:
>>> On 10/4/15, James Almer  wrote:
 Signed-off-by: James Almer 
 ---
  libavcodec/alacdsp.c  |   3 +
  libavcodec/alacdsp.h  |   1 +
  libavcodec/x86/Makefile   |   2 +
  libavcodec/x86/alacdsp.asm| 133
 ++
  libavcodec/x86/alacdsp_init.c |  44 ++
  5 files changed, 183 insertions(+)
  create mode 100644 libavcodec/x86/alacdsp.asm
  create mode 100644 libavcodec/x86/alacdsp_init.c

>>>
>>> Have you measured speed gain?
>>
>> About three to four times faster than c.
> 
> I was more interested in overall gain.
> If fate covers this functions and fate still passes it should be fine imho.

Fate passes, so pushed. Thanks.

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH] w32pthreads: add pthread_once emulation

2015-10-06 Thread Hendrik Leppkes 
The emulation uses native InitOnce* APIs on Windows Vista+, and a
lock-free/allocation-free approach using atomics and spinning for Windows XP.
---

This is in preparation to use pthread_once for global static init functions,
and eventually removing the global lock in avcodec_open2

compat/w32pthreads.h | 68 
 1 file changed, 68 insertions(+)

diff --git a/compat/w32pthreads.h b/compat/w32pthreads.h
index deb1c53..8523976 100644
--- a/compat/w32pthreads.h
+++ b/compat/w32pthreads.h
@@ -154,6 +154,19 @@ static inline int pthread_cond_signal(pthread_cond_t *cond)
 return 0;
 }
 
+typedef INIT_ONCE pthread_once_t;
+#define PTHREAD_ONCE_INIT INIT_ONCE_STATIC_INIT
+
+static av_unused int pthread_once(pthread_once_t *once_control, void 
(*init_routine)(void))
+{
+BOOL pending = FALSE;
+InitOnceBeginInitialize(once_control, 0, , NULL);
+if (pending)
+init_routine();
+InitOnceComplete(once_control, 0, NULL);
+return 0;
+}
+
 #else // _WIN32_WINNT < 0x0600
 /* for pre-Windows 6.0 platforms we need to define and use our own condition
  * variable and api */
@@ -304,6 +317,57 @@ static av_unused int pthread_cond_signal(pthread_cond_t 
*cond)
 pthread_mutex_unlock(_cond->mtx_broadcast);
 return 0;
 }
+
+/* for pre-Windows 6.0 platforms, define INIT_ONCE struct,
+ * compatible to the one used in the native API */
+
+typedef union pthread_once_t  {
+void * Ptr;///< For the Windows 6.0+ native functions
+LONG state;///< For the pre-Windows 6.0 compat code
+} pthread_once_t;
+
+#define PTHREAD_ONCE_INIT {0}
+
+/* function pointers to init once API on windows 6.0+ kernels */
+static BOOL (WINAPI *initonce_begin)(pthread_once_t *lpInitOnce, DWORD 
dwFlags, BOOL *fPending, void **lpContext);
+static BOOL (WINAPI *initonce_complete)(pthread_once_t *lpInitOnce, DWORD 
dwFlags, void *lpContext);
+
+static av_unused int pthread_once(pthread_once_t *once_control, void 
(*init_routine)(void))
+{
+/* Use native functions on Windows 6.0+ */
+if (initonce_begin && initonce_complete)
+{
+BOOL pending = FALSE;
+initonce_begin(once_control, 0, , NULL);
+if (pending)
+init_routine();
+initonce_complete(once_control, 0, NULL);
+return 0;
+}
+
+/* pre-Windows 6.0 compat using a spin-lock */
+switch (InterlockedCompareExchange(_control->state, 1, 0))
+{
+/* Initial run */
+case 0:
+init_routine();
+InterlockedExchange(_control->state, 2);
+break;
+/* Another thread is running init */
+case 1:
+while (1) {
+MemoryBarrier();
+if (once_control->state == 2)
+break;
+Sleep(0);
+}
+break;
+/* Initialization complete */
+case 2:
+break;
+}
+return 0;
+}
 #endif
 
 static av_unused void w32thread_init(void)
@@ -319,6 +383,10 @@ static av_unused void w32thread_init(void)
 (void*)GetProcAddress(kernel_dll, "WakeConditionVariable");
 cond_wait  =
 (void*)GetProcAddress(kernel_dll, "SleepConditionVariableCS");
+initonce_begin =
+(void*)GetProcAddress(kernel_dll, "InitOnceBeginInitialize");
+initonce_complete =
+(void*)GetProcAddress(kernel_dll, "InitOnceComplete");
 #endif
 
 }
-- 
2.5.3.windows.1

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 1/3] lavfi/af_pan: check ff_all_channel_counts() return.

2015-10-06 Thread Ganesh Ajjanagadde 
On Tue, Oct 6, 2015 at 4:18 AM, Nicolas George  wrote:
> Fix CID 1325680.
>
> Signed-off-by: Nicolas George 
> ---
>  libavfilter/af_pan.c | 2 ++
>  1 file changed, 2 insertions(+)
>
>
> Will push this series soon unless somebody objects.

The 1000 line diff I posted should take care of this and all other
such unchecked stuff in query_formats across libavfilter :). I don't
mind either way, though if this is applied, I will perhaps need to
rebase my stuff to avoid merge conflicts. Really it is a question of
whether people want a single patch or multiple patches - note that
there are over 40 files that need cleanup.

>
>
> diff --git a/libavfilter/af_pan.c b/libavfilter/af_pan.c
> index 9117cc0..d116818 100644
> --- a/libavfilter/af_pan.c
> +++ b/libavfilter/af_pan.c
> @@ -239,6 +239,8 @@ static int query_formats(AVFilterContext *ctx)
>
>  // inlink supports any channel layout
>  layouts = ff_all_channel_counts();
> +if (!layouts)
> +return AVERROR(ENOMEM);
>  ff_channel_layouts_ref(layouts, >out_channel_layouts);
>
>  // outlink supports only requested output channel layout
> --
> 2.5.3
>
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH] vp9: don't keep a stack pointer if we don't need it.

2015-10-06 Thread Ronald S. Bultje 
This saves one register in a few cases on 32bit builds with unaligned
stack (e.g. MSVC), making the code slightly easier to maintain.

(Can someone please test this on 32bit+msvc and confirm make fate-vp9
and tests/checkasm/checkasm still work after this patch?)
---
 libavcodec/x86/vp9intrapred_16bpp.asm | 20 +---
 1 file changed, 5 insertions(+), 15 deletions(-)

diff --git a/libavcodec/x86/vp9intrapred_16bpp.asm 
b/libavcodec/x86/vp9intrapred_16bpp.asm
index 3653469..c0ac16d 100644
--- a/libavcodec/x86/vp9intrapred_16bpp.asm
+++ b/libavcodec/x86/vp9intrapred_16bpp.asm
@@ -601,7 +601,7 @@ cglobal vp9_ipred_tm_16x16_12, 4, 4, 8, dst, stride, l, a
 jmp mangle(private_prefix %+ _ %+ vp9_ipred_tm_16x16_10 %+ SUFFIX).body
 
 INIT_XMM sse2
-cglobal vp9_ipred_tm_32x32_10, 4, 4, 10, 32 * ARCH_X86_32, dst, stride, l, a
+cglobal vp9_ipred_tm_32x32_10, 4, 4, 10, 32 * -ARCH_X86_32, dst, stride, l, a
 movam0, [pw_1023]
 .body:
 pxorm1, m1
@@ -655,7 +655,7 @@ cglobal vp9_ipred_tm_32x32_10, 4, 4, 10, 32 * ARCH_X86_32, 
dst, stride, l, a
 jge .loop
 RET
 
-cglobal vp9_ipred_tm_32x32_12, 4, 4, 10, 32 * ARCH_X86_32, dst, stride, l, a
+cglobal vp9_ipred_tm_32x32_12, 4, 4, 10, 32 * -ARCH_X86_32, dst, stride, l, a
 movam0, [pw_4095]
 jmp mangle(private_prefix %+ _ %+ vp9_ipred_tm_32x32_10 %+ SUFFIX).body
 
@@ -945,7 +945,7 @@ cglobal vp9_ipred_dr_16x16_16, 4, 4, 7, dst, stride, l, a
 RET
 
 cglobal vp9_ipred_dr_32x32_16, 4, 5, 10 + notcpuflag(ssse3), \
-   %1 * ARCH_X86_32 * mmsize, dst, stride, l, a
+   %1 * ARCH_X86_32 * -mmsize, dst, stride, l, a
 movam0, [aq+mmsize*3]   ; a[24-31]
 movum1, [aq+mmsize*3-2] ; a[23-30]
 psrldq  m2, m0, 2   ; a[25-31].
@@ -1634,13 +1634,8 @@ cglobal vp9_ipred_hu_16x16_16, 3, 4, 6 + 
notcpuflag(ssse3), dst, stride, l, a
 jg .loop
 RET
 
-%if ARCH_X86_64 || HAVE_ALIGNED_STACK
 cglobal vp9_ipred_hu_32x32_16, 3, 7, 10 + notcpuflag(ssse3), \
-   %1 * mmsize * ARCH_X86_32, dst, stride, l, a
-%else
-cglobal vp9_ipred_hu_32x32_16, 3, 6, 10 + notcpuflag(ssse3), \
-   %1 * mmsize * ARCH_X86_32, dst, stride, l, a
-%endif
+   %1 * -mmsize * ARCH_X86_32, dst, stride, l, a
 movam2, [lq+mmsize*0+0]
 movum1, [lq+mmsize*0+2]
 movum0, [lq+mmsize*0+4]
@@ -1671,12 +1666,7 @@ cglobal vp9_ipred_hu_32x32_16, 3, 6, 10 + 
notcpuflag(ssse3), \
 SBUTTERFLY   wd, 7,  6,  0
 pshufd  m1, m1, q
 UNSCRATCH0,  9, rsp+1*mmsize
-%if ARCH_X86_64 || HAVE_ALIGNED_STACK
 DEFINE_ARGS dst, stride, cnt, stride3, stride4, stride20, stride28
-%else
-DEFINE_ARGS dst, stride, stride3, stride4, stride20, stride28
-%define cntd dword r0m
-%endif
 lea   stride3q, [strideq*3]
 lea   stride4q, [strideq*4]
 lea  stride28q, [stride4q*8]
@@ -1902,7 +1892,7 @@ cglobal vp9_ipred_hd_16x16_16, 4, 4, 8, dst, stride, l, a
 RET
 
 cglobal vp9_ipred_hd_32x32_16, 4, 4 + 3 * ARCH_X86_64, 14, \
-   10 * mmsize * ARCH_X86_32, dst, stride, l, a
+   10 * -mmsize * ARCH_X86_32, dst, stride, l, a
 movam2, [lq+mmsize*0+0]
 movum1, [lq+mmsize*0+2]
 movum0, [lq+mmsize*0+4]
-- 
2.1.2

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] vp9: don't keep a stack pointer if we don't need it.

2015-10-06 Thread Hendrik Leppkes 
On Tue, Oct 6, 2015 at 2:38 PM, Ronald S. Bultje  wrote:
> This saves one register in a few cases on 32bit builds with unaligned
> stack (e.g. MSVC), making the code slightly easier to maintain.
>
> (Can someone please test this on 32bit+msvc and confirm make fate-vp9
> and tests/checkasm/checkasm still work after this patch?)

FATE still passes on MSVC 32-bit.

- Hendrik
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] avfilter/buffersrc: add av_warn_unused_result attributes

2015-10-06 Thread Ronald S. Bultje 
Hi,

On Tue, Oct 6, 2015 at 4:01 AM, Nicolas George  wrote:

> Le quartidi 14 vendémiaire, an CCXXIV, Ganesh Ajjanagadde a écrit :
> > This adds av_warn_unused_result whenever it is relevant.
> >
> > Signed-off-by: Ganesh Ajjanagadde 
> > ---
> >  libavfilter/buffersrc.h | 6 +++---
> >  1 file changed, 3 insertions(+), 3 deletions(-)
>
> I do not have much of an opinion about this. It looks right in principle,
> but warnings sometimes have unexpected advert effects.


Let's keep an eye out for where we want to apply it. I think these specific
ones are OK.


> > -int av_buffersrc_add_frame_flags(AVFilterContext *buffer_src,
> > +av_warn_unused_result int av_buffersrc_add_frame_flags(AVFilterContext
> *buffer_src,
> >   AVFrame *frame, int flags);
>
> It is a bit sad to break alignment, though. I would slightly prefer having
> the long attribute on a line by itself:
>
> av_warn_unused_result
> int av_yada_yada_yada(argu *ments);
>
> ... if people are ok with it too. Otherwise, reindenting with the same
> commit seems acceptable in this case.


I think we use the "previous line" approach for e.g. deprecations also, so
it sounds fine with me.

(Otherwise patch OK with me.)

Ronald
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] avfilter/buffersrc: add av_warn_unused_result attributes

2015-10-06 Thread Ganesh Ajjanagadde 
On Tue, Oct 6, 2015 at 4:01 AM, Nicolas George  wrote:
> Le quartidi 14 vendémiaire, an CCXXIV, Ganesh Ajjanagadde a écrit :
>> This adds av_warn_unused_result whenever it is relevant.
>>
>> Signed-off-by: Ganesh Ajjanagadde 
>> ---
>>  libavfilter/buffersrc.h | 6 +++---
>>  1 file changed, 3 insertions(+), 3 deletions(-)
>
> I do not have much of an opinion about this. It looks right in principle,
> but warnings sometimes have unexpected advert effects.

It is possible, but at the moment there are only a few warnings
(ffmpeg.c IIRC) that get triggered, and all are stuff that needs to be
cleaned up. Also, at the moment given the documentation, any unchecked
usage should be cleaned up IMHO. We could revisit this in the future
if there are adverse effects; I don't think attributes break user's
code (unless they have -Werror, in which case as pointed above they
need to fix it).

>
>> -int av_buffersrc_add_frame_flags(AVFilterContext *buffer_src,
>> +av_warn_unused_result int av_buffersrc_add_frame_flags(AVFilterContext 
>> *buffer_src,
>>   AVFrame *frame, int flags);
>
> It is a bit sad to break alignment, though. I would slightly prefer having
> the long attribute on a line by itself:
>
> av_warn_unused_result
> int av_yada_yada_yada(argu *ments);
>
> ... if people are ok with it too. Otherwise, reindenting with the same
> commit seems acceptable in this case.

Missed this cosmetic aspect, will change.

>
> Regards,
>
> --
>   Nicolas George
>
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH] vp9: add 10/12bpp mmxext-optimized iwht_iwht_4x4 function.

2015-10-06 Thread Ronald S. Bultje 
---
 libavcodec/x86/Makefile |   1 +
 libavcodec/x86/vp9dsp_init.c|   4 +-
 libavcodec/x86/vp9dsp_init.h|  15 ++--
 libavcodec/x86/vp9dsp_init_16bpp_template.c |  14 +++-
 libavcodec/x86/vp9itxfm.asm |  16 +
 libavcodec/x86/vp9itxfm_16bpp.asm   | 108 
 libavcodec/x86/vp9itxfm_template.asm|  37 ++
 7 files changed, 173 insertions(+), 22 deletions(-)
 create mode 100644 libavcodec/x86/vp9itxfm_16bpp.asm
 create mode 100644 libavcodec/x86/vp9itxfm_template.asm

diff --git a/libavcodec/x86/Makefile b/libavcodec/x86/Makefile
index 5ff3a77..c87bc65 100644
--- a/libavcodec/x86/Makefile
+++ b/libavcodec/x86/Makefile
@@ -160,6 +160,7 @@ YASM-OBJS-$(CONFIG_VP6_DECODER)+= x86/vp6dsp.o
 YASM-OBJS-$(CONFIG_VP9_DECODER)+= x86/vp9intrapred.o\
   x86/vp9intrapred_16bpp.o  \
   x86/vp9itxfm.o\
+  x86/vp9itxfm_16bpp.o  \
   x86/vp9lpf.o  \
   x86/vp9lpf_16bpp.o\
   x86/vp9mc.o   \
diff --git a/libavcodec/x86/vp9dsp_init.c b/libavcodec/x86/vp9dsp_init.c
index cd4af99..2347a47 100644
--- a/libavcodec/x86/vp9dsp_init.c
+++ b/libavcodec/x86/vp9dsp_init.c
@@ -216,10 +216,10 @@ av_cold void ff_vp9dsp_init_x86(VP9DSPContext *dsp, int 
bpp, int bitexact)
 int cpu_flags;
 
 if (bpp == 10) {
-ff_vp9dsp_init_10bpp_x86(dsp);
+ff_vp9dsp_init_10bpp_x86(dsp, bitexact);
 return;
 } else if (bpp == 12) {
-ff_vp9dsp_init_12bpp_x86(dsp);
+ff_vp9dsp_init_12bpp_x86(dsp, bitexact);
 return;
 }
 
diff --git a/libavcodec/x86/vp9dsp_init.h b/libavcodec/x86/vp9dsp_init.h
index 5842282..5d07b62 100644
--- a/libavcodec/x86/vp9dsp_init.h
+++ b/libavcodec/x86/vp9dsp_init.h
@@ -25,6 +25,9 @@
 
 #include "libavcodec/vp9dsp.h"
 
+// hack to force-expand BPC
+#define cat(a, bpp, b) a##bpp##b
+
 #define decl_fpel_func(avg, sz, bpp, opt) \
 void ff_vp9_##avg##sz##bpp##_##opt(uint8_t *dst, ptrdiff_t dst_stride, \
const uint8_t *src, ptrdiff_t src_stride, \
@@ -53,6 +56,12 @@ decl_ipred_fn(type,  8, bpp, opt8_16_32); \
 decl_ipred_fn(type, 16, bpp, opt8_16_32); \
 decl_ipred_fn(type, 32, bpp, opt8_16_32)
 
+#define decl_itxfm_func(typea, typeb, size, bpp, opt) \
+void cat(ff_vp9_##typea##_##typeb##_##size##x##size##_add_, bpp, 
_##opt)(uint8_t *dst, \
+ 
ptrdiff_t stride, \
+ 
int16_t *block, \
+ int 
eob)
+
 #define mc_rep_func(avg, sz, hsz, hszb, dir, opt, type, f_sz, bpp) \
 static av_always_inline void \
 ff_vp9_##avg##_8tap_1d_##dir##_##sz##_##bpp##_##opt(uint8_t *dst, ptrdiff_t 
dst_stride, \
@@ -154,8 +163,6 @@ filters_8tap_2d_fn(op, 4, align, bpp, bytes, opt4, f_opt)
 init_subpel3_8to64(idx, type, bpp, opt); \
 init_subpel2(4, idx,  4, type, bpp, opt)
 
-#define cat(a, bpp, b) a##bpp##b
-
 #define init_ipred_func(type, enum, sz, bpp, opt) \
 dsp->intra_pred[TX_##sz##X##sz][enum##_PRED] = \
 cat(ff_vp9_ipred_##type##_##sz##x##sz##_, bpp, _##opt)
@@ -169,8 +176,8 @@ filters_8tap_2d_fn(op, 4, align, bpp, bytes, opt4, f_opt)
 init_ipred_func(type, enum,  4, bpp, opt); \
 init_8_16_32_ipred_funcs(type, enum, bpp, opt)
 
-void ff_vp9dsp_init_10bpp_x86(VP9DSPContext *dsp);
-void ff_vp9dsp_init_12bpp_x86(VP9DSPContext *dsp);
+void ff_vp9dsp_init_10bpp_x86(VP9DSPContext *dsp, int bitexact);
+void ff_vp9dsp_init_12bpp_x86(VP9DSPContext *dsp, int bitexact);
 void ff_vp9dsp_init_16bpp_x86(VP9DSPContext *dsp);
 
 #endif /* AVCODEC_X86_VP9DSP_INIT_H */
diff --git a/libavcodec/x86/vp9dsp_init_16bpp_template.c 
b/libavcodec/x86/vp9dsp_init_16bpp_template.c
index f486caf..4983a2d 100644
--- a/libavcodec/x86/vp9dsp_init_16bpp_template.c
+++ b/libavcodec/x86/vp9dsp_init_16bpp_template.c
@@ -123,9 +123,11 @@ lpf_mix2_wrappers_set(BPC, ssse3);
 lpf_mix2_wrappers_set(BPC, avx);
 
 decl_ipred_fns(tm, BPC, mmxext, sse2);
+
+decl_itxfm_func(iwht, iwht, 4, BPC, mmxext);
 #endif /* HAVE_YASM */
 
-av_cold void INIT_FUNC(VP9DSPContext *dsp)
+av_cold void INIT_FUNC(VP9DSPContext *dsp, int bitexact)
 {
 #if HAVE_YASM
 int cpu_flags = av_get_cpu_flags();
@@ -155,8 +157,18 @@ av_cold void INIT_FUNC(VP9DSPContext *dsp)
 init_lpf_mix2_func(1, 0, 1, v, 8, 4, bpp, opt); \
 init_lpf_mix2_func(1, 1, 1, v, 8, 8, bpp, opt)
 
+#define init_itx_func(idxa, idxb, typea, typeb, size, bpp, opt) \
+dsp->itxfm_add[idxa][idxb] = \
+

Re: [FFmpeg-devel] [PATCH 1/2] avfilter/all: propagate errors of functions from avfilter/formats

2015-10-06 Thread Ronald S. Bultje 
Hello,

On Mon, Oct 5, 2015 at 3:43 PM, Ganesh Ajjanagadde  wrote:

> Hi,
>
> I have attached the patch.


>  // inlink supports any channel layout
>  layouts = ff_all_channel_counts();
> -ff_channel_layouts_ref(layouts, >out_channel_layouts);
> +if (!layouts)
> +return AVERROR(ENOMEM);
> +if ((ret = ff_channel_layouts_ref(layouts,
>out_channel_layouts)) < 0) {
> +ff_channel_layouts_unref();
> +return ret;
> +}

I already feel fully inadequate to review this patch :-D. But this looks
weird. My proposal is that someone familiar with avfilter review this.
Nicolas, Clement, Stefano, Michael, Paul, (I probably forgot some people,)
can one of you volunteer?

Ronald
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] Closing down the ABI again

2015-10-06 Thread Hendrik Leppkes 
Hey,

Libav is talking about closing the change window and stabilizing the
ABI, and I think we should follow suit. Its been a good couple of
weeks since the ABI bump, and should have given everyone ample time to
get their changes in.

Does anyone still have any ABI-relevant changes they want to perform
before this happens?
It'll probably remain open ABI season for another week or so, unless
pressing reasons require otherwise.

- Hendrik
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] Add space after commas in HTTP/RTSP auth header

2015-10-06 Thread Calvin Walton 
On Thu, 2015-10-01 at 13:56 +0300, Andrey Utkin wrote:
> This fixes access to Grandstream cameras, which return 401 to ffmpeg
> otherwise.
> VLC sends Authorization: header with spaces between parameters, and
> it
> is known to work with Grandstream devices and broad range of other
> HTTP
> and RTSP servers, so author considers switching to such behaviour
> safe.
> Just for record - RFC 2617 (HTTP Auth) does not specify the need in
> spaces, so this is not a bug of FFmpeg.

For those curious about the updated versions of the HTTP/1.1 specs, the
current HTTP Auth RFC 7235 uses the # (list) ABNF from RFC 7230 section
7, which specifies the separator as "," surrounded by OWS (optional
whitespace). Section 3.2.3 says:

   The OWS rule is used where zero or more linear whitespace octets
   might appear.  For protocol elements where optional whitespace is
   preferred to improve readability, a sender SHOULD generate the
   optional whitespace as a single SP; otherwise, a sender SHOULD NOT
   generate optional whitespace except as needed to white out invalid or
   unwanted protocol elements during in-place message filtering.

So in this case, using ", " as the separator appears to be preferred
but not required by the RFCs. But it certainly doesn't require that the
space is present! I agree that this isn't really an FFmpeg bug, but
 switching to use ", " is probably a good idea regardless.

-- 
Calvin Walton 

___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] README: replace http with https

2015-10-06 Thread Michael Niedermayer 
On Mon, Oct 05, 2015 at 11:39:08PM -0400, Ganesh Ajjanagadde wrote:
> Signed-off-by: Ganesh Ajjanagadde 
> ---
>  README.md | 12 ++--
>  1 file changed, 6 insertions(+), 6 deletions(-)

applied

thanks

[...]
-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

I have often repented speaking, but never of holding my tongue.
-- Xenocrates


signature.asc
Description: Digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 1/3] lavfi/af_pan: check ff_all_channel_counts() return.

2015-10-06 Thread Nicolas George 
Le quintidi 15 vendémiaire, an CCXXIV, Ganesh Ajjanagadde a écrit :
> The 1000 line diff I posted should take care of this and all other
> such unchecked stuff in query_formats across libavfilter :). I don't
> mind either way, though if this is applied, I will perhaps need to
> rebase my stuff to avoid merge conflicts. Really it is a question of
> whether people want a single patch or multiple patches - note that
> there are over 40 files that need cleanup.

I had your patch in my inbox to review the parts that I maintain, along with
the new Coverity report. I just looked at it: it is more complete than these
three patches, and I would not cause you extra work with conflicts, so from
my point of view, please go ahead.

It would probably be better if the commit message contains the CID numbers:
at least 1325679 and 1325680, but that is rather minor.

Thanks for your efforts.

Regards,

-- 
  Nicolas George


signature.asc
Description: Digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] lavf/mov: add support for sidx fragment indexes

2015-10-06 Thread Michael Niedermayer 
On Tue, Oct 06, 2015 at 03:50:23AM -0500, Rodger Combs wrote:
> Fixes trac #3842
> ---
>  libavformat/isom.h |   2 +
>  libavformat/mov.c  | 245 
> -
>  2 files changed, 208 insertions(+), 39 deletions(-)

i think this should be applied unless someone has more comments

[...]
-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

If you think the mosad wants you dead since a long time then you are either
wrong or dead since a long time.


signature.asc
Description: Digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] add CONTRIBUTING.md

2015-10-06 Thread Lou Logan 
On Tue, Oct 6, 2015, at 07:07 AM, Stefano Sabatini wrote:
> 
> I wonder if adding the contents to README.md is not a better choice
> 
> Note also since we're writing about github, that the README.md will
> have a better visibility there, since it is shown on the project main
> page:
> https://github.com/FFmpeg/FFmpeg

I forgot to mention that main reason for making this is to address this:

https://github.com/FFmpeg/FFmpeg/pull/153

README.md is already displayed on the Github page, but CONTRIBUTING.md
should add a notification banner as shown in the link above. The idea is
to attempt to reduce the number of Github pull requests since the vast
majority of us don't pay attention to them.

If you prefer I can remove everything but the "Note to Github Users" and
then mention they should refer to README.md for more info.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] add CONTRIBUTING.md

2015-10-06 Thread Stefano Sabatini 
On date Tuesday 2015-10-06 08:20:11 -0800, Lou Logan encoded:
> On Tue, Oct 6, 2015, at 07:07 AM, Stefano Sabatini wrote:
> > 
> > I wonder if adding the contents to README.md is not a better choice
> > 
> > Note also since we're writing about github, that the README.md will
> > have a better visibility there, since it is shown on the project main
> > page:
> > https://github.com/FFmpeg/FFmpeg
> 
> I forgot to mention that main reason for making this is to address this:
> 
> https://github.com/FFmpeg/FFmpeg/pull/153
> 
> README.md is already displayed on the Github page, but CONTRIBUTING.md
> should add a notification banner as shown in the link above. The idea is
> to attempt to reduce the number of Github pull requests since the vast
> majority of us don't pay attention to them.

Makes sense. 

> If you prefer I can remove everything but the "Note to Github Users" and
> then mention they should refer to README.md for more info.

If we keep CONTRIBUTING.md, better to make it independent from Github
- that is I'm suggesting that we move all contributing indications to
README.md, or we keep them in a separate file CONTRIBUTING.md, as
proposed by this patch.

In case we adopt the second solution (which I'm fine with), then you
could mention CONTRIBUTING.md in README.md and remove the
corresponding section, since otherwise you're duplicating the
information stated in README.md.
-- 
FFmpeg = Frenzy & Frenzy Mean Power Empowered Gem
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] Closing down the ABI again

2015-10-06 Thread Hendrik Leppkes 
On Tue, Oct 6, 2015 at 6:48 PM, Ganesh Ajjanagadde  wrote:
> On Tue, Oct 6, 2015 at 9:42 AM, Hendrik Leppkes  wrote:
>> Hey,
>>
>> Libav is talking about closing the change window and stabilizing the
>> ABI, and I think we should follow suit. Its been a good couple of
>> weeks since the ABI bump, and should have given everyone ample time to
>> get their changes in.
>>
>> Does anyone still have any ABI-relevant changes they want to perform
>> before this happens?
>> It'll probably remain open ABI season for another week or so, unless
>> pressing reasons require otherwise.
>
> I don't personally care about this, but maybe since
> http://ffmpeg.org/pipermail/ffmpeg-devel/2015-September/179537.html
> was applied, we can get rid of the deprecated function?
>

Thats an API change, not ABI, and all API changes and deprecation
removals have been performed during the bump already.

- Hendrik
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] modify ffplay for dumpstream in rtsp?

2015-10-06 Thread Stefano Sabatini 
On date Tuesday 2015-10-06 11:27:31 -0400, compn encoded:
> On Tue, 6 Oct 2015 10:50:30 -0400
> compn  wrote:
> 
> > On Sun, 4 Oct 2015 18:37:31 +0200
> > Nicolas George  wrote:
> > 
> > > Le duodi 12 vendémiaire, an CCXXIV, compn a écrit :
> > > > he wants to play and dump at the same time. like vlc can. 
> > > > 
> > > > should this functionality be added to ffmpeg or ffplay?
> > > 
> > > ffmpeg can already display video on the fly, with the opengl, xv and
> > > sdl devices.
> > 
> > maybe we could make an example in the docs specifying how to do this.
> 
> oops, i see it in the bottom of xv outdev
> https://ffmpeg.org/ffmpeg-devices.html#Examples-14
> 
> > 
> > this works for me:
> > 
> > ffmpeg -i http://samples.ffmpeg.org/V-codecs/sn40sample.avi -i
> > http://samples.ffmpeg.org/V-codecs/sn40sample.avi -f sdl out.mp4 
> > 
> > is there a way to just use a single input to dump 1 file and display 1
> > sdl output? hmm, probably.
> 

> i didnt realize that "display" (as in -f sdl display) was an option i
> needed to pass. its not listed anywhere else in the documentation or
> options afaict. i thought it was referring to xv's "display_name"
> subopt.
> 
> should i send a patch to add the "display" option to each outdev
> documentation indicating this feature?

"display" is the output filename, and is required for each
output. There is no way to skip the output filename.
-- 
FFmpeg = Frenzy & Funny Magic Programmable Evil Guru
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] vp9: add 10/12bpp mmxext-optimized iwht_iwht_4x4 function.

2015-10-06 Thread Henrik Gramner 
On Tue, Oct 6, 2015 at 3:43 PM, Ronald S. Bultje  wrote:
> ---
>  libavcodec/x86/Makefile |   1 +
>  libavcodec/x86/vp9dsp_init.c|   4 +-
>  libavcodec/x86/vp9dsp_init.h|  15 ++--
>  libavcodec/x86/vp9dsp_init_16bpp_template.c |  14 +++-
>  libavcodec/x86/vp9itxfm.asm |  16 +
>  libavcodec/x86/vp9itxfm_16bpp.asm   | 108 
> 
>  libavcodec/x86/vp9itxfm_template.asm|  37 ++
>  7 files changed, 173 insertions(+), 22 deletions(-)
>  create mode 100644 libavcodec/x86/vp9itxfm_16bpp.asm
>  create mode 100644 libavcodec/x86/vp9itxfm_template.asm

Did you look into using SSE2 instead? That would eliminate
instructions in some parts but might make other parts more complex.
Note that some MMX instructions only has half the throughput of
equivalent SSE/AVX ones in Skylake (and most likely future Intel
µarchs as well).
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 1/2] avfilter/all: propagate errors of functions from avfilter/formats

2015-10-06 Thread Ganesh Ajjanagadde 
On Tue, Oct 6, 2015 at 10:40 AM, Nicolas George  wrote:
> Le quartidi 14 vendémiaire, an CCXXIV, Ganesh Ajjanagadde a écrit :
>> -ff_channel_layouts_ref(layouts, >out_channel_layouts);
>> +if (!layouts)
>> +return AVERROR(ENOMEM);
>> +if ((ret = ff_channel_layouts_ref(layouts, 
>> >out_channel_layouts)) < 0) {
>> +ff_channel_layouts_unref();
>> +return ret;
>
> This is a pattern that comes frequently, there is probably room for code
> factorization.
>
> How about this: currently, ff_formats_ref() and cousins reject NULL with
> AVERROR_BUG. If it is changed to return AVERROR(ENOMEM) instead, then all
> the "if (!formats) return AVERROR(ENOMEM);" become unnecessary.
>
> Second, if ff_formats_ref() is changed to unref the format list on failure,
> then all the unref become unnecessary. The changed code would be just:
>
>  layouts = ff_all_channel_counts();
> -ff_channel_layouts_ref(layouts, >out_channel_layouts);
> +if ((ret = ff_channel_layouts_ref(layouts, 
> >out_channel_layouts)) < 0)
> +return ret;
>
> That is rather less cluttered.
>
> What do you think about this?

That is a good idea. I had some similar ideas, but did not implement
them as I am not a avfilter expert, and did not know whether changing
the behavior of ff_formats_ref and the like would be acceptable.

I can do the necessary refactoring, but please bear in mind that I am
busy over the next few days. Depending on the criticality of this (and
the relevant CID's), one of you can go ahead and refactor in the best
way possible. In fact, it could lead to less wasted effort overall due
to the better expertise with libavfilter.

>
> Regards,
>
> --
>   Nicolas George
>
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] Closing down the ABI again

2015-10-06 Thread Ganesh Ajjanagadde 
On Tue, Oct 6, 2015 at 9:42 AM, Hendrik Leppkes  wrote:
> Hey,
>
> Libav is talking about closing the change window and stabilizing the
> ABI, and I think we should follow suit. Its been a good couple of
> weeks since the ABI bump, and should have given everyone ample time to
> get their changes in.
>
> Does anyone still have any ABI-relevant changes they want to perform
> before this happens?
> It'll probably remain open ABI season for another week or so, unless
> pressing reasons require otherwise.

I don't personally care about this, but maybe since
http://ffmpeg.org/pipermail/ffmpeg-devel/2015-September/179537.html
was applied, we can get rid of the deprecated function?

>
> - Hendrik
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] videotoolbox: allow to enable the async decoding.

2015-10-06 Thread Clément Bœsch 
On Thu, Sep 24, 2015 at 11:45:42AM +0200, Clément Bœsch wrote:
> On Sun, Aug 09, 2015 at 01:11:44PM +0200, Sebastien Zwickert wrote:
> > This patch allows to use the Videotoolbox API in asynchonous mode.
> > Note that when using async decoding the user is responsible for
> > releasing the async frame.
> > Moreover, an option called videotoolbox_async was added to enable
> > async decoding with ffmpeg CLI.
> > 
> > ---
> >  ffmpeg.h  |   1 +
> >  ffmpeg_opt.c  |   1 +
> >  ffmpeg_videotoolbox.c |  69 +
> >  libavcodec/videotoolbox.c | 186 
> > --
> >  libavcodec/videotoolbox.h |  73 ++
> >  5 files changed, 294 insertions(+), 36 deletions(-)
> > 
> 
> Ping and more comments on this:
> 
> - is it meaningful to have a limit on the internal queue size (for memory
>   load for instance), or it's not relevant in case of hw accel?
> 

To answer myself: a limit is actually required or it causes a crash at
least on iOS after about 150 frames in the queue.

Following is a hack I needed:

diff --git a/libavcodec/videotoolbox.c b/libavcodec/videotoolbox.c
index 9664f16..73b9023 100644
--- a/libavcodec/videotoolbox.c
+++ b/libavcodec/videotoolbox.c
@@ -222,6 +222,8 @@ static void videotoolbox_clear_queue(struct 
AVVideotoolboxContext *videotoolbox)
 av_videotoolbox_release_async_frame(top_frame);
 }
 
+videotoolbox->nb_frames = 0;
+
 videotoolbox_lock_operation(>queue_mutex, AV_LOCK_RELEASE);
 }
 
@@ -379,6 +381,9 @@ static void videotoolbox_decoder_callback(void *opaque,
 
 videotoolbox_lock_operation(>queue_mutex, 
AV_LOCK_OBTAIN);
 
+while (videotoolbox->nb_frames == 16)
+pthread_cond_wait(>queue_reduce, 
videotoolbox->queue_mutex);
+
 queue_walker = videotoolbox->queue;
 
 if (!queue_walker || (new_frame->pts < queue_walker->pts)) {
@@ -401,6 +406,7 @@ static void videotoolbox_decoder_callback(void *opaque,
 }
 }
 
+videotoolbox->nb_frames++;
 videotoolbox_lock_operation(>queue_mutex, 
AV_LOCK_RELEASE);
 }
 }
@@ -617,6 +623,8 @@ static int videotoolbox_default_init(AVCodecContext *avctx)
 return -1;
 
 videotoolbox_lock_operation(>queue_mutex, 
AV_LOCK_CREATE);
+
+pthread_cond_init(>queue_reduce, NULL);
 }
 
 switch( avctx->codec_id ) {
@@ -700,6 +708,8 @@ static void videotoolbox_default_free(AVCodecContext *avctx)
 
 videotoolbox_clear_queue(videotoolbox);
 
+pthread_cond_destroy(>queue_reduce);
+
 if (videotoolbox->queue_mutex != NULL)
 videotoolbox_lock_operation(>queue_mutex, 
AV_LOCK_DESTROY);
 }
@@ -826,8 +836,11 @@ AVVideotoolboxAsyncFrame 
*av_videotoolbox_pop_async_frame(AVVideotoolboxContext
 videotoolbox_lock_operation(>queue_mutex, AV_LOCK_OBTAIN);
 top_frame = videotoolbox->queue;
 videotoolbox->queue = top_frame->next_frame;
+videotoolbox->nb_frames--;
 videotoolbox_lock_operation(>queue_mutex, AV_LOCK_RELEASE);
 
+pthread_cond_signal(>queue_reduce);
+
 return top_frame;
 }
 
diff --git a/libavcodec/videotoolbox.h b/libavcodec/videotoolbox.h
index b5bf030..db41b4a 100644
--- a/libavcodec/videotoolbox.h
+++ b/libavcodec/videotoolbox.h
@@ -113,6 +113,9 @@ typedef struct AVVideotoolboxContext {
  */
 void *queue_mutex;
 
+pthread_cond_t queue_reduce;
+int nb_frames;
+
 } AVVideotoolboxContext;
 
 /**


> - isn't it missing a flush mechanism so seeking can be accurate?

videotoolbox_clear_queue() should probably be exported

[...]

But again all of this is more in the spirit of a proper async API...

BTW, I can confirm it fixes the playback speed on these devices.

-- 
Clément B.


signature.asc
Description: PGP signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel