On Fri, Dec 09, 2022 at 02:09:45PM +0100, Timo Rothenpieler wrote:
> On 07/12/2022 23:22, Michael Niedermayer wrote:
> > On Wed, Dec 07, 2022 at 02:20:23PM +0100, Timo Rothenpieler wrote:
> > > From: Anton Khirnov <anton@khirnov.net>
> > > 
> > > Reorganize the code such that the frame threading code does not call the
> > > decoders directly, but instead calls back into the generic decoding
> > > code. This avoids duplicating the logic that wraps the decoder
> > > invocation and will be useful in the following commits.
> > > ---
> > >   libavcodec/decode.c        |  57 +++++----
> > >   libavcodec/decode.h        |   7 +
> > >   libavcodec/internal.h      |   7 +
> > >   libavcodec/pthread_frame.c | 256 ++++++++++++++++++++++++-------------
> > >   libavcodec/thread.h        |  18 +--
> > >   5 files changed, 222 insertions(+), 123 deletions(-)
> > 
> > This breaks on arm (probably lack of pthread support) in this env
> > 
> > libavcodec/libavcodec.a(decode.o): In function `decode_receive_frame_internal':
> > arm/src/libavcodec/decode.c:616: undefined reference to `ff_thread_receive_frame'
> > arm/src/libavcodec/decode.c:616: undefined reference to `ff_thread_receive_frame'
> > collect2: error: ld returned 1 exit status
> > Makefile:131: recipe for target 'ffprobe_g' failed
> > make: *** [ffprobe_g] Error 1
> 
> Probably just missing an #if somewhere.

> Why does arm not support pthreads though?
> Or is that just this specific configuration?

just this specific environment 
i could fix that but then noone will test the lack of pthreads so i think
its better if i leave it :)

thx

[...]

-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

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