Ported from ARMv7 NEON.

Ported from ARMv7 NEON.

Ported from ARMv7 NEON.

Since RV40 and VC-1 use almost the same algorithm so optimizations for
those two decoders are easy to do and included.

NEON and VFP are currently mandatory for all ARMv8 profiles. Both are
handled as extensions as far as cpuflags are concerned. This is
consistent with handling x86_64 which always has SSE2, but still
handles it as an extension.

Signed-off-by: Janne Grunau <janne-libav@jannau.net>

It could probably also be considered an error if the pointer isn't
null at this point, but then we might risk rejecting some
slightly broken files that we might have handled so far.

Sample-Id: 00000496-google
Reported-by: Mateusz "j00ru" Jurczyk and Gynvael Coldwind
CC: libav-stable@libav.org
Signed-off-by: Martin Storsjö <martin@martin.st>

These arrays are normally freed at the end of mov_read_trak,
but make sure they're freed in case mov_read_trak returned
early (due to errors) or in case the atoms that allocate arrays
are encountered at some other point than within a trak (which
we don't have checks against).

Sample-Id: 00000496-google
Reported-by: Mateusz "j00ru" Jurczyk and Gynvael Coldwind
CC: libav-stable@libav.org
Signed-off-by: Martin Storsjö <martin@martin.st>

Signed-off-by: Janne Grunau <janne-libav@jannau.net>

Stack is always 16 byte aligned and clz, 64bit operations and unaligned
memory access are fast in aarch64 mode on ARMv8.
Signed-off-by: Janne Grunau <janne-libav@jannau.net>

The cabac encoder was only used by the removed cabac test.
Signed-off-by: Janne Grunau <janne-libav@jannau.net>

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

Such files have IndexTableSegments which when parsed cover EditUnit
ranges like this:

 [0,1)
 [249,250)
 [249,377)
 [0,249)

where each interval is

 [IndexStartPosition, IndexStartPosition + IndexDuration)

This would be reduced to a sparse index like:

 [0,1), [249,250)

instead of the full range:

 [0,249), [249,377)
Signed-off-by: Luca Barbato <lu_zero@gentoo.org>

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

av_reallocp_array does the check already.

Without this fix the last sample was missing from the packet.

Overly large files are to be expected.
Reported-by: Jean-Baptiste Kempf <jb@videolan.org>

Needed for AVC-intra
Signed-off-by: Luca Barbato <lu_zero@gentoo.org>

All copyright holders have agreed to the relicensing.

Always use the actually read size as the offset instead of making
possibly invalid assumptions.

Addresses: CVE-2012-6618

It's shorter and more consistent with the rest of the code.

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

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

Needed for proper interlaced support.
Signed-off-by: Luca Barbato <lu_zero@gentoo.org>

Signed-off-by: Diego Biurrun <diego@biurrun.de>

The Omnia A/XE encoder writes the explicit extra data incorrectly
and wrongly disables parametric stereo. Truncating the extra data
by setting the size to 2 works around this. The AAC extra data
parser will then only parse the correct parts.

Bug-id: 599

This is pretty much based on the same test for XMM registers.
Signed-off-by: Martin Storsjö <martin@martin.st>

This fixes these fate tests on big endian.
Signed-off-by: Martin Storsjö <martin@martin.st>

The global header is not explicitly required for playback, and
omitting it allows for simple concatenation.