Re: [FFmpeg-devel] Question on the “decode_failed” logic in ffmpeg.c:

[Steven Liu]

2017-07-12 12:32 GMT+08:00 Geek.Song :
> In ffmpeg.c:
> //
> // @ static int process_input_packet(InputStream *ist, const AVPacket
> *pkt, int no_eof)
> //
>  if (ret < 0) {
> if (decode_failed) {
> av_log(NULL, AV_LOG_ERROR, "Error while decoding
> stream #%d:%d: %s\n",
>ist->file_index, ist->st->index, av_err2str(ret));
> } else {
> av_log(NULL, AV_LOG_FATAL, "Error while processing the 
> decoded "
>"data for stream #%d:%d\n", ist->file_index,
> ist->st->index);
> }
> if (!decode_failed || exit_on_error)
> exit_program(1);
> break;
> }
>
>
> why is:
> if (!decode_failed || exit_on_error)
> exit_program(1);
>
> I think it should be:
If it should be :if (decode_failed || exit_on_error)
maybe only if (exit_on_error) than that, isn't it?
> if (decode_failed || exit_on_error)
> exit_program(1);
>
>
> -
> Productive. Reliable. Fast.
> ___
> 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] Question on the “decode_failed” logic in ffmpeg.c:

[Geek.Song]

In ffmpeg.c:
//
// @ static int process_input_packet(InputStream *ist, const AVPacket
*pkt, int no_eof)
//
 if (ret < 0) {
if (decode_failed) {
av_log(NULL, AV_LOG_ERROR, "Error while decoding
stream #%d:%d: %s\n",
   ist->file_index, ist->st->index, av_err2str(ret));
} else {
av_log(NULL, AV_LOG_FATAL, "Error while processing the decoded "
   "data for stream #%d:%d\n", ist->file_index,
ist->st->index);
}
if (!decode_failed || exit_on_error)
exit_program(1);
break;
}


why is:
if (!decode_failed || exit_on_error)
exit_program(1);

I think it should be:
if (decode_failed || exit_on_error)
exit_program(1);


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

[FFmpeg-devel] [PATCH] opusenc: use float_dsp for transient mdcts

[Rostislav Pehlivanov]

vector_fmul_reverse requires padding the window at the front

Signed-off-by: Rostislav Pehlivanov 
---
 libavcodec/opus_celt.h | 4 ++--
 libavcodec/opusenc.c   | 8 +++-
 libavcodec/opustab.c   | 8 ++--
 libavcodec/opustab.h   | 3 +--
 4 files changed, 12 insertions(+), 11 deletions(-)

diff --git a/libavcodec/opus_celt.h b/libavcodec/opus_celt.h
index b80ade84f2..62aee359f6 100644
--- a/libavcodec/opus_celt.h
+++ b/libavcodec/opus_celt.h
@@ -75,8 +75,8 @@ typedef struct CeltBlock {
 DECLARE_ALIGNED(32, float, coeffs)[CELT_MAX_FRAME_SIZE];
 
 /* Used by the encoder */
-DECLARE_ALIGNED(32, float, overlap)[120];
-DECLARE_ALIGNED(32, float, samples)[CELT_MAX_FRAME_SIZE];
+DECLARE_ALIGNED(32, float, overlap)[CELT_OVERLAP];
+DECLARE_ALIGNED(32, float, samples)[FFALIGN(CELT_MAX_FRAME_SIZE, 8)];
 
 /* postfilter parameters */
 int   pf_period_new;
diff --git a/libavcodec/opusenc.c b/libavcodec/opusenc.c
index 8aba291e7e..6cefd33884 100644
--- a/libavcodec/opusenc.c
+++ b/libavcodec/opusenc.c
@@ -210,17 +210,15 @@ static void celt_frame_mdct(OpusEncContext *s, CeltFrame 
*f)
 int i, t, ch;
 float *win = s->scratch;
 
-/* I think I can use s->dsp->vector_fmul_window for transients at least */
 if (f->transient) {
 for (ch = 0; ch < f->channels; ch++) {
 CeltBlock *b = >block[ch];
 float *src1 = b->overlap;
 for (t = 0; t < f->blocks; t++) {
 float *src2 = >samples[CELT_OVERLAP*t];
-for (i = 0; i < CELT_OVERLAP; i++) {
-win[   i] = src1[i]*ff_celt_window[i];
-win[CELT_OVERLAP + i] = 
src2[i]*ff_celt_window[CELT_OVERLAP - i - 1];
-}
+s->dsp->vector_fmul(win, src1, ff_celt_window, CELT_OVERLAP);
+s->dsp->vector_fmul_reverse([CELT_OVERLAP], src2,
+ff_celt_window - 8, CELT_OVERLAP + 
8);
 src1 = src2;
 s->mdct[0]->mdct(s->mdct[0], b->coeffs + t, win, f->blocks);
 }
diff --git a/libavcodec/opustab.c b/libavcodec/opustab.c
index 635cc363e2..1f3049676e 100644
--- a/libavcodec/opustab.c
+++ b/libavcodec/opustab.c
@@ -1096,7 +1096,9 @@ const float ff_celt_postfilter_taps[3][3] = {
 { 0.7998046875f, 0.1000976562f, 0.0   }
 };
 
-DECLARE_ALIGNED(32, const float, ff_celt_window)[120] = {
+DECLARE_ALIGNED(32, static const float, ff_celt_window_padded)[128] = {
+0.f, 0.f, 0.f, 0.f,
+0.f, 0.f, 0.f, 0.f,
 6.7286966e-05f, 0.00060551348f, 0.0016815970f, 0.0032947962f, 
0.0054439943f,
 0.0081276923f, 0.011344001f, 0.015090633f, 0.019364886f, 0.024163635f,
 0.029483315f, 0.035319905f, 0.041668911f, 0.048525347f, 0.055883718f,
@@ -1120,9 +1122,11 @@ DECLARE_ALIGNED(32, const float, ff_celt_window)[120] = {
 0.99499004f, 0.99592297f, 0.99672162f, 0.99739874f, 0.99796667f,
 0.99843728f, 0.99882195f, 0.99913147f, 0.99937606f, 0.99956527f,
 0.99970802f, 0.99981248f, 0.99988613f, 0.3565f, 0.6697f,
-0.8518f, 0.9457f, 0.9859f, 0.9982f, 1.000f,
+0.8518f, 0.9457f, 0.9859f, 0.9982f, 1.f,
 };
 
+const float *ff_celt_window = _celt_window_padded[8];
+
 /* square of the window, used for the postfilter */
 const float ff_celt_window2[120] = {
 4.5275357e-09f, 3.66647e-07f, 2.82777e-06f, 1.08557e-05f, 2.96371e-05f, 
6.60594e-05f,
diff --git a/libavcodec/opustab.h b/libavcodec/opustab.h
index b4589869ef..bce5a42830 100644
--- a/libavcodec/opustab.h
+++ b/libavcodec/opustab.h
@@ -154,8 +154,7 @@ extern const uint32_t ff_celt_pvq_u[1272];
 extern const floatff_celt_postfilter_taps[3][3];
 
 extern const floatff_celt_window2[120];
-
-DECLARE_ALIGNED(32, extern const float, ff_celt_window)[120];
+extern const float   *ff_celt_window;
 
 extern const uint32_t * const ff_celt_pvq_u_row[15];
 
-- 
2.13.2

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

Re: [FFmpeg-devel] [PATCH] avcodec/aacps (fixed point): Fix multiple signed integer overflows

[Michael Niedermayer]

On Sun, Jul 09, 2017 at 06:27:58PM +0200, Michael Niedermayer wrote:
> Fixes: runtime error: signed integer overflow: 1421978265 - -1810326882 
> cannot be represented in type 'int'
> Fixes: 2527/clusterfuzz-testcase-minimized-5260915396050944
> 
> Found-by: continuous fuzzing process 
> https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
> Signed-off-by: Michael Niedermayer 
> ---
>  libavcodec/aacps.c | 25 -
>  1 file changed, 8 insertions(+), 17 deletions(-)

applied

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

Breaking DRM is a little like attempting to break through a door even
though the window is wide open and the only thing in the house is a bunch
of things you dont want and which you would get tomorrow for free anyway


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

Re: [FFmpeg-devel] [PATCH] Add prefetch for mips

[Michael Niedermayer]

On Tue, Jul 11, 2017 at 12:18:59PM +0530, kaustubh.ra...@imgtec.com wrote:
> From: Kaustubh Raste 
> 
> Signed-off-by: Kaustubh Raste 
> ---
>  libavcodec/mips/Makefile|1 +
>  libavcodec/mips/videodsp_mips.c |   42 
> +++
>  libavcodec/videodsp.c   |2 ++
>  libavcodec/videodsp.h   |1 +
>  4 files changed, 46 insertions(+)
>  create mode 100644 libavcodec/mips/videodsp_mips.c
> 
> diff --git a/libavcodec/mips/Makefile b/libavcodec/mips/Makefile
> index 797df09..e2a779c 100644
> --- a/libavcodec/mips/Makefile
> +++ b/libavcodec/mips/Makefile
> @@ -38,6 +38,7 @@ OBJS-$(CONFIG_ME_CMP) += 
> mips/me_cmp_init_mips.o
>  OBJS-$(CONFIG_MPEG4_DECODER)  += mips/xvididct_init_mips.o
>  OBJS-$(CONFIG_VC1DSP) += mips/vc1dsp_init_mips.o
>  OBJS-$(CONFIG_WMV2DSP)+= mips/wmv2dsp_init_mips.o
> +OBJS-$(CONFIG_VIDEODSP)   += mips/videodsp_mips.o
>  MSA-OBJS-$(CONFIG_HEVC_DECODER)   += mips/hevcdsp_msa.o\
>   mips/hevc_mc_uni_msa.o\
>   mips/hevc_mc_uniw_msa.o   \
> diff --git a/libavcodec/mips/videodsp_mips.c b/libavcodec/mips/videodsp_mips.c
> new file mode 100644
> index 000..c2c8282
> --- /dev/null
> +++ b/libavcodec/mips/videodsp_mips.c
> @@ -0,0 +1,42 @@
> +/*
> + * Copyright (c) 2017 Kaustubh Raste (kaustubh.ra...@imgtec.com)
> + *
> + * 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
> + */
> +
> +#include "config.h"
> +#include "libavutil/attributes.h"
> +#include "libavcodec/videodsp.h"
> +
> +#if HAVE_MSA
> +static void prefetch_mips(uint8_t *mem, ptrdiff_t stride, int h)
> +{
> +register const uint8_t *p = mem;

> +do {
> +__asm__ volatile ("pref 4, 0(%[p])" : : [p] "r" (p));
> +__asm__ volatile ("pref 4, 32(%[p])" : : [p] "r" (p));
> +p += stride;
> +} while(--h);

generally doing a loop in C with asm in it is worse than the whole
loop in asm, speedwise that is


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

it is not once nor twice but times without number that the same ideas make
their appearance in the world. -- Aristotle


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

Re: [FFmpeg-devel] [PATCH] pthread_frame: save the FF_DEBUG_THREADS option in PerThreadContext.

[Ronald S. Bultje]

Hi,

On Mon, Jul 10, 2017 at 5:51 PM, Ronald S. Bultje 
wrote:

> On Mon, Jul 10, 2017 at 1:24 PM, Wan-Teh Chang <
> wtc-at-google@ffmpeg.org> wrote:
>
>> Add the debug_threads boolean field to PerThreadContext. For
>> PerThreadContext *p, p->debug_threads records whether the
>> FF_DEBUG_THREADS bit is set in p->avctx->debug, and p->debug_threads and
>> p->avctx->debug are kept in sync. The debug_threads field is defined as
>> an atomic_int to allow atomic read by another thread in
>> ff_thread_await_progress().
>>
>> This fixes the tsan warning that
>> 2e664b9c1e73c80aab91070c1eb7676f04bdd12d attempted to fix:
>>
>> WARNING: ThreadSanitizer: data race (pid=452658)
>>   Write of size 4 at 0x7b640003f4fc by main thread (mutexes: write
>> M248499):
>> #0 update_context_from_user [..]/libavcodec/pthread_frame.c:335:19
>> (5ab42bb1a6f4b068d7863dabe9b2bacc+0xe73859)
>> [..]
>>   Previous read of size 4 at 0x7b640003f4fc by thread T130 (mutexes:
>> write M248502, write M248500):
>> #0 ff_thread_await_progress [..]/libavcodec/pthread_frame.c:591:26
>> (5ab42bb1a6f4b068d7863dabe9b2bacc+0xe749a1)
>>
>> Signed-off-by: Wan-Teh Chang 
>> ---
>>  libavcodec/pthread_frame.c | 11 +--
>>  1 file changed, 9 insertions(+), 2 deletions(-)
>
>
> I think this looks OK, thanks. I'll leave it out for a day or so for
> others to review before I merge.
>

Pushed.

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

[FFmpeg-devel] [PATCH 1/3] avutil: merge slice threading implementation from avcodec and avfilter

[Muhammad Faiz]

Rework it to improve performance. Now mutex is not shared by workers,
instead each worker has its own mutex and condition variable. This
reduces lock contention between workers. Also use atomic variable for
counter.

The interface also allows execute to run special function on main
thread, requested by Ronald.

Signed-off-by: Muhammad Faiz 
---
 libavutil/Makefile  |   1 +
 libavutil/slicethread.c | 259 
 libavutil/slicethread.h |  52 ++
 3 files changed, 312 insertions(+)
 create mode 100644 libavutil/slicethread.c
 create mode 100644 libavutil/slicethread.h

diff --git a/libavutil/Makefile b/libavutil/Makefile
index b4464b0..af9fba8 100644
--- a/libavutil/Makefile
+++ b/libavutil/Makefile
@@ -142,6 +142,7 @@ OBJS = adler32.o
\
samplefmt.o  \
sha.o\
sha512.o \
+   slicethread.o\
spherical.o  \
stereo3d.o   \
threadmessage.o  \
diff --git a/libavutil/slicethread.c b/libavutil/slicethread.c
new file mode 100644
index 000..785a1e4
--- /dev/null
+++ b/libavutil/slicethread.c
@@ -0,0 +1,259 @@
+/*
+ * 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
+ */
+
+#include 
+#include "slicethread.h"
+#include "mem.h"
+#include "thread.h"
+#include "avassert.h"
+
+#if HAVE_PTHREADS || HAVE_W32THREADS || HAVE_OS2THREADS
+
+typedef struct WorkerContext {
+AVSliceThread   *ctx;
+pthread_mutex_t mutex;
+pthread_cond_t  cond;
+pthread_t   thread;
+int done;
+} WorkerContext;
+
+struct AVSliceThread {
+WorkerContext   *workers;
+int nb_threads;
+int nb_active_threads;
+int nb_jobs;
+
+atomic_uint first_job;
+atomic_uint current_job;
+pthread_mutex_t done_mutex;
+pthread_cond_t  done_cond;
+int done;
+int finished;
+
+void*priv;
+void(*worker_func)(void *priv, int jobnr, int threadnr, int 
nb_jobs, int nb_threads);
+void(*main_func)(void *priv);
+};
+
+static int run_jobs(AVSliceThread *ctx)
+{
+unsigned nb_jobs= ctx->nb_jobs;
+unsigned nb_active_threads = ctx->nb_active_threads;
+unsigned first_job= atomic_fetch_add_explicit(>first_job, 1, 
memory_order_acq_rel);
+unsigned current_job  = first_job;
+
+do {
+ctx->worker_func(ctx->priv, current_job, first_job, nb_jobs, 
nb_active_threads);
+} while ((current_job = atomic_fetch_add_explicit(>current_job, 1, 
memory_order_acq_rel)) < nb_jobs);
+
+return current_job == nb_jobs + nb_active_threads - 1;
+}
+
+static void *attribute_align_arg thread_worker(void *v)
+{
+WorkerContext *w = v;
+AVSliceThread *ctx = w->ctx;
+
+pthread_mutex_lock(>mutex);
+pthread_cond_signal(>cond);
+
+while (1) {
+w->done = 1;
+while (w->done)
+pthread_cond_wait(>cond, >mutex);
+
+if (ctx->finished) {
+pthread_mutex_unlock(>mutex);
+return NULL;
+}
+
+if (run_jobs(ctx)) {
+pthread_mutex_lock(>done_mutex);
+ctx->done = 1;
+pthread_cond_signal(>done_cond);
+pthread_mutex_unlock(>done_mutex);
+}
+}
+}
+
+int avpriv_slicethread_create(AVSliceThread **pctx, void *priv,
+  void (*worker_func)(void *priv, int jobnr, int 
threadnr, int nb_jobs, int nb_threads),
+  void (*main_func)(void *priv),
+  int nb_threads)
+{
+AVSliceThread *ctx;
+int nb_workers, i;
+
+#if HAVE_W32THREADS
+w32thread_init();
+#endif
+
+av_assert0(nb_threads >= 0);
+if (!nb_threads) {
+int nb_cpus = av_cpu_count();
+if (nb_cpus > 1)
+nb_threads = nb_cpus + 1;
+

[FFmpeg-devel] [PATCH 3/3] avfilter/pthread: use slice threading from avutil

[Muhammad Faiz]

Benchmark (with 2 cpus):
./ffmpeg -f rawvideo -s 1280x720 -t 1000 -i /dev/zero \
-filter_threads $threads -vf transpose=clock -f null null
threads=2:
  old: 31.129s 31.446s 31.574s
  new: 29.602s 29.636s 29.656s
threads=3 (nb_threads = nb_cpus + 1 is bad choice at this situation):
  old: 40.132s 40.279s 40.279s
  new: 39.308s 39.570s 39.693s
threads=4:
  old: 31.306s 31.366s 31.654s
  new: 30.231s 30.360s 30.451s

Signed-off-by: Muhammad Faiz 
---
 libavfilter/pthread.c | 128 +-
 1 file changed, 12 insertions(+), 116 deletions(-)

diff --git a/libavfilter/pthread.c b/libavfilter/pthread.c
index c7a0021..567dd4c 100644
--- a/libavfilter/pthread.c
+++ b/libavfilter/pthread.c
@@ -27,6 +27,7 @@
 #include "libavutil/cpu.h"
 #include "libavutil/mem.h"
 #include "libavutil/thread.h"
+#include "libavutil/slicethread.h"
 
 #include "avfilter.h"
 #include "internal.h"
@@ -34,85 +35,26 @@
 
 typedef struct ThreadContext {
 AVFilterGraph *graph;
-
-int nb_threads;
-pthread_t *workers;
+AVSliceThread *thread;
 avfilter_action_func *func;
 
 /* per-execute parameters */
 AVFilterContext *ctx;
 void *arg;
 int   *rets;
-int nb_jobs;
-
-pthread_cond_t last_job_cond;
-pthread_cond_t current_job_cond;
-pthread_mutex_t current_job_lock;
-int current_job;
-unsigned int current_execute;
-int done;
 } ThreadContext;
 
-static void* attribute_align_arg worker(void *v)
+static void worker_func(void *priv, int jobnr, int threadnr, int nb_jobs, int 
nb_threads)
 {
-ThreadContext *c = v;
-int our_job  = c->nb_jobs;
-int nb_threads   = c->nb_threads;
-unsigned int last_execute = 0;
-int ret, self_id;
-
-pthread_mutex_lock(>current_job_lock);
-self_id = c->current_job++;
-
-for (;;) {
-while (our_job >= c->nb_jobs) {
-if (c->current_job == nb_threads + c->nb_jobs)
-pthread_cond_signal(>last_job_cond);
-
-while (last_execute == c->current_execute && !c->done)
-pthread_cond_wait(>current_job_cond, >current_job_lock);
-last_execute = c->current_execute;
-our_job = self_id;
-
-if (c->done) {
-pthread_mutex_unlock(>current_job_lock);
-return NULL;
-}
-}
-pthread_mutex_unlock(>current_job_lock);
-
-ret = c->func(c->ctx, c->arg, our_job, c->nb_jobs);
-if (c->rets)
-c->rets[our_job % c->nb_jobs] = ret;
-
-pthread_mutex_lock(>current_job_lock);
-our_job = c->current_job++;
-}
+ThreadContext *c = priv;
+int ret = c->func(c->ctx, c->arg, jobnr, nb_jobs);
+if (c->rets)
+c->rets[jobnr] = ret;
 }
 
 static void slice_thread_uninit(ThreadContext *c)
 {
-int i;
-
-pthread_mutex_lock(>current_job_lock);
-c->done = 1;
-pthread_cond_broadcast(>current_job_cond);
-pthread_mutex_unlock(>current_job_lock);
-
-for (i = 0; i < c->nb_threads; i++)
- pthread_join(c->workers[i], NULL);
-
-pthread_mutex_destroy(>current_job_lock);
-pthread_cond_destroy(>current_job_cond);
-pthread_cond_destroy(>last_job_cond);
-av_freep(>workers);
-}
-
-static void slice_thread_park_workers(ThreadContext *c)
-{
-while (c->current_job != c->nb_threads + c->nb_jobs)
-pthread_cond_wait(>last_job_cond, >current_job_lock);
-pthread_mutex_unlock(>current_job_lock);
+avpriv_slicethread_free(>thread);
 }
 
 static int thread_execute(AVFilterContext *ctx, avfilter_action_func *func,
@@ -122,67 +64,21 @@ static int thread_execute(AVFilterContext *ctx, 
avfilter_action_func *func,
 
 if (nb_jobs <= 0)
 return 0;
-
-pthread_mutex_lock(>current_job_lock);
-
-c->current_job = c->nb_threads;
-c->nb_jobs = nb_jobs;
 c->ctx = ctx;
 c->arg = arg;
 c->func= func;
 c->rets= ret;
-c->current_execute++;
-
-pthread_cond_broadcast(>current_job_cond);
-
-slice_thread_park_workers(c);
 
+avpriv_slicethread_execute(c->thread, nb_jobs, 0);
 return 0;
 }
 
 static int thread_init_internal(ThreadContext *c, int nb_threads)
 {
-int i, ret;
-
-if (!nb_threads) {
-int nb_cpus = av_cpu_count();
-// use number of cores + 1 as thread count if there is more than one
-if (nb_cpus > 1)
-nb_threads = nb_cpus + 1;
-else
-nb_threads = 1;
-}
-
+nb_threads = avpriv_slicethread_create(>thread, c, worker_func, NULL, 
nb_threads);
 if (nb_threads <= 1)
-return 1;
-
-c->nb_threads = nb_threads;
-c->workers = av_mallocz_array(sizeof(*c->workers), nb_threads);
-if (!c->workers)
-return AVERROR(ENOMEM);
-
-c->current_job = 0;
-c->nb_jobs = 0;
-c->done= 0;
-
-pthread_cond_init(>current_job_cond, NULL);
-pthread_cond_init(>last_job_cond,

[FFmpeg-devel] [PATCH 2/3] avcodec/pthread_slice: use slice threading from avutil

[Muhammad Faiz]

Also remove pthread_cond_broadcast(progress_cond) on uninit.
Broadcasting it is not required because workers are always
parked when they are not in thread_execute. So it is imposible
that a worker is waiting on progress_cond when uninitialized.

Benchmark:
./ffmpeg -threads $threads -thread_type slice -i 10slices.mp4 -f null null
threads=2:
  old: 70.212s 70.525s 70.877s
  new: 65.219s 65.377s 65.484s
threads=3:
  old: 65.086s 66.306s 66.409s
  new: 63.229s 65.026s 65.116s
threads=4:
  old: 60.993s 61.482s 62.123s
  new: 59.224s 59.441s 59.667s
threads=5:
  old: 57.576s 57.860s 58.832s
  new: 53.032s 53.948s 54.086s

Signed-off-by: Muhammad Faiz 
---
 libavcodec/pthread_slice.c | 122 -
 1 file changed, 20 insertions(+), 102 deletions(-)

diff --git a/libavcodec/pthread_slice.c b/libavcodec/pthread_slice.c
index 60f5b78..c781d35 100644
--- a/libavcodec/pthread_slice.c
+++ b/libavcodec/pthread_slice.c
@@ -34,26 +34,19 @@
 #include "libavutil/cpu.h"
 #include "libavutil/mem.h"
 #include "libavutil/thread.h"
+#include "libavutil/slicethread.h"
 
 typedef int (action_func)(AVCodecContext *c, void *arg);
 typedef int (action_func2)(AVCodecContext *c, void *arg, int jobnr, int 
threadnr);
 
 typedef struct SliceThreadContext {
-pthread_t *workers;
+AVSliceThread *thread;
 action_func *func;
 action_func2 *func2;
 void *args;
 int *rets;
-int job_count;
 int job_size;
 
-pthread_cond_t last_job_cond;
-pthread_cond_t current_job_cond;
-pthread_mutex_t current_job_lock;
-unsigned current_execute;
-int current_job;
-int done;
-
 int *entries;
 int entries_count;
 int thread_count;
@@ -61,43 +54,16 @@ typedef struct SliceThreadContext {
 pthread_mutex_t *progress_mutex;
 } SliceThreadContext;
 
-static void* attribute_align_arg worker(void *v)
+static void worker_func(void *priv, int jobnr, int threadnr, int nb_jobs, int 
nb_threads)
 {
-AVCodecContext *avctx = v;
+AVCodecContext *avctx = priv;
 SliceThreadContext *c = avctx->internal->thread_ctx;
-unsigned last_execute = 0;
-int our_job = c->job_count;
-int thread_count = avctx->thread_count;
-int self_id;
-
-pthread_mutex_lock(>current_job_lock);
-self_id = c->current_job++;
-for (;;){
-int ret;
-while (our_job >= c->job_count) {
-if (c->current_job == thread_count + c->job_count)
-pthread_cond_signal(>last_job_cond);
-
-while (last_execute == c->current_execute && !c->done)
-pthread_cond_wait(>current_job_cond, >current_job_lock);
-last_execute = c->current_execute;
-our_job = self_id;
-
-if (c->done) {
-pthread_mutex_unlock(>current_job_lock);
-return NULL;
-}
-}
-pthread_mutex_unlock(>current_job_lock);
+int ret;
 
-ret = c->func ? c->func(avctx, (char*)c->args + our_job*c->job_size):
-c->func2(avctx, c->args, our_job, self_id);
-if (c->rets)
-c->rets[our_job%c->job_count] = ret;
-
-pthread_mutex_lock(>current_job_lock);
-our_job = c->current_job++;
-}
+ret = c->func ? c->func(avctx, (char *)c->args + c->job_size * jobnr)
+  : c->func2(avctx, c->args, jobnr, threadnr);
+if (c->rets)
+c->rets[jobnr] = ret;
 }
 
 void ff_slice_thread_free(AVCodecContext *avctx)
@@ -105,40 +71,19 @@ void ff_slice_thread_free(AVCodecContext *avctx)
 SliceThreadContext *c = avctx->internal->thread_ctx;
 int i;
 
-pthread_mutex_lock(>current_job_lock);
-c->done = 1;
-pthread_cond_broadcast(>current_job_cond);
-for (i = 0; i < c->thread_count; i++)
-pthread_cond_broadcast(>progress_cond[i]);
-pthread_mutex_unlock(>current_job_lock);
-
-for (i=0; ithread_count; i++)
- pthread_join(c->workers[i], NULL);
+avpriv_slicethread_free(>thread);
 
 for (i = 0; i < c->thread_count; i++) {
 pthread_mutex_destroy(>progress_mutex[i]);
 pthread_cond_destroy(>progress_cond[i]);
 }
 
-pthread_mutex_destroy(>current_job_lock);
-pthread_cond_destroy(>current_job_cond);
-pthread_cond_destroy(>last_job_cond);
-
 av_freep(>entries);
 av_freep(>progress_mutex);
 av_freep(>progress_cond);
-
-av_freep(>workers);
 av_freep(>internal->thread_ctx);
 }
 
-static av_always_inline void thread_park_workers(SliceThreadContext *c, int 
thread_count)
-{
-while (c->current_job != thread_count + c->job_count)
-pthread_cond_wait(>last_job_cond, >current_job_lock);
-pthread_mutex_unlock(>current_job_lock);
-}
-
 static int thread_execute(AVCodecContext *avctx, action_func* func, void *arg, 
int *ret, int job_count, int job_size)
 {
 SliceThreadContext *c = avctx->internal->thread_ctx;
@@ -149,19 +94,12 @@ static int thread_execute(AVCodecContext 

Re: [FFmpeg-devel] [PATCH] pthread_frame: allow per-field ThreadFrame owners.

[Ronald S. Bultje]

Hi Wan-Teh,

On Tue, Jul 11, 2017 at 6:30 PM, Wan-Teh Chang  wrote:

> Hi Ronald,
>
> Thank you for the quick reply.
>
> On Tue, Jul 11, 2017 at 2:09 PM, Ronald S. Bultje 
> wrote:
> > Hi Wan-Teh,
> >
> > On Tue, Jul 11, 2017 at 4:53 PM, Wan-Teh Chang  wrote:
> >>
> >> Hi Ronald,
> >>
> >> I have a question about this patch.
> >>
> >> On Mon, Apr 3, 2017 at 7:24 AM, Ronald S. Bultje 
> >> wrote:
> [...]
> >> > diff --git a/libavcodec/utils.c b/libavcodec/utils.c
> >> > index 3e8677d..0c68836 100644
> >> > --- a/libavcodec/utils.c
> >> > +++ b/libavcodec/utils.c
> >> > @@ -3971,7 +3971,8 @@ int ff_thread_ref_frame(ThreadFrame *dst,
> >> > ThreadFrame *src)
> >> >  {
> >> >  int ret;
> >> >
> >> > -dst->owner = src->owner;
> >> > +dst->owner[0] = src->owner[0];
> >> > +dst->owner[1] = src->owner[1];
> >> >
> >> >  ret = av_frame_ref(dst->f, src->f);
> >> >  if (ret < 0)
> >> > @@ -3981,7 +3982,7 @@ int ff_thread_ref_frame(ThreadFrame *dst,
> >> > ThreadFrame *src)
> >> >
> >> >  if (src->progress &&
> >> >  !(dst->progress = av_buffer_ref(src->progress))) {
> >> > -ff_thread_release_buffer(dst->owner, dst);
> >> > +ff_thread_release_buffer(dst->owner[0], dst);
> >> >  return AVERROR(ENOMEM);
> >> >  }
> >> >
> >> [...]
> >>
> >> I don't understand why we pass dst->owner[0], not dst->owner[1], to
> >> the ff_thread_release_buffer() call. Does this assume dst->owner[0] ==
> >> dst->owner[1]?
> >
> > Neither is perfect, ideally (from an API programming PoV) you'd want to
> use
> > both. But that's not possible...
>
> Can ff_thread_release_buffer() use f->owner[0] and f->owner[1] and
> ignore the avctx argument?
>
> This should work for the ff_thread_release_buffer() call in
> ff_thread_ref_frame(), but I don't know if this is correct in general.


I guess. I'm guessing that the prototype was modeled after the
get_buffer2() (and release_buffer(), before refcounting) callback prototype
in AVCodecContext. I wouldn't object to a patch to fix that.

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

Re: [FFmpeg-devel] [PATCH 1/1] This change adds an encoder for Camera metadata motion. This is a type of sensor data associated with video, such as GPS, acceleration, gyro, and camera orientation. It

[Louis O'Bryan]

If I need to write a new atom under stsd for my stream in the mov muxer

(mov_write_stsd_tag),
is it appropriate to indicate that through the AVStream metadata rather
than the codec_tag?

On Mon, Jul 10, 2017 at 1:48 AM, wm4  wrote:

> On Fri, 7 Jul 2017 15:24:02 -0700
> "Louis O'Bryan"  wrote:
>
> > > +static av_cold int encode_init(AVCodecContext *avctx) {
> > > > +// Use dummy values for the height and width.
> > > > +avctx->width = DUMMY_ENCODER_SIZE;
> > > > +avctx->height = DUMMY_ENCODER_SIZE;
> > > > +avctx->max_pixels = DUMMY_ENCODER_SIZE;
> > > What? This makes no sense.
> >
> > Using avcodec_encode_video2() seems to require that the width and height
> be
> > nonzero. What is the recommended way to avoid that?
>
> Well, that API is for video. So I guess it's natural that it errors out
> if some basic parameters that would be necessarily always required for
> video are not set. There are other APIs for audio and subtitles. Also,
> these API functions are deprecated.
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] movenc:adds keywords metadata

[Michael Niedermayer]

On Tue, Jul 11, 2017 at 04:50:25PM +0100, Derek Buitenhuis wrote:
> On 7/10/2017 11:04 PM, Kieran O Leary wrote:
> > A user mentioned in ffmpeg-user (
> > http://ffmpeg.org/pipermail/ffmpeg-user/2017-July/036571.html)  that they
> > couldn't write the 'keywords' metadata tag. I tested this patch and it
> > appears to add the metadata value when using MOV and MP4 as output. I'm
> > sure I've messed something up so please let me know if I can improve this.
> 
> The patch itself loos OK, IMO.

+1
feel free to apply if noone else has comments


> 
> Does this change any FATE tests?

i think it does not change any


thx

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

Democracy is the form of government in which you can choose your dictator


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

Re: [FFmpeg-devel] [PATCH] pthread_frame: allow per-field ThreadFrame owners.

[Wan-Teh Chang]

Hi Ronald,

Thank you for the quick reply.

On Tue, Jul 11, 2017 at 2:09 PM, Ronald S. Bultje  wrote:
> Hi Wan-Teh,
>
> On Tue, Jul 11, 2017 at 4:53 PM, Wan-Teh Chang  wrote:
>>
>> Hi Ronald,
>>
>> I have a question about this patch.
>>
>> On Mon, Apr 3, 2017 at 7:24 AM, Ronald S. Bultje 
>> wrote:
[...]
>> > diff --git a/libavcodec/utils.c b/libavcodec/utils.c
>> > index 3e8677d..0c68836 100644
>> > --- a/libavcodec/utils.c
>> > +++ b/libavcodec/utils.c
>> > @@ -3971,7 +3971,8 @@ int ff_thread_ref_frame(ThreadFrame *dst,
>> > ThreadFrame *src)
>> >  {
>> >  int ret;
>> >
>> > -dst->owner = src->owner;
>> > +dst->owner[0] = src->owner[0];
>> > +dst->owner[1] = src->owner[1];
>> >
>> >  ret = av_frame_ref(dst->f, src->f);
>> >  if (ret < 0)
>> > @@ -3981,7 +3982,7 @@ int ff_thread_ref_frame(ThreadFrame *dst,
>> > ThreadFrame *src)
>> >
>> >  if (src->progress &&
>> >  !(dst->progress = av_buffer_ref(src->progress))) {
>> > -ff_thread_release_buffer(dst->owner, dst);
>> > +ff_thread_release_buffer(dst->owner[0], dst);
>> >  return AVERROR(ENOMEM);
>> >  }
>> >
>> [...]
>>
>> I don't understand why we pass dst->owner[0], not dst->owner[1], to
>> the ff_thread_release_buffer() call. Does this assume dst->owner[0] ==
>> dst->owner[1]?
>
> Neither is perfect, ideally (from an API programming PoV) you'd want to use
> both. But that's not possible...

Can ff_thread_release_buffer() use f->owner[0] and f->owner[1] and
ignore the avctx argument?

This should work for the ff_thread_release_buffer() call in
ff_thread_ref_frame(), but I don't know if this is correct in general.

> In practice, I don't think it matters much,
> since all it does is decide which release_buffer-queue it'll be appended to
> (if we do delayed free()'ing). Are there problems with this?

No, there aren't. With your explanation, I roughly understand the
ff_thread_release_buffer() code now. Thanks.

Note: I am cherry-picking tsan warning fixes to our copy of ffmpeg,
which is several months behind the tip. As due diligence, I review the
fixes before I merge them.

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

Re: [FFmpeg-devel] [PATCH] avcodec/htmlsubtitles: Be a bit more picky on syntax

[Michael Niedermayer]

On Sun, Jul 09, 2017 at 02:28:28PM +0200, Clément Bœsch wrote:
> On Sat, Jul 08, 2017 at 11:07:48PM +0200, Michael Niedermayer wrote:
> [...]
> > 5 days passed with no comments and no suggestions on how to implement
> > this better.
> > does anyone object to the fix as in the patch to be applied ?
> 
> misc patterns I found you may want to give a try (note that these are
> completely broken garbage you may want to ignore):
> 
> 82
> 00:04:50,430 --> 00:05:01,030
> < pisode 4
> saison 1>
> www.SeriesSub.com>
> 
> 
> 57
> 00:03:38,318 --> 00:03:42,778
> <>
> <>
> 
> 
> 2
> 00:01:10,000 --> 00:01:14,500
> >>> RebelSubTeam <<<
> 
> 
> 306
> 00:20:31,849 --> 00:20:56,839
> 
> <<<>>>
> 
> 
> 37
> 00:02:37,750 --> 00:02:43,700
> ~ASUKO MARCH!~
> >>:<<
> translation by: cangii
> Retiming by: furransu
> 
> 
> 1214
> 02:11:00,738 --> 02:11:05,538
> <<< ÓÍÀÊÑ ÒÈÉÌ < 2015 > UNACS TEAM >>>
> 
> 
> 1
> 00:00:01,000 --> 00:00:02,308
> << Antes <<
> Ela é hum...
> 
> 
> 544
> 00:53:43,780 --> 00:53:45,941
> <> - he calmed himself.
> 
> 
> 545
> 00:53:46,216 --> 00:53:49,083
> < the hotel is within easy reach.
> 
> 
> 894
> 00:37:59,693 --> 00:38:01,591
> mint asztalt foglaltatni
> a <<>Le Cirque-ben.
> 
> 
> I really have a LOT of matches, so these are very common patterns.
> 
> Feel free to apply your patch if it generally doesn't make these cases
> worse.

patch posted that adds this to fate
ill upload the srt file (copy and paste of above)

the patch seems not to change the output for this
i will apply the fate test before the patch here

[...]

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

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


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

[FFmpeg-devel] [PATCH] fate: add sub-srt-badsyntax test

[Michael Niedermayer]

Based-on: srt sample by ubitux

Signed-off-by: Michael Niedermayer 
---
 tests/fate/subtitles.mak |  3 +++
 tests/ref/fate/sub-srt-badsyntax | 22 ++
 2 files changed, 25 insertions(+)
 create mode 100644 tests/ref/fate/sub-srt-badsyntax

diff --git a/tests/fate/subtitles.mak b/tests/fate/subtitles.mak
index 11cbb82b24..8c310adeff 100644
--- a/tests/fate/subtitles.mak
+++ b/tests/fate/subtitles.mak
@@ -55,6 +55,9 @@ fate-sub-sami2: CMD = fmtstdout ass -i 
$(TARGET_SAMPLES)/sub/SAMI_multilang_twea
 FATE_SUBTITLES_ASS-$(call DEMDEC, SRT, SUBRIP) += fate-sub-srt
 fate-sub-srt: CMD = fmtstdout ass -i 
$(TARGET_SAMPLES)/sub/SubRip_capability_tester.srt
 
+FATE_SUBTITLES_ASS-$(call DEMDEC, SRT, SUBRIP) += fate-sub-srt-badsyntax
+fate-sub-srt-badsyntax: CMD = fmtstdout ass -i 
$(TARGET_SAMPLES)/sub/badsyntax.srt
+
 FATE_SUBTITLES-$(call ALLYES, SRT_DEMUXER SUBRIP_DECODER SRT_MUXER) += 
fate-sub-srt-rrn-remux
 fate-sub-srt-rrn-remux: CMD = fmtstdout srt -i 
$(TARGET_SAMPLES)/sub/ticket5032-rrn.srt -c:s copy
 
diff --git a/tests/ref/fate/sub-srt-badsyntax b/tests/ref/fate/sub-srt-badsyntax
new file mode 100644
index 00..1ee2f95dcc
--- /dev/null
+++ b/tests/ref/fate/sub-srt-badsyntax
@@ -0,0 +1,22 @@
+[Script Info]
+; Script generated by FFmpeg/Lavc
+ScriptType: v4.00+
+PlayResX: 384
+PlayResY: 288
+
+[V4+ Styles]
+Format: Name, Fontname, Fontsize, PrimaryColour, SecondaryColour, 
OutlineColour, BackColour, Bold, Italic, Underline, StrikeOut, ScaleX, ScaleY, 
Spacing, Angle, BorderStyle, Outline, Shadow, Alignment, MarginL, MarginR, 
MarginV, Encoding
+Style: 
Default,Arial,16,0,0,0,0,100,100,0,0,1,1,0,2,10,10,10,0
+
+[Events]
+Format: Layer, Start, End, Style, Name, MarginL, MarginR, MarginV, Effect, Text
+Dialogue: 0,0:00:01.00,0:00:02.31,Default,,0,0,0,,<< Antes <<\NEla é 
hum...
+Dialogue: 0,0:01:10.00,0:01:14.50,Default,,0,0,0,,>>> RebelSubTeam <<<
+Dialogue: 0,0:02:37.75,0:02:43.70,Default,,0,0,0,,{\b1}~ASUKO 
MARCH!~\N>>:<<\Ntranslation by: cangii\NRetiming by: furransu{\b0}
+Dialogue: 0,0:03:38.32,0:03:42.78,Default,,0,0,0,,<>\N<>
+Dialogue: 0,0:04:50.43,0:05:01.03,Default,,0,0,0,,\Nwww.SeriesSub.com>
+Dialogue: 
0,0:20:31.85,0:20:56.84,Default,,0,0,0,,{\c&}\N<<<>>>{\c}
+Dialogue: 0,0:37:59.69,0:38:01.59,Default,,0,0,0,,mint asztalt foglaltatni\Na 
<<>Le Cirque-ben.
+Dialogue: 0,0:53:43.78,0:53:45.94,Default,,0,0,0,,<> - he calmed 
himself.
+Dialogue: 0,0:53:46.22,0:53:49.09,Default,,0,0,0,,< 
UNACS TEAM >>>{\b0}
-- 
2.13.0

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

Re: [FFmpeg-devel] [PATCH] pthread_frame: allow per-field ThreadFrame owners.

[Ronald S. Bultje]

Hi Wan-Teh,

On Tue, Jul 11, 2017 at 4:53 PM, Wan-Teh Chang  wrote:

> Hi Ronald,
>
> I have a question about this patch.
>
> On Mon, Apr 3, 2017 at 7:24 AM, Ronald S. Bultje 
> wrote:
> > This tries to handle cases where separate invocations of decode_frame()
> > (each running in separate threads) write to respective fields in the
> > same AVFrame->data[]. Having per-field owners makes interaction between
> > readers (the referencing thread) and writers (the decoding thread)
> > slightly more optimal if both accesses are field-based, since they will
> > use the respective producer's thread objects (mutex/cond) instead of
> > sharing the thread objects of the first field's producer.
> >
> > In practice, this fixes the following tsan-warning in fate-h264:
> >
> > WARNING: ThreadSanitizer: data race (pid=21615)
> >   Read of size 4 at 0x7d64d9fc by thread T2 (mutexes: write M1006):
> > #0 ff_thread_report_progress pthread_frame.c:569
> (ffmpeg:x86_64+0x100f7cf54)
> > [..]
> >   Previous write of size 4 at 0x7d64d9fc by main thread (mutexes:
> write M1004):
> > #0 update_context_from_user pthread_frame.c:335
> (ffmpeg:x86_64+0x100f81abb)
> > ---
> >  libavcodec/h264_slice.c|  8 +---
> >  libavcodec/pthread_frame.c | 18 ++
> >  libavcodec/thread.h|  2 +-
> >  libavcodec/utils.c |  7 ---
> >  4 files changed, 20 insertions(+), 15 deletions(-)
> >
> > diff --git a/libavcodec/h264_slice.c b/libavcodec/h264_slice.c
> > index fa1e9ae..d4d31cc 100644
> > --- a/libavcodec/h264_slice.c
> > +++ b/libavcodec/h264_slice.c
> > @@ -1423,14 +1423,14 @@ static int h264_field_start(H264Context *h,
> const H264SliceContext *sl,
> >   * We have to do that before the "dummy" in-between frame
> allocation,
> >   * since that can modify h->cur_pic_ptr. */
> >  if (h->first_field) {
> > +int last_field = last_pic_structure == PICT_BOTTOM_FIELD;
> >  av_assert0(h->cur_pic_ptr);
> >  av_assert0(h->cur_pic_ptr->f->buf[0]);
> >  assert(h->cur_pic_ptr->reference != DELAYED_PIC_REF);
> >
> >  /* Mark old field/frame as completed */
> > -if (h->cur_pic_ptr->tf.owner == h->avctx) {
> > -ff_thread_report_progress(>cur_pic_ptr->tf, INT_MAX,
> > -  last_pic_structure ==
> PICT_BOTTOM_FIELD);
> > +if (h->cur_pic_ptr->tf.owner[last_field] == h->avctx) {
> > +ff_thread_report_progress(>cur_pic_ptr->tf, INT_MAX,
> last_field);
> >  }
> >
> >  /* figure out if we have a complementary field pair */
> > @@ -1568,7 +1568,9 @@ static int h264_field_start(H264Context *h, const
> H264SliceContext *sl,
> >  return AVERROR_INVALIDDATA;
> >  }
> >  } else {
> > +int field = h->picture_structure == PICT_BOTTOM_FIELD;
> >  release_unused_pictures(h, 0);
> > +h->cur_pic_ptr->tf.owner[field] = h->avctx;
> >  }
> >  /* Some macroblocks can be accessed before they're available in case
> >  * of lost slices, MBAFF or threading. */
>
> Note: I have to admit I don't understand the changes to
> libavcodec/h264_slice.c. The changes to the other files are
> straightforward, except for the one issue I ask about below.
>
> > diff --git a/libavcodec/utils.c b/libavcodec/utils.c
> > index 3e8677d..0c68836 100644
> > --- a/libavcodec/utils.c
> > +++ b/libavcodec/utils.c
> > @@ -3971,7 +3971,8 @@ int ff_thread_ref_frame(ThreadFrame *dst,
> ThreadFrame *src)
> >  {
> >  int ret;
> >
> > -dst->owner = src->owner;
> > +dst->owner[0] = src->owner[0];
> > +dst->owner[1] = src->owner[1];
> >
> >  ret = av_frame_ref(dst->f, src->f);
> >  if (ret < 0)
> > @@ -3981,7 +3982,7 @@ int ff_thread_ref_frame(ThreadFrame *dst,
> ThreadFrame *src)
> >
> >  if (src->progress &&
> >  !(dst->progress = av_buffer_ref(src->progress))) {
> > -ff_thread_release_buffer(dst->owner, dst);
> > +ff_thread_release_buffer(dst->owner[0], dst);
> >  return AVERROR(ENOMEM);
> >  }
> >
> [...]
>
> I don't understand why we pass dst->owner[0], not dst->owner[1], to
> the ff_thread_release_buffer() call. Does this assume dst->owner[0] ==
> dst->owner[1]?
>

Neither is perfect, ideally (from an API programming PoV) you'd want to use
both. But that's not possible... In practice, I don't think it matters
much, since all it does is decide which release_buffer-queue it'll be
appended to (if we do delayed free()'ing). Are there problems with this?

Although dst->owner[0] and dst->owner[1] are initialized to the same
> value, the changes to libavcodec/h264_slice.c seem to imply
> dst->owner[0] and dst->owner[1] may become different.


Right, if each slice is decoded in a separate (frame-)worker thread, then
they will be different.

Ronald
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org

Re: [FFmpeg-devel] [PATCH] configure: use pkg-config for libgme, if available

[Ricardo Constantino]

On 6 July 2017 at 23:16, Ricardo Constantino  wrote:
> On 23 June 2017 at 17:08, wm4  wrote:
>> On Fri, 23 Jun 2017 01:53:37 +0100
>> Ricardo Constantino  wrote:
>>
>>> The pkg-config file is relatively new (2013), so some distros might
>>> not have it yet. And the -lstdc++ being required for the static lib
>>> is only present since the last release in December 2016.
>>> ---
>>>  configure | 3 ++-
>>>  1 file changed, 2 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/configure b/configure
>>> index dd9608540e..74f8ba4c57 100755
>>> --- a/configure
>>> +++ b/configure
>>> @@ -5826,7 +5826,8 @@ enabled fontconfig&& enable libfontconfig
>>>  enabled libfontconfig && require_pkg_config fontconfig 
>>> "fontconfig/fontconfig.h" FcInit
>>>  enabled libfreetype   && require_pkg_config freetype2 "ft2build.h 
>>> FT_FREETYPE_H" FT_Init_FreeType
>>>  enabled libfribidi&& require_pkg_config fribidi fribidi.h 
>>> fribidi_version_info
>>> -enabled libgme&& require  libgme gme/gme.h gme_new_emu -lgme 
>>> -lstdc++
>>> +enabled libgme&& { use_pkg_config libgme gme/gme.h gme_new_emu 
>>> ||
>>> +   require libgme gme/gme.h gme_new_emu -lgme 
>>> -lstdc++; }
>>>  enabled libgsm&& { for gsm_hdr in "gsm.h" "gsm/gsm.h"; do
>>> check_lib libgsm "${gsm_hdr}" 
>>> gsm_create -lgsm && break;
>>> done || die "ERROR: libgsm not found"; }
>>
>> The first patch without the fallback has my blessing.
>
> Pinging this one because some distros (Ubuntu at least) don't have 0.6.1 yet.

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

Re: [FFmpeg-devel] [PATCH] pthread_frame: allow per-field ThreadFrame owners.

[Wan-Teh Chang]

Hi Ronald,

I have a question about this patch.

On Mon, Apr 3, 2017 at 7:24 AM, Ronald S. Bultje  wrote:
> This tries to handle cases where separate invocations of decode_frame()
> (each running in separate threads) write to respective fields in the
> same AVFrame->data[]. Having per-field owners makes interaction between
> readers (the referencing thread) and writers (the decoding thread)
> slightly more optimal if both accesses are field-based, since they will
> use the respective producer's thread objects (mutex/cond) instead of
> sharing the thread objects of the first field's producer.
>
> In practice, this fixes the following tsan-warning in fate-h264:
>
> WARNING: ThreadSanitizer: data race (pid=21615)
>   Read of size 4 at 0x7d64d9fc by thread T2 (mutexes: write M1006):
> #0 ff_thread_report_progress pthread_frame.c:569 
> (ffmpeg:x86_64+0x100f7cf54)
> [..]
>   Previous write of size 4 at 0x7d64d9fc by main thread (mutexes: write 
> M1004):
> #0 update_context_from_user pthread_frame.c:335 
> (ffmpeg:x86_64+0x100f81abb)
> ---
>  libavcodec/h264_slice.c|  8 +---
>  libavcodec/pthread_frame.c | 18 ++
>  libavcodec/thread.h|  2 +-
>  libavcodec/utils.c |  7 ---
>  4 files changed, 20 insertions(+), 15 deletions(-)
>
> diff --git a/libavcodec/h264_slice.c b/libavcodec/h264_slice.c
> index fa1e9ae..d4d31cc 100644
> --- a/libavcodec/h264_slice.c
> +++ b/libavcodec/h264_slice.c
> @@ -1423,14 +1423,14 @@ static int h264_field_start(H264Context *h, const 
> H264SliceContext *sl,
>   * We have to do that before the "dummy" in-between frame allocation,
>   * since that can modify h->cur_pic_ptr. */
>  if (h->first_field) {
> +int last_field = last_pic_structure == PICT_BOTTOM_FIELD;
>  av_assert0(h->cur_pic_ptr);
>  av_assert0(h->cur_pic_ptr->f->buf[0]);
>  assert(h->cur_pic_ptr->reference != DELAYED_PIC_REF);
>
>  /* Mark old field/frame as completed */
> -if (h->cur_pic_ptr->tf.owner == h->avctx) {
> -ff_thread_report_progress(>cur_pic_ptr->tf, INT_MAX,
> -  last_pic_structure == 
> PICT_BOTTOM_FIELD);
> +if (h->cur_pic_ptr->tf.owner[last_field] == h->avctx) {
> +ff_thread_report_progress(>cur_pic_ptr->tf, INT_MAX, 
> last_field);
>  }
>
>  /* figure out if we have a complementary field pair */
> @@ -1568,7 +1568,9 @@ static int h264_field_start(H264Context *h, const 
> H264SliceContext *sl,
>  return AVERROR_INVALIDDATA;
>  }
>  } else {
> +int field = h->picture_structure == PICT_BOTTOM_FIELD;
>  release_unused_pictures(h, 0);
> +h->cur_pic_ptr->tf.owner[field] = h->avctx;
>  }
>  /* Some macroblocks can be accessed before they're available in case
>  * of lost slices, MBAFF or threading. */

Note: I have to admit I don't understand the changes to
libavcodec/h264_slice.c. The changes to the other files are
straightforward, except for the one issue I ask about below.

> diff --git a/libavcodec/utils.c b/libavcodec/utils.c
> index 3e8677d..0c68836 100644
> --- a/libavcodec/utils.c
> +++ b/libavcodec/utils.c
> @@ -3971,7 +3971,8 @@ int ff_thread_ref_frame(ThreadFrame *dst, ThreadFrame 
> *src)
>  {
>  int ret;
>
> -dst->owner = src->owner;
> +dst->owner[0] = src->owner[0];
> +dst->owner[1] = src->owner[1];
>
>  ret = av_frame_ref(dst->f, src->f);
>  if (ret < 0)
> @@ -3981,7 +3982,7 @@ int ff_thread_ref_frame(ThreadFrame *dst, ThreadFrame 
> *src)
>
>  if (src->progress &&
>  !(dst->progress = av_buffer_ref(src->progress))) {
> -ff_thread_release_buffer(dst->owner, dst);
> +ff_thread_release_buffer(dst->owner[0], dst);
>  return AVERROR(ENOMEM);
>  }
>
[...]

I don't understand why we pass dst->owner[0], not dst->owner[1], to
the ff_thread_release_buffer() call. Does this assume dst->owner[0] ==
dst->owner[1]?

Although dst->owner[0] and dst->owner[1] are initialized to the same
value, the changes to libavcodec/h264_slice.c seem to imply
dst->owner[0] and dst->owner[1] may become different.

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

Re: [FFmpeg-devel] [PATCH 1/3] avcodec/aacdec_template: Fix undefined integer overflow in apply_tns()

[Michael Niedermayer]

On Sun, Jul 02, 2017 at 01:33:16PM +0200, Michael Niedermayer wrote:
> On Sun, Jul 02, 2017 at 01:14:31PM +0200, wm4 wrote:
> > On Sun,  2 Jul 2017 04:28:54 +0200
> > Michael Niedermayer  wrote:
> > 
> > > Fixes: runtime error: signed integer overflow: -2147483648 - 1202286525 
> > > cannot be represented in type 'int'
> > > Fixes: 2071/clusterfuzz-testcase-minimized-6036414271586304
> > > 
> > > Found-by: continuous fuzzing process 
> > > https://github.com/google/oss-fuzz/tree/master/projects/ffmpeg
> > > Signed-off-by: Michael Niedermayer 
> > > ---
> > >  libavcodec/aac_defines.h | 2 ++
> > >  libavcodec/aacdec_template.c | 5 +++--
> > >  2 files changed, 5 insertions(+), 2 deletions(-)
> > > 
> > > diff --git a/libavcodec/aac_defines.h b/libavcodec/aac_defines.h
> > > index 3c79a8a4a1..ee4c73a87d 100644
> > > --- a/libavcodec/aac_defines.h
> > > +++ b/libavcodec/aac_defines.h
> > > @@ -35,6 +35,7 @@
> > >  #define AAC_RENAME(x)   x ## _fixed
> > >  #define AAC_RENAME_32(x)x ## _fixed_32
> > >  typedef int INTFLOAT;
> > > +typedef unsignedSUINTFLOAT;
> > >  typedef int64_t INT64FLOAT;
> > >  typedef int16_t SHORTFLOAT;
> > >  typedef SoftFloat   AAC_FLOAT;
> > > @@ -83,6 +84,7 @@ typedef int AAC_SIGNE;
> > >  #define AAC_RENAME(x)   x
> > >  #define AAC_RENAME_32(x)x
> > >  typedef float   INTFLOAT;
> > > +typedef float   SUINTFLOAT;
> > 
> > Not more of this damn shit.
> 
> i dont think i understand your comment
> 
> The code is templated and uses largely the INTFLOAT data type
> which is either signed int or float depending on if the code is build
> for the fixed point or floating point decoder
> 
> to fix the undefined behavior in the fixed point decoder a type which
> is unsigned int is the obvious choice.
> Such type must be float in the floating point decoder.
> 
> This patch adds such type.
> 
> do you object to fixing the issue ?
> do you want to suggest a different solution ?

over a week passed, noone replied.
Is everyone ok with patch 1/3 ?
does someone object to it ?
does anyone have a better solution ?

If noone replies, i will apply this patch, i do not want to leave
undefined behavior in the codebase.

Thanks

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

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


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

Re: [FFmpeg-devel] [PATCH] lavfi/buffersrc: push the frame deeper if requested.

[Paul B Mahol]

On 7/11/17, Nicolas George  wrote:
> Le tridi 23 messidor, an CCXXV, Paul B Mahol a ecrit :
>> Nothing can get rid of that issue, except tootal lavfi rewrite.
>
> Why do you say that? My plan gets rid of them quite easily, since now
> all links have a dynamically-sized FIFO built-in.
>
>> I tried this and it did not work at all. And I even contacted Nicolas
>> privately and never got reply.
>
> I found your mail in my inbox, and I vaguely remember reading them at
> the time, but no more. It was a very busy week. Sorry for missing them.
>
> Unfortunately, you neglected to include your code, so I cannot tell why
> it did not work.

You never asked for one.

Here it is attached just for you.
From 20d00cead1e47b2e389fde99a3c0f9c36b6587ec Mon Sep 17 00:00:00 2001
From: Paul B Mahol 
Date: Tue, 20 Jun 2017 19:44:54 +0200
Subject: [PATCH] shit

Signed-off-by: Paul B Mahol 
---
 libavfilter/framesync.c | 47 +++
 libavfilter/framesync.h |  4 
 libavfilter/vf_stack.c  |  9 -
 3 files changed, 55 insertions(+), 5 deletions(-)

diff --git a/libavfilter/framesync.c b/libavfilter/framesync.c
index eb05d66..f2a4450 100644
--- a/libavfilter/framesync.c
+++ b/libavfilter/framesync.c
@@ -23,6 +23,7 @@
 
 #include "libavutil/avassert.h"
 #include "avfilter.h"
+#include "filters.h"
 #include "bufferqueue.h"
 #include "framesync.h"
 #include "internal.h"
@@ -224,6 +225,22 @@ void ff_framesync_next(FFFrameSync *fs)
 framesync_advance(fs);
 }
 
+void ff_framesync_next2(FFFrameSync *fs)
+{
+AVFilterContext *ctx = fs->parent;
+unsigned i;
+
+av_assert0(!fs->frame_ready);
+for (i = 0; i < fs->nb_in; i++)
+if (!fs->in[i].have_next && ff_framequeue_queued_frames(>inputs[i]->fifo)) {
+framesync_inject_frame(fs, i, ff_framequeue_take(>inputs[i]->fifo));
+ctx->inputs[i]->frame_wanted_out = 1;
+ff_filter_set_ready(ctx->inputs[i]->src, 100);
+}
+fs->frame_ready = 0;
+framesync_advance(fs);
+}
+
 void ff_framesync_drop(FFFrameSync *fs)
 {
 fs->frame_ready = 0;
@@ -300,6 +317,27 @@ int ff_framesync_process_frame(FFFrameSync *fs, unsigned all)
 return count;
 }
 
+int ff_framesync_process_frame2(FFFrameSync *fs, unsigned all)
+{
+int ret, count = 0;
+
+av_assert0(fs->on_event);
+while (1) {
+ff_framesync_next2(fs);
+if (fs->eof || !fs->frame_ready)
+break;
+if ((ret = fs->on_event(fs)) < 0)
+return ret;
+ff_framesync_drop(fs);
+count++;
+if (!all)
+break;
+}
+if (!count && fs->eof)
+return AVERROR_EOF;
+return count;
+}
+
 int ff_framesync_filter_frame(FFFrameSync *fs, AVFilterLink *inlink,
   AVFrame *in)
 {
@@ -314,6 +352,15 @@ int ff_framesync_filter_frame(FFFrameSync *fs, AVFilterLink *inlink,
 return 0;
 }
 
+int ff_framesync_activate(FFFrameSync *fs, AVFilterContext *ctx)
+{
+int ret;
+
+if ((ret = ff_framesync_process_frame2(fs, 1)) < 0)
+return ret;
+return 0;
+}
+
 int ff_framesync_request_frame(FFFrameSync *fs, AVFilterLink *outlink)
 {
 AVFilterContext *ctx = outlink->src;
diff --git a/libavfilter/framesync.h b/libavfilter/framesync.h
index 7ba99d5..0f381e3 100644
--- a/libavfilter/framesync.h
+++ b/libavfilter/framesync.h
@@ -250,6 +250,7 @@ int ff_framesync_add_frame(FFFrameSync *fs, unsigned in, AVFrame *frame);
  * The status of the operation can be found in fs->frame_ready and fs->eof.
  */
 void ff_framesync_next(FFFrameSync *fs);
+void ff_framesync_next2(FFFrameSync *fs);
 
 /**
  * Drop the current frame event.
@@ -275,6 +276,7 @@ int ff_framesync_get_frame(FFFrameSync *fs, unsigned in, AVFrame **rframe,
  * @return  number of frames processed or negative error code
  */
 int ff_framesync_process_frame(FFFrameSync *fs, unsigned all);
+int ff_framesync_process_frame2(FFFrameSync *fs, unsigned all);
 
 
 /**
@@ -286,6 +288,8 @@ int ff_framesync_process_frame(FFFrameSync *fs, unsigned all);
 int ff_framesync_filter_frame(FFFrameSync *fs, AVFilterLink *inlink,
   AVFrame *in);
 
+int ff_framesync_activate(FFFrameSync *fs, AVFilterContext *ctx);
+
 /**
  * Request a frame on the filter output.
  *
diff --git a/libavfilter/vf_stack.c b/libavfilter/vf_stack.c
index 03643b6..0e45952 100644
--- a/libavfilter/vf_stack.c
+++ b/libavfilter/vf_stack.c
@@ -58,10 +58,10 @@ static int query_formats(AVFilterContext *ctx)
 return ff_set_common_formats(ctx, pix_fmts);
 }
 
-static int filter_frame(AVFilterLink *inlink, AVFrame *in)
+static int activate(AVFilterContext *ctx)
 {
-StackContext *s = inlink->dst->priv;
-return ff_framesync_filter_frame(>fs, inlink, in);
+StackContext *s = ctx->priv;
+return ff_framesync_activate(>fs, ctx);
 }
 
 static av_cold int init(AVFilterContext *ctx)
@@ -83,7 +83,6 @@ static av_cold int 

Re: [FFmpeg-devel] [PATCH] lavfi/buffersrc: push the frame deeper if requested.

[Nicolas George]

Le tridi 23 messidor, an CCXXV, Paul B Mahol a écrit :
> Nothing can get rid of that issue, except tootal lavfi rewrite.

Why do you say that? My plan gets rid of them quite easily, since now
all links have a dynamically-sized FIFO built-in.

> I tried this and it did not work at all. And I even contacted Nicolas
> privately and never got reply.

I found your mail in my inbox, and I vaguely remember reading them at
the time, but no more. It was a very busy week. Sorry for missing them.

Unfortunately, you neglected to include your code, so I cannot tell why
it did not work.

Regards,

-- 
  Nicolas George


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

[FFmpeg-devel] [PATCH 1/3] avcodec/get_bits: add cached bitstream reader

[Paul B Mahol]

Signed-off-by: Paul B Mahol 
---
 libavcodec/get_bits.h | 263 +-
 1 file changed, 237 insertions(+), 26 deletions(-)

diff --git a/libavcodec/get_bits.h b/libavcodec/get_bits.h
index c530015..dbacdda 100644
--- a/libavcodec/get_bits.h
+++ b/libavcodec/get_bits.h
@@ -1,5 +1,6 @@
 /*
- * copyright (c) 2004 Michael Niedermayer 
+ * Copyright (c) 2004 Michael Niedermayer 
+ * Copyright (c) 2016 Alexandra Hájková
  *
  * This file is part of FFmpeg.
  *
@@ -54,6 +55,10 @@
 
 typedef struct GetBitContext {
 const uint8_t *buffer, *buffer_end;
+#ifdef CACHED_BITSTREAM_READER
+uint64_t cache;
+unsigned bits_left;
+#endif
 int index;
 int size_in_bits;
 int size_in_bits_plus8;
@@ -106,12 +111,16 @@ typedef struct GetBitContext {
  * For examples see get_bits, show_bits, skip_bits, get_vlc.
  */
 
-#ifdef LONG_BITSTREAM_READER
+#ifdef CACHED_BITSTREAM_READER
+#   define MIN_CACHE_BITS 64
+#elif defined LONG_BITSTREAM_READER
 #   define MIN_CACHE_BITS 32
 #else
 #   define MIN_CACHE_BITS 25
 #endif
 
+#ifndef CACHED_BITSTREAM_READER
+
 #define OPEN_READER_NOSIZE(name, gb)\
 unsigned int name ## _index = (gb)->index;  \
 unsigned int av_unused name ## _cache
@@ -196,20 +205,113 @@ typedef struct GetBitContext {
 
 #define GET_CACHE(name, gb) ((uint32_t) name ## _cache)
 
+#endif
+
 static inline int get_bits_count(const GetBitContext *s)
 {
+#ifdef CACHED_BITSTREAM_READER
+return s->index - s->bits_left;
+#else
 return s->index;
+#endif
 }
 
-static inline void skip_bits_long(GetBitContext *s, int n)
+static inline void refill_32(GetBitContext *s)
 {
-#if UNCHECKED_BITSTREAM_READER
-s->index += n;
+#ifdef CACHED_BITSTREAM_READER
+#if !UNCHECKED_BITSTREAM_READER
+if (s->index >> 3 >= s->buffer_end - s->buffer)
+return;
+#endif
+
+#ifdef BITSTREAM_READER_LE
+s->cache   = (uint64_t)AV_RL32(s->buffer + (s->index >> 3)) << 
s->bits_left | s->cache;
 #else
-s->index += av_clip(n, -s->index, s->size_in_bits_plus8 - s->index);
+s->cache   = s->cache | (uint64_t)AV_RB32(s->buffer + (s->index >> 3)) 
<< (32 - s->bits_left);
+#endif
+s->index += 32;
+s->bits_left += 32;
+#endif
+}
+
+static inline void refill_64(GetBitContext *s)
+{
+#ifdef CACHED_BITSTREAM_READER
+#if !UNCHECKED_BITSTREAM_READER
+if (s->index >> 3 >= s->buffer_end - s->buffer)
+return;
+#endif
+
+#ifdef BITSTREAM_READER_LE
+s->cache = AV_RL64(s->buffer + (s->index >> 3));
+#else
+s->cache = AV_RB64(s->buffer + (s->index >> 3));
+#endif
+s->index += 64;
+s->bits_left = 64;
+#endif
+}
+
+#ifdef CACHED_BITSTREAM_READER
+static inline uint64_t get_val(GetBitContext *s, unsigned n)
+{
+uint64_t ret;
+av_assert2(n>0 && n<=63);
+#ifdef BITSTREAM_READER_LE
+ret = s->cache & ((UINT64_C(1) << n) - 1);
+s->cache >>= n;
+#else
+ret = s->cache >> (64 - n);
+s->cache <<= n;
+#endif
+s->bits_left -= n;
+return ret;
+}
+#endif
+
+#ifdef CACHED_BITSTREAM_READER
+static inline unsigned show_val(const GetBitContext *s, unsigned n)
+{
+#ifdef BITSTREAM_READER_LE
+return s->cache & ((UINT64_C(1) << n) - 1);
+#else
+return s->cache >> (64 - n);
+#endif
+}
+#endif
+
+/**
+ * Show 1-25 bits.
+ */
+static inline unsigned int show_bits(GetBitContext *s, int n)
+{
+register int tmp;
+#ifdef CACHED_BITSTREAM_READER
+if (n > s->bits_left)
+refill_32(s);
+
+tmp = show_val(s, n);
+#else
+OPEN_READER_NOSIZE(re, s);
+av_assert2(n>0 && n<=25);
+UPDATE_CACHE(re, s);
+tmp = SHOW_UBITS(re, s, n);
 #endif
+return tmp;
 }
 
+#ifdef CACHED_BITSTREAM_READER
+static inline void skip_remaining(GetBitContext *s, unsigned n)
+{
+#ifdef BITSTREAM_READER_LE
+s->cache >>= n;
+#else
+s->cache <<= n;
+#endif
+s->bits_left -= n;
+}
+#endif
+
 /**
  * Read MPEG-1 dc-style VLC (sign bit + mantissa with no MSB).
  * if MSB not set it is negative
@@ -217,6 +319,13 @@ static inline void skip_bits_long(GetBitContext *s, int n)
  */
 static inline int get_xbits(GetBitContext *s, int n)
 {
+#ifdef CACHED_BITSTREAM_READER
+int32_t cache = show_bits(s, 32);
+int sign = ~cache >> 31;
+skip_remaining(s, n);
+
+return uint32_t)(sign ^ cache)) >> (32 - n)) ^ sign) - sign;
+#else
 register int sign;
 register int32_t cache;
 OPEN_READER(re, s);
@@ -227,8 +336,10 @@ static inline int get_xbits(GetBitContext *s, int n)
 LAST_SKIP_BITS(re, s, n);
 CLOSE_READER(re, s);
 return (NEG_USR32(sign ^ cache, n) ^ sign) - sign;
+#endif
 }
 
+#ifndef CACHED_BITSTREAM_READER
 static inline int get_xbits_le(GetBitContext *s, int n)
 {
 register int sign;
@@ -242,31 +353,61 @@ static inline int get_xbits_le(GetBitContext *s, int n)
 CLOSE_READER(re, s);
 return (zero_extend(sign ^ cache, n) ^ sign) - sign;
 }
+#endif
 
-static inline int get_sbits(GetBitContext *s, int 

Re: [FFmpeg-devel] [PATCH] lavfi/buffersrc: push the frame deeper if requested.

[Paul B Mahol]

On 7/11/17, Nicolas George  wrote:
> Le primidi 21 messidor, an CCXXV, Marton Balint a ecrit :
>> I am not saying they aren't, I'm just showing a case where your revert is
>> breaking another case which was working before. Nicolas also stated there
>> can be cases where the old code (before the revert) worked better. I just
>> hope that I found a simple enough case, so somebody can take a look and
>> find
>> the root cause.
>
> Thanks for stepping in. I will try to dot the `i's in this issue.
>
> From the start, libavfilter has had subtle issues in corner cases. These
> issue reside primarily with filters with several inputs and the handling
> of EOF. We all tried to get rid of them, but soon realized they are like
> lamination bubbles: once you think you are rid of one, another pops up a
> few centimeters away, the only solution is to redo almost the whole
> thing.
>
> I have been doing just that for libavfilter. And since doing it all at
> once is not an option, I have been doing it step by step. The
> consequence is that there is a large stitch between the new and the old
> code, that may be as annoying as the bubbles, and even more so when the
> stitch approaches areas where there are bubbles.
>
> Dropping the metaphor: I have been reworking the scheduling of
> libavfilter to get filter with multiple inputs and EOF working, but
> look, I don't mean to be rude, but this is not as easy as it looks.
>
> Since changing all the filters is not an option, I had to include a
> compatibility wrapper to have the old implementations work in the new
> design. This compatibility wrapper is obviously not perfect. In fact, it
> probably cannot be perfect, because if it could, we would not need it in
> the first place.
>
> It took time, but the new design is there, and as far as I know, it
> works. Filters with several inputs are activated when needed, EOF is
> propagated with its timestamp (but ffmpeg does not inject it because the
> patch series implementing it was blocked by bikeshedding). The only
> thing that does not work is the existing filters. That makes quite a big
> "only", I grant you.
>
> Now, I realize how frustrating to have a feature in a filter that used
> to work and no longer does, especially if it is a feature that you
> implemented yourself lovingly, and I sympathize.
>
> My goal, obviously, is to have everything working. But it takes time,
> especially when alone.
>
> Also, there have been unexpected stuff in my personal life that have
> left me with less time than before to work on ffmpeg.
>
> Now, if a feature has been broken and you want it back, you can have two
> options: you can revert, or you can help move forward.
>
> If you revert, you will possibly fix the feature, but you will also
> bring back all the issues that were fixed by these commits. Plus
> possibly other issues due to code changes that expect the new behaviour.
> And thus, you will have to revert and revert and revert.
>
> Also, you make more work for me, delaying by that much the time where
> the work is done.
>
> If you want to help move forward, on the other hand... IMO, it is the
> only sane option.
>
> Now, I also realize that helping move forward is easier said than done,
> even more so since I have not documented the new design. Documentation
> takes time, documenting in details something that does not work yet is a
> waste of time. Still, there is already quite a lot in the doxygen
> comments, and if somebody wants to help, I will give any information
> needed.
>
> And I will do so for the issue at hand.
>
> The problem is that with the "shortest" option, filters that use the
> "dualinput" system do not report EOF correctly.
>
> I have not yet been able to determine if the problem is in the dualinput
> system, not returning an error when it should, or in the wrapper code,
> not taking the return code into account properly.
>
> Still, I am not sure understanding that and fixing it would be a good
> use of the time, because it may not be possible, and because the filters
> with several inputs need to be rewritten with the new framework in mind:
> only then can they reap the benefits, especially getting rid of the
> "buffer queue overflow" problems.

Nothing can get rid of that issue, except tootal lavfi rewrite.

>
> So, how to write a filter like that with the new framework?
>
> There is a single callback, called "activate". It must, in succession:
>
> - Examine the input links (using:
>
> http://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20170615/4490ac33/attachment.patch
>   ):
>
>   - If a link has no queued frames but a status, use
> ff_inlink_acknowledge_status().
>
>   - If the queued frames (and if relevant status) allow to produce a
> frame on output, do it and return.
>
>   - If the input status change allow to deduce that one output or
> several are finished, report it with
> ff_avfilter_link_set_in_status() and return.
>
> - Examine the output links (using a wrapper, to 

Re: [FFmpeg-devel] [PATCH] movenc:adds keywords metadata

[Derek Buitenhuis]

On 7/10/2017 11:04 PM, Kieran O Leary wrote:
> A user mentioned in ffmpeg-user (
> http://ffmpeg.org/pipermail/ffmpeg-user/2017-July/036571.html)  that they
> couldn't write the 'keywords' metadata tag. I tested this patch and it
> appears to add the metadata value when using MOV and MP4 as output. I'm
> sure I've messed something up so please let me know if I can improve this.

The patch itself loos OK, IMO.

Does this change any FATE tests?

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

Re: [FFmpeg-devel] [PATCH] lavfi/buffersrc: push the frame deeper if requested.

[Nicolas George]

Le primidi 21 messidor, an CCXXV, Marton Balint a écrit :
> I am not saying they aren't, I'm just showing a case where your revert is
> breaking another case which was working before. Nicolas also stated there
> can be cases where the old code (before the revert) worked better. I just
> hope that I found a simple enough case, so somebody can take a look and find
> the root cause.

Thanks for stepping in. I will try to dot the ‘ı’s in this issue.

From the start, libavfilter has had subtle issues in corner cases. These
issue reside primarily with filters with several inputs and the handling
of EOF. We all tried to get rid of them, but soon realized they are like
lamination bubbles: once you think you are rid of one, another pops up a
few centimeters away, the only solution is to redo almost the whole
thing.

I have been doing just that for libavfilter. And since doing it all at
once is not an option, I have been doing it step by step. The
consequence is that there is a large stitch between the new and the old
code, that may be as annoying as the bubbles, and even more so when the
stitch approaches areas where there are bubbles.

Dropping the metaphor: I have been reworking the scheduling of
libavfilter to get filter with multiple inputs and EOF working, but
look, I don't mean to be rude, but this is not as easy as it looks.

Since changing all the filters is not an option, I had to include a
compatibility wrapper to have the old implementations work in the new
design. This compatibility wrapper is obviously not perfect. In fact, it
probably cannot be perfect, because if it could, we would not need it in
the first place.

It took time, but the new design is there, and as far as I know, it
works. Filters with several inputs are activated when needed, EOF is
propagated with its timestamp (but ffmpeg does not inject it because the
patch series implementing it was blocked by bikeshedding). The only
thing that does not work is the existing filters. That makes quite a big
“only”, I grant you.

Now, I realize how frustrating to have a feature in a filter that used
to work and no longer does, especially if it is a feature that you
implemented yourself lovingly, and I sympathize.

My goal, obviously, is to have everything working. But it takes time,
especially when alone.

Also, there have been unexpected stuff in my personal life that have
left me with less time than before to work on ffmpeg.

Now, if a feature has been broken and you want it back, you can have two
options: you can revert, or you can help move forward.

If you revert, you will possibly fix the feature, but you will also
bring back all the issues that were fixed by these commits. Plus
possibly other issues due to code changes that expect the new behaviour.
And thus, you will have to revert and revert and revert.

Also, you make more work for me, delaying by that much the time where
the work is done.

If you want to help move forward, on the other hand... IMO, it is the
only sane option.

Now, I also realize that helping move forward is easier said than done,
even more so since I have not documented the new design. Documentation
takes time, documenting in details something that does not work yet is a
waste of time. Still, there is already quite a lot in the doxygen
comments, and if somebody wants to help, I will give any information
needed.

And I will do so for the issue at hand.

The problem is that with the "shortest" option, filters that use the
"dualinput" system do not report EOF correctly.

I have not yet been able to determine if the problem is in the dualinput
system, not returning an error when it should, or in the wrapper code,
not taking the return code into account properly.

Still, I am not sure understanding that and fixing it would be a good
use of the time, because it may not be possible, and because the filters
with several inputs need to be rewritten with the new framework in mind:
only then can they reap the benefits, especially getting rid of the
"buffer queue overflow" problems.

So, how to write a filter like that with the new framework?

There is a single callback, called "activate". It must, in succession:

- Examine the input links (using:
  
http://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20170615/4490ac33/attachment.patch
  ):

  - If a link has no queued frames but a status, use
ff_inlink_acknowledge_status().

  - If the queued frames (and if relevant status) allow to produce a
frame on output, do it and return.

  - If the input status change allow to deduce that one output or
several are finished, report it with
ff_avfilter_link_set_in_status() and return.

- Examine the output links (using a wrapper, to plan for future
  evolutions such as mutexes)

  - If frame_wanted_out is set on an output, find out which inputs would
require a frame to allow to produce one on that output and request
them using ff_inlink_request_frame().

- If nothing could be done, just return FFERROR_NOT_READY (it 

Re: [FFmpeg-devel] [PATCH] web/template_head2: Add net neutrality script

[Michael Niedermayer]

On Tue, Jul 11, 2017 at 07:54:14AM -0400, Ronald S. Bultje wrote:
> Hi,
> 
> On Tue, Jul 11, 2017 at 6:45 AM, Michael Niedermayer  > wrote:
> 
> > On Mon, Jul 10, 2017 at 01:11:52AM +0200, Michael Niedermayer wrote:
> > > See: https://www.battleforthenet.com/july12/
> > >
> > > Signed-off-by: Michael Niedermayer 
> > > ---
> > >  src/template_head2 | 1 +
> > >  1 file changed, 1 insertion(+)
> >
> > applied, this script should automatically activate on the 12th and
> > deactivate on the day after.
> 
> 
> Thanks.
> 
> For those not knowing what this is about (and the link is unfortunately
> just a sign-up page), can you explain what will happen to our website on
> the 12th?

It will raise awarness of the consequences of loosing net neutrality.
And give people the option to send a letter to the FCC and Congress
Users can click it away and wont see it a 2nd time.

There is a demo at
https://widget.battleforthenet.com/demos/modal.html
You can also test it with ffmpeg.org
https://ffmpeg.org/index.html#ALWAYS_SHOW_BFTN_WIDGET

Documentation about the script is here:
https://github.com/fightforthefuture/battleforthenet-widget

theres also a incomplete and growing list of organizations participating
on:
https://www.battleforthenet.com/july12/


[...]

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

No great genius has ever existed without some touch of madness. -- Aristotle


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

Re: [FFmpeg-devel] [PATCH] Add FITS Demuxer

[Paras Chadha]

On Tue, Jul 11, 2017 at 3:41 PM, Nicolas George  wrote:

> Le decadi 20 messidor, an CCXXV, Reimar Döffinger a écrit :
> > I don't think that's a correct description then.
> > First, the format is made to change and be extended, so what is
> > true now might not stay true.
> > But also the images can have arbitrary dimensions, in particular
> > they can be "3D" images with the third dimension being time,
> > thus being a video.
> > This may not be well enough specified for the demuxer to be
> > able to produce a proper "video stream" at this point,
> > but implementing it in the img2 framework to me seems to
> > have a significant risk of turning out a dead-end.
>
> Ok. To me, it looks identical to GIF: it is primarily an image format
> but with non-essential animation features, it was first implemented as
> part of img2 and only when somebody did actually implement the animation
> features was it implemented as an actual demuxer. I think it was the
> right approach.
>
> Anyway, whatever solution is chosen to fix it, the big chunk of logic
> duplication between the demuxer and the decoder as they are is IMO
> unacceptable in new and non-essential code. Even more so in the scope of
> an internship project, where the primary goal is not to produce code as
> fast as possible but to teach good coding practices.
>
> Therefore I urge again to post a dump of a typical three-images FITS
> file and comment it to see which part belong in which data structure.
>
> Regards,
>
> --
>   Nicolas George
>
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
>
Hi, I have attached the dump of a FITS File containing 5 images and 4
binary table xtensions. The dump is taken using fdump utility. Please take
a look.
This is the header of the first (primary) image.

SIMPLE  =T / FITS STANDARD
BITPIX  =8 / Character information
NAXIS   =0 / No image data array present
EXTEND  =T / There may be standard extensions
DATE= '21/09/99'   / Date file was written (dd/mm/yy) 19yy
ORIGIN  = 'CEA/SSL UC Berkeley' / EUVE Science Archive
CREATOR = 'STWFITS '   / Fitsio version 05-Aug-1997
TELESCOP= 'EUVE'   / Extreme Ultraviolet Explorer
INSTTYPE= 'DS/S'   / Instrument type (DS/S, SCANNER)
OBJECT  = ''   / Name of observed object
RA_OBJ  = 79.17265 / R.A. of the object (degrees)
DEC_OBJ = 45.99862 / Declination of the object (degrees)
RA_PNT  = 79.17243 / R.A. of the pointing direction (degrees)
DEC_PNT =   46.007 / Declination of the pointing direction (degrees)
RA_PROC = 79.17586 / R.A. used to process data (degrees)
DEC_PROC= 45.99578 / Declination used to process data (degrees)
DATE-OBS= '08/09/99 GMT'   / Start date of observation (dd/mm/yy) 19yy
TIME-OBS= '00:14:29 GMT'   / Start time of observation (hh:mm:ss GMT)
DATE-END= '13/09/99 GMT'   / End date of observation (dd/mm/yy) 19yy
TIME-END= '22:07:43 GMT'   / End time of observation (hh:mm:ss GMT)
OBS_MODE= 'POINTING'   / Inertial pointing mode
DITHER  = 'SPIRAL  '   / Spacecraft dither type (DITHERED, SPIRAL, NONE)
DETMODE = 'WSZ '   / Detector position conversion mode (WSZ or XY)
OFF-AXIS=F / Was this pointing done off-axis
MOVING  =F / Did the source position vary during observation
DAYNIGHT= 'NIGHT   '   / Day/night data indicator (DAY, NIGHT, BOTH)
VALIDTIM=  132369.40583229 / Amount of telemetry present (seconds)
RA_UNIT = 'deg '   / Units for Right Ascension
DEC_UNIT= 'deg '   / Units for Declination
EQUINOX =2000. / Coordinate equinox
RADECSYS= 'FK5 '   / Frame of reference of coordinates
TIMESYS = 'MJD '   / MJD = JD - 240.5
TIMEZERO=   0. / No time offset required for EUVE event times
TIMEUNIT= 's   '   / Units for TSTART, TSTOP, TIMEZERO
CLOCKCOR= 'NO  '   / Not corrected to UT
TIMEREF = 'LOCAL   '   / No corrections applied (barycentric, etc.)
TASSIGN = 'SATELLITE'  / Event times are assigned at the satellite
TSTART  = 987466469.376002 / Time of start of observation (seconds)
TSTOP   = 987977263.104001 / Time of end of observation (seconds)
MJDREF  =   4. / MJD of SC clock start, 24.00 May 1968
EGOCSVER= 'egocs1.7.2' / Software version used to produce this data
REFVERS = 'egodata1.15.2'  / Reference calibration dataset version used
COMMENT ' '
COMMENT 'This file is part of the EUVE Science Archive. It contains'
COMMENT 'images and filter limits for one EUVE observation.'
COMMENT ' '
COMMENT 'The EUVE Science Archive contains the science data from'
COMMENT 'observations 

Re: [FFmpeg-devel] [PATCH v2] avfilter/pthread: rewrite implementation

[Muhammad Faiz]

On Tue, Jul 11, 2017 at 1:24 PM, Clément Bœsch  wrote:
> On Tue, Jul 11, 2017 at 11:18:42AM +0700, Muhammad Faiz wrote:
> [...]
>> My plan is to merge implementation of slice threading in avutil.
>>
>
> As a public API? With the .c include "trick"? avpriv_? I don't know what's
> the current consensus, but people never seem to agree about the path to
> take in that regard. You'll also get the discussion about merging all the
> libs into one.

avpriv_

>
> If you don't want to loose motivation, you're probably better of sending
> working patches with duplication first. But maybe that's what you had in
> mind anyway.

Probably I will send avpriv_. It simplifies my current working.

>
> Thanks for your work on this, the numbers are pretty cool.
>
> Note on tsan: you may want to increase the number of threads to increase
> your "chances" to trigger some races.
>
> --
> Clément B.
>
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] web/template_head2: Add net neutrality script

[Ronald S. Bultje]

Hi,

On Tue, Jul 11, 2017 at 6:45 AM, Michael Niedermayer  wrote:

> On Mon, Jul 10, 2017 at 01:11:52AM +0200, Michael Niedermayer wrote:
> > See: https://www.battleforthenet.com/july12/
> >
> > Signed-off-by: Michael Niedermayer 
> > ---
> >  src/template_head2 | 1 +
> >  1 file changed, 1 insertion(+)
>
> applied, this script should automatically activate on the 12th and
> deactivate on the day after.


Thanks.

For those not knowing what this is about (and the link is unfortunately
just a sign-up page), can you explain what will happen to our website on
the 12th?

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

Re: [FFmpeg-devel] [PATCH] web/template_head2: Add net neutrality script

[Michael Niedermayer]

On Mon, Jul 10, 2017 at 01:11:52AM +0200, Michael Niedermayer wrote:
> See: https://www.battleforthenet.com/july12/
> 
> Signed-off-by: Michael Niedermayer 
> ---
>  src/template_head2 | 1 +
>  1 file changed, 1 insertion(+)

applied, this script should automatically activate on the 12th and
deactivate on the day after.



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

The greatest way to live with honor in this world is to be what we pretend
to be. -- Socrates


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

Re: [FFmpeg-devel] [PATCH] Add FITS Demuxer

[Nicolas George]

Le decadi 20 messidor, an CCXXV, Reimar Döffinger a écrit :
> I don't think that's a correct description then.
> First, the format is made to change and be extended, so what is
> true now might not stay true.
> But also the images can have arbitrary dimensions, in particular
> they can be "3D" images with the third dimension being time,
> thus being a video.
> This may not be well enough specified for the demuxer to be
> able to produce a proper "video stream" at this point,
> but implementing it in the img2 framework to me seems to
> have a significant risk of turning out a dead-end.

Ok. To me, it looks identical to GIF: it is primarily an image format
but with non-essential animation features, it was first implemented as
part of img2 and only when somebody did actually implement the animation
features was it implemented as an actual demuxer. I think it was the
right approach.

Anyway, whatever solution is chosen to fix it, the big chunk of logic
duplication between the demuxer and the decoder as they are is IMO
unacceptable in new and non-essential code. Even more so in the scope of
an internship project, where the primary goal is not to produce code as
fast as possible but to teach good coding practices.

Therefore I urge again to post a dump of a typical three-images FITS
file and comment it to see which part belong in which data structure.

Regards,

-- 
  Nicolas George


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

Re: [FFmpeg-devel] [PATCH v2] avfilter/pthread: rewrite implementation

[Nicolas George]

Le tridi 23 messidor, an CCXXV, Clement Boesch a écrit :
> As a public API? With the .c include "trick"? avpriv_? I don't know what's
> the current consensus, but people never seem to agree about the path to
> take in that regard. You'll also get the discussion about merging all the
> libs into one.

Well, you brought it up, not me :-)

> If you don't want to loose motivation, you're probably better of sending

Nit: to loose =~ to set free != to lose =~ to misplace.

> working patches with duplication first. But maybe that's what you had in
> mind anyway.

I will not make difficulties for these changes, as they address code
that is already somewhat duplicated and quite tricky. But at some point
we will need to address the issue.

I think that even if nobody starts to implement anything right away, we
should discuss the question and decide the direction we want to go. At
the very least, it would alleviate bikeshedding for future patches and
make it safer for anybody to start working on something without fear of
being eventually rejected.

So I would like to put the following motion to discussion:

  Starting roughly three months from now, linking (including dynamically
  at run time) with different versions of the libraries will not be
  supported. Only linking with the exact same versions (source code and
  build options) will be supported. This applies even if nothing is
  actually implemented to enforce it (but it would be better to have
  something).

It is far from a complete solution, but at least it gives a direction.

Regards,

-- 
  Nicolas George


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

Re: [FFmpeg-devel] [PATCH v2] avfilter/pthread: rewrite implementation

[Marton Balint]

On Tue, 11 Jul 2017, wm4 wrote:


On Mon, 10 Jul 2017 23:40:10 +0200
Michael Niedermayer  wrote:


On Mon, Jul 10, 2017 at 10:53:42AM +0200, wm4 wrote:
> On Sat, 8 Jul 2017 01:45:06 +0200
> Michael Niedermayer  wrote:
> 
> > On Fri, Jul 07, 2017 at 09:04:37PM +0700, Muhammad Faiz wrote: 
> > > Avoid pthread_cond_broadcast that wakes up all workers. Make each of them

> > > uses distict mutex/cond. Also let main thread help running jobs.
> > > 
> > > Benchmark using afir with threads=5 and 4096 taps fir:

> > > channels=1:
> > > old:
> > > 1849650 decicycles in afir_execute,   2 runs,  0 skips
> > > 1525719 decicycles in afir_execute,1024 runs,  0 skips
> > > 1546032 decicycles in afir_execute,   16356 runs, 28 skips
> > > new:
> > > 1495525 decicycles in afir_execute,   2 runs,  0 skips
> > >  968897 decicycles in afir_execute,1024 runs,  0 skips
> > >  941286 decicycles in afir_execute,   16384 runs,  0 skips
> > > 
> > > channels=2:

> > > old:
> > > 3135485 decicycles in afir_execute,   2 runs,  0 skips
> > > 1967158 decicycles in afir_execute,1024 runs,  0 skips
> > > 1802430 decicycles in afir_execute,   16364 runs, 20 skips
> > > new:
> > > 1864750 decicycles in afir_execute,   2 runs,  0 skips
> > > 1437792 decicycles in afir_execute,1024 runs,  0 skips
> > > 1183963 decicycles in afir_execute,   16382 runs,  2 skips
> > > 
> > > channels=4:

> > > old:
> > > 4879925 decicycles in afir_execute,   2 runs,  0 skips
> > > 3557950 decicycles in afir_execute,1022 runs,  2 skips
> > > 3206843 decicycles in afir_execute,   16379 runs,  5 skips
> > > new:
> > > 2962320 decicycles in afir_execute,   2 runs,  0 skips
> > > 2450430 decicycles in afir_execute,1024 runs,  0 skips
> > > 2446219 decicycles in afir_execute,   16383 runs,  1 skips
> > > 
> > > channels=8:

> > > old:
> > > 6032455 decicycles in afir_execute,   2 runs,  0 skips
> > > 4838614 decicycles in afir_execute,1023 runs,  1 skips
> > > 4720760 decicycles in afir_execute,   16369 runs, 15 skips
> > > new:
> > > 5228150 decicycles in afir_execute,   2 runs,  0 skips
> > > 4592129 decicycles in afir_execute,1023 runs,  1 skips
> > > 4469067 decicycles in afir_execute,   16383 runs,  1 skips 
> > 
> > this causes a strange change:
> > 
> > ./ffmpeg -i ~/videos/matrixbench_mpeg2.mpg  -vcodec libxavs  -vf scale=80x60 -t 1 file3.nut
> > 
> > results in different files before and after this patch. Neither plays

> > i suspect this is not a bug in the patch but something odd elsewhere
> > but i dont know 
> 

> OK so you're saying there's no bug. 


no, i didnt say that


> Something changed, 


yes


> and you're too
> lazy to investigate, 


no, i didnt say that either, nor is that true


> but I guess he has all time in the world.
> 
> So why should he care? 


You seem to try to imply that i asked Muhammad to look into this
or take care of or fix the issue.

please read my reply again its just 3 lines, i have not asked
Muhammad to do anything. Nor was it intended to imply that.
It is just a report of some odd findings which were triggered by
the patch but which quite possibly are unrelated to the patch excpt
by coincidence.


So he can just ignore your mail? What was your mail supposed to
achieve? You basically wrote that something happened and that it
probably doesn't have to do with the patch. Why didn't you investigate
whether it did before writing that? Why post something completely
unrelated? It's not helpful.


I really don't see what is your problem. It is completely understandable 
if somebody does not track down every strange behaviour, we all have 
limted time. Reporting it still might be useful if the issue may be 
related to the patch, because investigating it might help improve the 
patch or find corner cases otherwise not easy to find.


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

Re: [FFmpeg-devel] [PATCH 3/3] avcodec/aacpsdsp_template: Fixes integer overflow in ps_add_squares_c()

[wm4]

On Mon, 10 Jul 2017 23:10:35 +0200
Michael Niedermayer  wrote:

> On Mon, Jul 10, 2017 at 10:37:46AM +0200, wm4 wrote:
> > On Sun, 9 Jul 2017 22:03:21 +0200
> > Reimar Döffinger  wrote:
> >   
> > > On 09.07.2017, at 16:08, "Ronald S. Bultje"  wrote:  
> > > > Hi,
> > > > 
> > > > On Sun, Jul 9, 2017 at 4:39 AM, Reimar Döffinger 
> > > > 
> > > > wrote:
> > > > 
> > > >> On 09.07.2017, at 02:52, "Ronald S. Bultje"  
> > > >> wrote:
> > > >>> On Sat, Jul 8, 2017 at 5:17 PM, Michael Niedermayer
> > > >> 
> > > >>> wrote:
> > > >>> 
> > >  
> > >  Does anyone object to this patch ?
> > >  Or does anyone have a better idea on how to fix this ?
> > >  if not id like to apply it
> > > >>> 
> > > >>> 
> > > >>> I think Rostislav's point is: why fix it, if it can only happen with
> > > >>> corrupt input? The before and after situation is identical: garbage 
> > > >>> in,
> > > >>> garbage out. If the compiler does funny things that makes the garbage
> > > >>> slightly differently bad, is that really so devilishly bad? It's still
> > > >>> garbage. Is anything improved by this?
> > > >> 
> > > >> The way C works, you MUST assume any undefined behaviour can at any 
> > > >> point
> > > >> [..] become exploitable.[..] If you don't like that, C is the wrong
> > > >> language to use.
> > > > 
> > > > 
> > > > I think I've read "the boy who cried wolf" a few too many times to my 
> > > > kids,
> > > > but the form of this discussion is currently too polarizing/political 
> > > > for
> > > > my taste.
> > > 
> > > That is my reading of the C standard, is that political or even just 
> > > controversial?
> > > I mean of course you can ignore standards (see MPEG-4 ASP, and in some 
> > > ways that was actually fairly reasonable thing to do at the time), and I 
> > > don't fix every undefined behaviour case in my code when I can't think of 
> > > any reasonable solution.
> > > So there is a cost-benefit discussion in principle.
> > > I believe the cost of not fixing undefined behaviour, just by virtue of 
> > > going outside what the standard guarantees should be considered fairly 
> > > high.
> > > That is an opinion, but is there any disagreement that undefined 
> > > behaviour is at least an issue of some degree?
> > > If we can agree on that, then the question would only be how much 
> > > effort/code ugliness is reasonable.
> > > There is also the point (which I hope I mentioned in the parts cut out) 
> > > that just making sure that these cases are not already exploitable right 
> > > now with the current compiler can in many cases be quite a pain (and does 
> > > not have tool support), so I think fixing it would often be the 
> > > lowest-effort method.  
> > 
> > The controversial thing is actually the SUINT nonsense. A type is
> > either signed or unsigned, but not both incompletely intransparent  
> 
> > ways. Michael keeps adding them even though many are against it.   
> 
> It is extreemly rude from you to make this claim.
> When in fact i try my best to respect every maitainer and authors
> preferrance and never add it when people object.

Do you deny that you keep sending patches that add SUINT usage? Do you
deny that you know that certain people don't like SUINT?
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH v2] avfilter/pthread: rewrite implementation

[wm4]

On Mon, 10 Jul 2017 23:40:10 +0200
Michael Niedermayer  wrote:

> On Mon, Jul 10, 2017 at 10:53:42AM +0200, wm4 wrote:
> > On Sat, 8 Jul 2017 01:45:06 +0200
> > Michael Niedermayer  wrote:
> >   
> > > On Fri, Jul 07, 2017 at 09:04:37PM +0700, Muhammad Faiz wrote:  
> > > > Avoid pthread_cond_broadcast that wakes up all workers. Make each of 
> > > > them
> > > > uses distict mutex/cond. Also let main thread help running jobs.
> > > > 
> > > > Benchmark using afir with threads=5 and 4096 taps fir:
> > > > channels=1:
> > > > old:
> > > > 1849650 decicycles in afir_execute,   2 runs,  0 skips
> > > > 1525719 decicycles in afir_execute,1024 runs,  0 skips
> > > > 1546032 decicycles in afir_execute,   16356 runs, 28 skips
> > > > new:
> > > > 1495525 decicycles in afir_execute,   2 runs,  0 skips
> > > >  968897 decicycles in afir_execute,1024 runs,  0 skips
> > > >  941286 decicycles in afir_execute,   16384 runs,  0 skips
> > > > 
> > > > channels=2:
> > > > old:
> > > > 3135485 decicycles in afir_execute,   2 runs,  0 skips
> > > > 1967158 decicycles in afir_execute,1024 runs,  0 skips
> > > > 1802430 decicycles in afir_execute,   16364 runs, 20 skips
> > > > new:
> > > > 1864750 decicycles in afir_execute,   2 runs,  0 skips
> > > > 1437792 decicycles in afir_execute,1024 runs,  0 skips
> > > > 1183963 decicycles in afir_execute,   16382 runs,  2 skips
> > > > 
> > > > channels=4:
> > > > old:
> > > > 4879925 decicycles in afir_execute,   2 runs,  0 skips
> > > > 3557950 decicycles in afir_execute,1022 runs,  2 skips
> > > > 3206843 decicycles in afir_execute,   16379 runs,  5 skips
> > > > new:
> > > > 2962320 decicycles in afir_execute,   2 runs,  0 skips
> > > > 2450430 decicycles in afir_execute,1024 runs,  0 skips
> > > > 2446219 decicycles in afir_execute,   16383 runs,  1 skips
> > > > 
> > > > channels=8:
> > > > old:
> > > > 6032455 decicycles in afir_execute,   2 runs,  0 skips
> > > > 4838614 decicycles in afir_execute,1023 runs,  1 skips
> > > > 4720760 decicycles in afir_execute,   16369 runs, 15 skips
> > > > new:
> > > > 5228150 decicycles in afir_execute,   2 runs,  0 skips
> > > > 4592129 decicycles in afir_execute,1023 runs,  1 skips
> > > > 4469067 decicycles in afir_execute,   16383 runs,  1 skips
> > > 
> > > this causes a strange change:
> > > 
> > > ./ffmpeg -i ~/videos/matrixbench_mpeg2.mpg  -vcodec libxavs  -vf 
> > > scale=80x60 -t 1 file3.nut
> > > 
> > > results in different files before and after this patch. Neither plays
> > > i suspect this is not a bug in the patch but something odd elsewhere
> > > but i dont know  
> >   
> 
> > OK so you're saying there's no bug.  
> 
> no, i didnt say that
> 
> 
> > Something changed,  
> 
> yes
> 
> 
> > and you're too
> > lazy to investigate,  
> 
> no, i didnt say that either, nor is that true
> 
> 
> > but I guess he has all time in the world.
> > 
> > So why should he care?  
> 
> You seem to try to imply that i asked Muhammad to look into this
> or take care of or fix the issue.
> 
> please read my reply again its just 3 lines, i have not asked
> Muhammad to do anything. Nor was it intended to imply that.
> It is just a report of some odd findings which were triggered by
> the patch but which quite possibly are unrelated to the patch excpt
> by coincidence.

So he can just ignore your mail? What was your mail supposed to
achieve? You basically wrote that something happened and that it
probably doesn't have to do with the patch. Why didn't you investigate
whether it did before writing that? Why post something completely
unrelated? It's not helpful.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH V2] examples/vaapi_dec: Add a VA-API hwaccel decoding example

[wm4]

On Tue, 11 Jul 2017 12:06:10 +0800
Jun Zhao  wrote:

> From 0e4d230ae4c98949a962c6bbdad31d216b54bb6a Mon Sep 17 00:00:00 2001
> From: Jun Zhao 
> Date: Tue, 21 Mar 2017 11:04:41 +0800
> Subject: [V2] examples/vaapi_dec: Add a VA-API hwaccel decoding example.
> 
> Add a VA-API hwaccel decoding example.
> 
> Signed-off-by: Liu, Kaixuan 
> Signed-off-by: Jun Zhao 
> ---
>  doc/examples/vaapi_dec.c | 266 
> +++
>  1 file changed, 266 insertions(+)
>  create mode 100644 doc/examples/vaapi_dec.c
> 
> diff --git a/doc/examples/vaapi_dec.c b/doc/examples/vaapi_dec.c
> new file mode 100644
> index 00..01320a3b71
> --- /dev/null
> +++ b/doc/examples/vaapi_dec.c
> @@ -0,0 +1,266 @@
> +/*
> + * Video Acceleration API (video decoding) decode sample
> + *
> + * 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
> + * Intel VAAPI-accelerated decoding example.
> + *
> + * @example vaapi_dec.c
> + * This example shows how to do VAAPI-accelerated decoding with output
> + * frames from the VAAPI video surfaces.
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +static AVBufferRef *hw_device_ctx = NULL;
> +FILE *output_file = NULL;
> +
> +int decoder_init_vaapi(AVCodecContext *ctx)
> +{
> +int err = 0;
> +const char *dev_name = "/dev/dri/renderD128";
> +
> +if ((err = av_hwdevice_ctx_create(_device_ctx, AV_HWDEVICE_TYPE_VAAPI,
> +  dev_name, NULL, 0)) < 0) {

The implementation already uses your dev_name as default, so you should
be able to drop that, and pass NULL to it.

> +fprintf(stderr, "Failed to create a VAAPI device.\n");
> +return err;
> +}
> +ctx->hw_device_ctx = av_buffer_ref(hw_device_ctx);
> +
> +return err;
> +}
> +
> +static enum AVPixelFormat get_vaapi_format(AVCodecContext *ctx,
> +   const enum AVPixelFormat 
> *pix_fmts)
> +{
> +const enum AVPixelFormat *p;
> +
> +for (p = pix_fmts; *p != -1; p++) {
> +if (*p == AV_PIX_FMT_VAAPI)
> +return *p;
> +}
> +
> +return AV_PIX_FMT_NONE;
> +}
> +
> +int retrieve_data(AVFrame *input)
> +{
> +AVFrame *output = NULL;
> +int err;
> +av_assert0(input->format == AV_PIX_FMT_VAAPI);
> +
> +if (!(output = av_frame_alloc()))
> +return AVERROR(ENOMEM);
> +/* default output nv12 */
> +output->format = AV_PIX_FMT_NV12;

You could use av_hwframe_transfer_get_formats() instead of hardcoding
it. Might be better if the input is 10 bit, not sure. (Just a
suggestion, up to you.)

> +if ((err = av_hwframe_transfer_data(output, input, 0)) < 0) {
> +fprintf(stderr, "Failed to transfer data to output frame: %d.\n", 
> err);
> +goto fail;
> +}
> +
> +if ((err = av_frame_copy_props(output, input)) < 0) {
> +av_frame_unref(output);
> +goto fail;
> +}
> +
> +av_frame_unref(input);
> +av_frame_move_ref(input, output);
> +av_frame_free();
> +return 0;
> +
> +fail:
> +av_frame_free();
> +return err;
> +}
> +
> +int write_frame(AVFrame *frame)
> +{
> +int idx, size;
> +int width = frame->width;
> +int height = frame->height;
> +
> +av_assert0(frame && frame->data[0] && output_file);
> +
> +for (idx = 0; idx < height; idx++) {
> +if ((size = fwrite(frame->data[0] + idx*frame->linesize[0],
> +   1, width, output_file)) < 0) {
> +fprintf(stderr, "Dump Y to file error.\n");
> +return -1;
> +}
> +}
> +
> +height >>= 1;
> +for (idx = 0; idx < height; idx++) {
> +if ((size = fwrite(frame->data[1] + idx*frame->linesize[1],
> +   1, width, output_file)) < 0) {
> +fprintf(stderr, "Dump UV to file error.\n");
> +return -1;
> +}
> +}

Using av_image_copy_to_buffer() would be more generic, although it'd
require another allocation/copy in memory. (Just a suggestion.)

> +
> +return 0;
> +}
> +
> +int 

Re: [FFmpeg-devel] [PATCH v3] avcodec/rdft: remove sintable

[Muhammad Faiz]

On Fri, Jul 7, 2017 at 2:50 PM, Muhammad Faiz  wrote:
> It is redundant with costable. The first half of sintable is
> identical with the second half of costable. The second half
> of sintable is negative value of the first half of sintable.
>
> The computation is changed to handle sign of sin values, in
> C code and ARM assembly code.
>
> Signed-off-by: Muhammad Faiz 
> ---
>  libavcodec/Makefile|  3 +-
>  libavcodec/arm/rdft_neon.S | 13 ++---
>  libavcodec/rdft.c  | 68 
> --
>  libavcodec/rdft.h  | 26 ++
>  4 files changed, 36 insertions(+), 74 deletions(-)
>
> diff --git a/libavcodec/Makefile b/libavcodec/Makefile
> index b440a00..59029a8 100644
> --- a/libavcodec/Makefile
> +++ b/libavcodec/Makefile
> @@ -122,8 +122,7 @@ OBJS-$(CONFIG_QSV) += qsv.o
>  OBJS-$(CONFIG_QSVDEC)  += qsvdec.o
>  OBJS-$(CONFIG_QSVENC)  += qsvenc.o
>  OBJS-$(CONFIG_RANGECODER)  += rangecoder.o
> -RDFT-OBJS-$(CONFIG_HARDCODED_TABLES)   += sin_tables.o
> -OBJS-$(CONFIG_RDFT)+= rdft.o $(RDFT-OBJS-yes)
> +OBJS-$(CONFIG_RDFT)+= rdft.o
>  OBJS-$(CONFIG_RV34DSP) += rv34dsp.o
>  OBJS-$(CONFIG_SHARED)  += log2_tab.o reverse.o
>  OBJS-$(CONFIG_SINEWIN) += sinewin.o sinewin_fixed.o
> diff --git a/libavcodec/arm/rdft_neon.S b/libavcodec/arm/rdft_neon.S
> index 781d976..eabb92b 100644
> --- a/libavcodec/arm/rdft_neon.S
> +++ b/libavcodec/arm/rdft_neon.S
> @@ -30,18 +30,21 @@ function ff_rdft_calc_neon, export=1
>
>  lslsr6,  r6,  #31
>  bne 1f
> -add r0,  r4,  #20
> +add r0,  r4,  #24
>  bl  X(ff_fft_permute_neon)
> -add r0,  r4,  #20
> +add r0,  r4,  #24
>  mov r1,  r5
>  bl  X(ff_fft_calc_neon)
>  1:
>  ldr r12, [r4, #0]   @ nbits
>  mov r2,  #1
> +ldr r8,  [r4, #20]  @ negative_sin
>  lsl r12, r2,  r12
>  add r0,  r5,  #8
> +lsl r8,  r8,  #31
>  add r1,  r5,  r12, lsl #2
>  lsr r12, r12, #2
> +vdup.32 d26, r8
>  ldr r2,  [r4, #12]  @ tcos
>  sub r12, r12, #2
>  ldr r3,  [r4, #16]  @ tsin
> @@ -55,6 +58,7 @@ function ff_rdft_calc_neon, export=1
>  vld1.32 {d5}, [r3,:64]! @ tsin[i]
>  vmov.f32d18, #0.5   @ k1
>  vdup.32 d19, r6
> +veord5,  d26, d5
>  pld [r0, #32]
>  veord19, d18, d19   @ k2
>  vmov.i32d16, #0
> @@ -90,6 +94,7 @@ function ff_rdft_calc_neon, export=1
>  vld1.32 {d5}, [r3,:64]! @  tsin[i]
>  veord24, d22, d17   @  ev.re,-ev.im
>  vrev64.32   d3,  d23@  od.re, od.im
> +veord5, d26, d5
>  pld [r2, #32]
>  veord2,  d3,  d16   @ -od.re, od.im
>  pld [r3, #32]
> @@ -140,10 +145,10 @@ function ff_rdft_calc_neon, export=1
>
>  vmul.f32d22, d22, d18
>  vst1.32 {d22},[r5,:64]
> -add r0,  r4,  #20
> +add r0,  r4,  #24
>  mov r1,  r5
>  bl  X(ff_fft_permute_neon)
> -add r0,  r4,  #20
> +add r0,  r4,  #24
>  mov r1,  r5
>  pop {r4-r8,lr}
>  b   X(ff_fft_calc_neon)
> diff --git a/libavcodec/rdft.c b/libavcodec/rdft.c
> index c318aa8..194e0bc 100644
> --- a/libavcodec/rdft.c
> +++ b/libavcodec/rdft.c
> @@ -28,28 +28,6 @@
>   * (Inverse) Real Discrete Fourier Transforms.
>   */
>
> -/* sin(2*pi*x/n) for 0<=x -#if !CONFIG_HARDCODED_TABLES
> -SINTABLE(16);
> -SINTABLE(32);
> -SINTABLE(64);
> -SINTABLE(128);
> -SINTABLE(256);
> -SINTABLE(512);
> -SINTABLE(1024);
> -SINTABLE(2048);
> -SINTABLE(4096);
> -SINTABLE(8192);
> -SINTABLE(16384);
> -SINTABLE(32768);
> -SINTABLE(65536);
> -#endif
> -static SINTABLE_CONST FFTSample * const ff_sin_tabs[] = {
> -NULL, NULL, NULL, NULL,
> -ff_sin_16, ff_sin_32, ff_sin_64, ff_sin_128, ff_sin_256, ff_sin_512, 
> ff_sin_1024,
> -ff_sin_2048, ff_sin_4096, ff_sin_8192, ff_sin_16384, ff_sin_32768, 
> ff_sin_65536,
> -};
> -
>  /** Map one real FFT into two parallel real even and odd FFTs. Then 
> interleave
>   * the two real FFTs into one complex FFT. Unmangle the results.
>   * ref: http://www.engineeringproductivitytools.com/stuff/T0001/PT10.HTM
> @@ -73,20 

[FFmpeg-devel] [PATCH] Add prefetch for mips

[kaustubh.raste]

From: Kaustubh Raste 

Signed-off-by: Kaustubh Raste 
---
 libavcodec/mips/Makefile|1 +
 libavcodec/mips/videodsp_mips.c |   42 +++
 libavcodec/videodsp.c   |2 ++
 libavcodec/videodsp.h   |1 +
 4 files changed, 46 insertions(+)
 create mode 100644 libavcodec/mips/videodsp_mips.c

diff --git a/libavcodec/mips/Makefile b/libavcodec/mips/Makefile
index 797df09..e2a779c 100644
--- a/libavcodec/mips/Makefile
+++ b/libavcodec/mips/Makefile
@@ -38,6 +38,7 @@ OBJS-$(CONFIG_ME_CMP) += 
mips/me_cmp_init_mips.o
 OBJS-$(CONFIG_MPEG4_DECODER)  += mips/xvididct_init_mips.o
 OBJS-$(CONFIG_VC1DSP) += mips/vc1dsp_init_mips.o
 OBJS-$(CONFIG_WMV2DSP)+= mips/wmv2dsp_init_mips.o
+OBJS-$(CONFIG_VIDEODSP)   += mips/videodsp_mips.o
 MSA-OBJS-$(CONFIG_HEVC_DECODER)   += mips/hevcdsp_msa.o\
  mips/hevc_mc_uni_msa.o\
  mips/hevc_mc_uniw_msa.o   \
diff --git a/libavcodec/mips/videodsp_mips.c b/libavcodec/mips/videodsp_mips.c
new file mode 100644
index 000..c2c8282
--- /dev/null
+++ b/libavcodec/mips/videodsp_mips.c
@@ -0,0 +1,42 @@
+/*
+ * Copyright (c) 2017 Kaustubh Raste (kaustubh.ra...@imgtec.com)
+ *
+ * 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
+ */
+
+#include "config.h"
+#include "libavutil/attributes.h"
+#include "libavcodec/videodsp.h"
+
+#if HAVE_MSA
+static void prefetch_mips(uint8_t *mem, ptrdiff_t stride, int h)
+{
+register const uint8_t *p = mem;
+do {
+__asm__ volatile ("pref 4, 0(%[p])" : : [p] "r" (p));
+__asm__ volatile ("pref 4, 32(%[p])" : : [p] "r" (p));
+p += stride;
+} while(--h);
+}
+#endif  // #if HAVE_MSA
+
+av_cold void ff_videodsp_init_mips(VideoDSPContext *ctx, int bpc)
+{
+#if HAVE_MSA
+ctx->prefetch = prefetch_mips;
+#endif  // #if HAVE_MSA
+}
diff --git a/libavcodec/videodsp.c b/libavcodec/videodsp.c
index ba618a7..ce9e9eb 100644
--- a/libavcodec/videodsp.c
+++ b/libavcodec/videodsp.c
@@ -52,4 +52,6 @@ av_cold void ff_videodsp_init(VideoDSPContext *ctx, int bpc)
 ff_videodsp_init_ppc(ctx, bpc);
 if (ARCH_X86)
 ff_videodsp_init_x86(ctx, bpc);
+if (ARCH_MIPS)
+ff_videodsp_init_mips(ctx, bpc);
 }
diff --git a/libavcodec/videodsp.h b/libavcodec/videodsp.h
index fc01a31..c0545f2 100644
--- a/libavcodec/videodsp.h
+++ b/libavcodec/videodsp.h
@@ -83,5 +83,6 @@ void ff_videodsp_init_aarch64(VideoDSPContext *ctx, int bpc);
 void ff_videodsp_init_arm(VideoDSPContext *ctx, int bpc);
 void ff_videodsp_init_ppc(VideoDSPContext *ctx, int bpc);
 void ff_videodsp_init_x86(VideoDSPContext *ctx, int bpc);
+void ff_videodsp_init_mips(VideoDSPContext *ctx, int bpc);
 
 #endif /* AVCODEC_VIDEODSP_H */
-- 
1.7.9.5

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

Re: [FFmpeg-devel] [PATCH V2] examples/vaapi_dec: Add aVA-APIhwaccel decoding example

[Steven Liu]

2017-07-11 13:54 GMT+08:00 liyoubdu :
> yes, you.  pls share your test file
I have no test file, i just review the code logic and code style, now,
do you have any questions?

>
>
> ---Original---
> From: "刘歧"
> Date: 2017/7/11 13:52:06
> To: "and patches development discussions FFmpeg";
> Cc: "刘歧";
> Subject: Re: [FFmpeg-devel] [PATCH V2] examples/vaapi_dec: Add aVA-APIhwaccel 
> decoding example
>
>
>
>> On Jul 11, 2017, at 12:49 PM, liyoubdu  wrote:
>>
>> where is your media file for testinfg
> me?
>>
>>
>>
>> ---Original---
>> From: "刘歧"
>> Date: 2017/7/11 12:39:31
>> To: "and patches development discussions FFmpeg";
>> Cc: "wm4";"Mark 
>> Thompson";"刘歧";"Liu, 
>> Kaixuan";
>> Subject: Re: [FFmpeg-devel] [PATCH V2] examples/vaapi_dec: Add a 
>> VA-APIhwaccel decoding example
>>
>>
>> From 0e4d230ae4c98949a962c6bbdad31d216b54bb6a Mon Sep 17 00:00:00 2001
>> From: Jun Zhao 
>> Date: Tue, 21 Mar 2017 11:04:41 +0800
>> Subject: [V2] examples/vaapi_dec: Add a VA-API hwaccel decoding example.
>>
>> Add a VA-API hwaccel decoding example.
>>
>> Signed-off-by: Liu, Kaixuan 
>> Signed-off-by: Jun Zhao 
>> ---
>> doc/examples/vaapi_dec.c | 266 
>> +++
>> 1 file changed, 266 insertions(+)
>> create mode 100644 doc/examples/vaapi_dec.c
>>
>> diff --git a/doc/examples/vaapi_dec.c b/doc/examples/vaapi_dec.c
>> new file mode 100644
>> index 00..01320a3b71
>> --- /dev/null
>> +++ b/doc/examples/vaapi_dec.c
>> @@ -0,0 +1,266 @@
>> +/*
>> + * Video Acceleration API (video decoding) decode sample
>> + *
>> + * 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
>> + * Intel VAAPI-accelerated decoding example.
>> + *
>> + * @example vaapi_dec.c
>> + * This example shows how to do VAAPI-accelerated decoding with output
>> + * frames from the VAAPI video surfaces.
>> + */
>> +
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +#include 
>> +
>> +static AVBufferRef *hw_device_ctx = NULL;
>> +FILE *output_file = NULL;
>> +
>> +int decoder_init_vaapi(AVCodecContext *ctx)
>> +{
>> +int err = 0;
>> +const char *dev_name = "/dev/dri/renderD128";
>> +
>> +if ((err = av_hwdevice_ctx_create(_device_ctx, 
>> AV_HWDEVICE_TYPE_VAAPI,
>> +  dev_name, NULL, 0)) < 0) {
>> +fprintf(stderr, "Failed to create a VAAPI device.\n");
>> +return err;
>> +}
>> +ctx->hw_device_ctx = av_buffer_ref(hw_device_ctx);
>> +
>> +return err;
>> +}
>> +
>> +static enum AVPixelFormat get_vaapi_format(AVCodecContext *ctx,
>> +   const enum AVPixelFormat 
>> *pix_fmts)
>> +{
>> +const enum AVPixelFormat *p;
>> +
>> +for (p = pix_fmts; *p != -1; p++) {
>> +if (*p == AV_PIX_FMT_VAAPI)
>> +return *p;
>> +}
>> +
>> +return AV_PIX_FMT_NONE;
>> +}
>> +
>> +int retrieve_data(AVFrame *input)
>> +{
>> +AVFrame *output = NULL;
>> +int err;
>> +av_assert0(input->format == AV_PIX_FMT_VAAPI);
>> +
>> +if (!(output = av_frame_alloc()))
>> +return AVERROR(ENOMEM);
>> +/* default output nv12 */
>> +output->format = AV_PIX_FMT_NV12;
>> +if ((err = av_hwframe_transfer_data(output, input, 0)) < 0) {
>> +fprintf(stderr, "Failed to transfer data to output frame: %d.\n", 
>> err);
>> +goto fail;
>> +}
>> +
>> +if ((err = av_frame_copy_props(output, input)) < 0) {
>> +av_frame_unref(output);
>> +goto fail;
>> +}
>> +
>> +av_frame_unref(input);
>> +av_frame_move_ref(input, output);
>> +av_frame_free();
>> +return 0;
>> +
>> +fail:
>> +av_frame_free();
>> +return err;
>> +}
>> +
>> +int write_frame(AVFrame *frame)
>> +{
>> +int idx, size;
>> +int width = frame->width;
>> +int height = frame->height;
>> +
>> +av_assert0(frame &&