Fix related register order issue in ff_h264_idct_add_neon.

Found-by: zjh8890 <243186085@qq.com>

This macro unconditionally used out[-1], which causes an out of bounds
read, if out is the very beginning of the buffer.

Signed-off-by: Andreas Cadhalpun <Andreas.Cadhalpun@googlemail.com>
Signed-off-by: Luca Barbato <lu_zero@gentoo.org>

Due to this typo max_center can be too large, causing nlsf to be set to
too large values, which in turn can cause nlsf[i - 1] + min_delta[i] to
overflow to a negative value, which is not allowed for nlsf and can
cause an out of bounds read in silk_lsf2lpc.

Signed-off-by: Andreas Cadhalpun <Andreas.Cadhalpun@googlemail.com>
Signed-off-by: Luca Barbato <lu_zero@gentoo.org>

Quite a bit faster than int32_to_float_fmul_array8_c calling
ff_int32_to_float_fmul_scalar_neon through FmtConvertContext.
Number of cycles per int32_to_float_fmul_array8 call while decoding
padded.dts on exynos5422:

               before  after   change
cortex-a7:     1270     951    -25%
cortex-a15:     434     285    -34%

checkasm --bench cycle counts:     cortex-a15   cortex-a7
int32_to_float_fmul_array8_c:      1730.4       4384.5
int32_to_float_fmul_array8_neon_c:  571.5       1694.3
int32_to_float_fmul_array8_neon:    374.0       1448.8

Interesting are the differences between
int32_to_float_fmul_array8_neon_c and int32_to_float_fmul_array8_neon.
The former is current behaviour of calling
ff_int32_to_float_fmul_scalar_neon repeatedly from the c function,
The raw numbers differ since checkasm uses different lengths than the
dca decoder.

3% faster dts decoding on a cortex-a57.

                                 cortex-a57   cortex-a53
int32_to_float_fmul_array8_c:    1270.9       4475.6
int32_to_float_fmul_array8_neon:  328.6        569.2
int32_to_float_fmul_scalar_c:     928.5       4119.6
int32_to_float_fmul_scalar_neon:  309.1        524.1

~25% faster dts decoding overall. The checkasm CPU cycles numbers are
not that useful since synth_filter_float() calls FFTContext.imdct_half().

                         cortex-a57   cortex-a53
synth_filter_float_c:    1866.2       3490.9
synth_filter_float_neon:  915.0       1531.5

With fftc.imdct_half forced to imdct_half_neon:
                         cortex-a57   cortex-a53
synth_filter_float_c:    1718.4       3025.3
synth_filter_float_neon:  926.2       1530.1

~2% faster dts decoding overall.

                    cortex-a57   cortex-a53
dca_decode_hf_c:    474.8        1659.9
dca_decode_hf_neon: 225.2         301.1
dca_lfe_fir0_c:     913.2        1537.7
dca_lfe_fir0_neon:  286.8         451.9
dca_lfe_fir1_c:     848.7        1711.5
dca_lfe_fir1_neon:  387.1         506.4

The vector mode was deprecated in ARMv7-A/VFPv3 and various cpu
implementations do not support it in hardware. Vector mode code will
depending the OS either be emulated in software or result in an illegal
instruction on cpus which does not support it. This was not really
problem in practice since NEON implementations of the same functions are
preferred. It will however become a problem for checkasm which tests
every cpu flag separately.

Since this is a cpu feature newer cpu do not support anymore the
behaviour of this flag differs from the other flags. It can be only
activated by runtime cpu feature selection.

The ISB (instruction synchronization barrier) might be too heavy for
START/STOPTIMER use but should be more accurate in checkasm where the
timing overhead is subtracted.

Include macros.h explicitly in common.h so that external code using
FFALIGN does not break. It was already implicitly included through
version.h. Include macros.h in lls.h and internal.h for FFALIGN.
lls.h was including common.h only for FFALIGN and internal.h was
missing the include for FFALIGN. `make checkheaders` did not catch it
because it's an internal header.

So far an AC-3 elementary stream is refered to in the PMT according to
System A (ATSC). However System B (DVB) has a different way to signal an AC-3
ES within the PMT. This different way can be enabled by a new flag. The flag is
more generally named 'system_b' as there are further differences between ATSC
and DVB (e.g. the signalling of E-AC-3) which should then also be covered by it
in the future.

Bug-Id: 73

Signed-off-by: Luca Barbato <lu_zero@gentoo.org>

That buffer is read only and marking it accordingly let
the user passing a constant buffer to it without having
a const-correctness warning.

Signed-off-by: Luca Barbato <lu_zero@gentoo.org>

This matches what librtmp does. This fixes automatic url parsing of
crunchyroll urls.

Signed-off-by: Martin Storsjö <martin@martin.st>

The stream parameters are not known until we read a packet, so postpone
creating it until then.

The current muxer behaviour is to create streams in read_header() based
on the audio/video presence flags, but fill in the stream parameters
later when we actually get some packets for them. This is rather shady,
since other demuxers set the stream parameters immediately when the
stream is created and do not touch the stream codec context after that.

Change the flv demuxer to behave in the same way as other similar
demuxers -- create the streams only when we get a packet for them.

It's not used by anything outside of lavc anymore.

The latter does not require a full AVCodecContext and still provides all
the functionality needed here.

Almost all the places from which this function is called already check
the header manually and in the two that don't (the mp3 muxer) the check
should not cause any problems.

The profiles are a property of the codec, so it makes sense to export
them through AVCodecDescriptors, not just the codec implementations.

It will not be set unless the muxing codec context is also the encoding
context, which is discouraged. When the frame size is not known from
av_get_audio_frame_duration(), the fallback should still be good enough.

It will not be set if the stream codec context is not the encoding
context. Use av_get_audio_frame_duration() instead, it should work for
all audio codecs supported by the muxer.

Fixes 2507b5dd67

fixes assembling on OS/2

Signed-off-by: Dave Yeo <dave.r.yeo@gmail.com>
Signed-off-by: Luca Barbato <lu_zero@gentoo.org>

Make easier to avoid compile failure when reworking the internal
headers.

Avoid the warning `-Wempty-body`.

matroskaenc applies divisors to the display width/height when generating
stereo content. This patch adds the corresponding multipliers to matroskadec
so that the original sample aspect ratio can be recovered.

Signed-off-by: wm4 <nfxjfg@googlemail.com>
Signed-off-by: Vittorio Giovara <vittorio.giovara@gmail.com>

Fix fate tests with asan. Introduced during bytestream2 porting
(in revision 62cc8f4d79).

Signed-off-by: Vittorio Giovara <vittorio.giovara@gmail.com>

These variables are coming from mpegvideoenc where are supposedly used
as bit counters on various frame properties. However their use is
unclear as they lack documentation, are available only from a very small
subset of encoders, and they are hardly used in the wild. Also frame_bits
in aacenc is employed in a similar way.

Remove this functionality from AVCodecContex, these variable are mostly
frame properties, and too few encoders support setting them with anything
useful.

Signed-off-by: Vittorio Giovara <vittorio.giovara@gmail.com>

Most option values are simply unused or ignored and in practice the
majory of codecs only need to check whether to enable rle or not.

Add appropriate codec private options which better expose the allowed
features.

Signed-off-by: Vittorio Giovara <vittorio.giovara@gmail.com>

We do not need to do a full setup like for a real frame, just allocate a
buffer and set cur_pic(_ptr).

EOVERFLOW seems to be unavailable on certain platforms.

Signed-off-by: Martin Storsjö <martin@martin.st>

Signed-off-by: Martin Storsjö <martin@martin.st>

Checking the codec context parameters to find out this information is
far too unreliable to be useful, so it is safer to assume B-frames are
always present.

Also, stop using AVCodecContext for storing the stream parameters.

Do not access the encoder options, since it makes no sense when the
AVStream codec context is not the encoding context.

Do not access the encoder options, since it makes no sense when the
AVStream codec context is not the encoding context.

Deprecate AVCodecContext.vbv_delay