If the get_buffer() call fails, the frame might have some side data
already set. Make sure it gets freed.

CC: libav-stable@libav.org

CC: libav-stable@libav.org
Signed-off-by: Anton Khirnov <anton@khirnov.net>

Use the correct ctxIdxInc calculation for coded_block_flag.
Keep old behavior for old versions of x264 for backward compatibility.

CC: libav-stable@libav.org
Signed-off-by: Anton Khirnov <anton@khirnov.net>

CC: libav-stable@libav.org
Signed-off-by: Anton Khirnov <anton@khirnov.net>

Do not use the one in the SEI directly as that is reset at certain
points.

Inspired by patches from Michael Niedermayer <michaelni@gmx.at> and
Anton Mitrofanov <BugMaster@narod.ru>.

CC: libav-stable@libav.org

Black isn't always just memset(ptr, 0, size). Limited YUV in particular
requires relatively non-obvious values, and filling a frame with
repeating 0 bytes is disallowed in some contexts. With component sizes
larger than 8 or packed YUV, this can become relatively complicated. So
having a generic function for this seems helpful.

In order to handle the complex cases in a generic way without destroying
performance, this code attempts to compute a black pixel, and then uses
that value to clear the image data quickly by using a function like
memset.

Common cases like yuv410p10 or rgba can't be handled with a simple
memset, so there is some code to fill memory with 2/4/8 byte patterns.
For the remaining cases, a generic slow fallback is used.
Signed-off-by: Anton Khirnov <anton@khirnov.net>

Signed-off-by: Anton Khirnov <anton@khirnov.net>

Accidentally left out of 95ce02b3.

The current qsv deinterlace module does not work at all because MSDK needs user to pass
extra parameters to enable hint functions,such as denoise,deinterlace,composition and so on.

Usage:-hwaccel qsv -r 25 -c:v h264_qsv -i in -vf deinterlace_qsv=bob -b 2M
      -maxrate 3M -c:v h264_qsv -y out.h264
Signed-off-by: ChaoX A Liu <chaox.a.liu@gmail.com>
Signed-off-by: Zhengxu Huang <zhengxu.maxwell@gmail.com>
Signed-off-by: Andrew Zhang <huazh407@gmail.com>
Change-Id: I9e7ddcf884f2788c2820f6c98affacfb9d8f3287
Signed-off-by: Maxym Dmytrychenko <maxim.d33@gmail.com>

usage:
-hwaccel qsv -c:v h264_qsv -i in -c:v mjpeg_qsv -global_quality 80 -f
mjpeg out
Signed-off-by: ChaoX A Liu <chaox.a.liu@gmail.com>
Signed-off-by: Zhengxu Huang <zhengxu.maxwell@gmail.com>
Signed-off-by: Andrew Zhang <huazh407@gmail.com
Signed-off-by: Maxym Dmytrychenko <maxim.d33@gmail.com>

This is consistent with how other destructors behave.
Signed-off-by: Anton Khirnov <anton@khirnov.net>

This mode apparently does not support decoding of HEVC Main (8 bit).
With D3D11 and Intel drivers on Windows 10 I get green corruption, while
using DXVA2_ModeHEVC_VLD_Main works.
Signed-off-by: Anton Khirnov <anton@khirnov.net>

CC: libav-stable@libav.org

Otherwise the first decoded frame will still be tagged with the
original transfer instead of the alternative one.
Signed-off-by: Vittorio Giovara <vittorio.giovara@gmail.com>

glibc introduced _DEFAULT_SOURCE in version 2.19 to replace _BSD_SOURCE and
_SVID_SOURCE, which were deprecated in version 2.20. Add _DEFAULT_SOURCE
where the latter two are used to be forwards-compatible and avoid warnings
about the use of deprecated definitions.

About an additional 4% speedup.
Signed-off-by: Diego Biurrun <diego@biurrun.de>

About 2% speedup on gcc-6.3.
Signed-off-by: Diego Biurrun <diego@biurrun.de>

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

Do not use skip_remaining() to fully wipe the cache, as this could do
a 64-bit shift of a 64-bit variable which is undefined behavior in C.
Instead set the related variables to zero directly.

Thanks to Uoti for pointing out the problem.

CC: libav-stable@libav.org

This works around type aliasing violations and related warnings.
Also add some missing error checking.

Avoid anonymously typedeffed structs and enums, drop an unused context member,
fix a small wording mishap, sizeof(type) ---> sizeof(*variable), drop a
needlessly verbose log message, use av_malloc_array() where appropriate.

Now it is possible to adjust compression speed vs R/D when needed
and also skip vintage player compatibility at will.
Signed-off-by: Diego Biurrun <diego@biurrun.de>

version 2013-02-08 Rl
- fixes/optimization in multistrip encoding and codebook size choice,
  quality/bitrate is now better than that of the binary proprietary encoder

version 2013-02-12 Rl
- separated codebook training sets, avoided the transfer of wasted bytes,
  which yields both better quality and smaller files
- now using the correct colorspace (TODO: move conversion to libswscale)

version 2013-02-14 Rl "Valentine's Day" version:
- made strip division more robust
- minimized bruteforcing the number of strips,
  (costs some R/D but speeds up compession a lot), the heuristic
  assumption is that score as a function of the number of strips has
  one wide minimum which moves slowly, of course not fully true
- simplified codebook generation,
  the old code was meant for other optimizations than we actually do
- optimized the codebook generation / error estimation for MODE_MC

version 2013-04-28 Rl
- bugfixed codebook optimization logic

version 2014-01-20 Rl
- made the encoder compatible with vintage decoders
  and added some yet unused code for possible future
  incremental codebook updates
- fixed a small memory leak

version 2014-01-21 Rl
- believe it or not, now we get even smaller files, with better quality
  (which means I missed an optimization earlier :)
Signed-off-by: Diego Biurrun <diego@biurrun.de>

With permission of Tomas Härdin applied by Rl aetey.se
Signed-off-by: Diego Biurrun <diego@biurrun.de>

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

If using the winstore compat library, a fallback LoadLibrary
function does exist, that only calls LoadPackagedLibrary though
(which doesn't work for dynamically loading d3d11 DLLs).

Therefore explicitly check the targeted API family instead.

Make this check a reusable HAVE_* component which other parts
of the libraries can check when necessary as well.
Signed-off-by: Martin Storsjö <martin@martin.st>

Currently, the tags enforced and set on the segmenter muxer level
mismatch what the mp4/ismv muxer uses (since 713efb2c).

Skip the codec_tag altogether here, to let the user (try to) set
whichever codec/tag is preferred; the individual chained muxer will
reject invalid codecs anyway.
Signed-off-by: Martin Storsjö <martin@martin.st>

The use of this SEI is for backward compatibility in HLG HDR systems:
older devices that cannot interpret the "arib-std-b67" transfer will
get the compatible transfer (usually bt709 or bt2020) from the VUI,
while newer devices that can interpret HDR will read the SEI and use
its value instead.
Signed-off-by: Vittorio Giovara <vittorio.giovara@gmail.com>

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

This fixes a segfault (originally found in Movian, but traced to libav)
when decoding subtitles because only an array of rects is allocated,
but not the actual structs it contains. The issue was probably
introduced in commit 23833236 where the loop to allocate the rects in
the array was thrown away.
Signed-off-by: Vittorio Giovara <vittorio.giovara@gmail.com>

Hardware accelerated decoding generally uses AVHWFramesContext for pool
allocation of hardware surfaces. These are setup to allocate surfaces
aligned to hardware and hwaccel API requirements. Due to the
architecture, av_hwframe_get_buffer() will return AVFrames with
the dimensions set to the aligned sizes.

This causes some decoders (like hevc) return these aligned size as
final frame size, instead of cropping them to the video's actual
dimensions. To make sure this doesn't happen, crop the frame to the
size the decoder expects when ff_get_buffer() is called.
Signed-off-by: Luca Barbato <lu_zero@gentoo.org>

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

Basically copied from VLC (LGPL):

http://git.videolan.org/?p=vlc.git;a=blob;f=modules/video_output/win32/direct3d11.c;h=e9fcb83dcabfe778f26e63d19f218caf06a7c3ae;hb=HEAD#l1482
http://git.videolan.org/?p=vlc.git;a=blob;f=modules/codec/avcodec/d3d11va.c;h=85e7d25caebc059a9770da2ef4bb8fe90816d76d;hb=HEAD#l599Signed-off-by: Luca Barbato <lu_zero@gentoo.org>

Some devices (some phones, apparently) will support only this opaque
format. Of course this won't work with CLI, because copying data
directly is not supported.

Automatic frame allocation (setting AVCodecContext.hw_device_ctx) does
not support this mode, even if it's the only supported mode. But since
opaque surfaces are generally less useful, that's probably ok.
Signed-off-by: Luca Barbato <lu_zero@gentoo.org>

Makes dealing with formats that can not be used for staging textures
easier (DXGI_FORMAT_420_OPAQUE). It also saves memory if the staging
texture is never needed, so this is a good thing.
Signed-off-by: Luca Barbato <lu_zero@gentoo.org>