When building for iOS in thumb mode, gas-preprocessor.pl doesn't
mark unused labels as thumb functions (as it does for other
local labels, where it can figure out that they are functions
due to being referenced in branch instructions). This leads to
linker warnings for some of those local labels, such as:

ld: warning: ARM function not 4-byte aligned: __a_evaluation from
libavcodec/libavcodec.a(simple_idct_arm.o)

Therefore, comment them out since they don't have any function.
They do still have a value in documenting key points in the
assembly source though.
Signed-off-by: NMartin Storsjö <martin@martin.st>

Reported-by: Mateusz "j00ru" Jurczyk and Gynvael Coldwind
CC: libav-stable@libav.org

Reported-by: Mateusz "j00ru" Jurczyk and Gynvael Coldwind
CC: libav-stable@libav.org

Fix at least a memory leak.

CC: libav-stable@libav.org

mcc_weightings is only 32 elements.

Reported-by: Mateusz "j00ru" Jurczyk and Gynvael Coldwind
CC: libav-stable@libav.org

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

               Before           After
               Mean    StdDev   Mean    StdDev  Change
This function   1323.0  98.0      746.2  60.6   +77.3%
Overall        15400.0 336.4    14147.5 288.4    +8.9%
Signed-off-by: NMartin Storsjö <martin@martin.st>

This does most of the work formerly carried out by
the static function qmf_32_subbands() in dcadec.c.
Signed-off-by: NMartin Storsjö <martin@martin.st>

               Before           After
               Mean    StdDev   Mean    StdDev  Change
This function   1389.3  4.2       967.8  35.1   +43.6%
Overall        15577.5 83.2     15400.0 336.4    +1.2%
Signed-off-by: NMartin Storsjö <martin@martin.st>

               Before           After
               Mean    StdDev   Mean    StdDev  Change
This function    868.2  33.5      436.0  27.0   +99.1%
Overall        15973.0 223.2    15577.5  83.2    +2.5%
Signed-off-by: NMartin Storsjö <martin@martin.st>

               Before           After
               Mean    StdDev   Mean    StdDev  Change
This function   2653.0  28.5     1108.8  51.4   +139.3%
Overall        17049.5 408.2    15973.0 223.2     +6.7%
Signed-off-by: NMartin Storsjö <martin@martin.st>

               Before           After
               Mean    StdDev   Mean    StdDev  Change
This function    366.2  18.3      277.8  13.7   +31.9%
Overall        18420.5 489.1    17049.5 408.2    +8.0%
Signed-off-by: NMartin Storsjö <martin@martin.st>

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

This is similar to int32_to_float_fmul_scalar, but
loads a new scalar multiplier every 8 input samples.
This enables the use of much larger input arrays, which
is important for pipelining on some CPUs (such as
ARMv6).
Signed-off-by: NMartin Storsjö <martin@martin.st>

               Before           After
               Mean    StdDev   Mean    StdDev  Change
This function   1175.0   4.4      366.2  18.3   +220.8%
Overall        19285.5 292.0    18420.5 489.1     +4.7%
Signed-off-by: NMartin Storsjö <martin@martin.st>

               Before           After
               Mean    StdDev   Mean    StdDev  Change
This function   9295.0 114.9     4853.2 83.5    +91.5%
Overall        23699.8 397.6    19285.5 292.0   +22.9%
Signed-off-by: NMartin Storsjö <martin@martin.st>

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

libx264 has a few data exports which require X264_API_IMPORTS
to be defined if we link to libx264 dynamically on Windows.

In a similar fashion to how we handle our compat snprintf
implementation, if we define it all the time, the compiler
will first try and link to __imp_x264_symbol_name, and failing
that, as in the case of a static libx264, will attempt to link
to the non-prefixed symbol, which has already been pulled in by
other x264 functions' object files.
Signed-off-by: NDerek Buitenhuis <derek.buitenhuis@gmail.com>

A packet larger than cin->bitmap_size does not make sense.

Reported-by: Mateusz "j00ru" Jurczyk and Gynvael Coldwind
CC: libav-stable@libav.org

Reported-by: Mateusz "j00ru" Jurczyk and Gynvael Coldwind
CC: libav-stable@libav.org

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

This supports inclusion of one single IP address for now,
at the media level. Specifying the filter at the session level
(instead of at the media level), multiple source addresses,
exclusion, or using FQDNs instead of plain IP addresses is not
supported (yet at least).
Signed-off-by: NMartin Storsjö <martin@martin.st>

If another peer is sending unicast packets to the same port that
we are listening on, those packets can end up being received despite
using source specific multicast. For those cases, manually check the
source address of received packets against the intended source address.

This only handles the case when the source list is one single IP
address for now, which probably is the most common case.

Based on a patch by Ed Torbett.
Signed-off-by: NMartin Storsjö <martin@martin.st>

Blocking/exclusion is not supported yet.

The rtp protocol parameter takes the same form as the existing
sources parameter for the udp protocol.
Signed-off-by: NMartin Storsjö <martin@martin.st>

Also fix a comment and an #endif comment.

There is no record of this ever being used at all, anywhere,
since the feature was added in 2effd274.

This gets rid of extra linker tricks just to support a feature
that isn't used, simplifying portability to other platforms.
Signed-off-by: NMartin Storsjö <martin@martin.st>

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

The AIX threads library exposes a function with the same name.
Signed-off-by: NMartin Storsjö <martin@martin.st>

If either of the deltas is too large for the multiplications to
succeed, don't use this for setting the avg frame rate.

Reported-by: Mateusz "j00ru" Jurczyk and Gynvael Coldwind
Cc: libav-stable@libav.org
Signed-off-by: NMartin Storsjö <martin@martin.st>

The time scale is set in mdhd, and later validated in the
enclosing trak atom once all of its children have been parsed.

A loose mdhd atom outside of a trak atom could update the time
scale of the last stream without any validation.

Reported-by: Mateusz "j00ru" Jurczyk and Gynvael Coldwind
Cc: libav-stable@libav.org
Signed-off-by: NMartin Storsjö <martin@martin.st>

Reported-by: Mateusz "j00ru" Jurczyk and Gynvael Coldwind
Cc: libav-stable@libav.org
Signed-off-by: NMartin Storsjö <martin@martin.st>

This was handled properly in the normal return case at the end
of the function, but not in this special case.

Returning a value larger than the input packet size can cause
problems for certain library users.

Returning the actual input buffer size unconditionally, since
it is not guaranteed that frame_size is set to a sensible
value at this point.

Cc: libav-stable@libav.org
Signed-off-by: NMartin Storsjö <martin@martin.st>

A frame marked FRAMETYPE_NULL cannot be scalable and requires a
previous frame successfully decoded.

Reported-by: Mateusz "j00ru" Jurczyk and Gynvael Coldwind
CC: libav-stable@libav.org