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
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 is not needed. Since
shared memory limits are low compared to RAM, we remove this waste.
https://bugzilla.gnome.org/show_bug.cgi?id=727236
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
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.
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.
