Should fix compilation failures introduced by 9b937958.

Signed-off-by: Paul B Mahol <onemda@gmail.com>

Fixes fate-source.

Signed-off-by: Paul B Mahol <onemda@gmail.com>

For the blue and violet noise, I took the pink and brown noise
respectively and subtracted the offsets instead of adding them. When I
eyeball the frequency spectrum of the resulting outputs it looks correct
to me, i.e. the blue graph appears to be a mirror image of the pink, and
the same can be said of the violet and the brown. I did not do anything
else to confirm the correctness.

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 <mfcc64@gmail.com>

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 <mfcc64@gmail.com>

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 <mfcc64@gmail.com>

Muxers may want to directly access filename in stored in
AVFormatContext. For example in case of RTSP, the filename (url)
is used by the muxer to extract parameters of the connection.
These muxers will fail when used with fifo pseudo-muxer.

This commit fixes this issue by passing filename from AVFormatContext
of fifo pseudo-muxer to all AVFormatContext(s) of underlying muxers
during initialization.
Signed-off-by: Jan Sebechlebsky <sebechlebskyjan@gmail.com>

Use proper get_bits.h functions instead of directly accessing index.
Signed-off-by: James Almer <jamrial@gmail.com>

Avoid using bitstream reader in a non-standard way by directly accessing
index. Use bit shifting/masking operations instead.
Signed-off-by: James Almer <jamrial@gmail.com>

Duration computation can be simplified because number of PCM blocks is
only allowed to be a multiple of 8.
Signed-off-by: James Almer <jamrial@gmail.com>

Permits applications to access DTS profile information without having to
decode a frame.
Signed-off-by: James Almer <jamrial@gmail.com>

This makes probing for regular DTS more strict because more header
fields are checked and values not supported by decoder are now rejected.

Also fixes an issue original code had with 14-bit streams: 96 bits of
header were expected, however only 84 bits were converted, which was not
enough to parse LFE flag.
Signed-off-by: James Almer <jamrial@gmail.com>

Signed-off-by: James Almer <jamrial@gmail.com>

Signed-off-by: James Almer <jamrial@gmail.com>

There are 3 different places where DCA core frame header is parsed:
decoder, parser and demuxer. Each one uses ad-hoc code. Add common core
frame header parsing function that will be used in all places.
Signed-off-by: James Almer <jamrial@gmail.com>

It will be used by the parser. This change avoids unwanted parser
dependency on dcadata.
Signed-off-by: James Almer <jamrial@gmail.com>

These values will be used by the parser. Prefix them with DCA_
appropriately.
Signed-off-by: James Almer <jamrial@gmail.com>

Fixes ticket #6526.

They were all reversed (oops).

Hardware pixel formats do not tell you anything about their actual
contents, but should still score higher than formats with completely
unknown properties, which in turn should score higher than invalid
formats.

Do not return an AVERROR code as a score.

Fixes a hang in libavfilter where format negotiation gets stuck in a
loop because AV_PIX_FMT_NONE scores more highly than all other
possibilities.

the VAEncSliceParameterBufferHEVC in libva have support this field,
so remove the duplicate field in VAAPIEncodeH265MiscSliceParams.
Signed-off-by: Jun Zhao <jun.zhao@intel.com>
Signed-off-by: Mark Thompson <sw@jkqxz.net>

This reduces the number of strstr() calls per byte
This diasalows empty tags like '< >' as well as '<' in tags like '<ab<cd<<ef>'

Fixes timeout
Fixes: 1817/clusterfuzz-testcase-minimized-5104230530547712

Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpegSigned-off-by: Michael Niedermayer <michael@niedermayer.cc>

Fixes: runtime error: shift exponent 47 is too large for 32-bit type 'int'
Fixes: 2581/clusterfuzz-testcase-minimized-4681474395602944

Found-by: continuous fuzzing process https://github.com/google/oss-fuzz/tree/master/projects/ffmpegSigned-off-by: Michael Niedermayer <michael@niedermayer.cc>

Just put the subtraction in the table.
Signed-off-by: Rostislav Pehlivanov <atomnuker@gmail.com>

v2:
- use uint16_t instead of int to store 10-bit ancillary data
- fix ancillary line numbers for 1080p
- some comments and clarifications as requested by Aaron Levinson
Signed-off-by: Marton Balint <cus@passwd.hu>

This also add supports for 4K DeckLink cards because they always output the
ancillary data in 10-bit.

v2:
- only try teletext decoding for 576i PAL mode
- some comments as requested by Aaron Levinson
Signed-off-by: Marton Balint <cus@passwd.hu>

Signed-off-by: Rostislav Pehlivanov <atomnuker@gmail.com>

Fixes:
    fatal error: libvmaf.h: No such file or directory.
Signed-off-by: Derek Buitenhuis <derek.buitenhuis@gmail.com>