Similar to AV_ZERO128, AV_COPY128 can use MMX instructions in x86

AV_ZERO64/128 can use MMX on x86.
Reviewed-By: James Almer <jamrial@gmail.com>

This fixes building on cygwin
Fixes ticket #5036

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

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

Note to maintainers: update tools

Note to maintainers: set a default whitelist for your protocol
If that makes no sense then consider to set "none" and thus require the user to specify a white-list
for sub-protocols to be opened

Note, testing and checking for missing changes is needed
Reviewed-by: Andreas Cadhalpun <andreas.cadhalpun@googlemail.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>

Signed-off-by: Derek Buitenhuis <derek.buitenhuis@gmail.com>

The codec context field was rightly deprecated, and the data
may change per-frame.
Signed-off-by: Derek Buitenhuis <derek.buitenhuis@gmail.com>

Signed-off-by: Derek Buitenhuis <derek.buitenhuis@gmail.com>

This reverts commit 8ed82d81.

SMPTE S377-1-2009c defines in F.4.1 that the Video Line Map should
always be an array with two 32 bit integers as elements. This is
repeated in G.2.12 with actual examples for progressive content,
where the second value would always be 0.

Additionally, the IRT MXF analyser also lists this as the only
error in the MXF output from ffmpeg: https://mxf-analyser-cloud.irt.deReviewed-by: Tomas Härdin <tomas.hardin@codemill.se>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>

And check for bitexact output instead
Reviewed-by: Hendrik Leppkes <h.leppkes@gmail.com>
Signed-off-by: James Almer <jamrial@gmail.com>

Fixes compilation with TRACE enabled
Reviewed-by: Hendrik Leppkes <h.leppkes@gmail.com>
Signed-off-by: James Almer <jamrial@gmail.com>

This can cause problems with urls that have arguments after the filename

This reverts commit b0c57206.
Reviewed-by: wm4 <nfxjfg@googlemail.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>

Fixes tickets #5208 and #5209

Fix trac ticket #5160.
Signed-off-by: Umair Khan <omerjerk@gmail.com>

Port of nnedi3 vapoursynth filter.
Signed-off-by: Paul B Mahol <onemda@gmail.com>

Signed-off-by: Paul B Mahol <onemda@gmail.com>

Signed-off-by: Paul B Mahol <onemda@gmail.com>

Due to this bug in VC++ 2015 Update 1:
https://connect.microsoft.com/VisualStudio/feedback/details/2291638

the 'key' array in ff_read_riff_info() ends up being not null
terminated which led to failures in a Chromium unit tests. Update 2
should have a fix, but until then it is important to avoid problems.

This fixes retrieving a valid profile for many of the FATE conformance samples,
allowing them to be properly decoded by the HWAccel after adding a profile check.

The configure detection is bumped to X265_BUILD >= 68,
since API version 68 corresponds with the x265 1.8
release tarball. The warnings inside x265 about
12-bit being experimental were removed prior to API
version 72 a short time later.  At this time of
writing, X265_BUILD is at version 80.

12-bit support in the HEVC standard was approved in
October 2014 as part of HEVC Version 2 and published
in January 2015:

http://www.itu.int/ITU-T/recommendations/rec.aspx?rec=12296
http://www.itu.int/rec/T-REC-H.265-201410-S
https://hevc.hhi.fraunhofer.de/rextReveiwed-by: Derek Buitenhuis <derek.buitenhuis@gmail.com>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>

The index creation is O(N^2) with number of entries (typically thousands).
On a Pi this can take more than 60 seconds to execute for a recording of a few hours.

By replacing with an O(N) loop, this takes virtually zero time
Liked-by: Paul B Mahol <onemda@gmail.com>
Reviewed-by: Peter Ross <pross@xvid.org>
Signed-off-by: Michael Niedermayer <michael@niedermayer.cc>

Reviewed-by: Paul B Mahol <onemda@gmail.com>

Signed-off-by: Paul B Mahol <onemda@gmail.com>

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

This was broken in 243df135.
Signed-off-by: Derek Buitenhuis <derek.buitenhuis@gmail.com>