The four examples (audio/video encoding/decoding) are completely
independent so it makes little sense to have them all in one file.

It is simpler and more efficient.

The four examples (audio/video encoding/decoding) are completely
independent so it makes little sense to have them all in one file.

This is intended as a replacement for the 'split' function exported by
some parsers.

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

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

This makes them easier to search for.

The Intel binary iHD driver does not support the
VASurfaceAttribMemoryType, so surface allocation will fail when using
it.

ptrdiff_t is the correct type for array strides and similar.

It is supported by the NVIDIA video SDK 7.
Signed-off-by: NLuca Barbato <lu_zero@gentoo.org>

See https://software.intel.com/en-us/articles/copying-accelerated-video-decode-frame-buffers

Deprecates struct vaapi_context and the installed header vaapi.h,
to be removed at the next version bump.

Signed-off-by: NBurt P <pburt0@gmail.com>
Signed-off-by: NDiego Biurrun <diego@biurrun.de>
Signed-off-by: NLuca Barbato <lu_zero@gentoo.org>

Unescaped literal left braces are deprecated and a warning was added in
Perl 5.22.

The driver being used is detected inside av_hwdevice_ctx_init() and
the quirks field then set from a table of known device.  If this
behaviour is unwanted, the user can also set the quirks field
manually.

Also adds the Intel i965 driver quirk (it does not destroy parameter
buffers used in a call to vaRenderPicture()) and detects that driver
to set it.

P010 is the 10-bit variant of NV12 (planar luma, packed chroma), using two
bytes per component to store 10-bit data plus 6-bit zeroes in the LSBs.
Signed-off-by: NAnton Khirnov <anton@khirnov.net>

While it is less featureful (and slower) than the built-in H264
decoder, one could potentially want to use it to take advantage
of the cisco patent license offer.
Signed-off-by: NMartin Storsjö <martin@martin.st>

Currently it's exported as AVFrame.pkt_pts, which is also the only use
for that field. The reason it is done like this is that lavc used to
export various codec-specific "timing" information in AVFrame.pts, which
is not done anymore.

Since it is confusing to the callers to have a separate field which is
used only for decoder timestamps and nothing else, deprecate pkt_pts and
use just AVFrame.pts everywhere.

For now it will only be used by the default get_buffer2 callback for
allocating hw frames.

Signed-off-by: NPaul B Mahol <onemda@gmail.com>
Signed-off-by: NVittorio Giovara <vittorio.giovara@gmail.com>

Signed-off-by: NPaul B Mahol <onemda@gmail.com>
Signed-off-by: NVittorio Giovara <vittorio.giovara@gmail.com>

This allows callers with avio write callbacks to get the bytestream
positions that correspond to keyframes, suitable for live streaming.

In the simplest form, a caller could expect that a header is written
to the bytestream during the avformat_write_header, and the data
output to the avio context during e.g. av_write_frame corresponds
exactly to the current packet passed in.

When combined with av_interleaved_write_frame, and with muxers that
do buffering (most muxers that do some sort of fragmenting or
clustering), the mapping from input data to bytestream positions
is nontrivial.

This allows callers to get directly information about what part
of the bytestream is what, without having to resort to assumptions
about the muxer behaviour.

One keyframe/fragment/block can still be split into multiple (if
they are larger than the aviocontext buffer), which would call
the callback with e.g. AVIO_DATA_MARKER_SYNC_POINT, followed by
AVIO_DATA_MARKER_UNKNOWN for the second time it is called with
the following data.
Signed-off-by: NMartin Storsjö <martin@martin.st>