[FFmpeg-devel] [PATCH] avfiltergraph: add -sample_rate_fallback

[Takayuki 'January June' Suwa]

dedicated to all audiophiles :)

examples:
  -sample_rate_fallback closest -i 48ksps_source -af 
"aformat=sample_rates=44100|88200|176400|352800"
=> 44.1ksps (default behavior)
  -sample_rate_fallback higher
=> 88.2ksps
  -sample_rate_fallback higher2x
=> 176.4ksps
  -sample_rate_fallback highest
=> 352.8ksps
---
 doc/ffmpeg.texi | 28 
 ffmpeg.h|  1 +
 ffmpeg_filter.c |  1 +
 ffmpeg_opt.c| 24 +
 libavfilter/avfilter.h  |  1 +
 libavfilter/avfiltergraph.c | 52 -
 6 files changed, 97 insertions(+), 10 deletions(-)

diff --git a/doc/ffmpeg.texi b/doc/ffmpeg.texi
index 8b08e22..6e6fb97 100644
--- a/doc/ffmpeg.texi
+++ b/doc/ffmpeg.texi
@@ -1276,6 +1276,34 @@ This option is similar to @option{-filter_complex}, the 
only difference is that
 its argument is the name of the file from which a complex filtergraph
 description is to be read.
 
+@item -sample_rate_fallback @var{method}  (@emph{global})
+Audio sample rate fallback method when no exact match found.
+
+Whenever the filtergraph connects its filters each other, attributes of output 
link
+on each filter will be compared to ones of input link on the next filter. If an
+attribute on the both sides have been matched exactly, it will be passed 
through. If
+not, of course, such attribute must be reformated or resampled.
+
+On audio filtergraph, sample format and channel layout are reformated with 
wider
+ones in such situation. This brings almost good result and less problem. 
However
+for audio sample rate, there is more than one point of view about a 
@emph{good} method.
+@table @option
+@item 0, closest
+Audio stream will be resampled to the closest (regardless of higher or lower) 
one
+of the next filter's available input sample rates. It is the default behavior 
and
+preferred for saving storage capacity or network bandwidth rather than 
preserving
+sound quality.
+@item 1, higher
+Resampled to the closest higher one of the next filter's available input
+sample rates.
+@item 2, higher2x
+Similar to @option{higher}, but twice high because of the sampling theorem.
+@item 3, highest
+Resampled to the highest one of the next filter's available input sample 
rates. It
+may be accepted when bandwidth won't be a problem, such as putting to local DAC
+directly.
+@end table
+
 @item -accurate_seek (@emph{input})
 This option enables or disables accurate seeking in input files with the
 @option{-ss} option. It is enabled by default, so seeking is accurate when
diff --git a/ffmpeg.h b/ffmpeg.h
index 06a1251..13d8e16 100644
--- a/ffmpeg.h
+++ b/ffmpeg.h
@@ -601,6 +601,7 @@ extern char *videotoolbox_pixfmt;
 
 extern int filter_nbthreads;
 extern int filter_complex_nbthreads;
+extern int sample_rate_fallback;
 extern int vstats_version;
 
 extern const AVIOInterruptCB int_cb;
diff --git a/ffmpeg_filter.c b/ffmpeg_filter.c
index 7f249c2..182048b 100644
--- a/ffmpeg_filter.c
+++ b/ffmpeg_filter.c
@@ -1045,6 +1045,7 @@ int configure_filtergraph(FilterGraph *fg)
 } else {
 fg->graph->nb_threads = filter_complex_nbthreads;
 }
+fg->graph->sample_rate_fallback = sample_rate_fallback;
 
 if ((ret = avfilter_graph_parse2(fg->graph, graph_desc, , 
)) < 0)
 goto fail;
diff --git a/ffmpeg_opt.c b/ffmpeg_opt.c
index e2c0176..d8b8918 100644
--- a/ffmpeg_opt.c
+++ b/ffmpeg_opt.c
@@ -121,6 +121,7 @@ int frame_bits_per_raw_sample = 0;
 float max_error_rate  = 2.0/3;
 int filter_nbthreads = 0;
 int filter_complex_nbthreads = 0;
+int sample_rate_fallback = 0;
 int vstats_version = 2;
 
 
@@ -3088,6 +3089,27 @@ static int opt_filter_complex_script(void *optctx, const 
char *opt, const char *
 return 0;
 }
 
+static int opt_sample_rate_fallback(void *optctx, const char *opt, const char 
*arg)
+{
+static const AVOption opts[] = {
+{ "sample_rate_fallback", NULL, 0, AV_OPT_TYPE_INT,   { .i64 = 0 }, 0, 
3, 0, "sample_rate_fallback" },
+{ "closest",  NULL, 0, AV_OPT_TYPE_CONST, { .i64 = 0 }, 0, 
0, 0, "sample_rate_fallback" },
+{ "higher",   NULL, 0, AV_OPT_TYPE_CONST, { .i64 = 1 }, 0, 
0, 0, "sample_rate_fallback" },
+{ "higher2x", NULL, 0, AV_OPT_TYPE_CONST, { .i64 = 2 }, 0, 
0, 0, "sample_rate_fallback" },
+{ "highest",  NULL, 0, AV_OPT_TYPE_CONST, { .i64 = 3 }, 0, 
0, 0, "sample_rate_fallback" },
+{ NULL },
+};
+static const AVClass class = {
+.class_name = "",
+.item_name  = av_default_item_name,
+.option = opts,
+.version= LIBAVUTIL_VERSION_INT,
+};
+const AVClass *pclass = 
+
+return av_opt_eval_int(, [0], arg, _rate_fallback);
+}
+
 void show_help_default(const char *opt, const char *arg)
 {
 /* per-file options have at least one of those set */
@@ -3434,6 +3456,8 @@ const OptionDef options[] = {
 "create a complex 

Re: [FFmpeg-devel] [PATCH] avutil/tests/lfg.c: added proper normality test

[Carl Eugen Hoyos]

2017-03-07 6:36 GMT+01:00 Thomas Turner :
> ./configure command worked without ccache:
>
> ./configure --enable-debug=3 --arch=x86_32 --target-os=linux
> --extra-cflags=-m32 --extra-ldflags=-m32  --enable-cross-compile
>
> but after installing the following software packages w/ apt-get:
>
> apt-get install gcc-multilib g++-mult
>
> after recompiling and installing ffmpeg and running lfg selftest again, the
> test still passes for x86_32 w/ gcc.
> Just to double check the results, i ran the lfg test in a virtual machine
> running 32 bit ubuntu and the test indeed passes.
>
> So i am unable to reproduce the error on x86_32.

The failure is reproducible with gcc 4.3.6 which we supported so far
(and several not-so-supported versions).

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

Re: [FFmpeg-devel] [PATCH 1/2] libx264: remove the "x264opts" AVOption

[Carl Eugen Hoyos]

2017-03-06 23:20 GMT+01:00 Jan Ekström :
> x264-params does the same thing and this leaves us with a single
> option that is name-matched with x265-params available in the
> libx265 wrapper.

(Why?)

You have to deprecate an option before removing it.

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

Re: [FFmpeg-devel] [PATCH] Revert "lavu/atomic: add support for the new memory model aware gcc built-ins"

[wm4]

On Tue,  7 Mar 2017 00:29:53 -0300
James Almer  wrote:

> This reverts commit faa9d2982969c999ab0e443a226eff116f7f8e4b.
> 
> This change became superfluous when support for C11 atomics was introduced.
> Reverting it will make the removal of this implementation in an upcoming
> merge conflict free.
> 
> Signed-off-by: James Almer 
> ---
>  configure  |  4 +---
>  libavutil/atomic_gcc.h | 17 -
>  2 files changed, 1 insertion(+), 20 deletions(-)
> 
> diff --git a/configure b/configure
> index 0199fec5c0..6350942ef9 100755
> --- a/configure
> +++ b/configure
> @@ -1821,7 +1821,6 @@ ARCH_FEATURES="
>  
>  BUILTIN_LIST="
>  atomic_cas_ptr
> -atomic_compare_exchange
>  machine_rw_barrier
>  MemoryBarrier
>  mm_empty
> @@ -2322,7 +2321,7 @@ symver_if_any="symver_asm_label symver_gnu_asm"
>  valgrind_backtrace_deps="!optimizations valgrind_valgrind_h"
>  
>  # threading support
> -atomics_gcc_if_any="sync_val_compare_and_swap atomic_compare_exchange"
> +atomics_gcc_if="sync_val_compare_and_swap"
>  atomics_suncc_if="atomic_cas_ptr machine_rw_barrier"
>  atomics_win32_if="MemoryBarrier"
>  atomics_native_if_any="$ATOMICS_LIST"
> @@ -5533,7 +5532,6 @@ if ! disabled network; then
>  fi
>  
>  check_builtin atomic_cas_ptr atomic.h "void **ptr; void *oldval, *newval; 
> atomic_cas_ptr(ptr, oldval, newval)"
> -check_builtin atomic_compare_exchange "" "int *ptr, *oldval; int newval; 
> __atomic_compare_exchange_n(ptr, oldval, newval, 0, __ATOMIC_SEQ_CST, 
> __ATOMIC_SEQ_CST)"
>  check_builtin machine_rw_barrier mbarrier.h "__machine_rw_barrier()"
>  check_builtin MemoryBarrier windows.h "MemoryBarrier()"
>  check_builtin sarestart signal.h "SA_RESTART"
> diff --git a/libavutil/atomic_gcc.h b/libavutil/atomic_gcc.h
> index 5f9fc49ba0..2bb43c3cea 100644
> --- a/libavutil/atomic_gcc.h
> +++ b/libavutil/atomic_gcc.h
> @@ -28,40 +28,27 @@
>  #define avpriv_atomic_int_get atomic_int_get_gcc
>  static inline int atomic_int_get_gcc(volatile int *ptr)
>  {
> -#if HAVE_ATOMIC_COMPARE_EXCHANGE
> -return __atomic_load_n(ptr, __ATOMIC_SEQ_CST);
> -#else
>  __sync_synchronize();
>  return *ptr;
> -#endif
>  }
>  
>  #define avpriv_atomic_int_set atomic_int_set_gcc
>  static inline void atomic_int_set_gcc(volatile int *ptr, int val)
>  {
> -#if HAVE_ATOMIC_COMPARE_EXCHANGE
> -__atomic_store_n(ptr, val, __ATOMIC_SEQ_CST);
> -#else
>  *ptr = val;
>  __sync_synchronize();
> -#endif
>  }
>  
>  #define avpriv_atomic_int_add_and_fetch atomic_int_add_and_fetch_gcc
>  static inline int atomic_int_add_and_fetch_gcc(volatile int *ptr, int inc)
>  {
> -#if HAVE_ATOMIC_COMPARE_EXCHANGE
> -return __atomic_add_fetch(ptr, inc, __ATOMIC_SEQ_CST);
> -#else
>  return __sync_add_and_fetch(ptr, inc);
> -#endif
>  }
>  
>  #define avpriv_atomic_ptr_cas atomic_ptr_cas_gcc
>  static inline void *atomic_ptr_cas_gcc(void * volatile *ptr,
> void *oldval, void *newval)
>  {
> -#if HAVE_SYNC_VAL_COMPARE_AND_SWAP
>  #ifdef __ARMCC_VERSION
>  // armcc will throw an error if ptr is not an integer type
>  volatile uintptr_t *tmp = (volatile uintptr_t*)ptr;
> @@ -69,10 +56,6 @@ static inline void *atomic_ptr_cas_gcc(void * volatile 
> *ptr,
>  #else
>  return __sync_val_compare_and_swap(ptr, oldval, newval);
>  #endif
> -#else
> -__atomic_compare_exchange_n(ptr, , newval, 0, __ATOMIC_SEQ_CST, 
> __ATOMIC_SEQ_CST);
> -return oldval;
> -#endif
>  }
>  
>  #endif /* AVUTIL_ATOMIC_GCC_H */

Sounds like a good thing.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 1/4] avcodec/allcodecs: make avcodec_register_all thread safe

[wm4]

On Tue,  7 Mar 2017 02:47:36 +0700
Muhammad Faiz  wrote:

> Signed-off-by: Muhammad Faiz 
> ---
>  libavcodec/allcodecs.c | 13 ++---
>  1 file changed, 10 insertions(+), 3 deletions(-)
> 
> diff --git a/libavcodec/allcodecs.c b/libavcodec/allcodecs.c
> index eee322b..1d05fc1 100644
> --- a/libavcodec/allcodecs.c
> +++ b/libavcodec/allcodecs.c
> @@ -24,6 +24,8 @@
>   * Provide registration of all codecs, parsers and bitstream filters for 
> libavcodec.
>   */
>  
> +#include 
> +
>  #include "config.h"
>  #include "avcodec.h"
>  #include "version.h"
> @@ -60,11 +62,14 @@
>  
>  void avcodec_register_all(void)
>  {
> -static int initialized;
> +static atomic_int initialized;
> +static atomic_int ready;
>  
> -if (initialized)
> +if (atomic_exchange_explicit(, 1, memory_order_relaxed)) {
> +while (!atomic_load_explicit(, memory_order_relaxed))
> +;
>  return;
> -initialized = 1;
> +}
>  
>  /* hardware accelerators */
>  REGISTER_HWACCEL(H263_VAAPI,h263_vaapi);
> @@ -716,4 +721,6 @@ void avcodec_register_all(void)
>  REGISTER_PARSER(VP8,vp8);
>  REGISTER_PARSER(VP9,vp9);
>  REGISTER_PARSER(XMA,xma);
> +
> +atomic_store_explicit(, 1, memory_order_relaxed);
>  }

avcodec_register() is already "safe" by attempting to do lock-free and
wait-free list insertion (not very convincing IMHO, but it's there).
Should that code be removed? Does anyone know why avcodec_register() is
even still public API? The same affects some other things.

Also, if you want to do it right, please use ff_thread_once() to do it
without busy waiting. It works like pthread_once(), which was invented
to avoid such constructions.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 1/4] lavfi: remove af_resample

[wm4]

On Mon, 6 Mar 2017 20:58:53 -0300
James Almer  wrote:

> On 3/6/2017 8:20 PM, Rostislav Pehlivanov wrote:
> > On 6 March 2017 at 22:45, James Almer  wrote:
> >   
> >> On 3/5/2017 11:46 PM, Rostislav Pehlivanov wrote:  
> >>> af_aresample does the same thing better and doesn't depend on
> >>> libavresample  
> >>
> >> But it depends on libswresample. What about the builds that are using
> >> lavr but nor lswr?
> >>  
> > 
> > You mean that library which is disabled by default? We tell people to use
> > the actual stuff we support rather than the stuff we've let in "for
> > convenience", like we've done for the past 5 bloody years.  
> 
> Yes, the library we disable by default but that some downstream projects
> enable to easily support both projects without a massive amount of custom
> codepaths or ifdeffery.

I still think that it's moronic bullshit to disable lavr by default.
How about you don't take your moronic fork drama bullshit out on your
API users?

> > 
> >   
> >>
> >> Is the purpose of this set to pave the way for a lavr removal? Because
> >> one thing is dropping ABI compatibility with libav since it was being a
> >> pain in the ass and probably not even working, but another is dropping
> >> whole modules or being increasingly API incompatible.
> >>
> >>  
> > So what if it is?
> > I'm not interested if it take 1 month, 6 months, a year, 2 years, that crap
> > is getting out of our code. If you ask me it should never have been merged. 
> >  
> 
> You seem to have forgotten the very long years where Debian shipped libav
> and not ffmpeg. Had we not merged that library and dropped API/ABI support
> from the get go, who knows what would have happened.

I doubt anyone really made use of the ABI compat. (you needed a special
configure flag to make fully use of it).

> > I'll write a shim just to keep people like you happy.  
> 
> I'd very much like if every other of your emails could stop being so
> aggressive when it's completely unjustifiable. You seem to be reacting to
> some old frustration with this code (or code you dislike in general) rather
> than to an email by "people like me" where I'm simply expressing the need
> to not disrupt downstream projects too much unless necessary.
> 
> > 
> >   
> >> If it gets in the way of some addition or refactoring then sure, I'm ok
> >> with an eventual removal, but if it's just "Redundant filter/library I
> >> don't want around" then not so much, because said redundancy was accepted
> >> in the first place to make downstream projects' and users' lives easier.
> >>
> >>  
> > And who's going to maintain it once their project dies? We? We already have
> > a better resampling library in our code. We won't need it.
> > As I said before I'll write a fucking API shim when I submit the patches to
> > kill that thing. Even if its half working it'll still work just about as
> > well as that thing's idea of "resampling".
> > 
> > Anyway I'm pushing this patch in a few days unless someone objects validly. 
> >  
> 
> My concerns are very valid, and i ask you again to drop the aggressiveness.
> You'll write a shim? That's great. Just don't be a dick when you're informing
> me about it.
> 
> And for that matter, if the general consensus is to drop all pretenses of API
> compatibility then i have no issues with all this. You wouldn't even need to
> write a shim in that case.

Who is talking about dropping API-compatibility? As long as there are
aliases for these extremely similar filters, the level of potential
breakages should be very minimal. I'm all for removing redundant code.
(Patch 2/4 is potentially contentious, but if someone tried to use that
in a portable way, he had to ifdef it between FFmpeg/Libav anyway,
because the main use is changing the options of auto-inserted
resamplers.)
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] avutil/tests/lfg.c: added proper normality test

[Thomas Turner]

./configure command worked without ccache:

./configure --enable-debug=3 --arch=x86_32 --target-os=linux
--extra-cflags=-m32 --extra-ldflags=-m32  --enable-cross-compile

but after installing the following software packages w/ apt-get:

apt-get install gcc-multilib g++-mult

after recompiling and installing ffmpeg and running lfg selftest again, the
test still passes for x86_32 w/ gcc.
Just to double check the results, i ran the lfg test in a virtual machine
running 32 bit ubuntu and the test indeed passes.

So i am unable to reproduce the error on x86_32.



On Fri, Feb 24, 2017 at 7:53 PM, Michael Niedermayer  wrote:

> On Fri, Feb 24, 2017 at 07:13:05PM -0800, Thomas Turner wrote:
> [...]
> > ccache gcc -m32 -c -o /tmp/ffconf.2gbznSmZ.o /tmp/ffconf.72hnkFGt.c
> > ./configure: 884: ./configure: ccache: not found
> > C compiler test failed.
>
> try without ccache
>
> [...]
>
> --
> Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
>
> Those who are too smart to engage in politics are punished by being
> governed by those who are dumber. -- Plato
>
> ___
> 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] Revert "lavu/atomic: add support for the new memory model aware gcc built-ins"

[James Almer]

This reverts commit faa9d2982969c999ab0e443a226eff116f7f8e4b.

This change became superfluous when support for C11 atomics was introduced.
Reverting it will make the removal of this implementation in an upcoming
merge conflict free.

Signed-off-by: James Almer 
---
 configure  |  4 +---
 libavutil/atomic_gcc.h | 17 -
 2 files changed, 1 insertion(+), 20 deletions(-)

diff --git a/configure b/configure
index 0199fec5c0..6350942ef9 100755
--- a/configure
+++ b/configure
@@ -1821,7 +1821,6 @@ ARCH_FEATURES="
 
 BUILTIN_LIST="
 atomic_cas_ptr
-atomic_compare_exchange
 machine_rw_barrier
 MemoryBarrier
 mm_empty
@@ -2322,7 +2321,7 @@ symver_if_any="symver_asm_label symver_gnu_asm"
 valgrind_backtrace_deps="!optimizations valgrind_valgrind_h"
 
 # threading support
-atomics_gcc_if_any="sync_val_compare_and_swap atomic_compare_exchange"
+atomics_gcc_if="sync_val_compare_and_swap"
 atomics_suncc_if="atomic_cas_ptr machine_rw_barrier"
 atomics_win32_if="MemoryBarrier"
 atomics_native_if_any="$ATOMICS_LIST"
@@ -5533,7 +5532,6 @@ if ! disabled network; then
 fi
 
 check_builtin atomic_cas_ptr atomic.h "void **ptr; void *oldval, *newval; 
atomic_cas_ptr(ptr, oldval, newval)"
-check_builtin atomic_compare_exchange "" "int *ptr, *oldval; int newval; 
__atomic_compare_exchange_n(ptr, oldval, newval, 0, __ATOMIC_SEQ_CST, 
__ATOMIC_SEQ_CST)"
 check_builtin machine_rw_barrier mbarrier.h "__machine_rw_barrier()"
 check_builtin MemoryBarrier windows.h "MemoryBarrier()"
 check_builtin sarestart signal.h "SA_RESTART"
diff --git a/libavutil/atomic_gcc.h b/libavutil/atomic_gcc.h
index 5f9fc49ba0..2bb43c3cea 100644
--- a/libavutil/atomic_gcc.h
+++ b/libavutil/atomic_gcc.h
@@ -28,40 +28,27 @@
 #define avpriv_atomic_int_get atomic_int_get_gcc
 static inline int atomic_int_get_gcc(volatile int *ptr)
 {
-#if HAVE_ATOMIC_COMPARE_EXCHANGE
-return __atomic_load_n(ptr, __ATOMIC_SEQ_CST);
-#else
 __sync_synchronize();
 return *ptr;
-#endif
 }
 
 #define avpriv_atomic_int_set atomic_int_set_gcc
 static inline void atomic_int_set_gcc(volatile int *ptr, int val)
 {
-#if HAVE_ATOMIC_COMPARE_EXCHANGE
-__atomic_store_n(ptr, val, __ATOMIC_SEQ_CST);
-#else
 *ptr = val;
 __sync_synchronize();
-#endif
 }
 
 #define avpriv_atomic_int_add_and_fetch atomic_int_add_and_fetch_gcc
 static inline int atomic_int_add_and_fetch_gcc(volatile int *ptr, int inc)
 {
-#if HAVE_ATOMIC_COMPARE_EXCHANGE
-return __atomic_add_fetch(ptr, inc, __ATOMIC_SEQ_CST);
-#else
 return __sync_add_and_fetch(ptr, inc);
-#endif
 }
 
 #define avpriv_atomic_ptr_cas atomic_ptr_cas_gcc
 static inline void *atomic_ptr_cas_gcc(void * volatile *ptr,
void *oldval, void *newval)
 {
-#if HAVE_SYNC_VAL_COMPARE_AND_SWAP
 #ifdef __ARMCC_VERSION
 // armcc will throw an error if ptr is not an integer type
 volatile uintptr_t *tmp = (volatile uintptr_t*)ptr;
@@ -69,10 +56,6 @@ static inline void *atomic_ptr_cas_gcc(void * volatile *ptr,
 #else
 return __sync_val_compare_and_swap(ptr, oldval, newval);
 #endif
-#else
-__atomic_compare_exchange_n(ptr, , newval, 0, __ATOMIC_SEQ_CST, 
__ATOMIC_SEQ_CST);
-return oldval;
-#endif
 }
 
 #endif /* AVUTIL_ATOMIC_GCC_H */
-- 
2.12.0

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

Re: [FFmpeg-devel] [PATCH 1/4] avcodec/allcodecs: make avcodec_register_all thread safe

[James Almer]

On 3/6/2017 11:55 PM, Michael Niedermayer wrote:
> On Tue, Mar 07, 2017 at 02:47:36AM +0700, Muhammad Faiz wrote:
>> Signed-off-by: Muhammad Faiz 
>> ---
>>  libavcodec/allcodecs.c | 13 ++---
>>  1 file changed, 10 insertions(+), 3 deletions(-)
> 
> fails to build
> 
> ibavcodec/allcodecs.c: In function ‘avcodec_register_all’:
> libavcodec/allcodecs.c:68:5: error: implicit declaration of function ‘typeof’ 
> [-Werror=implicit-function-declaration]
> libavcodec/allcodecs.c:68:33: error: expected ‘;’ before ‘_obj’
> libavcodec/allcodecs.c:68:78: error: expected ‘;’ before ‘_old’
> libavcodec/allcodecs.c:68:87: error: ‘_old’ undeclared (first use in this 
> function)
> libavcodec/allcodecs.c:68:87: note: each undeclared identifier is reported 
> only once for each function it appears in
> libavcodec/allcodecs.c:68:119: error: ‘_obj’ undeclared (first use in this 
> function)
> libavcodec/allcodecs.c:68:78: error: incompatible type for argument 1 of 
> ‘__sync_bool_compare_and_swap’
> cc1: some warnings being treated as errors
> make: *** [libavcodec/allcodecs.o] Error 1
> make: *** Waiting for unfinished jobs

This is from the compat header for c11 atomics on old GCC versions.
Looks like it should be using __typeof__ instead.

Try the attached patch.

>From 5af305a9180b691577e48731d9ca84a3b2342404 Mon Sep 17 00:00:00 2001
From: James Almer 
Date: Tue, 7 Mar 2017 00:04:46 -0300
Subject: [PATCH] compat/atomics/gcc: use __typeof__ instead of typeof

Signed-off-by: James Almer 
---
 compat/atomics/gcc/stdatomic.h | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/compat/atomics/gcc/stdatomic.h b/compat/atomics/gcc/stdatomic.h
index 41caddec5c..2b64687437 100644
--- a/compat/atomics/gcc/stdatomic.h
+++ b/compat/atomics/gcc/stdatomic.h
@@ -100,8 +100,8 @@ do {\
 
 #define atomic_exchange(object, desired)\
 ({  \
-typeof(object) _obj = (object); \
-typeof(*object) _old;   \
+__typeof__(object) _obj = (object); \
+__typeof__(*object) _old;   \
 do  \
 _old = atomic_load(_obj);   \
 while (!__sync_bool_compare_and_swap(_obj, _old, (desired)));   \
@@ -113,8 +113,8 @@ do {\
 
 #define atomic_compare_exchange_strong(object, expected, desired)   \
 ({  \
-typeof(object) _exp = (expected);   \
-typeof(*object) _old = *_exp;   \
+__typeof__(object) _exp = (expected);   \
+__typeof__(*object) _old = *_exp;   \
 *_exp = __sync_val_compare_and_swap((object), _old, (desired)); \
 *_exp == _old;  \
 })
-- 
2.12.0

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

Re: [FFmpeg-devel] [PATCH 1/4] avcodec/allcodecs: make avcodec_register_all thread safe

[Michael Niedermayer]

On Tue, Mar 07, 2017 at 02:47:36AM +0700, Muhammad Faiz wrote:
> Signed-off-by: Muhammad Faiz 
> ---
>  libavcodec/allcodecs.c | 13 ++---
>  1 file changed, 10 insertions(+), 3 deletions(-)

fails to build

ibavcodec/allcodecs.c: In function ‘avcodec_register_all’:
libavcodec/allcodecs.c:68:5: error: implicit declaration of function ‘typeof’ 
[-Werror=implicit-function-declaration]
libavcodec/allcodecs.c:68:33: error: expected ‘;’ before ‘_obj’
libavcodec/allcodecs.c:68:78: error: expected ‘;’ before ‘_old’
libavcodec/allcodecs.c:68:87: error: ‘_old’ undeclared (first use in this 
function)
libavcodec/allcodecs.c:68:87: note: each undeclared identifier is reported only 
once for each function it appears in
libavcodec/allcodecs.c:68:119: error: ‘_obj’ undeclared (first use in this 
function)
libavcodec/allcodecs.c:68:78: error: incompatible type for argument 1 of 
‘__sync_bool_compare_and_swap’
cc1: some warnings being treated as errors
make: *** [libavcodec/allcodecs.o] Error 1
make: *** Waiting for unfinished jobs


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

The bravest are surely those who have the clearest vision
of what is before them, glory and danger alike, and yet
notwithstanding go out to meet it. -- Thucydides


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

Re: [FFmpeg-devel] [RFC] Removal of the "x264opts" libx264 wrapper AVOption

[Lou Logan]

On Tue,  7 Mar 2017 00:20:19 +0200, Jan Ekström wrote:

> Hi,
> 
> I am not sure what the correct order of things to remove an AVOption is,
> but I would like to propose that the "x264opts" AVOption be removed, as it
> duplicates "x264-params", which has a matching pair over at the libx265
> wrapper.
> 
> Also, this way we would get rid of one in a group of similar features we
> have a duplicate of in our code base.
> 
> Jan Ekström (2):
>   libx264: remove the "x264opts" AVOption
>   doc/encoders: remove mentions of the x264opts AVOption
> 
>  doc/encoders.texi| 25 ++---
>  libavcodec/libx264.c | 29 -
>  2 files changed, 6 insertions(+), 48 deletions(-)
> 

Instead of updating the -x264opts example that Marton pointed out you
can just delete it because an existing -x264-params example is
immediately below it.

The rest of the patch series LGTM.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 1/4] lavfi: remove af_resample

[James Almer]

On 3/6/2017 8:20 PM, Rostislav Pehlivanov wrote:
> On 6 March 2017 at 22:45, James Almer  wrote:
> 
>> On 3/5/2017 11:46 PM, Rostislav Pehlivanov wrote:
>>> af_aresample does the same thing better and doesn't depend on
>>> libavresample
>>
>> But it depends on libswresample. What about the builds that are using
>> lavr but nor lswr?
>>
> 
> You mean that library which is disabled by default? We tell people to use
> the actual stuff we support rather than the stuff we've let in "for
> convenience", like we've done for the past 5 bloody years.

Yes, the library we disable by default but that some downstream projects
enable to easily support both projects without a massive amount of custom
codepaths or ifdeffery.

> 
> 
>>
>> Is the purpose of this set to pave the way for a lavr removal? Because
>> one thing is dropping ABI compatibility with libav since it was being a
>> pain in the ass and probably not even working, but another is dropping
>> whole modules or being increasingly API incompatible.
>>
>>
> So what if it is?
> I'm not interested if it take 1 month, 6 months, a year, 2 years, that crap
> is getting out of our code. If you ask me it should never have been merged.

You seem to have forgotten the very long years where Debian shipped libav
and not ffmpeg. Had we not merged that library and dropped API/ABI support
from the get go, who knows what would have happened.

> I'll write a shim just to keep people like you happy.

I'd very much like if every other of your emails could stop being so
aggressive when it's completely unjustifiable. You seem to be reacting to
some old frustration with this code (or code you dislike in general) rather
than to an email by "people like me" where I'm simply expressing the need
to not disrupt downstream projects too much unless necessary.

> 
> 
>> If it gets in the way of some addition or refactoring then sure, I'm ok
>> with an eventual removal, but if it's just "Redundant filter/library I
>> don't want around" then not so much, because said redundancy was accepted
>> in the first place to make downstream projects' and users' lives easier.
>>
>>
> And who's going to maintain it once their project dies? We? We already have
> a better resampling library in our code. We won't need it.
> As I said before I'll write a fucking API shim when I submit the patches to
> kill that thing. Even if its half working it'll still work just about as
> well as that thing's idea of "resampling".
> 
> Anyway I'm pushing this patch in a few days unless someone objects validly.

My concerns are very valid, and i ask you again to drop the aggressiveness.
You'll write a shim? That's great. Just don't be a dick when you're informing
me about it.

And for that matter, if the general consensus is to drop all pretenses of API
compatibility then i have no issues with all this. You wouldn't even need to
write a shim in that case.

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

Re: [FFmpeg-devel] [PATCH 1/4] lavfi: remove af_resample

[Rostislav Pehlivanov]

On 6 March 2017 at 22:45, James Almer  wrote:

> On 3/5/2017 11:46 PM, Rostislav Pehlivanov wrote:
> > af_aresample does the same thing better and doesn't depend on
> > libavresample
>
> But it depends on libswresample. What about the builds that are using
> lavr but nor lswr?
>

You mean that library which is disabled by default? We tell people to use
the actual stuff we support rather than the stuff we've let in "for
convenience", like we've done for the past 5 bloody years.


>
> Is the purpose of this set to pave the way for a lavr removal? Because
> one thing is dropping ABI compatibility with libav since it was being a
> pain in the ass and probably not even working, but another is dropping
> whole modules or being increasingly API incompatible.
>
>
So what if it is?
I'm not interested if it take 1 month, 6 months, a year, 2 years, that crap
is getting out of our code. If you ask me it should never have been merged.
I'll write a shim just to keep people like you happy.


> If it gets in the way of some addition or refactoring then sure, I'm ok
> with an eventual removal, but if it's just "Redundant filter/library I
> don't want around" then not so much, because said redundancy was accepted
> in the first place to make downstream projects' and users' lives easier.
>
>
And who's going to maintain it once their project dies? We? We already have
a better resampling library in our code. We won't need it.
As I said before I'll write a fucking API shim when I submit the patches to
kill that thing. Even if its half working it'll still work just about as
well as that thing's idea of "resampling".



Anyway I'm pushing this patch in a few days unless someone objects validly.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 2/2] doc/encoders: remove mentions of the x264opts AVOption

[Jan Ekstrom]

On Tue, Mar 7, 2017 at 12:44 AM, Marton Balint  wrote:
> I guess you meant to convert this to -x264-params as well, no?
>
> Thanks,
> Marton

Yup, welcome to doing things after midnight.

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

Re: [FFmpeg-devel] [PATCH 1/4] lavfi: remove af_resample

[James Almer]

On 3/5/2017 11:46 PM, Rostislav Pehlivanov wrote:
> af_aresample does the same thing better and doesn't depend on
> libavresample

But it depends on libswresample. What about the builds that are using
lavr but nor lswr?

Is the purpose of this set to pave the way for a lavr removal? Because
one thing is dropping ABI compatibility with libav since it was being a
pain in the ass and probably not even working, but another is dropping
whole modules or being increasingly API incompatible.

If it gets in the way of some addition or refactoring then sure, I'm ok
with an eventual removal, but if it's just "Redundant filter/library I
don't want around" then not so much, because said redundancy was accepted
in the first place to make downstream projects' and users' lives easier.

> 
> Signed-off-by: Rostislav Pehlivanov 
> ---
>  libavfilter/Makefile  |   1 -
>  libavfilter/af_resample.c | 357 
> --
>  2 files changed, 358 deletions(-)
>  delete mode 100644 libavfilter/af_resample.c
> 
> diff --git a/libavfilter/Makefile b/libavfilter/Makefile
> index 0ba1c74a26..6b9fba2d4c 100644
> --- a/libavfilter/Makefile
> +++ b/libavfilter/Makefile
> @@ -98,7 +98,6 @@ OBJS-$(CONFIG_LOUDNORM_FILTER)   += 
> af_loudnorm.o ebur128.o
>  OBJS-$(CONFIG_LOWPASS_FILTER)+= af_biquads.o
>  OBJS-$(CONFIG_PAN_FILTER)+= af_pan.o
>  OBJS-$(CONFIG_REPLAYGAIN_FILTER) += af_replaygain.o
> -OBJS-$(CONFIG_RESAMPLE_FILTER)   += af_resample.o
>  OBJS-$(CONFIG_RUBBERBAND_FILTER) += af_rubberband.o
>  OBJS-$(CONFIG_SIDECHAINCOMPRESS_FILTER)  += af_sidechaincompress.o
>  OBJS-$(CONFIG_SIDECHAINGATE_FILTER)  += af_agate.o
> diff --git a/libavfilter/af_resample.c b/libavfilter/af_resample.c
> deleted file mode 100644
> index e3c6a20696..00
> --- a/libavfilter/af_resample.c
> +++ /dev/null
> @@ -1,357 +0,0 @@
> -/*
> - * 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
> - * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 
> USA
> - */
> -
> -/**
> - * @file
> - * sample format and channel layout conversion audio filter
> - */
> -
> -#include "libavutil/avassert.h"
> -#include "libavutil/avstring.h"
> -#include "libavutil/common.h"
> -#include "libavutil/dict.h"
> -#include "libavutil/mathematics.h"
> -#include "libavutil/opt.h"
> -
> -#include "libavresample/avresample.h"
> -
> -#include "audio.h"
> -#include "avfilter.h"
> -#include "formats.h"
> -#include "internal.h"
> -
> -typedef struct ResampleContext {
> -const AVClass *class;
> -AVAudioResampleContext *avr;
> -AVDictionary *options;
> -
> -int resampling;
> -int64_t next_pts;
> -int64_t next_in_pts;
> -
> -/* set by filter_frame() to signal an output frame to request_frame() */
> -int got_output;
> -} ResampleContext;
> -
> -static av_cold int init(AVFilterContext *ctx, AVDictionary **opts)
> -{
> -ResampleContext *s = ctx->priv;
> -const AVClass *avr_class = avresample_get_class();
> -AVDictionaryEntry *e = NULL;
> -
> -while ((e = av_dict_get(*opts, "", e, AV_DICT_IGNORE_SUFFIX))) {
> -if (av_opt_find(_class, e->key, NULL, 0,
> -AV_OPT_SEARCH_FAKE_OBJ | AV_OPT_SEARCH_CHILDREN))
> -av_dict_set(>options, e->key, e->value, 0);
> -}
> -
> -e = NULL;
> -while ((e = av_dict_get(s->options, "", e, AV_DICT_IGNORE_SUFFIX)))
> -av_dict_set(opts, e->key, NULL, 0);
> -
> -/* do not allow the user to override basic format options */
> -av_dict_set(>options,  "in_channel_layout", NULL, 0);
> -av_dict_set(>options, "out_channel_layout", NULL, 0);
> -av_dict_set(>options,  "in_sample_fmt", NULL, 0);
> -av_dict_set(>options, "out_sample_fmt", NULL, 0);
> -av_dict_set(>options,  "in_sample_rate",NULL, 0);
> -av_dict_set(>options, "out_sample_rate",NULL, 0);
> -
> -return 0;
> -}
> -
> -static av_cold void uninit(AVFilterContext *ctx)
> -{
> -ResampleContext *s = ctx->priv;
> -
> -if (s->avr) {
> -avresample_close(s->avr);
> -avresample_free(>avr);
> -}
> -av_dict_free(>options);
> -}
> -
> -static int query_formats(AVFilterContext *ctx)
> -{
> -AVFilterLink *inlink  = 

Re: [FFmpeg-devel] [PATCH 2/2] doc/encoders: remove mentions of the x264opts AVOption

[Marton Balint]

On Tue, 7 Mar 2017, Jan Ekström wrote:


---
doc/encoders.texi | 25 ++---
1 file changed, 6 insertions(+), 19 deletions(-)

diff --git a/doc/encoders.texi b/doc/encoders.texi
index 594c612..ee28b9b 100644
--- a/doc/encoders.texi
+++ b/doc/encoders.texi
@@ -1762,9 +1762,9 @@ for detail retention (adaptive quantization, psy-RD, 
psy-trellis).

Many libx264 encoder options are mapped to FFmpeg global codec
options, while unique encoder options are provided through private
-options. Additionally the @option{x264opts} and @option{x264-params}
-private options allows one to pass a list of key=value tuples as accepted
-by the libx264 @code{x264_param_parse} function.
+options. Additionally the @option{x264-params} private option allows one
+to pass a list of key=value tuples as accepted by the libx264
+@code{x264_param_parse} function.

The x264 project website is at
@url{http://www.videolan.org/developers/x264.html}.
@@ -2094,19 +2094,6 @@ Variable bit rate.
Constant bit rate (not allowed in MP4 container).
@end table

-@item x264opts (N.A.)
-Set any x264 option, see @command{x264 --fullhelp} for a list.
-
-Argument is a list of @var{key}=@var{value} couples separated by
-":". In @var{filter} and @var{psy-rd} options that use ":" as a separator
-themselves, use "," instead. They accept it as well since long ago but this
-is kept undocumented for some reason.
-
-For example to specify libx264 encoding options with @command{ffmpeg}:
-@example
-ffmpeg -i foo.mpg -vcodec libx264 -x264opts keyint=123:min-keyint=20 -an 
out.mkv
-@end example
-
@item a53cc @var{boolean}
Import closed captions (which must be ATSC compatible format) into output.
Only the mpeg2 and h264 decoders provide these. Default is 1 (on).
@@ -2115,11 +2102,11 @@ Only the mpeg2 and h264 decoders provide these. Default 
is 1 (on).
Override the x264 configuration using a :-separated list of key=value
parameters.

-This option is functionally the same as the @option{x264opts}, but is
-duplicated for compatibility with the Libav fork.
-
For example to specify libx264 encoding options with @command{ffmpeg}:
@example
+ffmpeg -i foo.mpg -vcodec libx264 -x264opts keyint=123:min-keyint=20 -an 
out.mkv


I guess you meant to convert this to -x264-params as well, no?

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

[FFmpeg-devel] [RFC] Removal of the "x264opts" libx264 wrapper AVOption

[Jan Ekström]

Hi,

I am not sure what the correct order of things to remove an AVOption is,
but I would like to propose that the "x264opts" AVOption be removed, as it
duplicates "x264-params", which has a matching pair over at the libx265
wrapper.

Also, this way we would get rid of one in a group of similar features we
have a duplicate of in our code base.

Jan Ekström (2):
  libx264: remove the "x264opts" AVOption
  doc/encoders: remove mentions of the x264opts AVOption

 doc/encoders.texi| 25 ++---
 libavcodec/libx264.c | 29 -
 2 files changed, 6 insertions(+), 48 deletions(-)

-- 
2.9.3

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

[FFmpeg-devel] [PATCH 2/2] doc/encoders: remove mentions of the x264opts AVOption

[Jan Ekström]

---
 doc/encoders.texi | 25 ++---
 1 file changed, 6 insertions(+), 19 deletions(-)

diff --git a/doc/encoders.texi b/doc/encoders.texi
index 594c612..ee28b9b 100644
--- a/doc/encoders.texi
+++ b/doc/encoders.texi
@@ -1762,9 +1762,9 @@ for detail retention (adaptive quantization, psy-RD, 
psy-trellis).
 
 Many libx264 encoder options are mapped to FFmpeg global codec
 options, while unique encoder options are provided through private
-options. Additionally the @option{x264opts} and @option{x264-params}
-private options allows one to pass a list of key=value tuples as accepted
-by the libx264 @code{x264_param_parse} function.
+options. Additionally the @option{x264-params} private option allows one
+to pass a list of key=value tuples as accepted by the libx264
+@code{x264_param_parse} function.
 
 The x264 project website is at
 @url{http://www.videolan.org/developers/x264.html}.
@@ -2094,19 +2094,6 @@ Variable bit rate.
 Constant bit rate (not allowed in MP4 container).
 @end table
 
-@item x264opts (N.A.)
-Set any x264 option, see @command{x264 --fullhelp} for a list.
-
-Argument is a list of @var{key}=@var{value} couples separated by
-":". In @var{filter} and @var{psy-rd} options that use ":" as a separator
-themselves, use "," instead. They accept it as well since long ago but this
-is kept undocumented for some reason.
-
-For example to specify libx264 encoding options with @command{ffmpeg}:
-@example
-ffmpeg -i foo.mpg -vcodec libx264 -x264opts keyint=123:min-keyint=20 -an 
out.mkv
-@end example
-
 @item a53cc @var{boolean}
 Import closed captions (which must be ATSC compatible format) into output.
 Only the mpeg2 and h264 decoders provide these. Default is 1 (on).
@@ -2115,11 +2102,11 @@ Only the mpeg2 and h264 decoders provide these. Default 
is 1 (on).
 Override the x264 configuration using a :-separated list of key=value
 parameters.
 
-This option is functionally the same as the @option{x264opts}, but is
-duplicated for compatibility with the Libav fork.
-
 For example to specify libx264 encoding options with @command{ffmpeg}:
 @example
+ffmpeg -i foo.mpg -vcodec libx264 -x264opts keyint=123:min-keyint=20 -an 
out.mkv
+@end example
+@example
 ffmpeg -i INPUT -c:v libx264 -x264-params level=30:bframes=0:weightp=0:\
 cabac=0:ref=1:vbv-maxrate=768:vbv-bufsize=2000:analyse=all:me=umh:\
 no-fast-pskip=1:subq=6:8x8dct=0:trellis=0 OUTPUT
-- 
2.9.3

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

[FFmpeg-devel] [PATCH 1/2] libx264: remove the "x264opts" AVOption

[Jan Ekström]

x264-params does the same thing and this leaves us with a single
option that is name-matched with x265-params available in the
libx265 wrapper.
---
 libavcodec/libx264.c | 29 -
 1 file changed, 29 deletions(-)

diff --git a/libavcodec/libx264.c b/libavcodec/libx264.c
index b11ede6..5cbc376 100644
--- a/libavcodec/libx264.c
+++ b/libavcodec/libx264.c
@@ -53,7 +53,6 @@ typedef struct X264Context {
 char *level;
 int fastfirstpass;
 char *wpredp;
-char *x264opts;
 float crf;
 float crf_max;
 int cqp;
@@ -396,20 +395,6 @@ static av_cold int X264_close(AVCodecContext *avctx)
 return 0;
 }
 
-#define OPT_STR(opt, param)   \
-do {  \
-int ret;  \
-if ((ret = x264_param_parse(>params, opt, param)) < 0) { \
-if(ret == X264_PARAM_BAD_NAME)\
-av_log(avctx, AV_LOG_ERROR,   \
-"bad option '%s': '%s'\n", opt, param);   \
-else  \
-av_log(avctx, AV_LOG_ERROR,   \
-"bad value for '%s': '%s'\n", opt, param);\
-return -1;\
-} \
-} while (0)
-
 static int convert_pix_fmt(enum AVPixelFormat pix_fmt)
 {
 switch (pix_fmt) {
@@ -774,19 +759,6 @@ FF_ENABLE_DEPRECATION_WARNINGS
 if (avctx->flags & AV_CODEC_FLAG_GLOBAL_HEADER)
 x4->params.b_repeat_headers = 0;
 
-if(x4->x264opts){
-const char *p= x4->x264opts;
-while(p){
-char param[4096]={0}, val[4096]={0};
-if(sscanf(p, "%4095[^:=]=%4095[^:]", param, val) == 1){
-OPT_STR(param, "1");
-}else
-OPT_STR(param, val);
-p= strchr(p, ':');
-p+=!!p;
-}
-}
-
 if (x4->x264_params) {
 AVDictionary *dict= NULL;
 AVDictionaryEntry *en = NULL;
@@ -908,7 +880,6 @@ static const AVOption options[] = {
 {"passlogfile", "Filename for 2 pass stats", OFFSET(stats), 
AV_OPT_TYPE_STRING, {.str=NULL}, 0, 0, VE},
 {"wpredp", "Weighted prediction for P-frames", OFFSET(wpredp), 
AV_OPT_TYPE_STRING, {.str=NULL}, 0, 0, VE},
 {"a53cc",  "Use A53 Closed Captions (if available)",  
OFFSET(a53_cc),AV_OPT_TYPE_BOOL,   {.i64 = 1}, 0, 1, VE},
-{"x264opts", "x264 options", OFFSET(x264opts), AV_OPT_TYPE_STRING, 
{.str=NULL}, 0, 0, VE},
 { "crf",   "Select the quality for constant quality mode",
OFFSET(crf),   AV_OPT_TYPE_FLOAT,  {.dbl = -1 }, -1, FLT_MAX, VE },
 { "crf_max",   "In CRF mode, prevents VBV from lowering quality beyond 
this point.",OFFSET(crf_max), AV_OPT_TYPE_FLOAT, {.dbl = -1 }, -1, FLT_MAX, VE 
},
 { "qp","Constant quantization parameter rate control 
method",OFFSET(cqp),AV_OPT_TYPE_INT,{ .i64 = -1 }, -1, INT_MAX, VE 
},
-- 
2.9.3

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

Re: [FFmpeg-devel] [PATCH 4/4] lavfi: remove af_asynts filter

[Marton Balint]

On Mon, 6 Mar 2017, Rostislav Pehlivanov wrote:


Long overdue for removal, af_aresample should be used instead.

Signed-off-by: Rostislav Pehlivanov 
---
Changelog   |   1 +
configure   |   2 -
doc/filters.texi|  33 -
libavfilter/Makefile|   1 -
libavfilter/af_asyncts.c| 323 
libavfilter/allfilters.c|   1 -
libavfilter/version.h   |   2 +-
tests/fate/filter-audio.mak |   6 -
8 files changed, 2 insertions(+), 367 deletions(-)
delete mode 100644 libavfilter/af_asyncts.c

diff --git a/Changelog b/Changelog
index 13628ca28b..88e188bacb 100644
--- a/Changelog
+++ b/Changelog
@@ -2,6 +2,7 @@ Entries are sorted chronologically from oldest to youngest 
within each release,
releases are sorted from youngest to oldest.

version :
+- Removed asyncts filter (use af_aresample instead)


Entires are sorted from oldest to youngest :P

Thanks for the cleanup.

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

Re: [FFmpeg-devel] [PATCH] Clean up support for openjpeg encoder

[Aaron Boxer]

Sorry, another change: switched irreversible default to 0, which matches
the OpenJPEG default (i.e. lossless is the default)


On Mon, Mar 6, 2017 at 11:10 AM, Aaron Boxer  wrote:

> One last change: numresolution default setting changed to 6, to match
> OpenJPEG default.
>
> On Mon, Mar 6, 2017 at 10:49 AM, Aaron Boxer  wrote:
>
>> >>
>>> >> This was vertically algined. Now its not any more.
>>> >>
>>> >
>>> >
>>> > How is this? Feels like doing ASCII artwork to format this.
>>>
>>> The irreversible thing is not used at all, its just blank option.
>>>
>>
>> Yes, quite right. Here is an updated patch.
>>
>>
>>
>>
>>
>>> ___
>>> ffmpeg-devel mailing list
>>> ffmpeg-devel@ffmpeg.org
>>> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>>>
>>
>>
>


0001-1.-limit-to-single-layer-as-there-is-no-current-supp.patch
Description: Binary data
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 1/2] (was Re: deduplicated [PATCH] Cinepak: speed up decoding several-fold...) formats.

[u-9iep]

Hello Karl,

I appreciate your interest and comments.

Keeping on topic, to the patch decision makers:

 I actually complied with all real suggestions heard during
 the discussion, even with those I find being misdirected,
 i.e. virtually everything except dropping the patch as a whole.

 Now I am unsure, will anybody look at the patch
 or is it so that some policy (which everyone here but me knows)
 does clearly specify that such a patch shall be rejected no matter what?

Possibly the dialogue below will be ok ontopic, as a background.

On Mon, Mar 06, 2017 at 05:42:31PM +0100, Karl Blomster wrote:
> >Nor is there any apparent reasonable way to "get rid" of those getenv()s.
> I would say that as usual when determining what is "right" in software
> architecture, the answer is "it depends". As far as I am aware, most of the

Thank you. I fully agree.

> things libav* touches environment variables for is related to interactions
> with things external to ffmpeg, such as the network (HTTP_PROXY), the
> terminal, the locations of certain types of plugins, etc. Modifying internal
> behavior based on environment variables is ugly in my opinion, and I can't
> think of any other case in ffmpeg where this is done. In general, if you
> want to interact with library functionality, do it through the API. In this
> case there's even a mechanism in place explicitly for this purpose
> (negotiating output pixelformat via the get_format callback), although I'll
> note that the ordinary use case for that is quite different from what you
> want to do here.

Exactly, the possibility to choose the pixel format is present but it
is not meant to be controlled otherwise than via a competent application.

I agree that an added envvar is by nature an intrusive change,
that's why I try to reduce the tention by omitting this
(I have to patch my own ffmpeg builds in any case).

> As far as SDL goes, I'll just note that the documentation states that
> "[u]sing these variables isn't recommended and the names and presence of
> these variables aren't guaranteed from one release to the next." They seem
> intended for debugging only.

I guess they _were_ thought for debugging while one did not realize
that some things are impossible or hard to put under the applications'
responsibility. They have since then in practice become an integral part
of the product. My opinion corresponds to the fact that the variables
always are present in the usual non-debug SDL builds, do you have a
different experience? Of course I can not talk for the usage od SDL
everywhere, my use of the SDL-bound applications would be hardly
meaningful without the variables.

> >The cost in the code is in fact not that "big", about 68 LOC per output
> >pixel format, in the latest revision. Compared to the several times (!)
> >speed loss when going through swscale it looks to me like an
> >exceptionally low hanging fruit.
> And here's one of the biggest issues in this debate and where I think you
> and wm4 et al keep talking past each other. The cost in lines of code is
> relatively unimportant. The cost in "number of different behaviors" is
> different.

Ah. I see your point. Each extra degree of freedom makes it harder
to support all the possible cases and combinations.

> In practice this isn't a huge deal for cinepak in particular
> since it already does this bit of ugliness, but surely you can see why there
> is a reluctance to add more of it?

Thanks. Pity no one else did say this. Fortunately the last version
of the patch definitely does not make the situation worse, rather
quite more regular - pal8 was handled as a special case (a very rare one,
which makes maintenance even harder, also one which made the output depend
on the format of input), rgb565 is fast, fully regular and always available
(and also well defined what it shall look like, no uncertainty like yuv).

0rgb or argb are full quality and faster than rgb24 on usual hardware
but replacing the default rgb24 format would introduce a surprise.

> Then there's also the fact that, to be blunt to the point of rudeness,
> nobody *cares* about cinepak. I'm sure that *you* do, and as you've
> repeatedly pointed out we do not have your point of view, but from the
> "mainstream" perspective or whatever you want to call it this is definitely
> a fringe codec that has very few users today. Hence the reluctance to accept

I agree, it is not so well visible as the newest heavy codecs. It is not
profitable to the CPU/GPU manufacturers nor suits the contents providers,
they _choose_ to copy every byte again and again as many times as it is
being played. That's why the compression ratio becomes so important,
because the user not the provider pays for the heavy decoding while the
provider can not avoid paying for the (accumulated) traffic, nor accepts
to optimize the transmission by decoupling the user from the service
(say, like bittorrent).

The applications using cinepak do still exist but it is seldom advertised.

OTOH 

[FFmpeg-devel] opencl on osx

[numinous_one-at-yahoo.com]

all,
i have compiled ffmpeg with opencl on osx 10.12 but.. when i run the benchmark 
ffmpeg -opencl_bench i get this error
clEnqueueNDRangeKernel error 'INVALID WORK GROUP SIZE'
[opencl @ 0x10ad10ea8] Benchmark failed with OpenCL device Intel(R) Core(TM) 
i7-4980HQ CPU @ 2.80GHz
platform_idx    device_idx    device_name    runtime
0    1    AMD Radeon R9 M370X Compute Engine    4781
0    0    Iris Pro    11438
in opencl.c i don't see anywhere where this memory allocation is set??


Sent from Yahoo Mail. Get the app
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] lswr: remove support for libsoxr resampling

[Rob Sykes]

On Mon, Mar 06, 2017 at 03:19:48AM +, Rostislav Pehlivanov wrote:


> The soxr resampler is slower and worse than the swr resampler,
> hence drop the former.
With git master of ffmpeg and libsoxr 0.1.1, using default parameters, on x86, 
soxr is indeed a little slower than swr; however many would consider soxr’s 
quality (w.r.t. aliasing artefacts etc.) to be much higher—see attached image.  
 IIRC, when resampling with other options (such as using a ‘steep’ filter), 
soxr (0.1.1) is faster than swr.
These relative merits formed the basis for including soxr originally and are 
unchanged AFAIK.
Btw, testing using git master of libsoxr shows soxr to be faster than swr even 
with default parameters.

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

Re: [FFmpeg-devel] [PATCH] lavc/libvpxenc: add -row-mt option

[James Zern]

On Fri, Mar 3, 2017 at 4:52 PM, James Zern  wrote:
> On Fri, Mar 3, 2017 at 2:20 AM, Kagami Hiiragi  wrote:
>> [...]
>>
>> Updated. I don't think -slices would fit logically because -row-mt is 
>> boolean and -slices is integer.
>>
>> ---
>>  libavcodec/libvpxenc.c | 11 +++
>>  1 file changed, 11 insertions(+)
>>
>
> Looks all right, I'll submit it soon if there are no other comments.

Applied. Thanks for the patch.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH 3/4] avfilter/allfilters: make avfilter_register_all thread safe

[Muhammad Faiz]

Signed-off-by: Muhammad Faiz 
---
 libavfilter/allfilters.c | 13 ++---
 1 file changed, 10 insertions(+), 3 deletions(-)

diff --git a/libavfilter/allfilters.c b/libavfilter/allfilters.c
index 15a74c4..2042b35 100644
--- a/libavfilter/allfilters.c
+++ b/libavfilter/allfilters.c
@@ -19,6 +19,8 @@
  * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA
  */
 
+#include 
+
 #include "avfilter.h"
 #include "config.h"
 #include "opencl_allkernels.h"
@@ -39,11 +41,14 @@
 
 void avfilter_register_all(void)
 {
-static int initialized;
+static atomic_int initialized;
+static atomic_int ready;
 
-if (initialized)
+if (atomic_exchange_explicit(, 1, memory_order_relaxed)) {
+while (!atomic_load_explicit(, memory_order_relaxed))
+;
 return;
-initialized = 1;
+}
 
 REGISTER_FILTER(ABENCH, abench, af);
 REGISTER_FILTER(ACOMPRESSOR,acompressor,af);
@@ -379,4 +384,6 @@ void avfilter_register_all(void)
 REGISTER_FILTER_UNCONDITIONAL(af_afifo);
 REGISTER_FILTER_UNCONDITIONAL(vf_fifo);
 ff_opencl_register_filter_kernel_code_all();
+
+atomic_store_explicit(, 1, memory_order_relaxed);
 }
-- 
2.9.3

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

[FFmpeg-devel] [PATCH 2/4] avformat/allformats: make av_register_all thread safe

[Muhammad Faiz]

Signed-off-by: Muhammad Faiz 
---
 libavformat/allformats.c | 12 +---
 1 file changed, 9 insertions(+), 3 deletions(-)

diff --git a/libavformat/allformats.c b/libavformat/allformats.c
index 35869e3..e91a59b 100644
--- a/libavformat/allformats.c
+++ b/libavformat/allformats.c
@@ -19,6 +19,8 @@
  * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA
  */
 
+#include 
+
 #include "avformat.h"
 #include "rtp.h"
 #include "rdt.h"
@@ -43,10 +45,14 @@
 
 void av_register_all(void)
 {
-static int initialized;
+static atomic_int initialized;
+static atomic_int ready;
 
-if (initialized)
+if (atomic_exchange_explicit(, 1, memory_order_relaxed)) {
+while (!atomic_load_explicit(, memory_order_relaxed))
+;
 return;
+}
 
 avcodec_register_all();
 
@@ -384,5 +390,5 @@ void av_register_all(void)
 REGISTER_MUXDEMUX(LIBNUT,   libnut);
 REGISTER_DEMUXER (LIBOPENMPT,   libopenmpt);
 
-initialized = 1;
+atomic_store_explicit(, 1, memory_order_relaxed);
 }
-- 
2.9.3

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

Re: [FFmpeg-devel] [PATCH] Fix off-by-few crasher in ff_h2645_extract_rbsp function

[Michael Niedermayer]

On Mon, Mar 06, 2017 at 03:51:51PM +0100, Michał Krasowski wrote:
> It seems that the loop tried to access the memory regions
> beyond allocation, what caused crashes in not-so-rare cases, when
> the memory read did not belong to current process.
> 
> This change is fixing the out-of-bounds read problem.
> Compiling this function with -fsanitize=address and running doesn't
> result in sanitizer warning as before.
> ---
>  libavcodec/h2645_parse.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)

have you seen/read the documentation for AV_INPUT_BUFFER_PADDING_SIZE
?

if not, that may be the cause of the issues you see


[...]
-- 
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

[FFmpeg-devel] [PATCH 1/4] avcodec/allcodecs: make avcodec_register_all thread safe

[Muhammad Faiz]

Signed-off-by: Muhammad Faiz 
---
 libavcodec/allcodecs.c | 13 ++---
 1 file changed, 10 insertions(+), 3 deletions(-)

diff --git a/libavcodec/allcodecs.c b/libavcodec/allcodecs.c
index eee322b..1d05fc1 100644
--- a/libavcodec/allcodecs.c
+++ b/libavcodec/allcodecs.c
@@ -24,6 +24,8 @@
  * Provide registration of all codecs, parsers and bitstream filters for 
libavcodec.
  */
 
+#include 
+
 #include "config.h"
 #include "avcodec.h"
 #include "version.h"
@@ -60,11 +62,14 @@
 
 void avcodec_register_all(void)
 {
-static int initialized;
+static atomic_int initialized;
+static atomic_int ready;
 
-if (initialized)
+if (atomic_exchange_explicit(, 1, memory_order_relaxed)) {
+while (!atomic_load_explicit(, memory_order_relaxed))
+;
 return;
-initialized = 1;
+}
 
 /* hardware accelerators */
 REGISTER_HWACCEL(H263_VAAPI,h263_vaapi);
@@ -716,4 +721,6 @@ void avcodec_register_all(void)
 REGISTER_PARSER(VP8,vp8);
 REGISTER_PARSER(VP9,vp9);
 REGISTER_PARSER(XMA,xma);
+
+atomic_store_explicit(, 1, memory_order_relaxed);
 }
-- 
2.9.3

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

[FFmpeg-devel] [PATCH 4/4] avdevice/alldevice: make avdevice_register_all thread safe

[Muhammad Faiz]

Signed-off-by: Muhammad Faiz 
---
 libavdevice/alldevices.c | 13 ++---
 libavdevice/avdevice.h   |  1 -
 2 files changed, 10 insertions(+), 4 deletions(-)

diff --git a/libavdevice/alldevices.c b/libavdevice/alldevices.c
index a761be4..cc8b8ce 100644
--- a/libavdevice/alldevices.c
+++ b/libavdevice/alldevices.c
@@ -18,6 +18,8 @@
  * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA
  */
 
+#include 
+
 #include "config.h"
 #include "avdevice.h"
 
@@ -39,11 +41,14 @@
 
 void avdevice_register_all(void)
 {
-static int initialized;
+static atomic_int initialized;
+static atomic_int ready;
 
-if (initialized)
+if (atomic_exchange_explicit(, 1, memory_order_relaxed)) {
+while (!atomic_load_explicit(, memory_order_relaxed))
+;
 return;
-initialized = 1;
+}
 
 /* devices */
 REGISTER_INOUTDEV(ALSA, alsa);
@@ -75,4 +80,6 @@ void avdevice_register_all(void)
 /* external libraries */
 REGISTER_INDEV   (LIBCDIO,  libcdio);
 REGISTER_INDEV   (LIBDC1394,libdc1394);
+
+atomic_store_explicit(, 1, memory_order_relaxed);
 }
diff --git a/libavdevice/avdevice.h b/libavdevice/avdevice.h
index 6153f2c..84f374a 100644
--- a/libavdevice/avdevice.h
+++ b/libavdevice/avdevice.h
@@ -67,7 +67,6 @@ const char *avdevice_license(void);
 
 /**
  * Initialize libavdevice and register all the input and output devices.
- * @warning This function is not thread safe.
  */
 void avdevice_register_all(void);
 
-- 
2.9.3

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

Re: [FFmpeg-devel] [PATCH 2/4] ffmpeg: don't use resample_lavr_opts

[Michael Niedermayer]

On Mon, Mar 06, 2017 at 02:46:49AM +, Rostislav Pehlivanov wrote:
> That pointer isn't used by absolutely anything.
> 
> Signed-off-by: Rostislav Pehlivanov 
> ---
>  ffmpeg_filter.c | 1 -
>  1 file changed, 1 deletion(-)

LGTM

thx

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

Many that live deserve death. And some that die deserve life. Can you give
it to them? Then do not be too eager to deal out death in judgement. For
even the very wise cannot see all ends. -- Gandalf


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/exr

[Paul B Mahol]

On 3/6/17, Dzung Hoang  wrote:
> The EXR decoder cannot handle the image files included in NVidia's HDR SDK.
> After debugging, I found that the line offset table in the image files
> contained 0's. Other EXR decoders, including the official OpenEXR decoder,
> can detect and reconstruct missing line offset tables, so I added some code
> to do so.
> I filed a trac ticket for this issue here:
> https://trac.ffmpeg.org/ticket/6220.
>

Do you have files with this issue?
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH] avcodec/exr

[Dzung Hoang]

The EXR decoder cannot handle the image files included in NVidia's HDR SDK. 
After debugging, I found that the line offset table in the image files 
contained 0's. Other EXR decoders, including the official OpenEXR decoder, can 
detect and reconstruct missing line offset tables, so I added some code to do 
so.
I filed a trac ticket for this issue here: https://trac.ffmpeg.org/ticket/6220.


The patch is below.
Regards,Dzung Hoang


diff --git a/libavcodec/exr.c b/libavcodec/exr.c

index 034920f..de48e76 100644

--- a/libavcodec/exr.c

+++ b/libavcodec/exr.c

@@ -1726,6 +1726,24 @@ static intdecode_frame(AVCodecContext *avctx, void *data,

if(bytestream2_get_bytes_left(>gb) < nb_blocks * 8)

 returnAVERROR_INVALIDDATA;


 
+    // check offset table

+    if (bytestream2_peek_le64(>gb)== 0)

+    {

+    uint64_t *table= (uint64_t *)s->gb.buffer;

+    uint8_t *head =avpkt->data;

+    uint8_t *marker= head + bytestream2_tell(>gb) + nb_blocks * 8;

+    uint64_t offset;

+

+   av_log(s->avctx, AV_LOG_DEBUG, "recreating invalid offsettable\n");

+

+    for (y = 0; y< nb_blocks; y++)

+    {

+   offset = marker - head;

+   table[y] = offset;

+   marker += ((uint32_t *)marker)[1] + 8;

+    }

+    }

+

 // save pointer we are going to usein decode_block

s->buf  = avpkt->data;

 s->buf_size = avpkt->size;


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

Re: [FFmpeg-devel] [PATCH 1/2] (was Re: deduplicated [PATCH] Cinepak: speed up decoding several-fold...) formats.

[Karl Blomster]

On 2017-03-06 15:12, u-9...@aetey.se wrote:

Karl,

I wish to thank you for the effort to make the "opposite" parties
to better understand each other.

As you say, indeed the patch makes a move which looks in line with
ffmpeg's former traditions but which at least formally collides with
the currently percepted "best practices".

On Mon, Mar 06, 2017 at 12:47:26PM +0100, Karl Blomster wrote:

think the original patch made this seem particularly unpalatable since it
added a whole new "quick and dirty" colorspace conversion to YUV with
hardcoded constants (there are several different YUV variants with slightly
different constants), with a intended-as-helpful link to the Wikipedia page

I am pretty sure the definition of yuv420p in ffmpeg and the constants
agree to each other. Yes I am aware of the mess around the variety of
YUVs, that's why I referred to the source of the numbers. (IIRC they
come actually from Microsoft but I felt Wikipedia looked more neutral)
I'm honestly not sure what you mean here. The most common flavor of YUV (or more 
strictly speaking YCbCr), which is the one that you seem to have taken the 
numeric approximation of color primaries from - informally "Rec. 601", from its 
ITU recommendation number - has its roots in analog color television and I 
believe it was standardized back in the early 1980's, long before digital video 
was practically usable in consumer applications. ffmpeg naturally supports 
several other well established variants as well, such as ITU rec. 709 (first 
standardized in 1990 I believe, originally for use in likewise analog HDTV) and 
ITU rec. 2020 (a recent invention intended for 4k and other such things). In 
practice someone decoding from cinepak's storage format (which is similar to 
ycgco in spirit but not the same as conventional ycgco, as far as I can tell) to 
yuv is probably unlikely to want anything other than rec. 601 primaries, but you 
can't know that. Standards conversion of digital video can be very complex if 
you want to do it right, and as CPU's have gotten faster there has been more 
emphasis in general in digital video on correctness and less on just getting it 
to work, which is why standards conversion these days tends to be left to 
specialized libraries. I understand that in your case you simply want it done 
fast and don't really worry too much about correctness, and while that's fine 
and a legitimate use case (if unusual, in this day and age), it may not be what 
other users want, and more importantly it's a principle of least astonishment 
violation.


Regardless, it is now gone so there's no use in dwelling on it further - just 
trying to clarify what's going on, here.



Do you believe that libraries are not supposed to react on environment
variables? The most ubiquitous system one (libc) does by design.

Ffmpeg itself contains over twenty getenv() in the libav* libraries and
also via ffplay depends on SDL which for very natural reasons (similar
to my motivation with Cinepak) relies on environment variables.
Nor is there any apparent reasonable way to "get rid" of those getenv()s.
I would say that as usual when determining what is "right" in software 
architecture, the answer is "it depends". As far as I am aware, most of the 
things libav* touches environment variables for is related to interactions with 
things external to ffmpeg, such as the network (HTTP_PROXY), the terminal, the 
locations of certain types of plugins, etc. Modifying internal behavior based on 
environment variables is ugly in my opinion, and I can't think of any other case 
in ffmpeg where this is done. In general, if you want to interact with library 
functionality, do it through the API. In this case there's even a mechanism in 
place explicitly for this purpose (negotiating output pixelformat via the 
get_format callback), although I'll note that the ordinary use case for that is 
quite different from what you want to do here.


As far as SDL goes, I'll just note that the documentation states that "[u]sing 
these variables isn't recommended and the names and presence of these variables 
aren't guaranteed from one release to the next." They seem intended for 
debugging only.



ffmpeg
is a generalist library that tries to support a broad range of use cases on
a wide range of platforms, but that also by necessity means it lends itself
less well to extremely specific use cases like this one, where you're
prepared to buy decoding performance at any cost.

The cost in the code is in fact not that "big", about 68 LOC per output
pixel format, in the latest revision. Compared to the several times (!)
speed loss when going through swscale it looks to me like an
exceptionally low hanging fruit.
And here's one of the biggest issues in this debate and where I think you and 
wm4 et al keep talking past each other. The cost in lines of code is relatively 
unimportant. The cost in "number of different behaviors" is different. The Unix 
way is to do one thing and do it 

Re: [FFmpeg-devel] [PATCH] Added vmaf filter linking to netflix's vmaf repo. It may not necessarily be suitable for adding into mainline since it uses fork/pipe and exec for calling vmaf scripts. It i

[Michael Niedermayer]

On Sun, Mar 05, 2017 at 02:25:03AM +0530, Ashish Singh wrote:
> From: ashk43712 
> 
> Compiled Netflix's vmaf repo needs to be present inside libavfilter directory 
> for it to run successfully. 
> 
> ---
>  libavfilter/Makefile |   1 +
>  libavfilter/allfilters.c |   1 +
>  libavfilter/vf_vmaf.c| 319 
> +++
>  libavfilter/vmaf.h   |  33 +
>  4 files changed, 354 insertions(+)
>  create mode 100644 libavfilter/vf_vmaf.c
>  create mode 100644 libavfilter/vmaf.h

fails to build on mingw32

src/libavfilter/vf_vmaf.c:33:22: fatal error: sys/wait.h: No such file or 
directory
compilation terminated.
make: *** [libavfilter/vf_vmaf.o] Error 1
make: *** Waiting for unfinished jobs

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

Frequently ignored answer#1 FFmpeg bugs should be sent to our bugtracker. User
questions about the command line tools should be sent to the ffmpeg-user ML.
And questions about how to use libav* should be sent to the libav-user ML.


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

Re: [FFmpeg-devel] [PATCH] Clean up support for openjpeg encoder

[Aaron Boxer]

One last change: numresolution default setting changed to 6, to match
OpenJPEG default.

On Mon, Mar 6, 2017 at 10:49 AM, Aaron Boxer  wrote:

> >>
>> >> This was vertically algined. Now its not any more.
>> >>
>> >
>> >
>> > How is this? Feels like doing ASCII artwork to format this.
>>
>> The irreversible thing is not used at all, its just blank option.
>>
>
> Yes, quite right. Here is an updated patch.
>
>
>
>
>
>> ___
>> ffmpeg-devel mailing list
>> ffmpeg-devel@ffmpeg.org
>> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>>
>
>


0001-1.-limit-to-single-layer-as-there-is-no-current-supp.patch
Description: Binary data
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] deduplicated [PATCH] Cinepak: speed up decoding several-fold, depending on the scenario, by supporting multiple output pixel formats.

[u-9iep]

On Mon, Mar 06, 2017 at 04:31:32PM +0100, wm4 wrote:
> On Mon, 6 Mar 2017 16:23:15 +0100
> u-9...@aetey.se wrote:
> 
> > Did the project (who?) ever make a general decision about Cinepak
> > or delegate to wm4 to represent the project's stance?
> > 
> > I question her/his tone, not the policy, but what is the latter
> > when not refracted through your, wm4's or someone else's interpretation?
> > 
> > The design decision you refer to I would love to read. What I have
> > seen on the ffmpeg.org did not say "decoders shall not produce multiple
> > pixel formats".
> 
> Before you get too obsessed with me, I have never represented anything,
> or intended to represent. I merely contributed my own opinion about
> these patches. I have not more powers than Paul Mahol or Ronald Bultje
> (if anything, I have less powers than them).

It is nice of you to say this. Thanks for the clarification.

Regards,
Rune

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

Re: [FFmpeg-devel] [PATCH] Clean up support for openjpeg encoder

[Aaron Boxer]

>
> >>
> >> This was vertically algined. Now its not any more.
> >>
> >
> >
> > How is this? Feels like doing ASCII artwork to format this.
>
> The irreversible thing is not used at all, its just blank option.
>

Yes, quite right. Here is an updated patch.





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


0001-1.-limit-to-single-layer-as-there-is-no-current-supp.patch
Description: Binary data
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] Clean up support for openjpeg encoder

[Paul B Mahol]

On 3/6/17, Aaron Boxer  wrote:
> On Mon, Mar 6, 2017 at 10:04 AM, Paul B Mahol  wrote:
>
>> On 3/6/17, Aaron Boxer  wrote:
>> > I limited encoder to single quality layer, since there is currently no
>> way
>> > of specifying distortion for multiple layers. If there is any interest
>> > in
>> > this,
>> > I can add support. Someone just needs to tell me how to create an
>> > AVOption which takes a comma separated list of doubles.
>> >
>> > Cheers,
>> > Aaron
>> >
>>
>> This was vertically algined. Now its not any more.
>>
>
>
> How is this? Feels like doing ASCII artwork to format this.

The irreversible thing is not used at all, its just blank option.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] deduplicated [PATCH] Cinepak: speed up decoding several-fold, depending on the scenario, by supporting multiple output pixel formats.

[Ronald S. Bultje]

Hi,

On Mon, Mar 6, 2017 at 9:52 AM,  wrote:

> I am sorry for misrepresentation of the statements of wm4!
>

No problem.

Now Ronald where were you with your policing
> when the person in question (wm4) repeatedly violated CoC?
>
> I point out that your behaviour of selective punishment
> is most probably not conscious but it is a fact.


I will deal with people privately on IRC where I can. But thank you for
pointing it out.

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

Re: [FFmpeg-devel] [PATCH] avcodec/proresdec2: Do not discard frames with bad slices

[Michael Niedermayer]

On Sat, Mar 04, 2017 at 03:59:50AM +0100, Marton Balint wrote:
> 
> On Sat, 4 Mar 2017, Michael Niedermayer wrote:
> 
> >The code previously completely discarded frames that had any error in a slice
> 
> Could you set either AVFrame->flags to AV_FRAME_FLAG_CORRUPT or
> AVFrame->decode_error_flags to FF_DECODE_ERROR_INVALID_BITSTREAM in
> case of error on any of the slices?

done, applied

thx

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

If you drop bombs on a foreign country and kill a hundred thousand
innocent people, expect your government to call the consequence
"unprovoked inhuman terrorist attacks" and use it to justify dropping
more bombs and killing more people. The technology changed, the idea is old.


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

Re: [FFmpeg-devel] [PATCH] Clean up support for openjpeg encoder

[Aaron Boxer]

On Mon, Mar 6, 2017 at 10:04 AM, Paul B Mahol  wrote:

> On 3/6/17, Aaron Boxer  wrote:
> > I limited encoder to single quality layer, since there is currently no
> way
> > of specifying distortion for multiple layers. If there is any interest in
> > this,
> > I can add support. Someone just needs to tell me how to create an
> > AVOption which takes a comma separated list of doubles.
> >
> > Cheers,
> > Aaron
> >
>
> This was vertically algined. Now its not any more.
>


How is this? Feels like doing ASCII artwork to format this.





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


0001-1.-limit-to-single-layer-as-there-is-no-current-supp.patch
Description: Binary data
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] deduplicated [PATCH] Cinepak: speed up decoding several-fold, depending on the scenario, by supporting multiple output pixel formats.

[wm4]

On Mon, 6 Mar 2017 16:23:15 +0100
u-9...@aetey.se wrote:

> Did the project (who?) ever make a general decision about Cinepak
> or delegate to wm4 to represent the project's stance?
> 
> I question her/his tone, not the policy, but what is the latter
> when not refracted through your, wm4's or someone else's interpretation?
> 
> The design decision you refer to I would love to read. What I have
> seen on the ffmpeg.org did not say "decoders shall not produce multiple
> pixel formats".

Before you get too obsessed with me, I have never represented anything,
or intended to represent. I merely contributed my own opinion about
these patches. I have not more powers than Paul Mahol or Ronald Bultje
(if anything, I have less powers than them).
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] deduplicated [PATCH] Cinepak: speed up decoding several-fold, depending on the scenario, by supporting multiple output pixel formats.

[u-9iep]

On Mon, Mar 06, 2017 at 08:19:06AM -0500, Ronald S. Bultje wrote:
> On Mon, Mar 6, 2017 at 7:08 AM,  wrote:
> 
> > It is clear that you personally do not want the Cinepak decoder to be able
> > to output multiple pixel formats, for unspecified reasons ("by choice").
> >
> > You make it look like it is your discretion who decides whether something
> > is deemed to be good or not for FFmpeg. I do not believe this.

> It is a general project design decision.

Did the project (who?) ever make a general decision about Cinepak
or delegate to wm4 to represent the project's stance?

I question her/his tone, not the policy, but what is the latter
when not refracted through your, wm4's or someone else's interpretation?

The design decision you refer to I would love to read. What I have
seen on the ffmpeg.org did not say "decoders shall not produce multiple
pixel formats".

> If you want to change that, fine, propose it and let's discuss that on its

I am really interested to know what is "that" you refer to.

> own merit. But right now this is how the project works. You can't change
> that without changing official project policy.
> 
> I'm fundamentally against it, and as such I'm against the patch. I
> understand why you want it, but I don't think that's sufficient reason.

Thanks for stating your position as you do, constructively and coherently.

Regards,
Rune

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

Re: [FFmpeg-devel] [PATCH] avcodec/movtextdec: Call mov_text_cleanup() on close

[Michael Niedermayer]

On Sat, Mar 04, 2017 at 08:58:48PM +0100, Michael Niedermayer wrote:
> Fixes memleak
> Fixes: 548/clusterfuzz-testcase-5511470875934720
> 
> Found-by: continuous fuzzing process 
> https://github.com/google/oss-fuzz/tree/master/targets/ffmpeg
> Signed-off-by: Michael Niedermayer 
> ---
>  libavcodec/movtextdec.c | 1 +
>  1 file changed, 1 insertion(+)

applied

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

If you fake or manipulate statistics in a paper in physics you will never
get a job again.
If you fake or manipulate statistics in a paper in medicin you will get
a job for life at the pharma industry.


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

Re: [FFmpeg-devel] [PATCH] Clean up support for openjpeg encoder

[Paul B Mahol]

On 3/6/17, Aaron Boxer  wrote:
> I limited encoder to single quality layer, since there is currently no way
> of specifying distortion for multiple layers. If there is any interest in
> this,
> I can add support. Someone just needs to tell me how to create an
> AVOption which takes a comma separated list of doubles.
>
> Cheers,
> Aaron
>

This was vertically algined. Now its not any more.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH] Fix off-by-few crasher in ff_h2645_extract_rbsp function

[Michał Krasowski]

It seems that the loop tried to access the memory regions
beyond allocation, what caused crashes in not-so-rare cases, when
the memory read did not belong to current process.

This change is fixing the out-of-bounds read problem.
Compiling this function with -fsanitize=address and running doesn't
result in sanitizer warning as before.
---
 libavcodec/h2645_parse.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/libavcodec/h2645_parse.c b/libavcodec/h2645_parse.c
index c3961a5e90..ccb65eabfe 100644
--- a/libavcodec/h2645_parse.c
+++ b/libavcodec/h2645_parse.c
@@ -52,7 +52,7 @@ int ff_h2645_extract_rbsp(const uint8_t *src, int length,
 while (src[i])  \
 i++
 #if HAVE_FAST_64BIT
-for (i = 0; i + 1 < length; i += 9) {
+for (i = 0; i + 8 < length; i += 9) {
 if (!((~AV_RN64A(src + i) &
(AV_RN64A(src + i) - 0x0100010001000101ULL)) &
   0x8000800080008080ULL))
@@ -62,7 +62,7 @@ int ff_h2645_extract_rbsp(const uint8_t *src, int length,
 i -= 7;
 }
 #else
-for (i = 0; i + 1 < length; i += 5) {
+for (i = 0; i + 4 < length; i += 5) {
 if (!((~AV_RN32A(src + i) &
(AV_RN32A(src + i) - 0x01000101U)) &
   0x80008080U))
-- 
2.11.0

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

Re: [FFmpeg-devel] deduplicated [PATCH] Cinepak: speed up decoding several-fold, depending on the scenario, by supporting multiple output pixel formats.

[u-9iep]

On Mon, Mar 06, 2017 at 08:19:06AM -0500, Ronald S. Bultje wrote:
> Hi,
> 
> On Mon, Mar 6, 2017 at 7:08 AM,  wrote:
> 
> > You did not have to pay attention to the patch, given your limited
> > understanding of the matter
> 
> 
> And this is a CoC [1] violation, please don't do that again.

Actually what I wrote is:

> > You did not have to pay attention to the patch, given your limited
> > understanding of the matter (which _you_ stated repeatedly) 

I am sorry for saying this.

Pointing to one's behaviour is correct, presenting it as one's inherent
quality is not. I did wrong.

Indeed that person did not state her/his limited understanding nor
did this repeatedly. What was repeated was erroneous technical
comments about which "native" pixel format Cinepak has.

The formulation about understanding I meant to refer to was that of wm4:

  > I don't know what you're thinking, but that's just wrong.

It looks bizarre to me to judge without knowing
but this was _not_ a confession of a "limited understanding of the matter".

I am sorry for misrepresentation of the statements of wm4!

Now Ronald where were you with your policing
when the person in question (wm4) repeatedly violated CoC?

I point out that your behaviour of selective punishment
is most probably not conscious but it is a fact.

Regards,
Rune

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

Re: [FFmpeg-devel] lavc/aarch64: add simple idct neon functions

[Matthieu Bouron]

On Thu, Feb 23, 2017 at 04:59:16PM +0100, Matthieu Bouron wrote:
> Hello,
> 
> The following patchset add the ff_simple_idct function neon functions for the
> aarch64 platform. It's ported from armv7 simple_idct_neon with some 
> improvements:
>  * the source idct blocks are now loaded once and kept in v24-v31
>  * the source idct blocks are no longer overriden in idct_col4_top
>  * the destination is now written in one pass at the end of
>ff_simple_idct{,_put,_add}_neon
> 
> It is bitexact with the armv7 neon implementation.
> 
> Here are some results (reported by {START,STOP}_TIMER) on an Odroid-C2 (Cortex
> A53):
> 
> Functions IDCT: simple   IDCT: simpleneon
> ff_simple_idct_put 9795 units3170 units
> ff_simple_idct_add10227 units3302 units
> 

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

[FFmpeg-devel] [PATCH] Clean up support for openjpeg encoder

[Aaron Boxer]

I limited encoder to single quality layer, since there is currently no way
of specifying distortion for multiple layers. If there is any interest in
this,
I can add support. Someone just needs to tell me how to create an
AVOption which takes a comma separated list of doubles.

Cheers,
Aaron


0001-1.-limit-to-single-layer-as-there-is-no-current-supp.patch
Description: Binary data
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 1/2] (was Re: deduplicated [PATCH] Cinepak: speed up decoding several-fold...) formats.

[u-9iep]

Karl,

I wish to thank you for the effort to make the "opposite" parties
to better understand each other.

As you say, indeed the patch makes a move which looks in line with
ffmpeg's former traditions but which at least formally collides with
the currently percepted "best practices".

On Mon, Mar 06, 2017 at 12:47:26PM +0100, Karl Blomster wrote:
> think the original patch made this seem particularly unpalatable since it
> added a whole new "quick and dirty" colorspace conversion to YUV with
> hardcoded constants (there are several different YUV variants with slightly
> different constants), with a intended-as-helpful link to the Wikipedia page

I am pretty sure the definition of yuv420p in ffmpeg and the constants
agree to each other. Yes I am aware of the mess around the variety of
YUVs, that's why I referred to the source of the numbers. (IIRC they
come actually from Microsoft but I felt Wikipedia looked more neutral)

> I really don't think that link was appreciated at all.

Interesting that nobody but you could articulate what was wrong with
it. Anyway, this detail is now a matter of the past. I never needed
it in practice myself (hardware scalers via yuv420p were slower than
Cinepak-on-the-CPU), implemented it just for generality.

Undesired - removed.

> With all of this in mind, there would need to be an extraordinarily big
> practical benefit for a large number of users for this patch to be percieved
> as a "necessary evil" (and just to be perfectly clear here, I'm not trying

My problem with the commenters is that they take their percepted best
practice rules as something which is not to be exposed to scrutiny.

An attempt to say that the rules are not necessary applicable or useful
is not heard at all or otherwise amounts to heresy.

> correspondence, my impression gathered from several different hints in
> different emails is that you're trying to play back video on some
> extraordinarily slow system with no GPU, where the only decoder you could

Correct, no GPU. (GPU costs among others a lot more lines of code to
take care of than Cinepak patches :)

> cannot modify the playback software, necessitating the rather remarkable
> hack where a ubiquitous system library modifies its behavior based on an

Do you believe that libraries are not supposed to react on environment
variables? The most ubiquitous system one (libc) does by design.

Ffmpeg itself contains over twenty getenv() in the libav* libraries and
also via ffplay depends on SDL which for very natural reasons (similar
to my motivation with Cinepak) relies on environment variables.
Nor is there any apparent reasonable way to "get rid" of those getenv()s.

> ffmpeg
> is a generalist library that tries to support a broad range of use cases on
> a wide range of platforms, but that also by necessity means it lends itself
> less well to extremely specific use cases like this one, where you're
> prepared to buy decoding performance at any cost.

The cost in the code is in fact not that "big", about 68 LOC per output
pixel format, in the latest revision. Compared to the several times (!)
speed loss when going through swscale it looks to me like an
exceptionally low hanging fruit.

> In an earlier email you pointed out that historically, very few code changes
> have been needed to keep the cinepak decoder up to date with the rest of
> ffmpeg, highlighting a view of what maintainability is that I believe is
> substantially different from that of other participants in this debate.

Nobody cared to define their view on what maintainability means
even when I explicitly asked how to measure it.

> However, what it does imply is that the maintenance burden of having your
> own branch that suits your use case, with all the oddball solutions you
> could imagine, would not seem to be overly heavy.

That's what I was doing and apparently will have to, given that the
vitally useful things like out-of-band control are percepted as "evil" here.

It still feels inadequate to keep this functionality for myself, or
otherwise to maintain the patches so that they would suit someone else
(I made this now for the submission but would not do continuously).

> Also, in another of your earlier emails you also rather passive-aggressively
> mentioned that not accepting the patch might be a "problem for the project".
> I really don't think anyone around here sees it that way, precisely because
> interest in cinepak in 2017 is not, shall we say, at an all time high.

Indeed it is not the speed of Cinepak, nor the speed of any module
which is a problem, but I would say the atmosphere in the project.

> Best regards
> Karl Blomster

Thanks again.

Rune

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

Re: [FFmpeg-devel] deduplicated [PATCH] Cinepak: speed up decoding several-fold, depending on the scenario, by supporting multiple output pixel formats.

[Ronald S. Bultje]

Hi,

On Mon, Mar 6, 2017 at 7:08 AM,  wrote:

> It is clear that you personally do not want the Cinepak decoder to be able
> to output multiple pixel formats, for unspecified reasons ("by choice").
>
> You make it look like it is your discretion who decides whether something
> is deemed to be good or not for FFmpeg. I do not believe this.
>

It is a general project design decision.

If you want to change that, fine, propose it and let's discuss that on its
own merit. But right now this is how the project works. You can't change
that without changing official project policy.

I'm fundamentally against it, and as such I'm against the patch. I
understand why you want it, but I don't think that's sufficient reason.


> You did not have to pay attention to the patch, given your limited
> understanding of the matter


And this is a CoC [1] violation, please don't do that again.

Ronald

[1] https://ffmpeg.org/developer.html#Code-of-conduct
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] lswr: remove support for libsoxr resampling

[Michael Niedermayer]

On Mon, Mar 06, 2017 at 03:19:48AM +, Rostislav Pehlivanov wrote:
> The soxr resampler is slower and worse than the swr resampler,
> hence drop the former.
> 
> Signed-off-by: Rostislav Pehlivanov 
> ---
>  Changelog   |   1 +
>  MAINTAINERS |   1 -
>  configure   |   5 +-
>  doc/resampler.texi  |  53 ---
>  libswresample/Makefile  |   1 -
>  libswresample/options.c |   7 --
>  libswresample/resample.c|   2 +-
>  libswresample/soxr_resample.c   | 130 
> 
>  libswresample/swresample.c  |  18 +
>  libswresample/swresample.h  |   7 --
>  libswresample/swresample_internal.h |   9 +--
>  11 files changed, 21 insertions(+), 213 deletions(-)
>  delete mode 100644 libswresample/soxr_resample.c

the way soxr resamples is different from how swr implements it, that
could result in different advantages and disadvantages.
I would expect "which is better" to depend on what is meassured

i also think this should be CC-ed to rob, thus adding him to CC

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

Those who would give up essential Liberty, to purchase a little
temporary Safety, deserve neither Liberty nor Safety -- Benjamin Franklin


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

Re: [FFmpeg-devel] deduplicated [PATCH] Cinepak: speed up decoding several-fold, depending on the scenario, by supporting multiple output pixel formats.

[u-9iep]

To everyone:

I am really sorry for having to react to this kind of irrational
arguments. OTOH keeping silence could be interpreted as accepting them.

As far as my common sense goes, I can not count these as "pending comments".

TL;DR:
 trying to reason,
 given the arbitrary statements and careless behaviour of the opponent

On Mon, Mar 06, 2017 at 10:31:42AM +0100, wm4 wrote:
> I think we've repeatedly made clear that:
> - we don't really want the decoder to output multiple pixfmts by choice

It is clear that you personally do not want the Cinepak decoder to be able
to output multiple pixel formats, for unspecified reasons ("by choice").

You make it look like it is your discretion who decides whether something
is deemed to be good or not for FFmpeg. I do not believe this.

> - but if it's limited to a very small number of formats (say, 2) it
>   might be ok

You are again referring to nothing but your discretion.

Anyway, if you take your time to look at the current version of the patch,
it _happens_ to do exactly this.

So this point is moot.

> - but ideally the decoder should output the "native" pixfmt/colorspace
>   of the codec, which apparently is YCgCo (which would also require
>   libswscale modifications)

What makes it "ideal", by which criteria? Be technical please.

(BTW "which apparently is" is a wrong assumption.
You still did not use the references I offered you for some background
information on the matter. Please learn, before posting next time.)

> - we're not even interested in a faster cinepak decoder, because we see
>   no need for it (even you haven't demonstrated any need for it - I'm
>   pretty sure everyone would be all over a fast intermediate codec, but
>   people don't use cinepak for that)

Are you saying no need for everyone?

Nor have they ever tasted a 3 times faster decoder but you already know
they will not like it?

Sorry, seriously I have no reason to assume that you have prerequisites
to know for everyone and especially in advance.

You are talking about what is inside the horizon of yourself.

> - trying to trick us into applying this patch by playing policy lawyer
>   won't work

You make it again sound like you decide for the project.
Frankly, such behaviour makes the project look bad.

Also you are accusing me of "tricking" and "playing".

Please be specific about what I am doing wrong
or apologize otherwise.

While at it, I am still expecting your apology
for the use of abusive language when you were commenting
on my proposal last time.

> - whether or not having these multiple code paths would be so horrible
>   is not even the main question - by now we're just annoyed by this
>   topic and how much attention it seems to drain, so we'd rather ignore
>   this (don't blame us - people tend to ignore unimportant things to
>   get important work done, and not applying your patches seems to be
>   the safer option)

You did not have to pay attention to the patch, given your limited
understanding of the matter (which _you_ stated repeatedly) and the
limited capacity to participate, which you demonstrated by relying on
wrong assumptions and neglecting to correct your mistakes in this discussion.

> - again, nobody understands your needs, and some we find extremely

You are assuming that everyone has the same level of understanding
as you do. This is not necessarily true.

>   absurd and out of place, like using getenv() in a decoder (we'd
>   probably suggest a better alternative if we did, maybe)

Regrettably, the proposed alternatives were either to put the
corresponding functionality into every application or to avoid ffmpeg
and start a separate project. Neither of those alternatives would be
practically useful. Never mind, this is not part of the current patch.

Thanks for reading this long!

Regards,
Rune

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

Re: [FFmpeg-devel] OT: Re: deduplicated [PATCH] Cinepak: speed up decoding several-fold, depending on the scenario, by supporting multiple output pixel formats.

[Paul B Mahol]

On 3/6/17, u-9...@aetey.se  wrote:
> On Mon, Mar 06, 2017 at 10:19:33AM +0100, Paul B Mahol wrote:
>> On 3/6/17, u-9...@aetey.se  wrote:
>> > I do have respect for your work and competence.
>> > Please do the same to others.
>>
>> What is your Work and Competence in FFmpeg?
>
> This is offtopic and looks like ad hominem
> "a logical fallacy in which an argument is rebutted by attacking the
> character, motive, or other attribute of the person making the argument"
> (Wikipedia)
>
> It is more of a fallacy because you make it look like the "competence
> in FFmpeg" (whatever you mean with this) is the only competence kind to
> be respected or/and to be relevant while doing work for FFmpeg.
>
> As for your curiosity, feel free to do the research.
> The data is public.
>
> Rune

Your mail doesn't give me anything useful when googling.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH 1/2] (was Re: deduplicated [PATCH] Cinepak: speed up decoding several-fold...) formats.

[Karl Blomster]

Hi,
It is regrettable that the positions are so entrenched here, but I agree with 
the majority opinion that pushing this really isn't a good idea, nor do I 
understand the reasons it's even desirable in the first place. The core issue 
here, I think, is fundamentally different views of software architectural issues 
as well as an almost as fundamentally different understanding of what 
"maintainability" means. I will make an honest attempt at laying out the 
situation _as I see it_ and while I don't think it will actually convince 
anyone, perhaps it will clarify a few points, make the situation slightly 
clearer and/or prevent further misunderstandings. I am not a ffmpeg developer 
and do not speak for anyone else and definitely not for the project, but I've 
been following the project for a long time and I believe I have come to at least 
some understanding of its principles.
To start off with an obvious fact, ffmpeg is a huge project, and a relatively 
old one. It has quite a bit of legacy code that, while it works, does things in 
ways that are not viewed with favor today, nor fit in with the way the current 
developers think. My general impression of the project in the last few years is 
that the consensus has been to attempt to steer the project to align with the 
principle of least astonishment: less "clever" solutions, more separation of 
concerns, more consistency in code and in behavior. This patch is almost 
directly contrary to that principle, and I think that's where one of the major 
rubs are. That's not to say solutions that are seen as "ugly" cannot be 
accepted, but it has to be weighed carefully against the estimated usefulness of 
the change.
In this particular case, the cinepak decoder is already "doing it wrong", so to 
speak (of course it's not actually bugged, but hopefully you see what I mean) - 
it's outputting a colorspace that isn't its "natural" output colorspace. Adding 
more options may seem reasonable since it's already doing it, but it's in the 
opposite direction of where the project is heading. I think the original patch 
made this seem particularly unpalatable since it added a whole new "quick and 
dirty" colorspace conversion to YUV with hardcoded constants (there are several 
different YUV variants with slightly different constants), with a 
intended-as-helpful link to the Wikipedia page on YUV in an explanatory comment. 
Considering what project the patch was contributed to, I really don't think that 
link was appreciated at all.
With all of this in mind, there would need to be an extraordinarily big 
practical benefit for a large number of users for this patch to be percieved as 
a "necessary evil" (and just to be perfectly clear here, I'm not trying to say 
that there is any evil intent anywhere - it's a figure of speech). I'm sure that 
for _you_ there is such a benefit, but I don't think anyone else has even fully 
understood your use case. From your earlier correspondence, my impression 
gathered from several different hints in different emails is that you're trying 
to play back video on some extraordinarily slow system with no GPU, where the 
only decoder you could find that was fast enough (not just in terms of CPU 
cycles but also in terms of memory bandwidth) was cinepak with 16-bit RGB 
output. Furthermore, you cannot modify the playback software, necessitating the 
rather remarkable hack where a ubiquitous system library modifies its behavior 
based on an environment variable. You've done away with this modification now, 
but I think having that in there at the start kinda poisoned the well from the 
beginning. Regardless, while I don't doubt that you have a legitimate use case 
that is important to you, I really cannot see the scenario you seem to be 
painting as anything other than an extremely specific edge case. ffmpeg is a 
generalist library that tries to support a broad range of use cases on a wide 
range of platforms, but that also by necessity means it lends itself less well 
to extremely specific use cases like this one, where you're prepared to buy 
decoding performance at any cost.


In an earlier email you pointed out that historically, very few code changes 
have been needed to keep the cinepak decoder up to date with the rest of ffmpeg, 
highlighting a view of what maintainability is that I believe is substantially 
different from that of other participants in this debate. However, what it does 
imply is that the maintenance burden of having your own branch that suits your 
use case, with all the oddball solutions you could imagine, would not seem to be 
overly heavy.
Also, in another of your earlier emails you also rather passive-aggressively 
mentioned that not accepting the patch might be a "problem for the project". I 
really don't think anyone around here sees it that way, precisely because 
interest in cinepak in 2017 is not, shall we say, at an all time high.


Best regards
Karl Blomster

Re: [FFmpeg-devel] [PATCH] swresample/resample: use uniform normalization

[Muhammad Faiz]

On Fri, Mar 3, 2017 at 3:58 PM, Muhammad Faiz  wrote:
> On Wed, Mar 1, 2017 at 10:24 PM, Muhammad Faiz  wrote:
>> this gives better frequency response
>>
>> update swresample fate and other fates
>> that depend on resampling
>>
>> Signed-off-by: Muhammad Faiz 
>> ---
>>  libswresample/resample.c |  14 +--
>>  tests/fate/libswresample.mak | 276 
>> +--
>>  tests/ref/acodec/roqaudio|   2 +-
>>  tests/ref/acodec/s302m   |   6 +-
>>  tests/ref/lavf/dv_fmt|   8 +-
>>  tests/ref/lavf/gxf   |   8 +-
>>  tests/ref/lavf/mxf   |  12 +-
>>  7 files changed, 163 insertions(+), 163 deletions(-)
>>
>
> Test case, from 44100 to 705600 (16*44100)
> ffmpeg -filter_complex "aevalsrc='if(n-300,0,1)',
> aresample=osr=705600:filter_size=16" -f f32le - | ./freq-resp >
> freq-resp.txt
>
>
> gnuplot result attached

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

Re: [FFmpeg-devel] [PATCH v2 1/2] lavc: consider an error during decoder draining as EOF

[wm4]

On Thu,  2 Mar 2017 10:45:23 +0100
wm4  wrote:

> There is no reason that draining couldn't return an error or two. But
> some decoders don't handle this very well, and might always return an
> error. This can lead to API users getting into an infinite loop and
> burning CPU, because no progress is made and EOF is never returned.
> 
> In fact, ffmpeg.c contains a hack against such a case. It is removed
> with this patch. This particular error case seems to have been fixed
> since the hack was added, though.
> 
> This might lose frames if decoding returns errors during draining.
> ---
> Minor lavc bump missing.
> ---
>  libavcodec/utils.c | 6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)
> 
> diff --git a/libavcodec/utils.c b/libavcodec/utils.c
> index 1156e43079..db3adb18d4 100644
> --- a/libavcodec/utils.c
> +++ b/libavcodec/utils.c
> @@ -2807,12 +2807,12 @@ static int do_decode(AVCodecContext *avctx, AVPacket 
> *pkt)
>  if (ret == AVERROR(EAGAIN))
>  ret = pkt->size;
>  
> -if (ret < 0)
> -return ret;
> -
>  if (avctx->internal->draining && !got_frame)
>  avctx->internal->draining_done = 1;
>  
> +if (ret < 0)
> +return ret;
> +
>  if (ret >= pkt->size) {
>  av_packet_unref(avctx->internal->buffer_pkt);
>  } else {

Both patches pushed, with some changes to the commit message of the
first one. Also I just noticed that I forgot the minor lavc bump, but I
guess it's not too important anyway.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] OT: Re: deduplicated [PATCH] Cinepak: speed up decoding several-fold, depending on the scenario, by supporting multiple output pixel formats.

[u-9iep]

On Mon, Mar 06, 2017 at 10:19:33AM +0100, Paul B Mahol wrote:
> On 3/6/17, u-9...@aetey.se  wrote:
> > I do have respect for your work and competence.
> > Please do the same to others.
> 
> What is your Work and Competence in FFmpeg?

This is offtopic and looks like ad hominem
"a logical fallacy in which an argument is rebutted by attacking the
character, motive, or other attribute of the person making the argument"
(Wikipedia)

It is more of a fallacy because you make it look like the "competence
in FFmpeg" (whatever you mean with this) is the only competence kind to
be respected or/and to be relevant while doing work for FFmpeg.

As for your curiosity, feel free to do the research.
The data is public.

Rune

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

Re: [FFmpeg-devel] [PATCH] lavc/videotoolbox: set kCVPixelBufferIOSurfaceOpenGLTextureCompatibilityKey

[wm4]

On Fri, 3 Mar 2017 18:16:18 +0800
Wang Bin  wrote:

> From 011d03c4d2b6b138de539dcf5019169781ee7fb2 Mon Sep 17 00:00:00 2001
> From: wang-bin 
> Date: Fri, 3 Mar 2017 18:10:54 +0800
> Subject: [PATCH] avcodec/videotoolbox: set
>  kCVPixelBufferOpenGLESCompatibilityKey for iOS
> 
> kCVPixelBufferIOSurfaceOpenGLTextureCompatibilityKey is not available in
> iOS
> ---
>  libavcodec/videotoolbox.c | 5 +
>  1 file changed, 5 insertions(+)
> 
> diff --git a/libavcodec/videotoolbox.c b/libavcodec/videotoolbox.c
> index 824f2d8e68..9199b02055 100644
> --- a/libavcodec/videotoolbox.c
> +++ b/libavcodec/videotoolbox.c
> @@ -31,6 +31,7 @@
>  #include "bytestream.h"
>  #include "h264dec.h"
>  #include "mpegvideo.h"
> +#include 
> 
>  #ifndef kVTVideoDecoderSpecification_RequireHardwareAcceleratedVideoDecoder
>  #  define
> kVTVideoDecoderSpecification_RequireHardwareAcceleratedVideoDecoder
> CFSTR("RequireHardwareAcceleratedVideoDecoder")
> @@ -477,7 +478,11 @@ static CFDictionaryRef
> videotoolbox_buffer_attributes_create(int width,
>  CFDictionarySetValue(buffer_attributes,
> kCVPixelBufferIOSurfacePropertiesKey, io_surface_properties);
>  CFDictionarySetValue(buffer_attributes, kCVPixelBufferWidthKey, w);
>  CFDictionarySetValue(buffer_attributes, kCVPixelBufferHeightKey, h);
> +#if TARGET_OS_IPHONE
> +CFDictionarySetValue(buffer_attributes,
> kCVPixelBufferOpenGLESCompatibilityKey, kCFBooleanTrue);
> +#else
>  CFDictionarySetValue(buffer_attributes,
> kCVPixelBufferIOSurfaceOpenGLTextureCompatibilityKey, kCFBooleanTrue);
> +#endif
> 
>  CFRelease(io_surface_properties);
>  CFRelease(cv_pix_fmt);

Applied.

The patch was broken by auto-wrapping in your mail client. I managed to
fix it, but please use git send-email next time, or attach it as
attachment.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH v2] avcodec/h264, videotoolbox: fix crash after VT decoder fails

[wm4]

On Thu, 2 Mar 2017 09:58:28 -0800
Aman Gupta  wrote:

> On Thu, Mar 2, 2017 at 1:34 AM, wm4  wrote:
> 
> > On Tue, 21 Feb 2017 13:40:08 -0800
> > Aman Gupta  wrote:
> >  
> > > On Tue, Feb 21, 2017 at 1:04 PM, Ronald S. Bultje 
> > > wrote:
> > >  
> > > > Hi,
> > > >
> > > > On Tue, Feb 21, 2017 at 1:48 PM, Aman Gupta  wrote:
> > > >  
> > > >> diff --git a/libavcodec/h264dec.c b/libavcodec/h264dec.c
> > > >> index 41c0964392..a0ae632fed 100644
> > > >> --- a/libavcodec/h264dec.c
> > > >> +++ b/libavcodec/h264dec.c
> > > >> @@ -850,7 +850,12 @@ static int output_frame(H264Context *h, AVFrame
> > > >> *dst, H264Picture *srcp)
> > > >>  AVFrame *src = srcp->f;
> > > >>  const AVPixFmtDescriptor *desc = av_pix_fmt_desc_get(src->  
> > format);  
> > > >>  int i;
> > > >> -int ret = av_frame_ref(dst, src);
> > > >> +int ret;
> > > >> +
> > > >> +if (src->format == AV_PIX_FMT_VIDEOTOOLBOX && src->buf[0]->size  
> > == 1)  
> > > >> +return AVERROR_INVALIDDATA;
> > > >> +
> > > >> +ret = av_frame_ref(dst, src);
> > > >>  if (ret < 0)
> > > >>  return ret;  
> > > >
> > > >
> > > > This is a total hack :) Is there a way to hide this into VT-specific  
> > code  
> > > > outside h264*.[ch]?
> > > >  
> > >
> > > The way the VT hwaccel works is a total hack, as noted in my commit  
> > message.  
> > >
> > > AFAICT, given how the hwaccel APIs work, there's no way to do this  
> > outside  
> > > the h264 decoder. But I'm happy to try fixing this a different way if
> > > anyone has a suggestion.  
> >
> > So, should we push this?
> >  
> 
> I'm struggling to find a less hacky way to implement this, so my vote would
> be to move forward. Changing the error to AVERROR_EXTERNAL makes sense too.

I'll apply the patch in 24h then, with the error code changed.

It's a regrettable hack, but probably better than violating the API.
With the patch applied, it'll behave like normal hwaccels do, and I
suppose the internals can always be changed later. So I think there's a
good case for applying this.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH] avcodec: clarify some decoding/encoding API details

[wm4]

Make it clear that there is no timing-dependent behavior. In particular,
there is no state in which both input and output are denied, and where
you have to wait for a while yourself to make progress (apparently some
hardware decoders like to do this).

Avoid wording that makes references to time. It shouldn't be mistaken
for some kind of asynchronous API (like POSIX read() can return EAGAIN
if there is no new input yet). It's a state machine, so try to use
appropriate terms.
---
I hope it's actually an improvement, instead of making the wall of text
worse.

To be fair, I think using EAGAIN was Wrong anyway, but there was a
precedent in libavfilter.
---
 libavcodec/avcodec.h | 42 +-
 1 file changed, 33 insertions(+), 9 deletions(-)

diff --git a/libavcodec/avcodec.h b/libavcodec/avcodec.h
index 489a618cbb..f9f409d3c5 100644
--- a/libavcodec/avcodec.h
+++ b/libavcodec/avcodec.h
@@ -114,6 +114,12 @@
  * are filled. This situation is handled transparently if you follow the steps
  * outlined above.
  *
+ * In theory, sending input can result in EAGAIN - this should happen only if
+ * not all output was received. You can use this to structure alternative 
decode
+ * or encode loops other than the one suggested above. For example, you could
+ * try sending new input on each iteration, and try to receive ouput if that
+ * returns EAGAIN.
+ *
  * End of stream situations. These require "flushing" (aka draining) the codec,
  * as the codec might buffer multiple frames or packets internally for
  * performance or out of necessity (consider B-frames).
@@ -148,7 +154,8 @@
  *   Unlike with the old video decoding API, multiple frames might result from
  *   a packet. For audio, splitting the input packet into frames by partially
  *   decoding packets becomes transparent to the API user. You never need to
- *   feed an AVPacket to the API twice.
+ *   feed an AVPacket to the API twice (unless it is rejected with EAGAIN - 
then
+ *   no data was read from the packet).
  *   Additionally, sending a flush/draining packet is required only once.
  * - avcodec_encode_video2()/avcodec_encode_audio2():
  *   Use avcodec_send_frame() to feed input to the encoder, then use
@@ -161,7 +168,20 @@
  * and will result in arbitrary behavior.
  *
  * Some codecs might require using the new API; using the old API will return
- * an error when calling it.
+ * an error when calling it. All codecs support the new API.
+ *
+ * A codec is not allowed to return EAGAIN for both sending and receiving. This
+ * would be an invalid state, which could put the codec user into an endless
+ * loop. The API has no concept of time either: it cannot happen that trying to
+ * do avcodec_send_packet() results in EAGAIN, but a repeated call 1 second
+ * later accepts the packet (with no other receive/flush API calls involved).
+ * The API is a strict state machine, and the passage of time is not supposed
+ * to influence it. As long as it never results to both send/receive returning
+ * both EAGAIN at the same time at any point, and no "flip flopping" between 
the
+ * send/receive APIs is possible (e.g. the codec randomly deciding that it
+ * actually wants to consume a packet now instead of returning a frame, after 
it
+ * just has returned EAGAIN on an avcodec_send_packet() call), such behavior
+ * might still be deemed acceptable.
  * @}
  */
 
@@ -4339,8 +4359,10 @@ int avcodec_decode_subtitle2(AVCodecContext *avctx, 
AVSubtitle *sub,
  *  a flush packet.
  *
  * @return 0 on success, otherwise negative error code:
- *  AVERROR(EAGAIN):   input is not accepted right now - the packet must be
- * resent after trying to read output
+ *  AVERROR(EAGAIN):   input is not accepted in the current state - user
+ * must read output with avcodec_receive_frame() (once
+ * all ouput is read, the packet should be resent, and
+ * the call will not fail with EAGAIN).
  *  AVERROR_EOF:   the decoder has been flushed, and no new packets can
  * be sent to it (also returned if more than 1 flush
  * packet is sent)
@@ -4361,7 +4383,7 @@ int avcodec_send_packet(AVCodecContext *avctx, const 
AVPacket *avpkt);
  *
  * @return
  *  0: success, a frame was returned
- *  AVERROR(EAGAIN):   output is not available right now - user must try
+ *  AVERROR(EAGAIN):   output is not available in this state - user must 
try
  * to send new input
  *  AVERROR_EOF:   the decoder has been fully flushed, and there will 
be
  * no more output frames
@@ -4394,8 +4416,10 @@ int avcodec_receive_frame(AVCodecContext *avctx, AVFrame 
*frame);
  *  avctx->frame_size for all frames except the last.
  *  The final frame may be smaller than avctx->frame_size.
  * @return 0 

Re: [FFmpeg-devel] deduplicated [PATCH] Cinepak: speed up decoding several-fold, depending on the scenario, by supporting multiple output pixel formats.

[wm4]

On Mon, 6 Mar 2017 10:15:44 +0100
u-9...@aetey.se wrote:

> On Sun, Mar 05, 2017 at 06:20:34PM -0500, Ronald S. Bultje wrote:
> > Hi Rune,
> > 
> > On Sun, Mar 5, 2017 at 4:26 PM,  wrote:
> >   
> > > Ronald,
> > >
> > > On Sun, Mar 05, 2017 at 02:38:31PM -0500, Ronald S. Bultje wrote:  
> > > > Hi,
> > > >
> > > > On Sun, Mar 5, 2017 at 2:22 PM,  wrote:
> > > >  
> > > > > On Mon, Feb 13, 2017 at 02:41:40PM +0100, u-9...@aetey.se wrote:  
> > > > > > On Mon, Feb 13, 2017 at 02:19:45PM +0100, Michael Niedermayer 
> > > > > > wrote:  
> > > > > > > you may want to add yourself to MAINTAINERs (after talking with
> > > > > > > roberto, who i belive has less interrest in cinepak than you do
> > > > > > > nowadays)  
> > > > > >
> > > > > > Sounds ok for me. Roberto, what do you think (if you read this)?  
> > > > >
> > > > > The only address to him which I found (in an old commit) bounced,
> > > > > there was no reply here on the list either.
> > > > >
> > > > > Both can be a coincidence, but otherwise it looks like the change  
> > > should  
> > > > > be OK.  
> > > >
> > > >
> > > > No. This has been discussed repeatedly. Stop trying to push this 
> > > > through.  
> > >
> > > My maintainership (for the code which I have contributed to, you may be
> > > unaware about this fact) was not discussed otherwise than cited here.
> > >
> > > Please check what you are commenting,
> > > especially when you mean to sound like having a definite power  
> > 
> > 
> > The rule is that a patch cannot be committed while a developer has
> > outstanding comments. There's outstanding comments, including some from me.
> > You said "the change should be OK", and I'm simply saying "no" to that,
> > because it's not. The patch is not OK until review comments from other
> > developers have been addressed by the patch submitter.  
> 
> Thanks for the explanation Ronald,
> 
> 1. Apparently you did not aim at the maintainership question.
> 
>   It would be nice if you confirm this point,
>   to avoid further misunderstandings.
> 
> 2. Would you cite the outstanding comment or comments about the patches
>which you feel are valid and not addressed?
> 
>I kindly ask you check the latest iteration of the patch series
>where I tried to summarize all discussion points in the containing
>letter.
> 
> TL;DR: I do have respect for your work and competence.
>Please do the same to others. Even if we all too often meet people
>who lack in those areas, there are some exceptions.
> 
> To be fair your comments concerning the patches were among the most
> detailed and friendly, this is appreciated!
> 
> But even your well meant comments happened to miss the point, being based
> in unfounded assumptions. I answered and explained and there it stopped.
> 
> Frankly the only outstanding comments which I am aware of are of the kind
> "you the patch submitter do not understand why 'this' is better than
> 'that'".
> 
> The fact is that I _do_ understand why you believe that something is
> better or not. I just do not feel a belief is sufficient per se.
> 
> I invited you and others to look at _what_ makes something better
> or not and got literally no answers.
> 
> Besides of course
> "imagine if someone else will do something else,
> it would be terrible, thus you are leading us to hell" :)
> 
> or otherwise, citing literally:
> "we know this code, we know it can do this, don't tell us it's not
> possible" without specifying (and in fact misunderstanding) what
> "this" we were talking about: making the speedup usable with an
> unprepared application, which the overhelming majority of applications
> are. Regrettably, the present code is not prepared nor meant to be able to.
> The proposed code could, but this possiblity is now cut off,
> just to avoid contention.
> 
> As a third example, your comment
> "We [...] know it's unreasonable from a maintenance perspective".
> 
> The very presence of the cinepak decoder is a proof to the opposite
> because it worked this way (generating two different pixel formats
> inside the decoder) for years. Again, what "it's" we are talking about?
> The same "it" in your mind as in the patch?
> 
> I went so long as to quantify/estimate the expected extra maintenance
> burden while you did not even mention any tangible criteria.
> 
> This makes me doubt that you or others who commented have time to read
> the answers or are prepared to expect competence of your counterparts.
> Unfortunately this affects the quality of the judgement.
> 
> I do have respect for your work and competence.
> Please do the same to others.

I think we've repeatedly made clear that:

- we don't really want the decoder to output multiple pixfmts by choice
- but if it's limited to a very small number of formats (say, 2) it
  might be ok
- but ideally the decoder should output the "native" pixfmt/colorspace
  of the codec, which apparently is YCgCo (which would also require
  libswscale 

Re: [FFmpeg-devel] [PATCH] lswr: remove support for libsoxr resampling

[Paul B Mahol]

On 3/6/17, Rostislav Pehlivanov  wrote:
> The soxr resampler is slower and worse than the swr resampler,
> hence drop the former.

Why you think its worse? There are some popular tests with all
resampleres being tested and I can confirm that swr defaults are
hardly better than soxr defaults.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] deduplicated [PATCH] Cinepak: speed up decoding several-fold, depending on the scenario, by supporting multiple output pixel formats.

[Paul B Mahol]

On 3/6/17, u-9...@aetey.se  wrote:
> On Sun, Mar 05, 2017 at 06:20:34PM -0500, Ronald S. Bultje wrote:
>> Hi Rune,
>>
>> On Sun, Mar 5, 2017 at 4:26 PM,  wrote:
>>
>> > Ronald,
>> >
>> > On Sun, Mar 05, 2017 at 02:38:31PM -0500, Ronald S. Bultje wrote:
>> > > Hi,
>> > >
>> > > On Sun, Mar 5, 2017 at 2:22 PM,  wrote:
>> > >
>> > > > On Mon, Feb 13, 2017 at 02:41:40PM +0100, u-9...@aetey.se wrote:
>> > > > > On Mon, Feb 13, 2017 at 02:19:45PM +0100, Michael Niedermayer
>> > > > > wrote:
>> > > > > > you may want to add yourself to MAINTAINERs (after talking with
>> > > > > > roberto, who i belive has less interrest in cinepak than you do
>> > > > > > nowadays)
>> > > > >
>> > > > > Sounds ok for me. Roberto, what do you think (if you read this)?
>> > > >
>> > > > The only address to him which I found (in an old commit) bounced,
>> > > > there was no reply here on the list either.
>> > > >
>> > > > Both can be a coincidence, but otherwise it looks like the change
>> > should
>> > > > be OK.
>> > >
>> > >
>> > > No. This has been discussed repeatedly. Stop trying to push this
>> > > through.
>> >
>> > My maintainership (for the code which I have contributed to, you may be
>> > unaware about this fact) was not discussed otherwise than cited here.
>> >
>> > Please check what you are commenting,
>> > especially when you mean to sound like having a definite power
>>
>>
>> The rule is that a patch cannot be committed while a developer has
>> outstanding comments. There's outstanding comments, including some from
>> me.
>> You said "the change should be OK", and I'm simply saying "no" to that,
>> because it's not. The patch is not OK until review comments from other
>> developers have been addressed by the patch submitter.
>
> Thanks for the explanation Ronald,
>
> 1. Apparently you did not aim at the maintainership question.
>
>   It would be nice if you confirm this point,
>   to avoid further misunderstandings.
>
> 2. Would you cite the outstanding comment or comments about the patches
>which you feel are valid and not addressed?
>
>I kindly ask you check the latest iteration of the patch series
>where I tried to summarize all discussion points in the containing
>letter.
>
> TL;DR: I do have respect for your work and competence.
>Please do the same to others. Even if we all too often meet people
>who lack in those areas, there are some exceptions.
>
> To be fair your comments concerning the patches were among the most
> detailed and friendly, this is appreciated!
>
> But even your well meant comments happened to miss the point, being based
> in unfounded assumptions. I answered and explained and there it stopped.
>
> Frankly the only outstanding comments which I am aware of are of the kind
> "you the patch submitter do not understand why 'this' is better than
> 'that'".
>
> The fact is that I _do_ understand why you believe that something is
> better or not. I just do not feel a belief is sufficient per se.
>
> I invited you and others to look at _what_ makes something better
> or not and got literally no answers.
>
> Besides of course
> "imagine if someone else will do something else,
> it would be terrible, thus you are leading us to hell" :)
>
> or otherwise, citing literally:
> "we know this code, we know it can do this, don't tell us it's not
> possible" without specifying (and in fact misunderstanding) what
> "this" we were talking about: making the speedup usable with an
> unprepared application, which the overhelming majority of applications
> are. Regrettably, the present code is not prepared nor meant to be able to.
> The proposed code could, but this possiblity is now cut off,
> just to avoid contention.
>
> As a third example, your comment
> "We [...] know it's unreasonable from a maintenance perspective".
>
> The very presence of the cinepak decoder is a proof to the opposite
> because it worked this way (generating two different pixel formats
> inside the decoder) for years. Again, what "it's" we are talking about?
> The same "it" in your mind as in the patch?
>
> I went so long as to quantify/estimate the expected extra maintenance
> burden while you did not even mention any tangible criteria.
>
> This makes me doubt that you or others who commented have time to read
> the answers or are prepared to expect competence of your counterparts.
> Unfortunately this affects the quality of the judgement.
>
> I do have respect for your work and competence.
> Please do the same to others.

What is your Work and Competence in FFmpeg?
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] deduplicated [PATCH] Cinepak: speed up decoding several-fold, depending on the scenario, by supporting multiple output pixel formats.

[u-9iep]

On Sun, Mar 05, 2017 at 06:20:34PM -0500, Ronald S. Bultje wrote:
> Hi Rune,
> 
> On Sun, Mar 5, 2017 at 4:26 PM,  wrote:
> 
> > Ronald,
> >
> > On Sun, Mar 05, 2017 at 02:38:31PM -0500, Ronald S. Bultje wrote:
> > > Hi,
> > >
> > > On Sun, Mar 5, 2017 at 2:22 PM,  wrote:
> > >
> > > > On Mon, Feb 13, 2017 at 02:41:40PM +0100, u-9...@aetey.se wrote:
> > > > > On Mon, Feb 13, 2017 at 02:19:45PM +0100, Michael Niedermayer wrote:
> > > > > > you may want to add yourself to MAINTAINERs (after talking with
> > > > > > roberto, who i belive has less interrest in cinepak than you do
> > > > > > nowadays)
> > > > >
> > > > > Sounds ok for me. Roberto, what do you think (if you read this)?
> > > >
> > > > The only address to him which I found (in an old commit) bounced,
> > > > there was no reply here on the list either.
> > > >
> > > > Both can be a coincidence, but otherwise it looks like the change
> > should
> > > > be OK.
> > >
> > >
> > > No. This has been discussed repeatedly. Stop trying to push this through.
> >
> > My maintainership (for the code which I have contributed to, you may be
> > unaware about this fact) was not discussed otherwise than cited here.
> >
> > Please check what you are commenting,
> > especially when you mean to sound like having a definite power
> 
> 
> The rule is that a patch cannot be committed while a developer has
> outstanding comments. There's outstanding comments, including some from me.
> You said "the change should be OK", and I'm simply saying "no" to that,
> because it's not. The patch is not OK until review comments from other
> developers have been addressed by the patch submitter.

Thanks for the explanation Ronald,

1. Apparently you did not aim at the maintainership question.

  It would be nice if you confirm this point,
  to avoid further misunderstandings.

2. Would you cite the outstanding comment or comments about the patches
   which you feel are valid and not addressed?

   I kindly ask you check the latest iteration of the patch series
   where I tried to summarize all discussion points in the containing
   letter.

TL;DR: I do have respect for your work and competence.
   Please do the same to others. Even if we all too often meet people
   who lack in those areas, there are some exceptions.

To be fair your comments concerning the patches were among the most
detailed and friendly, this is appreciated!

But even your well meant comments happened to miss the point, being based
in unfounded assumptions. I answered and explained and there it stopped.

Frankly the only outstanding comments which I am aware of are of the kind
"you the patch submitter do not understand why 'this' is better than
'that'".

The fact is that I _do_ understand why you believe that something is
better or not. I just do not feel a belief is sufficient per se.

I invited you and others to look at _what_ makes something better
or not and got literally no answers.

Besides of course
"imagine if someone else will do something else,
it would be terrible, thus you are leading us to hell" :)

or otherwise, citing literally:
"we know this code, we know it can do this, don't tell us it's not
possible" without specifying (and in fact misunderstanding) what
"this" we were talking about: making the speedup usable with an
unprepared application, which the overhelming majority of applications
are. Regrettably, the present code is not prepared nor meant to be able to.
The proposed code could, but this possiblity is now cut off,
just to avoid contention.

As a third example, your comment
"We [...] know it's unreasonable from a maintenance perspective".

The very presence of the cinepak decoder is a proof to the opposite
because it worked this way (generating two different pixel formats
inside the decoder) for years. Again, what "it's" we are talking about?
The same "it" in your mind as in the patch?

I went so long as to quantify/estimate the expected extra maintenance
burden while you did not even mention any tangible criteria.

This makes me doubt that you or others who commented have time to read
the answers or are prepared to expect competence of your counterparts.
Unfortunately this affects the quality of the judgement.

I do have respect for your work and competence.
Please do the same to others.

Regards,
Rune

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

Re: [FFmpeg-devel] libopenjpegenc initialization

[Carl Eugen Hoyos]

2017-03-06 3:19 GMT+01:00 Aaron Boxer :

> Also, there doesn't seem to be any way of setting lossy vs. lossless
> encoding.

Please send a patch.

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

Re: [FFmpeg-devel] [PATCH] lavfi: rename af_aresample to af_resample

[Rostislav Pehlivanov]

On 6 March 2017 at 09:00, Carl Eugen Hoyos  wrote:

> 2017-03-06 9:48 GMT+01:00 Rostislav Pehlivanov :
>
> > +AVFilter ff_af_resample = {
> > +.name  = "resample",
>
> Why? Do we really need two identical filters with similar name?
>
> We cannot remove the "aresample" filter that is mentioned
> all over our documentation.
> We did not support he resample filter for several years,
> removing it can't be an issue.
>
> Carl Eugen
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>

Yeah, I agree, I'd prefer af_aresample to remain. Most of our filters use
af_a for audio and vf_ for video (e.g. af_apad and
vf_pad).
I'd be happy with the filename remaining af_aresample and the filter
remaining as af_aresample but also providing af_resample (that is if
there's a real need for it; I don't believe there is but maybe someone can
say there is). I've attached a patch which does that.
From 7a7b31afd4211ba980f73e7d3247d00d3bc563b1 Mon Sep 17 00:00:00 2001
From: Rostislav Pehlivanov 
Date: Mon, 6 Mar 2017 09:06:19 +
Subject: [PATCH] af_aresample: provide af_resample

Signed-off-by: Rostislav Pehlivanov 
---
 libavfilter/af_aresample.c | 13 +
 1 file changed, 13 insertions(+)

diff --git a/libavfilter/af_aresample.c b/libavfilter/af_aresample.c
index 028e105318..1ee02a96ad 100644
--- a/libavfilter/af_aresample.c
+++ b/libavfilter/af_aresample.c
@@ -349,3 +349,16 @@ AVFilter ff_af_aresample = {
 .inputs= aresample_inputs,
 .outputs   = aresample_outputs,
 };
+
+/* af_resample got removed, this provides compatibility for now */
+AVFilter ff_af_resample = {
+.name  = "resample",
+.description   = NULL_IF_CONFIG_SMALL("Resample audio data."),
+.init_dict = init_dict,
+.uninit= uninit,
+.query_formats = query_formats,
+.priv_size = sizeof(AResampleContext),
+.priv_class= _class,
+.inputs= aresample_inputs,
+.outputs   = aresample_outputs,
+};
-- 
2.12.0.rc1.440.g5b76565f74

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

Re: [FFmpeg-devel] [PATCH] matroska: add DSD support

[Carl Eugen Hoyos]

2017-03-06 9:00 GMT+01:00 Takayuki 'January June' Suwa
:

> +{"A_PDM/DSD/LSBF"   , AV_CODEC_ID_DSD_LSBF},
> +{"A_PDM/DSD/MSBF"   , AV_CODEC_ID_DSD_MSBF},

Where are they specified?

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

Re: [FFmpeg-devel] [PATCH] lavfi: rename af_aresample to af_resample

[Carl Eugen Hoyos]

2017-03-06 9:48 GMT+01:00 Rostislav Pehlivanov :

> +AVFilter ff_af_resample = {
> +.name  = "resample",

Why? Do we really need two identical filters with similar name?

We cannot remove the "aresample" filter that is mentioned
all over our documentation.
We did not support he resample filter for several years,
removing it can't be an issue.

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

[FFmpeg-devel] [PATCH] lavfi: rename af_aresample to af_resample

[Rostislav Pehlivanov]

Meant to be applied on top of the patch which removes af_resample

Registers both af_aresample and af_resample as valid filters to mainain
compatibility.

Signed-off-by: Rostislav Pehlivanov 
---
 MAINTAINERS   |  2 +-
 libavfilter/Makefile  |  2 +-
 libavfilter/{af_aresample.c => af_resample.c} | 12 
 3 files changed, 14 insertions(+), 2 deletions(-)
 rename libavfilter/{af_aresample.c => af_resample.c} (96%)

diff --git a/MAINTAINERS b/MAINTAINERS
index c33a976411..eaf721c6c8 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -311,7 +311,7 @@ Filters:
   af_afade.cPaul B Mahol
   af_amerge.c   Nicolas George
   af_aphaser.c  Paul B Mahol
-  af_aresample.cMichael Niedermayer
+  af_resample.c Michael Niedermayer
   af_astats.c   Paul B Mahol
   af_atempo.c   Pavel Koshevoy
   af_biquads.c  Paul B Mahol
diff --git a/libavfilter/Makefile b/libavfilter/Makefile
index d3641370de..baaa696b19 100644
--- a/libavfilter/Makefile
+++ b/libavfilter/Makefile
@@ -54,7 +54,7 @@ OBJS-$(CONFIG_APERMS_FILTER) += f_perms.o
 OBJS-$(CONFIG_APHASER_FILTER)+= af_aphaser.o 
generate_wave_table.o
 OBJS-$(CONFIG_APULSATOR_FILTER)  += af_apulsator.o
 OBJS-$(CONFIG_AREALTIME_FILTER)  += f_realtime.o
-OBJS-$(CONFIG_ARESAMPLE_FILTER)  += af_aresample.o
+OBJS-$(CONFIG_ARESAMPLE_FILTER)  += af_resample.o
 OBJS-$(CONFIG_AREVERSE_FILTER)   += f_reverse.o
 OBJS-$(CONFIG_ASELECT_FILTER)+= f_select.o
 OBJS-$(CONFIG_ASENDCMD_FILTER)   += f_sendcmd.o
diff --git a/libavfilter/af_aresample.c b/libavfilter/af_resample.c
similarity index 96%
rename from libavfilter/af_aresample.c
rename to libavfilter/af_resample.c
index 028e105318..1e5d43faff 100644
--- a/libavfilter/af_aresample.c
+++ b/libavfilter/af_resample.c
@@ -338,6 +338,18 @@ static const AVFilterPad aresample_outputs[] = {
 { NULL }
 };
 
+AVFilter ff_af_resample = {
+.name  = "resample",
+.description   = NULL_IF_CONFIG_SMALL("Resample audio data."),
+.init_dict = init_dict,
+.uninit= uninit,
+.query_formats = query_formats,
+.priv_size = sizeof(AResampleContext),
+.priv_class= _class,
+.inputs= aresample_inputs,
+.outputs   = aresample_outputs,
+};
+
 AVFilter ff_af_aresample = {
 .name  = "aresample",
 .description   = NULL_IF_CONFIG_SMALL("Resample audio data."),
-- 
2.12.0.rc1.440.g5b76565f74

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

Re: [FFmpeg-devel] [PATCH 1/4] lavfi: remove af_resample

[Rostislav Pehlivanov]

On 6 March 2017 at 07:51, wm4  wrote:

>
> I'd rather remove af_aresample.c (and port af_resample.c to
> libswsresample or whatever if you want), because af_resample.c has the
> better filter name.
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>

I'll post a separate commit to rename af_aresample to af_resample and also
register the filter as af_aresample to keep compatibility for now.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

[FFmpeg-devel] [PATCH] matroska: add DSD support

[Takayuki 'January June' Suwa]

this patch makes transporting several (low-bitrate to hi-res) music data more 
simpler.
almost major/defacto-std lossy/lossless audio codecs such as MP3, AAC, FLAC, 
etc. and now DSD can be muxed by the single way :)

global/per-stream metadata seems to be exported correctly.
---
 libavformat/matroska.c| 2 ++
 libavformat/matroskaenc.c | 2 ++
 2 files changed, 4 insertions(+)

diff --git a/libavformat/matroska.c b/libavformat/matroska.c
index 6af667c..125a026 100644
--- a/libavformat/matroska.c
+++ b/libavformat/matroska.c
@@ -48,6 +48,8 @@ const CodecTags ff_mkv_codec_tags[]={
 {"A_PCM/INT/LIT", AV_CODEC_ID_PCM_S24LE},
 {"A_PCM/INT/LIT", AV_CODEC_ID_PCM_S32LE},
 {"A_PCM/INT/LIT", AV_CODEC_ID_PCM_U8},
+{"A_PDM/DSD/LSBF"   , AV_CODEC_ID_DSD_LSBF},
+{"A_PDM/DSD/MSBF"   , AV_CODEC_ID_DSD_MSBF},
 {"A_QUICKTIME/QDMC" , AV_CODEC_ID_QDMC},
 {"A_QUICKTIME/QDM2" , AV_CODEC_ID_QDM2},
 {"A_REAL/14_4"  , AV_CODEC_ID_RA_144},
diff --git a/libavformat/matroskaenc.c b/libavformat/matroskaenc.c
index 1605f0c..a9503f6 100644
--- a/libavformat/matroskaenc.c
+++ b/libavformat/matroskaenc.c
@@ -2528,6 +2528,8 @@ static const AVCodecTag additional_audio_tags[] = {
 { AV_CODEC_ID_PCM_S16BE, 0x },
 { AV_CODEC_ID_PCM_S24BE, 0x },
 { AV_CODEC_ID_PCM_S32BE, 0x },
+{ AV_CODEC_ID_DSD_LSBF,  0x },
+{ AV_CODEC_ID_DSD_MSBF,  0x },
 { AV_CODEC_ID_QDMC,  0x },
 { AV_CODEC_ID_QDM2,  0x },
 { AV_CODEC_ID_RA_144,0x },
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel