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
https://github.com/mesonbuild/meson
With contributions from:
Tim-Philipp Müller <tim@centricular.com>
Jussi Pakkanen <jpakkane@gmail.com> (original port)
Highlights of the features provided are:
* Faster builds on Linux (~40-50% faster)
* The ability to build with MSVC on Windows
* Generate Visual Studio project files
* Generate XCode project files
* Much faster builds on Windows (on-par with Linux)
* Seriously fast configure and building on embedded
... and many more. For more details see:
http://blog.nirbheek.in/2016/05/gstreamer-and-meson-new-hope.htmlhttp://blog.nirbheek.in/2016/07/building-and-developing-gstreamer-using.html
Building with Meson should work on both Linux and Windows, but may
need a few more tweaks on other operating systems.
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
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
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.
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.
