[FFmpeg-devel] [PATCH] avfiltergraph: add -sample_rate_fallback
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, &inputs,
&outputs)) < 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 = &class;
+
+return av_opt_eval_int(&pclass, &opts[0], arg, &sample_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
Re: [FFmpeg-devel] [PATCH] avutil/tests/lfg.c: added proper normality test
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
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 1/4] lavfi: remove af_resample
2017-03-07 7:37 GMT+01:00 wm4 : > 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? How about you stop breaking development rules for once? 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"
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, &oldval, 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
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(&initialized, 1, memory_order_relaxed)) {
> +while (!atomic_load_explicit(&ready, 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(&ready, 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
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
./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"
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, &oldval, 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/2] libx264: remove the "x264opts" AVOption
On Tue, Mar 07, 2017 at 12:20:20AM +0200, Jan Ekström wrote: > 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(-) please wait with this its a long time ago but i faintly remember that the option you are about to remove worked while the one remaining had bugs i just tested a bit and thes behave differently for at least no-fast-pskip, i dont remember what the original bug was though also this would break scripts [...] -- 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] [PATCH 1/4] avcodec/allcodecs: make avcodec_register_all thread safe
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
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
[FFmpeg-devel] [PATCH 4/4] avcodec/vp8: remove redundant check
Signed-off-by: Michael Niedermayer
---
libavcodec/vp8.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/libavcodec/vp8.c b/libavcodec/vp8.c
index 8039e7817e..a3d057d62e 100644
--- a/libavcodec/vp8.c
+++ b/libavcodec/vp8.c
@@ -2504,8 +2504,6 @@ int vp78_decode_mb_row_sliced(AVCodecContext *avctx, void
*tdata, int jobnr,
td->thread_nr = threadnr;
for (mb_y = jobnr; mb_y < s->mb_height; mb_y += num_jobs) {
-if (mb_y >= s->mb_height)
-break;
td->thread_mb_pos = mb_y << 16;
ret = s->decode_mb_row_no_filter(avctx, tdata, jobnr, threadnr);
if (ret < 0)
--
2.11.0
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 1/4] avcodec/pictordec: Fix runtime error: left shift of 64 by 25 places cannot be represented in type 'int'
Fixes: 724/clusterfuzz-testcase-6738249571631104
Found-by: continuous fuzzing process
https://github.com/google/oss-fuzz/tree/master/targets/ffmpeg
Signed-off-by: Michael Niedermayer
---
libavcodec/pictordec.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavcodec/pictordec.c b/libavcodec/pictordec.c
index a09ee379c0..2dbc040b5c 100644
--- a/libavcodec/pictordec.c
+++ b/libavcodec/pictordec.c
@@ -57,7 +57,7 @@ static void picmemset_8bpp(PicContext *s, AVFrame *frame, int
value, int run,
}
}
-static void picmemset(PicContext *s, AVFrame *frame, int value, int run,
+static void picmemset(PicContext *s, AVFrame *frame, unsigned value, int run,
int *x, int *y, int *plane, int bits_per_plane)
{
uint8_t *d;
--
2.11.0
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 2/4] avcodec/wavpack: Fix runtime error: left shift of negative value -5
Fixes: 729/clusterfuzz-testcase-5154831595470848
Found-by: continuous fuzzing process
https://github.com/google/oss-fuzz/tree/master/targets/ffmpeg
Signed-off-by: Michael Niedermayer
---
libavcodec/wavpack.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/libavcodec/wavpack.c b/libavcodec/wavpack.c
index a4ba07fc83..943e46a25c 100644
--- a/libavcodec/wavpack.c
+++ b/libavcodec/wavpack.c
@@ -273,7 +273,7 @@ static inline int wv_get_value_integer(WavpackFrameContext
*s, uint32_t *crc,
unsigned bit;
if (s->extra_bits) {
-S <<= s->extra_bits;
+S *= 1 << s->extra_bits;
if (s->got_extra_bits &&
get_bits_left(&s->gb_extra_bits) >= s->extra_bits) {
--
2.11.0
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
[FFmpeg-devel] [PATCH 3/4] avcodec/vp568: Check that there is enough data for ff_vp56_init_range_decoder()
Fixes: timeout in 730/clusterfuzz-testcase-5265113739165696
Found-by: continuous fuzzing process
https://github.com/google/oss-fuzz/tree/master/targets/ffmpeg
Signed-off-by: Michael Niedermayer
---
libavcodec/vp5.c | 5 -
libavcodec/vp56.h| 2 +-
libavcodec/vp56rac.c | 5 -
libavcodec/vp6.c | 15 +++
libavcodec/vp8.c | 21 ++---
5 files changed, 34 insertions(+), 14 deletions(-)
diff --git a/libavcodec/vp5.c b/libavcodec/vp5.c
index 54db620bde..b5f06a0940 100644
--- a/libavcodec/vp5.c
+++ b/libavcodec/vp5.c
@@ -38,8 +38,11 @@ static int vp5_parse_header(VP56Context *s, const uint8_t
*buf, int buf_size)
{
VP56RangeCoder *c = &s->c;
int rows, cols;
+int ret;
-ff_vp56_init_range_decoder(&s->c, buf, buf_size);
+ret = ff_vp56_init_range_decoder(&s->c, buf, buf_size);
+if (ret < 0)
+return ret;
s->frames[VP56_FRAME_CURRENT]->key_frame = !vp56_rac_get(c);
vp56_rac_get(c);
ff_vp56_init_dequant(s, vp56_rac_gets(c, 6));
diff --git a/libavcodec/vp56.h b/libavcodec/vp56.h
index e5c5bea963..c049399df8 100644
--- a/libavcodec/vp56.h
+++ b/libavcodec/vp56.h
@@ -224,7 +224,7 @@ int ff_vp56_decode_frame(AVCodecContext *avctx, void *data,
int *got_frame,
*/
extern const uint8_t ff_vp56_norm_shift[256];
-void ff_vp56_init_range_decoder(VP56RangeCoder *c, const uint8_t *buf, int
buf_size);
+int ff_vp56_init_range_decoder(VP56RangeCoder *c, const uint8_t *buf, int
buf_size);
static av_always_inline unsigned int vp56_rac_renorm(VP56RangeCoder *c)
{
diff --git a/libavcodec/vp56rac.c b/libavcodec/vp56rac.c
index 6061b7ee72..e70302bf85 100644
--- a/libavcodec/vp56rac.c
+++ b/libavcodec/vp56rac.c
@@ -37,11 +37,14 @@ const uint8_t ff_vp56_norm_shift[256]= {
0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,
};
-void ff_vp56_init_range_decoder(VP56RangeCoder *c, const uint8_t *buf, int
buf_size)
+int ff_vp56_init_range_decoder(VP56RangeCoder *c, const uint8_t *buf, int
buf_size)
{
c->high = 255;
c->bits = -16;
c->buffer = buf;
c->end = buf + buf_size;
+if (buf_size < 1)
+return AVERROR_INVALIDDATA;
c->code_word = bytestream_get_be24(&c->buffer);
+return 0;
}
diff --git a/libavcodec/vp6.c b/libavcodec/vp6.c
index 662126ca70..f0e60a3822 100644
--- a/libavcodec/vp6.c
+++ b/libavcodec/vp6.c
@@ -52,6 +52,7 @@ static int vp6_parse_header(VP56Context *s, const uint8_t
*buf, int buf_size)
int sub_version;
int rows, cols;
int res = 0;
+int ret;
int separated_coeff = buf[0] & 1;
s->frames[VP56_FRAME_CURRENT]->key_frame = !(buf[0] & 0x80);
@@ -93,7 +94,7 @@ static int vp6_parse_header(VP56Context *s, const uint8_t
*buf, int buf_size)
s->avctx->coded_width = 16 * cols;
s->avctx->coded_height = 16 * rows;
} else {
-int ret = ff_set_dimensions(s->avctx, 16 * cols, 16 * rows);
+ret = ff_set_dimensions(s->avctx, 16 * cols, 16 * rows);
if (ret < 0)
return ret;
@@ -105,7 +106,9 @@ static int vp6_parse_header(VP56Context *s, const uint8_t
*buf, int buf_size)
res = VP56_SIZE_CHANGE;
}
-ff_vp56_init_range_decoder(c, buf+6, buf_size-6);
+ret = ff_vp56_init_range_decoder(c, buf+6, buf_size-6);
+if (ret < 0)
+return ret;
vp56_rac_gets(c, 2);
parse_filter_info = s->filter_header;
@@ -122,7 +125,9 @@ static int vp6_parse_header(VP56Context *s, const uint8_t
*buf, int buf_size)
buf += 2;
buf_size -= 2;
}
-ff_vp56_init_range_decoder(c, buf+1, buf_size-1);
+ret = ff_vp56_init_range_decoder(c, buf+1, buf_size-1);
+if (ret < 0)
+return ret;
s->golden_frame = vp56_rac_get(c);
if (s->filter_header) {
@@ -165,7 +170,9 @@ static int vp6_parse_header(VP56Context *s, const uint8_t
*buf, int buf_size)
s->parse_coeff = vp6_parse_coeff_huffman;
init_get_bits(&s->gb, buf, buf_size<<3);
} else {
-ff_vp56_init_range_decoder(&s->cc, buf, buf_size);
+ret = ff_vp56_init_range_decoder(&s->cc, buf, buf_size);
+if (ret < 0)
+return ret;
s->ccp = &s->cc;
}
} else {
diff --git a/libavcodec/vp8.c b/libavcodec/vp8.c
index cc158528ef..8039e7817e 100644
--- a/libavcodec/vp8.c
+++ b/libavcodec/vp8.c
@@ -261,6 +261,7 @@ static int setup_partitions(VP8Context *s, const uint8_t
*buf, int buf_size)
{
const uint8_t *sizes = buf;
int i;
+int ret;
s->num_coeff_partitions = 1 << vp8_rac_get_uint(&s->c, 2);
@@ -274,13 +275,13 @@ static int setup_partitions(VP8Context *s, const uint8_t
*buf, int buf_size)
if (buf_size - size < 0)
return -1;
-ff_vp56_init_range_decoder(&s->coeff_partition[i], buf, size);
+ret = ff_vp
Re: [FFmpeg-devel] [RFC] Removal of the "x264opts" libx264 wrapper AVOption
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
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
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
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
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(&avr_class, e->key, NULL, 0,
> -AV_OPT_SEARCH_FAKE_OBJ | AV_OPT_SEARCH_CHILDREN))
> -av_dict_set(&s->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(&s->options, "in_channel_layout", NULL, 0);
> -av_dict_set(&s->options, "out_channel_layout", NULL, 0);
> -av_dict_set(&s->options, "in_sample_fmt", NULL, 0);
> -av_dict_set(&s->options, "out_sample_fmt", NULL, 0);
> -av_dict_set(&s->options, "in_sample_rate",NULL, 0);
> -av_dict_set(&s->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(&s->avr);
> -}
> -av_dict_free(&s->options);
> -}
> -
> -static int query_formats(AVFilterContext *ctx)
> -{
> -AVFilterLink *inlin
Re: [FFmpeg-devel] [PATCH 2/2] doc/encoders: remove mentions of the x264opts AVOption
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
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 1/2] libx264: remove the "x264opts" AVOption
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(&x4->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
[FFmpeg-devel] [PATCH 2/2] doc/encoders: remove mentions of the x264opts AVOption
---
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
Re: [FFmpeg-devel] [PATCH 4/4] lavfi: remove af_asynts filter
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
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.
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 ma
[FFmpeg-devel] opencl on osx
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
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
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
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(&initialized, 1, memory_order_relaxed)) {
+while (!atomic_load_explicit(&ready, 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(&ready, 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
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(&initialized, 1, memory_order_relaxed)) {
+while (!atomic_load_explicit(&ready, 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(&ready, 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
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
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(&initialized, 1, memory_order_relaxed)) {
+while (!atomic_load_explicit(&ready, 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(&ready, 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
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(&initialized, 1, memory_order_relaxed)) {
+while (!atomic_load_explicit(&ready, 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(&ready, 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
[FFmpeg-devel] [PATCH] avcodec/mpeg12dec: parse A53 caption data embedded in SCTE-20 user data
From: Aman Gupta
---
libavcodec/mpeg12dec.c | 38 ++
1 file changed, 38 insertions(+)
diff --git a/libavcodec/mpeg12dec.c b/libavcodec/mpeg12dec.c
index 27db14c..8cafdb0 100644
--- a/libavcodec/mpeg12dec.c
+++ b/libavcodec/mpeg12dec.c
@@ -2260,6 +2260,44 @@ static int mpeg_decode_a53_cc(AVCodecContext *avctx,
avctx->properties |= FF_CODEC_PROPERTY_CLOSED_CAPTIONS;
}
return 1;
+} else if (buf_size >= 2 &&
+ p[0] == 0x03 && (p[1]&0x7f) == 0x01) {
+/* extract SCTE-20 CC data */
+GetBitContext gb;
+int cc_count = 0;
+int i;
+
+init_get_bits(&gb, p + 2, buf_size - 2);
+cc_count = get_bits(&gb, 5);
+if (cc_count > 0) {
+av_freep(&s1->a53_caption);
+s1->a53_caption_size = cc_count * 3;
+s1->a53_caption = av_malloc(s1->a53_caption_size);
+if (s1->a53_caption) {
+uint8_t field, cc1, cc2;
+uint8_t *cap = s1->a53_caption;
+for (i = 0; i < cc_count; i++) {
+skip_bits(&gb, 2); // priority
+field = get_bits(&gb, 2);
+skip_bits(&gb, 5); // line_offset
+cc1 = get_bits(&gb, 8);
+cc2 = get_bits(&gb, 8);
+skip_bits(&gb, 1); // marker
+
+if (!field) { // forbidden
+cap[0] = cap[1] = cap[2] = 0x00;
+} else {
+field = (field == 2 ? 1 : 0);
+if (!s1->mpeg_enc_ctx.top_field_first) field = !field;
+cap[0] = 0x04 | field;
+cap[1] = ff_reverse[cc1];
+cap[2] = ff_reverse[cc2];
+}
+cap += 3;
+}
+}
+}
+return 1;
} else if (buf_size >= 11 &&
p[0] == 'C' && p[1] == 'C' && p[2] == 0x01 && p[3] == 0xf8) {
/* extract DVD CC data
--
2.10.1 (Apple Git-78)
___
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
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
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
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(&s->gb) < nb_blocks * 8)
returnAVERROR_INVALIDDATA;
+ // check offset table
+ if (bytestream2_peek_le64(&s->gb)== 0)
+ {
+ uint64_t *table= (uint64_t *)s->gb.buffer;
+ uint8_t *head =avpkt->data;
+ uint8_t *marker= head + bytestream2_tell(&s->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.
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 well.
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
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
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.
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
> > >> > >> 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
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.
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
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
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.
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.
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
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
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
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.
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
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
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.
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.
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
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.
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.
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.
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
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
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.
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
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
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
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.
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 modifications) - we're not even in
Re: [FFmpeg-devel] [PATCH] lswr: remove support for libsoxr resampling
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.
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.
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
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
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= &aresample_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
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
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
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= &aresample_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
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
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
