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 previous patch increased allocations by 15 bytes in order to ensure
16 byte alignment for g_malloc blocks. However, shared memory is
already block aligned, and this extra 15 bytes caused allocation
to fail when we were already allocating to the shared memory limit,
which is a lot smaller than typical available RAM.
Fix this by removing the alignment slack when allocating shared
memory.
https://bugzilla.gnome.org/show_bug.cgi?id=706066
Video buffer pool will update video alignment to respect stride alignment
requirement. But haven't updated it to video alignment in configure.
Which will cause user get wrong video alignment.
Fixes https://bugzilla.gnome.org/show_bug.cgi?id=741501
Update the new buffer size after alignment in the pool configuration
before calling the parent set_config. This ensures that the parent knows
about the buffer size that we will allocate and makes the size check
work in the release_buffer method.
Fixes https://bugzilla.gnome.org/show_bug.cgi?id=741420
Don't try to set port attribute that's not advertised by the
adaptor. Fixes videotestsrc ! xvimagesink aborting with
X Error of failed request: BadMatch (invalid parameter attributes)
Major opcode of failed request: 151 (XVideo)
Minor opcode of failed request: 13 ()
on intel HD4600 graphics with kernel 3.16, xserver 1.15,
intel driver 2.21.15.
Can't print a GstMemory via GST_PTR_FORMAT, it will crash
inside GObject checking if it's a GObject, and we can't
check generically whether it's a derived GstMemory type,
as boxed types don't allowe derivation.
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
Align the allocated memory to 16 bytes. When doing XSHM we are already aligned
to a page boundary but without, we use plain g_malloc, which could allocate
aligned on 8 bytes only.
See https://bugzilla.gnome.org/show_bug.cgi?id=680796
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.
