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
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
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
