vaapipostproc: Add string representation of VPP functions to ElementFactoy Klass

Added the same Klass specifications used in other upstream
video postprocessing elements like videoconvert, videoscale,
videobalance and deinterlace.
An example use case is for this is to help the playsink
to autoplug the hardware accelerated deinterlacer.

vaapipostproc: Tweak the output video format setting to enable the autoplugging

This is a workaround until auto-plugging is fixed when
format=ENCODED + memory:VASurface caps feature are provided.

Use the downstream negotiated video format as the output video format
if the user didn't ask for the colorspace conversion explicitly.
Usecase: This will help to connect elements like videoscale, videorate etc
to vaapipostproc.

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

vaapipostproc: allow user defined scaling mode.

Add new "scale-method" property to expose the scaling mode to use during
video processing. Note that this is only a hint, and the actual behaviour
may differ from implementation (VA driver) to implementation.

filter: add initial support for high quality scaling.

Add support for video scaling options in VPP pipelines. Only the
DEFAULT mode is bound to exist. Others might be folded into that
mode.

filter: re-indent all GstVaapiFilter related source code.

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

2218b02 h264parse: expose parsed profile and level to downstream
3dbfab4 h264parse: return flushing if we get chained while being set to READY
d40fa8b h264: fix frame packing SEI parsing
32d40be h264: Use proper bit_reader api while parsing buffering_period SEI
b3e022e h264: initialize some fields of pic_timing structure
a70661d vc1: fix expected level in sequence-layer parsing unit test
6cee88d vc1: fix level values for simple/main profile
356c189 vc1: add unit test for sequence-layer parsing
ab9f641 vc1: take care of endianness when parsing sequence-layer
8dc8e35 mpeg4: fix vlc table used for sprite trajectory

vaapidecode: Expose the supported profiles as caps to upstream

This will allows the playbin to fallback to Software Decoder
if the Hardware Decoder does not support a particular profile.

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

encode: Attach the codec-data to out caps only based on negotiated caps

Attach the codec_data to out_caps only if downstream needed.
For eg: h264 encoder doesn't need to stuff codec_data to the
src caps if the negotiated caps has a stream format of byte-stream.

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

configure: echoing installation prefix path

display: add support for DRM Render-Nodes.

Add support for DRM Render-Nodes. This is a new feature that appeared
in kernel 3.12 for experimentation purposes, but was later declared
stable enough in kernel 3.15 for getting enabled by default.

This allows headless usages without authentication at all, i.e. usages
through plain ssh connections is possible.

vaapisink: clean-ups (indentation, drop unused variables).

vaapisink: fix GstNavigation "key-press" / "key-release" events.

Fix arguments to XkbKeycodeToKeysym() for converting an X11 keycode
to a KeySym. In particular, there is no such Window argument. Also
make sure to check for, and use, the correct <X11/XKBlib.h> header
where that new function is defined. Otherwise, default to the older
XKeycodeToKeysym() function.

vaapisink: fix GstNavigation "mouse-move" event.

Really use the motion event coordinates to propagate the "mouse-move"
event to upper layer, instead of those from a button event. Those are
technically the same though.

vaapisink: implement the GstNavigation interface

This is useful for things like DVD menus, where key/mouse events
would need to be forwarded from the upstream sink element.

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

vaapipostproc: fix deinterlacing from non VA memory buffers.

When we copy a buffer because we're moving it into VA-API memory, we
need to copy flags. Otherwise, interlaced YUV buffers from a capture
source (e.g. V4L2) don't get flagged as interlaced.

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

Signed-off-by: Simon Farnsworth <simon.farnsworth@onelan.co.uk>
[reversed order of gst_buffer_copy_into() flags to match <1.0 code]
Signed-off-by: Gwenole Beauchesne <gwenole.beauchesne@intel.com>

vaapipostproc: add support for GLTextureUploadMeta output.

This allows for vaapipostproc to be chained to the glimagesink element
for instance.

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

vaapipostproc: add support for "download" capability.

Allow implicit conversions to raw video formats, while still keeping
VA surfaces underneath. This allows for chaining the vaapipostproc
element to a software-only element that takes care of maps/unmaps.
e.g. xvimagesink.

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

vaapipostproc: use pooled vaapi video meta.

Use pooled GstVaapiVideoMeta information, i.e. always allocate that on
video buffer allocation. Also optimize copy of additional metadata info
into the resulting video buffer: only copy the video cropping info and
the source surface proxy.

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

Signed-off-by: Sreerenj Balachandran <sreerenj.balachandran@intel.com>
[fixed proxy leak, fixed double free on error, optimized meta copy]
Signed-off-by: Gwenole Beauchesne <gwenole.beauchesne@intel.com>

vaapipostproc: fix passthrough mode.

If no explicit output surface format is supplied try to keep the one
supplied through the sink pad caps. This avoids a useless copy, even
if things are kept in GPU memory.

This is a performance regression from git commit dfa70b9.

vaapipostproc: fix output buffer to have a GstVaapiVideoMemory.

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

[used new infrastructure through base decide_allocation() impl]
Signed-off-by: Gwenole Beauchesne <gwenole.beauchesne@intel.com>

vaapipostproc: enable advanced deinterlacing with same format.

If only advanced deinterlacing is requested, i.e. deinterlacing is
the only active algorithm to apply with source and output surface
formats being the same, then make sure to enable VPP processing.

Otherwise, allow fallback to bob-deinterlacing with simple rendering
flags alteration.

vaapivideomemory: avoid NULL pointer unref if GstVaapiImage creation failed.

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

plugins: fix memory leaks.

plugins: factor out decide_allocation() hook.

Add a default decide_allocation() hook to GstVaapiPluginBase. The caps
feature argument can be used to force a bufferpool with a specific kind
of memory.

plugins: allow bufferpool to not allocate vaapi video meta.

Add GST_VAAPI_VIDEO_BUFFER_POOL_ACQUIRE_FLAG_NO_ALLOC params flag that
can be used to disable early allocations of vaapi video metas on buffers,
thus delagating that to the bufferpool user.

plugins: re-indent all GstVaapiVideo* related source code.

surfaceproxy: fix copy to propagate view_id.

Fix gst_vaapi_surface_proxy_copy() to copy the view-id element, thus
fixing random frames skipped when vaapipostproc element is used in
passthrough mode. In that mode, GstMemory is copied, thus including
the underlying GstVaapiVideoMeta and associated GstVaapiSurfaceProxy.

vaapipostproc: fix detection of output surface format changes.

Default to I420 format for output surfaces so that to match the usual
GStreamer pipelines. Though, internally, we could still opt for NV12
surface formats, i.e. default format=ENCODED is a hint for that, thus
delegating the decision to the VA driver.

vaapipostproc: fix construction of allowed sink pad caps.

Fix construction of the set of caps allowed on the sink pad to filter
out unsupported raw video caps with GStreamer >= 1.2.

vaapipostproc: improve heuristics for detecting native VA surfaces.

Use the new gst_caps_has_vaapi_surface() helper function to detect
whether the sink pad caps contain native VA surfaces, or not, i.e.
no raw video caps.

Also rename is_raw_yuv to get_va_surfaces to make the variable more
explicit as we just want a way to differentiate raw video caps from
VA surfaces actually.

vaapipostproc: disable discontinuity detection code.

The "discontinuity" tracking code, whereby lost frames are tentatively
detected, is inoperant if the sink pad buffer timestamps are not right
to begin with.

This is a temporary workaround until the following bug is fixed:
https://bugzilla.gnome.org/show_bug.cgi?id=734386

vaapipostproc: fix heuristic for detecting discontinuity.

In order to make the discontinuity detection code useful, we need to
detect the lost frames in the history as early as the previous frame.
This is because some VA implementations only support one reference
frame for advanced deinterlacing.

In practice, turn the condition for detecting new frame that is beyond
the previous frame from field_duration*2 to field_duration*3, i.e.
nothing received for the past frame and a half because of possible
rounding errors when calculating the field-duration either in this
element (vaapipostproc), or from the upstream element (parser element).

This is a regression introduced with commit faefd62.

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

plugins: fix detection of raw video caps.

Use the new gst_caps_has_vaapi_surface() helper function to better
detect raw video caps, and in particular those from RGB colorspace.

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

plugins: add helper for detecting VA surfaces in caps.

Introduce new gst_caps_has_vaapi_surface() helper function to detect
whether the supplied caps has VA surfaces. With GStreamer >= 1.2, this
implies a check for memory:VASurface caps features, and format=ENCODED
for earlier versions of GStreamer.

vaapidecode: start the decoder task again after finishing

This allows the element to accept data again after draining without
a hard reset or caps change happening in between.

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

vaapidecode: unlock condition variables before shutting down the element

Otherwise threads might wait for them, causing the shutdown of the element
to deadlock on the streaming thread.

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

vaapidecode: reset decoder_finish variable after stopping the decoder thread

Otherwise the element is not usable again after draining/EOS.

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

vaapidecode: don't try flushing the decoder instance if we didn't create one yet

This otherwise results in unnecessary error messages.

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

build: fix with --no-undefined linker flags.

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

vaapisink: add support for GstColorBalance interface.

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

[fixed channel names, simplified range factor, fixed memory leak]
Signed-off-by: Gwenole Beauchesne <gwenole.beauchesne@intel.com>

vaapisink: add support for colorbalance adjustment.

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

[fixed and simplified tracking of colorbalance value changes]
Signed-off-by: Gwenole Beauchesne <gwenole.beauchesne@intel.com>

vaapisink: improve installation of properties.

Simplify the creation and installation process of properties, by first
accumulating them into a g_properties[] array, and next calling into
g_object_class_install_properties().

Also add missing docs and flags to some properties.

vaapisink: code clean-ups.

Move code around in a more logical way. Introduce GST_VAAPISINK_CAST()
helper macro and use it wherever we know the object is a GstBaseSink or
any base class. Drop explicit initializers for values that have defaults
set to zero.

vaapisink: re-indent all GstVaapiSink related source code.

vaapisink: introduce separate backends.

Introduce new backends vtable so that to have clean separation between
display dependent code and common base code. That's a "soft" separation,
we don't really need dedicated objects.

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

vaapisink: drop unused "synchronous" mode.

Support for X11 "synchronous" mode was never implemented, and was only
to be useful for debugging. Drop that altogether, that's not going to
be useful in practice.

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

vaapisink: drop unused variables.

Drop obsolete, and now unused, video_buffer_pool and video_buffer_size
variables. They got merged into the GstVaapiPluginBase object.

vaapisink: drop GLX rendering and fancy effects.

Rendering with GLX in vaapisink is kind of useless nowadays, including
OpenGL related fancy effects. Plain VA/GLX interfaces are also getting
deprecated in favor of EGL, or more direct buffer sharing with actual
GL textures.

Should testing of interop with GLX be needed, one could still be using
the modern cluttersink or glimagesink elements.

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

vaapisink: listen to window size changes on X11.

Allow dynamic changes to the window, e.g. performed by the user, and
make sure to refresh its contents, while preserving aspect ratio.

In practice, Expose and ConfigureNotify events are tracked in X11
display mode by default. This occurs in a separte event thread, and
this is similar to what xvimagesink does. Any of those events will
trigger a reconfiguration of the window "soft" size, subsequently
the render-rect when necessary, and finally _expose() the result.

The default of handle_events=true can be changed programatically via
gst_x_overlay_handle_events().

Thanks to Fabrice Bellet for rebasing the patch.

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

[dropped XInitThreads(), cleaned up the code a little]
Signed-off-by: Gwenole Beauchesne <gwenole.beauchesne@intel.com>

vaapidecode: decode and output all pending frames on normal EOS.

The gst_vaapidecode_decode_loop() function is called within a separate
task to fetch and output all frames that were decoded so far. So, if
the decoder_loop_status is forcibly set to EOS when _finish() is called,
then we are bound to exist the task without submitting the pending
frames.

If the downstream element error'ed out, then the gst_pad_push() would
propagate up an error and so we will get it right for cutting off
_finish() early in that case.

This is a regression from 6003596.

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

Bump version for development.

AUTHORS: updates.

NEWS: updates.

vaapidecode: properly return from decode loop on downstream errors.

Fixes a hang/race on shutdown where _decode_loop() had already completed
its execution and _finish() was waiting on a GCond for decode_loop()
to complete.  Also fixes the possible race where _finish() is called
but _decode_loop() endlessly returns before signalling completion
iff the decoder instance returns GST_FLOW_OK.

Found with: ... ! vaapidecode ! {glimagesink,cluttersink}

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

[factored out GST_VIDEO_DECODER_STREAM_UNLOCK() call]
Signed-off-by: Gwenole Beauchesne <gwenole.beauchesne@intel.com>

0.5.9.

vaapisink: fix GstVideoOverlay::expose() implementation.

Now that we always track the currently active video buffer, it is
not necessary to automatically increase its reference since this is
implicitly performed in ::show_frame() through the get_input_buffer()
helper from GstVaapiPluginBase class.

This is a regression from a26df80.

vaapidecode: simplify bufferpool configuration.

Rework the logics behind the configuration of an adequate bufferpool,
especially when OpenGL meta or additional capsfeatures are needed.

Besides, for GStreamer >= 1.4, the first capsfeatures that gets matched,
and that is not system memory, is now selected by default.

vaapidecode: fix auto-plugging of vaapisink element.

Make sure to propagate memory:VASurface capsfeature to srcpad caps
only for GStreamer >= 1.5 as the plug-in elements in GStreamer 1.4
core currently miss additional patches available in 1.5-git (1.6).

This is a temporary workaround.

configure: allow builds against GStreamer git (1.5.x).

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

configure: fix build with GStreamer 1.4.0 release.

debian: fix packaging for new naming scheme.

NEWS: updates.

configure: mark support for GStreamer < 1.2 as deprecated.

Supporting anything thing below GStreamer 1.2 is asking for trouble
for keeping up with the required facilities to make efficient pipelines.
Users are invited to upgrade to the very latest GStreamer 1.2.x release,
at the minimum.

configure: mark support for GStreamer 0.10 as obsolete.

Support for GStreamer 0.10 is obsolete. i.e. it is no longer supported
and may actually be removed altogether for a future release. There is
no real point to maintain a build for such an ancient GStreamer version
that is not even supported upstream.

vaapisink: allow a specific view component to be displayed.

If a multiview stream is decoded, multiple view components are submitted
as is downstream. It is the responsibility of the sink element to display
the required view components. By default, always select the frame buffer
that matches the view-id of the very first frame to be displayed.

However, introduce a "view-id" property to allow the selection of a
specific view component of interest to display.

vaapisink: always keep the last displayed buffer around.

Always record the VA surface that is currently being rendered, no matter
the fact we are using texturedblit or overlay. That's because in some
occasions, we need to refresh or resize the displayed contents based on
new events. e.g. user-resized window.

Besides, it's simpler to track the last video buffer in GstVaapiSink than
through the base sink "last-sample".

vaapisink: add support for "display-name" property.

Add a "display-name" property to vaapisink so that the end user could
select the desired output. Keep "display-name" in-line with the existing
"display" (GstVaapiDisplayXXX type).

So, for X11 or GLX, the "display-name" is the usual display name as we
know for XOpenDisplay(); for Wayland, the "display-name" is the name used
for wl_display_connect(); and for DRM, the "display-name" is actually the
DRI device name.

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

window: make gst_vaapi_window_reconfigure() thread-safe.

Ensure the X11 implementation for GstVaapiWindow::get_geometry() is
thread-safe by default, so that upper layer users don't need to handle
that explicitly.

window: allow for updating size from current geometry.

Add gst_vaapi_window_reconfigure() interface to force an update of
the GstVaapiWindow "soft" size, based on the current geometry of the
underlying native window.

This can be useful for instance to synchronize the window size when
the user changed it.

Thanks to Fabrice Bellet for rebasing the patch.

[changed interface to gst_vaapi_window_reconfigure()]
Signed-off-by: Gwenole Beauchesne <gwenole.beauchesne@intel.com>

window: re-indent all GstVaapiWindow related source code.

display: add interface to retrieve the display name.

Add gst_vaapi_display_get_display_name() helper function to determine
the name associated with the underlying native display. Note that for
raw DRM backends, the display name is actually the device path.

display: fix comparison of X11 display names.

Make sure to not only compare display host names, but also the actual
display number. The screen number does not need to be checked at this
time.

vaapidecode: add support for VideoAlignment bufferpool option.

Always add VideoAlignment bufferpool option if the downstream element
expects its own pool to be used but does not offer it through a proper
propose_allocation() implementation for instance, and that the ALLOCATION
query does not expose the availability of the Video Meta API.

This fixes propagation of video buffer stride information to Firefox.

vaapivideomemory: always prefer native VA surface formats.

Make sure to always prefer native internal formats for the VA surfaces
that get allocated. Also disable "direct-rendering" mode in this case.

This is needed so that to make sure that anything that gets out of the
decoder, or anything that gets into the encoder, is in native format
for the hardware, and thus the driver doesn't need to perform implicit
conversions in there. Interop with SW elements is still available with
fast implementations of VA imaging APIs.

vaapivideomemory: disallow memory shares across buffers, use a copy.

Forbid shares of GstMemory instances, and rather make copy of it. This
effectively copies the GstMemory structure and enclosed metadata, but
this does not copy the VA surface contents itself. It should though.

This fixes preroll and makes sure to not download garbage for the first
frame when a SW rendering sink is used.

vaapivideomemory: use an image pool to cache objects.

Use an image pool to hold VA images to be used for downloads/uploads
of contents for the associated surface.

This is an optmization for size. So, instead of creating as many VA
images as there are buffers (then VA surfaces) allocated, we only
maintain a minimal set of live VA images, thus preserving memory
resources.

vaapivideomemory: forbid R/W mappings if non direct-rendering mode.

Disable read-write mappings if "direct-rendering" is not supported.
Since the ordering of read and write operations is not specified,
this would require to always download the VA surface on _map(), then
commit the temporary VA image back to the VA surface on _unmap().

Some SW decoding plug-in elements still use R/W mappings though.

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

vaapivideomemory: minor code clean-ups.

Fix error messages introduced in the previous commit for the _map()
imaplementation. Also use the new get_image_data() helper function
to determine the base pixels data buffer from a GstVaapiImage when
updating the video info structure from it.

vaapivideomemory: add support for raw pixels mappings.

Allow raw pixels of the whole frame to be mapped read-only. i.e. in
cases where the buffer pool is allocated without VideoMeta API, thus
individual planes cannot be mapped.

This is initial support for Firefox >= 30.

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

vaapivideomemory: fix determination of the surface pool format.

While creating the vaapi video allocator, make sure the associated
surface pool has correct format instead of defaulting to NV12 video
format even though there is no direct rendering support.

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

vaapivideomemory: fix association of surface to proxy.

Make sure to always update the VA surface pointer whenever the proxy
changes. This used to only work when the VA surface is written to, in
interop with SW element ("upload" feature), and this now fixes cases
when the VA surface is needed for reading, in interop with SW element
("download" feature).

plugins: expose I420 format for interop with SW elements.

Always expose I420 format by default when the VA surface could be
mapped for interoperability with non harware accelerated elements.
However, the default behaviour remains the auto-plugging of vaapi
elements, down to the sink.

Side effect: "direct-rendering" mode is also disabled most of the
times as plain memcpy() from uncached speculative write combining
memory is not going to be efficient enough.

plugins: allow download capability to vaapidecode element.

Fix support for VA surface download capability in vaapidecode element
for GStreamer >= 1.2. This is a fix to supporting libva-vdpau-driver,
but also the libva-intel-driver while performing hardware accelerated
conversions from the native VA surface format (NV12) to the desired
output VA image format.

For instance, this fixes pipelines involving vaapidecode ! xvimagesink.

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

decoder: mpeg4: fix picture decoder return value for skipped frames.

The picture decoder should return GST_VAAPI_DECODER_STATUS_DROP_FRAME
when a frame should be skipped, so the stream processing is not stalled.

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

decoder: mpeg2: respect any input PTS provided for a frame.

The timestamp generator in gstvaapidecoder_mpeg2.c always interpolated
frame timestamps within a GOP, even when it's been fed input PTS for
every frame.

That leads to incorrect output timestamps in some situations - for example
live playback where input timestamps have been scaled based on arrival time
from the network and don't exactly match the framerate.

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

GstVaapiObject: make gst_vaapi_object_new() more robust.

Forbid GstVaapiObject to be created without an associated klass spec.
It is mandatory that the subclass implements an adequate .finalize()
hook, so it shall provide a valid GstVaapiObjectClass.

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

[made non-NULL klass argument to gst_vaapi_object_new() a requirement]
Signed-off-by: Gwenole Beauchesne <gwenole.beauchesne@intel.com>

GstVaapiObject: initialize the derived object data with init() hook.

Call the subclass .init() function in gst_vaapi_object_new(), if
needed. The default behaviour is to zero initialize the subclass
object data, then the .init() function can be used to initialize
fields to non-default values, e.g. VA object ids to VA_INVALID_ID.

Also fix the gst_vaapi_object_new() description, which was merely
copied from GstVaapiMiniObject.

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

[changed to always zero initialize the subclass]
Signed-off-by: Gwenole Beauchesne <gwenole.beauchesne@intel.com>

vaapidecode: make decoder work with playbin

When playbin/decodebin builds the pipeline, it puts decoders and sinks
into different bins and forwards the queries from bins to bins. So in
the initials steps the pipeline is built iteratively by playbin and
looks like this :

[filesrc]

[filesrc] -> [typefind]

[filesrc] -> [typefind] -> [demuxer]

[filesrc] -> [typefind] -> [demuxer] -> [decoder]

At this point the decoder is asked for its SRC caps and it will make a
choice based on what gst_pad_peer_query_caps() returns. The problem is
that the caps returns at that point includes caps features like ANY,
essentially because playbin can plug in additional elements like
videoscale, videoconv or deinterlace.

This patch adds a another call to
gst_vaapi_find_preferred_caps_feature() when the decoder decides its
allocation, to make sure we asks the downstream elements when the
entire pipeline has been built.

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

vaapipostproc: don't let tmp_rect go out of scope.

A compiler change showed me that tmp_rect went out of scope before
it was used. Move it to the beginning of the function instead.

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

Signed-off-by: Simon Farnsworth <simon.farnsworth@onelan.co.uk>
[added guards for GStreamer 0.10 builds]
Signed-off-by: Gwenole Beauchesne <gwenole.beauchesne@intel.com>

AUTHORS: updates.

README: updates.

Drop references to deprecated plugins (vaapiupload, vaapidownload),
mention that support for GStreamer 0.10 is deprecated, make overview
more descriptive in certain aspects.

NEWS: updates.

build: mention that support for GStreamer 0.10 is deprecated.

build: fix for GStreamer 0.10.

build: fix for GStreamer 1.0.x.

decoder: h264: detect incorrectly paired fields in frames.

When a DPB flush is required, e.g. at a natural and of stream or issued
explicitly through an IDR, try to detect any frame left in the DPB that
is interlaced but does not contain two decoded fields. In that case, mark
the picture as having a single field only.

This avoids a hang while decoding tv_cut.mkv.

decoder: h264: simplify the DPB output process.

Simplify the dpb_output() function to exclusively rely on the frame store
buffer to output, since this is now always provided. Besides, also fix
cases where split fields would not be displayed.

This is a regression from f48b1e0.

h264parse: drop patches merged upstream.

0003-h264parse-fix-and-optimize-NAL-collection-function.patch
0005-h264parse-introduce-new-state-tracking-variables.patch
0006-h264parse-improve-conditions-for-skipping-NAL-units.patch
0007-h264parse-fix-collection-of-access-units-to-preserve.patch

decoder: h264: fix memory leak in PPS.

Cope with latest changes from codecparsers/h264. It is now required
to explicitly clear the GstH264PPS structure as it could contain
additional allocations (slice_group_ids).

codecparsers: update to gst-vaapi-branch commit 2d53b69.

c4ace00 h264parse: fix collection of access units to preserve config headers
0f9f7c9 h264parse: improve conditions for skipping NAL units
9ffb25c h264parse: introduce new state tracking variables
64955d3 h264parse: fix and optimize NAL collection function
13cd2a3 h264: clarifications and documentation fixes
53e7dd1 h264: fix identification of EOSEQ and EOS NALs
18f0de0 h264: fix memory leak in GstH264PPS
fdcb54c h264: fix typo in GstH264VUIParams description
fd4dae9 vp8: move up built-in range decoder private data