avformat/flvenc: add no_metadata to flvflags

some flv have no metadata,
ffmpeg will same with the source flv stream.

Signed-off-by: Steven Liu <lingjiujianke@gmail.com>

avformat/utils: add missing brackets around arguments in av_realloc() call

Found-by: Neil Birkbeck <neil.birkbeck@gmail.com>
Signed-off-by: James Almer <jamrial@gmail.com>

vaapi_encode: Fix format specifier for bitrate logging

Same as e0df56f25d09b14f5315799338be246806c46806.  This was accidentally
reintroduced while merging c8241e730f116f1c9cfc0b34110aa7f052e05332.

lavc/vaapi_encode_h264: fix poc incorrect issue after meeting idr frame.

when meeting IDR frame, vaapi_encode_h264 poc number don't reset, now fix
this issue based on h264 spec. Some decoder don't care this case, but this
fix will enhance the encoder action. Before this fix, poc number is
negative in some case.

Reviewed-by: Jun Zhao <jun.zhao@intel.com>
Signed-off-by: Wang, Yi A <yi.a.wang@intel.com>
Signed-off-by: Mark Thompson <sw@jkqxz.net>

vaapi_h265: Fix buffering parameters

A decoder may need this to be set correctly to output frames in the
right order.

(cherry picked from commit b8cac1e83066aa87e8402c146c81b77a11b5eec3)

vaapi_h265: Fix slice header writing

This was not observed earlier because the only syntax element which
it normally misses with the current setup is slice_qp_delta, but that
is always going to be zero (in IDR frames QP isn't varied on the
slice) which will always exp-golomb code as a single 1 bit.  The
immediately following part is the byte alignment, which is always a 1
bit followed by 0s which are ignored, so as long as the bitstream is
never aligned at that point we will never notice because the only
difference is that an ignored bit is a 1 instead of a 0.

(cherry picked from commit fc30a90898e419cee7c7cb496976da6337d0bf3e)

vaapi_h264: Write bitstream restriction fields

(cherry picked from commit ec17ab381ede4f31c4bdd2767d8f62d24aaf430a)

vaapi_h264: Fix CFR mode with frame_rate set in AVCodecContext

(cherry picked from commit 17a0f9481cf07af0feb3838ca315b970117e8000)

vaapi_encode: Decide on GOP setup before initialising sequence parameters

This was always too late; several fields related to it have been incorrectly
zero since the encoder was added.

(cherry picked from commit 314b421dd8910ebed7a8d419a0dbea239a00044e)

vaapi_h264: Set max_num_ref_frames to 1 when not using B frames

(cherry picked from commit 956a54129db522998a5abae869568dae2c9774cb)

vaapi_encode: Sync to input surface rather than output

While outwardly bizarre, this change makes the behaviour consistent
with other VAAPI encoders which sync to the encode /input/ picture in
order to wait for /output/ from the encoder.  It is not harmful on
i965 (because synchronisation already happens in vaRenderPicture(),
so it has no effect there), and it allows the encoder to work on
mesa/gallium which assumes this behaviour.

(cherry picked from commit 086e4b58b59ea3993107aa24d92bb962ec69667c)

vaapi_encode: Check packed header capabilities

This improves behaviour with drivers which do not support packed
headers, such as AMD VCE on mesa/gallium.

(cherry picked from commit 892bbbcdc171ff0d08d69636a240ffb95f54243c)

vaapi_encode: Refactor initialisation

This allows better checking of capabilities and will make it easier
to add more functionality later.

It also commonises some duplicated code around rate control setup
and adds more comments explaining the internals.

(cherry picked from commit 80a5d05108cb218e8cd2e25c6621a3bfef0a832e)

vaapi_h264: Fix HRD bit_rate/cpb_size scaling

There should be an extra offset of 6 on bit_rate_scale and of 4 on
cpb_size_scale which were not accounted for here.

(cherry picked from commit 3a9662af6c741f8354b1ca97642f78f5c02e2e8f)

avformat/movenc: Restrict experimental VP9 support to MODE_MP4.

Signed-off-by: Matthew Gregan <kinetik@flim.org>
Signed-off-by: James Almer <jamrial@gmail.com>

Add experimental demuxing support for FLAC in ISO BMFF (MP4).

Based on the draft spec at https://git.xiph.org/?p=flac.git;a=blob;f=doc/isoflac.txt

Signed-off-by: Matthew Gregan <kinetik@flim.org>
Signed-off-by: James Almer <jamrial@gmail.com>

Add experimental muxing support for FLAC in ISO BMFF (MP4).

Based on the draft spec at https://git.xiph.org/?p=flac.git;a=blob;f=doc/isoflac.txt

'-strict experimental' is required to create files in this format.

Signed-off-by: Matthew Gregan <kinetik@flim.org>
Signed-off-by: James Almer <jamrial@gmail.com>

MAINTAINERS: add myself as an API tests maintainer

Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>

ffplay: allow fallback to software renderer

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

ffplay: add support for negative RGBA linesize

This fixes the crash reported in ticket #5947.

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

avformat/matroskaenc: write updated STREAMINFO metadata for FLAC streams if available

FLAC streams originating from the FLAC encoder send updated and more
complete STREAMINFO metadata as part of the last packet, so write that
to CodecPrivate instead of the incomplete one available in extradata
during init.

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

avformat/matroskaenc: postpone writing the Tracks master

This will allow us to write updated stream information not available
during write_header().

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

avutil/opt: Fix setting int64 to its maximum

Found-by: Andreas
Reviewed-by: Andreas Cadhalpun <andreas.cadhalpun@googlemail.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>

lavc/ffv1: Support YUV4xxP12 and GRAY12.

ffmdec: validate codec parameters

A negative extradata size for example gets passed to memcpy in
avcodec_parameters_from_context causing a segmentation fault.

Reviewed-by: Michael Niedermayer <michael@niedermayer.cc>
Signed-off-by: Andreas Cadhalpun <Andreas.Cadhalpun@googlemail.com>

swscale/options: Use AV_OPT_TYPE_PIXEL_FMT

Found-by: Andreas Cadhalpun <andreas.cadhalpun@googlemail.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>

avcodec/avpacket: fix leak on realloc in av_packet_add_side_data()

If realloc fails, the pointer is overwritten and the previously allocated
buffer is leaked, which goes against the expected behavior of keeping the
packet unchanged in case of error.

Michael Niedermayer <michael@niedermayer.cc>
Signed-off-by: James Almer <jamrial@gmail.com>

avformat/utils: check for overflow before reallocating side data

This makes av_stream_add_side_data() consistent with av_packet_add_side_data().

Reviewed-by: Michael Niedermayer <michael@niedermayer.cc>
Signed-off-by: James Almer <jamrial@gmail.com>

avformat/matroska: use av_stream_add_side_data() for stereo3d side data

Reviewed-by: Michael Niedermayer <michael@niedermayer.cc>
Signed-off-by: James Almer <jamrial@gmail.com>

avformat/mov: reuse existing err variable

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

avformat/mov: use av_stream_add_side_data() for displaymatrix side data

Reviewed-by: Michael Niedermayer <michael@niedermayer.cc>
Signed-off-by: James Almer <jamrial@gmail.com>

avformat/utils: add av_stream_add_side_data()

Functionally similar to av_packet_add_side_data(). Allows the use of an
already allocated buffer as stream side data.

Reviewed-by: Michael Niedermayer <michael@niedermayer.cc>
Signed-off-by: James Almer <jamrial@gmail.com>

avformat/flvdec: add debug message to list keyframes index metadata

when parsing keyframe index metadata, list the message by trace log

Signed-off-by: Steven Liu <lq@chinaffmpeg.org>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>

options_table: limit codec parameters to sane values

Reviewed-by: Michael Niedermayer <michael@niedermayer.cc>
Signed-off-by: Andreas Cadhalpun <Andreas.Cadhalpun@googlemail.com>

x86/vp9itxfm: add missing AVX2 guards

Fixes compilation with Yasm 1.1.0 and older.

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

ffmpeg: factor out sending frame to filters

Video doesn't exit ffmpeg on error anymore, and audio now prints an
error.

ffmpeg: remove dead code out of the video filter loop

It makes no sense for this code to be inside the video filter loop, and
the frame sample aspect ratio is even set unconditionally a few lines
above.

avcodec/ffv1dec: Set packed_at_lsb for 16bit YUV

This avoids unneeded computations

Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>

avcodec/ffv1dec: Support gray 10/12/16 explicitly avoid shifts

Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>

avformat/apngenc: use the stream parameters extradata if available

Fixes remuxing apng streams coming from the apng demuxer, which sends extradata
during init.

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

Revert "apngdec: use side data to pass extradata to the decoder"

This reverts commit e0c6b32046f4bab7d34be77dd2f03b2a80c86d39.

Said commit changed the behavior of the demuxer and decoder in a non
backwards compatible way.
Demuxers should make extradata available at init if possible, and send
new extradata as side data within a packet if needed.

A better fix for the remuxing crash will follow.

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

Merge commit '8d07e941b04d63fc4443dd986e3dc7b69cdcca43'

* commit '8d07e941b04d63fc4443dd986e3dc7b69cdcca43':
  FATE: add a test of H.264 SEI recovery in an intra refresh stream

Our H264 decoder drops 3 frames from the beginning of the stream, but
all frames after those match, hence the difference in the fate test.

Merged-by: Hendrik Leppkes <h.leppkes@gmail.com>

Merge commit '46278ec90ac5ad1dab5e85991f176afe49003fee'

* commit '46278ec90ac5ad1dab5e85991f176afe49003fee':
  mp3enc: write trailing padding

Noop, we have our own implementation for mp3 gapless.

Merged-by: Hendrik Leppkes <h.leppkes@gmail.com>

Merge commit 'd60c2d5216930ef98c7d4d6837d6229b37e0dcb3'

* commit 'd60c2d5216930ef98c7d4d6837d6229b37e0dcb3':
  mp3dec: read the initial/trailing padding from the LAME tag

Noop, we have our own implementation for mp3 gapless tags.

Merged-by: Hendrik Leppkes <h.leppkes@gmail.com>

Merge commit '7a76371437f9562c3414f985523f883489e3936a'

* commit '7a76371437f9562c3414f985523f883489e3936a':
  libopenh264enc: Simplify init by setting FF_CODEC_CAP_INIT_CLEANUP

Merged-by: Hendrik Leppkes <h.leppkes@gmail.com>

Merge commit '2d097c16b833c532ac974a7f1fd05c0a1f3b7675'

* commit '2d097c16b833c532ac974a7f1fd05c0a1f3b7675':
  libopenh264enc: Return a more sensible error code in some init failure paths

Merged-by: Hendrik Leppkes <h.leppkes@gmail.com>

Merge commit '36b380dcd52ef47d7ba0559ed51192c88d82a9bd'

* commit '36b380dcd52ef47d7ba0559ed51192c88d82a9bd':
  libopenh264dec: Simplify the init thanks to FF_CODEC_CAP_INIT_CLEANUP being set

Merged-by: Hendrik Leppkes <h.leppkes@gmail.com>

Merge commit 'd0b1e6049b06eeeeca146ece4d2f199c5dba1565'

* commit 'd0b1e6049b06eeeeca146ece4d2f199c5dba1565':
  libopenh264dec: Fix cleanup if the init failed early

Merged-by: Hendrik Leppkes <h.leppkes@gmail.com>

Merge commit '61cb9fac47498a38dfe7623f66aa1f3696e9158c'

* commit '61cb9fac47498a38dfe7623f66aa1f3696e9158c':
  mov: fix stream extradata_size allocation

Merged-by: Hendrik Leppkes <h.leppkes@gmail.com>

Merge commit '0b1bd1b2057d41fd0ccba7317911c484a50f9207'

* commit '0b1bd1b2057d41fd0ccba7317911c484a50f9207':
  lavd: Drop unneeded av_init_packet()s

Merged-by: Hendrik Leppkes <h.leppkes@gmail.com>

Merge commit '390b95b88b2b896b63f257f69e434dfc0111e076'

* commit '390b95b88b2b896b63f257f69e434dfc0111e076':
  fate: Add a mixed NAL coding sample

Merged-by: Hendrik Leppkes <h.leppkes@gmail.com>

doc/bsfs: various improvements

- Restored alphabetical order.
- Enhanced sections aac_adtstoasc, dca_core, h264_mp4toannexb.
- Added sections hevc_mp4toannexb and vp9_superframe.
- Renamed (if required) and filled previously empty sections
  mjpegadump, mov2textsub/text2movsub, mp3decomp, and
  remove_extra.
- Fixes ticket #3198.

Signed-off-by: Moritz Barsnick <barsnick@gmx.net>
Signed-off-by: Lou Logan <lou@lrcd.com>

ffprobe: fix crash in case -of is specified with an empty string

Fix trac issue #5957.

avformat/movenc: Check frame rate before use.

Fixes division by 0
This is similar to how avg_frame_rate is checked elsewhere
Fixes: 6d24add0455f41b1b45b7ba615cd46f3/asan_generic_dc34c3_5480_0a2ef411cae999b9871ed71a2e481b71.mov

Found-by: Mateusz "j00ru" Jurczyk and Gynvael Coldwind
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>

avcodec/ass_split: Change order of operations in ass_split_section()

This matches the other branch
Fixes out of array read
Fixes: 4d142ca76d39fe685effcf5017098723/asan_heap-oob_31ae824_8611_348fdb64f9009b63c8a8eae9a0e497c5.mkv

Found-by: Mateusz "j00ru" Jurczyk and Gynvael Coldwind
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>

Merge commit 'cbbb404055877e3beb9890ffe22784a6a100963e'

* commit 'cbbb404055877e3beb9890ffe22784a6a100963e':
  fate: Restore order of h264 entries

Merged-by: Hendrik Leppkes <h.leppkes@gmail.com>

Merge commit '61bd0ed781b56eea1e8e851aab34a2ee3b59fbac'

* commit '61bd0ed781b56eea1e8e851aab34a2ee3b59fbac':
  h264: Log more information about invalid NALu size

Merged-by: Hendrik Leppkes <h.leppkes@gmail.com>

Merge commit '7b1ae0e73ab7f7c5eabc70dbe2e579127c6e154f'

* commit '7b1ae0e73ab7f7c5eabc70dbe2e579127c6e154f':
  checkasm/arm: preserve the stack alignment checkasm_checked_call

Merged-by: Hendrik Leppkes <h.leppkes@gmail.com>

Merge commit '80fbb7becae530167373fe5178966b7d7604306e'

* commit '80fbb7becae530167373fe5178966b7d7604306e':
  checkasm: vp8.mc: initialize the full src buffer after ec32574209f

Merged-by: Hendrik Leppkes <h.leppkes@gmail.com>

Merge commit '17c99b6158f2c6720af74e81ee727ee50d2e7e96'

* commit '17c99b6158f2c6720af74e81ee727ee50d2e7e96':
  h2645_parse: handle embedded Annex B NAL units in size prefixed NAL units

This commit is a noop, see a9bb4cf87d1eb68f9ed2dc971e3400b95c1a6a78

Merged-by: Hendrik Leppkes <h.leppkes@gmail.com>

Merge commit 'a8cbe5a0ccebf60a8a8b0aba5d5716dd54c1595c'

* commit 'a8cbe5a0ccebf60a8a8b0aba5d5716dd54c1595c':
  h264_ps: export actual height in MBs as SPS.mb_height

Merged-by: Hendrik Leppkes <h.leppkes@gmail.com>

Merge commit '99cf943339a2e5171863c48cd1a73dd43dc243e1'

* commit '99cf943339a2e5171863c48cd1a73dd43dc243e1':
  d3d11va: don't keep the context lock while waiting for a frame

Merged-by: Hendrik Leppkes <h.leppkes@gmail.com>

Merge commit '2866d108c9e9da7baf53ff57a51d470691049a57'

* commit '2866d108c9e9da7baf53ff57a51d470691049a57':
  vp8dsp: Remove the comment saying that the height is equal to the width

Merged-by: Hendrik Leppkes <h.leppkes@gmail.com>

Merge commit '8c816c0c9b12fdefd9046415e97df299880bc9b8'

* commit '8c816c0c9b12fdefd9046415e97df299880bc9b8':
  checkasm/arm: align the clobber check data properly for ldrd

Merged-by: Hendrik Leppkes <h.leppkes@gmail.com>

Merge commit 'ec32574209f36467ef0d22c21a7e811ba98c15b6'

* commit 'ec32574209f36467ef0d22c21a7e811ba98c15b6':
  checkasm: vp8: mc: test unequal width/height for partitions

Merged-by: Hendrik Leppkes <h.leppkes@gmail.com>

Merge commit '5f74bd31a9bd1ac7655103b11743c12d38e0419f'

* commit '5f74bd31a9bd1ac7655103b11743c12d38e0419f':
  vp8/armv6: mc: avoid boolean expression in calculation

Merged-by: Hendrik Leppkes <h.leppkes@gmail.com>

Merge commit 'fc5cdc0d5372f5103c71d5dede296734fe71ead2'

* commit 'fc5cdc0d5372f5103c71d5dede296734fe71ead2':
  doc: escape left brace in texi2pod.pl regex

This commit is a noop, see e43ea1cbb213def50083812936c6a3c8e28a7789

Merged-by: Hendrik Leppkes <h.leppkes@gmail.com>

Merge commit 'd825b1a5306576dcd0553b7d0d24a3a46ad92864'

* commit 'd825b1a5306576dcd0553b7d0d24a3a46ad92864':
  libopenh264: Support building with the 1.6 release

This commit is a noop, see 293676c476733e81d7b596736add6cd510eb6960

Merged-by: Hendrik Leppkes <h.leppkes@gmail.com>

Merge commit '4f7723cb3b913c577842a5bb088c804ddacac8df'

* commit '4f7723cb3b913c577842a5bb088c804ddacac8df':
  movenc: Add an option for skipping writing the mfra/tfra/mfro trailer

Merged-by: Hendrik Leppkes <h.leppkes@gmail.com>

lavc/ffv1dec: Scale output for msb-packed compression to full 16bit.

2% slowdown for existing decode-line timer.

lavc/ffv1enc: Support pix_fmt GRAY10.

avcodec/mpeg4videodec: Workaround interlaced mpeg4 edge MC bug

Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>

avcodec/mpegvideo: Fix edge emu buffer overlap with interlaced mpeg4

Fixes Ticket5936
Regression since c5fc8ae12622a507d7b9ee30ddcd3734e6de6b1d

Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>

libavcodec/exr : fix channel size calculation for uint32 channel

uint32 need 4 bytes not 1.
Fix decoding when there is half/float and uint32 channel.

This fixes crashes due to pointer corruption caused by invalid writes.

The problem was introduced in commit
03152e74dfdc7f438cb4a10402c4de744e807e22.

Signed-off-by: Andreas Cadhalpun <Andreas.Cadhalpun@googlemail.com>

exr: reindent after previous commit

Signed-off-by: Andreas Cadhalpun <Andreas.Cadhalpun@googlemail.com>

exr: fix out-of-bounds read

channel_index can be -1.

This problem was introduced in commit
2dd7b46132e2801ef34fe1b5c27e0113cdcfa2f9.

Reviewed-by: Paul B Mahol <onemda@gmail.com>
Signed-off-by: Andreas Cadhalpun <Andreas.Cadhalpun@googlemail.com>

avutil/frame: fix indention after last commit

Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>

avutil/frame: Copy size=0 side data in ff_init_buffer_info()

Fixes null pointer dereference
Fixes: 189/FOO

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

libschroedingerdec: fix leaking of framewithpts

Reviewed-by: Michael Niedermayer <michael@niedermayer.cc>
Signed-off-by: Andreas Cadhalpun <Andreas.Cadhalpun@googlemail.com>

libschroedingerdec: don't produce empty frames

They are not valid and can cause problems/crashes for API users.

Reviewed-by: Michael Niedermayer <michael@niedermayer.cc>
Signed-off-by: Andreas Cadhalpun <Andreas.Cadhalpun@googlemail.com>

dds: limit 4 bpp handling to AV_PIX_FMT_PAL8

This fixes NULL pointer dereferencing for formats, where frame->data[1]
is not allocated.

The problem was introduced in commit
257fbc3af4cba08ac471dab68924182160bde6fd.

Reviewed-by: Paul B Mahol <onemda@gmail.com>
Signed-off-by: Andreas Cadhalpun <Andreas.Cadhalpun@googlemail.com>

doc/filters: adds recently added -vf colorspace options

Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>

cmdutils: remove duplicate windows.h include

Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>

configure: properly add dxva2 link dependencies

Fixes building with --disable-everything --enable-shared --enable-dxva2

The hwcontext DXVA2 implementation in avutil needs this library now, instead
of just the ffmpeg program.

fate: Add h264 extradata reload tests

Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>

Fix -Werror=parentheses error

Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>

avcodec/rv40: Test remaining space in loop of get_dimension()

Fixes infinite loop
Fixes: 178/fuzz-3-ffmpeg_VIDEO_AV_CODEC_ID_RV40_fuzzer

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

mlz: limit next_code to data buffer size

This fixes a heap-buffer-overflow detected by AddressSanitizer.

Reviewed-by: Michael Niedermayer <michael@niedermayer.cc>
Signed-off-by: Andreas Cadhalpun <Andreas.Cadhalpun@googlemail.com>

aarch64: vp9: Implement NEON loop filters

This work is sponsored by, and copyright, Google.

These are ported from the ARM version; thanks to the larger
amount of registers available, we can do the loop filters with
16 pixels at a time. The implementation is fully templated, with
a single macro which can generate versions for both 8 and
16 pixels wide, for both 4, 8 and 16 pixels loop filters
(and the 4/8 mixed versions as well).

For the 8 pixel wide versions, it is pretty close in speed (the
v_4_8 and v_8_8 filters are the best examples of this; the h_4_8
and h_8_8 filters seem to get some gain in the load/transpose/store
part). For the 16 pixels wide ones, we get a speedup of around
1.2-1.4x compared to the 32 bit version.

Examples of runtimes vs the 32 bit version, on a Cortex A53:
                                       ARM AArch64
vp9_loop_filter_h_4_8_neon:          144.0   127.2
vp9_loop_filter_h_8_8_neon:          207.0   182.5
vp9_loop_filter_h_16_8_neon:         415.0   328.7
vp9_loop_filter_h_16_16_neon:        672.0   558.6
vp9_loop_filter_mix2_h_44_16_neon:   302.0   203.5
vp9_loop_filter_mix2_h_48_16_neon:   365.0   305.2
vp9_loop_filter_mix2_h_84_16_neon:   365.0   305.2
vp9_loop_filter_mix2_h_88_16_neon:   376.0   305.2
vp9_loop_filter_mix2_v_44_16_neon:   193.2   128.2
vp9_loop_filter_mix2_v_48_16_neon:   246.7   218.4
vp9_loop_filter_mix2_v_84_16_neon:   248.0   218.5
vp9_loop_filter_mix2_v_88_16_neon:   302.0   218.2
vp9_loop_filter_v_4_8_neon:           89.0    88.7
vp9_loop_filter_v_8_8_neon:          141.0   137.7
vp9_loop_filter_v_16_8_neon:         295.0   272.7
vp9_loop_filter_v_16_16_neon:        546.0   453.7

The speedup vs C code in checkasm tests is around 2-7x, which is
pretty much the same as for the 32 bit version. Even if these functions
are faster than their 32 bit equivalent, the C version that we compare
to also became around 1.3-1.7x faster than the C version in 32 bit.

Based on START_TIMER/STOP_TIMER wrapping around a few individual
functions, the speedup vs C code is around 4-5x.

Examples of runtimes vs C on a Cortex A57 (for a slightly older version
of the patch):
                         A57 gcc-5.3  neon
loop_filter_h_4_8_neon:        256.6  93.4
loop_filter_h_8_8_neon:        307.3 139.1
loop_filter_h_16_8_neon:       340.1 254.1
loop_filter_h_16_16_neon:      827.0 407.9
loop_filter_mix2_h_44_16_neon: 524.5 155.4
loop_filter_mix2_h_48_16_neon: 644.5 173.3
loop_filter_mix2_h_84_16_neon: 630.5 222.0
loop_filter_mix2_h_88_16_neon: 697.3 222.0
loop_filter_mix2_v_44_16_neon: 598.5 100.6
loop_filter_mix2_v_48_16_neon: 651.5 127.0
loop_filter_mix2_v_84_16_neon: 591.5 167.1
loop_filter_mix2_v_88_16_neon: 855.1 166.7
loop_filter_v_4_8_neon:        271.7  65.3
loop_filter_v_8_8_neon:        312.5 106.9
loop_filter_v_16_8_neon:       473.3 206.5
loop_filter_v_16_16_neon:      976.1 327.8

The speed-up compared to the C functions is 2.5 to 6 and the cortex-a57
is again 30-50% faster than the cortex-a53.

This is an adapted cherry-pick from libav commits
9d2afd1eb8c5cc0633062430e66326dbf98c99e0 and
31756abe29eb039a11c59a42cb12e0cc2aef3b97.

Signed-off-by: Ronald S. Bultje <rsbultje@gmail.com>

aarch64: vp9: Add NEON itxfm routines

This work is sponsored by, and copyright, Google.

These are ported from the ARM version; thanks to the larger
amount of registers available, we can do the 16x16 and 32x32
transforms in slices 8 pixels wide instead of 4. This gives
a speedup of around 1.4x compared to the 32 bit version.

The fact that aarch64 doesn't have the same d/q register
aliasing makes some of the macros quite a bit simpler as well.

Examples of runtimes vs the 32 bit version, on a Cortex A53:
                                       ARM  AArch64
vp9_inv_adst_adst_4x4_add_neon:       90.0     87.7
vp9_inv_adst_adst_8x8_add_neon:      400.0    354.7
vp9_inv_adst_adst_16x16_add_neon:   2526.5   1827.2
vp9_inv_dct_dct_4x4_add_neon:         74.0     72.7
vp9_inv_dct_dct_8x8_add_neon:        271.0    256.7
vp9_inv_dct_dct_16x16_add_neon:     1960.7   1372.7
vp9_inv_dct_dct_32x32_add_neon:    11988.9   8088.3
vp9_inv_wht_wht_4x4_add_neon:         63.0     57.7

The speedup vs C code (2-4x) is smaller than in the 32 bit case,
mostly because the C code ends up significantly faster (around
1.6x faster, with GCC 5.4) when built for aarch64.

Examples of runtimes vs C on a Cortex A57 (for a slightly older version
of the patch):
                                A57 gcc-5.3   neon
vp9_inv_adst_adst_4x4_add_neon:       152.2   60.0
vp9_inv_adst_adst_8x8_add_neon:       948.2  288.0
vp9_inv_adst_adst_16x16_add_neon:    4830.4 1380.5
vp9_inv_dct_dct_4x4_add_neon:         153.0   58.6
vp9_inv_dct_dct_8x8_add_neon:         789.2  180.2
vp9_inv_dct_dct_16x16_add_neon:      3639.6  917.1
vp9_inv_dct_dct_32x32_add_neon:     20462.1 4985.0
vp9_inv_wht_wht_4x4_add_neon:          91.0   49.8

The asm is around factor 3-4 faster than C on the cortex-a57 and the asm
is around 30-50% faster on the a57 compared to the a53.

This is an adapted cherry-pick from libav commit
3c9546dfafcdfe8e7860aff9ebbf609318220f29.

Signed-off-by: Ronald S. Bultje <rsbultje@gmail.com>

aarch64: vp9: Add NEON optimizations of VP9 MC functions

This work is sponsored by, and copyright, Google.

These are ported from the ARM version; it is essentially a 1:1
port with no extra added features, but with some hand tuning
(especially for the plain copy/avg functions). The ARM version
isn't very register starved to begin with, so there's not much
to be gained from having more spare registers here - we only
avoid having to clobber callee-saved registers.

Examples of runtimes vs the 32 bit version, on a Cortex A53:
                                     ARM   AArch64
vp9_avg4_neon:                      27.2      23.7
vp9_avg8_neon:                      56.5      54.7
vp9_avg16_neon:                    169.9     167.4
vp9_avg32_neon:                    585.8     585.2
vp9_avg64_neon:                   2460.3    2294.7
vp9_avg_8tap_smooth_4h_neon:       132.7     125.2
vp9_avg_8tap_smooth_4hv_neon:      478.8     442.0
vp9_avg_8tap_smooth_4v_neon:       126.0      93.7
vp9_avg_8tap_smooth_8h_neon:       241.7     234.2
vp9_avg_8tap_smooth_8hv_neon:      690.9     646.5
vp9_avg_8tap_smooth_8v_neon:       245.0     205.5
vp9_avg_8tap_smooth_64h_neon:    11273.2   11280.1
vp9_avg_8tap_smooth_64hv_neon:   22980.6   22184.1
vp9_avg_8tap_smooth_64v_neon:    11549.7   10781.1
vp9_put4_neon:                      18.0      17.2
vp9_put8_neon:                      40.2      37.7
vp9_put16_neon:                     97.4      99.5
vp9_put32_neon/armv8:              346.0     307.4
vp9_put64_neon/armv8:             1319.0    1107.5
vp9_put_8tap_smooth_4h_neon:       126.7     118.2
vp9_put_8tap_smooth_4hv_neon:      465.7     434.0
vp9_put_8tap_smooth_4v_neon:       113.0      86.5
vp9_put_8tap_smooth_8h_neon:       229.7     221.6
vp9_put_8tap_smooth_8hv_neon:      658.9     621.3
vp9_put_8tap_smooth_8v_neon:       215.0     187.5
vp9_put_8tap_smooth_64h_neon:    10636.7   10627.8
vp9_put_8tap_smooth_64hv_neon:   21076.8   21026.9
vp9_put_8tap_smooth_64v_neon:     9635.0    9632.4

These are generally about as fast as the corresponding ARM
routines on the same CPU (at least on the A53), in most cases
marginally faster.

The speedup vs C code is pretty much the same as for the 32 bit
case; on the A53 it's around 6-13x for ther larger 8tap filters.
The exact speedup varies a little, since the C versions generally
don't end up exactly as slow/fast as on 32 bit.

This is an adapted cherry-pick from libav commit
383d96aa2229f644d9bd77b821ed3a309da5e9fc.

Signed-off-by: Ronald S. Bultje <rsbultje@gmail.com>

aarch64: Add an offset parameter to the movrel macro

With apple tools, the linker fails with errors like these, if the
offset is negative:

ld: in section __TEXT,__text reloc 8: symbol index out of range for architecture arm64

This is cherry-picked from libav commit
c44a8a3eabcd6acd2ba79f32ec8a432e6ebe552c.

Signed-off-by: Ronald S. Bultje <rsbultje@gmail.com>

arm: vp9: Add NEON loop filters

This work is sponsored by, and copyright, Google.

The implementation tries to have smart handling of cases
where no pixels need the full filtering for the 8/16 width
filters, skipping both calculation and writeback of the
unmodified pixels in those cases. The actual effect of this
is hard to test with checkasm though, since it tests the
full filtering, and the benefit depends on how many filtered
blocks use the shortcut.

Examples of relative speedup compared to the C version, from checkasm:
                          Cortex       A7     A8     A9    A53
vp9_loop_filter_h_4_8_neon:          2.72   2.68   1.78   3.15
vp9_loop_filter_h_8_8_neon:          2.36   2.38   1.70   2.91
vp9_loop_filter_h_16_8_neon:         1.80   1.89   1.45   2.01
vp9_loop_filter_h_16_16_neon:        2.81   2.78   2.18   3.16
vp9_loop_filter_mix2_h_44_16_neon:   2.65   2.67   1.93   3.05
vp9_loop_filter_mix2_h_48_16_neon:   2.46   2.38   1.81   2.85
vp9_loop_filter_mix2_h_84_16_neon:   2.50   2.41   1.73   2.85
vp9_loop_filter_mix2_h_88_16_neon:   2.77   2.66   1.96   3.23
vp9_loop_filter_mix2_v_44_16_neon:   4.28   4.46   3.22   5.70
vp9_loop_filter_mix2_v_48_16_neon:   3.92   4.00   3.03   5.19
vp9_loop_filter_mix2_v_84_16_neon:   3.97   4.31   2.98   5.33
vp9_loop_filter_mix2_v_88_16_neon:   3.91   4.19   3.06   5.18
vp9_loop_filter_v_4_8_neon:          4.53   4.47   3.31   6.05
vp9_loop_filter_v_8_8_neon:          3.58   3.99   2.92   5.17
vp9_loop_filter_v_16_8_neon:         3.40   3.50   2.81   4.68
vp9_loop_filter_v_16_16_neon:        4.66   4.41   3.74   6.02

The speedup vs C code is around 2-6x. The numbers are quite
inconclusive though, since the checkasm test runs multiple filterings
on top of each other, so later rounds might end up with different
codepaths (different decisions on which filter to apply, based
on input pixel differences). Disabling the early-exit in the asm
doesn't give a fair comparison either though, since the C code
only does the necessary calcuations for each row.

Based on START_TIMER/STOP_TIMER wrapping around a few individual
functions, the speedup vs C code is around 4-9x.

This is pretty similar in runtime to the corresponding routines
in libvpx. (This is comparing vpx_lpf_vertical_16_neon,
vpx_lpf_horizontal_edge_8_neon and vpx_lpf_horizontal_edge_16_neon
to vp9_loop_filter_h_16_8_neon, vp9_loop_filter_v_16_8_neon
and vp9_loop_filter_v_16_16_neon - note that the naming of horizonal
and vertical is flipped between the libraries.)

In order to have stable, comparable numbers, the early exits in both
asm versions were disabled, forcing the full filtering codepath.

                           Cortex           A7      A8      A9     A53
vp9_loop_filter_h_16_8_neon:             597.2   472.0   482.4   415.0
libvpx vpx_lpf_vertical_16_neon:         626.0   464.5   470.7   445.0
vp9_loop_filter_v_16_8_neon:             500.2   422.5   429.7   295.0
libvpx vpx_lpf_horizontal_edge_8_neon:   586.5   414.5   415.6   383.2
vp9_loop_filter_v_16_16_neon:            905.0   784.7   791.5   546.0
libvpx vpx_lpf_horizontal_edge_16_neon: 1060.2   751.7   743.5   685.2

Our version is consistently faster on on A7 and A53, marginally slower on
A8, and sometimes faster, sometimes slower on A9 (marginally slower in all
three tests in this particular test run).

This is an adapted cherry-pick from libav commit
dd299a2d6d4d1af9528ed35a8131c35946be5973.

Signed-off-by: Ronald S. Bultje <rsbultje@gmail.com>

arm: vp9: Add NEON itxfm routines

This work is sponsored by, and copyright, Google.

For the transforms up to 8x8, we can fit all the data (including
temporaries) in registers and just do a straightforward transform
of all the data. For 16x16, we do a transform of 4x16 pixels in
4 slices, using a temporary buffer. For 32x32, we transform 4x32
pixels at a time, in two steps of 4x16 pixels each.

Examples of relative speedup compared to the C version, from checkasm:
                         Cortex       A7     A8     A9    A53
vp9_inv_adst_adst_4x4_add_neon:     3.39   5.83   4.17   4.01
vp9_inv_adst_adst_8x8_add_neon:     3.79   4.86   4.23   3.98
vp9_inv_adst_adst_16x16_add_neon:   3.33   4.36   4.11   4.16
vp9_inv_dct_dct_4x4_add_neon:       4.06   6.16   4.59   4.46
vp9_inv_dct_dct_8x8_add_neon:       4.61   6.01   4.98   4.86
vp9_inv_dct_dct_16x16_add_neon:     3.35   3.44   3.36   3.79
vp9_inv_dct_dct_32x32_add_neon:     3.89   3.50   3.79   4.42
vp9_inv_wht_wht_4x4_add_neon:       3.22   5.13   3.53   3.77

Thus, the speedup vs C code is around 3-6x.

This is mostly marginally faster than the corresponding routines
in libvpx on most cores, tested with their 32x32 idct (compared to
vpx_idct32x32_1024_add_neon). These numbers are slightly in libvpx's
favour since their version doesn't clear the input buffer like ours
do (although the effect of that on the total runtime probably is
negligible.)

                           Cortex       A7       A8       A9      A53
vp9_inv_dct_dct_32x32_add_neon:    18436.8  16874.1  14235.1  11988.9
libvpx vpx_idct32x32_1024_add_neon 20789.0  13344.3  15049.9  13030.5

Only on the Cortex A8, the libvpx function is faster. On the other cores,
ours is slightly faster even though ours has got source block clearing
integrated.

This is an adapted cherry-pick from libav commits
a67ae67083151f2f9595a1f2d17b601da19b939e and
52d196fb30fb6628921b5f1b31e7bd11eb7e1d9a.

Signed-off-by: Ronald S. Bultje <rsbultje@gmail.com>

arm: vp9: Add NEON optimizations of VP9 MC functions

This work is sponsored by, and copyright, Google.

The filter coefficients are signed values, where the product of the
multiplication with one individual filter coefficient doesn't
overflow a 16 bit signed value (the largest filter coefficient is
127). But when the products are accumulated, the resulting sum can
overflow the 16 bit signed range. Instead of accumulating in 32 bit,
we accumulate the largest product (either index 3 or 4) last with a
saturated addition.

(The VP8 MC asm does something similar, but slightly simpler, by
accumulating each half of the filter separately. In the VP9 MC
filters, each half of the filter can also overflow though, so the
largest component has to be handled individually.)

Examples of relative speedup compared to the C version, from checkasm:
                       Cortex      A7     A8     A9    A53
vp9_avg4_neon:                   1.71   1.15   1.42   1.49
vp9_avg8_neon:                   2.51   3.63   3.14   2.58
vp9_avg16_neon:                  2.95   6.76   3.01   2.84
vp9_avg32_neon:                  3.29   6.64   2.85   3.00
vp9_avg64_neon:                  3.47   6.67   3.14   2.80
vp9_avg_8tap_smooth_4h_neon:     3.22   4.73   2.76   4.67
vp9_avg_8tap_smooth_4hv_neon:    3.67   4.76   3.28   4.71
vp9_avg_8tap_smooth_4v_neon:     5.52   7.60   4.60   6.31
vp9_avg_8tap_smooth_8h_neon:     6.22   9.04   5.12   9.32
vp9_avg_8tap_smooth_8hv_neon:    6.38   8.21   5.72   8.17
vp9_avg_8tap_smooth_8v_neon:     9.22  12.66   8.15  11.10
vp9_avg_8tap_smooth_64h_neon:    7.02  10.23   5.54  11.58
vp9_avg_8tap_smooth_64hv_neon:   6.76   9.46   5.93   9.40
vp9_avg_8tap_smooth_64v_neon:   10.76  14.13   9.46  13.37
vp9_put4_neon:                   1.11   1.47   1.00   1.21
vp9_put8_neon:                   1.23   2.17   1.94   1.48
vp9_put16_neon:                  1.63   4.02   1.73   1.97
vp9_put32_neon:                  1.56   4.92   2.00   1.96
vp9_put64_neon:                  2.10   5.28   2.03   2.35
vp9_put_8tap_smooth_4h_neon:     3.11   4.35   2.63   4.35
vp9_put_8tap_smooth_4hv_neon:    3.67   4.69   3.25   4.71
vp9_put_8tap_smooth_4v_neon:     5.45   7.27   4.49   6.52
vp9_put_8tap_smooth_8h_neon:     5.97   8.18   4.81   8.56
vp9_put_8tap_smooth_8hv_neon:    6.39   7.90   5.64   8.15
vp9_put_8tap_smooth_8v_neon:     9.03  11.84   8.07  11.51
vp9_put_8tap_smooth_64h_neon:    6.78   9.48   4.88  10.89
vp9_put_8tap_smooth_64hv_neon:   6.99   8.87   5.94   9.56
vp9_put_8tap_smooth_64v_neon:   10.69  13.30   9.43  14.34

For the larger 8tap filters, the speedup vs C code is around 5-14x.

This is significantly faster than libvpx's implementation of the same
functions, at least when comparing the put_8tap_smooth_64 functions
(compared to vpx_convolve8_horiz_neon and vpx_convolve8_vert_neon from
libvpx).

Absolute runtimes from checkasm:
                          Cortex      A7        A8        A9       A53
vp9_put_8tap_smooth_64h_neon:    20150.3   14489.4   19733.6   10863.7
libvpx vpx_convolve8_horiz_neon: 52623.3   19736.4   21907.7   25027.7

vp9_put_8tap_smooth_64v_neon:    14455.0   12303.9   13746.4    9628.9
libvpx vpx_convolve8_vert_neon:  42090.0   17706.2   17659.9   16941.2

Thus, on the A9, the horizontal filter is only marginally faster than
libvpx, while our version is significantly faster on the other cores,
and the vertical filter is significantly faster on all cores. The
difference is especially large on the A7.

The libvpx implementation does the accumulation in 32 bit, which
probably explains most of the differences.

This is an adapted cherry-pick from libav commits
ffbd1d2b0002576ef0d976a41ff959c635373fdc,
392caa65df3efa8b2d48a80f08a6af4892c61c08,
557c1675cf0e803b2fee43b4c8b58433842c84d0 and
11623217e3c9b859daee544e31acdd0821b61039.

Signed-off-by: Ronald S. Bultje <rsbultje@gmail.com>

arm: Clear the gp register alias at the end of functions

We reset .Lpic_gp to zero at the start of each function, which means
that the logic within movrelx for clearing gp when necessary will
be missed.

This fixes using movrelx in different functions with a different
helper register.

This is cherry-picked from libav commit
824e8c284054f323f854892d1b4739239ed1fdc7.

Signed-off-by: Ronald S. Bultje <rsbultje@gmail.com>

vp9dsp: Deduplicate the subpel filters

Make them aligned, to allow efficient access to them from simd.

This is an adapted cherry-pick from libav commit
a4cfcddcb0f76e837d5abc06840c2b26c0e8aefc.

Signed-off-by: Ronald S. Bultje <rsbultje@gmail.com>

avcodec/ituh263dec: Avoid spending a long time in slice sync

Fixes: 177/fuzz-3-ffmpeg_VIDEO_AV_CODEC_ID_FLV1_fuzzer

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

vp9: add avx2 iadst16 implementations.

Also a small cosmetic change to the avx2 idct16 version to make it
explicit that one of the arguments to the write-out macros is unused
for >=avx2 (it uses pmovzxbw instead of punpcklbw).

avcodec/movtextdec: Add error message for tsmb_size check

Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>