ximagesink and xvimagesink use XkbKeycodeToKeysym when the key event is
received. However, this function returns NoSymbol if Xkb is unavailable.
This causes all key events to be translated to "unknown" key when running
ximagsink under some VNC.
Fix it by using XKeycodeToKeysym if Xkb is unavailable.
I'm currently playing with modified ximagesink that does XGrabPointer()
in order to receive the mouse events occurred outside of the window and
send them to the navigation interface.
The pointer positions usually have positive coordinates, but it could
be negative with that change.
When the ximagesink handles XEvent that contains a negative pointer
coordinate, it incorrectly generates the GstEvent that contains an
extremely large positive pointer coordinate.
This is because the negative pointer position in XEvent is incorrectly
converted from signed to unsigned and passed as an argument to
gst_navigation_send_mouse_event() which causes implicit conversion from
integer to double. So the pointer position in the received XEvent and
generated GstEvent are completely different.
This potential problem does not seem to be a real problem with unmodified
ximagesink but there is no reason to leave it as is. This also fixes
xvimagesink that has the same potential problem.
https://bugzilla.gnome.org/show_bug.cgi?id=791140
When ximagesink is given a new window handle, it should check
its geometry and if the size of the new window differs from
the previous one, create reconfigure event in order to get
a chance to negotiate a more suitable image resolution with
the upstream elements.
We can't rely on receiving Expose or ConfigureNotify from
the X server for the newly assigned window, which would also
generate reconfigure.
https://bugzilla.gnome.org/show_bug.cgi?id=765424
libgstreamer currently exports some debug category
symbols GST_CAT_*, but those are not declared in any
public headers.
Some plugins and libgstvideo just use GST_DEBUG_CATEGORY_EXTERN()
to declare and use those, but that's just not right at
all, and it won't work on Windows with MSVC. Instead look
up the categories via the API.
Sharing the internal pool results in situation where the pool may have
two upstream owners. This create a race upon deactivation. Instead,
always offer a new pool, and keep the internal pool internal in case
we absolutely need it.
https://bugzilla.gnome.org/show_bug.cgi?id=748344
When X screen return a depth = 32 with bpp = 32, the alpha mask
must be correctly set to have a known GStreamer video format.
X visual structure doesn't provide the alpha mask information,
but we can find it from the others masks.
https://bugzilla.gnome.org/show_bug.cgi?id=700413
If the intersection between our caps and the filter caps is
empty, just immediately return EMPTY caps instead of trying
to access the (non-existant) structures.
Don't ever block when acquiring a buffer from the bufferpool in the fallback
mode. If we block, we might deadlock when going to PAUSED because we never
unlock when going to paused.
The acquire can block when there are no more buffers in the pool, this is a
sign that the pool is too small. Since we are the only ones using the pool in
the fallback case and because we scale the buffer, someone else must be using
our pool as well and is doing something bad.
