Cropping was not handled properly when frames have to be copied to
xvimage's buffer pool, first because the crop meta were dropped, and
second because the allocated frame size in xvimage's buffer pool were
smaller than the incoming frame.
This patch updates xvimagesink's video info when propose_allocation()
is called, and copies the GstVideoCropMeta from source frame to
destination one.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/merge_requests/1088>
Buffer pool is created every time setcaps() is called, but it's
required only when upstream doesn't use it, so it's only needed to
copy frames onto XV buffers.
This patch delay the creation of the buffer pool until it's frame copy
is required.
Part-of: <https://gitlab.freedesktop.org/gstreamer/gst-plugins-base/-/merge_requests/1088>
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
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.
Right now navigation events are being sent via gst_pad_send_event
after getting the peer pad of the sinkpad.
But the same functionality can be done using gst_pad_push_event
without need of getting peer pad in xvimagesink.
https://bugzilla.gnome.org/show_bug.cgi?id=752059
Sharing the internal pool results in situation where the pool may have
two upstream owners. This creates 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
A xvcontext can be created early in gst_xvimagesink_set_window_handle().
In this case don't recreate, i.e. overwrite it in gst_xvimagesink_open().
Otherwise XEvents won't be handled in the xevent listener thread.
Fixes a regression when setting the window handle on the sink in
the very beginning before changing its state.
https://bugzilla.gnome.org/show_bug.cgi?id=715138
Make a new refcounted xvcontext object that handles the X connection.
Use the xvcontext to allocate images and windows. Move some code
around so that all X calls are made from the xvcontext object.
Make a GstXvImageAllocator object that allocates images from the xvcontext. We
can implement a copy function now for these memory objects now.
Make the bufferpool use the xvimageallocator object for its images.
We don't want to share the memory between buffers because that could
cause the memory of the bufferpool buffers to be copied and replaced
with other memory.
This is a hopefully a temporary fix until we can figure out how to share
properly.
Fixes https://bugzilla.gnome.org/show_bug.cgi?id=695203
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.
