Signed-off-by: Zhu Pengfei <411294962@qq.com>
Signed-off-by: Steven Liu <lq@chinaffmpeg.org>

Signed-off-by: Fei Wang <fei.w.wang@intel.com>

Signed-off-by: Fei Wang <fei.w.wang@intel.com>

This may reduce the number of internal threads when using hwupload or
hwdownload filter.
Signed-off-by: Haihao Xiang <haihao.xiang@intel.com>

When all cached frames are drained, the output mfxSyncPoint pointer is
NULL and  MFX_ERR_MORE_DATA is returned, hence needn't print warning for
this expected behavior, otherwise the user might think the output from
qsv decoders are wrong.
Signed-off-by: Haihao Xiang <haihao.xiang@intel.com>

Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>

Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>

The latter is not supported by MSVC 19.27.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>

ff_aac_coder_init_mips() modifies a static const structure of
function pointers. This will crash if the binary uses relro
and is a data race in any case.

Furthermore it points to a maintainability issue: The
AACCoefficientsEncoder structures have been constified
in commit fd9212f2,
a Libav commit merged in 318778de.
Libav did not have the MIPS-specific AAC code and so this was
fine for them; yet FFmpeg had them, but this was not recognized.

Commit 75a099fc points to another
maintainability issue: Contrary to ordinary DSP code, this code
here is way more complex and needs to be constantly kept in sync
with the ordinary code which it mimicks and replaces. Said commit
is the only commit actually changing aaccoder.c in the last few
years and the same change has not been performed for the MIPS
clone; before that, it even happened several times that the mips
code was broken due to changes of the generic code (see commits
97437bd1 and
de262d01 or
860dbe02 or
933309a6 or
b65ffa31). This might even lead
to scenarios where someone changing non-dsp aacenc code would
have to modify mips inline asm in order to keep them in sync.
This is obviously a significant burden (if the AAC encoder were
actively developed).

Finally, the code does not even compile here due to errors like
"Error: float register should be even, was 1".
Reviewed-by: Lynne <dev@lynne.ee>
Reviewed-by: Jean-Baptiste Kempf <jb@videolan.org>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>

These strings are so short (longest takes 11B) that using
pointers is wasteful. Avoiding them also moves hashdesc
into .rodata (from .data.rel.ro).
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>

AIFF is a big-endian format, so this is more natural.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>

Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>

In particular, test writing tags with odd strlen.
(These tags are zero-padded to even size.)
Reviewed-by: Michael Niedermayer <michael@niedermayer.cc>
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>

Avoids .got entries for ff_mpa_bitrate_tab, ff_mpa_synth_window_fixed,
ff_band_size_long, ff_mpa_pretab, ff_band_size_short,
ff_mpa_synth_window_float and ff_band_index_long here.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>

Avoids .got entries for ff_vorbis_ch_layouts.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>

Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>

Because they are.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>

Both GCC and Clang create code that inlines the loops in
next_input() and next_output() at high optimization
levels (presumably when there are not too many devices)
and this code leads to the creation of .got entries:
  e7:	48 3b 3d 00 00 00 00 	cmp    0x0(%rip),%rdi        # ee <av_input_video_device_next+0xe>
			ea: R_X86_64_REX_GOTPCRELX	ff_alsa_demuxer-0x4
  ee:	74 43                	je     133 <av_input_video_device_next+0x53>
  f0:	48 3b 3d 00 00 00 00 	cmp    0x0(%rip),%rdi        # f7 <av_input_video_device_next+0x17>
			f3: R_X86_64_REX_GOTPCRELX	ff_fbdev_demuxer-0x4
  f7:	74 41                	je     13a <av_input_video_device_next+0x5a>

These relocations can't be fixed up lateron when it is known
that the symbols exist in the same DSO.

This commit therefore marks these symbols as hidden, leading
to code like this:
  f7:	48 8d 05 00 00 00 00 	lea    0x0(%rip),%rax        # fe <av_input_video_device_next+0xe>
			fa: R_X86_64_PC32	ff_alsa_demuxer-0x4
  fe:	48 39 c7             	cmp    %rax,%rdi
 101:	74 55                	je     158 <av_input_video_device_next+0x68>
 103:	48 8d 05 00 00 00 00 	lea    0x0(%rip),%rax        # 10a <av_input_video_device_next+0x1a>
			106: R_X86_64_PC32	ff_fbdev_demuxer-0x4
 10a:	48 39 c7             	cmp    %rax,%rdi
 10d:	74 50                	je     15f <av_input_video_device_next+0x6f>

(Note: It is actually strange that the compiler creates code
that tries to read the addresses from the .got given that the
addresses can be read directly from indev_list/outdev_list.)
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>

Forgotten in 4c8d9b1d.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>

Avoids .got entries for ff_iamf_scalable_ch_layouts and
ff_iamf_sound_system_map (whether they would have been
created otherwise depends upon the compiler and compiler
options).
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>

OptionDef.u is only an offset (i.e. its off member) iff OPT_FLAG_OFFSET
is true. Otherwise, the pointer arithmetic can be undefined behaviour.
UBSan warns about this (on 32bit arches):
src/fftools/ffmpeg_opt.c:102:15: runtime error: pointer index expression with base 0xffa4db10 overflowed to 0x56059a50

This commit fixes this by checking for OPT_FLAG_OFFSET first.
Signed-off-by: Andreas Rheinhardt <andreas.rheinhardt@outlook.com>

Fixes yadif-16 which allows FATE to pass.

Broken since 2904db90 (2017).

The documentation correctly states that the rdiv is a multiplier but incorrectly states the default behavior is to multiply by the sum of all matrix elements - it multiplies by 1/sum.

This changes the documentation to match the code.

Address trac #10889
Signed-off-by: Marton Balint <cus@passwd.hu>

Signed-off-by: Marton Balint <cus@passwd.hu>

Signed-off-by: Marton Balint <cus@passwd.hu>

Also make initialization/uninitialization behaviour more explicit in the docs,
and make sure we do not leak a channel map on error.
Signed-off-by: Marton Balint <cus@passwd.hu>

Also make use of the av_channel_from_string() function to determine the channel
id. This fixes some parse issues in av_channel_layout_from_string().
Signed-off-by: Marton Balint <cus@passwd.hu>

avutil/tests/channel_layout: add some av_channel_from_string and av_channel_layout_from_string tests

We lacked tests which supposed to fail, and there are some which should fail
but right now it does not. This will be fixed in a later commit.
Signed-off-by: Marton Balint <cus@passwd.hu>

Deduplicates a lot of code.

Some minor differences (mostly white space and inconsistent use of quotes) are
expected in the fate tests, there was no point aiming for exactly the same
formatting.
Signed-off-by: Marton Balint <cus@passwd.hu>

Signed-off-by: Marton Balint <cus@passwd.hu>

Signed-off-by: Marton Balint <cus@passwd.hu>

This makes the wav and pcm demuxer demux bigger packets, which is more
efficient.

As a side effect of the bigger packets, audio durations can become less exact
for command lines such as "ffmpeg -i $INPUT -c:a copy -t 1.0 $OUTPUT".
Signed-off-by: Marton Balint <cus@passwd.hu>

Signed-off-by: Marton Balint <cus@passwd.hu>

- Remove the 1024 cap on the number of samples, for high sample rate audio it
  was suboptimal, calculate the low neighbour power of two for the number of
  samples (audio blocks) instead.
- Make the function work correctly also for non-pcm codecs by using the stream
  bitrate to estimate the target packet size. A previous version of this patch
  used av_get_audio_frame_duration2() the estimate the desired packet size, but
  for some codecs that returns the duration of a single audio frame regardless
  of frame_bytes.
- Fallback to 4096/block_align*block_align if bitrate is not available.
Signed-off-by: Marton Balint <cus@passwd.hu>

8559cce3 made the bitstream check generic using a LUT.
However, one of the comparisons which involves a bitwise AND
and equality check is faulty due to operator precedence.

First reported and analysed at
https://github.com/streamlink/streamlink/issues/5876

Fixes #10908

Otherwise they will not even open.
Reviewed-by: Michael Niedermayer <michael@niedermayer.cc>
Signed-off-by: James Almer <jamrial@gmail.com>

One some system, one some displays, for unknown reasons,
these contain rather bad flags that cause all kinds of weird
behaviour.

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

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

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