vaapipostproc: reset deinterlacer state when there is a discontinuity.

Reset deinterlacer state, i.e. past reference frames used for advanced
deinterlacing, when there is some discontinuity detected in the course
of processing source buffers.

This fixes support for advanced deinterlacing when a seek occurred.

https://bugzilla.gnome.org/show_bug.cgi?id=720375

[fixed type of pts_diff variable, fetch previous buffer PTS from the
 history buffer, reduce heuristic for detecting discontinuity]
Signed-off-by: Gwenole Beauchesne <gwenole.beauchesne@intel.com>

vaapipostproc: add support for crop regions in VPP mode.

Apply video cropping regions stored in GstVideoCropMeta, or in older
GstVaapiSurfaceProxy representation, to VPP pipelines. In non-VPP modes,
the crop meta are already propagated to the output buffers.

https://bugzilla.gnome.org/show_bug.cgi?id=720730

vaapipostproc: make deinterlace-mode behave as expected.

deinterlace-mode didn't behave in the way you'd expect if you have
past experience of the deinterlace element. There were two bugs:

 1. "auto" mode wouldn't deinterlace "interleaved" buffers, only "mixed".
 2. "force" mode wouldn't deinterlace "mixed" buffers flagged as progressive.

Fix these up, and add assertions and error messages to detect cases that
aren't handled.

https://bugzilla.gnome.org/show_bug.cgi?id=726361

Signed-off-by: Simon Farnsworth <simon.farnsworth@onelan.co.uk>
Signed-off-by: Gwenole Beauchesne <gwenole.beauchesne@intel.com>

vaapidecode: do not discard video info props when the format changed.

gst_video_info_set_format() does not preserve video info properties. In
order to keep important information in the caps such as interlace mode,
framerate, pixel aspect ratio, ... we need to manually copy back those
properties after setting the new video format.

https://bugzilla.gnome.org/show_bug.cgi?id=722276

vaapidecode: plug a memory leak.

It can happen that there is a pool provided that does not advertise
the vappivideometa. We should unref that pool before using our own.

Discovered with vaapidecode ! {glimagesink,cluttersink}

https://bugzilla.gnome.org/show_bug.cgi?id=724957

[fixed compilation by adding the missing semi-colon]
Signed-off-by: Gwenole Beauchesne <gwenole.beauchesne@intel.com>

vaapidecode: parse source data until a frame is obtained.

Parse any pending data until a complete frame is obtained. This is a
memory optimization to avoid expansion of video packets stuffed into
the GstAdapter, and a fix to EOS condition to detect there is actually
pending data that needs to be decoded, and subsequently output.

https://bugzilla.gnome.org/show_bug.cgi?id=731831

encoder: h264: fix multiple slices support in packed headers mode.

Handle packedi slice headers and packed raw data on a per-slice basis,
which is necessary for multi slice encoding.

encoder: add infrastructure for per-slice handling of packed headers.

The packed slice header and packed raw data need to be paired with
the submission of VAEncSliceHeaderParameterBuffer. So handle them
on a per-slice basis insted of a per-picture basis.

[removed useless initializer]
Signed-off-by: Gwenole Beauchesne <gwenole.beauchesne@intel.com>

vaapisink: fix initialization with "drm" display type.

Force early initializatin of the GstVaapiDisplay so that to make sure
that the sink element display object is presented first to upstream
elements, as it will be correctly featuring the requested display type
by the user.

Otherwise, we might end up in situations where a VA/X11 display is
initialized in vaapidecode, then we try VA/DRM display in vaapisink
(as requested by the "display" property), but this would cause a failure
because we cannot acquire a DRM display that was previously acquired
through another backend (e.g. VA/X11).

plugins: fix initialization with foreign context.

When a new display is settled through GstElement::set_context() (>= 1.2),
or GstVideoContext::set_context() (<= 1.0), then we shall also update the
associated display type.

plugins: add built-in video parsers as "vaapiparse" element.

The built-in video parsers elements are built into a single DSO named
libgstvaapi_parse.so. The various video parsers could be accessed as
vaapiparse_CODEC.

For now, this only includes a modified version of h264parse so that to
support H.264 MVC encoded streams.

decoder: h264: cope with new gst_h264_quant_matrix_*() interfaces.

New gst_h264_quant_matrix_*_get_raster_from_zigzag() were renamed
from gst_h264_video_quant_matrix_*_get_raster_from_zigzag().

codecparsers: update to gst-vaapi-branch commit d6325ac.

7d8d045 h264parse: use new gst_h264_video_calculate_framerate()
d2f965a h264parse: set field_pic_flag when parsing a slice header
24c15b8 Import h264parse
a9283e5 bytereader: Use concistant derefence method
a8252c6 bytereader: Use pointer instead of index access
b1bebfc Import GstBitReader and GstByteReader
2f58788 h264: recognize SVC NAL units
4335da5 h264: fix SPS copy code for MVC
cf9b6dc h264: fix quantization matrix conversion routine names
b11ce2a h264: add gst_h264_video_calculate_framerate()
126dc6f add C++ guards for MPEG-4 and VP8 parsers

decoder: h264: factor out DPB pruning for MVC.

Factor out the removal process of unused inter-view only reference
pictures from the DPB, prior to the possible insertion of the current
picture.

Ideally, the compiler could still opt for generating two loops. But
at least, the code is now clearer for maintenance.

decoder: h264: clean-ups.

Fix GST_VAAPI_PICTURE_IS_{INTER_VIEW,ANCHOR}() definitions to use
the base GST_VAAPI_PICTURE_FLAG_IS_SET() macro.

decoder: h264: improve pruning of unused MVC inter-view frames.

Improve process for the removal of pictures from DPB before possible
insertion of the current picture (C.4.4) for H.264 MVC inter-view only
reference components. In particular, handle cases where picture to be
inserted is not the last one of the access unit and if it was already
output and is no longer marked as used for reference, including for
decoding next view components within the same access unit.

decoder: h264: improve DPB bumping process for MVC.

While invoking the DPB bumping process in presence of many views,
it could be necessary to output previous pictures that are ready,
in a whole. i.e. emitting all view components from the very first
view order index zero to the very last one in its original access
unit; and not starting from the view order index of the picture
that caused the DPB bumping process to be invoked.

As a reminder, the maximum number of frames in DPB for MultiView
High profile with more than 2 views is not necessarily a multiple
of the number of views.

This fixes decoding of MVCNV-4.264.

decoder: h264: fix inter-view references array growth.

Let the utility layer handle dynamic growth of the inter-view pictures
array. By definition, setting a new size to the array will effectively
grow the array, but would also fill in the newly created elements with
empty entries (NULL), thus also increasing the reported length, which
is not correct.

decoder: h264: reduce ReferenceFrames entries to the essential set.

When decoding Multiview High profile streams with a large number of
views, it is not possible to make the VAPictureParameterBufferH264.
ReferenceFrames[] array hold the complete DPB, with all possibly
active pictures to be used for inter-view prediction in the current
access unit.

So reduce the scope of the ReferenceFrames[] array to only include
the set of reference pictures that are going to be used for decoding
the current picture. Basically, this is a union of all RefPicListX[]
array, for all slices constituting the decoded picture.

decoder: h264: fix MVC inter-view prediction process.

The inter-view reference components and inter-view only reference
components that are included in the reference picture lists shall
be considered as not being marked as "used for short-term reference"
or "used for long-term reference". This means that reference flags
should all be removed from VAPictureH264.flags.

This fixes decoding of MVCNV-2.264.

decoder: h264: fix detection of profile changes for MVC.

If the VA driver exposes ad-hoc H.264 MVC profiles, then we have to
be careful to detect profiles changes and not reset the underlying
VA context erroneously. In MVC situations, we could indeed get a
profile_idc change for every SPS that gets activated, alternatively
(base-view -> non-base view -> base-view, etc.).

An improved fix would be to characterize the exact profile to use
once and for all when SPS NAL units are parsed. This would also
allow for fallbacks to a base-view decoding only mode.

encoder: h264: drop extraneous definitions.

Re-use definitions from the codecparser headers instead of duplicating
them here again. That covers NALU definitions and slice types.

encoder: h264: remove unnecessary calcualtion of max_pic_order_cnt.

https://bugzilla.gnome.org/show_bug.cgi?id=727418

encoder: h264: don't allow CABAC with Extended profile.

The H.264 specification does not support CABAC entropy coding for the
Extended profile.

https://bugzilla.gnome.org/show_bug.cgi?id=727418

encoder: h264: use packed headers mode for MVC encoding.

Exclusively use VA drivers that support raw packed headers for encoding.
i.e. simply submit packed headers Subset SPS and Prefix NAL units. This
provides for better compatibility accross the various VA drivers and HW
generations since no particular API is needed beyond what readily exists.

encoder: h264: add support for packed slice headers.

https://bugzilla.gnome.org/show_bug.cgi?id=722905

encoder: h264: store subset sps to generate the codec-data

Store the SubsetSPS nal unit which we need for MVC specific
codec_data generation.

encoder: h264: fix MVC pipeline hang while encoding with B-frames.

Since we are encoding each view independently from each other, we
need a higher number of pre-allocated surfaces to be used as the
reconstructed frames. For Stereo High profile encoding, this means
to effectively double the number of frames to be stored in the DPB.

encoder: h264: add initial support for H.264 Stereo High profile.

Add initial support for Subset SPS, Prefix NAL and Slice Extension NAL
for non-base-view streams encoding, and the usual SPS, PPS and Slice
NALs for base-view encoding.

The H.264 Stereo High profile encoding mode will be turned on when the
"num-views" parameter is set to 2. The source (raw) YUV frames will be
considered as Left/Right view, alternatively.

Each of the two views has its own frames reordering pool and reference
frames list management system. Inter-view references are not supported
yet, so the views are encoded independently from each other.

Signed-off-by: Li Xiaowei <xiaowei.a.li@intel.com>
[limited to Stereo High profile per the definition of MAX_NUM_VIEWS]
Signed-off-by: Gwenole Beauchesne <gwenole.beauchesne@intel.com>

encoder: h264: wrap pools for refs and frames reordering.

Create structures to maintain the reference frames list (RefPool) and
frames reordering (ReorderPool) logic.

This is a prerequisite for H.264 MVC support.

Signed-off-by: Li Xiaowei <xiaowei.a.li@intel.com>

encoder: h264: add provisional support for subset SPS headers.

Add provisions to write subset SPS headers to the bitstream in view
to supporting the H.264 MVC specification.

This assumes the libva "staging" branch is in use.

Signed-off-by: Li Xiaowei <xiaowei.a.li@intel.com>

utils: add H.264 MVC profiles.

Add "MultiView High" and "Stereo High" definitions.

Signed-off-by: Li Xiaowei <xiaowei.a.li@intel.com>
[require VA-API >= 0.35.2 for MVC profiles]
Signed-off-by: Gwenole Beauchesne <gwenole.beauchesne@intel.com>

utils: only enable VP8 profiles for newer VA-API versions.

VP8 decoding API appeared in VA-API >= 0.35.0. So, disable mappings
involving VP8 codec on earlier versions of the API.

decoder: h264: compute view ids only once per slice.

Optimize lookups of view ids / view order indices by caching the result
of the calculatiosn right into the GstVaapiParserInfoH264 struct. This
terribly simplifies is_new_access_unit() and find_first_field() functions.

decoder: h264: add support for MVC interlaced streams.

Fix support for MVC Stereo High profile streams with interlaced frames.
Also improve the detection logic of the first field.

decoder: h264: add MVC profiles compatibility logic.

Add safe fallbacks for MVC profiles:
- all MultiView High profile streams with 2 views at most can be decoded
  with a Stereo High profile compliant decoder ;
- all Stereo High profile streams with only progressive views can be
  decoded with a MultiView High profile compliant decoder ;
- all drivers that support slice-level decoding could normally support
  MVC profiles when the DPB holds at most 16 frames.

decoder: h264: add initial support for MVC.

https://bugzilla.gnome.org/show_bug.cgi?id=721772

decoder: h264: dynamically allocate the DPB.

Dynamically allocate the Decoded Picture Buffer (DPB) and add provisions
for supporting the MVC allocation requirements.

decoder: h264: fix detection of access unit boundaries.

In order to have a stricter conforming implementation, we need to carefully
detect access unit boundaries. Additional operations could be necessary to
perform at those boundaries.

decoder: h264: detect the first VCL NAL unit of a picture for MVC.

Detect the first VCL NAL unit of a picture for MVC, based on the
view_id as per H.7.4.1.2.4. Note that we only need to detect new
view components.

Signed-off-by: Gwenole Beauchesne <gwenole.beauchesne@intel.com>

decoder: h264: properly handle Prefix NAL units.

Always cache the previous NAL unit so that we could check whether
there is a Prefix NAL unit immediately preceding the current slice
or IDR NAL unit. In that case, the NAL unit metadata is copied into
the current NAL unit. Otherwise, some default values are inferred,
tentatively. e.g. view_id shall be set to 0 and inter_view_flag to 1.

[infer default values for slice if previous NAL was not a Prefix]
Signed-off-by: Gwenole Beauchesne <gwenole.beauchesne@intel.com>

decoder: h264: add support for MVC base views.

Allow decoding for base views of MVC encoded streams. For now, just skip
the slice extension and prefix NAL units, and skip non-base view frames.

Signed-off-by: Xiaowei Li <xiaowei.a.li@intel.com>
[fixed memory leak, improved check for MVC NAL units]
Signed-off-by: Gwenole Beauchesne <gwenole.beauchesne@intel.com>

decoder: h264: simplify storage of decoded picture into DPB.

Factor out process by which the decoded picture with the lowest POC
is found, and possibly output. Likewise, the storage and marking of
a reference decoded, or non-reference decoded picture, into the DPB
could also be simplified as they mostly share the same operations.

decoder: h264: minor clean-ups.

Make init_picture_ref_lists() more consistent with other functions
related to the reference marking process by supplying the current
picture as argument.

display: add utility function to query VA driver name.

Add gst_vaapi_display_get_vendor_string() helper function to query
the underlying VA driver name. The display object owns the resulting
string, so it shall not be deallocated.

That function is thread-safe. It could be used for debugging purposes,
for instance.

display: make cache maintenance really MT-safe.

Make sure to initialize one GstVaapiDisplay at a time, even in threaded
environments. This makes sure the display cache is also consistent
during the whole display creation process. In the former implementation,
there were risks that display cache got updated in another thread.

context: allow dynamic growth of VA surfaces pool.

Add support for dynamic growth of the VA surfaces pool. For decoding,
this implies the recreation of the underlying VA context, as per the
requirement from VA-API. Besides, only increases are supported, not
shrinks.

context: reset VA context if VA surfaces set changed.

It is a requirement from VA-API specification that the VA context got
from vaCreateContext(), for decoding purposes, binds the supplied set
of VA surfaces. This means that if the set of VA surfaces is to be
changed for the current decode session, then the VA context needs to
be recreated with the new set of VA surfaces.

decoder: h264: fix assignment of LongTermFrameIdx.

Complement fix committed as e95a42e.

The H.264 AVC standard has to say: if the field is part of a reference
frame or a complementary reference field pair, and the other field of
the same reference frame or complementary reference field pair is also
marked as "used for long-term reference", the reference frame or
complementary reference field pair is also marked as "used for long-term
reference" and assigned LongTermFrameIdx equal to long_term_frame_idx.

This fixes decoding of MR9_BT_B in strict mode.

https://bugs.freedesktop.org/show_bug.cgi?id=64624
https://bugzilla.gnome.org/show_bug.cgi?id=724518

decoder: h264: properly support grayscale formats.

Request the correct chroma format for decoding grayscale streams.
i.e. make lookups of the VA chroma format more generic, thus possibly
supporting more formats in the future.

This means that, if a VA driver doesn't support grayscale formats,
it is now going to fail. We cannot safely assume that maybe grayscale
was implemented on top of some YUV 4:2:0 with the chroma components
all set to 0x80.

build: fix source file modes.

A few source files are marked executable in error - fix them

https://bugzilla.gnome.org/show_bug.cgi?id=723748

Signed-off-by: Simon Farnsworth <simon.farnsworth@onelan.co.uk>

build: fix conditional compilation of VP8 decoder.

https://bugzilla.gnome.org/show_bug.cgi?id=729170

[added check for VASliceParameterBufferBase fields]
Signed-off-by: Gwenole Beauchesne <gwenole.beauchesne@intel.com>

build: fix make dist for codecparsers.

codecparsers: update to gst-vaapi-branch commit eaa3f7e.

h264: fix parsing of slice groups for map type = 2

codecparsers: update to gst-vaapi branch commit f44edfc.

h264: fix derivation of default scaling lists

decoder: h264: fix long-term reference picture marking process.

Fix reference picture marking process with memory_management_control_op
set to 3 and 6, i.e. assign LongTermFrameIdx to a short-term reference
picture, or the current picture.

This fixes decoding of FRExt_MMCO4_Sony_B.

https://bugs.freedesktop.org/show_bug.cgi?id=64624
https://bugzilla.gnome.org/show_bug.cgi?id=724518

[squashed, edited to use GST_VAAPI_PICTURE_IS_COMPLETE() macro]
Signed-off-by: Gwenole Beauchesne <gwenole.beauchesne@intel.com>

decoder: h264: fix initialization of RefPicLists for multiple slices.

The initialization of reference picture lists (8.2.4.2) applies to all
slices. So, the RefPicList0/1 lists need to be constructed prior to
each slice submission to the HW decoder.

This fixes decoding of video sequences where frames are encoded with
multiple slices of different types, e.g. 4 slices in this order I, P,
I, and P. More precisely, CABAST3_Sony_E and CABASTBR3_Sony_B.

https://bugzilla.gnome.org/show_bug.cgi?id=724518

decoder: h264: skip SPS extension and auxiliary slice NALs.

When NAL units of type 13 (SPS extension) or type 19 (auxiliary slice)
are present in a video, decoders shall perform the (optional) decoding
process specified for these NAL units or shall ignore them (7.4.1).

Implement option 2 (skip) for now, as alpha composition is not
supported yet during the decoding process.

This fixes decoding of the primary coded video in alphaconformanceG.

https://bugzilla.gnome.org/show_bug.cgi?id=703928
https://bugzilla.gnome.org/show_bug.cgi?id=728869
https://bugzilla.gnome.org/show_bug.cgi?id=724518

[skip NAL units earlier, i.e. at parsing time]
Signed-off-by: Gwenole Beauchesne <gwenole.beauchesne@intel.com>

decoder: h264: fix slice data bit offset with MVC NAL units.

When MVC slice NAL units (coded slice extension and prefix NAL) are
present, the number of NAL header bytes is 3, not 1 as usual.

Signed-off-by: Li Xiaowei <xiaowei.a.li@intel.com>
Signed-off-by: Gwenole Beauchesne <gwenole.beauchesne@intel.com>

decoder: h264: fix activation of picture and sequence parameters.

At the time the first VCL NAL unit of a primary coded picture is found,
and if that NAL unit was parsed to be an SPS or PPS, then the entries
in the parser may have been overriden. This means that, when the picture
is to be decoded, slice_hdr->pps could point to an invalid (the next)
PPS entry.

So, one way to solve this problem is to not use the parser PPS and
SPS info but rather maintain our own activation chain in the decoder.

https://bugzilla.gnome.org/show_bug.cgi?id=724519
https://bugzilla.gnome.org/show_bug.cgi?id=724518

decoder: h264: retain SEI messages until the end of frame.

Retain the SEI messages that were parsed from the access unit until we
have completely decoded the current frame. This is done so that we can
peek at that data whenever necessary during decoding. e.g. for exposing
3D stereoscopic information at a later stage.

decoder: h264: add support for grayscale encoded clips.

Fix support for grayscale encoded video clips, and possibly others if
the underlying driver supports the non-YUV 4:2:0 formats. i.e. defer
the decision that a surface with the desired chroma format is not
supported to the actual VA driver implementation.

https://bugzilla.gnome.org/show_bug.cgi?id=728144

decoder: default to YUV 4:2:0 VA surfaces.

Cope with context changes to support non-YUV 4:2:0 VA surfaces. Still,
make sure all codecs use YUV 4:2:0 output format for now, by default.

decoder: re-indent GstVaapiDecoder base object.

encoder: derive chroma type from video format.

Cope with previous VA context change to derive the correct surface chroma
type from the input video format.

context: add support for non-YUV 4:2:0 formats.

Don't force allocation of VA surfaces in YUV 4:2:0 format. Rather, allow
for the upper layer to specify the desired chroma type. If the chroma
type field is not set (or yields zero), then YUV 4:2:0 format is used
by default.

vp8: fix per-segment deblocking filter level in relative mode.

Fix possible bug when a per-segment deblocking filter level value
needs to be set in non-absolute mode, i.e. when the loop filter update
value is negative in delta mode.

Also clamp the resulting filter level value to 0..63 range.

vp8: fix check for disabling the loop filter (again).

Improve condition to disable the loop filter. The previous heuristic
used to check all filter levels, for all segments. It turns out that
only the base filter_level value defined in the frame header needs
to be checked.

This fixes 00-comprehensive-013.

build: fix make dist with certain conditionals not met.

Fix generation of source tarballs when certain conditionals are not
met. e.g. always include all buildable codecparsers sources in the
distribution tarball, fix plug-in element sources set to include X11
and encoder bits.

build: add missing files for GStreamer 0.10.

Add missing GstVideoEncoder implementation files to fix build with ancient
GStreamer 0.10 stack.

https://bugzilla.gnome.org/show_bug.cgi?id=723964

build: add missing files for VP8 bitstream parser.

Fix make dist for building the VP8 bitstream parser.

vp8: allow compilation without the built-in libvpx.

The built-in libvpx serves multiple purposes, among which the most
important ones could be: track the most up-to-date, and optimized,
range decoder; allow for future hybrid implementations (non-VLD);
and have a completely independent range decoder implementation.

vp8: propagate PTS from demux frame.

gst_adapter_prev_pts() is forbidden within libgstvaapi. Besides, the demuxer
or parser would already have determined the PTS from a previous stage.

vp8: fix compilation with built-in libvpx.

Apply correct patch from fd.o #722760 to fix several issues: update the
license terms to LGPLv2.1+, fix dependencies to built-in libvpx and fix
make dist.

vp8: use range decoder from libvpx.

Add libvpx submodule that tracks the upstream version 1.3.0. This is
needed to build a libgstcodecparsers_vpx.so library with all symbols
placed into the GSTREAMER namespace.

vp8: fix check for disabling the loop filter.

Add initial VP8 decoder.

https://bugzilla.gnome.org/show_bug.cgi?id=722761

[complete overhaul, fixed support for resolution changes]
Signed-off-by: Gwenole Beauchesne <gwenole.beauchesne@intel.com>

decoder: h264: cope with new gst_h264_parser_parse_sei() interface.

The gst_h264_parse_parse_sei() function now returns an array of SEI
messages, instead of a single SEI message. Reason: it is allowed to
have several SEI messages packed into a single SEI NAL unit, instead
of multiple NAL units.

codecparsers: update to gst-vaapi-branch commit a454f86.

b2eb5f6 vp8: rename dboolhuff symbols
b74a881 vp8: add GStreamer native utilities
2940ac6 add VP8 bitstream parser

codecparsers: update to gst-vaapi-branch commit d459bc5.

d459bc5 h264: set framerate even for interlaced videos
c78b82c h264: add support for Recovery Point SEI message
7693bac h264: add support for Frame Packing Arrangement SEI message
31fafa7 h264: add support for Stereo Video Information SEI message
8b113a6 h264: parse seq_parameter_set_mvc_extension()
040f9b8 h264: parse MVC syntax elements
cc18ef3 h264: add nal_reader_skip_long() helper
7e76a48 h264: fix slice_header() parsing for MVC
caf46d8 h264: add gst_h264_parse_nalu_header() helper
f75074e h264: add gst_h264_parse_sps_data() helper
798c397 h264: clean-up gst_h264_parser_parse_sei_message()
4e36737 h264: fix skipping of unsupported SEI messages
5300766 h264: fix SEI buffering_period() parsing

codecparsers: update to gst-vaapi-branch commit 8fadf40.

8fadf40 h264: Fix multiple SEI messages in one SEI RBSP parsing.
644825f h265: remove trailling 0x00 bytes as the spec doesn't allow them
95f9f0f h264: remove trailling 0x00 bytes as the spec doesn't allow them
766007b h265: Initialize pointer correctly that is never assigned but freed in error cases
8ec5816 h265: Fix segfault when parsing HRD parameter
5b1730f h265: Fix segfault when parsing VPS
983b7f7 h265: prevent to overrun chroma_weight_l0_flag
7ba641d h265: Fix debug output
d9f9f9b h264: not all startcodes should have 3-byte 0 prefix

decoder: h264: fix robustness patch for bytestream format.

Fix parser and decoder state to sync at the right locations. This is
because we could reset the parser state, while the decoder state was
not copied yet, e.g. when parsing several NAL units from multiple frames
whereas the current frame was not decoded yet.

This is a regression brought in by commit 6fe5496.

build: fix pkgconfig file names (again).

It turns out it is more convenient to have only pkgconfig files named
after the installed GStreamer API version (1.0) instead of using all
possible subsequent names from that (1.0, 1.2, 1.4). i.e. they conflict
altogether anyway, so align pkgconfig file names to that.

build: fix packaging for GStreamer 1.2.

Fix gstreamer-vaapi includedir for GStreamer 1.2 setups. i.e. use
the pkgconfig version (1.0) instead of the intended API version (1.2).
libgstvaapi1.0-dev and libgstvaapi1.2-dev packages will now conflict,
as would core GStreamer 1.0 and GStreamer 1.2 dev packages anyway.

Bump version for development.

debian: fix trailing whitespace in description.

debian: fix package description.

Try to improve package description for the compiled plug-in elements
available in there. e.g. only display vaapidownload and vaapiupload
for GStreamer 0.10 builds, display vaapiencode_* elements when VA
encoding is enabled, etc.

Also increase the copyright notice date.

build: fix warnings on 64-bit platforms.

build: fix for older versions of VA-API (< 0.34.0).

Fix build with older versions of VA-API (< 0.34.0), or versions without
good enough headers for encoding support for instance.

0.5.8.

README: updates.

VA-API up to 0.34.0 is actually supported. Mention new video encoding
support. Update copyright years, list of supported Intel HD Graphics
hardware.

NEWS: updates.

tests: test-filter: fix "deinterlace" option parse.

Default to GST_VAAPI_DEINTERLACE_METHOD_NONE if no "deinterlace" option
string was provided, i.e. if it remained set to NULL.

libs: factor out usages of vaGetConfigAttributes().

Add gst_vaapi_get_config_attribute() helper function that takes a
GstVaapiDisplay and the rest of the arguments with VA types. The aim
is to have thread-safe VA helpers by default.

libs: re-indent all source code related to VA utilities.

libs: add missing file (libgstvaapi_priv_check.h).

encoder: notify the encoder of the submitted packed headers.

Make sure to configure the encoder with the set of packed headers we
intend to generate and submit. i.e. make selection of packed headers
to submit more robust.

encoder: fix and factor out check for supported rate-control modes.

Cache the first compatible GstVaapiProfile found if the encoder is not
configured yet. Next, factor out the code to check for the supported
rate-control modes by moving out vaGetConfigAttributes() to a separate
function, while also making sure that the attribute type is actually
supported by the encoder.

Also fix the default set of supported rate control modes to not the
"none" variant. It's totally useless to expose it at this point.

context: move rate-control mode to encoder specific config.

Move usage-specific config out of the common GstVaapiContextInfo.
Create a specialized config for encoding and move rate-control mode
to there.

context: introduce concept of usage.

Introduce GstVaapiContextUsage so that to explicitly determine the
usage of a VA context. This is useful in view to simplifying the
creation of VA context for VPP too.