Re: [FFmpeg-devel] [PATCH 2/2] x86/vf_w3fdif: simplify w3fdif_simple_high

[Paul B Mahol]

On 10/11/15, James Almer  wrote:
> Signed-off-by: James Almer 
> ---
>  libavfilter/x86/vf_w3fdif.asm | 16 +++-
>  1 file changed, 7 insertions(+), 9 deletions(-)
>
> diff --git a/libavfilter/x86/vf_w3fdif.asm b/libavfilter/x86/vf_w3fdif.asm
> index f02319b..f2001a4 100644
> --- a/libavfilter/x86/vf_w3fdif.asm
> +++ b/libavfilter/x86/vf_w3fdif.asm
> @@ -103,13 +103,11 @@ REP_RET
>
>  %if ARCH_X86_64
>
> -cglobal w3fdif_simple_high, 5, 9, 9, 0, work_line, in_lines_cur0,
> in_lines_adj0, coef, linesize
> +cglobal w3fdif_simple_high, 5, 9, 8, 0, work_line, in_lines_cur0,
> in_lines_adj0, coef, linesize
>  movq  m2, [coefq]
>  DEFINE_ARGSwork_line, in_lines_cur0, in_lines_adj0, in_lines_cur1,
> linesize, offset, in_lines_cur2, in_lines_adj1, in_lines_adj2
> -SPLATWm0, m2, 0
> -SPLATWm1, m2, 1
> +pshufdm0, m2, q
>  SPLATWm2, m2, 2
> -SBUTTERFLYwd, 0, 1, 7
>  pxor  m7, m7
>  mov  offsetq, 0
>  mov   in_lines_cur2q, [in_lines_cur0q+gprsize*2]
> @@ -124,23 +122,23 @@ cglobal w3fdif_simple_high, 5, 9, 9, 0, work_line,
> in_lines_cur0, in_lines_adj0,
>  movh   m4, [in_lines_cur1q+offsetq]
>  punpcklbw  m3, m7
>  punpcklbw  m4, m7
> -SBUTTERFLY wd, 3, 4, 8
> +SBUTTERFLY wd, 3, 4, 1
>  pmaddwdm3, m0
> -pmaddwdm4, m1
> +pmaddwdm4, m0
>  movh   m5, [in_lines_adj0q+offsetq]
>  movh   m6, [in_lines_adj1q+offsetq]
>  punpcklbw  m5, m7
>  punpcklbw  m6, m7
> -SBUTTERFLY wd, 5, 6, 8
> +SBUTTERFLY wd, 5, 6, 1
>  pmaddwdm5, m0
> -pmaddwdm6, m1
> +pmaddwdm6, m0
>  paddd  m3, m5
>  paddd  m4, m6
>  movh   m5, [in_lines_cur2q+offsetq]
>  movh   m6, [in_lines_adj2q+offsetq]
>  punpcklbw  m5, m7
>  punpcklbw  m6, m7
> -SBUTTERFLY wd, 5, 6, 8
> +SBUTTERFLY wd, 5, 6, 1
>  pmaddwdm5, m2
>  pmaddwdm6, m2
>  paddd  m3, m5
> --
> 2.6.0
>
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>

Cant this now be used on x32?
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [FFmpeg-cvslog] avconv: Do not try to configure filter outputs without streams

[Michael Niedermayer]

On Sat, Oct 10, 2015 at 09:31:05AM -0400, Ganesh Ajjanagadde wrote:
> On Sat, Oct 10, 2015 at 9:18 AM, Michael Niedermayer
>  wrote:
> > Hi
> >
> > On Sat, Oct 10, 2015 at 09:43:55AM +0200, Luca Barbato wrote:
> >> ffmpeg | branch: master | Luca Barbato  | Mon Oct  5 
> >> 20:49:55 2015 +0200| [8b830ee9a26d47b138f12a82085cdb372f407f1e] | 
> >> committer: Luca Barbato
> >>
> >> avconv: Do not try to configure filter outputs without streams
> >>
> >> Prevent a NULL-dereference.
> >>
> >> CC: libav-sta...@libav.org
> >>
> >> > http://git.videolan.org/gitweb.cgi/ffmpeg.git/?a=commit;h=8b830ee9a26d47b138f12a82085cdb372f407f1e
> >
> > this is not good
> > we already have code in configure_output_filter that checks
> > ofilter->ost != NULL and prints a clear warning in that case
> >
> > example:
> > ./ffmpeg -f lavfi -i color -f lavfi -i color -filter_complex 
> > "[1]null[x],[0][1]overlay" -f null -
> > before:
> > Filter null has a unconnected output
> > after:
> > Output pad "default" with type video of the filter instance "Parsed_null_0" 
> > of null not connected to any destination
> > Error configuring complex filters.
> > Invalid argument
> >
> > anyone against reverting this ?
> 
> No, I agree with your reasoning; the error message before was definitely 
> clear.

applied

thanks

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

Good people do not need laws to tell them to act responsibly, while bad
people will find a way around the laws. -- Plato


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/WIP: add selectivecolor filter

[Clément Bœsch]

On Sat, Aug 15, 2015 at 07:02:11PM +0200, Clément Bœsch wrote:
> ---
> Only K adjustment remains to fix before it's ready for a first upstream
> version. Help figuring out is still welcome. Otherwise, since this is very
> close to the final version, review is welcome as well.
> ---
>  doc/filters.texi|  67 ++
>  libavfilter/Makefile|   1 +
>  libavfilter/allfilters.c|   1 +
>  libavfilter/vf_selectivecolor.c | 457 
> 
>  4 files changed, 526 insertions(+)

Finally figured out the K adjustment and applied.

Remaining is making it bitexact to add a FATE test, and add >8bit support.

[...]

For the record, the original formula I was using was:

  f(v,a)   = clip(-a, -v, 1-v) . R

and taking k into account, it is now:
  f(v,a,k) = clip((-1-a).k - a, -v, 1-v) . R

With:
 f   adjustment function
 a   user component adjust (normed to [-1;1])
 v   component value (normed to [-1;1])
 k   user K adjust
 R   adjust range

-- 
Clément B.


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

Re: [FFmpeg-devel] [PATCH] os2threads: Add pthread_once emulation

[Hendrik Leppkes]

On Sun, Oct 11, 2015 at 4:32 AM, Dave Yeo  wrote:
> Based on code by Yuri Dario, http://svn.netlabs.org/repos/ports/pthread/trunk
>
> Signed-off-by: Dave Yeo 
> ---
>  compat/os2threads.h | 45 +
>  1 file changed, 45 insertions(+)
>
> diff --git a/compat/os2threads.h b/compat/os2threads.h
> index 5b6ca55..7f2c925 100644
> --- a/compat/os2threads.h
> +++ b/compat/os2threads.h
> @@ -31,9 +31,18 @@
>
>  #undef __STRICT_ANSI__  /* for _beginthread() */
>  #include 
> +#include 
>
>  #include "libavutil/mem.h"
>
> +/*
> + * Boolean values to make us independent of system includes.
> + */
> +enum {
> +  PTW32_FALSE = 0,
> +  PTW32_TRUE = (! PTW32_FALSE)
> +};
> +
>  typedef TID  pthread_t;
>  typedef void pthread_attr_t;
>
> @@ -47,6 +56,19 @@ typedef struct {
>
>  typedef void pthread_condattr_t;
>
> +typedef struct pthread_once_t_ pthread_once_t;
> +
> +#define PTHREAD_ONCE_INIT {0}
> +
> +struct pthread_once_t_
> +{
> +  unsigned  done;/* indicates if user function 
> has been executed */
> +  pthread_mutex_t lock;
> +  int   reserved1;
> +  int   reserved2;
> +};
> +
> +
>  struct thread_arg {
>  void *(*start_routine)(void *);
>  void *arg;
> @@ -163,4 +185,27 @@ static av_always_inline int 
> pthread_cond_wait(pthread_cond_t *cond, pthread_mute
>  return 0;
>  }
>
> +static av_always_inline int pthread_once(pthread_once_t *once_control, void 
> (*init_routine)(void))
> +{
> +   if (once_control == NULL || init_routine == NULL)
> +   {
> +   return EINVAL;
> +   }
> +
> +   if (__atomic_cmpxchg32((unsigned*)_control->done, 0, 0)) /* MBR 
> fence */
> +   {
> +   pthread_mutex_lock(_control->lock);
> +
> +   if (!once_control->done)
> +   {
> +   (*init_routine)();
> +   once_control->done = PTW32_TRUE;
> +   }
> +
> +   pthread_mutex_unlock(_control->lock);
> +   }
> +
> +   return 0;
> +}
> +
>  #endif /* AVCODEC_OS2PTHREADS_H */

I don't think this works properly, as you don't initialize the mutexes
- which I think OS/2 needs, why would we otherwise have a mutex
initialization function. :)
Either add atomic initialization, or use a atomic sleep loop like in
the win32 code.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [RFC] avx2 and scalarproduct

[Kieran Kunhya]

On 9 Oct 2015 10:13 pm, "Paul B Mahol"  wrote:
>
> diff --git a/libavcodec/x86/audiodsp.asm b/libavcodec/x86/audiodsp.asm
> index 3ffb27f..246e945 100644
> --- a/libavcodec/x86/audiodsp.asm
> +++ b/libavcodec/x86/audiodsp.asm
> @@ -41,7 +41,14 @@ cglobal scalarproduct_int16, 3,3,3, v1, v2, order
>  add orderq, mmsize*2
>  jl .loop
>  HADDD   m2, m0
> +%if cpuflag(avx2)
> +movd   eax, xm2
> +%if mmsize > 16
> +xor   eax, eax

huh?

> +%endif
> +%else
>  movd   eax, m2
> +%endif
>  %if mmsize == 8
>  emms
>  %endif
> @@ -52,6 +59,8 @@ INIT_MMX mmxext
>  SCALARPRODUCT
>  INIT_XMM sse2
>  SCALARPRODUCT
> +INIT_YMM avx2
> +SCALARPRODUCT
>
>
>
 ;-
> diff --git a/libavcodec/x86/audiodsp_init.c
b/libavcodec/x86/audiodsp_init.c
> index a2ce231..b99a129 100644
> --- a/libavcodec/x86/audiodsp_init.c
> +++ b/libavcodec/x86/audiodsp_init.c
> @@ -29,6 +29,8 @@ int32_t ff_scalarproduct_int16_mmxext(const int16_t
*v1, const int16_t *v2,
>int order);
>  int32_t ff_scalarproduct_int16_sse2(const int16_t *v1, const int16_t *v2,
>  int order);
> +int32_t ff_scalarproduct_int16_avx2(const int16_t *v1, const int16_t *v2,
> +int order);
>
>  void ff_vector_clip_int32_mmx(int32_t *dst, const int32_t *src,
>int32_t min, int32_t max, unsigned int
len);
> @@ -64,4 +66,8 @@ av_cold void ff_audiodsp_init_x86(AudioDSPContext *c)
>
>  if (EXTERNAL_SSE4(cpu_flags))
>  c->vector_clip_int32 = ff_vector_clip_int32_sse4;
> +
> +if (EXTERNAL_AVX2(cpu_flags))
> +c->scalarproduct_int16 = ff_scalarproduct_int16_avx2;
> +
>  }
> --
> 1.9.1
>
> ___
> 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] [RFC] avx2 and scalarproduct

[Ronald S. Bultje]

Hi Kieran,

On Sun, Oct 11, 2015 at 5:02 AM, Kieran Kunhya  wrote:

> On 9 Oct 2015 10:13 pm, "Paul B Mahol"  wrote:
> >
> > diff --git a/libavcodec/x86/audiodsp.asm b/libavcodec/x86/audiodsp.asm
> > index 3ffb27f..246e945 100644
> > --- a/libavcodec/x86/audiodsp.asm
> > +++ b/libavcodec/x86/audiodsp.asm
> > @@ -41,7 +41,14 @@ cglobal scalarproduct_int16, 3,3,3, v1, v2, order
> >  add orderq, mmsize*2
> >  jl .loop
> >  HADDD   m2, m0
> > +%if cpuflag(avx2)
> > +movd   eax, xm2
> > +%if mmsize > 16
> > +xor   eax, eax
>
> huh?


This was some test code discussed on IRC, Paul seems to have an issue where
mmsize=16 after INIT_YMM avx2, or something like that.

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

Re: [FFmpeg-devel] [PATCH] os2threads: Add pthread_once emulation

[Ronald S. Bultje]

Hi,

On Sat, Oct 10, 2015 at 10:32 PM, Dave Yeo  wrote:

> Based on code by Yuri Dario,
> http://svn.netlabs.org/repos/ports/pthread/trunk
>
> Signed-off-by: Dave Yeo 
> ---
>  compat/os2threads.h | 45 +
>  1 file changed, 45 insertions(+)
>
> diff --git a/compat/os2threads.h b/compat/os2threads.h
> index 5b6ca55..7f2c925 100644
> --- a/compat/os2threads.h
> +++ b/compat/os2threads.h
> @@ -31,9 +31,18 @@
>
>  #undef __STRICT_ANSI__  /* for _beginthread() */
>  #include 
> +#include 
>
>  #include "libavutil/mem.h"
>
> +/*
> + * Boolean values to make us independent of system includes.
> + */
> +enum {
> +  PTW32_FALSE = 0,
> +  PTW32_TRUE = (! PTW32_FALSE)
> +};
> +


I know this is os2 specific code, but do we really need this part?

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

Re: [FFmpeg-devel] av_ctz optimization

[Ronald S. Bultje]

Hi,

On Sat, Oct 10, 2015 at 10:50 PM, James Almer  wrote:

> On 10/10/2015 11:44 PM, Ganesh Ajjanagadde wrote:
> > Hi all,
> >
> > Turns out that the De-Bruijn method can be used to speed up av_ctz as
> > well. But before going about it, I was curious as to why such an
> > interface is actually public. It makes absolutely zero sense to me:
> > usage is limited exactly to one location, namely libavcodec/flacenc.c.
> > Was this an accident?
> >
> > Regards,
> > Ganesh
>
> It's not really public since intmath.h is not an installed header.
> Why it exists and is used instead of ff_ctz, i don't know.


Looks like it was added for use in flacenc, and we typically don't share
ff_ symbols between libraries. However, since it's inlined anyway, I'm not
sure anyone cares. Maybe time to remove it?

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

Re: [FFmpeg-devel] [PATCH] vp9: add 10/12bpp sse2 SIMD version for idct_idct_16x16.

[Ronald S. Bultje]

Hi,

On Thu, Oct 8, 2015 at 10:19 AM, Ronald S. Bultje 
wrote:

> Hi,
>
> On Thu, Oct 8, 2015 at 10:16 AM, Ronald S. Bultje 
> wrote:
>
>> ---
>>  libavcodec/x86/vp9dsp_init_16bpp_template.c |   2 +
>>  libavcodec/x86/vp9itxfm_16bpp.asm   | 237
>> ++--
>>  2 files changed, 223 insertions(+), 16 deletions(-)
>
>
> Oops, I forgot the dc-only code, don't bother looking at this yet...
>

N/m I ended up doing that in a separate patch, so ignore patch and patch is
open for review after all...

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

[FFmpeg-devel] Patch for Ticket 4922

[Ganesh Ajjanagadde]

Hi all,

Bug report from user: https://trac.ffmpeg.org/ticket/4922, and
associated patch has been attached. The patch LGTM, except for the
commit message, which should be changed to "configure: fix configure
when using gcc".

This should be backported. Apologies for the breakage.

Regards,
Ganesh
From 1c4d147167ccea142ede0f47bd0cf57121b45620 Mon Sep 17 00:00:00 2001
From: Jean-Yves Avenard 
Date: Sun, 11 Oct 2015 21:58:24 +1100
Subject: [PATCH] Fix configure when using gcc.

---
 configure | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/configure b/configure
index 91f366e..3f44157 100755
--- a/configure
+++ b/configure
@@ -3567,7 +3567,8 @@ probe_cc(){
 gcc_ext_ver=$(expr "$gcc_version" : ".*$gcc_pkg_ver $gcc_basever \\(.*\\)")
 _ident=$(cleanws "gcc $gcc_basever $gcc_pkg_ver $gcc_ext_ver")
 case $gcc_basever in
-2*) _depflags='-MMD -MF $(@:.o=.d) -MT $@' ;;
+2*) ;;
+*) _depflags='-MMD -MF $(@:.o=.d) -MT $@' ;;
 esac
 if [ "$first" = true ]; then
 case $gcc_basever in
-- 
2.1.4

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

Re: [FFmpeg-devel] [PATCHv2] avutil/mathematics: speed up av_gcd by using Stein's binary GCD algorithm

[wm4]

On Sat, 10 Oct 2015 21:58:47 -0400
Ganesh Ajjanagadde  wrote:

> This uses Stein's binary GCD algorithm:
> https://en.wikipedia.org/wiki/Binary_GCD_algorithm
> to get a roughly 4x speedup over Euclidean GCD on standard architectures
> with a compiler intrinsic for ctzll, and a roughly 2x speedup otherwise.
> At the moment, the compiler intrinsic is used on GCC and Clang due to
> its easy availability.
> 
> Quick note regarding overflow: yes, subtractions on int64_t can, but the
> llabs takes care of that. The llabs is also guaranteed to be safe, with
> no annoying INT64_MIN business since INT64_MIN being a power of 2, is
> shifted down before being sent to llabs.
> 
> The binary GCD needs ff_ctzll, an extension of ff_ctz for long long 
> (int64_t). On
> GCC, this is provided by a built-in. On Microsoft, there is a
> BitScanForward64 analog of BitScanForward that should work; but I can't 
> confirm.
> Apparently it is not available on 32 bit builds; so this may or may not
> work correctly. On Intel, per the documentation there is only an
> intrinsic for _bit_scan_forward and people have posted on forums
> regarding _bit_scan_forward64, but often their documentation is
> woeful. Again, I don't have it, so I can't test.
> 
> As such, to be safe, for now only the GCC/Clang intrinsic is added, the rest
> use a compiled version based on the De-Bruijn method of Leiserson et al:
> http://supertech.csail.mit.edu/papers/debruijn.pdf.
> 
> Tested with FATE, sample benchmark (x86-64, GCC 5.2.0, Haswell)
> with a START_TIMER and STOP_TIMER in libavutil/rationsl.c, followed by a
> make fate.
> 
> aac-am00_88.err:
> builtin:
> 714 decicycles in av_gcd,4095 runs,  1 skips
> 
> de-bruijn:
> 1440 decicycles in av_gcd,4096 runs,  0 skips
> 
> previous:
> 2889 decicycles in av_gcd,4096 runs,  0 skips
> 
> Signed-off-by: Ganesh Ajjanagadde 
> ---
>  libavutil/intmath.h | 19 +++
>  libavutil/mathematics.c | 26 +-
>  2 files changed, 40 insertions(+), 5 deletions(-)
> 
> diff --git a/libavutil/intmath.h b/libavutil/intmath.h
> index 08d54a6..b412385 100644
> --- a/libavutil/intmath.h
> +++ b/libavutil/intmath.h
> @@ -114,6 +114,9 @@ static av_always_inline av_const int 
> ff_log2_16bit_c(unsigned int v)
>  #ifndef ff_ctz
>  #define ff_ctz(v) __builtin_ctz(v)
>  #endif
> +#ifndef ff_ctzll
> +#define ff_ctzll(v) __builtin_ctzll(v)
> +#endif
>  #endif
>  #endif
>  
> @@ -158,6 +161,22 @@ static av_always_inline av_const int ff_ctz_c( int v )
>  #endif
>  #endif
>  
> +#ifndef ff_ctzll
> +#define ff_ctzll ff_ctzll_c
> +/* We use the De-Bruijn method outlined in:
> + * http://supertech.csail.mit.edu/papers/debruijn.pdf. */
> +static av_always_inline av_const int ff_ctzll_c(long long v)
> +{
> +static const int debruijn_ctz64[64] = {
> +0, 1, 2, 53, 3, 7, 54, 27, 4, 38, 41, 8, 34, 55, 48, 28,
> +62, 5, 39, 46, 44, 42, 22, 9, 24, 35, 59, 56, 49, 18, 29, 11,
> +63, 52, 6, 26, 37, 40, 33, 47, 61, 45, 43, 21, 23, 58, 17, 10,
> +51, 25, 36, 32, 60, 20, 57, 16, 50, 31, 19, 15, 30, 14, 13, 12
> +};
> +return debruijn_ctz64[(uint64_t)((v & -v) * 0x022FDD63CC95386D) >> 58];
> +}
> +#endif
> +

Is this duplicated from somewhere?
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] avcodec/webvttdec: Deal with WebVTT escapes

[Clément Bœsch]

On Fri, Oct 09, 2015 at 04:29:03PM +0100, Ricardo Constantino wrote:
> Bare ampersand characters are still accepted, even though out-of-spec.
> Also fixes adjacent tags not being parsed.
> 
> Fixes trac #4915
> 
> Signed-off-by: Ricardo Constantino 
> ---
>  libavcodec/webvttdec.c | 13 +++--
>  1 file changed, 11 insertions(+), 2 deletions(-)
> 
> diff --git a/libavcodec/webvttdec.c b/libavcodec/webvttdec.c
> index 1284a17..3b98e98 100644
> --- a/libavcodec/webvttdec.c
> +++ b/libavcodec/webvttdec.c
> @@ -37,11 +37,14 @@ static const struct {
>  {"", "{\\b1}"}, {"", "{\\b0}"},
>  {"", "{\\u1}"}, {"", "{\\u0}"},
>  {"{", "\\{"}, {"}", "\\}"}, // escape to avoid ASS markup conflicts
> +{"", ">"}, {"", "<"},
> +{"", ""}, {"", ""}, // FIXME: properly honor bidi marks

> +{"", "&"}, {"", " "},

nbsp → \h in ASS

See http://docs.aegisub.org/3.2/ASS_Tags/

>  };
>  
>  static int webvtt_event_to_ass(AVBPrint *buf, const char *p)
>  {
> -int i, skip = 0;
> +int i, again, skip = 0;
>  
>  while (*p) {
>  
> @@ -51,13 +54,19 @@ static int webvtt_event_to_ass(AVBPrint *buf, const char 
> *p)
>  if (!strncmp(p, from, len)) {
>  av_bprintf(buf, "%s", webvtt_tag_replace[i].to);
>  p += len;
> +again = 1;
>  break;
>  }
>  }
>  if (!*p)
>  break;
>  
> -if (*p == '<')
> +if (again) {
> +again = 0;
> +skip = 0;
> +continue;
> +}

> +else if (*p == '<')

nit: this else can be kept away to keep the diff small.

[...]

-- 
Clément B.


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

Re: [FFmpeg-devel] Patch for Ticket 4922

[Ganesh Ajjanagadde]

On Sun, Oct 11, 2015 at 9:26 AM, Ganesh Ajjanagadde  wrote:
> Hi all,
>
> Bug report from user: https://trac.ffmpeg.org/ticket/4922, and
> associated patch has been attached. The patch LGTM, except for the
> commit message, which should be changed to "configure: fix configure
> when using gcc".
>
> This should be backported. Apologies for the breakage.

Sent a patch with cleaned up commit message, please let me know if
attributing the way I did via a "From/Signed-Off" is incorrect.

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

Re: [FFmpeg-devel] [PATCH] avcodec/webvttdec: Deal with WebVTT escapes

[Ricardo Constantino]

On 11 October 2015 at 15:37, Clément Bœsch  wrote:

> nbsp → \h in ASS


nevcairiel suggested not relying on \h being parsed as nbsp in .srt with
VSFilter and Libass, but maybe using the unicode char itself. Unless FFmpeg
converts \h to the char code in srtenc or something?
Aegisub converts \h to regular space on exporting to .srt; SubtitleEdit
leaves as \h.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 3/5] lavu/jni: add helpers to manage android application contexts

[Ronald S. Bultje]

Hi,

On Fri, Oct 9, 2015 at 12:26 PM, Matthieu Bouron 
wrote:

> From: Matthieu Bouron 
>
> ---
>  libavutil/jni.c  | 104
> +++
>  libavutil/jni.h  |  28 +
>  libavutil/jni_internal.c |  30 ++
>  libavutil/jni_internal.h |  11 +
>  4 files changed, 173 insertions(+)


(Personal opinion only - applies to this whole patch set), this stuff had
no place anywhere in libavutil.

I don't even think it has any place anywhere in libavanything, but
certainly not in libavutil. Libavdevice _maybe_, and then really only for
android devices (other systems can have JNI, and you'd be sitting with all
this stuff and deps in your libav*.so/a which does nothing), but far, far,
far away from our core APIs. You could accomplish this by having a jni
dependency in configure which is only enabled when the android context
subsystem is enabled, so non-android builds are not affected by this.

All of this is just to get I/O in your Android app right? What's the issue
with setting AVFormatContext->io before calling avformat_open_input() and
implementing a custom input? Is it that each app would rewrite the same
code? Or am I missing something super-obvious?

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

[FFmpeg-devel] [PATCH 9/9] simple_idct: align with x86 version

[Christophe Gisquet]

This is slightly beneficial to omse (0.1691 to 0.1688). The x86 idct
is thus marked as a valid simple implementation.
---
 libavcodec/simple_idct_template.c | 15 +++
 libavcodec/x86/idctdsp_init.c |  8 +++-
 2 files changed, 6 insertions(+), 17 deletions(-)

diff --git a/libavcodec/simple_idct_template.c 
b/libavcodec/simple_idct_template.c
index 0585679..b38a039 100644
--- a/libavcodec/simple_idct_template.c
+++ b/libavcodec/simple_idct_template.c
@@ -66,7 +66,6 @@
 
 #elif BIT_DEPTH == 10 || BIT_DEPTH == 12
 
-# if BIT_DEPTH == 10
 #define W1 22725 // 90901
 #define W2 21407 //  85627
 #define W3 19265 //  77062
@@ -75,6 +74,7 @@
 #define W6  8867 //  35468
 #define W7  4520 //  18081
 
+# if BIT_DEPTH == 10
 #   ifdef EXTRA_SHIFT
 #define ROW_SHIFT 13
 #define COL_SHIFT 18
@@ -84,18 +84,9 @@
 #define COL_SHIFT 19
 #define DC_SHIFT  2
 #   endif
-
 # else
-#define W1 45451
-#define W2 42813
-#define W3 38531
-#define W4 32767
-#define W5 25746
-#define W6 17734
-#define W7 9041
-
-#define ROW_SHIFT 16
-#define COL_SHIFT 17
+#define ROW_SHIFT 15
+#define COL_SHIFT 16
 #define DC_SHIFT -1
 # endif
 
diff --git a/libavcodec/x86/idctdsp_init.c b/libavcodec/x86/idctdsp_init.c
index bcf7e5b..8b25ff9 100644
--- a/libavcodec/x86/idctdsp_init.c
+++ b/libavcodec/x86/idctdsp_init.c
@@ -86,11 +86,11 @@ av_cold void ff_idctdsp_init_x86(IDCTDSPContext *c, 
AVCodecContext *avctx,
 c->add_pixels_clamped= ff_add_pixels_clamped_sse2;
 }
 
-if (ARCH_X86_64 && avctx->lowres == 0) {
-if (avctx->bits_per_raw_sample == 10 &&
+if (ARCH_X86_64 && avctx->lowres == 0 &&
 (avctx->idct_algo == FF_IDCT_AUTO ||
  avctx->idct_algo == FF_IDCT_SIMPLEAUTO ||
  avctx->idct_algo == FF_IDCT_SIMPLE)) {
+if (avctx->bits_per_raw_sample == 10) {
 if (EXTERNAL_SSE2(cpu_flags)) {
 c->idct_put  = ff_simple_idct10_put_sse2;
 c->idct_add  = NULL;
@@ -106,9 +106,7 @@ av_cold void ff_idctdsp_init_x86(IDCTDSPContext *c, 
AVCodecContext *avctx,
 }
 }
 
-if (avctx->bits_per_raw_sample == 12 &&
-(avctx->idct_algo == FF_IDCT_AUTO ||
- avctx->idct_algo == FF_IDCT_SIMPLEMMX)) {
+if (avctx->bits_per_raw_sample == 12) {
 if (EXTERNAL_SSE2(cpu_flags)) {
 c->idct_put  = ff_simple_idct12_put_sse2;
 c->idct_add  = NULL;
-- 
2.6.0

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

[FFmpeg-devel] [PATCH 8/9] x86: dct-test: add more idcts

[Christophe Gisquet]

In particular for 10 and 12 bits.
---
 libavcodec/dct-test.c |  2 ++
 libavcodec/x86/dct-test.c | 10 ++
 2 files changed, 12 insertions(+)

diff --git a/libavcodec/dct-test.c b/libavcodec/dct-test.c
index 56e1a62..72fe353 100644
--- a/libavcodec/dct-test.c
+++ b/libavcodec/dct-test.c
@@ -82,6 +82,8 @@ static const struct algo idct_tab[] = {
 { "REF-DBL", ff_ref_idct,  FF_IDCT_PERM_NONE },
 { "INT", ff_j_rev_dct, FF_IDCT_PERM_LIBMPEG2 },
 { "SIMPLE-C",ff_simple_idct_8, FF_IDCT_PERM_NONE },
+{ "SIMPLE-C10",  ff_simple_idct_10,FF_IDCT_PERM_NONE },
+{ "SIMPLE-C12",  ff_simple_idct_12,FF_IDCT_PERM_NONE },
 { "PR-C",ff_prores_idct_wrap,  FF_IDCT_PERM_NONE, 0, 1 },
 #if CONFIG_FAANIDCT
 { "FAANI",   ff_faanidct,  FF_IDCT_PERM_NONE },
diff --git a/libavcodec/x86/dct-test.c b/libavcodec/x86/dct-test.c
index 0414381..b022552 100644
--- a/libavcodec/x86/dct-test.c
+++ b/libavcodec/x86/dct-test.c
@@ -85,6 +85,16 @@ static const struct algo idct_tab_arch[] = {
 { "PR-AVX",  ff_prores_idct_put_10_avx_wrap, FF_IDCT_PERM_TRANSPOSE, 
AV_CPU_FLAG_AVX, 1 },
 # endif
 #endif
+#if HAVE_YASM
+#if HAVE_SSE2_EXTERNAL
+{ "SIMPLE10-SSE2",  ff_simple_idct10_sse2, FF_IDCT_PERM_TRANSPOSE, 
AV_CPU_FLAG_SSE2, 1 },
+{ "SIMPLE12-SSE2",  ff_simple_idct12_sse2, FF_IDCT_PERM_TRANSPOSE, 
AV_CPU_FLAG_SSE2, 1 },
+#endif
+#if HAVE_AVX_EXTERNAL
+{ "SIMPLE10-AVX",   ff_simple_idct10_avx,  FF_IDCT_PERM_TRANSPOSE, 
AV_CPU_FLAG_AVX,  1 },
+{ "SIMPLE12-AVX",   ff_simple_idct12_avx,  FF_IDCT_PERM_TRANSPOSE, 
AV_CPU_FLAG_AVX,  1 },
+#endif
+#endif
 { 0 }
 };
 
-- 
2.6.0

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

[FFmpeg-devel] [PATCH 5/9] x86: proresdsp: simple_idct: free or use 1 xmm reg

[Christophe Gisquet]

m15 is zeroed but never used. If it's not needed, decrease by 1 the
number of xmm regs used (prores), otherwise, make use of it, for the
rounder in the row pass of simple_idct.
---
 libavcodec/x86/proresdsp.asm  |  8 
 libavcodec/x86/simple_idct10.asm  |  9 +
 libavcodec/x86/simple_idct10_template.asm | 17 -
 3 files changed, 17 insertions(+), 17 deletions(-)

diff --git a/libavcodec/x86/proresdsp.asm b/libavcodec/x86/proresdsp.asm
index 18cf15b..3fb71ba 100644
--- a/libavcodec/x86/proresdsp.asm
+++ b/libavcodec/x86/proresdsp.asm
@@ -37,17 +37,17 @@ cextern pw_1019
 
 section .text align=16
 
-%macro idct_put_fn 1
-cglobal prores_idct_put_10, 4, 4, %1
+%macro idct_put_fn 0
+cglobal prores_idct_put_10, 4, 4, 15
 IDCT_PUT_FNpw_1, 15, pw_88, 18, pw_4, pw_1019, r3
 RET
 %endmacro
 
 INIT_XMM sse2
-idct_put_fn 16
+idct_put_fn
 %if HAVE_AVX_EXTERNAL
 INIT_XMM avx
-idct_put_fn 16
+idct_put_fn
 %endif
 
 %endif
diff --git a/libavcodec/x86/simple_idct10.asm b/libavcodec/x86/simple_idct10.asm
index 982fb1e..cd2b905 100644
--- a/libavcodec/x86/simple_idct10.asm
+++ b/libavcodec/x86/simple_idct10.asm
@@ -37,17 +37,18 @@ pd_round: times 4 dd 1<<(12-1)
 
 section .text align=16
 
-%macro idct_put_fn 1
-cglobal simple_idct10_put, 3, 3, %1
+%macro idct_put_fn 0
+cglobal simple_idct10_put, 3, 3, 16
+mova  m15, [pd_round]
 IDCT_PUT_FN"", 12, pw_16, 19, 0, pw_1023
 RET
 %endmacro
 
 INIT_XMM sse2
-idct_put_fn 16
+idct_put_fn
 %if HAVE_AVX_EXTERNAL
 INIT_XMM avx
-idct_put_fn 16
+idct_put_fn
 %endif
 
 %endif
diff --git a/libavcodec/x86/simple_idct10_template.asm 
b/libavcodec/x86/simple_idct10_template.asm
index 86c2765..d4a08f8 100644
--- a/libavcodec/x86/simple_idct10_template.asm
+++ b/libavcodec/x86/simple_idct10_template.asm
@@ -90,14 +90,14 @@ cextern w7_min_w5
 pmaddwd m1, [w4_plus_w2]
 %ifstr %1
 ; 1<<(%1-1)
-paddd   m2, [pd_round]
-paddd   m3, [pd_round]
-paddd   m4, [pd_round]
-paddd   m5, [pd_round]
-paddd   m6, [pd_round]
-paddd   m7, [pd_round]
-paddd   m0, [pd_round]
-paddd   m1, [pd_round]
+paddd   m2, m15
+paddd   m3, m15
+paddd   m4, m15
+paddd   m5, m15
+paddd   m6, m15
+paddd   m7, m15
+paddd   m0, m15
+paddd   m1, m15
 %endif
 
 ; a0: -1*row[0]-1*row[2]
@@ -237,7 +237,6 @@ cextern w7_min_w5
 
 %macro IDCT_PUT_FN 6-7
 movsxd  r1,  r1d
-pxorm15, m15   ; zero
 
 ; for (i = 0; i < 8; i++)
 ; idctRowCondDC(block + i*8);
-- 
2.6.0

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

[FFmpeg-devel] [PATCH 2/9] x86: prores: templatize 10 bits simple_idct

[Christophe Gisquet]

This should be reused for a generic simple_idct10 function.
Requires a bit of trickery to declare common constants in C.
---
 libavcodec/x86/constants.c|  28 +++
 libavcodec/x86/constants.h|  16 ++
 libavcodec/x86/proresdsp.asm  | 263 +-
 libavcodec/x86/simple_idct10_template.asm | 299 ++
 4 files changed, 346 insertions(+), 260 deletions(-)
 create mode 100644 libavcodec/x86/simple_idct10_template.asm

diff --git a/libavcodec/x86/constants.c b/libavcodec/x86/constants.c
index 3f3ee0f..9592fa7 100644
--- a/libavcodec/x86/constants.c
+++ b/libavcodec/x86/constants.c
@@ -87,3 +87,31 @@ DECLARE_ALIGNED(32, const ymm_reg,  ff_pd_32)   = { 
0x00200020ULL, 0x000
 0x00200020ULL, 
0x00200020ULL };
 DECLARE_ALIGNED(32, const ymm_reg,  ff_pd_65535)= { 0xULL, 
0xULL,
 0xULL, 
0xULL };
+
+/* simple idct 10 */
+#define W1sh2 22725 // W1 = 90901 = 22725<<2 + 1
+#define W2sh2 21407 // W2 = 85627 = 21407<<2 - 1
+#define W3sh2 19265 // W3 = 77062 = 19265<<2 + 2
+#define W4sh2 16384 // W4 = 65535 = 16384<<2 - 1
+#define W5sh2 12873 // W5 = 51491 = 12873<<2 - 1
+#define W6sh2  8867 // W6 = 35468 =  8867<<2
+#define W7sh2  4520 // W7 = 18081 =  4520<<2 + 1
+
+#define TIMES4(a, b)\
+ 
(((b)&0xLL)<<48)+(((a)&0xLL)<<32)+(((b)&0xLL)<<16)+((a)&0xLL), \
+ 
(((b)&0xLL)<<48)+(((a)&0xLL)<<32)+(((b)&0xLL)<<16)+((a)&0xLL)
+
+#if ARCH_X86_64
+DECLARE_ALIGNED(16, const xmm_reg,  ff_w4_plus_w2) = { TIMES4(W4sh2,  W2sh2) };
+DECLARE_ALIGNED(16, const xmm_reg,  ff_w4_min_w2)  = { TIMES4(W4sh2, -W2sh2) };
+DECLARE_ALIGNED(16, const xmm_reg,  ff_w4_plus_w6) = { TIMES4(W4sh2, +W6sh2) };
+DECLARE_ALIGNED(16, const xmm_reg,  ff_w4_min_w6)  = { TIMES4(W4sh2, -W6sh2) };
+DECLARE_ALIGNED(16, const xmm_reg,  ff_w1_plus_w3) = { TIMES4(W1sh2, +W3sh2) };
+DECLARE_ALIGNED(16, const xmm_reg,  ff_w3_min_w1)  = { TIMES4(W3sh2, -W1sh2) };
+DECLARE_ALIGNED(16, const xmm_reg,  ff_w7_plus_w3) = { TIMES4(W7sh2, +W3sh2) };
+DECLARE_ALIGNED(16, const xmm_reg,  ff_w3_min_w7)  = { TIMES4(W3sh2, -W7sh2) };
+DECLARE_ALIGNED(16, const xmm_reg,  ff_w1_plus_w5) = { TIMES4(W1sh2, +W5sh2) };
+DECLARE_ALIGNED(16, const xmm_reg,  ff_w5_min_w1)  = { TIMES4(W5sh2, -W1sh2) };
+DECLARE_ALIGNED(16, const xmm_reg,  ff_w5_plus_w7) = { TIMES4(W5sh2, +W7sh2) };
+DECLARE_ALIGNED(16, const xmm_reg,  ff_w7_min_w5)  = { TIMES4(W7sh2, -W5sh2) };
+#endif
diff --git a/libavcodec/x86/constants.h b/libavcodec/x86/constants.h
index ee8422e..3605b63 100644
--- a/libavcodec/x86/constants.h
+++ b/libavcodec/x86/constants.h
@@ -67,4 +67,20 @@ extern const ymm_reg  ff_pd_16;
 extern const ymm_reg  ff_pd_32;
 extern const ymm_reg  ff_pd_65535;
 
+# if ARCH_X86_64
+/* simple_idct10, used by prores and dnxhd */
+extern const xmm_reg  ff_w4_plus_w2;
+extern const xmm_reg  ff_w4_min_w2;
+extern const xmm_reg  ff_w4_plus_w6;
+extern const xmm_reg  ff_w4_min_w6;
+extern const xmm_reg  ff_w1_plus_w3;
+extern const xmm_reg  ff_w3_min_w1;
+extern const xmm_reg  ff_w7_plus_w3;
+extern const xmm_reg  ff_w3_min_w7;
+extern const xmm_reg  ff_w1_plus_w5;
+extern const xmm_reg  ff_w5_min_w1;
+extern const xmm_reg  ff_w5_plus_w7;
+extern const xmm_reg  ff_w7_min_w5;
+# endif
+
 #endif /* AVCODEC_X86_CONSTANTS_H */
diff --git a/libavcodec/x86/proresdsp.asm b/libavcodec/x86/proresdsp.asm
index 632ece6..18cf15b 100644
--- a/libavcodec/x86/proresdsp.asm
+++ b/libavcodec/x86/proresdsp.asm
@@ -24,279 +24,22 @@
 
 %include "libavutil/x86/x86util.asm"
 
-%define W1sh2 22725 ; W1 = 90901 = 22725<<2 + 1
-%define W2sh2 21407 ; W2 = 85627 = 21407<<2 - 1
-%define W3sh2 19265 ; W3 = 77062 = 19265<<2 + 2
-%define W4sh2 16384 ; W4 = 65535 = 16384<<2 - 1
-%define W5sh2 12873 ; W5 = 51491 = 12873<<2 - 1
-%define W6sh2  8867 ; W6 = 35468 =  8867<<2
-%define W7sh2  4520 ; W7 = 18081 =  4520<<2 + 1
-
 %if ARCH_X86_64
 
 SECTION_RODATA
 
-w4_plus_w2: times 4 dw W4sh2, +W2sh2
-w4_min_w2:  times 4 dw W4sh2, -W2sh2
-w4_plus_w6: times 4 dw W4sh2, +W6sh2
-w4_min_w6:  times 4 dw W4sh2, -W6sh2
-w1_plus_w3: times 4 dw W1sh2, +W3sh2
-w3_min_w1:  times 4 dw W3sh2, -W1sh2
-w7_plus_w3: times 4 dw W7sh2, +W3sh2
-w3_min_w7:  times 4 dw W3sh2, -W7sh2
-w1_plus_w5: times 4 dw W1sh2, +W5sh2
-w5_min_w1:  times 4 dw W5sh2, -W1sh2
-w5_plus_w7: times 4 dw W5sh2, +W7sh2
-w7_min_w5:  times 4 dw W7sh2, -W5sh2
 pw_88:  times 8 dw 0x2008
-
 cextern pw_1
 cextern pw_4
-cextern pw_512
 cextern pw_1019
 
-section .text align=16
-
-; interleave data while maintaining source
-; %1=type, %2=dstlo, %3=dsthi, %4=src, %5=interleave
-%macro SBUTTERFLY3 5
-punpckl%1   m%2, m%4, m%5
-punpckh%1   m%3, m%4, m%5
-%endmacro
-
-; %1/%2=src1/dst1, %3/%4=dst2, %5/%6=src2, %7=shift
-; action: 

[FFmpeg-devel] [PATCH 6/9] x86: simple_idct: add pure idct functions

[Christophe Gisquet]

This is done by not passing clamping regs to the macro, and there,
deducing that this is a pure idct.

There are not many users (vf_spp is one), and the _add version doesn't
look like it will ever be used.
---
 libavcodec/x86/idctdsp_init.c |  4 +-
 libavcodec/x86/proresdsp.asm  |  8 ++--
 libavcodec/x86/simple_idct.h  |  3 ++
 libavcodec/x86/simple_idct10.asm  | 13 --
 libavcodec/x86/simple_idct10_template.asm | 76 +++
 5 files changed, 65 insertions(+), 39 deletions(-)

diff --git a/libavcodec/x86/idctdsp_init.c b/libavcodec/x86/idctdsp_init.c
index f6d2b50..6ab2620 100644
--- a/libavcodec/x86/idctdsp_init.c
+++ b/libavcodec/x86/idctdsp_init.c
@@ -94,14 +94,14 @@ av_cold void ff_idctdsp_init_x86(IDCTDSPContext *c, 
AVCodecContext *avctx,
 if (EXTERNAL_SSE2(cpu_flags)) {
 c->idct_put  = ff_simple_idct10_put_sse2;
 c->idct_add  = NULL;
-c->idct  = NULL;
+c->idct  = ff_simple_idct10_sse2;
 c->perm_type = FF_IDCT_PERM_TRANSPOSE;
 
 }
 if (EXTERNAL_AVX(cpu_flags)) {
 c->idct_put  = ff_simple_idct10_put_avx;
 c->idct_add  = NULL;
-c->idct  = NULL;
+c->idct  = ff_simple_idct10_avx;
 c->perm_type = FF_IDCT_PERM_TRANSPOSE;
 }
 }
diff --git a/libavcodec/x86/proresdsp.asm b/libavcodec/x86/proresdsp.asm
index 3fb71ba..4633844 100644
--- a/libavcodec/x86/proresdsp.asm
+++ b/libavcodec/x86/proresdsp.asm
@@ -37,17 +37,17 @@ cextern pw_1019
 
 section .text align=16
 
-%macro idct_put_fn 0
+%macro idct_fn 0
 cglobal prores_idct_put_10, 4, 4, 15
-IDCT_PUT_FNpw_1, 15, pw_88, 18, pw_4, pw_1019, r3
+IDCT_FNpw_1, 15, pw_88, 18, pw_4, pw_1019, r3
 RET
 %endmacro
 
 INIT_XMM sse2
-idct_put_fn
+idct_fn
 %if HAVE_AVX_EXTERNAL
 INIT_XMM avx
-idct_put_fn
+idct_fn
 %endif
 
 %endif
diff --git a/libavcodec/x86/simple_idct.h b/libavcodec/x86/simple_idct.h
index d886434..e8f59c1 100644
--- a/libavcodec/x86/simple_idct.h
+++ b/libavcodec/x86/simple_idct.h
@@ -25,6 +25,9 @@ void ff_simple_idct_mmx(int16_t *block);
 void ff_simple_idct_add_mmx(uint8_t *dest, int line_size, int16_t *block);
 void ff_simple_idct_put_mmx(uint8_t *dest, int line_size, int16_t *block);
 
+void ff_simple_idct10_sse2(int16_t *block);
+void ff_simple_idct10_avx(int16_t *block);
+
 void ff_simple_idct10_put_sse2(uint8_t *dest, int line_size, int16_t *block);
 void ff_simple_idct10_put_avx(uint8_t *dest, int line_size, int16_t *block);
 
diff --git a/libavcodec/x86/simple_idct10.asm b/libavcodec/x86/simple_idct10.asm
index cd2b905..8490d65 100644
--- a/libavcodec/x86/simple_idct10.asm
+++ b/libavcodec/x86/simple_idct10.asm
@@ -37,18 +37,23 @@ pd_round: times 4 dd 1<<(12-1)
 
 section .text align=16
 
-%macro idct_put_fn 0
+%macro idct_fn 0
+cglobal simple_idct10, 1, 1, 16
+mova  m15, [pd_round]
+IDCT_FN"", 12, pw_16, 19
+RET
+
 cglobal simple_idct10_put, 3, 3, 16
 mova  m15, [pd_round]
-IDCT_PUT_FN"", 12, pw_16, 19, 0, pw_1023
+IDCT_FN"", 12, pw_16, 19, 0, pw_1023
 RET
 %endmacro
 
 INIT_XMM sse2
-idct_put_fn
+idct_fn
 %if HAVE_AVX_EXTERNAL
 INIT_XMM avx
-idct_put_fn
+idct_fn
 %endif
 
 %endif
diff --git a/libavcodec/x86/simple_idct10_template.asm 
b/libavcodec/x86/simple_idct10_template.asm
index d4a08f8..5368ac7 100644
--- a/libavcodec/x86/simple_idct10_template.asm
+++ b/libavcodec/x86/simple_idct10_template.asm
@@ -128,18 +128,18 @@ cextern w7_min_w5
 psubd   m3,  m9; a1[4-7] intermediate
 
 ; load/store
-mova   [r2+  0], m0
-mova   [r2+ 32], m2
-mova   [r2+ 64], m4
-mova   [r2+ 96], m6
-movam10,[r2+ 16]   ; { row[1] }[0-7]
-movam8, [r2+ 48]   ; { row[3] }[0-7]
-movam13,[r2+ 80]   ; { row[5] }[0-7]
-movam14,[r2+112]   ; { row[7] }[0-7]
-mova   [r2+ 16], m1
-mova   [r2+ 48], m3
-mova   [r2+ 80], m5
-mova   [r2+112], m7
+mova   [COEFFS+  0], m0
+mova   [COEFFS+ 32], m2
+mova   [COEFFS+ 64], m4
+mova   [COEFFS+ 96], m6
+movam10,[COEFFS+ 16]   ; { row[1] }[0-7]
+movam8, [COEFFS+ 48]   ; { row[3] }[0-7]
+movam13,[COEFFS+ 80]   ; { row[5] }[0-7]
+movam14,[COEFFS+112]   ; { row[7] }[0-7]
+mova   [COEFFS+ 16], m1
+mova   [COEFFS+ 48], m3
+mova   [COEFFS+ 80], m5
+mova   [COEFFS+112], m7
 %if %0 == 3
 pmullw  m10,[%3+ 16]
 pmullw  m8, [%3+ 48]
@@ -210,17 +210,17 @@ cextern w7_min_w5
 ; row[5] = (a2 - b2) >> 15;
 ; row[3] = (a3 + b3) >> 15;
 ; row[4] = (a3 - b3) >> 15;
-movam8, [r2+ 0]; a0[0-3]
-movam9, [r2+16]; a0[4-7]
+movam8, [COEFFS+ 0]; a0[0-3]
+movam9, [COEFFS+16]; a0[4-7]
 SUMSUB_SHPK m8,  m9,  m10, m11, m0,  m1,  %2
-

[FFmpeg-devel] [PATCH 1/9] dnxhdenc: fix scan used for bitstream generation

[Christophe Gisquet]

The functions related to bitstream reading must use the natural zigzag
order, and not the one permuted for use in the iDCT. This currently
results in bitstreams with 2 issues:
- AC coefficients are encoded in an unexpected order;
- Incorrect weights are applied in the (de)quantization.

This currently can't show up because there's no simple_idct which
requires a permutation.

With one that does (based on prores'), and using the following source:
-f lavfi -i testsrc=s=1920x1080 -vframes 1 -pix_fmt yuv422p10le
and encoding to CID 1241 (interlaced 1080p YUV422) using:
-vcodec dnxhd -flags +ildct -vb 185M

before: stddev:   55.57 PSNR: 61.43 MAXDIFF:  960
after:  stddev:0.35 PSNR:105.45 MAXDIFF:   11
---
 libavcodec/dnxhdenc.c | 12 +++-
 1 file changed, 7 insertions(+), 5 deletions(-)

diff --git a/libavcodec/dnxhdenc.c b/libavcodec/dnxhdenc.c
index 7d96cd4..fa0b1dc 100644
--- a/libavcodec/dnxhdenc.c
+++ b/libavcodec/dnxhdenc.c
@@ -213,14 +213,14 @@ static av_cold int dnxhd_init_qmat(DNXHDEncContext *ctx, 
int lbias, int cbias)
 
 if (ctx->cid_table->bit_depth == 8) {
 for (i = 1; i < 64; i++) {
-int j = ctx->m.idsp.idct_permutation[ff_zigzag_direct[i]];
+int j = ctx->m.intra_scantable.scantable[i];
 weight_matrix[j] = ctx->cid_table->luma_weight[i];
 }
 ff_convert_matrix(>m, ctx->qmatrix_l, ctx->qmatrix_l16,
   weight_matrix, ctx->intra_quant_bias, 1,
   ctx->m.avctx->qmax, 1);
 for (i = 1; i < 64; i++) {
-int j = ctx->m.idsp.idct_permutation[ff_zigzag_direct[i]];
+int j = ctx->m.intra_scantable.scantable[i];
 weight_matrix[j] = ctx->cid_table->chroma_weight[i];
 }
 ff_convert_matrix(>m, ctx->qmatrix_c, ctx->qmatrix_c16,
@@ -241,7 +241,7 @@ static av_cold int dnxhd_init_qmat(DNXHDEncContext *ctx, 
int lbias, int cbias)
 // 10-bit
 for (qscale = 1; qscale <= ctx->m.avctx->qmax; qscale++) {
 for (i = 1; i < 64; i++) {
-int j = ctx->m.idsp.idct_permutation[ff_zigzag_direct[i]];
+int j = ctx->m.intra_scantable.scantable[i];
 
 /* The quantization formula from the VC-3 standard is:
  * quantized = sign(block[i]) * floor(abs(block[i]/s) * p /
@@ -464,6 +464,7 @@ static av_always_inline
 void dnxhd_encode_block(DNXHDEncContext *ctx, int16_t *block,
 int last_index, int n)
 {
+const uint8_t *scan = ctx->m.intra_scantable.scantable;
 int last_non_zero = 0;
 int slevel, i, j;
 
@@ -471,7 +472,7 @@ void dnxhd_encode_block(DNXHDEncContext *ctx, int16_t 
*block,
 ctx->m.last_dc[n] = block[0];
 
 for (i = 1; i <= last_index; i++) {
-j = ctx->m.intra_scantable.permutated[i];
+j = scan[i];
 slevel = block[j];
 if (slevel) {
 int run_level = i - last_non_zero - 1;
@@ -542,11 +543,12 @@ static av_always_inline int dnxhd_ssd_block(int16_t 
*qblock, int16_t *block)
 static av_always_inline
 int dnxhd_calc_ac_bits(DNXHDEncContext *ctx, int16_t *block, int last_index)
 {
+const uint8_t *scan = ctx->m.intra_scantable.scantable;
 int last_non_zero = 0;
 int bits = 0;
 int i, j, level;
 for (i = 1; i <= last_index; i++) {
-j = ctx->m.intra_scantable.permutated[i];
+j = scan[i];
 level = block[j];
 if (level) {
 int run_level = i - last_non_zero - 1;
-- 
2.6.0

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

[FFmpeg-devel] [PATCH 3/9] simple_idct10: improve precision

[Christophe Gisquet]

omse goes from 0.03060703 (which fails for dct-test) to 0.01663750.
---
 libavcodec/simple_idct.c  |  9 --
 libavcodec/simple_idct_template.c | 45 ++-
 tests/ref/fate/dnxhr-444  |  2 +-
 tests/ref/vsynth/vsynth1-dnxhd-720p-10bit |  2 +-
 tests/ref/vsynth/vsynth2-dnxhd-720p-10bit |  2 +-
 tests/ref/vsynth/vsynth_lena-dnxhd-720p-10bit |  2 +-
 6 files changed, 42 insertions(+), 20 deletions(-)

diff --git a/libavcodec/simple_idct.c b/libavcodec/simple_idct.c
index eeb6279..4d6d20d 100644
--- a/libavcodec/simple_idct.c
+++ b/libavcodec/simple_idct.c
@@ -36,6 +36,11 @@
 
 #define BIT_DEPTH 10
 #include "simple_idct_template.c"
+
+#define EXTRA_SHIFT  2
+#include "simple_idct_template.c"
+
+#undef EXTRA_SHIFT
 #undef BIT_DEPTH
 
 #define BIT_DEPTH 12
@@ -230,10 +235,10 @@ void ff_prores_idct(int16_t *block, const int16_t *qmat)
 block[i] *= qmat[i];
 
 for (i = 0; i < 8; i++)
-idctRowCondDC_10(block + i*8, 2);
+idctRowCondDC_extrashift_10(block + i*8, 2);
 
 for (i = 0; i < 8; i++) {
 block[i] += 8192;
-idctSparseCol_10(block + i);
+idctSparseCol_extrashift_10(block + i);
 }
 }
diff --git a/libavcodec/simple_idct_template.c 
b/libavcodec/simple_idct_template.c
index 789db8d..0585679 100644
--- a/libavcodec/simple_idct_template.c
+++ b/libavcodec/simple_idct_template.c
@@ -66,19 +66,26 @@
 
 #elif BIT_DEPTH == 10 || BIT_DEPTH == 12
 
-#if BIT_DEPTH == 10
-#define W1 (22725*4)  // 90901
-#define W2 (21407*4) //  85627
-#define W3 (19265*4) //  77062
-#define W4 (16384*4) //  65535
-#define W5 (12873*4) //  51491
-#define W6 ( 8867*4) //  35468
-#define W7 ( 4520*4) //  18081
-
-#define ROW_SHIFT 15
-#define COL_SHIFT 20
-#define DC_SHIFT 1
-#else
+# if BIT_DEPTH == 10
+#define W1 22725 // 90901
+#define W2 21407 //  85627
+#define W3 19265 //  77062
+#define W4 16384 //  65535
+#define W5 12873 //  51491
+#define W6  8867 //  35468
+#define W7  4520 //  18081
+
+#   ifdef EXTRA_SHIFT
+#define ROW_SHIFT 13
+#define COL_SHIFT 18
+#define DC_SHIFT  1
+#   else
+#define ROW_SHIFT 12
+#define COL_SHIFT 19
+#define DC_SHIFT  2
+#   endif
+
+# else
 #define W1 45451
 #define W2 42813
 #define W3 38531
@@ -90,7 +97,7 @@
 #define ROW_SHIFT 16
 #define COL_SHIFT 17
 #define DC_SHIFT -1
-#endif
+# endif
 
 #define MUL(a, b)((a) * (b))
 #define MAC(a, b, c) ((a) += (b) * (c))
@@ -101,7 +108,11 @@
 
 #endif
 
+#ifdef EXTRA_SHIFT
+static inline void FUNC(idctRowCondDC_extrashift)(int16_t *row, int 
extra_shift)
+#else
 static inline void FUNC(idctRowCondDC)(int16_t *row, int extra_shift)
+#endif
 {
 int a0, a1, a2, a3, b0, b1, b2, b3;
 
@@ -236,6 +247,9 @@ static inline void FUNC(idctRowCondDC)(int16_t *row, int 
extra_shift)
 }   \
 } while (0)
 
+#ifdef EXTRA_SHIFT
+static inline void FUNC(idctSparseCol_extrashift)(int16_t *col)
+#else
 static inline void FUNC(idctSparseColPut)(pixel *dest, int line_size,
   int16_t *col)
 {
@@ -285,6 +299,7 @@ static inline void FUNC(idctSparseColAdd)(pixel *dest, int 
line_size,
 }
 
 static inline void FUNC(idctSparseCol)(int16_t *col)
+#endif
 {
 int a0, a1, a2, a3, b0, b1, b2, b3;
 
@@ -300,6 +315,7 @@ static inline void FUNC(idctSparseCol)(int16_t *col)
 col[56] = ((a0 - b0) >> COL_SHIFT);
 }
 
+#ifndef EXTRA_SHIFT
 void FUNC(ff_simple_idct_put)(uint8_t *dest_, int line_size, int16_t *block)
 {
 pixel *dest = (pixel *)dest_;
@@ -338,3 +354,4 @@ void FUNC(ff_simple_idct)(int16_t *block)
 for (i = 0; i < 8; i++)
 FUNC(idctSparseCol)(block + i);
 }
+#endif
diff --git a/tests/ref/fate/dnxhr-444 b/tests/ref/fate/dnxhr-444
index 743067d..f9e73c3 100644
--- a/tests/ref/fate/dnxhr-444
+++ b/tests/ref/fate/dnxhr-444
@@ -1,2 +1,2 @@
 #tb 0: 1/24
-0,  0,  0,1,  9665280, 0x238a023e
+0,  0,  0,1,  9665280, 0x19ef4057
diff --git a/tests/ref/vsynth/vsynth1-dnxhd-720p-10bit 
b/tests/ref/vsynth/vsynth1-dnxhd-720p-10bit
index ab58807..dc808f3 100644
--- a/tests/ref/vsynth/vsynth1-dnxhd-720p-10bit
+++ b/tests/ref/vsynth/vsynth1-dnxhd-720p-10bit
@@ -1,4 +1,4 @@
 f8c4b7aa165a80df2485d526161290a3 
*tests/data/fate/vsynth1-dnxhd-720p-10bit.dnxhd
 2293760 tests/data/fate/vsynth1-dnxhd-720p-10bit.dnxhd
-3cc84f9e8d2e704475b410de27dd9951 
*tests/data/fate/vsynth1-dnxhd-720p-10bit.out.rawvideo
+87f1f0e074466facd3a9922ecc8311db 
*tests/data/fate/vsynth1-dnxhd-720p-10bit.out.rawvideo
 stddev:6.23 PSNR: 32.23 MAXDIFF:   64 bytes:  7603200/   760320
diff --git a/tests/ref/vsynth/vsynth2-dnxhd-720p-10bit 
b/tests/ref/vsynth/vsynth2-dnxhd-720p-10bit
index 5c21985..0d2068d 100644
--- a/tests/ref/vsynth/vsynth2-dnxhd-720p-10bit
+++ b/tests/ref/vsynth/vsynth2-dnxhd-720p-10bit
@@ -1,4 +1,4 @@
 e49cb87f69acc809aee55d64990c84a9 
*tests/data/fate/vsynth2-dnxhd-720p-10bit.dnxhd
 2293760 

[FFmpeg-devel] [PATCH 4/9] x86: simple_idct_put: 10bits versions

[Christophe Gisquet]

Modeled from the prores version. Clips to [0;1023] and is bitexact.
Bitexactness requires to add an offset in a different place compared
to prores or C, and makes the function approximately 2% slower.

For 16 frames of a DNxHD 4:2:2 10bits test sequence:

C:60861 decicycles in idct, 1048205 runs,371 skips
sse2: 27567 decicycles in idct, 1048216 runs,360 skips
avx:  26272 decicycles in idct, 1048171 runs,405 skips

The pure and _add versions are not implemented, so the corresponding
dsp functions are set to NULL to make it clear in a code executing
them.
---
 libavcodec/x86/Makefile   |  1 +
 libavcodec/x86/idctdsp_init.c | 20 
 libavcodec/x86/simple_idct.h  |  3 ++
 libavcodec/x86/simple_idct10.asm  | 53 +++
 libavcodec/x86/simple_idct10_template.asm | 12 +++
 5 files changed, 89 insertions(+)
 create mode 100644 libavcodec/x86/simple_idct10.asm

diff --git a/libavcodec/x86/Makefile b/libavcodec/x86/Makefile
index a9d8032..ef7628e 100644
--- a/libavcodec/x86/Makefile
+++ b/libavcodec/x86/Makefile
@@ -126,6 +126,7 @@ YASM-OBJS-$(CONFIG_QPELDSP)+= x86/qpeldsp.o 
\
   x86/fpel.o\
   x86/qpel.o
 YASM-OBJS-$(CONFIG_RV34DSP)+= x86/rv34dsp.o
+YASM-OBJS-$(CONFIG_IDCTDSP)+= x86/simple_idct10.o
 YASM-OBJS-$(CONFIG_VIDEODSP)   += x86/videodsp.o
 YASM-OBJS-$(CONFIG_VP3DSP) += x86/vp3dsp.o
 YASM-OBJS-$(CONFIG_VP8DSP) += x86/vp8dsp.o  \
diff --git a/libavcodec/x86/idctdsp_init.c b/libavcodec/x86/idctdsp_init.c
index 2c26a98..f6d2b50 100644
--- a/libavcodec/x86/idctdsp_init.c
+++ b/libavcodec/x86/idctdsp_init.c
@@ -85,4 +85,24 @@ av_cold void ff_idctdsp_init_x86(IDCTDSPContext *c, 
AVCodecContext *avctx,
 c->put_pixels_clamped= ff_put_pixels_clamped_sse2;
 c->add_pixels_clamped= ff_add_pixels_clamped_sse2;
 }
+
+if (ARCH_X86_64 &&
+avctx->bits_per_raw_sample == 10 && avctx->lowres == 0 &&
+(avctx->idct_algo == FF_IDCT_AUTO ||
+ avctx->idct_algo == FF_IDCT_SIMPLEAUTO ||
+ avctx->idct_algo == FF_IDCT_SIMPLE)) {
+if (EXTERNAL_SSE2(cpu_flags)) {
+c->idct_put  = ff_simple_idct10_put_sse2;
+c->idct_add  = NULL;
+c->idct  = NULL;
+c->perm_type = FF_IDCT_PERM_TRANSPOSE;
+
+}
+if (EXTERNAL_AVX(cpu_flags)) {
+c->idct_put  = ff_simple_idct10_put_avx;
+c->idct_add  = NULL;
+c->idct  = NULL;
+c->perm_type = FF_IDCT_PERM_TRANSPOSE;
+}
+}
 }
diff --git a/libavcodec/x86/simple_idct.h b/libavcodec/x86/simple_idct.h
index 4a98732..d886434 100644
--- a/libavcodec/x86/simple_idct.h
+++ b/libavcodec/x86/simple_idct.h
@@ -25,4 +25,7 @@ void ff_simple_idct_mmx(int16_t *block);
 void ff_simple_idct_add_mmx(uint8_t *dest, int line_size, int16_t *block);
 void ff_simple_idct_put_mmx(uint8_t *dest, int line_size, int16_t *block);
 
+void ff_simple_idct10_put_sse2(uint8_t *dest, int line_size, int16_t *block);
+void ff_simple_idct10_put_avx(uint8_t *dest, int line_size, int16_t *block);
+
 #endif /* AVCODEC_X86_SIMPLE_IDCT_H */
diff --git a/libavcodec/x86/simple_idct10.asm b/libavcodec/x86/simple_idct10.asm
new file mode 100644
index 000..982fb1e
--- /dev/null
+++ b/libavcodec/x86/simple_idct10.asm
@@ -0,0 +1,53 @@
+;**
+;* x86-SIMD-optimized IDCT for prores
+;* this is identical to "simple" IDCT written by Michael Niedermayer
+;* except for the clip range
+;*
+;* Copyright (c) 2011 Ronald S. Bultje 
+;* Copyright (c) 2015 Christophe Gisquet
+;*
+;* This file is part of FFmpeg.
+;*
+;* FFmpeg is free software; you can redistribute it and/or
+;* modify it under the terms of the GNU Lesser General Public
+;* License as published by the Free Software Foundation; either
+;* version 2.1 of the License, or (at your option) any later version.
+;*
+;* FFmpeg is distributed in the hope that it will be useful,
+;* but WITHOUT ANY WARRANTY; without even the implied warranty of
+;* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+;* Lesser General Public License for more details.
+;*
+;* You should have received a copy of the GNU Lesser General Public
+;* License along with FFmpeg; if not, write to the Free Software
+;* 51, Inc., Foundation Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA
+;**
+
+%include "libavutil/x86/x86util.asm"
+
+%if ARCH_X86_64
+
+SECTION_RODATA
+
+cextern pw_16
+cextern pw_1023
+pd_round: times 4 dd 1<<(12-1)
+
+%include "libavcodec/x86/simple_idct10_template.asm"
+
+section .text align=16
+
+%macro idct_put_fn 1
+cglobal 

[FFmpeg-devel] [PATCH 7/9] x86: simple_idct: 12bits versions

[Christophe Gisquet]

On 12 frames of a 444p 12 bits DNxHR sequence, _put function:
C: 78902 decicycles in idct,  262071 runs, 73 skips
avx:   32478 decicycles in idct,  262045 runs, 99 skips

Difference between the 2:
stddev:0.39 PSNR:104.47 MAXDIFF:2

This is unavoidable and due to the scale factors used in the x86
version, which cannot match the C ones.

In addition, the trick of adding an initial bias to the input of a
pass can overflow, as the input coefficients are already 15bits,
which is the maximum this function can handle.

Overall, however, the omse on 12 bits samples goes from 0.16916 to
0.16883. Reducing rowshift by 1 improves to 0.0908, but causes
overflows.
---
 libavcodec/x86/idctdsp_init.c | 22 --
 libavcodec/x86/simple_idct.h  |  6 ++
 libavcodec/x86/simple_idct10.asm  | 21 ++---
 libavcodec/x86/simple_idct10_template.asm |  1 +
 4 files changed, 45 insertions(+), 5 deletions(-)

diff --git a/libavcodec/x86/idctdsp_init.c b/libavcodec/x86/idctdsp_init.c
index 6ab2620..bcf7e5b 100644
--- a/libavcodec/x86/idctdsp_init.c
+++ b/libavcodec/x86/idctdsp_init.c
@@ -86,8 +86,8 @@ av_cold void ff_idctdsp_init_x86(IDCTDSPContext *c, 
AVCodecContext *avctx,
 c->add_pixels_clamped= ff_add_pixels_clamped_sse2;
 }
 
-if (ARCH_X86_64 &&
-avctx->bits_per_raw_sample == 10 && avctx->lowres == 0 &&
+if (ARCH_X86_64 && avctx->lowres == 0) {
+if (avctx->bits_per_raw_sample == 10 &&
 (avctx->idct_algo == FF_IDCT_AUTO ||
  avctx->idct_algo == FF_IDCT_SIMPLEAUTO ||
  avctx->idct_algo == FF_IDCT_SIMPLE)) {
@@ -104,5 +104,23 @@ av_cold void ff_idctdsp_init_x86(IDCTDSPContext *c, 
AVCodecContext *avctx,
 c->idct  = ff_simple_idct10_avx;
 c->perm_type = FF_IDCT_PERM_TRANSPOSE;
 }
+}
+
+if (avctx->bits_per_raw_sample == 12 &&
+(avctx->idct_algo == FF_IDCT_AUTO ||
+ avctx->idct_algo == FF_IDCT_SIMPLEMMX)) {
+if (EXTERNAL_SSE2(cpu_flags)) {
+c->idct_put  = ff_simple_idct12_put_sse2;
+c->idct_add  = NULL;
+c->idct  = ff_simple_idct12_sse2;
+c->perm_type = FF_IDCT_PERM_TRANSPOSE;
+}
+if (EXTERNAL_AVX(cpu_flags)) {
+c->idct_put  = ff_simple_idct12_put_avx;
+c->idct_add  = NULL;
+c->idct  = ff_simple_idct12_avx;
+c->perm_type = FF_IDCT_PERM_TRANSPOSE;
+}
+}
 }
 }
diff --git a/libavcodec/x86/simple_idct.h b/libavcodec/x86/simple_idct.h
index e8f59c1..8eeb31e 100644
--- a/libavcodec/x86/simple_idct.h
+++ b/libavcodec/x86/simple_idct.h
@@ -31,4 +31,10 @@ void ff_simple_idct10_avx(int16_t *block);
 void ff_simple_idct10_put_sse2(uint8_t *dest, int line_size, int16_t *block);
 void ff_simple_idct10_put_avx(uint8_t *dest, int line_size, int16_t *block);
 
+void ff_simple_idct12_sse2(int16_t *block);
+void ff_simple_idct12_avx(int16_t *block);
+
+void ff_simple_idct12_put_sse2(uint8_t *dest, int line_size, int16_t *block);
+void ff_simple_idct12_put_avx(uint8_t *dest, int line_size, int16_t *block);
+
 #endif /* AVCODEC_X86_SIMPLE_IDCT_H */
diff --git a/libavcodec/x86/simple_idct10.asm b/libavcodec/x86/simple_idct10.asm
index 8490d65..20a16bb 100644
--- a/libavcodec/x86/simple_idct10.asm
+++ b/libavcodec/x86/simple_idct10.asm
@@ -29,9 +29,13 @@
 
 SECTION_RODATA
 
+cextern pw_2
 cextern pw_16
 cextern pw_1023
-pd_round: times 4 dd 1<<(12-1)
+cextern pw_4095
+pd_round_12: times 4 dd 1<<(12-1)
+pd_round_15: times 4 dd 1<<(15-1)
+pd_round_16: times 4 dd 1<<(16-1)
 
 %include "libavcodec/x86/simple_idct10_template.asm"
 
@@ -39,14 +43,25 @@ section .text align=16
 
 %macro idct_fn 0
 cglobal simple_idct10, 1, 1, 16
-mova  m15, [pd_round]
 IDCT_FN"", 12, pw_16, 19
 RET
 
 cglobal simple_idct10_put, 3, 3, 16
-mova  m15, [pd_round]
 IDCT_FN"", 12, pw_16, 19, 0, pw_1023
 RET
+
+cglobal simple_idct12, 1, 1, 16
+; coeffs are already 15bits, adding the offset would cause
+; overflow in the input
+IDCT_FN"", 15, pw_2, 16
+RET
+
+cglobal simple_idct12_put, 3, 3, 16
+; range isn't known, so the C simple_idct range is used
+; Also, using a bias on input overflows, so use the bias
+; on output of the first butterfly instead
+IDCT_FN"", 15, pw_2, 16, 0, pw_4095
+RET
 %endmacro
 
 INIT_XMM sse2
diff --git a/libavcodec/x86/simple_idct10_template.asm 
b/libavcodec/x86/simple_idct10_template.asm
index 5368ac7..fa4b928 100644
--- a/libavcodec/x86/simple_idct10_template.asm
+++ b/libavcodec/x86/simple_idct10_template.asm
@@ -76,6 +76,7 @@ cextern w7_min_w5
 ; a3 -= W2 * row[2];
 %ifstr %1
 ; 1<<(%1-1) / W4 < 1
+movam15, [pd_round_ %+ %2]
 %else
 paddw   m10, [%1]
 %endif
-- 
2.6.0

[FFmpeg-devel] [PATCH] configure: fix configure when using gcc

[Ganesh Ajjanagadde]

Fixes Ticket4922.

Commit 060102389e572abb2beaed3b9f5e1036aeea43f1 broke configure.

From: Jean-Yves Avenard 
Signed-off-by: Ganesh Ajjanagadde 
---
 configure | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/configure b/configure
index 3d9803a..7e55e92 100755
--- a/configure
+++ b/configure
@@ -3621,7 +3621,8 @@ probe_cc(){
 gcc_ext_ver=$(expr "$gcc_version" : ".*$gcc_pkg_ver $gcc_basever 
\\(.*\\)")
 _ident=$(cleanws "gcc $gcc_basever $gcc_pkg_ver $gcc_ext_ver")
 case $gcc_basever in
-2*) _depflags='-MMD -MF $(@:.o=.d) -MT $@' ;;
+2*) ;;
+*) _depflags='-MMD -MF $(@:.o=.d) -MT $@' ;;
 esac
 if [ "$first" = true ]; then
 case $gcc_basever in
-- 
2.6.1

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

Re: [FFmpeg-devel] [PATCH] avcodec/webvttdec: Deal with WebVTT escapes

[Ricardo Constantino]

Ok, nevermind. I see the srt and webvttenc samples use \h already, so
that's what you'll want.

On 11 October 2015 at 16:53, Ricardo Constantino  wrote:

>
> On 11 October 2015 at 15:37, Clément Bœsch  wrote:
>
>> nbsp → \h in ASS
>
>
> nevcairiel suggested not relying on \h being parsed as nbsp in .srt with
> VSFilter and Libass, but maybe using the unicode char itself. Unless FFmpeg
> converts \h to the char code in srtenc or something?
> Aegisub converts \h to regular space on exporting to .srt; SubtitleEdit
> leaves as \h.
>
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] av_ctz optimization

[James Almer]

On 10/11/2015 8:01 AM, Ronald S. Bultje wrote:
> Hi,
> 
> On Sat, Oct 10, 2015 at 10:50 PM, James Almer  wrote:
> 
>> On 10/10/2015 11:44 PM, Ganesh Ajjanagadde wrote:
>>> Hi all,
>>>
>>> Turns out that the De-Bruijn method can be used to speed up av_ctz as
>>> well. But before going about it, I was curious as to why such an
>>> interface is actually public. It makes absolutely zero sense to me:
>>> usage is limited exactly to one location, namely libavcodec/flacenc.c.
>>> Was this an accident?
>>>
>>> Regards,
>>> Ganesh
>>
>> It's not really public since intmath.h is not an installed header.
>> Why it exists and is used instead of ff_ctz, i don't know.
> 
> 
> Looks like it was added for use in flacenc, and we typically don't share
> ff_ symbols between libraries. However, since it's inlined anyway, I'm not
> sure anyone cares. Maybe time to remove it?
> 
> Ronald

We're still in ABI breaking season so it's fine if we do it asap.
flacenc can use ff_ctz just fine.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] Patch for Ticket 4922

[Ganesh Ajjanagadde]

On Sun, Oct 11, 2015 at 11:22 AM, Ganesh Ajjanagadde  wrote:
> On Sun, Oct 11, 2015 at 9:26 AM, Ganesh Ajjanagadde  wrote:
>> Hi all,
>>
>> Bug report from user: https://trac.ffmpeg.org/ticket/4922, and
>> associated patch has been attached. The patch LGTM, except for the
>> commit message, which should be changed to "configure: fix configure
>> when using gcc".
>>
>> This should be backported. Apologies for the breakage.
>
> Sent a patch with cleaned up commit message, please let me know if
> attributing the way I did via a "From/Signed-Off" is incorrect.

Also, would like to add that feeling a greater sense of personal
responsibility for this breakage, I would like to exercise my commit
access for this patch. Anyone against this?

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

Re: [FFmpeg-devel] [PATCH 3/3] fate/subtitles: Add a new test for WebVTT

[Ricardo Constantino]

Attached is a new version of the sample with the missing non-breaking
spaces tests.


WebVTT_extended_tester.vtt
Description: Binary data
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] configure: fix configure when using gcc

[Nicolas George]

Le decadi 20 vendémiaire, an CCXXIV, Ganesh Ajjanagadde a écrit :
> I am not so sure, there was a reason for it documented in the
> 060102389e572abb2beaed3b9f5e1036aeea43f1 commit message.

Indeed. We have until gcc version 20 to find a solution.

Regards,

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

Re: [FFmpeg-devel] av_ctz optimization

[Timothy Gu]

On Sun, Oct 11, 2015 at 9:10 AM Ganesh Ajjanagadde  wrote:

> Isn't that an API change and not an ABI change (it was in doc/APIchanges)?
>

No, since intmath.h is not public.

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

[FFmpeg-devel] [PATCH] avcodec/h264: remove redundant and bogus get_format call

[wm4]

The AVCodecContext.get_format callback is not only used for pixel format
negotiation with the API user, but also for hwaccel init. For the
latter, it's required that some codec parameters, in particular the
codec profile, are set when the callback is invoked.

This patch removes a get_format invocation where this is not guaranteed.
The codec parameters, including the profile, are really set further
below. (The same code path that sets the profile also calls get_format
properly too.)

This just happened to work by coincidence in most cases. For example, if
the API user just copied or reused the AVStream's AVCodecContext when
decoding, the profile would be set properly. But in some cases it
fails., such as with the sample WolfensteinTwitch.mp4 on the samples
server.

Remove the redundant get_format call. Apparently it serves no purpose
anymore, although it is possible that this was different at the time it
was added in commit ffd77f94a26be22b8ead3178ceec3ed39e68abc5.

This fixes hwaccel usage for API users which do not set the profile
when setting up the AVCodecContext (which is allowed).
---
 libavcodec/h264_slice.c | 14 --
 1 file changed, 14 deletions(-)

diff --git a/libavcodec/h264_slice.c b/libavcodec/h264_slice.c
index a346ccb..1272319 100644
--- a/libavcodec/h264_slice.c
+++ b/libavcodec/h264_slice.c
@@ -1129,17 +1129,6 @@ fail:
 return ret;
 }
 
-static enum AVPixelFormat non_j_pixfmt(enum AVPixelFormat a)
-{
-switch (a) {
-case AV_PIX_FMT_YUVJ420P: return AV_PIX_FMT_YUV420P;
-case AV_PIX_FMT_YUVJ422P: return AV_PIX_FMT_YUV422P;
-case AV_PIX_FMT_YUVJ444P: return AV_PIX_FMT_YUV444P;
-default:
-return a;
-}
-}
-
 /**
  * Decode a slice header.
  * This will (re)intialize the decoder and call h264_frame_start() as needed.
@@ -1323,9 +1312,6 @@ int ff_h264_decode_slice_header(H264Context *h, 
H264SliceContext *sl)
  || h->mb_width  != h->sps.mb_width
  || h->mb_height != h->sps.mb_height * (2 - 
h->sps.frame_mbs_only_flag)
 ));
-if (h->avctx->pix_fmt == AV_PIX_FMT_NONE
-|| (non_j_pixfmt(h->avctx->pix_fmt) != 
non_j_pixfmt(get_pixel_format(h, 0
-must_reinit = 1;
 
 if (first_slice && av_cmp_q(h->sps.sar, h->avctx->sample_aspect_ratio))
 must_reinit = 1;
-- 
2.5.1

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

Re: [FFmpeg-devel] [PATCH 2/2] x86/vf_w3fdif: simplify w3fdif_simple_high

[James Almer]

On 10/11/2015 4:31 AM, Paul B Mahol wrote:
> On 10/11/15, James Almer  wrote:
>> Signed-off-by: James Almer 
>> ---
>>  libavfilter/x86/vf_w3fdif.asm | 16 +++-
>>  1 file changed, 7 insertions(+), 9 deletions(-)
>>
>> diff --git a/libavfilter/x86/vf_w3fdif.asm b/libavfilter/x86/vf_w3fdif.asm
>> index f02319b..f2001a4 100644
>> --- a/libavfilter/x86/vf_w3fdif.asm
>> +++ b/libavfilter/x86/vf_w3fdif.asm
>> @@ -103,13 +103,11 @@ REP_RET
>>
>>  %if ARCH_X86_64
>>
>> -cglobal w3fdif_simple_high, 5, 9, 9, 0, work_line, in_lines_cur0,
>> in_lines_adj0, coef, linesize
>> +cglobal w3fdif_simple_high, 5, 9, 8, 0, work_line, in_lines_cur0,
>> in_lines_adj0, coef, linesize
>>  movq  m2, [coefq]
>>  DEFINE_ARGSwork_line, in_lines_cur0, in_lines_adj0, in_lines_cur1,
>> linesize, offset, in_lines_cur2, in_lines_adj1, in_lines_adj2
>> -SPLATWm0, m2, 0
>> -SPLATWm1, m2, 1
>> +pshufdm0, m2, q
>>  SPLATWm2, m2, 2
>> -SBUTTERFLYwd, 0, 1, 7
>>  pxor  m7, m7
>>  mov  offsetq, 0
>>  mov   in_lines_cur2q, [in_lines_cur0q+gprsize*2]
>> @@ -124,23 +122,23 @@ cglobal w3fdif_simple_high, 5, 9, 9, 0, work_line,
>> in_lines_cur0, in_lines_adj0,
>>  movh   m4, [in_lines_cur1q+offsetq]
>>  punpcklbw  m3, m7
>>  punpcklbw  m4, m7
>> -SBUTTERFLY wd, 3, 4, 8
>> +SBUTTERFLY wd, 3, 4, 1
>>  pmaddwdm3, m0
>> -pmaddwdm4, m1
>> +pmaddwdm4, m0
>>  movh   m5, [in_lines_adj0q+offsetq]
>>  movh   m6, [in_lines_adj1q+offsetq]
>>  punpcklbw  m5, m7
>>  punpcklbw  m6, m7
>> -SBUTTERFLY wd, 5, 6, 8
>> +SBUTTERFLY wd, 5, 6, 1
>>  pmaddwdm5, m0
>> -pmaddwdm6, m1
>> +pmaddwdm6, m0
>>  paddd  m3, m5
>>  paddd  m4, m6
>>  movh   m5, [in_lines_cur2q+offsetq]
>>  movh   m6, [in_lines_adj2q+offsetq]
>>  punpcklbw  m5, m7
>>  punpcklbw  m6, m7
>> -SBUTTERFLY wd, 5, 6, 8
>> +SBUTTERFLY wd, 5, 6, 1
>>  pmaddwdm5, m2
>>  pmaddwdm6, m2
>>  paddd  m3, m5
>> --
>> 2.6.0
>>
>> ___
>> ffmpeg-devel mailing list
>> ffmpeg-devel@ffmpeg.org
>> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>>
> 
> Cant this now be used on x32?

Even though i got it down to eight xmm regs, we still have only seven grps
to work with on x86_32. 
The function has seven pointers plus the offset variable used as part of
effective addresses, which means they can't be accessed directly from
stack for this purpose, something that can be done with linesize.

So it will need some changes, like constant movs of grps to and from stack
to get it working.

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

Re: [FFmpeg-devel] setting up a proper Github mirror

[Timothy Gu]

On Sun, Oct 11, 2015 at 11:44 AM Ganesh Ajjanagadde 
wrote:

> I noticed that the Github mirror: https://github.com/FFmpeg/FFmpeg is
> over 3 hours out of sync with the main repos, making it unusable as a
> fetch url for development. Anyone knows why this is the case?
>

It is not an automatic mirror, and it is only updated when Michael or I
pushes since a) only three people have been added to the FFmpeg
organization and b) only Michael and I bothered to add Git aliases.

Same goes for the other repos.

Also, it looks like one can set some fancy UI illustrating that it is
> a mirror, see for instance: https://github.com/coreutils/coreutils.
> Anyone knows how to do this?
>

One has to contact GitHub for it. I tried doing that a long time ago but
they said they would do it only if Michael asked for it, and I didn't
bother.

Plus the mirror symbol doesn't offer any advantages:

1. pull requests still cannot be disabled
2. one still has to manually push to the GitHub mirror, either by hand or
through a receive hook on the server IIRC

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

[FFmpeg-devel] [PATCH 2/2] avcodec/h264_slice: Never call get_format() for just checking if the format matches

[Michael Niedermayer]

From: Michael Niedermayer 

Signed-off-by: Michael Niedermayer 
---
 libavcodec/h264_slice.c |4 
 1 file changed, 4 insertions(+)

diff --git a/libavcodec/h264_slice.c b/libavcodec/h264_slice.c
index cce97d9..daa3737 100644
--- a/libavcodec/h264_slice.c
+++ b/libavcodec/h264_slice.c
@@ -985,6 +985,10 @@ static enum AVPixelFormat get_pixel_format(H264Context *h, 
int force_callback)
 for (i=0; choices[i] != AV_PIX_FMT_NONE; i++)
 if (non_j_pixfmt(choices[i]) == non_j_pixfmt(h->avctx->pix_fmt) && 
!force_callback)
 return choices[i];
+
+if (!force_callback)
+return AV_PIX_FMT_NONE;
+
 return ff_thread_get_format(h->avctx, choices);
 }
 
-- 
1.7.9.5

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

Re: [FFmpeg-devel] av_ctz optimization

[Ganesh Ajjanagadde]

On Sun, Oct 11, 2015 at 12:06 PM, James Almer  wrote:
> On 10/11/2015 8:01 AM, Ronald S. Bultje wrote:
>> Hi,
>>
>> On Sat, Oct 10, 2015 at 10:50 PM, James Almer  wrote:
>>
>>> On 10/10/2015 11:44 PM, Ganesh Ajjanagadde wrote:
 Hi all,

 Turns out that the De-Bruijn method can be used to speed up av_ctz as
 well. But before going about it, I was curious as to why such an
 interface is actually public. It makes absolutely zero sense to me:
 usage is limited exactly to one location, namely libavcodec/flacenc.c.
 Was this an accident?

 Regards,
 Ganesh
>>>
>>> It's not really public since intmath.h is not an installed header.
>>> Why it exists and is used instead of ff_ctz, i don't know.
>>
>>
>> Looks like it was added for use in flacenc, and we typically don't share
>> ff_ symbols between libraries. However, since it's inlined anyway, I'm not
>> sure anyone cares. Maybe time to remove it?
>>
>> Ronald
>
> We're still in ABI breaking season so it's fine if we do it asap.
> flacenc can use ff_ctz just fine.

Isn't that an API change and not an ABI change (it was in doc/APIchanges)?
Per the development rules, I think the most ideal name is avpriv_ctz.
However, I am fine with ff_ as well.

> ___
> 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] configure: fix configure when using gcc

[Ganesh Ajjanagadde]

On Sun, Oct 11, 2015 at 12:15 PM, Nicolas George  wrote:
> Le decadi 20 vendémiaire, an CCXXIV, Ganesh Ajjanagadde a écrit :
>> Fixes Ticket4922.
>>
>> Commit 060102389e572abb2beaed3b9f5e1036aeea43f1 broke configure.
>
> The commit message could be a little more explicit: it forgot the ! that
> inverted the result.

Will change, thanks.

>
> Also, it seems that the test went from '2.' to just '2', maybe it should be
> fixed as well.

I am not so sure, there was a reason for it documented in the
060102389e572abb2beaed3b9f5e1036aeea43f1 commit message.

>
> 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] [PATCHv2] avutil/mathematics: speed up av_gcd by using Stein's binary GCD algorithm

[Ganesh Ajjanagadde]

On Sun, Oct 11, 2015 at 12:33 PM, wm4  wrote:
> On Sun, 11 Oct 2015 09:59:39 -0400
> Ganesh Ajjanagadde  wrote:
>
>> On Sun, Oct 11, 2015 at 9:34 AM, wm4  wrote:
>> > On Sat, 10 Oct 2015 21:58:47 -0400
>> > Ganesh Ajjanagadde  wrote:
>> >
>> >> This uses Stein's binary GCD algorithm:
>> >> https://en.wikipedia.org/wiki/Binary_GCD_algorithm
>> >> to get a roughly 4x speedup over Euclidean GCD on standard architectures
>> >> with a compiler intrinsic for ctzll, and a roughly 2x speedup otherwise.
>> >> At the moment, the compiler intrinsic is used on GCC and Clang due to
>> >> its easy availability.
>> >>
>> >> Quick note regarding overflow: yes, subtractions on int64_t can, but the
>> >> llabs takes care of that. The llabs is also guaranteed to be safe, with
>> >> no annoying INT64_MIN business since INT64_MIN being a power of 2, is
>> >> shifted down before being sent to llabs.
>> >>
>> >> The binary GCD needs ff_ctzll, an extension of ff_ctz for long long 
>> >> (int64_t). On
>> >> GCC, this is provided by a built-in. On Microsoft, there is a
>> >> BitScanForward64 analog of BitScanForward that should work; but I can't 
>> >> confirm.
>> >> Apparently it is not available on 32 bit builds; so this may or may not
>> >> work correctly. On Intel, per the documentation there is only an
>> >> intrinsic for _bit_scan_forward and people have posted on forums
>> >> regarding _bit_scan_forward64, but often their documentation is
>> >> woeful. Again, I don't have it, so I can't test.
>> >>
>> >> As such, to be safe, for now only the GCC/Clang intrinsic is added, the 
>> >> rest
>> >> use a compiled version based on the De-Bruijn method of Leiserson et al:
>> >> http://supertech.csail.mit.edu/papers/debruijn.pdf.
>> >>
>> >> Tested with FATE, sample benchmark (x86-64, GCC 5.2.0, Haswell)
>> >> with a START_TIMER and STOP_TIMER in libavutil/rationsl.c, followed by a
>> >> make fate.
>> >>
>> >> aac-am00_88.err:
>> >> builtin:
>> >> 714 decicycles in av_gcd,4095 runs,  1 skips
>> >>
>> >> de-bruijn:
>> >> 1440 decicycles in av_gcd,4096 runs,  0 skips
>> >>
>> >> previous:
>> >> 2889 decicycles in av_gcd,4096 runs,  0 skips
>> >>
>> >> Signed-off-by: Ganesh Ajjanagadde 
>> >> ---
>> >>  libavutil/intmath.h | 19 +++
>> >>  libavutil/mathematics.c | 26 +-
>> >>  2 files changed, 40 insertions(+), 5 deletions(-)
>> >>
>> >> diff --git a/libavutil/intmath.h b/libavutil/intmath.h
>> >> index 08d54a6..b412385 100644
>> >> --- a/libavutil/intmath.h
>> >> +++ b/libavutil/intmath.h
>> >> @@ -114,6 +114,9 @@ static av_always_inline av_const int 
>> >> ff_log2_16bit_c(unsigned int v)
>> >>  #ifndef ff_ctz
>> >>  #define ff_ctz(v) __builtin_ctz(v)
>> >>  #endif
>> >> +#ifndef ff_ctzll
>> >> +#define ff_ctzll(v) __builtin_ctzll(v)
>> >> +#endif
>> >>  #endif
>> >>  #endif
>> >>
>> >> @@ -158,6 +161,22 @@ static av_always_inline av_const int ff_ctz_c( int v 
>> >> )
>> >>  #endif
>> >>  #endif
>> >>
>> >> +#ifndef ff_ctzll
>> >> +#define ff_ctzll ff_ctzll_c
>> >> +/* We use the De-Bruijn method outlined in:
>> >> + * http://supertech.csail.mit.edu/papers/debruijn.pdf. */
>> >> +static av_always_inline av_const int ff_ctzll_c(long long v)
>> >> +{
>> >> +static const int debruijn_ctz64[64] = {
>> >> +0, 1, 2, 53, 3, 7, 54, 27, 4, 38, 41, 8, 34, 55, 48, 28,
>> >> +62, 5, 39, 46, 44, 42, 22, 9, 24, 35, 59, 56, 49, 18, 29, 11,
>> >> +63, 52, 6, 26, 37, 40, 33, 47, 61, 45, 43, 21, 23, 58, 17, 10,
>> >> +51, 25, 36, 32, 60, 20, 57, 16, 50, 31, 19, 15, 30, 14, 13, 12
>> >> +};
>> >> +return debruijn_ctz64[(uint64_t)((v & -v) * 0x022FDD63CC95386D) >> 
>> >> 58];
>> >> +}
>> >> +#endif
>> >> +
>> >
>> > Is this duplicated from somewhere?
>>
>> It may be obtained from a number of sources (or generated onself from
>> the link I gave, which actually is an original source):
>> "The De Bruijn bitscan was devised in 1997, according to Donald Knuth
>> [3] by Martin Läuter, and independently by Charles Leiserson, Harald
>> Prokop and Keith H. Randall a few month later." (I use the Leiserson
>> et al reference in the code).
>>
>> It is not a unique sequence, there are many available on the web:
>> https://chessprogramming.wikispaces.com/BitScan,
>> https://gist.github.com/deffi420/e700f0adefc82f28c0d7 (the sequence I
>> randomly picked).
>
> I just thought I've seen this somewhere else in libav*, but I didn't
> find anything. Ignore me.

I was actually thinking of legal/licensing issues of which I have no
knowledge. Anyway, good to see the confusion cleared up.

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

Re: [FFmpeg-devel] [PATCH] configure: fix configure when using gcc

[Timothy Gu]

On Sun, Oct 11, 2015 at 8:21 AM Ganesh Ajjanagadde 
wrote:

> Fixes Ticket4922.
>
> Commit 060102389e572abb2beaed3b9f5e1036aeea43f1 broke configure.
>
> From: Jean-Yves Avenard 
>

You might want to use `git commit --author` instead of manually adding a
"From" line in the commit message body.

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

Re: [FFmpeg-devel] [PATCH] configure: fix configure when using gcc

[Ganesh Ajjanagadde]

On Sun, Oct 11, 2015 at 12:53 PM, Ganesh Ajjanagadde
 wrote:
> On Sun, Oct 11, 2015 at 12:50 PM, Timothy Gu  wrote:
>> On Sun, Oct 11, 2015 at 8:21 AM Ganesh Ajjanagadde 
>> wrote:
>>>
>>> Fixes Ticket4922.
>>>
>>> Commit 060102389e572abb2beaed3b9f5e1036aeea43f1 broke configure.
>>>
>>> From: Jean-Yves Avenard 
>>
>>
>> You might want to use `git commit --author` instead of manually adding a
>> "From" line in the commit message body.
>
> will change, thanks

Could not find a command for adding "Reviewed by", so added it
manually. I am all ears for a script for this; manually looking up
names and emails can get tedious.

All changes made and pushed.

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

Re: [FFmpeg-devel] av_ctz optimization

[Ronald S. Bultje]

Hi,

On Sun, Oct 11, 2015 at 12:53 PM, Ganesh Ajjanagadde 
wrote:

> On Sun, Oct 11, 2015 at 12:33 PM, Timothy Gu 
> wrote:
> > On Sun, Oct 11, 2015 at 9:10 AM Ganesh Ajjanagadde 
> wrote:
> >
> >> Isn't that an API change and not an ABI change (it was in
> doc/APIchanges)?
> >>
> >
> > No, since intmath.h is not public.
>
> So basically av_ctz was a bungled operation. Someone needed it for
> flacdec, and decided to add it to intmath with the av_ prefix. We
> should get rid of this while we still have the window available. As
> obviously I do not know what is API/ABI clearly enough, I will refrain
> from sending a patch and leave it in more capable hands.


You can always try to take the approach of "send a patch and if it's bad,
we'll tell you" :-p.

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

Re: [FFmpeg-devel] [PATCH 2/2] x86/vf_w3fdif: simplify w3fdif_simple_high

[Ronald S. Bultje]

Hi,

On Sun, Oct 11, 2015 at 1:17 PM, James Almer  wrote:

> On 10/11/2015 4:31 AM, Paul B Mahol wrote:
> > On 10/11/15, James Almer  wrote:
> >> Signed-off-by: James Almer 
> >> ---
> >>  libavfilter/x86/vf_w3fdif.asm | 16 +++-
> >>  1 file changed, 7 insertions(+), 9 deletions(-)
> >>
> >> diff --git a/libavfilter/x86/vf_w3fdif.asm
> b/libavfilter/x86/vf_w3fdif.asm
> >> index f02319b..f2001a4 100644
> >> --- a/libavfilter/x86/vf_w3fdif.asm
> >> +++ b/libavfilter/x86/vf_w3fdif.asm
> >> @@ -103,13 +103,11 @@ REP_RET
> >>
> >>  %if ARCH_X86_64
> >>
> >> -cglobal w3fdif_simple_high, 5, 9, 9, 0, work_line, in_lines_cur0,
> >> in_lines_adj0, coef, linesize
> >> +cglobal w3fdif_simple_high, 5, 9, 8, 0, work_line, in_lines_cur0,
> >> in_lines_adj0, coef, linesize
> >>  movq  m2, [coefq]
> >>  DEFINE_ARGSwork_line, in_lines_cur0, in_lines_adj0,
> in_lines_cur1,
> >> linesize, offset, in_lines_cur2, in_lines_adj1, in_lines_adj2
> >> -SPLATWm0, m2, 0
> >> -SPLATWm1, m2, 1
> >> +pshufdm0, m2, q
> >>  SPLATWm2, m2, 2
> >> -SBUTTERFLYwd, 0, 1, 7
> >>  pxor  m7, m7
> >>  mov  offsetq, 0
> >>  mov   in_lines_cur2q, [in_lines_cur0q+gprsize*2]
> >> @@ -124,23 +122,23 @@ cglobal w3fdif_simple_high, 5, 9, 9, 0, work_line,
> >> in_lines_cur0, in_lines_adj0,
> >>  movh   m4, [in_lines_cur1q+offsetq]
> >>  punpcklbw  m3, m7
> >>  punpcklbw  m4, m7
> >> -SBUTTERFLY wd, 3, 4, 8
> >> +SBUTTERFLY wd, 3, 4, 1
> >>  pmaddwdm3, m0
> >> -pmaddwdm4, m1
> >> +pmaddwdm4, m0
> >>  movh   m5, [in_lines_adj0q+offsetq]
> >>  movh   m6, [in_lines_adj1q+offsetq]
> >>  punpcklbw  m5, m7
> >>  punpcklbw  m6, m7
> >> -SBUTTERFLY wd, 5, 6, 8
> >> +SBUTTERFLY wd, 5, 6, 1
> >>  pmaddwdm5, m0
> >> -pmaddwdm6, m1
> >> +pmaddwdm6, m0
> >>  paddd  m3, m5
> >>  paddd  m4, m6
> >>  movh   m5, [in_lines_cur2q+offsetq]
> >>  movh   m6, [in_lines_adj2q+offsetq]
> >>  punpcklbw  m5, m7
> >>  punpcklbw  m6, m7
> >> -SBUTTERFLY wd, 5, 6, 8
> >> +SBUTTERFLY wd, 5, 6, 1
> >>  pmaddwdm5, m2
> >>  pmaddwdm6, m2
> >>  paddd  m3, m5
> >> --
> >> 2.6.0
> >>
> >> ___
> >> ffmpeg-devel mailing list
> >> ffmpeg-devel@ffmpeg.org
> >> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
> >>
> >
> > Cant this now be used on x32?
>

Add to the data pointers directly (in_lines_cur0q and work_lineq). Then sub
all other curXq/adjXq from cur0q (on 32bit only) before the loop and you
have to adds (on 32bit) instead of one (on 64bit), but one reg less
(offset), making it 7, which means it works.

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

[FFmpeg-devel] [PATCH] intmath: remove av_ctz.

[Ronald S. Bultje]

It's an a non-installed header and only used in one place (flacenc).
Since ff_ctz is static inline, it's fine to use that instead.
---
 libavcodec/flacenc.c | 2 +-
 libavutil/intmath.c  | 5 -
 libavutil/intmath.h  | 8 
 3 files changed, 1 insertion(+), 14 deletions(-)

diff --git a/libavcodec/flacenc.c b/libavcodec/flacenc.c
index f849ffc..e87fdc1 100644
--- a/libavcodec/flacenc.c
+++ b/libavcodec/flacenc.c
@@ -1065,7 +1065,7 @@ static void remove_wasted_bits(FlacEncodeContext *s)
 }
 
 if (v && !(v & 1)) {
-v = av_ctz(v);
+v = ff_ctz(v);
 
 for (i = 0; i < s->frame.blocksize; i++)
 sub->samples[i] >>= v;
diff --git a/libavutil/intmath.c b/libavutil/intmath.c
index 1f725c7..b0c00e1 100644
--- a/libavutil/intmath.c
+++ b/libavutil/intmath.c
@@ -32,8 +32,3 @@ int av_log2_16bit(unsigned v)
 {
 return ff_log2_16bit(v);
 }
-
-int av_ctz(int v)
-{
-return ff_ctz(v);
-}
diff --git a/libavutil/intmath.h b/libavutil/intmath.h
index 08d54a6..78db28c 100644
--- a/libavutil/intmath.h
+++ b/libavutil/intmath.h
@@ -159,14 +159,6 @@ static av_always_inline av_const int ff_ctz_c( int v )
 #endif
 
 /**
- * Trailing zero bit count.
- *
- * @param v  input value. If v is 0, the result is undefined.
- * @return   the number of trailing 0-bits
- */
-int av_ctz(int v);
-
-/**
  * @}
  */
 #endif /* AVUTIL_INTMATH_H */
-- 
2.1.2

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

Re: [FFmpeg-devel] Patch for Ticket 4922

[Ganesh Ajjanagadde]

On Sun, Oct 11, 2015 at 12:12 PM, Ganesh Ajjanagadde  wrote:
> On Sun, Oct 11, 2015 at 11:22 AM, Ganesh Ajjanagadde  wrote:
>> On Sun, Oct 11, 2015 at 9:26 AM, Ganesh Ajjanagadde  wrote:
>>> Hi all,
>>>
>>> Bug report from user: https://trac.ffmpeg.org/ticket/4922, and
>>> associated patch has been attached. The patch LGTM, except for the
>>> commit message, which should be changed to "configure: fix configure
>>> when using gcc".
>>>
>>> This should be backported. Apologies for the breakage.
>>
>> Sent a patch with cleaned up commit message, please let me know if
>> attributing the way I did via a "From/Signed-Off" is incorrect.
>
> Also, would like to add that feeling a greater sense of personal
> responsibility for this breakage, I would like to exercise my commit
> access for this patch. Anyone against this?

patch applied to master, so the question is irrelevant now.

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

Re: [FFmpeg-devel] [PATCH] avformat/rtmpcrypt: fix discarded const warning

[Ronald S. Bultje]

Hi,

On Sun, Oct 11, 2015 at 2:15 PM, Ganesh Ajjanagadde 
wrote:

> On Fri, Sep 18, 2015 at 5:02 PM, Michael Niedermayer 
> wrote:
> > On Fri, Sep 18, 2015 at 09:50:29PM +0200, Nicolas George wrote:
> >> Le jour du Génie, an CCXXIII, Ganesh Ajjanagadde a écrit :
> >> > This patch silences a -Wdiscarded-qualifiers observed with GCC 5.2.
> >> >
> >> > Signed-off-by: Ganesh Ajjanagadde 
> >> > ---
> >> >  libavformat/rtmpcrypt.c | 2 +-
> >> >  1 file changed, 1 insertion(+), 1 deletion(-)
> >>
> >> I am not sure this is correct: the buffer is const for a reason, the
> warning
> >> is right. An application would be completely allowed to give a buffer in
> >> read-only memory, or to reuse the contents of the buffer afterwards.
> >>
> >> Actually, I suspect this muxer, if used as first output in the tee
> muxer,
> >> would cause the next outputs to be corrupt.
> >
> > IIRC the code is safe, just ugly
> > the writing only occurs if handshaked is set, which is only set
> > by ff_rtmpe_update_keystream() which is not part of the public
> > interface and only called from libavformat/rtmpproto.c
> > i assume but did not double check that libavformat/rtmpproto.c
> > calls the functions so that writable buffers are used
> >
> >
> >>
> >> The correct fix would probably be to allocate a new buffer, probably
> keeping
> >> it in the context for performances reasons instead of allocating each
> time.
> >
> > id need to double check but i think the calling code possibly uses
> > the written buffer with the expectation that it has been updated
> >
> > if that is so then such fix would break it.
>
> Have you checked the code and confirmed that this patch is fine?


I don't think the explanation makes the patch fine, the explanation just
says that there's no actual issue being hidden behind the warning. It
sounds like this code needs some refactoring...

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

[FFmpeg-devel] setting up a proper Github mirror

[Ganesh Ajjanagadde]

Hi all,

I noticed that the Github mirror: https://github.com/FFmpeg/FFmpeg is
over 3 hours out of sync with the main repos, making it unusable as a
fetch url for development. Anyone knows why this is the case?

Also, it looks like one can set some fancy UI illustrating that it is
a mirror, see for instance: https://github.com/coreutils/coreutils.
Anyone knows how to do this?

The reason I bothered with this is that setting this up correctly
could reduce the server load: only for pushing is the
source.ffmpeg.org needed, for pulling one can use the Github URL. I
currently point my fetch to Videolan and push to source.ffmpeg for
this purpose.

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

Re: [FFmpeg-devel] policy on "necro-bumping" patches

[Ganesh Ajjanagadde]

On Sat, Sep 26, 2015 at 12:00 PM, Henrik Gramner  wrote:
> On Sat, Sep 26, 2015 at 5:18 PM, Ganesh Ajjanagadde  wrote:
>> On Sat, Sep 26, 2015 at 11:09 AM, Hendrik Leppkes  
>> wrote:
>>> Please ping the actual thread of the patch, and not some seemingly
>>> unrelated thread, so people are actually aware of the topic at hand.
>>
>> Apologies, but since the thread was so old and no one seemed willing
>> to apply it at the time, I deleted it from my inbox. I do not know an
>> easy way to reply again to the actual thread, at least for the gmail
>> web interface that I use.
>
> You can click the sender's e-mail address at the top of the pipermail
> web interface to reply with the correct headers.

I tried this, but it seems like it places the headers without placing
the contents of the thread. Nevertheless, I have updated it with a
copy-pasted patch:
https://ffmpeg.org/pipermail/ffmpeg-devel/2015-October/180707.html

> ___
> 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] setting up a proper Github mirror

[Clément Bœsch]

On Sun, Oct 11, 2015 at 02:43:53PM -0400, Ganesh Ajjanagadde wrote:
> Hi all,
> 
> I noticed that the Github mirror: https://github.com/FFmpeg/FFmpeg is
> over 3 hours out of sync with the main repos, making it unusable as a
> fetch url for development. Anyone knows why this is the case?
> 

Isn't this done manually by whoever has access to it?

> Also, it looks like one can set some fancy UI illustrating that it is
> a mirror, see for instance: https://github.com/coreutils/coreutils.
> Anyone knows how to do this?
> 

> The reason I bothered with this is that setting this up correctly
> could reduce the server load: only for pushing is the
> source.ffmpeg.org needed, for pulling one can use the Github URL. I

> currently point my fetch to Videolan and push to source.ffmpeg for
> this purpose.

I hope this won't disappoint you but:

[~]☭ host source.ffmpeg.org
source.ffmpeg.org is an alias for git.videolan.org.

[...]

-- 
Clément B.


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

Re: [FFmpeg-devel] setting up a proper Github mirror

[Timothy Gu]

On Sun, Oct 11, 2015 at 12:16 PM Ganesh Ajjanagadde 
wrote:

> Alternatively (for now, more sustainable is a proper hook), could you
> post here your alias to do this?
>

git remote set-url origin --push --add g...@github.com:FFmpeg/FFmpeg.git

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

Re: [FFmpeg-devel] [PATCH 1/2] avcodec/h264_slice: Use non_j_pixfmt() in the format match code

[wm4]

On Sun, 11 Oct 2015 21:16:26 +0200
Michael Niedermayer  wrote:

> From: Michael Niedermayer 
> 
> Signed-off-by: Michael Niedermayer 
> ---
>  libavcodec/h264_slice.c |   24 
>  1 file changed, 12 insertions(+), 12 deletions(-)
> 
> diff --git a/libavcodec/h264_slice.c b/libavcodec/h264_slice.c
> index a346ccb..cce97d9 100644
> --- a/libavcodec/h264_slice.c
> +++ b/libavcodec/h264_slice.c
> @@ -865,6 +865,17 @@ static void init_scan_tables(H264Context *h)
>  }
>  }
>  
> +static enum AVPixelFormat non_j_pixfmt(enum AVPixelFormat a)
> +{
> +switch (a) {
> +case AV_PIX_FMT_YUVJ420P: return AV_PIX_FMT_YUV420P;
> +case AV_PIX_FMT_YUVJ422P: return AV_PIX_FMT_YUV422P;
> +case AV_PIX_FMT_YUVJ444P: return AV_PIX_FMT_YUV444P;
> +default:
> +return a;
> +}
> +}
> +
>  static enum AVPixelFormat get_pixel_format(H264Context *h, int 
> force_callback)
>  {
>  #define HWACCEL_MAX (CONFIG_H264_DXVA2_HWACCEL + \
> @@ -972,7 +983,7 @@ static enum AVPixelFormat get_pixel_format(H264Context 
> *h, int force_callback)
>  *fmt = AV_PIX_FMT_NONE;
>  
>  for (i=0; choices[i] != AV_PIX_FMT_NONE; i++)
> -if (choices[i] == h->avctx->pix_fmt && !force_callback)
> +if (non_j_pixfmt(choices[i]) == non_j_pixfmt(h->avctx->pix_fmt) && 
> !force_callback)
>  return choices[i];
>  return ff_thread_get_format(h->avctx, choices);
>  }
> @@ -1129,17 +1140,6 @@ fail:
>  return ret;
>  }
>  
> -static enum AVPixelFormat non_j_pixfmt(enum AVPixelFormat a)
> -{
> -switch (a) {
> -case AV_PIX_FMT_YUVJ420P: return AV_PIX_FMT_YUV420P;
> -case AV_PIX_FMT_YUVJ422P: return AV_PIX_FMT_YUV422P;
> -case AV_PIX_FMT_YUVJ444P: return AV_PIX_FMT_YUV444P;
> -default:
> -return a;
> -}
> -}
> -
>  /**
>   * Decode a slice header.
>   * This will (re)intialize the decoder and call h264_frame_start() as needed.

Not particularly fond of this weird thing spreading.

Can't we finally execute the half-decade old deprecation of the J
formats?
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH 3/3] fate/subtitles: Add a new test for WebVTT

[Ricardo Constantino]

Includes escapes that should now be supported and a few features not yet
fully supported, like comments, regions, classes, ruby, and lang.

All were tested with https://quuz.org/webvtt/ for validation, except
regions because the validator doesn't support them yet, and I couldn't
find any other way to validate WebVTT.

Signed-off-by: Ricardo Constantino 
---
 tests/fate/subtitles.mak   |  3 +++
 tests/ref/fate/sub-webvtt2 | 24 
 2 files changed, 27 insertions(+)
 create mode 100644 tests/ref/fate/sub-webvtt2

diff --git a/tests/fate/subtitles.mak b/tests/fate/subtitles.mak
index 81ad4d7..2d9eb50 100644
--- a/tests/fate/subtitles.mak
+++ b/tests/fate/subtitles.mak
@@ -70,6 +70,9 @@ fate-sub-vplayer: CMD = fmtstdout ass -i 
$(TARGET_SAMPLES)/sub/VPlayer_capabilit
 FATE_SUBTITLES_ASS-$(call DEMDEC, WEBVTT, WEBVTT) += fate-sub-webvtt
 fate-sub-webvtt: CMD = fmtstdout ass -i 
$(TARGET_SAMPLES)/sub/WebVTT_capability_tester.vtt
 
+FATE_SUBTITLES_ASS-$(call DEMDEC, WEBVTT, WEBVTT) += fate-sub-webvtt2
+fate-sub-webvtt2: CMD = fmtstdout ass -i 
$(TARGET_SAMPLES)/sub/WebVTT_extended_tester.vtt
+
 FATE_SUBTITLES-$(call ALLYES, SRT_DEMUXER SUBRIP_DECODER WEBVTT_ENCODER 
WEBVTT_MUXER) += fate-sub-webvttenc
 fate-sub-webvttenc: CMD = fmtstdout webvtt -i 
$(TARGET_SAMPLES)/sub/SubRip_capability_tester.srt
 
diff --git a/tests/ref/fate/sub-webvtt2 b/tests/ref/fate/sub-webvtt2
new file mode 100644
index 000..9f7827d
--- /dev/null
+++ b/tests/ref/fate/sub-webvtt2
@@ -0,0 +1,24 @@
+[Script Info]
+; Script generated by FFmpeg/Lavc
+ScriptType: v4.00+
+PlayResX: 384
+PlayResY: 288
+
+[V4+ Styles]
+Format: Name, Fontname, Fontsize, PrimaryColour, SecondaryColour, 
OutlineColour, BackColour, Bold, Italic, Underline, StrikeOut, ScaleX, ScaleY, 
Spacing, Angle, BorderStyle, Outline, Shadow, Alignment, MarginL, MarginR, 
MarginV, Encoding
+Style: 
Default,Arial,16,0,0,0,0,100,100,0,0,1,1,0,2,10,10,10,0
+
+[Events]
+Format: Layer, Start, End, Style, Name, MarginL, MarginR, MarginV, Effect, Text
+Dialogue: 0,0:00:00.00,0:00:20.00,Default,,0,0,0,,Hi, my name is Fred
+Dialogue: 0,0:00:02.50,0:00:22.50,Default,,0,0,0,,Hi, I’m Bill
+Dialogue: 0,0:00:05.00,0:00:25.00,Default,,0,0,0,,Would you like to get a 
coffee?
+Dialogue: 0,0:00:07.50,0:00:27.50,Default,,0,0,0,,Sure! I’ve only had one 
today.
+Dialogue: 0,0:00:10.00,0:00:30.00,Default,,0,0,0,,This is my fourth!
+Dialogue: 0,0:00:12.50,0:00:32.50,Default,,0,0,0,,OK, let’s go.
+Dialogue: 0,0:00:38.00,0:00:43.00,Default,,0,0,0,,I want to 愛あい love 
you\NThat's not proper English!
+Dialogue: 0,0:00:43.00,0:00:46.00,Default,,0,0,0,,{\i1}キツネ{\i0}じゃない　
キツネじゃない\N乙女おとめは
+Dialogue: 0,0:00:50.00,0:00:55.00,Default,,0,0,0,,Some time ago in a rather 
distant place
+Dialogue: 0,0:00:55.00,0:01:00.00,Default,,0,0,0,,Descending: 
123456\NAscending: 123456
+Dialogue: 0,0:01:00.00,0:01:05.00,Default,,0,0,0,,>> Never gonna give you up 
Never gonna let you down\NNever\hgonna\hrun\haround & desert\hyou
+Dialogue: 0,0:55:00.00,1:00:00.00,Default,,0,0,0,,Transcrit par Célestes™
-- 
2.6.0

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

[FFmpeg-devel] [PATCH 1/3] avcodec/webvttdec: Deal with WebVTT escapes

[Ricardo Constantino]

Bare ampersand characters are still accepted, even though out-of-spec.
Also fixes adjacent tags not being parsed.

Fixes trac #4915

Signed-off-by: Ricardo Constantino 
---
 libavcodec/webvttdec.c | 11 ++-
 1 file changed, 10 insertions(+), 1 deletion(-)

diff --git a/libavcodec/webvttdec.c b/libavcodec/webvttdec.c
index 1284a17..fb1a422 100644
--- a/libavcodec/webvttdec.c
+++ b/libavcodec/webvttdec.c
@@ -37,11 +37,14 @@ static const struct {
 {"", "{\\b1}"}, {"", "{\\b0}"},
 {"", "{\\u1}"}, {"", "{\\u0}"},
 {"{", "\\{"}, {"}", "\\}"}, // escape to avoid ASS markup conflicts
+{"", ">"}, {"", "<"},
+{"", ""}, {"", ""}, // FIXME: properly honor bidi marks
+{"", "&"}, {"", "\\h"},
 };
 
 static int webvtt_event_to_ass(AVBPrint *buf, const char *p)
 {
-int i, skip = 0;
+int i, again, skip = 0;
 
 while (*p) {
 
@@ -51,12 +54,18 @@ static int webvtt_event_to_ass(AVBPrint *buf, const char *p)
 if (!strncmp(p, from, len)) {
 av_bprintf(buf, "%s", webvtt_tag_replace[i].to);
 p += len;
+again = 1;
 break;
 }
 }
 if (!*p)
 break;
 
+if (again) {
+again = 0;
+skip = 0;
+continue;
+}
 if (*p == '<')
 skip = 1;
 else if (*p == '>')
-- 
2.6.0

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

[FFmpeg-devel] [PATCH 2/3] avformat/webvttdec: Don't stop parsing on comments

[Ricardo Constantino]

Signed-off-by: Ricardo Constantino 
---
 libavformat/webvttdec.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/libavformat/webvttdec.c b/libavformat/webvttdec.c
index 43c2a63..47a3255 100644
--- a/libavformat/webvttdec.c
+++ b/libavformat/webvttdec.c
@@ -92,7 +92,8 @@ static int webvtt_read_header(AVFormatContext *s)
 
 /* ignore header chunk */
 if (!strncmp(p, "\xEF\xBB\xBFWEBVTT", 9) ||
-!strncmp(p, "WEBVTT", 6))
+!strncmp(p, "WEBVTT", 6) ||
+!strncmp(p, "NOTE", 4))
 continue;
 
 /* optional cue identifier (can be a number like in SRT or some kind of
-- 
2.6.0

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

Re: [FFmpeg-devel] [PATCH 1/2] x86/vf_w3fdif: move pxor outside the loop in w3fdif_complex_low

[Paul B Mahol]

On 10/11/15, James Almer  wrote:
> Signed-off-by: James Almer 
> ---
>  libavfilter/x86/vf_w3fdif.asm | 8 
>  1 file changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/libavfilter/x86/vf_w3fdif.asm b/libavfilter/x86/vf_w3fdif.asm
> index 988b847..f02319b 100644
> --- a/libavfilter/x86/vf_w3fdif.asm
> +++ b/libavfilter/x86/vf_w3fdif.asm
> @@ -65,11 +65,12 @@ cglobal w3fdif_simple_low, 4, 5, 6, 0, work_line,
> in_lines_cur0, coef, linesize,
>  jg .loop
>  REP_RET
>
> -cglobal w3fdif_complex_low, 4, 7, 7, 0, work_line, in_lines_cur0, coef,
> linesize
> +cglobal w3fdif_complex_low, 4, 7, 8, 0, work_line, in_lines_cur0, coef,
> linesize
>  movq  m0, [coefq]
>  DEFINE_ARGSwork_line, in_lines_cur0, in_lines_cur1, linesize,
> offset, in_lines_cur2, in_lines_cur3
>  pshufdm2, m0, q
>  SPLATDm0
> +pxor  m1, m1
>  mov  offsetq, 0
>  mov   in_lines_cur3q, [in_lines_cur0q+gprsize*3]
>  mov   in_lines_cur2q, [in_lines_cur0q+gprsize*2]
> @@ -79,17 +80,16 @@ cglobal w3fdif_complex_low, 4, 7, 7, 0, work_line,
> in_lines_cur0, coef, linesize
>  .loop:
>  movh   m4, [in_lines_cur0q+offsetq]
>  movh   m5, [in_lines_cur1q+offsetq]
> -pxor   m1, m1
>  punpcklbw  m4, m1
>  punpcklbw  m5, m1
> -SBUTTERFLY wd, 4, 5, 3
> +SBUTTERFLY wd, 4, 5, 7
>  pmaddwdm4, m0
>  pmaddwdm5, m0
>  movh   m6, [in_lines_cur2q+offsetq]
>  movh   m3, [in_lines_cur3q+offsetq]
>  punpcklbw  m6, m1
>  punpcklbw  m3, m1
> -SBUTTERFLY wd, 6, 3, 1
> +SBUTTERFLY wd, 6, 3, 7
>  pmaddwdm6, m2
>  pmaddwdm3, m2
>  paddd  m4, m6
> --
> 2.6.0
>
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>

fine if it still works on x32.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] configure: fix configure when using gcc

[Ganesh Ajjanagadde]

On Sun, Oct 11, 2015 at 12:50 PM, Timothy Gu  wrote:
> On Sun, Oct 11, 2015 at 8:21 AM Ganesh Ajjanagadde 
> wrote:
>>
>> Fixes Ticket4922.
>>
>> Commit 060102389e572abb2beaed3b9f5e1036aeea43f1 broke configure.
>>
>> From: Jean-Yves Avenard 
>
>
> You might want to use `git commit --author` instead of manually adding a
> "From" line in the commit message body.

will change, thanks

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

Re: [FFmpeg-devel] av_ctz optimization

[Ganesh Ajjanagadde]

On Sun, Oct 11, 2015 at 12:33 PM, Timothy Gu  wrote:
> On Sun, Oct 11, 2015 at 9:10 AM Ganesh Ajjanagadde  wrote:
>
>> Isn't that an API change and not an ABI change (it was in doc/APIchanges)?
>>
>
> No, since intmath.h is not public.

So basically av_ctz was a bungled operation. Someone needed it for
flacdec, and decided to add it to intmath with the av_ prefix. We
should get rid of this while we still have the window available. As
obviously I do not know what is API/ABI clearly enough, I will refrain
from sending a patch and leave it in more capable hands.

>
> Timothy
> ___
> 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 1/2] x86/vf_w3fdif: move pxor outside the loop in w3fdif_complex_low

[James Almer]

On 10/11/2015 1:28 PM, Paul B Mahol wrote:
> On 10/11/15, James Almer  wrote:
>> Signed-off-by: James Almer 
>> ---
>>  libavfilter/x86/vf_w3fdif.asm | 8 
>>  1 file changed, 4 insertions(+), 4 deletions(-)
>>
>> diff --git a/libavfilter/x86/vf_w3fdif.asm b/libavfilter/x86/vf_w3fdif.asm
>> index 988b847..f02319b 100644
>> --- a/libavfilter/x86/vf_w3fdif.asm
>> +++ b/libavfilter/x86/vf_w3fdif.asm
>> @@ -65,11 +65,12 @@ cglobal w3fdif_simple_low, 4, 5, 6, 0, work_line,
>> in_lines_cur0, coef, linesize,
>>  jg .loop
>>  REP_RET
>>
>> -cglobal w3fdif_complex_low, 4, 7, 7, 0, work_line, in_lines_cur0, coef,
>> linesize
>> +cglobal w3fdif_complex_low, 4, 7, 8, 0, work_line, in_lines_cur0, coef,
>> linesize
>>  movq  m0, [coefq]
>>  DEFINE_ARGSwork_line, in_lines_cur0, in_lines_cur1, linesize,
>> offset, in_lines_cur2, in_lines_cur3
>>  pshufdm2, m0, q
>>  SPLATDm0
>> +pxor  m1, m1
>>  mov  offsetq, 0
>>  mov   in_lines_cur3q, [in_lines_cur0q+gprsize*3]
>>  mov   in_lines_cur2q, [in_lines_cur0q+gprsize*2]
>> @@ -79,17 +80,16 @@ cglobal w3fdif_complex_low, 4, 7, 7, 0, work_line,
>> in_lines_cur0, coef, linesize
>>  .loop:
>>  movh   m4, [in_lines_cur0q+offsetq]
>>  movh   m5, [in_lines_cur1q+offsetq]
>> -pxor   m1, m1
>>  punpcklbw  m4, m1
>>  punpcklbw  m5, m1
>> -SBUTTERFLY wd, 4, 5, 3
>> +SBUTTERFLY wd, 4, 5, 7
>>  pmaddwdm4, m0
>>  pmaddwdm5, m0
>>  movh   m6, [in_lines_cur2q+offsetq]
>>  movh   m3, [in_lines_cur3q+offsetq]
>>  punpcklbw  m6, m1
>>  punpcklbw  m3, m1
>> -SBUTTERFLY wd, 6, 3, 1
>> +SBUTTERFLY wd, 6, 3, 7
>>  pmaddwdm6, m2
>>  pmaddwdm3, m2
>>  paddd  m4, m6
>> --
>> 2.6.0
>>
>> ___
>> ffmpeg-devel mailing list
>> ffmpeg-devel@ffmpeg.org
>> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>>
> 
> fine if it still works on x32.

8 xmm regs, so yes.

Pushed, thanks.

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

Re: [FFmpeg-devel] [PATCH] avformat/rtmpcrypt: fix discarded const warning

[Ganesh Ajjanagadde]

On Fri, Sep 18, 2015 at 5:02 PM, Michael Niedermayer  wrote:
> On Fri, Sep 18, 2015 at 09:50:29PM +0200, Nicolas George wrote:
>> Le jour du Génie, an CCXXIII, Ganesh Ajjanagadde a écrit :
>> > This patch silences a -Wdiscarded-qualifiers observed with GCC 5.2.
>> >
>> > Signed-off-by: Ganesh Ajjanagadde 
>> > ---
>> >  libavformat/rtmpcrypt.c | 2 +-
>> >  1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> I am not sure this is correct: the buffer is const for a reason, the warning
>> is right. An application would be completely allowed to give a buffer in
>> read-only memory, or to reuse the contents of the buffer afterwards.
>>
>> Actually, I suspect this muxer, if used as first output in the tee muxer,
>> would cause the next outputs to be corrupt.
>
> IIRC the code is safe, just ugly
> the writing only occurs if handshaked is set, which is only set
> by ff_rtmpe_update_keystream() which is not part of the public
> interface and only called from libavformat/rtmpproto.c
> i assume but did not double check that libavformat/rtmpproto.c
> calls the functions so that writable buffers are used
>
>
>>
>> The correct fix would probably be to allocate a new buffer, probably keeping
>> it in the context for performances reasons instead of allocating each time.
>
> id need to double check but i think the calling code possibly uses
> the written buffer with the expectation that it has been updated
>
> if that is so then such fix would break it.

Have you checked the code and confirmed that this patch is fine?

>
> [...]
>
> --
> Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
>
> What does censorship reveal? It reveals fear. -- Julian Assange
>
> ___
> 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] ffplay: log possible error of SDL_EnableKeyRepeat

[Ganesh Ajjanagadde]

On Fri, Oct 9, 2015 at 9:03 AM, Ganesh Ajjanagadde  wrote:
> On Fri, Oct 9, 2015 at 4:21 AM, wm4  wrote:
>> On Thu,  8 Oct 2015 18:46:44 -0400
>> Ganesh Ajjanagadde  wrote:
>>
>>> Note that for the current SDL source code, 0 is always returned.
>>> Nevertheless, this makes the code more robust.
>>>
>>> Signed-off-by: Ganesh Ajjanagadde 
>>> ---
>>>  ffplay.c | 3 ++-
>>>  1 file changed, 2 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/ffplay.c b/ffplay.c
>>> index 79f430d..c143e96 100644
>>> --- a/ffplay.c
>>> +++ b/ffplay.c
>>> @@ -3814,7 +3814,8 @@ int main(int argc, char **argv)
>>>  SDL_EventState(SDL_SYSWMEVENT, SDL_IGNORE);
>>>  SDL_EventState(SDL_USEREVENT, SDL_IGNORE);
>>>
>>> -SDL_EnableKeyRepeat(SDL_DEFAULT_REPEAT_DELAY, 
>>> SDL_DEFAULT_REPEAT_INTERVAL);
>>> +if (SDL_EnableKeyRepeat(SDL_DEFAULT_REPEAT_DELAY, 
>>> SDL_DEFAULT_REPEAT_INTERVAL) < 0)
>>> +av_log(NULL, AV_LOG_ERROR, "SDL_EnableKeyRepeat(): %s\n", 
>>> SDL_GetError());
>>>
>>>  if (av_lockmgr_register(lockmgr)) {
>>>  av_log(NULL, AV_LOG_FATAL, "Could not initialize lock manager!\n");
>>
>> How does this make the code more "robust"?
>
> If in future some limitations are placed on the repeat delay/repeat
> interval apart from nonnegativity, or if someone accidentally changes
> the repeat delay to e.g something dynamic and forgot to check that it
> is > 0, etc we would get a log message from ffplay allowing quick
> fixing of the issue.
>
> I don't know if "robust" is the right word for it, maybe "more complete"?

I drop this patch, on reflection I am anyway ambivalent to it - it
increases the code verbosity for minimal gain: in the event that the
delay values are changed, this code will anyway be examine; logging
for debugging purposes is not really that helpful.

>
>> ___
>> 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] avformat/rtmpcrypt: fix discarded const warning

[Ronald S. Bultje]

Hi,

On Sun, Oct 11, 2015 at 2:35 PM, Ganesh Ajjanagadde 
wrote:

> On Sun, Oct 11, 2015 at 2:33 PM, Ronald S. Bultje 
> wrote:
> > Hi,
> >
> > On Sun, Oct 11, 2015 at 2:15 PM, Ganesh Ajjanagadde 
> > wrote:
> >
> >> On Fri, Sep 18, 2015 at 5:02 PM, Michael Niedermayer 
> >> wrote:
> >> > On Fri, Sep 18, 2015 at 09:50:29PM +0200, Nicolas George wrote:
> >> >> Le jour du Génie, an CCXXIII, Ganesh Ajjanagadde a écrit :
> >> >> > This patch silences a -Wdiscarded-qualifiers observed with GCC 5.2.
> >> >> >
> >> >> > Signed-off-by: Ganesh Ajjanagadde 
> >> >> > ---
> >> >> >  libavformat/rtmpcrypt.c | 2 +-
> >> >> >  1 file changed, 1 insertion(+), 1 deletion(-)
> >> >>
> >> >> I am not sure this is correct: the buffer is const for a reason, the
> >> warning
> >> >> is right. An application would be completely allowed to give a
> buffer in
> >> >> read-only memory, or to reuse the contents of the buffer afterwards.
> >> >>
> >> >> Actually, I suspect this muxer, if used as first output in the tee
> >> muxer,
> >> >> would cause the next outputs to be corrupt.
> >> >
> >> > IIRC the code is safe, just ugly
> >> > the writing only occurs if handshaked is set, which is only set
> >> > by ff_rtmpe_update_keystream() which is not part of the public
> >> > interface and only called from libavformat/rtmpproto.c
> >> > i assume but did not double check that libavformat/rtmpproto.c
> >> > calls the functions so that writable buffers are used
> >> >
> >> >
> >> >>
> >> >> The correct fix would probably be to allocate a new buffer, probably
> >> keeping
> >> >> it in the context for performances reasons instead of allocating each
> >> time.
> >> >
> >> > id need to double check but i think the calling code possibly uses
> >> > the written buffer with the expectation that it has been updated
> >> >
> >> > if that is so then such fix would break it.
> >>
> >> Have you checked the code and confirmed that this patch is fine?
> >
> >
> > I don't think the explanation makes the patch fine, the explanation just
> > says that there's no actual issue being hidden behind the warning. It
> > sounds like this code needs some refactoring...
>
> Unfortunately, I can't see a clean solution to this without changing some
> API.


Right, sorry, I was unclear; I do indeed think we need some API changes to
allow calling this code with a const buffer, with the actual constraint
being that it indeed does not get updated (which, according to Michael, is
usually the case), and then an additional second call which has a non-const
buffer that gets updated (as expected by rtmp).

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

Re: [FFmpeg-devel] setting up a proper Github mirror

[Ganesh Ajjanagadde]

On Sun, Oct 11, 2015 at 3:09 PM, Timothy Gu  wrote:
> On Sun, Oct 11, 2015 at 11:44 AM Ganesh Ajjanagadde 
> wrote:
>
>> I noticed that the Github mirror: https://github.com/FFmpeg/FFmpeg is
>> over 3 hours out of sync with the main repos, making it unusable as a
>> fetch url for development. Anyone knows why this is the case?
>>
>
> It is not an automatic mirror, and it is only updated when Michael or I
> pushes since a) only three people have been added to the FFmpeg
> organization and b) only Michael and I bothered to add Git aliases.
>
> Same goes for the other repos.

Can't this be done through a post-commit/receive hook:
https://help.github.com/articles/about-github-mirrors/?

Alternatively (for now, more sustainable is a proper hook), could you
post here your alias to do this?

>
> Also, it looks like one can set some fancy UI illustrating that it is
>> a mirror, see for instance: https://github.com/coreutils/coreutils.
>> Anyone knows how to do this?
>>
>
> One has to contact GitHub for it. I tried doing that a long time ago but
> they said they would do it only if Michael asked for it, and I didn't
> bother.
>
> Plus the mirror symbol doesn't offer any advantages:
>
> 1. pull requests still cannot be disabled
> 2. one still has to manually push to the GitHub mirror, either by hand or
> through a receive hook on the server IIRC

It is still perhaps slightly helpful from a UI perspective: people are
further tuned to the fact that Github is just for hosting FFmpeg;
development is elsewhere.

>
> Timothy
> ___
> 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] intmath: remove av_ctz.

[Timothy Gu]

On Sun, Oct 11, 2015 at 11:29 AM Ronald S. Bultje 
wrote:

> It's an a non-installed header and only used in one place (flacenc).
> Since ff_ctz is static inline, it's fine to use that instead.
> ---
>  libavcodec/flacenc.c | 2 +-
>  libavutil/intmath.c  | 5 -
>  libavutil/intmath.h  | 8 
>  3 files changed, 1 insertion(+), 14 deletions(-)
>

Should we change ff_ctz to avpriv_ctz? Using a ff_ from another library
just doesn't look right. (Or we could remove the prefix like emms_c but
ctz() sounds too generic)

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

Re: [FFmpeg-devel] [PATCH] avcodec/h264: remove redundant and bogus get_format call

[Michael Niedermayer]

On Sun, Oct 11, 2015 at 07:05:27PM +0200, wm4 wrote:
> The AVCodecContext.get_format callback is not only used for pixel format
> negotiation with the API user, but also for hwaccel init. For the
> latter, it's required that some codec parameters, in particular the
> codec profile, are set when the callback is invoked.
> 
> This patch removes a get_format invocation where this is not guaranteed.
> The codec parameters, including the profile, are really set further
> below. (The same code path that sets the profile also calls get_format
> properly too.)
> 
> This just happened to work by coincidence in most cases. For example, if
> the API user just copied or reused the AVStream's AVCodecContext when
> decoding, the profile would be set properly. But in some cases it
> fails., such as with the sample WolfensteinTwitch.mp4 on the samples
> server.
> 
> Remove the redundant get_format call. Apparently it serves no purpose
> anymore, although it is possible that this was different at the time it
> was added in commit ffd77f94a26be22b8ead3178ceec3ed39e68abc5.
> 
> This fixes hwaccel usage for API users which do not set the profile
> when setting up the AVCodecContext (which is allowed).
> ---
>  libavcodec/h264_slice.c | 14 --
>  1 file changed, 14 deletions(-)

ive posted an alternative patchset of 2 patches which should prevent
get_format() from being called. That would leave the check in place

I couldnt reproduce the problem with command line FFmpeg though,
Also i dont object to this patch here, if people prefer it but iam not
sure that the test is really redundant

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

Its not that you shouldnt use gotos but rather that you should write
readable code and code with gotos often but not always is less readable


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

Re: [FFmpeg-devel] [PATCH] configure: fix configure when using gcc

[Nicolas George]

Le decadi 20 vendémiaire, an CCXXIV, Ganesh Ajjanagadde a écrit :
> Fixes Ticket4922.
> 
> Commit 060102389e572abb2beaed3b9f5e1036aeea43f1 broke configure.

The commit message could be a little more explicit: it forgot the ! that
inverted the result.

Also, it seems that the test went from '2.' to just '2', maybe it should be
fixed as well.

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/9] dnxhdenc: fix scan used for bitstream generation

[Michael Niedermayer]

On Sun, Oct 11, 2015 at 04:06:05PM +0200, Christophe Gisquet wrote:
> The functions related to bitstream reading must use the natural zigzag
> order, and not the one permuted for use in the iDCT. This currently
> results in bitstreams with 2 issues:
> - AC coefficients are encoded in an unexpected order;
> - Incorrect weights are applied in the (de)quantization.
> 
> This currently can't show up because there's no simple_idct which
> requires a permutation.
> 
> With one that does (based on prores'), and using the following source:
> -f lavfi -i testsrc=s=1920x1080 -vframes 1 -pix_fmt yuv422p10le
> and encoding to CID 1241 (interlaced 1080p YUV422) using:
> -vcodec dnxhd -flags +ildct -vb 185M
> 
> before: stddev:   55.57 PSNR: 61.43 MAXDIFF:  960
> after:  stddev:0.35 PSNR:105.45 MAXDIFF:   11
> ---
>  libavcodec/dnxhdenc.c | 12 +++-
>  1 file changed, 7 insertions(+), 5 deletions(-)

breaks:
./ffmpeg -f lavfi -i testsrc=s=1920x1080 -vframes 1 -pix_fmt yuv422p -vcodec 
dnxhd -flags +ildct -vb 185M test.mov

and thinking about it a bit more (which i should have done earlier)
i suspect it to break every 8bit case
the fdct permutes its output if the idct_permutation is set so its
output is ready for the idct in hybrid coders like h26x
the idct_permutation used by the fdct is not set to the identity
permutation so that either need to be changed or idct_permutation
must be used when encoding the coefficients
or maybe something else and this analysis is wrong ...

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

The real ebay dictionary, page 1
"Used only once"- "Some unspecified defect prevented a second use"
"In good condition" - "Can be repaird by experienced expert"
"As is" - "You wouldnt want it even if you were payed for it, if you knew ..."


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

Re: [FFmpeg-devel] [PATCHv2] avutil/mathematics: speed up av_gcd by using Stein's binary GCD algorithm

[wm4]

On Sun, 11 Oct 2015 09:59:39 -0400
Ganesh Ajjanagadde  wrote:

> On Sun, Oct 11, 2015 at 9:34 AM, wm4  wrote:
> > On Sat, 10 Oct 2015 21:58:47 -0400
> > Ganesh Ajjanagadde  wrote:
> >
> >> This uses Stein's binary GCD algorithm:
> >> https://en.wikipedia.org/wiki/Binary_GCD_algorithm
> >> to get a roughly 4x speedup over Euclidean GCD on standard architectures
> >> with a compiler intrinsic for ctzll, and a roughly 2x speedup otherwise.
> >> At the moment, the compiler intrinsic is used on GCC and Clang due to
> >> its easy availability.
> >>
> >> Quick note regarding overflow: yes, subtractions on int64_t can, but the
> >> llabs takes care of that. The llabs is also guaranteed to be safe, with
> >> no annoying INT64_MIN business since INT64_MIN being a power of 2, is
> >> shifted down before being sent to llabs.
> >>
> >> The binary GCD needs ff_ctzll, an extension of ff_ctz for long long 
> >> (int64_t). On
> >> GCC, this is provided by a built-in. On Microsoft, there is a
> >> BitScanForward64 analog of BitScanForward that should work; but I can't 
> >> confirm.
> >> Apparently it is not available on 32 bit builds; so this may or may not
> >> work correctly. On Intel, per the documentation there is only an
> >> intrinsic for _bit_scan_forward and people have posted on forums
> >> regarding _bit_scan_forward64, but often their documentation is
> >> woeful. Again, I don't have it, so I can't test.
> >>
> >> As such, to be safe, for now only the GCC/Clang intrinsic is added, the 
> >> rest
> >> use a compiled version based on the De-Bruijn method of Leiserson et al:
> >> http://supertech.csail.mit.edu/papers/debruijn.pdf.
> >>
> >> Tested with FATE, sample benchmark (x86-64, GCC 5.2.0, Haswell)
> >> with a START_TIMER and STOP_TIMER in libavutil/rationsl.c, followed by a
> >> make fate.
> >>
> >> aac-am00_88.err:
> >> builtin:
> >> 714 decicycles in av_gcd,4095 runs,  1 skips
> >>
> >> de-bruijn:
> >> 1440 decicycles in av_gcd,4096 runs,  0 skips
> >>
> >> previous:
> >> 2889 decicycles in av_gcd,4096 runs,  0 skips
> >>
> >> Signed-off-by: Ganesh Ajjanagadde 
> >> ---
> >>  libavutil/intmath.h | 19 +++
> >>  libavutil/mathematics.c | 26 +-
> >>  2 files changed, 40 insertions(+), 5 deletions(-)
> >>
> >> diff --git a/libavutil/intmath.h b/libavutil/intmath.h
> >> index 08d54a6..b412385 100644
> >> --- a/libavutil/intmath.h
> >> +++ b/libavutil/intmath.h
> >> @@ -114,6 +114,9 @@ static av_always_inline av_const int 
> >> ff_log2_16bit_c(unsigned int v)
> >>  #ifndef ff_ctz
> >>  #define ff_ctz(v) __builtin_ctz(v)
> >>  #endif
> >> +#ifndef ff_ctzll
> >> +#define ff_ctzll(v) __builtin_ctzll(v)
> >> +#endif
> >>  #endif
> >>  #endif
> >>
> >> @@ -158,6 +161,22 @@ static av_always_inline av_const int ff_ctz_c( int v )
> >>  #endif
> >>  #endif
> >>
> >> +#ifndef ff_ctzll
> >> +#define ff_ctzll ff_ctzll_c
> >> +/* We use the De-Bruijn method outlined in:
> >> + * http://supertech.csail.mit.edu/papers/debruijn.pdf. */
> >> +static av_always_inline av_const int ff_ctzll_c(long long v)
> >> +{
> >> +static const int debruijn_ctz64[64] = {
> >> +0, 1, 2, 53, 3, 7, 54, 27, 4, 38, 41, 8, 34, 55, 48, 28,
> >> +62, 5, 39, 46, 44, 42, 22, 9, 24, 35, 59, 56, 49, 18, 29, 11,
> >> +63, 52, 6, 26, 37, 40, 33, 47, 61, 45, 43, 21, 23, 58, 17, 10,
> >> +51, 25, 36, 32, 60, 20, 57, 16, 50, 31, 19, 15, 30, 14, 13, 12
> >> +};
> >> +return debruijn_ctz64[(uint64_t)((v & -v) * 0x022FDD63CC95386D) >> 
> >> 58];
> >> +}
> >> +#endif
> >> +
> >
> > Is this duplicated from somewhere?
> 
> It may be obtained from a number of sources (or generated onself from
> the link I gave, which actually is an original source):
> "The De Bruijn bitscan was devised in 1997, according to Donald Knuth
> [3] by Martin Läuter, and independently by Charles Leiserson, Harald
> Prokop and Keith H. Randall a few month later." (I use the Leiserson
> et al reference in the code).
> 
> It is not a unique sequence, there are many available on the web:
> https://chessprogramming.wikispaces.com/BitScan,
> https://gist.github.com/deffi420/e700f0adefc82f28c0d7 (the sequence I
> randomly picked).

I just thought I've seen this somewhere else in libav*, but I didn't
find anything. Ignore me.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] configure: fix configure when using gcc

[Ganesh Ajjanagadde]

On Sun, Oct 11, 2015 at 12:23 PM, Nicolas George  wrote:
> Le decadi 20 vendémiaire, an CCXXIV, Ganesh Ajjanagadde a écrit :
>> I am not so sure, there was a reason for it documented in the
>> 060102389e572abb2beaed3b9f5e1036aeea43f1 commit message.
>
> Indeed. We have until gcc version 20 to find a solution.

That is a long time hopefully (estimated 15+ years), unless gcc starts
pulling a "fast release" cycle like Firefox or Chrome. Who knows, by
that time the bleeding mess that is multimedia might get sorted out,
and FFmpeg would have reached a stage of perfection where we can all
just sit back and relax, looking back on all these years with
satisfaction (and maybe some nostalgia) on our faces.

>
> 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] [PATCHv2] doc/developer: add note on patches that fix warnings

[Ganesh Ajjanagadde]

On Tue, Oct 6, 2015 at 6:55 PM, Ganesh Ajjanagadde
 wrote:
> This adds some recommendations while submitting patches that fix warnings.
>
> Signed-off-by: Ganesh Ajjanagadde 
> ---
>  doc/developer.texi | 6 ++
>  1 file changed, 6 insertions(+)
>
> diff --git a/doc/developer.texi b/doc/developer.texi
> index b8259e7..4d0fc9f 100644
> --- a/doc/developer.texi
> +++ b/doc/developer.texi
> @@ -391,6 +391,12 @@ be changed to not generate a warning unless that causes 
> a slowdown
>  or obfuscates the code.
>
>  @item
> +While fixing compiler warnings, please add some information to the commit
> +message body indicating the toolchain configuration.
> +This is very helpful for future maintainers since it eases possible
> +modifications when the toolchain gets updated.
> +
> +@item
>  Make sure that no parts of the codebase that you maintain are missing from 
> the
>  @file{MAINTAINERS} file. If something that you want to maintain is missing 
> add it with
>  your name after it.
> --
> 2.6.1
>

Anyone thinks this is useful? I can't really say: regular developers
anyway know this, and drive-by/sporadic contributions are highly
unlikely to be warning fixes.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

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

[Ronald S. Bultje]

Hi,

On Sun, Oct 11, 2015 at 2:20 PM, Ganesh Ajjanagadde 
wrote:

> On Wed, Oct 7, 2015 at 10:18 AM, Ganesh Ajjanagadde 
> wrote:
> > On Wed, Oct 7, 2015 at 10:01 AM, Clément Bœsch  wrote:
> >> On Wed, Oct 07, 2015 at 09:31:49AM -0400, Ganesh Ajjanagadde wrote:
> >>> On Wed, Oct 7, 2015 at 8:59 AM, Clément Bœsch  wrote:
> >>> > On Tue, Oct 06, 2015 at 06:53:47PM -0400, Ganesh Ajjanagadde wrote:
> >>> >> 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);
> >>> >>
> >>> >
> >>> > Aren't you just supposed to (void)-prefix the call in the caller
> when you
> >>> > explicitly don't care about the result?
> >>> >
> >>> > These functions certainly looks like you actually want to check for
> the
> >>> > result most of the time.
> >>>
> >>> Exactly - this addition to the declaration in the header will trigger
> >>> a warning whenever this function is used without obtaining the return
> >>> value.
> >>>
> >>
> >> Oh, my bad, I misunderstood, sounds indeed saner than what I had in
> mind.
> >>
> >> Thanks for the clarification.
> >
> > By the way, I highly encourage all developers to slowly start adding
> > this to relevant headers, at least in the things they respectively
> > maintain. For instance, a bunch of possible bugs/robustness issues
> > will be fixed. Here is one I noticed today: by applying to
> > init_get_bits8, a few warnings get triggered. There have been commits
> > from Michael addressing some CID's related to this - this will ensure
> > a complete weeding out of that particular issue.
>
> ping


Yes, sorry, pushed.

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

Re: [FFmpeg-devel] [PATCH] avformat/rtmpcrypt: fix discarded const warning

[Ganesh Ajjanagadde]

On Sun, Oct 11, 2015 at 2:33 PM, Ronald S. Bultje  wrote:
> Hi,
>
> On Sun, Oct 11, 2015 at 2:15 PM, Ganesh Ajjanagadde 
> wrote:
>
>> On Fri, Sep 18, 2015 at 5:02 PM, Michael Niedermayer 
>> wrote:
>> > On Fri, Sep 18, 2015 at 09:50:29PM +0200, Nicolas George wrote:
>> >> Le jour du Génie, an CCXXIII, Ganesh Ajjanagadde a écrit :
>> >> > This patch silences a -Wdiscarded-qualifiers observed with GCC 5.2.
>> >> >
>> >> > Signed-off-by: Ganesh Ajjanagadde 
>> >> > ---
>> >> >  libavformat/rtmpcrypt.c | 2 +-
>> >> >  1 file changed, 1 insertion(+), 1 deletion(-)
>> >>
>> >> I am not sure this is correct: the buffer is const for a reason, the
>> warning
>> >> is right. An application would be completely allowed to give a buffer in
>> >> read-only memory, or to reuse the contents of the buffer afterwards.
>> >>
>> >> Actually, I suspect this muxer, if used as first output in the tee
>> muxer,
>> >> would cause the next outputs to be corrupt.
>> >
>> > IIRC the code is safe, just ugly
>> > the writing only occurs if handshaked is set, which is only set
>> > by ff_rtmpe_update_keystream() which is not part of the public
>> > interface and only called from libavformat/rtmpproto.c
>> > i assume but did not double check that libavformat/rtmpproto.c
>> > calls the functions so that writable buffers are used
>> >
>> >
>> >>
>> >> The correct fix would probably be to allocate a new buffer, probably
>> keeping
>> >> it in the context for performances reasons instead of allocating each
>> time.
>> >
>> > id need to double check but i think the calling code possibly uses
>> > the written buffer with the expectation that it has been updated
>> >
>> > if that is so then such fix would break it.
>>
>> Have you checked the code and confirmed that this patch is fine?
>
>
> I don't think the explanation makes the patch fine, the explanation just
> says that there's no actual issue being hidden behind the warning. It
> sounds like this code needs some refactoring...

Unfortunately, I can't see a clean solution to this without changing some API.

>
> 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] .gitignore: some font temporaries

[Ganesh Ajjanagadde]

---
 .gitignore | 1 +
 1 file changed, 1 insertion(+)

diff --git a/.gitignore b/.gitignore
index 0b26f68..b215828 100644
--- a/.gitignore
+++ b/.gitignore
@@ -3,3 +3,4 @@
 /htdocs/main.rss
 /htdocs/components
 /htdocs/style.less
+/htdocs/fonts/*.woff2
-- 
2.6.1

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

Re: [FFmpeg-devel] [PATCH 2/2] avcodec/h264_slice: Never call get_format() for just checking if the format matches

[Hendrik Leppkes]

On Sun, Oct 11, 2015 at 10:43 PM, wm4  wrote:
> On Sun, 11 Oct 2015 21:55:12 +0200
> Michael Niedermayer  wrote:
>
>> On Sun, Oct 11, 2015 at 09:39:32PM +0200, wm4 wrote:
>> > On Sun, 11 Oct 2015 21:16:27 +0200
>> > Michael Niedermayer  wrote:
>> >
>> > > From: Michael Niedermayer 
>> > >
>> > > Signed-off-by: Michael Niedermayer 
>> > > ---
>> > >  libavcodec/h264_slice.c |4 
>> > >  1 file changed, 4 insertions(+)
>> > >
>> > > diff --git a/libavcodec/h264_slice.c b/libavcodec/h264_slice.c
>> > > index cce97d9..daa3737 100644
>> > > --- a/libavcodec/h264_slice.c
>> > > +++ b/libavcodec/h264_slice.c
>> > > @@ -985,6 +985,10 @@ static enum AVPixelFormat 
>> > > get_pixel_format(H264Context *h, int force_callback)
>> > >  for (i=0; choices[i] != AV_PIX_FMT_NONE; i++)
>> > >  if (non_j_pixfmt(choices[i]) == non_j_pixfmt(h->avctx->pix_fmt) 
>> > > && !force_callback)
>> > >  return choices[i];
>> > > +
>> > > +if (!force_callback)
>> > > +return AV_PIX_FMT_NONE;
>> > > +
>> > >  return ff_thread_get_format(h->avctx, choices);
>> > >  }
>> > >
>> >
>> > So if I can see this right, the whole purpose of this is to check
>> > whether the h264 parameters map to a lavc pixfmt, and bail out or
>> > reinitialize if it doesn't. Why can't this be delayed later? What
>> > actually needs it sooner than the first "real" get_format? For dealing
>>
>> > with paramater changes, why can't it check the raw parameters instead?
>>
>> The raw parameters are checked as well but iam not sure these checks
>> are complete, they are more complex.
>>
>
> I've checked again. 3 parameters influence the pixfmt:
> bit_depth_luma, chroma_format_idc, and colorspace. Maybe add
> color_range because of the J formats.  The first two are already
> checked (lazily, if the SPS changes). A colorspace change also triggers
> reinit, although the check for it is buried somewhat deeper in the
> code. (Also I see a potential bug there: are colorspace and other
> fields not reset correctly if the SPS changes, and the new SPS doesn't
> have these fields set anymore?) A changing color_range does not force
> reinit; this must be fixed (although I'd prefer dropping the J hack
> completely).
>
> So do you agree that checks for colorspace and color_range should be
> added, and that they should trigger reinit, and that this combined with
> my patch would fix all the potential issues the patch could introduce?

 Color Range and Color Space should not trigger a re-init, its
pointless and may disrupt playback if a HWAccel re-inits.
The in-memory representaiton, and as such the surface format, do not
change when only these two change, so re-initing makes no sense to me.
I have specifically hacked my local fork to avoid this because it can
disrupt playback.

>
> Note that because of hwaccels, get_format should always be triggered
> if the SPS changes in any way, because some hwaccels might rely on the
> current SPS information.
>
> I'm also questioning why there are so many "clever" fine grained reinit
> checks. Wouldn't it be better to fully reinit every time there is a new
> SPS, and the new SPS is different than the previous SPS on the byte
> level? (Don't worry, I'm only speaking hypothetically.)
>
> ___
> 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 1/9] dnxhdenc: fix scan used for bitstream generation

[Christophe Gisquet]

Hi,

2015-10-11 18:20 GMT+02:00 Michael Niedermayer :
> On Sun, Oct 11, 2015 at 04:06:05PM +0200, Christophe Gisquet wrote:
>> The functions related to bitstream reading must use the natural zigzag
>> order, and not the one permuted for use in the iDCT. This currently
>> results in bitstreams with 2 issues:
>> - AC coefficients are encoded in an unexpected order;
>> - Incorrect weights are applied in the (de)quantization.
>>
>> This currently can't show up because there's no simple_idct which
>> requires a permutation.
>>
>> With one that does (based on prores'), and using the following source:
>> -f lavfi -i testsrc=s=1920x1080 -vframes 1 -pix_fmt yuv422p10le
>> and encoding to CID 1241 (interlaced 1080p YUV422) using:
>> -vcodec dnxhd -flags +ildct -vb 185M
>>
>> before: stddev:   55.57 PSNR: 61.43 MAXDIFF:  960
>> after:  stddev:0.35 PSNR:105.45 MAXDIFF:   11
>> ---
>>  libavcodec/dnxhdenc.c | 12 +++-
>>  1 file changed, 7 insertions(+), 5 deletions(-)
>
> breaks:
> ./ffmpeg -f lavfi -i testsrc=s=1920x1080 -vframes 1 -pix_fmt yuv422p -vcodec 
> dnxhd -flags +ildct -vb 185M test.mov

> and thinking about it a bit more (which i should have done earlier)
> i suspect it to break every 8bit case
> the fdct permutes its output if the idct_permutation is set so its

OK, so that's the issue, and the current dnxhdenc code totally misled me here.

So, actually, it's the quantize function that applies this, and it's
missing from the 10bits version.

In the end, I don't think the code really needs all of this (there's
one single scantable...), but that cleanup is not for now.

I decided to reuse the code from mpegvideo_enc in that matter, so see
the new patch here.

-- 
Christophe


0001-mpegvideo-dnxhdenc-permute-10bits-content.patch
Description: Binary data
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 2/2] avcodec/h264_slice: Never call get_format() for just checking if the format matches

[Michael Niedermayer]

On Sun, Oct 11, 2015 at 10:43:04PM +0200, wm4 wrote:
> On Sun, 11 Oct 2015 21:55:12 +0200
> Michael Niedermayer  wrote:
> 
> > On Sun, Oct 11, 2015 at 09:39:32PM +0200, wm4 wrote:
> > > On Sun, 11 Oct 2015 21:16:27 +0200
> > > Michael Niedermayer  wrote:
> > > 
> > > > From: Michael Niedermayer 
> > > > 
> > > > Signed-off-by: Michael Niedermayer 
> > > > ---
> > > >  libavcodec/h264_slice.c |4 
> > > >  1 file changed, 4 insertions(+)
> > > > 
> > > > diff --git a/libavcodec/h264_slice.c b/libavcodec/h264_slice.c
> > > > index cce97d9..daa3737 100644
> > > > --- a/libavcodec/h264_slice.c
> > > > +++ b/libavcodec/h264_slice.c
> > > > @@ -985,6 +985,10 @@ static enum AVPixelFormat 
> > > > get_pixel_format(H264Context *h, int force_callback)
> > > >  for (i=0; choices[i] != AV_PIX_FMT_NONE; i++)
> > > >  if (non_j_pixfmt(choices[i]) == 
> > > > non_j_pixfmt(h->avctx->pix_fmt) && !force_callback)
> > > >  return choices[i];
> > > > +
> > > > +if (!force_callback)
> > > > +return AV_PIX_FMT_NONE;
> > > > +
> > > >  return ff_thread_get_format(h->avctx, choices);
> > > >  }
> > > >  
> > > 
> > > So if I can see this right, the whole purpose of this is to check
> > > whether the h264 parameters map to a lavc pixfmt, and bail out or
> > > reinitialize if it doesn't. Why can't this be delayed later? What
> > > actually needs it sooner than the first "real" get_format? For dealing
> > 
> > > with paramater changes, why can't it check the raw parameters instead?
> > 
> > The raw parameters are checked as well but iam not sure these checks
> > are complete, they are more complex.
> > 
> 
> I've checked again. 3 parameters influence the pixfmt:
> bit_depth_luma, chroma_format_idc, and colorspace. Maybe add
> color_range because of the J formats.  The first two are already
> checked (lazily, if the SPS changes). A colorspace change also triggers
> reinit, although the check for it is buried somewhat deeper in the
> code. (Also I see a potential bug there: are colorspace and other
> fields not reset correctly if the SPS changes, and the new SPS doesn't
> have these fields set anymore?) A changing color_range does not force
> reinit; this must be fixed (although I'd prefer dropping the J hack
> completely).
> 
> So do you agree that checks for colorspace and color_range should be
> added, and that they should trigger reinit, and that this combined with
> my patch would fix all the potential issues the patch could introduce?
> 
> Note that because of hwaccels, get_format should always be triggered
> if the SPS changes in any way, because some hwaccels might rely on the
> current SPS information.
> 
> I'm also questioning why there are so many "clever" fine grained reinit
> checks. Wouldn't it be better to fully reinit every time there is a new
> SPS, and the new SPS is different than the previous SPS on the byte
> level? (Don't worry, I'm only speaking hypothetically.)

i suspect that would break some file somewhere somehow

but iam happy with anything that works

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

Why not whip the teacher when the pupil misbehaves? -- Diogenes of Sinope


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

[FFmpeg-devel] [PATCH] avcodec: remove leftover iff_byterun1 decoder

[Andreas Cadhalpun]

It was merged with the iff_ilbm decoder in commit
929a24efff9a208a52748605eb412ffb915c1403.

Define AV_CODEC_ID_IFF_BYTERUN1 as AV_CODEC_ID_IFF_ILBM for API
compatibility.

Signed-off-by: Andreas Cadhalpun 
---

This changes ABI, but that should be still OK.

---
 libavcodec/Makefile |  1 -
 libavcodec/allcodecs.c  |  1 -
 libavcodec/avcodec.h|  2 +-
 libavcodec/codec_desc.c |  7 ---
 libavcodec/iff.c| 13 -
 libavcodec/utils.c  |  2 +-
 tests/fate/video.mak|  2 +-
 7 files changed, 3 insertions(+), 25 deletions(-)

diff --git a/libavcodec/Makefile b/libavcodec/Makefile
index fc0b584..7a576fd 100644
--- a/libavcodec/Makefile
+++ b/libavcodec/Makefile
@@ -312,7 +312,6 @@ OBJS-$(CONFIG_HUFFYUV_DECODER) += huffyuv.o 
huffyuvdec.o
 OBJS-$(CONFIG_HUFFYUV_ENCODER) += huffyuv.o huffyuvenc.o
 OBJS-$(CONFIG_IDCIN_DECODER)   += idcinvideo.o
 OBJS-$(CONFIG_IDF_DECODER) += bintext.o cga_data.o
-OBJS-$(CONFIG_IFF_BYTERUN1_DECODER)+= iff.o
 OBJS-$(CONFIG_IFF_ILBM_DECODER)+= iff.o
 OBJS-$(CONFIG_IMC_DECODER) += imc.o
 OBJS-$(CONFIG_INDEO2_DECODER)  += indeo2.o
diff --git a/libavcodec/allcodecs.c b/libavcodec/allcodecs.c
index 3870cf6..c8f7992 100644
--- a/libavcodec/allcodecs.c
+++ b/libavcodec/allcodecs.c
@@ -203,7 +203,6 @@ void avcodec_register_all(void)
 REGISTER_DECODER(HQX,   hqx);
 REGISTER_ENCDEC (HUFFYUV,   huffyuv);
 REGISTER_DECODER(IDCIN, idcin);
-REGISTER_DECODER(IFF_BYTERUN1,  iff_byterun1);
 REGISTER_DECODER(IFF_ILBM,  iff_ilbm);
 REGISTER_DECODER(INDEO2,indeo2);
 REGISTER_DECODER(INDEO3,indeo3);
diff --git a/libavcodec/avcodec.h b/libavcodec/avcodec.h
index 22a68fb..9b7ab3c 100644
--- a/libavcodec/avcodec.h
+++ b/libavcodec/avcodec.h
@@ -241,7 +241,7 @@ enum AVCodecID {
 AV_CODEC_ID_ANM,
 AV_CODEC_ID_BINKVIDEO,
 AV_CODEC_ID_IFF_ILBM,
-AV_CODEC_ID_IFF_BYTERUN1,
+#define AV_CODEC_ID_IFF_BYTERUN1 AV_CODEC_ID_IFF_ILBM
 AV_CODEC_ID_KGV1,
 AV_CODEC_ID_YOP,
 AV_CODEC_ID_VP8,
diff --git a/libavcodec/codec_desc.c b/libavcodec/codec_desc.c
index da8d658..6076c41 100644
--- a/libavcodec/codec_desc.c
+++ b/libavcodec/codec_desc.c
@@ -877,13 +877,6 @@ static const AVCodecDescriptor codec_descriptors[] = {
 .props = AV_CODEC_PROP_LOSSY,
 },
 {
-.id= AV_CODEC_ID_IFF_BYTERUN1,
-.type  = AVMEDIA_TYPE_VIDEO,
-.name  = "iff_byterun1",
-.long_name = NULL_IF_CONFIG_SMALL("IFF ByteRun1"),
-.props = AV_CODEC_PROP_LOSSY,
-},
-{
 .id= AV_CODEC_ID_KGV1,
 .type  = AVMEDIA_TYPE_VIDEO,
 .name  = "kgv1",
diff --git a/libavcodec/iff.c b/libavcodec/iff.c
index 9d1f9a7..49df17c 100644
--- a/libavcodec/iff.c
+++ b/libavcodec/iff.c
@@ -890,16 +890,3 @@ AVCodec ff_iff_ilbm_decoder = {
 .capabilities   = AV_CODEC_CAP_DR1,
 };
 #endif
-#if CONFIG_IFF_BYTERUN1_DECODER
-AVCodec ff_iff_byterun1_decoder = {
-.name   = "iff",
-.long_name  = NULL_IF_CONFIG_SMALL("IFF"),
-.type   = AVMEDIA_TYPE_VIDEO,
-.id = AV_CODEC_ID_IFF_BYTERUN1,
-.priv_data_size = sizeof(IffContext),
-.init   = decode_init,
-.close  = decode_end,
-.decode = decode_frame,
-.capabilities   = AV_CODEC_CAP_DR1,
-};
-#endif
diff --git a/libavcodec/utils.c b/libavcodec/utils.c
index 7bfd760..1751067 100644
--- a/libavcodec/utils.c
+++ b/libavcodec/utils.c
@@ -409,7 +409,7 @@ void avcodec_align_dimensions2(AVCodecContext *s, int 
*width, int *height,
 break;
 }
 
-if (s->codec_id == AV_CODEC_ID_IFF_ILBM || s->codec_id == 
AV_CODEC_ID_IFF_BYTERUN1) {
+if (s->codec_id == AV_CODEC_ID_IFF_ILBM) {
 w_align = FFMAX(w_align, 8);
 }
 
diff --git a/tests/fate/video.mak b/tests/fate/video.mak
index a575434..a0a7079 100644
--- a/tests/fate/video.mak
+++ b/tests/fate/video.mak
@@ -198,7 +198,7 @@ fate-hap-chunk: CMD = framecrc -i 
$(TARGET_SAMPLES)/hap/hapy-12-chunks.mov
 FATE_SAMPLES_AVCONV-$(call DEMDEC, MOV, HAP) += $(FATE_HAP)
 fate-hap: $(FATE_HAP)
 
-FATE_IFF-$(CONFIG_IFF_BYTERUN1_DECODER) += fate-iff-byterun1
+FATE_IFF-$(CONFIG_IFF_ILBM_DECODER) += fate-iff-byterun1
 fate-iff-byterun1: CMD = framecrc -i $(TARGET_SAMPLES)/iff/ASH.LBM -pix_fmt 
rgb24
 
 FATE_IFF-$(CONFIG_EIGHTSVX_FIB_DECODER) += fate-iff-fibonacci
-- 
2.6.1

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

Re: [FFmpeg-devel] [PATCH 2/2] avcodec/h264_slice: Never call get_format() for just checking if the format matches

[Hendrik Leppkes]

On Sun, Oct 11, 2015 at 11:14 PM, wm4  wrote:
> On Sun, 11 Oct 2015 23:00:07 +0200
> Hendrik Leppkes  wrote:
>
>> On Sun, Oct 11, 2015 at 10:43 PM, wm4  wrote:
>> > On Sun, 11 Oct 2015 21:55:12 +0200
>> > Michael Niedermayer  wrote:
>> >
>> >> On Sun, Oct 11, 2015 at 09:39:32PM +0200, wm4 wrote:
>> >> > On Sun, 11 Oct 2015 21:16:27 +0200
>> >> > Michael Niedermayer  wrote:
>> >> >
>> >> > > From: Michael Niedermayer 
>> >> > >
>> >> > > Signed-off-by: Michael Niedermayer 
>> >> > > ---
>> >> > >  libavcodec/h264_slice.c |4 
>> >> > >  1 file changed, 4 insertions(+)
>> >> > >
>> >> > > diff --git a/libavcodec/h264_slice.c b/libavcodec/h264_slice.c
>> >> > > index cce97d9..daa3737 100644
>> >> > > --- a/libavcodec/h264_slice.c
>> >> > > +++ b/libavcodec/h264_slice.c
>> >> > > @@ -985,6 +985,10 @@ static enum AVPixelFormat 
>> >> > > get_pixel_format(H264Context *h, int force_callback)
>> >> > >  for (i=0; choices[i] != AV_PIX_FMT_NONE; i++)
>> >> > >  if (non_j_pixfmt(choices[i]) == 
>> >> > > non_j_pixfmt(h->avctx->pix_fmt) && !force_callback)
>> >> > >  return choices[i];
>> >> > > +
>> >> > > +if (!force_callback)
>> >> > > +return AV_PIX_FMT_NONE;
>> >> > > +
>> >> > >  return ff_thread_get_format(h->avctx, choices);
>> >> > >  }
>> >> > >
>> >> >
>> >> > So if I can see this right, the whole purpose of this is to check
>> >> > whether the h264 parameters map to a lavc pixfmt, and bail out or
>> >> > reinitialize if it doesn't. Why can't this be delayed later? What
>> >> > actually needs it sooner than the first "real" get_format? For dealing
>> >>
>> >> > with paramater changes, why can't it check the raw parameters instead?
>> >>
>> >> The raw parameters are checked as well but iam not sure these checks
>> >> are complete, they are more complex.
>> >>
>> >
>> > I've checked again. 3 parameters influence the pixfmt:
>> > bit_depth_luma, chroma_format_idc, and colorspace. Maybe add
>> > color_range because of the J formats.  The first two are already
>> > checked (lazily, if the SPS changes). A colorspace change also triggers
>> > reinit, although the check for it is buried somewhat deeper in the
>> > code. (Also I see a potential bug there: are colorspace and other
>> > fields not reset correctly if the SPS changes, and the new SPS doesn't
>> > have these fields set anymore?) A changing color_range does not force
>> > reinit; this must be fixed (although I'd prefer dropping the J hack
>> > completely).
>> >
>> > So do you agree that checks for colorspace and color_range should be
>> > added, and that they should trigger reinit, and that this combined with
>> > my patch would fix all the potential issues the patch could introduce?
>>
>>  Color Range and Color Space should not trigger a re-init, its
>> pointless and may disrupt playback if a HWAccel re-inits.
>> The in-memory representaiton, and as such the surface format, do not
>> change when only these two change, so re-initing makes no sense to me.
>> I have specifically hacked my local fork to avoid this because it can
>> disrupt playback.
>
> What kind of stream did you deal with that changed color range/space so
> often, and was it one of those single-sample-fixes?

Not "often", but I have seen many clips which start without this
information and then suddenly they have it. If it needs to do a full
re-init there, even only once, it can disrupt hwaccel decoding quite
strongly and cause loss of frames or corrupted frames if your HWAccel
re-inits.
Even having that once in a clip is not acceptable if it can simply be avoided.

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

Re: [FFmpeg-devel] [PATCH 2/2] avcodec/h264_slice: Never call get_format() for just checking if the format matches

[wm4]

On Sun, 11 Oct 2015 23:09:19 +0200
Michael Niedermayer  wrote:

> On Sun, Oct 11, 2015 at 10:43:04PM +0200, wm4 wrote:
> > On Sun, 11 Oct 2015 21:55:12 +0200
> > Michael Niedermayer  wrote:
> > 
> > > On Sun, Oct 11, 2015 at 09:39:32PM +0200, wm4 wrote:
> > > > On Sun, 11 Oct 2015 21:16:27 +0200
> > > > Michael Niedermayer  wrote:
> > > > 
> > > > > From: Michael Niedermayer 
> > > > > 
> > > > > Signed-off-by: Michael Niedermayer 
> > > > > ---
> > > > >  libavcodec/h264_slice.c |4 
> > > > >  1 file changed, 4 insertions(+)
> > > > > 
> > > > > diff --git a/libavcodec/h264_slice.c b/libavcodec/h264_slice.c
> > > > > index cce97d9..daa3737 100644
> > > > > --- a/libavcodec/h264_slice.c
> > > > > +++ b/libavcodec/h264_slice.c
> > > > > @@ -985,6 +985,10 @@ static enum AVPixelFormat 
> > > > > get_pixel_format(H264Context *h, int force_callback)
> > > > >  for (i=0; choices[i] != AV_PIX_FMT_NONE; i++)
> > > > >  if (non_j_pixfmt(choices[i]) == 
> > > > > non_j_pixfmt(h->avctx->pix_fmt) && !force_callback)
> > > > >  return choices[i];
> > > > > +
> > > > > +if (!force_callback)
> > > > > +return AV_PIX_FMT_NONE;
> > > > > +
> > > > >  return ff_thread_get_format(h->avctx, choices);
> > > > >  }
> > > > >  
> > > > 
> > > > So if I can see this right, the whole purpose of this is to check
> > > > whether the h264 parameters map to a lavc pixfmt, and bail out or
> > > > reinitialize if it doesn't. Why can't this be delayed later? What
> > > > actually needs it sooner than the first "real" get_format? For dealing
> > > 
> > > > with paramater changes, why can't it check the raw parameters instead?
> > > 
> > > The raw parameters are checked as well but iam not sure these checks
> > > are complete, they are more complex.
> > > 
> > 
> > I've checked again. 3 parameters influence the pixfmt:
> > bit_depth_luma, chroma_format_idc, and colorspace. Maybe add
> > color_range because of the J formats.  The first two are already
> > checked (lazily, if the SPS changes). A colorspace change also triggers
> > reinit, although the check for it is buried somewhat deeper in the
> > code. (Also I see a potential bug there: are colorspace and other
> > fields not reset correctly if the SPS changes, and the new SPS doesn't
> > have these fields set anymore?) A changing color_range does not force
> > reinit; this must be fixed (although I'd prefer dropping the J hack
> > completely).
> > 
> > So do you agree that checks for colorspace and color_range should be
> > added, and that they should trigger reinit, and that this combined with
> > my patch would fix all the potential issues the patch could introduce?
> > 
> > Note that because of hwaccels, get_format should always be triggered
> > if the SPS changes in any way, because some hwaccels might rely on the
> > current SPS information.
> > 
> > I'm also questioning why there are so many "clever" fine grained reinit
> > checks. Wouldn't it be better to fully reinit every time there is a new
> > SPS, and the new SPS is different than the previous SPS on the byte
> > level? (Don't worry, I'm only speaking hypothetically.)
> 
> i suspect that would break some file somewhere somehow
> 
> but iam happy with anything that works

Then I'll post an alternative patch, which will separate pixfmt
selection and calling get_format, or something.

Still, my videotoolbox change kind of relies on a get_format invocation
strictly on each SPS change, even though the API user can of course
implement a change detection to avoid reinit selectively. (Since the
API user itself has to call the decoder reinit function from within
get_format.)
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 2/2] avcodec/h264_slice: Never call get_format() for just checking if the format matches

[wm4]

On Sun, 11 Oct 2015 23:20:02 +0200
Hendrik Leppkes  wrote:

> On Sun, Oct 11, 2015 at 11:14 PM, wm4  wrote:
> > On Sun, 11 Oct 2015 23:00:07 +0200
> > Hendrik Leppkes  wrote:
> >
> >> On Sun, Oct 11, 2015 at 10:43 PM, wm4  wrote:
> >> > On Sun, 11 Oct 2015 21:55:12 +0200
> >> > Michael Niedermayer  wrote:
> >> >
> >> >> On Sun, Oct 11, 2015 at 09:39:32PM +0200, wm4 wrote:
> >> >> > On Sun, 11 Oct 2015 21:16:27 +0200
> >> >> > Michael Niedermayer  wrote:
> >> >> >
> >> >> > > From: Michael Niedermayer 
> >> >> > >
> >> >> > > Signed-off-by: Michael Niedermayer 
> >> >> > > ---
> >> >> > >  libavcodec/h264_slice.c |4 
> >> >> > >  1 file changed, 4 insertions(+)
> >> >> > >
> >> >> > > diff --git a/libavcodec/h264_slice.c b/libavcodec/h264_slice.c
> >> >> > > index cce97d9..daa3737 100644
> >> >> > > --- a/libavcodec/h264_slice.c
> >> >> > > +++ b/libavcodec/h264_slice.c
> >> >> > > @@ -985,6 +985,10 @@ static enum AVPixelFormat 
> >> >> > > get_pixel_format(H264Context *h, int force_callback)
> >> >> > >  for (i=0; choices[i] != AV_PIX_FMT_NONE; i++)
> >> >> > >  if (non_j_pixfmt(choices[i]) == 
> >> >> > > non_j_pixfmt(h->avctx->pix_fmt) && !force_callback)
> >> >> > >  return choices[i];
> >> >> > > +
> >> >> > > +if (!force_callback)
> >> >> > > +return AV_PIX_FMT_NONE;
> >> >> > > +
> >> >> > >  return ff_thread_get_format(h->avctx, choices);
> >> >> > >  }
> >> >> > >
> >> >> >
> >> >> > So if I can see this right, the whole purpose of this is to check
> >> >> > whether the h264 parameters map to a lavc pixfmt, and bail out or
> >> >> > reinitialize if it doesn't. Why can't this be delayed later? What
> >> >> > actually needs it sooner than the first "real" get_format? For dealing
> >> >>
> >> >> > with paramater changes, why can't it check the raw parameters instead?
> >> >>
> >> >> The raw parameters are checked as well but iam not sure these checks
> >> >> are complete, they are more complex.
> >> >>
> >> >
> >> > I've checked again. 3 parameters influence the pixfmt:
> >> > bit_depth_luma, chroma_format_idc, and colorspace. Maybe add
> >> > color_range because of the J formats.  The first two are already
> >> > checked (lazily, if the SPS changes). A colorspace change also triggers
> >> > reinit, although the check for it is buried somewhat deeper in the
> >> > code. (Also I see a potential bug there: are colorspace and other
> >> > fields not reset correctly if the SPS changes, and the new SPS doesn't
> >> > have these fields set anymore?) A changing color_range does not force
> >> > reinit; this must be fixed (although I'd prefer dropping the J hack
> >> > completely).
> >> >
> >> > So do you agree that checks for colorspace and color_range should be
> >> > added, and that they should trigger reinit, and that this combined with
> >> > my patch would fix all the potential issues the patch could introduce?
> >>
> >>  Color Range and Color Space should not trigger a re-init, its
> >> pointless and may disrupt playback if a HWAccel re-inits.
> >> The in-memory representaiton, and as such the surface format, do not
> >> change when only these two change, so re-initing makes no sense to me.
> >> I have specifically hacked my local fork to avoid this because it can
> >> disrupt playback.
> >
> > What kind of stream did you deal with that changed color range/space so
> > often, and was it one of those single-sample-fixes?
> 
> Not "often", but I have seen many clips which start without this
> information and then suddenly they have it. If it needs to do a full
> re-init there, even only once, it can disrupt hwaccel decoding quite
> strongly and cause loss of frames or corrupted frames if your HWAccel
> re-inits.
> Even having that once in a clip is not acceptable if it can simply be avoided.

Do you mean the first N frames do not have it, and then the following
frames suddenly have it? Or is it a difference between the h264 parser
and decoder?
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] intmath: remove av_ctz.

[Andreas Cadhalpun]

On 11.10.2015 20:28, Ronald S. Bultje wrote:
> It's an a non-installed header and only used in one place (flacenc).
   ^
This 'an' should not be there.

> Since ff_ctz is static inline, it's fine to use that instead.
> ---
>  libavcodec/flacenc.c | 2 +-
>  libavutil/intmath.c  | 5 -
>  libavutil/intmath.h  | 8 
>  3 files changed, 1 insertion(+), 14 deletions(-)

This breaks libavutil ABI, but that should be OK, because there hasn't been
a release since the SOVERSION bump yet.

Anyway, please also remove the entry for av_ctz from APIchanges.
It's not public API, so it never belonged there.

> diff --git a/libavutil/intmath.h b/libavutil/intmath.h
> index 08d54a6..78db28c 100644
> --- a/libavutil/intmath.h
> +++ b/libavutil/intmath.h
> @@ -159,14 +159,6 @@ static av_always_inline av_const int ff_ctz_c( int v )
>  #endif
>  
>  /**
> - * Trailing zero bit count.
> - *
> - * @param v  input value. If v is 0, the result is undefined.
> - * @return   the number of trailing 0-bits
> - */

I'm not sure if it's worth the trouble, but maybe this documentation can
be kept. Move it to ff_ctz_c?

Best regards,
Andreas

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

Re: [FFmpeg-devel] [PATCH] intmath: remove av_ctz.

[James Almer]

On 10/11/2015 6:26 PM, Andreas Cadhalpun wrote:
> Anyway, please also remove the entry for av_ctz from APIchanges.
> It's not public API, so it never belonged there.

Huh, even an APIChanges line? Wonder if intmath.h was public at some
point, or if whoever added this wasn't aware it was an internal header.

It's a very old change, merged from libav apparently.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] avcodec: remove leftover iff_byterun1 decoder

[Ronald S. Bultje]

Hi,

On Sun, Oct 11, 2015 at 5:17 PM, Andreas Cadhalpun <
andreas.cadhal...@googlemail.com> wrote:

> It was merged with the iff_ilbm decoder in commit
> 929a24efff9a208a52748605eb412ffb915c1403.
>
> Define AV_CODEC_ID_IFF_BYTERUN1 as AV_CODEC_ID_IFF_ILBM for API
> compatibility.
>
> Signed-off-by: Andreas Cadhalpun 
> ---
>
> This changes ABI, but that should be still OK.
>
> ---
>  libavcodec/Makefile |  1 -
>  libavcodec/allcodecs.c  |  1 -
>  libavcodec/avcodec.h|  2 +-
>  libavcodec/codec_desc.c |  7 ---
>  libavcodec/iff.c| 13 -
>  libavcodec/utils.c  |  2 +-
>  tests/fate/video.mak|  2 +-
>  7 files changed, 3 insertions(+), 25 deletions(-)
>
[..]

> --- a/libavcodec/avcodec.h
> +++ b/libavcodec/avcodec.h
> @@ -241,7 +241,7 @@ enum AVCodecID {
>  AV_CODEC_ID_ANM,
>  AV_CODEC_ID_BINKVIDEO,
>  AV_CODEC_ID_IFF_ILBM,
> -AV_CODEC_ID_IFF_BYTERUN1,
> +#define AV_CODEC_ID_IFF_BYTERUN1 AV_CODEC_ID_IFF_ILBM
>  AV_CODEC_ID_KGV1,
>  AV_CODEC_ID_YOP,
>  AV_CODEC_ID_VP8,
>

Should this go under a version define so it disappears in 3 years?

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

[FFmpeg-devel] [PATCH] intmath: remove av_ctz.

[Ronald S. Bultje]

It's a non-installed header and only used in one place (flacenc).
Since ff_ctz is static inline, it's fine to use that instead.
---
 doc/APIchanges   |  3 ---
 libavcodec/flacenc.c |  2 +-
 libavutil/intmath.c  |  5 -
 libavutil/intmath.h  | 14 ++
 4 files changed, 7 insertions(+), 17 deletions(-)

diff --git a/doc/APIchanges b/doc/APIchanges
index 03ffda8..67605dc 100644
--- a/doc/APIchanges
+++ b/doc/APIchanges
@@ -1052,9 +1052,6 @@ lavd 54.4.100 / 54.0.0, lavfi 3.5.0
 2012-11-11 - 03b0787 / 5980f5d - lavu 52.6.100 / 52.2.0 - audioconvert.h
   Rename audioconvert.h to channel_layout.h. audioconvert.h is now deprecated.
 
-2012-11-05 - 7d26be6 / dfde8a3 - lavu 52.5.100 / 52.1.0 - intmath.h
-  Add av_ctz() for trailing zero bit count
-
 2012-10-21 - e3a91c5 / a893655 - lavu 51.77.100 / 51.45.0 - error.h
   Add AVERROR_EXPERIMENTAL
 
diff --git a/libavcodec/flacenc.c b/libavcodec/flacenc.c
index f849ffc..e87fdc1 100644
--- a/libavcodec/flacenc.c
+++ b/libavcodec/flacenc.c
@@ -1065,7 +1065,7 @@ static void remove_wasted_bits(FlacEncodeContext *s)
 }
 
 if (v && !(v & 1)) {
-v = av_ctz(v);
+v = ff_ctz(v);
 
 for (i = 0; i < s->frame.blocksize; i++)
 sub->samples[i] >>= v;
diff --git a/libavutil/intmath.c b/libavutil/intmath.c
index 1f725c7..b0c00e1 100644
--- a/libavutil/intmath.c
+++ b/libavutil/intmath.c
@@ -32,8 +32,3 @@ int av_log2_16bit(unsigned v)
 {
 return ff_log2_16bit(v);
 }
-
-int av_ctz(int v)
-{
-return ff_ctz(v);
-}
diff --git a/libavutil/intmath.h b/libavutil/intmath.h
index ec7286a..802abe3 100644
--- a/libavutil/intmath.h
+++ b/libavutil/intmath.h
@@ -122,6 +122,12 @@ static av_always_inline av_const int 
ff_log2_16bit_c(unsigned int v)
 
 #ifndef ff_ctz
 #define ff_ctz ff_ctz_c
+/**
+ * Trailing zero bit count.
+ *
+ * @param v  input value. If v is 0, the result is undefined.
+ * @return   the number of trailing 0-bits
+ */
 #if !defined( _MSC_VER )
 static av_always_inline av_const int ff_ctz_c(int v)
 {
@@ -178,14 +184,6 @@ static av_always_inline av_const int ff_ctzll_c(long long 
v)
 #endif
 
 /**
- * Trailing zero bit count.
- *
- * @param v  input value. If v is 0, the result is undefined.
- * @return   the number of trailing 0-bits
- */
-int av_ctz(int v);
-
-/**
  * @}
  */
 #endif /* AVUTIL_INTMATH_H */
-- 
2.1.2

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

Re: [FFmpeg-devel] [PATCH 1/3] ffmpeg: modify tty state when stderr is redirected

[Ronald S. Bultje]

Hi,

On Fri, Jul 31, 2015 at 8:36 AM, Ganesh Ajjanagadde 
wrote:

> Removes unnecessary isatty(), fixes Ticket2964
>
> Signed-off-by: Ganesh Ajjanagadde 
> ---
>  ffmpeg.c | 8 +---
>  1 file changed, 1 insertion(+), 7 deletions(-)
>
> diff --git a/ffmpeg.c b/ffmpeg.c
> index 5575e2f..fe250e5 100644
> --- a/ffmpeg.c
> +++ b/ffmpeg.c
> @@ -32,14 +32,12 @@
>  #include 
>  #include 
>
> -#if HAVE_ISATTY
>  #if HAVE_IO_H
>  #include 
>  #endif
>  #if HAVE_UNISTD_H
>  #include 
>  #endif
> -#endif
>
>  #include "libavformat/avformat.h"
>  #include "libavdevice/avdevice.h"
> @@ -370,11 +368,7 @@ void term_init(void)
>  #if HAVE_TERMIOS_H
>  if(!run_as_daemon){
>  struct termios tty;
> -int istty = 1;
> -#if HAVE_ISATTY
> -istty = isatty(0) && isatty(2);
> -#endif
> -if (istty && tcgetattr (0, ) == 0) {
> +if (tcgetattr (0, ) == 0) {
>  oldtty = tty;
>  restore_tty = 1;
>
> --
> 2.5.0


Pushed.

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

Re: [FFmpeg-devel] [PATCH] avcodec: remove leftover iff_byterun1 decoder

[Andreas Cadhalpun]

Hi Ronald,

On 11.10.2015 23:39, Ronald S. Bultje wrote:
> On Sun, Oct 11, 2015 at 5:17 PM, Andreas Cadhalpun <
> andreas.cadhal...@googlemail.com> wrote:
>> --- a/libavcodec/avcodec.h
>> +++ b/libavcodec/avcodec.h
>> @@ -241,7 +241,7 @@ enum AVCodecID {
>>  AV_CODEC_ID_ANM,
>>  AV_CODEC_ID_BINKVIDEO,
>>  AV_CODEC_ID_IFF_ILBM,
>> -AV_CODEC_ID_IFF_BYTERUN1,
>> +#define AV_CODEC_ID_IFF_BYTERUN1 AV_CODEC_ID_IFF_ILBM
>>  AV_CODEC_ID_KGV1,
>>  AV_CODEC_ID_YOP,
>>  AV_CODEC_ID_VP8,
>>
> 
> Should this go under a version define so it disappears in 3 years?

It shouldn't as long as Libav still uses this codec ID.

AV_CODEC_ID_H265 on the other hand could disappear in such a way.

Best regards,
Andreas
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] intmath: remove av_ctz.

[Andreas Cadhalpun]

On 11.10.2015 23:44, Ronald S. Bultje wrote:
> It's a non-installed header and only used in one place (flacenc).
> Since ff_ctz is static inline, it's fine to use that instead.
> ---
>  doc/APIchanges   |  3 ---
>  libavcodec/flacenc.c |  2 +-
>  libavutil/intmath.c  |  5 -
>  libavutil/intmath.h  | 14 ++
>  4 files changed, 7 insertions(+), 17 deletions(-)

Should be fine.

Best regards,
Andreas

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

Re: [FFmpeg-devel] [PATCH 1/3] ffmpeg: modify tty state when stderr is redirected

[Ganesh Ajjanagadde]

On Sun, Oct 11, 2015 at 5:45 PM, Ronald S. Bultje  wrote:
> Hi,
>
> On Fri, Jul 31, 2015 at 8:36 AM, Ganesh Ajjanagadde 
> wrote:
>>
>> Removes unnecessary isatty(), fixes Ticket2964
>>
>> Signed-off-by: Ganesh Ajjanagadde 
>>
>> ---
>>  ffmpeg.c | 8 +---
>>  1 file changed, 1 insertion(+), 7 deletions(-)
>>
>> diff --git a/ffmpeg.c b/ffmpeg.c
>> index 5575e2f..fe250e5 100644
>> --- a/ffmpeg.c
>> +++ b/ffmpeg.c
>> @@ -32,14 +32,12 @@
>>  #include 
>>  #include 
>>
>> -#if HAVE_ISATTY
>>  #if HAVE_IO_H
>>  #include 
>>  #endif
>>  #if HAVE_UNISTD_H
>>  #include 
>>  #endif
>> -#endif
>>
>>  #include "libavformat/avformat.h"
>>  #include "libavdevice/avdevice.h"
>> @@ -370,11 +368,7 @@ void term_init(void)
>>  #if HAVE_TERMIOS_H
>>  if(!run_as_daemon){
>>  struct termios tty;
>> -int istty = 1;
>> -#if HAVE_ISATTY
>> -istty = isatty(0) && isatty(2);
>> -#endif
>> -if (istty && tcgetattr (0, ) == 0) {
>> +if (tcgetattr (0, ) == 0) {
>>  oldtty = tty;
>>  restore_tty = 1;
>>
>> --
>> 2.5.0
>
>
> Pushed.

Thanks for bearing with my repeated pinging over a few months
regarding this patch. Ticket 2964 can finally be closed.

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

Re: [FFmpeg-devel] [PATCH] avcodec/h264: remove redundant and bogus get_format call

[Michael Niedermayer]

On Sun, Oct 11, 2015 at 09:27:13PM +0200, wm4 wrote:
> On Sun, 11 Oct 2015 21:22:40 +0200
> Michael Niedermayer  wrote:
> 
> > On Sun, Oct 11, 2015 at 07:05:27PM +0200, wm4 wrote:
> > > The AVCodecContext.get_format callback is not only used for pixel format
> > > negotiation with the API user, but also for hwaccel init. For the
> > > latter, it's required that some codec parameters, in particular the
> > > codec profile, are set when the callback is invoked.
> > > 
> > > This patch removes a get_format invocation where this is not guaranteed.
> > > The codec parameters, including the profile, are really set further
> > > below. (The same code path that sets the profile also calls get_format
> > > properly too.)
> > > 
> > > This just happened to work by coincidence in most cases. For example, if
> > > the API user just copied or reused the AVStream's AVCodecContext when
> > > decoding, the profile would be set properly. But in some cases it
> > > fails., such as with the sample WolfensteinTwitch.mp4 on the samples
> > > server.
> > > 
> > > Remove the redundant get_format call. Apparently it serves no purpose
> > > anymore, although it is possible that this was different at the time it
> > > was added in commit ffd77f94a26be22b8ead3178ceec3ed39e68abc5.
> > > 
> > > This fixes hwaccel usage for API users which do not set the profile
> > > when setting up the AVCodecContext (which is allowed).
> > > ---
> > >  libavcodec/h264_slice.c | 14 --
> > >  1 file changed, 14 deletions(-)
> > 
> > ive posted an alternative patchset of 2 patches which should prevent
> > get_format() from being called. That would leave the check in place
> 
> I would prefer getting rid of this completely, because it looks
> redundant. My patch also manages to get rid of the weird J format
> handling (kill it with fire).
> 

> Do you have a sample that breaks with my patch?

none of the files i tried

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

Everything should be made as simple as possible, but not simpler.
-- Albert Einstein


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: remove leftover iff_byterun1 decoder

[Ronald S. Bultje]

Howdy,

On Sun, Oct 11, 2015 at 5:50 PM, Andreas Cadhalpun <
andreas.cadhal...@googlemail.com> wrote:

> Hi Ronald,
>
> On 11.10.2015 23:39, Ronald S. Bultje wrote:
> > On Sun, Oct 11, 2015 at 5:17 PM, Andreas Cadhalpun <
> > andreas.cadhal...@googlemail.com> wrote:
> >> --- a/libavcodec/avcodec.h
> >> +++ b/libavcodec/avcodec.h
> >> @@ -241,7 +241,7 @@ enum AVCodecID {
> >>  AV_CODEC_ID_ANM,
> >>  AV_CODEC_ID_BINKVIDEO,
> >>  AV_CODEC_ID_IFF_ILBM,
> >> -AV_CODEC_ID_IFF_BYTERUN1,
> >> +#define AV_CODEC_ID_IFF_BYTERUN1 AV_CODEC_ID_IFF_ILBM
> >>  AV_CODEC_ID_KGV1,
> >>  AV_CODEC_ID_YOP,
> >>  AV_CODEC_ID_VP8,
> >>
> >
> > Should this go under a version define so it disappears in 3 years?
>
> It shouldn't as long as Libav still uses this codec ID.
>

Hm, ... ok so it's one of these political bits. OK, fine, I'll drop that
objection. Rest of patch is OK.

AV_CODEC_ID_H265 on the other hand could disappear in such a way.


That's unrelated to this patch though, so no need to hold this one up for
that :)

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

Re: [FFmpeg-devel] [PATCH] web/src/about: add note on portability

[Moritz Barsnick]

On Sun, Oct 11, 2015 at 16:29:16 -0400, Ganesh Ajjanagadde wrote:
> +  Microsoft Windows, the BSD's, Solaris, etc. under a wide variety of build
^
Even abbreviations and acronyms don't get an apostrophe with their
plural 's'.

http://www.oxforddictionaries.com/words/apostrophe

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

Re: [FFmpeg-devel] [PATCH] avcodec: remove leftover iff_byterun1 decoder

[Andreas Cadhalpun]

On 11.10.2015 23:56, Ronald S. Bultje wrote:
> On Sun, Oct 11, 2015 at 5:50 PM, Andreas Cadhalpun <
> andreas.cadhal...@googlemail.com> wrote:
>> On 11.10.2015 23:39, Ronald S. Bultje wrote:
>>> On Sun, Oct 11, 2015 at 5:17 PM, Andreas Cadhalpun <
>>> andreas.cadhal...@googlemail.com> wrote:
 --- a/libavcodec/avcodec.h
 +++ b/libavcodec/avcodec.h
 @@ -241,7 +241,7 @@ enum AVCodecID {
  AV_CODEC_ID_ANM,
  AV_CODEC_ID_BINKVIDEO,
  AV_CODEC_ID_IFF_ILBM,
 -AV_CODEC_ID_IFF_BYTERUN1,
 +#define AV_CODEC_ID_IFF_BYTERUN1 AV_CODEC_ID_IFF_ILBM
  AV_CODEC_ID_KGV1,
  AV_CODEC_ID_YOP,
  AV_CODEC_ID_VP8,

>>>
>>> Should this go under a version define so it disappears in 3 years?
>>
>> It shouldn't as long as Libav still uses this codec ID.
>>
> 
> Hm, ... ok so it's one of these political bits. OK, fine, I'll drop that
> objection. Rest of patch is OK.

Thanks, pushed.

> AV_CODEC_ID_H265 on the other hand could disappear in such a way.
> 
> 
> That's unrelated to this patch though, so no need to hold this one up for
> that :)

Yes, I just mentioned it in case you want to write a patch for it. :)

Best regards,
Andreas

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

Re: [FFmpeg-devel] [PATCHv2] doc/developer: add note on patches that fix warnings

[Michael Niedermayer]

On Sun, Oct 11, 2015 at 02:27:11PM -0400, Ganesh Ajjanagadde wrote:
> On Tue, Oct 6, 2015 at 6:55 PM, Ganesh Ajjanagadde
>  wrote:
> > This adds some recommendations while submitting patches that fix warnings.
> >
> > Signed-off-by: Ganesh Ajjanagadde 
> > ---
> >  doc/developer.texi | 6 ++
> >  1 file changed, 6 insertions(+)
> >
> > diff --git a/doc/developer.texi b/doc/developer.texi
> > index b8259e7..4d0fc9f 100644
> > --- a/doc/developer.texi
> > +++ b/doc/developer.texi
> > @@ -391,6 +391,12 @@ be changed to not generate a warning unless that 
> > causes a slowdown
> >  or obfuscates the code.
> >
> >  @item
> > +While fixing compiler warnings, please add some information to the commit
> > +message body indicating the toolchain configuration.
> > +This is very helpful for future maintainers since it eases possible
> > +modifications when the toolchain gets updated.
> > +
> > +@item
> >  Make sure that no parts of the codebase that you maintain are missing from 
> > the
> >  @file{MAINTAINERS} file. If something that you want to maintain is missing 
> > add it with
> >  your name after it.
> > --
> > 2.6.1
> >
> 
> Anyone thinks this is useful? I can't really say: regular developers
> anyway know this, and drive-by/sporadic contributions are highly
> unlikely to be warning fixes.

i dont know about "usefull" but iam a bit concerned about complicating
the developer policy with it

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

Avoid a single point of failure, be that a person or equipment.


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

Re: [FFmpeg-devel] [PATCHv2] doc/developer: add note on patches that fix warnings

[Ganesh Ajjanagadde]

On Sun, Oct 11, 2015 at 6:33 PM, Michael Niedermayer
 wrote:
> On Sun, Oct 11, 2015 at 02:27:11PM -0400, Ganesh Ajjanagadde wrote:
>> On Tue, Oct 6, 2015 at 6:55 PM, Ganesh Ajjanagadde
>>  wrote:
>> > This adds some recommendations while submitting patches that fix warnings.
>> >
>> > Signed-off-by: Ganesh Ajjanagadde 
>> > ---
>> >  doc/developer.texi | 6 ++
>> >  1 file changed, 6 insertions(+)
>> >
>> > diff --git a/doc/developer.texi b/doc/developer.texi
>> > index b8259e7..4d0fc9f 100644
>> > --- a/doc/developer.texi
>> > +++ b/doc/developer.texi
>> > @@ -391,6 +391,12 @@ be changed to not generate a warning unless that 
>> > causes a slowdown
>> >  or obfuscates the code.
>> >
>> >  @item
>> > +While fixing compiler warnings, please add some information to the commit
>> > +message body indicating the toolchain configuration.
>> > +This is very helpful for future maintainers since it eases possible
>> > +modifications when the toolchain gets updated.
>> > +
>> > +@item
>> >  Make sure that no parts of the codebase that you maintain are missing 
>> > from the
>> >  @file{MAINTAINERS} file. If something that you want to maintain is 
>> > missing add it with
>> >  your name after it.
>> > --
>> > 2.6.1
>> >
>>
>> Anyone thinks this is useful? I can't really say: regular developers
>> anyway know this, and drive-by/sporadic contributions are highly
>> unlikely to be warning fixes.
>
> i dont know about "usefull" but iam a bit concerned about complicating
> the developer policy with it

agreed, like I point out above, I don't think this is that important.
Consider the patch dropped.

>
> [...]
> --
> Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
>
> Avoid a single point of failure, be that a person or equipment.
>
> ___
> 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] avcodec: remove leftover iff_byterun1 decoder

[Ronald S. Bultje]

Hi,

On Sun, Oct 11, 2015 at 6:26 PM, Andreas Cadhalpun <
andreas.cadhal...@googlemail.com> wrote:

> On 11.10.2015 23:56, Ronald S. Bultje wrote:
> > On Sun, Oct 11, 2015 at 5:50 PM, Andreas Cadhalpun <
> > andreas.cadhal...@googlemail.com> wrote:
> >> On 11.10.2015 23:39, Ronald S. Bultje wrote:
> >>> On Sun, Oct 11, 2015 at 5:17 PM, Andreas Cadhalpun <
> >>> andreas.cadhal...@googlemail.com> wrote:
>  --- a/libavcodec/avcodec.h
>  +++ b/libavcodec/avcodec.h
>  @@ -241,7 +241,7 @@ enum AVCodecID {
>   AV_CODEC_ID_ANM,
>   AV_CODEC_ID_BINKVIDEO,
>   AV_CODEC_ID_IFF_ILBM,
>  -AV_CODEC_ID_IFF_BYTERUN1,
>  +#define AV_CODEC_ID_IFF_BYTERUN1 AV_CODEC_ID_IFF_ILBM
>   AV_CODEC_ID_KGV1,
>   AV_CODEC_ID_YOP,
>   AV_CODEC_ID_VP8,
> 
> >>>
> >>> Should this go under a version define so it disappears in 3 years?
> >>
> >> It shouldn't as long as Libav still uses this codec ID.
> >>
> >
> > Hm, ... ok so it's one of these political bits. OK, fine, I'll drop that
> > objection. Rest of patch is OK.
>
> Thanks, pushed.
>
> > AV_CODEC_ID_H265 on the other hand could disappear in such a way.
> >
> >
> > That's unrelated to this patch though, so no need to hold this one up for
> > that :)
>
> Yes, I just mentioned it in case you want to write a patch for it. :)


Oh, I see, you're volunteering me... Hm... Nobody likes making changes to
core headers, I suppose?

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

Re: [FFmpeg-devel] GCC 5.1 warning: -Warray-bounds

[Ganesh Ajjanagadde]

On Wed, Jul 22, 2015 at 10:56 PM, Ganesh Ajjanagadde  wrote:
> On Tue, Jul 21, 2015 at 10:46 PM, James Almer  wrote:
>> On 21/07/15 11:43 PM, Ganesh Ajjanagadde wrote:
>>> or try to work upstream with GCC to remove these spurious warnings.
>>
>> If it can be fixed upstream then that's certainly the best option.
>> For all we know new code we add in the future may trigger this bug
>> again.
>
> I have filed a new bugreport for the issue in libavcodec/dca_xll.c:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66974

Ticket above looks dead, and given their high bug volume, I doubt any
one will be investigating it soon. Since there are only 2 instances
remaining, both silencable with one line changes, I will submit
patches for them unless someone objects.

>
>> ___
>> 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 2/2] x86/vf_w3fdif: simplify w3fdif_simple_high

[James Almer]

On 10/11/2015 3:11 PM, Ronald S. Bultje wrote:
> Hi,
> 
> On Sun, Oct 11, 2015 at 1:17 PM, James Almer  wrote:
> 
>> On 10/11/2015 4:31 AM, Paul B Mahol wrote:
>>> On 10/11/15, James Almer  wrote:
 Signed-off-by: James Almer 
 ---
  libavfilter/x86/vf_w3fdif.asm | 16 +++-
  1 file changed, 7 insertions(+), 9 deletions(-)

 diff --git a/libavfilter/x86/vf_w3fdif.asm
>> b/libavfilter/x86/vf_w3fdif.asm
 index f02319b..f2001a4 100644
 --- a/libavfilter/x86/vf_w3fdif.asm
 +++ b/libavfilter/x86/vf_w3fdif.asm
 @@ -103,13 +103,11 @@ REP_RET

  %if ARCH_X86_64

 -cglobal w3fdif_simple_high, 5, 9, 9, 0, work_line, in_lines_cur0,
 in_lines_adj0, coef, linesize
 +cglobal w3fdif_simple_high, 5, 9, 8, 0, work_line, in_lines_cur0,
 in_lines_adj0, coef, linesize
  movq  m2, [coefq]
  DEFINE_ARGSwork_line, in_lines_cur0, in_lines_adj0,
>> in_lines_cur1,
 linesize, offset, in_lines_cur2, in_lines_adj1, in_lines_adj2
 -SPLATWm0, m2, 0
 -SPLATWm1, m2, 1
 +pshufdm0, m2, q
  SPLATWm2, m2, 2
 -SBUTTERFLYwd, 0, 1, 7
  pxor  m7, m7
  mov  offsetq, 0
  mov   in_lines_cur2q, [in_lines_cur0q+gprsize*2]
 @@ -124,23 +122,23 @@ cglobal w3fdif_simple_high, 5, 9, 9, 0, work_line,
 in_lines_cur0, in_lines_adj0,
  movh   m4, [in_lines_cur1q+offsetq]
  punpcklbw  m3, m7
  punpcklbw  m4, m7
 -SBUTTERFLY wd, 3, 4, 8
 +SBUTTERFLY wd, 3, 4, 1
  pmaddwdm3, m0
 -pmaddwdm4, m1
 +pmaddwdm4, m0
  movh   m5, [in_lines_adj0q+offsetq]
  movh   m6, [in_lines_adj1q+offsetq]
  punpcklbw  m5, m7
  punpcklbw  m6, m7
 -SBUTTERFLY wd, 5, 6, 8
 +SBUTTERFLY wd, 5, 6, 1
  pmaddwdm5, m0
 -pmaddwdm6, m1
 +pmaddwdm6, m0
  paddd  m3, m5
  paddd  m4, m6
  movh   m5, [in_lines_cur2q+offsetq]
  movh   m6, [in_lines_adj2q+offsetq]
  punpcklbw  m5, m7
  punpcklbw  m6, m7
 -SBUTTERFLY wd, 5, 6, 8
 +SBUTTERFLY wd, 5, 6, 1
  pmaddwdm5, m2
  pmaddwdm6, m2
  paddd  m3, m5
 --
 2.6.0

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

>>>
>>> Cant this now be used on x32?
>>
> 
> Add to the data pointers directly (in_lines_cur0q and work_lineq). Then sub
> all other curXq/adjXq from cur0q (on 32bit only) before the loop and you
> have to adds (on 32bit) instead of one (on 64bit), but one reg less
> (offset), making it 7, which means it works.
> 
> Ronald

Ah, like it's being done in PACK_6CH from swr's audio_convert.asm
For complex_high some stack ab/use will be needed (see PACK_8CH), but it should
be doable.
This way w3fdif will be able to fully dethrone yadif :P
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 2/2] avcodec/h264_slice: Never call get_format() for just checking if the format matches

[wm4]

On Sun, 11 Oct 2015 21:16:27 +0200
Michael Niedermayer  wrote:

> From: Michael Niedermayer 
> 
> Signed-off-by: Michael Niedermayer 
> ---
>  libavcodec/h264_slice.c |4 
>  1 file changed, 4 insertions(+)
> 
> diff --git a/libavcodec/h264_slice.c b/libavcodec/h264_slice.c
> index cce97d9..daa3737 100644
> --- a/libavcodec/h264_slice.c
> +++ b/libavcodec/h264_slice.c
> @@ -985,6 +985,10 @@ static enum AVPixelFormat get_pixel_format(H264Context 
> *h, int force_callback)
>  for (i=0; choices[i] != AV_PIX_FMT_NONE; i++)
>  if (non_j_pixfmt(choices[i]) == non_j_pixfmt(h->avctx->pix_fmt) && 
> !force_callback)
>  return choices[i];
> +
> +if (!force_callback)
> +return AV_PIX_FMT_NONE;
> +
>  return ff_thread_get_format(h->avctx, choices);
>  }
>  

So if I can see this right, the whole purpose of this is to check
whether the h264 parameters map to a lavc pixfmt, and bail out or
reinitialize if it doesn't. Why can't this be delayed later? What
actually needs it sooner than the first "real" get_format? For dealing
with paramater changes, why can't it check the raw parameters instead?
Doing it this way seems a bit convoluted. (I understand it now that I
thought about it, but normally I'd think it's VERY weird that it
somehow can go on without using the user-decided pixfmt, or that the
user-decided pixfmt sometimes doesn't seem to matter?)
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 2/2] avcodec/h264_slice: Never call get_format() for just checking if the format matches

[Michael Niedermayer]

On Sun, Oct 11, 2015 at 09:39:32PM +0200, wm4 wrote:
> On Sun, 11 Oct 2015 21:16:27 +0200
> Michael Niedermayer  wrote:
> 
> > From: Michael Niedermayer 
> > 
> > Signed-off-by: Michael Niedermayer 
> > ---
> >  libavcodec/h264_slice.c |4 
> >  1 file changed, 4 insertions(+)
> > 
> > diff --git a/libavcodec/h264_slice.c b/libavcodec/h264_slice.c
> > index cce97d9..daa3737 100644
> > --- a/libavcodec/h264_slice.c
> > +++ b/libavcodec/h264_slice.c
> > @@ -985,6 +985,10 @@ static enum AVPixelFormat get_pixel_format(H264Context 
> > *h, int force_callback)
> >  for (i=0; choices[i] != AV_PIX_FMT_NONE; i++)
> >  if (non_j_pixfmt(choices[i]) == non_j_pixfmt(h->avctx->pix_fmt) && 
> > !force_callback)
> >  return choices[i];
> > +
> > +if (!force_callback)
> > +return AV_PIX_FMT_NONE;
> > +
> >  return ff_thread_get_format(h->avctx, choices);
> >  }
> >  
> 
> So if I can see this right, the whole purpose of this is to check
> whether the h264 parameters map to a lavc pixfmt, and bail out or
> reinitialize if it doesn't. Why can't this be delayed later? What
> actually needs it sooner than the first "real" get_format? For dealing

> with paramater changes, why can't it check the raw parameters instead?

The raw parameters are checked as well but iam not sure these checks
are complete, they are more complex.


> Doing it this way seems a bit convoluted. (I understand it now that I
> thought about it, but normally I'd think it's VERY weird that it
> somehow can go on without using the user-decided pixfmt, or that the
> user-decided pixfmt sometimes doesn't seem to matter?)


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

It is dangerous to be right in matters on which the established authorities
are wrong. -- Voltaire


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

Re: [FFmpeg-devel] [PATCH] configure: fix configure when using gcc

[Ganesh Ajjanagadde]

On Sun, Oct 11, 2015 at 3:45 PM, Ben Boeckel  wrote:
> On Sun, 11 Oct, 2015 at 16:34:51 GMT, Ganesh Ajjanagadde wrote:
>> That is a long time hopefully (estimated 15+ years), unless gcc starts
>> pulling a "fast release" cycle like Firefox or Chrome.
>
> Sort of. Old point releases will be major version number bumps (GCC 6 is
> under development already).

Guess they are transitioning to the "move fast" style. I am
deliberately avoiding the "and break things" aspect of "move fast and
break things" out of perhaps misplaced optimism.

>
> --Ben
>
> ___
> 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] setting up a proper Github mirror

[Michael Niedermayer]

On Sun, Oct 11, 2015 at 03:43:19PM -0400, Ganesh Ajjanagadde wrote:
> On Sun, Oct 11, 2015 at 3:33 PM, Michael Niedermayer
>  wrote:
> > On Sun, Oct 11, 2015 at 09:04:32PM +0200, Clément Bœsch wrote:
> >> On Sun, Oct 11, 2015 at 02:43:53PM -0400, Ganesh Ajjanagadde wrote:
> >> > Hi all,
> >> >
> >> > I noticed that the Github mirror: https://github.com/FFmpeg/FFmpeg is
> >> > over 3 hours out of sync with the main repos, making it unusable as a
> >> > fetch url for development. Anyone knows why this is the case?
> >> >
> >>
> >> Isn't this done manually by whoever has access to it?
> >
> > yes
> > i (and possibly timothy) push to github after doing full build and
> > fate tests. If for some reason build or fate fails or iam aware of
> > a major/critical breakage in master which is not in github yet then i
> > do not push to github.
> > So github may be a few hours behind master but in the rare event
> > of a major messup it should not propagate to github before its fixed
> 
> Thanks for clarifying. Any inherent reason you want to keep it like
> this instead of a post-receive hook?

just that i like github always building fate on x86-64 and
that iam used to it, beyond that not really, no


> I do not see any concrete benefit for keeping Github slightly more
> "pristine' than our repository: someone who builds off master will in
> all likelihood not be using the Github URL, but our repo's url anyway.
> Furthermore, I do not consider such a difference useful (especially
> since it is not documented) - keeping both "complete" and up to date
> is IMHO good.
> 
> Of course, the concrete benefit I am trying to get is to move
> fetch/pull load away from VideoLAN/our host more generally to Github
> who are much less starved for resources than us.

if theres a problem with the load on the videolan git server, then we
should consider using one of our own servers for git i think.
It would reduce the load on videolan and truth is, we have a basically
unused and rather powerfull box 

[...]

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

It is what and why we do it that matters, not just one of them.


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

Re: [FFmpeg-devel] setting up a proper Github mirror

[Michael Niedermayer]

On Sun, Oct 11, 2015 at 09:04:32PM +0200, Clément Bœsch wrote:
> On Sun, Oct 11, 2015 at 02:43:53PM -0400, Ganesh Ajjanagadde wrote:
> > Hi all,
> > 
> > I noticed that the Github mirror: https://github.com/FFmpeg/FFmpeg is
> > over 3 hours out of sync with the main repos, making it unusable as a
> > fetch url for development. Anyone knows why this is the case?
> > 
> 
> Isn't this done manually by whoever has access to it?

yes
i (and possibly timothy) push to github after doing full build and
fate tests. If for some reason build or fate fails or iam aware of
a major/critical breakage in master which is not in github yet then i
do not push to github.
So github may be a few hours behind master but in the rare event
of a major messup it should not propagate to github before its fixed

[...]


-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

When the tyrant has disposed of foreign enemies by conquest or treaty, and
there is nothing more to fear from them, then he is always stirring up
some war or other, in order that the people may require a leader. -- Plato


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