On Wed, Aug 03, 2022 at 03:58:26PM +0200, Anton Khirnov wrote: > There are currently three possible modes for an output stream: > 1) The stream is produced by encoding output from some filtergraph. This > is true when ost->enc_ctx != NULL, or equivalently when > ost->encoding_needed != 0. > 2) The stream is produced by copying some input stream's packets. This > is true when ost->enc_ctx == NULL && ost->source_index >= 0. > 3) The stream is produced by attaching some file directly. This is true > when ost->enc_ctx == NULL && ost->source_index < 0. > > OutputStream.stream_copy is currently used to identify case 2), and > sometimes to confusingly (or even incorrectly) identify case 1). Remove > it, replacing its usage with checking enc_ctx/source_index values. > --- > fftools/ffmpeg.c | 23 +++++++++-------------- > fftools/ffmpeg.h | 1 - > fftools/ffmpeg_opt.c | 33 ++++++++++++--------------------- > 3 files changed, 21 insertions(+), 36 deletions(-) seems to break build with shared libs: CC fftools/ffmpeg.o src/fftools/ffmpeg.c:405:32: warning: suggest braces around initialization of subobject [-Wmissing-braces] struct sigaction action = {0}; ^ {} src/fftools/ffmpeg.c:1612:37: error: address argument to atomic operation must be a pointer to non-const _Atomic type ('const atomic_uint_least64_t *' (aka 'const _Atomic(uint_least64_t) *') invalid) uint64_t frame_number = atomic_load(&ost->packets_written); ^ ~~~~~~~~~~~~~~~~~~~~~ /usr/lib/llvm-6.0/lib/clang/6.0.0/include/stdatomic.h:134:29: note: expanded from macro 'atomic_load' #define atomic_load(object) __c11_atomic_load(object, __ATOMIC_SEQ_CST) ^ ~~~~~~ 1 warning and 1 error generated. src/ffbuild/common.mak:81: recipe for target 'fftools/ffmpeg.o' failed make: *** [fftools/ffmpeg.o] Error 1 [...] -- Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB In a rich man's house there is no place to spit but his face. -- Diogenes of Sinope