[wl_shell] is officially [deprecated], so provide support for the
XDG-shell protocol should be provided by all desktop-like compositors.
(In case they don't, we can of course fall back to wl_shell).

Note that the [XML spec] is provided by the `wayland-protocols`
git repository, which is provided by the Wayland project.

Fixes #897

[wl_shell]: https://people.freedesktop.org/~whot/wayland-doxygen/wayland/Client/group__iface__wl__shell.html
[deprecated]: https://github.com/wayland-project/wayland/commit/698dde195837f3d0844b2725ba4ea8ce9ee7518c
[XML spec]: https://github.com/wayland-project/wayland-protocols/blob/master/stable/xdg-shell/xdg-shell.xml

Add the fullscreen property that makes the sink displayed all across
the output.

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

This fixes conflict resolution error introduced in commit:

  816d1153

http://bugzilla.gnome.org/show_bug.cgi?id=790042

gst_allocator_find() needs gst_object_unref() after usage.

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

We change the video info base on the received buffer. We need to
rollback these changes whenever we want to copy into our internal
pool of buffers.

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

As SHM interface only support 1 stride, and 1 offset, we need to
make sure that there is no padding between planes for planar formats.

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

We where setting the size to the first memory size, this may be
too small in case we received a buffer with multiple memory.

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

There was this regression that we'd be using the updated video
info size instead of default size when initializing the pool.

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

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

The sink->video_info might not reflect the current buffer
when expose is being called.

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

The SHM interface does not allow passing arbitrary strides and offsets,
for this reason, we simply disable this feature from the proposed pool.

This fixes video artifact seen when using the FFMPEG based video
decoder.

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

When tee is used, it will not request a pool, but still it wants to
know how many buffers are required.

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

When the sink receives a buffer that is neither a wl_shm one nor a
dmabuf one, this buffer is copied to an internal wl_shm buffer before
being sent to the display.
In that case, the actual size of the received buffer (which may differ
from the one negotiated in the caps) must be used.

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

Reset redraw_pending at display disconnection, so we can re-connect
later from a clean state (avoid endless buffer drops).
Add a log to inform of dropped buffers.

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

Simplify and fix some of the show_frame logic.

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

Support the wayland zwp_linux_dmabuf_unstable_v1 protocol.
SHM formats and DMABuf formats are exposed differently in caps: the
DMABuf formats are flagged with GST_CAPS_FEATURE_MEMORY_DMABUF.
No buffer pool is proposed for DMABuf buffers, it is the upstream
element responsibility to provide with such buffers.

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

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

There was a small omission in the code. It still worked, but the pool
configuration may not have been optimimal.

CID: 1373420

This is specific to when the waylandsink is not being embedded. In
this patch we pass the render lock to the window so it can safely
call gst_wl_window_set_render_rectangle() with the new size.

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

We already take the render lock from the wlqueue thread in some other
place which indicates that there is no use of this atomic instead of
a proper locking mechanism.

Upstream must configure the pool before using it. Pre-configuring
the proposed pool could hide bugs in upstream elements.

This add support for non-standard strides to be used. Note that
some extra work is needed for multi-plane format which may have
a different GstMemory object per plane. This is not currently a
problem since SHM interface is limited to 1 memory.

The buffer pool API does not allow multiple of owner. This otherwise
lead to error when renegotiation take place. Aso consider the
allocation query "need_pool" boolean.

Otherwise those error may go unseen making debugging much
harder.

This fixes the property show-preroll-frame expose by the VideoSink base
class and removes redundant code.

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

rename gst-launch --> gst-launch-1.0
replace old elements with new elements(ffmpegcolorspace -> videoconvert, ffenc_** -> avenc_**)
fix caps in examples

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

g_free() is NULL-safe

Waylandsink needs exception code in gst_wayland_sink_set_window_handle().
After making sink->window, User can call
gst_wayland_sink_set_window_handle(). It is the user's fault, but
Waylandsink needs to handle the exception, if not then sink->window is
changed and rendering fails.

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

Waylandsink needs exception code in gst_wayland_sink_set_context(). After
calling gst_wayland_sink_set_context(), below code is set.
GST_ELEMENT_CLASS (parent_class)->set_context (element, context); but, If
user can call onemore. It is user's fault. but waylandsink need to
exception.

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

This wl_display proxy is temporary only until waylandsink goes NULL,
at which point the connection to the display is disposed. Unfortunately,
if this is advertised as a GstContext, playbin will cache it and re-feed
it to the sink when it goes PLAYING again, but the wl_display pointer
will at that point be invalid and cause a crash.

Another solution to the problem would be to also cache the GstWlDisplay
object inside the GstContext, which would automatically ref-count
the display connection, but I see no reason in doing that at the moment,
as there are no known users of this GstContext outside waylandsink.
It's probably better to avoid chasing hidden refcounts.

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

Copy-paste mistake; the wl_buffer was attached on the wrong buffer...

These formats are specific to the wl_shm interface. We are going
to add dmabuf formats later as well.

Coverity CID : 1256565